3、危害识别：功能失效分析、系统性失效与随机硬件失效、危害事件的识别方法
好，咱们进入HARA分析最核心的一步——危害识别。
说实话，很多工程师做HARA容易犯一个毛病：拿到系统就开始列故障清单，恨不得把所有能想到的坏情况都写上去。结果呢？文档厚得像本字典，真正有用的信息却没多少。
我个人习惯是，先搞清楚三个问题：
- 功能失效到底长什么样？
- 失效的来源是系统性的，还是随机的？
- 怎么把这些失效转化成危害事件？
咱们一个一个来拆解。
3.1 功能失效分析：从功能到失效的映射
功能失效分析，说白了就是回答一个问题：“这个功能如果坏了，会怎样？”
你想想看，一个EPS（电动助力转向）系统，它的基本功能是“根据驾驶员转向意图提供助力”。那失效模式有哪些？
- 助力突然消失——方向盘变沉
- 助力过大——方向盘发飘
- 助力反向——你往左打，它往右推
- 助力卡滞——方向盘转不动
嗯，这里要注意：功能失效 ≠ 硬件故障。功能失效是从“功能表现”的角度去描述的，而不是从“哪个零件坏了”的角度。
核心原则：每个功能至少对应一种失效模式。如果一个功能你找不到任何失效模式，说明你对这个功能的理解还不够深。
我在项目中遇到过一件事：一个团队做ADAS的HARA，列了30多种失效模式，结果评审时发现有一半其实是同一个失效的不同表现。后来我让他们用“功能-失效-影响”三层映射表来梳理，一下子就清晰了。
| 功能 | 失效模式 | 失效影响（车辆层面） |
|---|---|---|
| 提供转向助力 | 助力丧失 | 驾驶员需施加更大手力，转向沉重 |
| 提供转向助力 | 助力过大 | 转向过度，车辆可能偏离车道 |
| 提供转向助力 | 助力反向 | 驾驶员意图与车辆响应相反，极易失控 |
| 提供转向助力 | 助力卡滞 | 方向盘无法转动，车辆失去转向能力 |
3.2 系统性失效 vs 随机硬件失效：两种不同的“坏法”
做危害识别时，很多人会纠结：这个失效到底算系统性的，还是随机硬件的？
我的判断方法很简单：
- 系统性失效：设计或制造过程中的“bug”。只要条件触发，它必然发生。比如软件里有个逻辑漏洞，每次车速超过120km/h就会触发误报警。
- 随机硬件失效：硬件老化、磨损、环境应力导致的“意外”。它可能发生，但概率可以估算。比如电阻开路、电容漏液、芯片闩锁。
避坑指南：我曾经见过一个项目，把“软件跑飞”归为随机硬件失效。这是不对的。软件跑飞通常是系统性失效（设计缺陷），除非你能证明是硬件位翻转导致的。记住：软件没有随机失效，只有设计缺陷。
为什么这个区分很重要？因为ISO 26262对两者的处理方式完全不同：
| 失效类型 | 应对策略 | 安全机制 |
|---|---|---|
| 系统性失效 | 通过过程控制、设计规范、评审、测试来避免 | 冗余设计、多样性设计、故障检测 |
| 随机硬件失效 | 通过硬件架构、失效率计算、诊断覆盖率来降低风险 | 监控电路、ECC、看门狗、冗余 |
嗯，这里有个小技巧：做HARA时，先不要管失效是系统性的还是随机的。先把所有可能的失效模式列出来，等到了安全目标定义阶段，再根据失效性质去分配不同的安全机制。否则你会在识别阶段就陷入无休止的争论。
3.3 危害事件的识别方法：从失效到场景
功能失效分析完了，接下来最关键的一步：把失效放到具体场景中，变成危害事件。
为什么需要场景？因为同一个失效，在不同场景下危害程度天差地别。
举个例子：
- “转向助力丧失”这个失效，在低速泊车时，驾驶员还能应付，顶多费点劲。
- 但同样的失效，在高速变道时，驾驶员可能瞬间失控，导致严重事故。
所以，危害事件 = 功能失效 + 运行场景 + 系统状态。
识别方法三步走：
- 列出所有功能失效（刚才咱们做的）
- 列出典型运行场景（高速、低速、弯道、直道、雨雪、夜间……）
- 组合配对，形成危害事件
我个人习惯用“失效-场景矩阵”来做这件事。横轴是失效模式，纵轴是典型场景，交叉点就是危害事件。
| 场景 \ 失效 | 助力丧失 | 助力过大 | 助力反向 |
|---|---|---|---|
| 高速直行（100km/h） | 驾驶员需用力修正，可能偏离车道 | 转向过度，车辆甩尾 | 车辆瞬间反向转向，严重失控 |
| 低速泊车（5km/h） | 转向沉重，但可控 | 转向过快，可能碰撞相邻车辆 | 驾驶员困惑，可能误操作 |
| 弯道行驶（60km/h） | 出弯困难，可能冲出路外 | 入弯过度，可能侧翻 | 车辆反向转向，极易翻滚 |
你可能会问：场景要列多少才够？
我的经验是：不要贪多。先覆盖最典型的3-5个场景，把危害等级最高的找出来。等安全目标定下来后，再回头补充边缘场景。否则你会在场景枚举上浪费大量时间。
重要提醒：危害事件描述必须包含“什么失效”、“在什么场景下”、“导致什么后果”。缺少任何一项，后续的ASIL等级评估都会出问题。
我曾经见过一个危害事件只写了“转向助力失效”，没有场景和后果。结果评审时大家吵了一个小时，才发现每个人想象的场景都不一样。从那以后，我要求团队必须用“当……时，由于……，导致……”的句式来描述危害事件。
3.4 实战中的常见误区
最后，分享几个我踩过的坑：
- 误区一：把故障模式当危害事件。比如“ECU供电失效”是故障模式，不是危害事件。危害事件应该是“当车辆高速行驶时，由于ECU供电失效导致转向助力丧失，驾驶员无法控制车辆”。
- 误区二：忽略多故障组合。ISO 26262要求考虑单点故障，但实际中很多严重事故是多个故障叠加的结果。我的建议是：先做单点故障的HARA，再针对关键安全目标做多故障分析。
- 误区三：场景太笼统。“正常行驶”这种场景太模糊了。要具体到车速范围、道路类型、环境条件。越具体，后续的ASIL评估越准确。
好了，危害识别这部分就讲到这里。下一章咱们会进入ASIL等级评估，看看怎么给这些危害事件定级。记住一句话：危害识别做得越扎实，后面的安全设计就越有底气。