2026年6月AEB功能安全基础执行包

1. 本月定位

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

6月主题：

AEB功能安全基础：HARA、Safety Goal、FSC/TSC。

本月目标不是泛泛了解 ISO 26262，而是围绕一个具体功能 AEB，把功能安全概念阶段的核心逻辑打通：

功能定义 -> 危险识别 -> 场景分析 -> ASIL判断 -> Safety Goal -> FSC -> TSC -> 需求追踪。

本月结束后，应能回答：

• AEB是什么功能，边界是什么？
• AEB有哪些危险事件？
• 为什么AEB漏触发和误触发都可能是安全问题？
• HARA到底怎么做？
• S/E/C分别怎么理解？
• ASIL为什么不能脱离场景固定判断？
• Safety Goal怎么从危险事件推导出来？
• FSC和TSC有什么区别？
• FSR和TSR如何分解？
• 如何把Safety Goal追踪到测试证据？

2. 本月交付物清单

3. 本月学习总图

功能安全分析可以理解为一个逐层收敛过程：

一句话理解：

HARA告诉你“什么场景下会有什么危险、严重到什么程度”；Safety Goal告诉你“系统必须避免什么”；FSC/TSC告诉你“系统怎么避免”；测试证据告诉你“怎么证明真的避免了”。

4. 功能安全基础概念

4.1 Item Definition

4.1.1 理论

Item Definition 是功能安全分析的入口。

它要回答：

• 分析对象是什么？
• 功能目标是什么？
• 系统边界在哪里？
• 输入是什么？
• 输出是什么？
• 与哪些外部系统交互？
• 驾驶员责任是什么？
• ODD或使用条件是什么？
• 不分析什么？

如果Item Definition不清楚，后面的HARA会失控。

例如，AEB可以有不同边界：

• 只分析纵向紧急制动功能。
• 分析AEB作为L2辅助驾驶功能的一部分。
• 分析AEB作为L3 ADS最小风险策略的一部分。
• 分析AEB与ACC、FCW、ESC、HMI的交互。

边界不同，HARA、ASIL、Safety Goal和安全机制都会不同。

4.1.2 AEB Item Definition示例

4.1.3 实践任务

请补充你自己的AEB Item Definition：

验收标准：

能清楚说明“我分析的是哪个AEB，不分析哪些内容”。

4.2 Hazard

4.2.1 理论

Hazard 是可能导致伤害的潜在来源。

在功能安全中，不能只写“系统故障”，要写这个故障可能造成的车辆危险行为。

错误写法：

• 感知模块故障。
• 雷达信号异常。
• 软件bug。
• 模型漏检。

更好的写法：

• AEB未在碰撞风险存在时触发制动。
• AEB在无碰撞风险时发出强制动请求。
• AEB发出过大的减速度请求。
• AEB关键传感器不可用但系统未降级。

区别是：

Hazard要面向车辆级危险行为，而不是停留在模块故障。

4.2.2 AEB主要Hazard清单

4.2.3 实践任务

补充至少3个AEB Hazard：

验收标准：

写出来的Hazard必须是车辆级危险行为，而不是模块级故障。

4.3 Operational Situation

4.3.1 理论

Operational Situation 是危险发生时的运行场景。

同一个Hazard，在不同Operational Situation下，风险等级可能不同。

例如：

危险：AEB误触发强制动。

不同场景：

• 高速巡航，后车距离很近。
• 城市低速拥堵。
• 地库低速行驶。

这三个场景的严重度、暴露率、可控性都不同，因此ASIL可能不同。

4.3.2 AEB典型Operational Situation

4.3.3 实践任务

对每个Hazard至少配置2个Operational Situation：

验收标准：

能说明为什么同一个Hazard在不同场景下ASIL可能不同。

4.4 Hazardous Event

4.4.1 理论

Hazardous Event = Hazard + Operational Situation。

也就是：

危险行为发生在具体运行场景中，才形成可评估的危险事件。

示例：

