第3章 危害分析与风险评估（HARA）：HARA方法论、运行场景与危害识别、ASIL等级确定
好，咱们进入功能安全最核心的一步——HARA。
很多刚入行的产品经理，一听到HARA就头大。觉得它太理论、太抽象。其实说白了，HARA就是回答三个问题：
- 车会不会出危险？（危害识别）
- 在什么情况下出危险？（运行场景）
- 这个危险有多严重？（ASIL等级）
我个人习惯把HARA比作「给车辆做体检」。你想想看，医生看病得先问症状、看环境、再下诊断。HARA也是这个逻辑。
3.1 HARA方法论：从零开始的系统思维
HARA的全称是Hazard Analysis and Risk Assessment。它不是一个工具，而是一套方法论。
我见过不少团队，上来就拿着Excel表格填危害。结果填到一半发现，场景没定义清楚，ASIL等级算出来全是QM。嗯，这其实是在浪费时间。
正确的做法是什么？
- 定义系统边界：你的产品是做什么的？它和谁交互？
- 识别功能失效：如果这个功能坏了，会发生什么？
- 分析运行场景：在什么路况、什么车速、什么环境下失效？
- 评估风险等级：用严重度、暴露率、可控性三个维度打分。
我在项目中遇到过，有些产品经理把HARA做成了「填空题」。填完就扔给安全工程师，自己不管了。这是大忌。HARA是产品经理的武器，不是别人的作业。
核心要点：HARA不是一次性的工作。它需要随着项目迭代不断更新。我建议每个里程碑都重新审视一次HARA。
3.2 运行场景与危害识别：别让「想当然」害了你
危害识别，说白了就是「找茬」。但找茬得有依据。
我记得有一次，团队在做电动尾门的HARA。大家一致认为「尾门意外关闭」是危害。但场景呢？有人说是「在车库内」，有人说是「在高速上」。你想想看，这两个场景的ASIL等级能一样吗？
所以，运行场景必须具体。我一般会从三个维度去定义：
- 车辆状态：静止、低速、高速、转弯、倒车
- 环境条件：白天、夜晚、雨雪、隧道、停车场
- 用户行为：正常操作、误操作、系统故障
举个例子，同样是「刹车失灵」：
| 场景 | 危害描述 | 严重度 |
|---|---|---|
| 高速公路上120km/h | 车辆无法减速，碰撞风险极高 | S3 |
| 停车场内5km/h | 车辆缓慢溜车，可能轻微碰撞 | S1 |
你看，同一个功能失效，场景不同，结果天差地别。
我的小技巧：做危害识别时，拉上系统工程师、测试工程师一起头脑风暴。一个人想不全所有场景。我曾经有一次，就是测试同事提醒了我「倒车时尾门意外打开」这个场景，才补上了关键的一条危害。
3.3 ASIL等级确定：三个维度，一个公式
ASIL等级，是HARA的最终输出。它决定了你的安全目标有多高。
ASIL有四个等级：A、B、C、D。D是最严格的，A是最宽松的。还有一个QM，表示不需要安全措施。
确定ASIL等级，靠三个参数：
- Severity（S）：严重度。伤害有多重？轻伤、重伤、致命？
- Exposure（E）：暴露率。这个场景发生的概率高不高？
- Controllability（C）：可控性。驾驶员能不能避免事故？
公式很简单：ASIL = f(S, E, C)。具体查ISO 26262的表格就行。
我刚开始做HARA时，总喜欢把ASIL定得很高。觉得「安全嘛，越高越好」。后来发现，ASIL D意味着巨大的开发成本。你想想看，一个ASIL D的软件模块，光测试覆盖率就要达到90%以上。这可不是闹着玩的。
避坑指南：我曾经把一个「车内娱乐系统」的ASIL定成了B。后来评审时被安全专家怼了——「娱乐系统失效，最多影响用户体验，不会造成人身伤害，应该是QM。」嗯，从那以后我学会了：ASIL等级要基于事实，不要拍脑袋。
最后，我给大家一个实战建议：
做HARA时，一定要把每个危害的「安全目标」写清楚。安全目标就是「为了预防这个危害，系统必须做到什么」。比如：
- 危害：刹车踏板失效
- 安全目标：在驾驶员踩下刹车踏板后，车辆必须在200ms内开始减速
有了安全目标，后面的功能安全设计才有方向。
好了，这一章就到这里。下一章咱们聊聊「安全目标与功能安全概念」，这是把HARA落地到设计的关键一步。