3. 危害分析与风险评估（HARA）：危害识别、风险评估方法、ASIL等级确定
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车子会出什么危险？危险有多严重？我们该用多高的安全等级去防？
我刚开始做功能安全那会儿，总觉得HARA就是走个过场，填几张表就完事了。直到有一次，一个转向系统的项目，我们漏掉了一个低速场景下的危害，结果在实车测试时差点出了事故。嗯，从那以后，我再也不敢轻视HARA了。
3.1 危害识别：把“可能出问题的地方”全挖出来
危害识别，就是头脑风暴。把车辆所有可能的功能异常，都列出来。
我个人习惯，会从三个维度去扫描：
- 功能失效： 比如刹车踩下去没反应、油门自己加速、转向突然卡死。
- 非功能失效： 比如传感器信号延迟、通信总线丢包、软件跑飞进入死循环。
- 外部干扰： 比如电磁干扰导致信号跳变、极端温度下芯片性能下降。
你想想看，一个高级驾驶辅助系统（ADAS）的摄像头，如果因为镜头起雾导致目标识别丢失，这算不算危害？当然算。我见过一个项目，就是没把“传感器脏污”这个场景写进HARA，结果后续的测试用例全都没覆盖到。
3.2 风险评估三要素：S、E、C
危害找到了，接下来要评估它有多“要命”。ISO 26262给了三个评估维度：
| 参数 | 全称 | 含义 | 等级范围 |
|---|---|---|---|
| S | Severity | 对驾驶员或行人造成的伤害严重程度 | S0 ~ S3 |
| E | Exposure | 危害场景发生的概率（暴露在危险中的频次） | E0 ~ E4 |
| C | Controllability | 驾驶员或其他人员能否通过反应避免伤害 | C0 ~ C3 |
举个例子，刹车突然失效：
- S（严重度）： 高速下可能造成多人死亡，S3。
- E（暴露率）： 每次开车都可能遇到刹车场景，E4。
- C（可控性）： 普通人基本无法控制，C3。
这三个值一出来，ASIL等级基本就定了。
3.3 ASIL等级确定：一张表搞定
有了S、E、C，查下表就能得到ASIL等级：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| E2 | QM | QM | ASIL A | |
| E3 | QM | ASIL A | ASIL B | |
| S2 | E1 | QM | QM | ASIL A |
| E2 | QM | ASIL A | ASIL B | |
| E3 | ASIL A | ASIL B | ASIL C | |
| S3 | E1 | QM | ASIL A | ASIL B |
| E2 | ASIL A | ASIL B | ASIL C | |
| E3 | ASIL B | ASIL C | ASIL D |
QM（Quality Management）表示按普通质量管理即可，不需要额外功能安全措施。ASIL A到D，等级越来越高，开发成本也指数级上升。
我曾经在一个项目中，把某个功能评成了ASIL D，结果整个团队加班半年，就为了满足那严苛的覆盖率和独立性要求。后来复盘发现，其实那个场景的E值评高了，实际应该是ASIL B。所以，评级一定要谨慎，评高了浪费钱，评低了要人命。
3.4 HARA核心流程：一张图看懂
下面这张图，是我自己总结的HARA执行流程，每次做新项目我都会贴在白板上：
3.5 实战案例：电动助力转向（EPS）的HARA
拿电动助力转向系统举个例子。我们识别出一个危害：非预期的转向助力输出（比如车子自己打方向）。
评估过程如下：
- S（严重度）： 高速下突然转向，车辆失控，可能造成严重伤亡 → S3
- E（暴露率）： 车辆在高速上行驶的场景很常见 → E4
- C（可控性）： 普通驾驶员很难在瞬间稳住方向盘 → C3
查表：S3 + E4 + C3 = ASIL D。
这意味着，这个功能的所有开发活动，从需求、设计、编码到测试，都必须满足ASIL D的要求。比如代码覆盖率要达到100%的语句覆盖和分支覆盖，还要做MC/DC覆盖。
3.6 常见误区与避坑
- 误区一： 把“故障率”当成“暴露率”。E值评估的是场景，不是故障本身。
- 误区二： 低估C值。别假设驾驶员都是赛车手，普通人遇到突发情况，反应时间至少1秒以上。
- 误区三： 一个危害只对应一个安全目标。实际上，一个危害可能需要多个安全目标来覆盖不同的安全状态。
好了，HARA的核心内容就这些。记住，HARA不是一次性的工作。当系统设计变更、新增功能或发现新的运行场景时，HARA需要重新审视和更新。它是一份活文档。