• Hazard：AEB未触发或触发过晚。
• Operational Situation：高速跟车，前车急刹。
• Hazardous Event：高速跟车前车急刹时，AEB未触发或触发过晚，导致追尾风险。

4.4.2 AEB Hazardous Event示例

4.4.3 实践任务

写出5个AEB Hazardous Event：

验收标准：

每个Hazardous Event都必须包含“危险行为 + 场景”。

5. HARA怎么做

5.1 HARA是什么

HARA 是 Hazard Analysis and Risk Assessment，危险分析与风险评估。

它的目标是：

• 找出功能可能导致的不合理风险。
• 结合运行场景评估风险等级。
• 推导Safety Goal。
• 为后续FSC/TSC提供输入。

HARA不是为了填表，而是为了回答：

这个功能在什么场景下可能伤人？严重程度如何？出现概率如何？驾驶员能不能控制？系统必须避免什么？

5.2 HARA核心字段

5.3 Severity怎么理解

Severity 表示可能伤害的严重程度。

常见理解：

注意：

Severity关注伤害后果，不关注发生概率。

AEB Severity示例

5.4 Exposure怎么理解

Exposure 表示车辆处于该运行场景的频率。

常见理解：

Exposure不是危险发生概率，而是运行场景出现概率。

例如：

• 高速跟车是常见场景，Exposure可能较高。
• 极端暴雪可能Exposure较低。
• 城市行人横穿在城市道路较常见。

AEB Exposure示例

5.5 Controllability怎么理解

Controllability 表示驾驶员或其他交通参与者避免伤害的能力。

常见理解：

Controllability非常依赖场景：

• 高速前车急刹，驾驶员可控性较差。
• 低速拥堵，驾驶员较容易控制。
• 行人突然横穿，行人和驾驶员可控性都可能低。

AEB Controllability示例

5.6 ASIL怎么理解

ASIL 是 Automotive Safety Integrity Level，汽车安全完整性等级。

从低到高：

• QM。
• ASIL A。
• ASIL B。
• ASIL C。
• ASIL D。

ASIL不是凭感觉定的，而是由：

Severity + Exposure + Controllability

共同决定。

注意：

• ASIL需要结合企业方法、车型、目标市场、ODD和评审规则最终确认。
• 学习作品集中可以写“ASIL候选”，不要绝对声称固定结论。
• 同一个功能不同危险事件可能有不同ASIL。
• 同一个危险事件在不同Operational Situation下ASIL也可能不同。

6. AEB HARA V1示例

以下表格用于学习和作品集初版，不代表真实项目最终ASIL。

6.1 示例1：高速跟车AEB漏触发

场景描述

自车在高速道路以100 km/h跟随前车行驶，前车突然急刹。AEB因目标检测漏检、TTC估计错误或风险判断延迟，未及时触发预警或制动。

风险分析

• Hazard：AEB未触发或触发过晚。
• Operational Situation：高速跟车，前车急刹。
• Hazardous Event：高速跟车前车急刹时，AEB未触发或触发过晚。
• 可能后果：高速追尾，乘员严重伤害。

S/E/C判断

Safety Goal草案

AEB应在ODD内当前方目标存在高碰撞风险时，在规定时间内触发预警或制动，以降低碰撞概率或减轻碰撞严重度。

后续需求方向

• 感知目标检测应覆盖前车急刹场景。
• TTC计算应满足时间准确性要求。
• AEB风险判断应在规定时间内完成。
• 制动请求应及时传递到底盘执行系统。
• 关键输入异常时应降级或提示。

6.2 示例2：高速AEB误触发强制动

场景描述

自车在高速道路正常巡航，前方无真实碰撞风险。由于路面阴影、金属反光、目标误检或融合错误，AEB错误发出强制动请求。

风险分析

• Hazard：AEB误触发强制动。
• Operational Situation：高速巡航，后车距离较近。
• Hazardous Event：无真实碰撞风险时AEB误触发强制动。
• 可能后果：后车追尾，乘员受伤，交通扰动。

S/E/C判断

Safety Goal草案

AEB不应在无合理碰撞风险时发出导致车辆显著减速的强制动请求。

