2026年7月ADS架构与空间感知安全风险执行包

1. 本月定位

本文件是 12-2026年度双轨学习与能力建设计划书.md 中“2026年7月计划”的具体实现。

7月主题：

ADS系统架构 + PV/BEV/Occupancy安全风险。

6月已经围绕AEB建立了功能安全基础，包括 Item Definition、Hazard、Hazardous Event、HARA、Safety Goal、FSC、TSC 和 SG-FSR-TSR 追踪。

7月要解决的问题是：

这些安全目标和安全需求到底落在ADS系统架构的哪些环节？AI感知错误如何传播到规划、控制、执行器和HMI？PV、BEV、Occupancy这些空间感知表达方式分别有什么安全风险？

本月目标不是训练感知模型，也不是实现BEV算法，而是建立安全负责人需要的系统架构理解能力。

2. 本月应达到的能力

7月底应具备：

• 能画出AEB从传感器到制动执行的基本链路。
• 能解释感知、融合、风险判断、制动请求、执行器、HMI、诊断之间的关系。
• 能说明PV、BEV、Occupancy分别是什么、用于哪里、有哪些安全风险。
• 能解释感知错误如何传播为规划错误、控制错误和执行风险。
• 能把6月的 Safety Goal / FSR / TSR 映射到ADS架构模块。
• 能初步将ADS架构方法迁移到机器人感知-规划-控制-执行链路。

3. 本月交付物清单

4. ADS系统架构总览

4.1 ADS是什么

ADS 是 Automated Driving System，自动驾驶系统。

从安全分析角度，ADS不是一个单独模块，而是一条从环境感知到车辆执行的链路。

典型链路如下：

对于AEB而言，链路可以简化为：

一句话理解：

AEB不是“感知模型发现障碍物就刹车”，而是传感器、感知、融合、风险评估、制动决策、独立监控、执行器、HMI和诊断共同构成的安全链路。

4.2 ADS主要模块

5. AEB系统链路

5.1 AEB输入

AEB通常需要以下输入：

5.2 AEB输出

5.3 AEB风险传播路径

路径一：感知漏检 -> AEB漏触发

安全解释：

• 感知漏检对应 FN / False Negative。
• 如果没有其他传感器或监控机制补偿，AEB可能完全不触发。
• 这会进入HARA中的“前方真实目标存在，AEB未触发或触发过晚”危险事件。

路径二：感知误检 -> AEB误触发

安全解释：

• 感知误检对应 FP / False Positive。
• 如果没有目标持续性、TTC合理性、多传感器一致性和独立监控，可能导致误制动。

路径三：距离/速度估计错误 -> 触发时机错误

安全解释：

• 即使目标被正确检测，如果距离或相对速度错误，AEB仍可能触发过早或过晚。
• 所以AEB不仅需要分类正确，还需要空间位置、速度和时间同步可靠。

路径四：制动请求错误 -> 执行风险

安全解释：

• 即使感知正确，错误制动请求也可能引入新风险。
• 因此需要制动请求限幅、jerk限制、持续时间限制和独立监控。

路径五：降级未提示 -> 驾驶员误信任

安全解释：

• 这是交互安全问题。
• 功能不可用、降级、退出或ODD边界条件必须通过HMI清晰提示。

6. PV、BEV、Occupancy是什么

6.1 PV，Perspective View

PV 是 Perspective View，即相机透视视角。

它接近人眼或相机看到的原始图像视角。

示例：

• 前视相机看到前方车辆、行人、车道线。
• 环视相机看到车辆周围环境。
• 目标检测模型在图像上输出2D框。

PV的优点：

• 接近原始感知输入。
• 适合图像特征提取。
• 对语义信息较友好，例如识别车辆、行人、标志牌、车道线。

PV的安全风险：

• 远距离目标像素小，容易漏检。
• 透视关系导致距离估计困难。
• 遮挡和重叠目标难以判断。
• 强光、雨雾、夜间、反光会影响图像质量。
• 多相机之间视角和标定误差会影响融合。

安全追问：

• 相机标定是否可靠？
• 图像质量异常如何检测？
• 夜间、逆光、雨雾是否单独验证？
• PV检测结果如何转入3D空间或BEV空间？
• 距离估计是否有雷达或其他传感器校验？

