3. 危害识别（Hazard Identification）：运行场景与模式分析、功能失效模式、危害事件定义
好，我们进入HARA的第三步——危害识别。
这一步说白了，就是把「系统可能怎么坏」这件事，从模糊的担忧变成具体的清单。我个人觉得，这是整个HARA里最考验工程直觉的一步。你想想看，如果连危害都找不全，后面的风险评估和安全目标设计，全都是在沙滩上盖楼。
3.1 运行场景与模式分析
先别急着想失效。第一步，你得搞清楚：我的系统在什么情况下工作？
我习惯把运行场景拆成三个维度来考虑：
- 车辆状态：上电、下电、行驶、驻车、充电、休眠……
- 环境条件：白天/黑夜、晴天/雨雪、隧道/开阔地、高海拔/低海拔……
- 人为操作：驾驶员正常操作、误操作、无操作（比如L3级自动驾驶下驾驶员在睡觉）
举个例子。我在做电动尾门项目时，一开始只考虑了「车辆静止时开闭尾门」的场景。结果呢？有一次客户反馈，车辆在等红灯时，尾门突然自动打开了。后来一查，是因为系统把「车速为0」误判为「驻车状态」。你看，这就是场景分析没做全——忘了考虑「临时停车」这个模式。
关键原则：运行场景要覆盖「正常使用」和「合理可预见的误使用」。别只盯着设计工况，想想用户会怎么「乱来」。
3.2 功能失效模式
场景定好了，接下来就是问：在这个场景下，功能会怎么失效？
ISO 26262里常用的失效模式分类，我列个表给你看：
| 失效模式 | 含义 | 举个栗子（ACC自适应巡航） |
|---|---|---|
| 功能丧失 | 该干活时不干活 | 前车减速，ACC没反应 |
| 功能误触发 | 不该干活时瞎干活 | 前方没车，ACC突然急刹车 |
| 功能超出范围 | 干活太猛或太弱 | ACC请求的减速度超过车辆物理极限 |
| 功能方向错误 | 反着来 | 应该加速，结果减速了 |
| 功能时序错误 | 早到或迟到 | 制动请求晚了200ms，追尾了 |
嗯，这里要注意：不是每个功能都要穷举所有失效模式。我一般会先问自己一个问题——「这个功能最怕什么？」比如转向系统，最怕「方向错误」；制动系统，最怕「功能丧失」。抓住主要矛盾，效率更高。
我的小技巧：用「功能-场景-失效模式」三维矩阵来打勾。比如「ACC-高速跟车-功能丧失」打一个勾，代表这是一个需要分析的组合。这样不容易漏项。
3.3 危害事件定义
有了失效模式，再结合运行场景，就能定义出具体的「危害事件」了。
危害事件的标准格式是：「在[运行场景]下，[功能]发生[失效模式]，导致[危害]」。
举个例子：
- 在高速公路上以120km/h行驶时，ACC功能丧失，导致车辆无法自动减速，与前车发生碰撞。
- 在停车场内，电动尾门误触发，导致尾门撞到后方行人。
我曾经犯过一个错：把危害事件写得太笼统。比如「制动失效导致事故」——这等于没写。你得说清楚：什么场景？什么车速？什么路面？是追尾还是侧翻？越具体，后面的风险评估越准确。
避坑指南：危害事件不要写成「系统故障」。危害事件关注的是「对人的伤害」，不是「对系统的伤害」。比如「ECU烧毁」不是危害事件，「ECU烧毁导致制动助力丧失，车辆无法刹停」才是。
3.4 实战中的常见问题
最后，我总结几个我在评审会上经常看到的问题：
- 场景遗漏：只考虑「正常驾驶」，忘了「维修模式」「拖车模式」「充电模式」。
- 失效模式单一：只分析「功能丧失」，忽略了「误触发」和「时序错误」。
- 危害描述模糊：用「事故」「伤害」这种词，没有量化。建议用「导致车辆非预期加速」「导致转向力矩反向」这种可测量的描述。
说白了，危害识别就是一场「脑力风暴」——但得有章法。我建议你做完初稿后，找两个没参与过这个项目的人来评审。为什么？因为「当局者迷」，你自己觉得理所当然的场景，外人一看可能就发现漏洞。
好，这一步做完，你就有了一个「危害事件清单」。下一步，我们就要给这些危害事件「打分」了——也就是风险评估。咱们下一章见。