后续需求方向

• AEB制动请求应经过独立合理性检查。
• 应检查目标持续性、TTC范围、目标类别、置信度。
• 应进行多传感器一致性检查。
• 应限制最大减速度、jerk和制动持续时间。
• 对误检高发场景应建立回归测试集。

6.3 示例3：传感器污染未识别

场景描述

雨雾、泥污、雪、水滴等导致摄像头或雷达性能下降，但系统未识别传感器不可用或性能退化，AEB继续输出可信判断。

风险分析

• Hazard：关键传感器退化未被识别。
• Operational Situation：雨雾或传感器污染场景。
• Hazardous Event：传感器退化但AEB继续输出可信判断。
• 可能后果：漏触发、误触发或错误风险评估。

S/E/C判断

Safety Goal草案

当AEB关键传感器、感知链路或制动执行链路不满足安全运行条件时，系统应进入降级、退出或驾驶员提示状态。

7. Safety Goal怎么推导

7.1 理论

Safety Goal是从HARA中高风险危险事件推导出的顶层安全目标。

Safety Goal要表达：

系统必须避免什么不合理风险。

不要把Safety Goal写得太细。

错误写法：

• 摄像头应以30fps输出图像。
• TTC阈值应设置为1.5秒。
• CAN信号超时时间应为100ms。

这些是技术需求，不是Safety Goal。

更好的写法：

• AEB应在ODD内碰撞风险超过阈值时及时触发预警或制动。
• AEB不应在无合理碰撞风险时发出强制动请求。
• AEB制动请求应被限制在车辆稳定性和乘员安全范围内。
• AEB不可用、降级或退出时应及时提示驾驶员。

7.2 AEB Safety Goals V1

7.3 Safety Goal检查标准

一个好的Safety Goal应满足：

• 来源于HARA。
• 描述车辆级安全目标。
• 不过早指定具体技术实现。
• 能被进一步分解为FSR。
• 能通过验证证据证明。

8. FSC功能安全概念

8.1 FSC是什么

FSC 是 Functional Safety Concept，功能安全概念。

它回答：

为了实现Safety Goal，系统在功能层面应该具备哪些安全能力？

FSC通常输出：

• Functional Safety Requirement，FSR。
• 安全状态。
• 功能降级策略。
• 初步安全机制。
• 功能分配对象。

FSC仍然偏功能层，不应该过早写具体代码、通信周期、芯片配置。

8.2 AEB FSC V1

8.3 FSC示例解释

以 SG-AEB-002 为例：

Safety Goal：

AEB不应在无合理碰撞风险时发出导致车辆显著减速的强制动请求。

对应FSR：

AEB制动请求应经过独立合理性检查，避免单点错误导致误制动。

为什么合理：

• 误制动可能来自感知误检、TTC错误、软件逻辑错误。
• 独立合理性检查可以作为安全机制，阻止明显不合理的制动请求。
• 后续TSC可以进一步定义检查内容，如目标有效性、车速范围、TTC范围、目标持续性、多传感器一致性。

9. TSC技术安全概念

9.1 TSC是什么

TSC 是 Technical Safety Concept，技术安全概念。

它回答：

功能层安全需求如何落到系统架构、技术机制和接口要求上？

TSC比FSC更具体。

它会涉及：

• 传感器输入检查。
• 时间同步。
• 信号有效性。
• 目标一致性。
• TTC合理性。
• 制动请求限幅。
• 通信超时。
• E2E保护。
• 诊断。
• 降级。
• HMI提示。

9.2 AEB TSC V1

9.3 TSC示例解释

以 TSR-AEB-004 为例：

技术需求：

AEB制动请求应由独立监控器检查目标有效性、车速范围、TTC范围和驾驶员输入。

它解决的问题：

• 感知误检导致虚假目标。
• TTC计算错误导致误制动。
• 软件逻辑错误导致错误制动请求。
• 驾驶员已经踩油门或转向避让时系统仍强制动。

监控器可以检查：