6.2 BEV，Bird's Eye View

BEV 是 Bird's Eye View，即鸟瞰视角。

它把周围环境转换到俯视坐标系中，更接近规划和控制需要的空间表达。

BEV常用于：

• 多摄像头融合。
• 目标位置表达。
• 可行驶区域识别。
• 轨迹预测。
• 规划避障。
• Occupancy表达。

BEV的优点：

• 适合表达目标相对自车的位置。
• 适合规划和控制使用。
• 便于融合多传感器、多相机信息。
• 对路径、障碍物、车道和可行驶区域更直观。

BEV的安全风险：

• PV到BEV转换依赖标定和深度估计。
• 标定错误会导致目标位置偏移。
• 时间同步错误会导致动态目标位置错误。
• 遮挡区域可能被错误表达为可通行。
• BEV中的小位置误差可能导致规划错误。

安全追问：

• BEV坐标误差如何评估？
• 多相机外参标定是否有监控？
• 动态目标时间同步如何保证？
• 遮挡和未知区域如何表达？
• BEV不确定性是否传递给规划？

6.3 Occupancy

Occupancy 表示空间是否被占用。

相比传统目标框，Occupancy更关注：

• 某个空间格子是否有障碍物。
• 某个区域是否可通行。
• 是否存在未知或不规则障碍物。

Occupancy常用于：

• 自动驾驶可通行空间判断。
• 低矮障碍物识别。
• 不规则物体表达。
• 机器人避障。
• 人形机器人周围空间理解。

Occupancy的优点：

• 不依赖目标类别一定被识别出来。
• 可以表达不规则障碍物。
• 对未知物体和可行驶空间有价值。
• 更适合机器人和自动驾驶的避障场景。

Occupancy的安全风险：

• 低矮障碍物、透明物体、悬空物体可能被漏掉。
• 未知区域如果被错误认为可通行，会导致碰撞。
• 占用空间误差会影响路径规划。
• 动态物体占用变化如果更新不及时，会导致规划滞后。

安全追问：

• 未知空间如何表达？
• 不确定性是否传递给规划？
• 可通行区域是否过度乐观？
• 低矮、透明、反光物体是否专项测试？
• Occupancy失败时是否降级或保守规划？

7. PV、BEV、Occupancy对比

一句话理解：

• PV 关注“看到了什么”。
• BEV 关注“它在自车周围哪里”。
• Occupancy 关注“哪些空间被占用或不可通行”。

8. BEV错误如何传播为安全风险

8.1 目标位置偏移

场景：

BEV中前方车辆位置被估计得比真实位置更远。

风险传播：

安全影响：

• AEB认为碰撞风险较低。
• 制动触发延迟。
• 制动距离不足。

8.2 虚假占用

场景：

BEV中将路面反光错误表达为障碍物。

风险传播：

安全影响：

• AEB可能误触发。
• NOA可能异常绕行。
• 机器人可能误停。

8.3 遮挡区域过度乐观

场景：

BEV或Occupancy将遮挡区域错误表达为可通行。

风险传播：

安全影响：

• 系统未对遮挡区域保持保守。
• 行人、两轮车、障碍物突然出现时反应不足。

8.4 时间同步错误

场景：

多摄像头或雷达数据时间戳不同步，导致动态目标在BEV中位置错误。

安全影响：

• 目标轨迹不稳定。
• TTC计算错误。
• AEB触发过早或过晚。
• 规划轨迹不合理。

9. AEB Safety Goal到架构模块映射

10. FSR/TSR到架构模块映射

11. 交互安全与HMI在架构中的位置

交互安全不是附属功能，而是ADS安全链路的一部分。

典型交互安全风险：

• 功能已经退出，但驾驶员以为仍可用。
• AEB不可用，但没有明显提示。
• 接管请求不清晰。
• 功能降级状态没有被驾驶员理解。
• 驾驶员对系统能力产生过度信任。
• 不同自动驾驶模式之间切换提示不清。

HMI应支持：

• 功能可用状态提示。
• 功能不可用提示。
• 降级提示。
• 故障提示。
• 接管请求。
• 风险预警。
• 驾驶员响应确认。

安全追问：

