4. HARA 第二步：危害识别（Hazard Identification）

好，我们继续往下走。上一章我们聊了怎么把整车级的功能定义清楚，也就是 Item Definition。有了这个基础，HARA 的第二步——危害识别，才能真正落地。

说白了，这一步就是要回答一个问题：“我的系统如果出故障，到底会带来什么危险？”

很多人觉得这步简单，不就是列个清单吗？我刚开始做功能安全的时候也这么想。结果第一次做项目，漏掉了一个很关键的危害场景，后来被评审老师揪出来，改了好几版。嗯，从那以后我再也不敢小看这个环节了。

4.1 功能失效模式分析：从“功能”到“失效”

危害识别的起点，是分析每个功能的失效模式。你不能凭空想危害，得先知道“功能坏了”是什么样子。

我个人习惯用 “功能 + 失效类型” 的组合来推导。常见的失效类型就那几种：

• 功能丧失：该干活的时候不干活。比如刹车踩下去，没反应。
• 功能误报：不该干活的时候瞎干活。比如没障碍物，AEB 突然急刹。
• 功能超出：干活干过头了。比如加速踏板信号异常，导致非预期加速。
• 功能反向：往反方向干。比如转向系统，你往左打，它往右转。
• 功能卡滞：卡在一个固定值不动。比如车速信号一直显示 0 km/h。

你想想看，一个简单的“车门解锁”功能，如果出现“功能丧失”——你拉门把手，门不开，这在高速上就是致命问题。如果出现“功能误报”——行驶中门突然弹开，那更吓人。

4.2 基于场景的危害识别：把失效放到“真实世界”里

光有失效模式还不够。你得把失效放到具体的运行场景里去看，才能判断它是不是“危害”。

举个例子：“大灯功能丧失”。白天在市区开，最多就是仪表盘报个警，没什么大危险。但如果是晚上在高速上，没有路灯，突然大灯灭了——那就是要命的事。

所以，场景分析是危害识别的灵魂。我一般会从这几个维度去定义场景：

把这些维度组合起来，就能生成大量的具体场景。你不需要穷举所有组合，但关键场景一定要覆盖到。

4.3 Hazard 清单的建立：把分析结果结构化

好了，现在你有了失效模式，也有了场景。下一步就是把它们组合起来，形成一个个具体的 Hazard（危害事件）。

一个完整的 Hazard 描述，通常包含三个要素：

1. 失效行为：系统出了什么故障？
2. 运行场景：故障发生在什么条件下？
3. 潜在后果：对人或车会造成什么伤害？

举个例子，一个完整的 Hazard 条目可能是这样：

把所有识别出来的 Hazard 整理成一个清单，就是 Hazard List。这个清单是后续 ASIL 等级评定和功能安全目标定义的基础。

我个人习惯用表格来管理 Hazard List，结构清晰，方便评审。下面是一个简化的模板：

4.4 核心逻辑：从功能到危害的推导路径

为了让你更直观地理解整个推导过程，我画了一张流程图。它展示了从“功能定义”到“Hazard 清单”的完整路径。

这张图把整个流程串起来了。从功能定义出发，先做失效模式分析，再结合场景分析，最后识别出具体的危害，形成 Hazard 清单。每一步都有明确的输入和输出。

4.5 实战中的几个关键点

最后，分享几个我在实际项目中积累的经验，希望能帮你少走弯路：

• 别一个人闷头做：危害识别最好由功能安全工程师、系统工程师、甚至测试工程师一起做。不同视角能发现不同的问题。
• 场景要“够用”但不要“过度”：场景太多会陷入细节，太少又会漏掉关键危害。我一般会先列出 10-15 个典型场景，覆盖主要工况，再根据项目特点补充。
• Hazard 描述要“可验证”：每个 Hazard 的描述要清晰到让测试工程师能设计出对应的测试用例。如果描述模糊，后续的验证工作会很痛苦。
• 别忘了“人为因素”：有些危害不是系统本身故障，而是系统行为误导了驾驶员。比如，一个错误的报警信号导致驾驶员做出错误决策。这类危害也要纳入清单。