• 目标是否持续存在。
• 目标是否位于自车路径相关区域。
• TTC是否在合理范围。
• 车速是否在AEB工作范围。
• 驾驶员是否已有明确接管输入。
• 制动请求是否超过限制。

10. SG-FSR-TSR追踪表

追踪表的意义：

认证机构或面试官问“你如何证明这个Safety Goal被落实”，你可以从SG一路追踪到FSR、TSR、验证方法和证据。

10.1 代码视角：追踪矩阵完整性检查

6月的代码实践不需要复杂开发，只需要把追踪关系变成可检查规则。

目的：

防止Safety Goal、FSR、TSR、验证方法和证据之间出现断链。

建议用CSV或YAML维护追踪表，字段包括：

检查规则：

• 每个 SG 至少关联一个 FSR。
• 每个 FSR 至少关联一个 TSR。
• 每个 TSR 必须有验证方法。
• 每个验证方法必须有证据类型。
• 不允许出现空字段。

伪代码示意：

# 伪代码示意，后续可实现为 scripts/trace/traceability_check.py
for sg in safety_goals:
    assert has_related_fsr(sg)

for fsr in functional_safety_requirements:
    assert has_related_tsr(fsr)

for tsr in technical_safety_requirements:
    assert has_verification(tsr)
    assert has_evidence(tsr)

输出报告应包括：

• 缺少FSR的Safety Goal。
• 缺少TSR的FSR。
• 缺少验证方法的TSR。
• 缺少证据的验证项。
• 是否满足进入Safety Case的最低完整性。

11. 6月实践任务

11.1 实践任务1：完成AEB Item Definition

填写模板：

11.2 实践任务2：写出至少6个Hazardous Event

填写模板：

11.3 实践任务3：完成HARA V1

填写模板：

要求：

• 每个S/E/C都必须写理由。
• ASIL写“候选”，不要写死。
• Safety Goal不要写成技术实现。

11.4 实践任务4：完成Safety Goals V1

填写模板：

11.5 实践任务5：完成FSC V1

填写模板：

11.6 实践任务6：完成TSC V1

填写模板：

11.7 实践任务7：完成追踪表

填写模板：

12. 常见错误

12.1 把故障当成Hazard

错误：

摄像头故障。

正确：

摄像头故障导致AEB未识别前方目标，系统未触发制动，产生碰撞风险。

12.2 脱离场景判断ASIL

错误：

AEB一定是ASIL D。

正确：

AEB不同危险事件、不同运行场景下ASIL不同，需要结合S/E/C判断。

12.3 Safety Goal写得太技术化

错误：

系统应在100ms内检测CAN信号超时。

正确：

AEB关键输入或执行链路不满足安全运行条件时，系统应降级、退出或提示驾驶员。

12.4 FSC和TSC混淆

FSC偏功能安全能力：

系统应监控关键传感器状态。

TSC偏技术实现要求：

摄像头目标输入应检查时间戳、有效位、更新周期和信号冻结。

12.5 没有追踪关系

如果只有HARA、Safety Goal、FSR、TSR分散存在，但没有追踪表，就很难支撑认证和审计。

必须建立：

HE -> SG -> FSR -> TSR -> Verification -> Evidence

13. 6月验收问答

13.1 AEB Item Definition为什么重要？

回答：

Item Definition定义分析对象和边界。如果不明确AEB的功能目标、输入输出、驾驶员责任、ODD和不覆盖范围，HARA会失控，ASIL判断和Safety Goal也会不稳定。

13.2 Hazard和Failure有什么区别？

回答：

Failure是系统、硬件、软件或模型层面的失效，例如摄像头信号异常、模型漏检。Hazard是车辆级危险行为，例如AEB未触发或误触发。功能安全分析最终关注的是Failure可能导致的车辆级Hazard。

13.3 Hazardous Event是什么？

回答：

Hazardous Event是Hazard和Operational Situation的组合。只有把危险行为放到具体运行场景中，才能评估Severity、Exposure和Controllability。

13.4 ASIL为什么不能固定说AEB就是ASIL D？

回答：