• 驾驶员是否能及时理解系统状态？
• 提示是否足够清晰？
• 声音、视觉、触觉是否组合使用？
• 接管请求是否有足够提前量？
• 功能退出后是否仍可能让驾驶员误信任？

12. ADS架构与机器人架构对比

一句话：

ADS和机器人都遵循“感知-理解-规划-控制-执行-交互”的安全链路，只是执行对象从车辆变成了机器人本体、轮式底盘或机械臂。

13. 代码视角：架构风险表的结构化管理

7月可以继续保持轻量代码实践。

目标不是写ADS软件，而是把架构风险结构化。

建议用CSV/YAML维护架构风险表：

可检查规则：

• 每个关键模块是否至少有一个失效模式。
• 每个失效模式是否有安全后果。
• 每个安全后果是否有检测方式。
• 每个检测方式是否有缓解措施。
• 每个缓解措施是否有验证证据。

伪代码：

for row in architecture_risks:
    assert row["module"]
    assert row["failure_mode"]
    assert row["safety_effect"]
    assert row["detection"]
    assert row["mitigation"]

输出：

• 架构风险缺口清单。
• 缺少检测机制的失效模式。
• 缺少验证证据的缓解措施。

14. 7月实践任务

14.1 实践任务1：画出AEB系统链路

要求至少包含：

• 传感器。
• 感知。
• 融合。
• TTC/风险评估。
• AEB决策。
• 独立监控器。
• 制动请求。
• 制动执行。
• HMI。
• 诊断和事件记录。

14.2 实践任务2：完成ADS模块风险表

填写模板：

14.3 实践任务3：写PV/BEV/Occupancy安全说明

要求：

• 每个概念用一句话解释。
• 每个概念列出至少3个安全风险。
• 每个概念列出至少3个安全追问。

14.4 实践任务4：完成AEB Safety Goal到架构映射

填写模板：

14.5 实践任务5：完成ADS与机器人架构对比

要求：

• 至少列出8组对应关系。
• 每组说明安全迁移逻辑。
• 重点关注感知、空间理解、规划、控制、执行和交互。

15. 常见错误

15.1 只懂模型，不懂系统链路

错误：

感知模型Recall提升，所以系统一定更安全。

正确：

感知只是链路一部分。还需要看融合、TTC、决策、监控、制动执行、HMI和诊断。

15.2 把BEV当成天然安全

错误：

BEV能看全局，所以更安全。

正确：

BEV依赖标定、深度估计、时间同步和数据覆盖。BEV错误会直接影响规划和控制。

15.3 忽略未知区域

错误：

没检测到障碍物，所以可通行。

正确：

未检测到不等于没有障碍物。遮挡和未知区域应保守处理。

15.4 忽略HMI和驾驶员理解

错误：

系统内部已经降级，所以安全。

正确：

如果驾驶员不知道系统降级，仍可能产生误信任和延迟接管风险。

16. 7月验收问答

16.1 ADS系统链路包括哪些主要模块？

回答：

典型ADS链路包括传感器、感知、融合、定位、预测、规划、控制、执行器、HMI和诊断。AEB可简化为传感器、目标检测、融合跟踪、TTC/风险评估、AEB决策、独立监控器、制动请求、制动执行、HMI和事件记录。

16.2 PV和BEV有什么区别？

回答：

PV是相机透视视角，接近原始图像，适合目标识别和语义理解；BEV是鸟瞰视角，把环境转换到俯视空间，更适合目标位置表达、规划和控制。PV关注“看到了什么”，BEV关注“它在自车周围哪里”。

16.3 BEV为什么不是天然安全？

回答：

BEV依赖相机标定、深度估计、多传感器融合和时间同步。标定错误、深度错误、动态目标时间不同步或遮挡区域表达错误，都可能导致目标位置偏移、虚假障碍或过度乐观的可通行区域，从而影响规划和控制。

16.4 Occupancy对安全有什么价值？

回答：

Occupancy关注空间是否被占用，能够表达未知物体、不规则障碍物和可通行区域。它对自动驾驶和机器人避障都有价值，尤其适合处理不容易分类的障碍物。但Occupancy也需要处理低矮、透明、悬空、动态物体和未知空间的不确定性。

