4. 危害识别：功能失效、危害事件、危害分类
好，咱们进入HARA最核心的一步——危害识别。
说白了，这一步就是要回答一个问题：我的系统如果出毛病了，到底会怎么伤害人？
我见过不少新手，上来就对着功能列表猛写“刹车失灵”、“转向卡死”。这太粗糙了。真正的危害识别，需要你把一个抽象的功能失效，翻译成具体的、可感知的危害事件，然后再给它分门别类。
4.1 功能失效：源头在哪里？
一切危害，都源于功能失效。但注意，不是所有失效都会导致危害。比如，车里的空调坏了，你热得满头大汗，这不叫危害（除非中暑导致你撞车）。
功能失效，我习惯把它分成两类：
- 失效 (Loss of Function)：该干活的时候不干活。比如，你踩了刹车，但刹车没反应。
- 非预期功能 (Unexpected Function)：不该干活的时候瞎干活。比如，你没踩刹车，但刹车自己抱死了。
嗯，这里要注意。很多工程师只盯着“失效”看，忽略了“非预期功能”。
4.2 危害事件：把失效翻译成场景
光有“刹车失效”还不够。你得问自己：在什么场景下，这个失效会变成危害？
这就是危害事件。它包含三个要素：
- 功能失效：比如，制动助力失效。
- 运行场景：比如，车辆在高速公路上以120km/h行驶。
- 操作条件：比如，驾驶员需要紧急制动避让前车。
你看，同样的“制动助力失效”，在停车场里慢慢挪车，可能只是吓一跳；但在高速上，那就是要命的事。
我个人习惯，在写危害事件时，一定要把场景写具体。不要写“车辆行驶中”，要写“车辆在湿滑路面、夜间、弯道行驶中”。场景越具体，后面的ASIL等级评估就越准确。
你看，这个描述就非常清晰，后续的S、E、C参数打分几乎不会产生争议。
4.3 危害分类：给危害贴上标签
危害事件列出来了，接下来就是分类。分类的目的是为了后续的ASIL等级评估做准备。常见的分类维度有：
| 分类维度 | 说明 | 举例 |
|---|---|---|
| 对人员伤害 | 直接导致乘员、行人受伤 | 碰撞、碾压 |
| 对车辆控制 | 导致车辆失控或非预期运动 | 非预期加速、转向锁死 |
| 对系统可用性 | 导致关键功能不可用 | 制动助力失效、灯光熄灭 |
| 对法规合规性 | 违反功能安全或法规要求 | 排放超标、功能安全目标未满足 |
你想想看，这个分类其实是在帮我们理清思路。比如，一个“非预期加速”的危害，它既属于“对车辆控制”，也属于“对人员伤害”。分类不是绝对的，但一定要有逻辑。
4.4 实战中的常见误区
最后，我总结几个我在评审中经常看到的坑：
- 把功能失效当危害事件：比如只写“车门无法打开”，而不写“在车辆落水后，车门无法打开导致乘员无法逃生”。
- 场景过于笼统：比如“车辆行驶中”。行驶中？是市区还是高速？是白天还是黑夜？这直接影响E（暴露概率）的评估。
- 忽略组合失效：比如，只分析单个传感器失效，没考虑“传感器失效 + 驾驶员分心”的组合情况。
嗯，说到这里，我想起一个项目。当时我们分析一个自动紧急制动（AEB）系统，只考虑了“雷达失效”和“摄像头失效”的单一情况。结果在实车测试中，发现当雷达和摄像头同时被泥巴遮挡时，系统会进入一个未定义的状态，直接导致车辆不制动。这就是典型的组合失效没识别到。
所以，做危害识别，一定要穷举，要具体，要场景化。别偷懒，这一步做得越扎实，后面的工作就越轻松。