ASIL由Severity、Exposure和Controllability共同决定。同一个AEB功能中，漏触发、误触发、制动请求过大、传感器退化未识别等危险事件不同；同一个危险事件在高速、城市、低速拥堵等场景下S/E/C也不同，因此ASIL不能脱离场景固定判断。

13.5 Safety Goal和FSR有什么区别？

回答：

Safety Goal是从HARA推导出的顶层安全目标，描述系统必须避免的不合理风险。FSR是为了实现Safety Goal而定义的功能安全需求，更接近系统应具备的安全能力。

13.6 FSC和TSC有什么区别？

回答：

FSC是功能安全概念，回答系统在功能层面应具备哪些安全能力。TSC是技术安全概念，回答这些功能安全需求如何落到系统架构、技术机制、接口和诊断上。

13.7 AEB误触发为什么也是功能安全问题？

回答：

AEB误触发强制动可能导致后车追尾、乘员伤害和交通扰动，因此不仅漏触发是风险，误触发也是不合理风险。需要通过目标合理性检查、多传感器一致性、制动请求限幅、误触发场景回归测试等机制控制。

13.8 AI模型漏检应该放在FuSa、SOTIF还是AI Safety？

回答：

要看原因。如果漏检来自硬件、通信或软件故障，偏FuSa；如果传感器未故障但在夜间、遮挡、逆光等场景能力不足，偏SOTIF；如果漏检来自数据覆盖不足、模型泛化不足或增训回归问题，偏AI Safety。真实项目中三者可能交叉，需要在Safety Case中说明边界和证据。

14. 与5月成果的衔接

5月学习的AI基础概念会进入6月功能安全分析：

15. 与7月学习的衔接

7月会进入：

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

6月输出会作为7月输入：

• Safety Goal会映射到架构中的感知、融合、AEB决策、制动执行、HMI、诊断。
• FSR会帮助确定功能层安全能力。
• TSR会帮助分析技术安全机制放在哪里。
• 追踪表会帮助后续连接测试验证和Safety Case。

16. 6月底复盘模板

17. 本月最终验收标准

6月底应达到：

• 能独立解释AEB功能安全分析流程。
• 能写出AEB Item Definition。
• 能识别至少6个AEB Hazardous Event。
• 能对至少3个危险事件做S/E/C分析。
• 能解释ASIL候选理由。
• 能从HARA推导Safety Goal。
• 能从Safety Goal拆出FSR。
• 能从FSR拆出TSR。
• 能建立基础追踪表。
• 能在面试中用AEB漏触发和误触发讲清楚FuSa基础逻辑。

一句话验收：

看到一个AEB风险，你能从“危险事件”一路讲到“安全目标、功能需求、技术机制和验证证据”。

18. 端到端模型视角补充

端到端模型不会取消HARA、Safety Goal、FSC/TSC的价值。

它改变的是：

安全需求不再总能清晰分配到传统感知、预测、规划模块，而要更多分配到模型行为约束、运行时监控和输出安全检查。

18.1 HARA如何适配端到端模型

端到端下，危险事件应从“模块失效”转向“模型输出危险行为”。

18.2 Safety Goal如何适配端到端模型

Safety Goal应保持车辆级表达。

示例：

• 端到端驾驶模型不应在无合理碰撞风险时输出导致车辆显著减速的控制行为。
• 端到端驾驶模型应在目标ODD内对高碰撞风险场景输出及时、可执行且安全的减速或避让行为。
• 当输入超出ODD、模型置信度不足或运行时监控发现输出异常时，系统应进入降级、fallback或请求接管。

18.3 FSC/TSC如何适配端到端模型

端到端下的安全机制更应关注：

• 输出轨迹合理性检查。
• 碰撞风险独立监控。
• 速度、加速度、jerk限制。
• 交通规则约束。
• ODD/OOD监控。
• fallback/MRC。
• 模型版本回归测试。
• 运行时异常检测。

18.4 新增实践任务

将AEB危险事件改写为端到端行为风险：

验收：

能把传统模块化HARA语言改写成端到端模型行为安全语言。