16.5 感知错误如何传播到控制风险？

回答：

感知漏检会导致融合目标缺失，风险评估无法计算碰撞风险，AEB可能不触发；感知误检会生成虚假目标，TTC可能被错误计算为危险，AEB可能误制动；目标位置或速度估计错误会导致触发过早或过晚，最终影响制动执行和车辆安全。

16.6 HMI为什么是安全链路的一部分？

回答：

HMI负责向驾驶员表达功能状态、风险预警、降级、退出、故障和接管请求。如果提示不清晰或不及时，驾驶员可能误信任系统或延迟接管。因此HMI不仅是用户体验问题，也是交互安全问题。

16.7 ADS架构如何迁移到机器人安全？

回答：

ADS和机器人都遵循感知、理解、规划、控制、执行和交互的链路。ADS中的ODD可迁移为机器人操作域，BEV/Occupancy可迁移为机器人局部地图或占用栅格，MRC/fallback可迁移为机器人停止、退回或安全姿态，HMI可迁移为语音、屏幕、灯光或动作反馈。

17. 与6月成果的衔接

6月成果 | 7月用途

--- | ---

AEB Safety Goal | 映射到传感器、感知、融合、决策、执行、HMI模块

FSR | 确定功能层安全能力由哪个模块承担

TSR | 分配到具体技术机制，如输入检查、TTC检查、制动限幅

追踪矩阵 | 继续扩展到架构模块和验证证据

18. 与8月学习的衔接

8月会进入：

SOTIF、ODD、触发条件和机器人操作域。

7月成果将用于8月：

• ADS架构帮助判断触发条件影响哪个模块。
• PV/BEV/Occupancy风险帮助识别SOTIF功能不足。
• HMI和交互安全帮助分析驾驶员误信任、接管和功能退出风险。
• ADS与机器人架构对比帮助后续定义机器人操作域。

19. 7月底复盘模板

20. 本月最终验收标准

7月底应达到：

• 能画出AEB感知-决策-制动链路。
• 能解释ADS主要模块和安全风险。
• 能说清PV、BEV、Occupancy的区别和安全影响。
• 能解释BEV错误如何影响AEB、NOA或机器人避障。
• 能把AEB Safety Goal映射到架构模块。
• 能说清HMI、降级、退出和接管提示为什么属于安全问题。
• 能完成ADS架构与机器人架构对比。

一句话验收：

看到一个感知或空间理解错误，你能说明它如何沿ADS链路传播到规划、控制、执行器和HMI，并能提出检测、缓解和验证证据。

21. 端到端架构视角补充

端到端模型会弱化传统模块边界，但不会消除系统架构安全分析。

传统模块化ADS：

Sensor -> Perception -> Fusion -> Prediction -> Planning -> Control

端到端ADS：

Sensor / History / Map / Navigation -> End-to-End Model -> Trajectory / Control

表面上链路缩短了，但安全负责人仍需理解：

• 输入来自哪些传感器。
• 模型内部可能隐式学习了哪些空间表达。
• 输出是轨迹、控制还是高层动作。
• 输出是否经过独立安全检查。
• 执行器是否有约束和限幅。
• HMI是否能表达模型能力边界。

21.1 PV/BEV/Occupancy在端到端中的作用

端到端不代表没有PV、BEV、Occupancy。

它们可能变成：

• 模型内部隐式表征。
• 中间特征。
• 训练监督信号。
• 可解释性分析工具。
• 安全监控器输入。

安全追问：

• 模型是否显式或隐式使用BEV/Occupancy？
• 如果没有显式中间结果，如何解释空间理解错误？
• 是否有独立Occupancy或碰撞监控兜底？
• 输出轨迹是否与可通行空间一致？

21.2 端到端输出安全检查

端到端输出必须经过安全约束：

• 轨迹碰撞检查。
• 速度/加速度/jerk限制。
• 车道边界和道路边界检查。
• 与动态目标的时空冲突检查。
• ODD边界检查。
• fallback/MRC检查。

21.3 新增实践任务

将AEB链路改写为端到端安全链路：

Camera/Radar/History -> E2E Model -> Longitudinal Trajectory / Brake Intent -> Safety Monitor -> Brake System

输出一张表：