4、危害识别（Hazard Identification）

好，咱们进入HARA分析中最关键的一步——危害识别。

说实话，我见过不少团队，前面系统定义做得漂漂亮亮，一到危害识别就开始「放飞自我」。要么漏掉关键危害，要么把功能失效和系统失效混为一谈。结果呢？后期整改成本翻倍，项目延期，甚至召回。

所以这一章，咱们把危害识别这件事彻底讲透。

4.1 危害的定义

先问个问题：什么是危害？

ISO 26262里给的定义是：危害是由功能异常表现导致的潜在伤害源。

听起来有点绕？我换个说法。

危害不是事故本身，而是可能导致事故的那个「坏种子」。比如刹车失灵是危害，但撞车是事故。危害是「因」，事故是「果」。

我在一个EPS项目中就吃过亏。团队把「电机过流」直接当成危害，结果HARA分析做了三遍都不对。后来才发现，真正的危害是「转向助力突然丧失」，电机过流只是导致这个危害的一个故障模式。

嗯，这个坑我帮你们踩过了。

4.2 危害识别的方法

危害识别不是拍脑袋。我常用的方法有三种：头脑风暴、检查表、HAZOP。各有各的适用场景。

4.2.1 头脑风暴

这是最灵活的方法，适合项目早期。

叫上系统工程师、软件工程师、硬件工程师、测试工程师，甚至安全工程师（对，就是我这种人），关起门来聊一天。

怎么聊？我一般会问几个引导性问题：

• 「这个功能如果突然不工作了，会发生什么？」
• 「如果它工作得太积极了，又会怎样？」
• 「驾驶员在什么情况下会误解系统的行为？」

4.2.2 检查表

头脑风暴容易漏，检查表就是兜底的。

我自己的检查表里，会包含这些维度：

维度	典型问题
功能缺失	该有的功能没有？
功能过度	不该有的功能出现了？
功能错误	功能执行了但结果不对？
时序异常	功能执行得太早或太晚？
非预期激活	系统自己「抽风」了？

检查表的好处是标准化，新人也能上手。但坏处是——容易僵化。我见过有人对着检查表打勾，打完就说「OK，危害识别完了」。结果呢？漏了一堆场景。

所以我的建议是：检查表是辅助，不是全部。

4.2.3 HAZOP

HAZOP，全称是Hazard and Operability Study。这玩意儿最早是化工行业用的，后来被汽车行业「借」过来了。

它的核心思路是：用一组引导词，去「拷问」每个系统功能。

常用的引导词包括：

• 没有（No）：功能完全不执行
• 更多（More）：功能执行过度
• 更少（Less）：功能执行不足
• 相反（Reverse）：功能反向执行
• 部分（Part of）：功能只执行了一部分
• 伴随（As well as）：功能执行时附带其他行为
• 过早/过晚（Early/Late）：时序问题

举个例子，对于「自动紧急制动（AEB）」功能：

引导词	可能的危害
没有	需要制动时没制动 → 碰撞
更多	制动力过大 → 后车追尾
更少	制动力不足 → 碰撞
相反	该制动时加速 → 严重碰撞
过早	误触发制动 → 后车追尾
过晚	制动太迟 → 碰撞

你看，一个功能就能衍生出这么多危害。HAZOP的好处是系统化、不容易漏。但缺点也很明显——耗时。一个复杂的ADAS功能，HAZOP做一天是常事。

4.3 功能失效与系统失效的区别

这是很多人的知识盲区。我面试功能安全工程师时，必问这个问题。

功能失效：功能层面的异常表现。比如「转向助力丧失」、「制动距离增加」。它描述的是「系统做了什么不该做的事」或「没做什么该做的事」。

系统失效：技术层面的故障原因。比如「电机断线」、「传感器漂移」、「软件跑飞」。它描述的是「为什么系统会这样」。

举个例子你就明白了：

• 功能失效：车辆在湿滑路面上，ESP（电子稳定程序）没有介入 → 车辆失控
• 系统失效：ESP的横摆角速度传感器输出值漂移，导致控制算法误判 → ESP没有介入

看到了吗？功能失效是「症状」，系统失效是「病因」。

在HARA分析中，我们关注的是功能失效。为什么？因为危害是直接由功能失效导致的，而不是由某个具体的故障导致的。

我遇到过最典型的错误：有人把「CAN总线通信中断」直接当成危害。但你想，CAN总线中断本身不会造成伤害，造成伤害的是「因为CAN中断导致制动信号没传过去，最终刹车失灵」。所以，真正的危害是「制动功能丧失」。

好了，这一章的内容就到这里。下一章咱们聊聊「危害事件与安全目标」，也就是怎么把识别出来的危害，转化成可量化的安全要求。

到时候见。

---

公众号:蓝海资料掘金营，微信deep3321