第3章 危害分析与风险评估(HARA)：HARA方法、危害识别、风险评估与ASIL等级确定
好，咱们进入功能安全最核心的一步——HARA。
说实话，我见过不少项目，前期设计做得漂漂亮亮，一到HARA就开始糊弄。结果呢？后期测试发现一堆漏洞，ASIL等级定得不对，整个安全生命周期都得返工。所以这一章，咱们得把HARA的每个环节掰开揉碎了讲清楚。
3.1 HARA到底是什么？
HARA，全称Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 我的系统会不会出危险？（危害识别）
- 出了危险有多严重？（风险评估）
- 需要多严格的安全措施？（ASIL定级）
我个人习惯把HARA比作「体检」。你想想看，一个人没症状不代表没病。系统也一样，功能正常不代表没有潜在风险。HARA就是给系统做一次全面体检，把那些隐藏的「病灶」找出来。
核心原则：HARA必须在系统定义完成之后、详细设计开始之前进行。我见过有人把HARA拖到设计快完成了才做，结果发现某个危害需要ASIL D等级，但架构根本不支持——那叫一个惨。
3.2 危害识别——第一步，也是最容易漏的一步
危害识别，就是找出「什么情况下系统会出问题」。
这里有个常见的误区：很多人只关注「功能失效」，比如刹车失灵、转向卡死。但实际项目中，危害的来源远不止这些。
我给大家列一个我常用的检查清单：
- 功能失效：该动的时候不动，不该动的时候乱动
- 性能降级：响应变慢、精度下降（比如ACC跟车距离突然变大）
- 时序问题：信号延迟、数据不同步（我在一个项目中遇到过，摄像头和雷达的时间戳差了200ms，导致融合结果完全错误）
- 通信故障：丢包、错包、总线负载过高
- 环境干扰：电磁干扰、温度漂移、振动
我的一个小技巧：做危害识别时，别只盯着「正常工况」。多想想「边界情况」——比如电池快没电了、传感器被泥巴糊住了、GPS信号丢失了。这些场景往往才是真正的杀手。
3.3 风险评估——三个维度，一个都不能少
危害识别完了，接下来要评估每个危害的风险等级。ISO 26262给出了三个评估维度：
| 维度 | 全称 | 含义 | 等级范围 |
|---|---|---|---|
| S | Severity | 伤害的严重程度 | S0~S3 |
| E | Exposure | 暴露于危险场景的概率 | E0~E4 |
| C | Controllability | 驾驶员或其他人控制风险的能力 | C0~C3 |
嗯，这里要注意：这三个维度不是独立评估的。它们组合起来，才能确定最终的ASIL等级。
举个例子吧。我参与过一个电动助力转向项目，其中一个危害是「高速行驶时转向助力突然消失」。
- S（严重度）：高速失控可能导致严重伤亡，S3
- E（暴露率）：高速行驶是常见工况，E3
- C（可控性）：突然失去助力，大多数驾驶员很难控制，C2
查表得到：S3+E3+C2 = ASIL C。嗯，这个等级意味着需要相当严格的安全措施。
避坑指南：我曾经在一个项目中，团队把C等级定得太乐观了。他们觉得「驾驶员总能反应过来」，结果评估出来全是ASIL A或B。后来我让他们做了个实车测试——让普通驾驶员在高速上突然失去转向助力，看看多少人能安全靠边停车。结果呢？超过一半的人直接冲出了车道。从那以后，我们对C等级的评估就谨慎多了。
3.4 ASIL等级确定——从A到D，要求天差地别
ASIL等级分为四个：A、B、C、D。D是最严格的，A是最宽松的。还有一个QM（Quality Management），表示不需要功能安全措施，普通质量管理即可。
ASIL等级决定了什么？说白了，决定了你的安全措施要做到什么程度：
- ASIL A：基本的安全机制，比如故障检测、报警
- ASIL B：需要一定的冗余和诊断覆盖
- ASIL C：需要较高的诊断覆盖率和硬件冗余
- ASIL D：几乎要「双倍冗余+全面诊断」，成本极高
我给大家一个直观的感受：ASIL D的硬件开发成本，大概是ASIL B的3~5倍。所以，千万别盲目定高等级。能定ASIL B的，就别硬上ASIL D。
一个实用的建议：在HARA阶段，我建议把每个危害的S、E、C评估结果都记录下来，包括评估依据。为什么？因为后期审核时，审核员一定会问：「你这个S3是怎么来的？有没有数据支撑？」如果你拿不出依据，整个HARA都可能被推翻。
3.5 一个完整的HARA示例
咱们拿一个自适应巡航系统（ACC）来练练手。
系统定义：ACC系统，能在30~150km/h范围内自动调节车速，保持与前车的安全距离。
危害1：ACC在高速行驶时，突然误识别前方有障碍物，导致急刹车。
- S：高速急刹车可能导致追尾，严重度S2
- E：高速行驶是常见场景，暴露率E3
- C：驾驶员可以踩油门或接管，可控性C1
- 结果：S2+E3+C1 = ASIL B
危害2：ACC在跟车时，突然失去前车距离信息，导致加速追尾。
- S：追尾可能导致伤亡，严重度S3
- E：跟车场景很常见，暴露率E4
- C：驾驶员反应时间有限，可控性C2
- 结果：S3+E4+C2 = ASIL C
你看，同一个ACC系统，不同的危害场景，ASIL等级完全不同。这就是为什么HARA必须一个一个危害去分析，不能笼统地说「这个系统是ASIL C」。
我的经验：做HARA时，最好拉上系统工程师、软件工程师、硬件工程师一起讨论。一个人闭门造车，很容易漏掉关键场景。我记得有一次，硬件工程师提醒我：「这个传感器在低温下会降级。」我们一分析，发现这个降级场景的暴露率比常温场景高得多——因为车在冬天启动时，传感器还没预热。这个场景如果不加进去，HARA就是不完整的。
3.6 本章小结
HARA不是一次性的工作。随着设计的深入，你可能会发现新的危害，或者原来的评估需要调整。所以，我建议把HARA当作一个「活文档」，持续更新。
最后送大家一句话：HARA做得越细，后面的设计越顺。别怕花时间，这个时间省不得。
下一章，咱们聊聊安全目标——HARA的输出，也是安全设计的起点。