3、危害分析与风险评估（HARA）
好，咱们进入功能安全里最核心、也是最考验功力的环节——HARA。说实话，我见过不少项目，前期设计做得风生水起，一到HARA就开始糊弄，最后认证审计时被问得哑口无言。嗯，这章咱们就把HARA的底裤扒干净。
3.1 HARA到底在干什么？
HARA的全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 我的系统会不会出危险？
- 出了危险后果有多严重？
- 我得做到多安全才算合格？
我个人习惯把HARA比作「排雷」。你想想看，一个系统可能有几十上百种失效模式，但真正能要人命的可能就三五个。HARA就是帮你把这些「地雷」找出来，然后决定每个雷旁边要站几个哨兵。
核心目的：识别系统在功能失效时可能导致的危害事件，评估其风险等级，并导出安全目标（Safety Goal）。
我在项目中遇到过最典型的反面教材：某团队做ADAS系统，HARA只做了3个场景，结果路试时发现一个未识别的危害——车辆在隧道出口处突然急刹。为什么？因为HARA时根本没考虑光照突变场景。所以，HARA做得细不细，直接决定你后面要补多少坑。
3.2 危害识别方法——怎么把「鬼」揪出来？
危害识别不是拍脑袋。我常用的方法有这几种：
3.2.1 头脑风暴法（Brainstorming）
拉上系统、软件、硬件、测试、甚至市场的人，关在会议室里。对着功能清单，一个一个问：「如果这个功能失效了，会发生什么？」
注意，这里有个坑：不要只讨论「技术失效」。我曾经见过一个团队，讨论转向系统时只盯着电机卡死，却忽略了「驾驶员误操作」这种使用场景。嗯，HARA要覆盖所有合理可预见的误用。
3.2.2 检查表法（Checklist）
对于成熟系统，检查表效率很高。比如ISO 26262-3:2018的Table B.1就给出了常见的危害类型：
| 危害类型 | 示例 |
|---|---|
| 非预期加速 | ACC系统误判前车距离，突然加速 |
| 非预期制动 | AEB系统对路边广告牌误触发 |
| 转向失控 | EPS系统丢失扭矩指令 |
| 信息显示错误 | 仪表盘显示剩余电量50%，实际为5% |
3.2.3 HAZOP（危险与可操作性分析）
这个方法我特别喜欢，因为它系统化。你对着每个功能，用引导词（如：无、多、少、相反、早、晚）去「拷问」系统。
举个例子，对于「车门解锁」功能：
- 无： 车门无法解锁 → 人员被困
- 多： 行驶中车门意外解锁 → 人员跌落
- 相反： 解锁变成上锁 → 紧急情况无法逃生
- 早： 车辆未停稳就解锁 → 危险
我的小技巧： 做HAZOP时，一定要把「操作模式」也列进去。比如「倒车时」、「高速行驶时」、「充电时」——同一个失效在不同模式下，危害等级天差地别。
3.3 风险评估矩阵——给危害「称重」
危害找到了，接下来要评估它有多「重」。ISO 26262用三个参数来评估：
- S（Severity，严重度）： 伤害有多重？
- E（Exposure，暴露概率）： 这种情况发生的频率？
- C（Controllability，可控性）： 驾驶员或其他人能避免吗？
这三个参数组合起来，就决定了你的ASIL等级（Automotive Safety Integrity Level）。
| 参数 | 等级 | 描述 |
|---|---|---|
| S（严重度） | S0 | 无伤害 |
| S1 | 轻伤（可恢复） | |
| S2 | 重伤（可能危及生命） | |
| S3 | 致命伤 | |
| E（暴露概率） | E0 | 几乎不可能 |
| E1 | 很少发生（<1%的操作时间） | |
| E2 | 偶尔发生（1%-10%） | |
| E3 | 频繁发生（>10%） | |
| C（可控性） | C0 | 完全可控 |
| C1 | 简单可控（一般驾驶员可应对） | |
| C2 | 难以控制（需要特殊技能或运气） | |
| C3 | 不可控 |
然后，查这个矩阵：
| C1 | C2 | C3 | |
|---|---|---|---|
| S1 + E1 | QM | QM | ASIL A |
| S1 + E2 | QM | ASIL A | ASIL B |
| S1 + E3 | ASIL A | ASIL B | ASIL B |
| S2 + E1 | QM | ASIL A | ASIL B |
| S2 + E2 | ASIL A | ASIL B | ASIL C |
| S2 + E3 | ASIL B | ASIL C | ASIL C |
| S3 + E1 | ASIL A | ASIL B | ASIL C |
| S3 + E2 | ASIL B | ASIL C | ASIL D |
| S3 + E3 | ASIL C | ASIL D | ASIL D |
注意： 这个矩阵不是死的。不同OEM可能有自己的微调版本。我曾经在审计时遇到一家公司，把S2+E2+C2从ASIL B改成了ASIL C，理由是「我们做过统计，这种场景下驾驶员反应时间平均超过2秒」。审计员认可了，但要求提供统计数据支撑。所以，矩阵可以调，但要有理有据。
3.4 安全目标定义——把「要求」写清楚
评估完风险，就要导出安全目标（Safety Goal）。安全目标是什么？就是一句话：「系统必须避免某某危害」。
举个例子，对于「非预期加速」这个危害：
- 危害： 车辆在高速行驶时，ACC系统误判导致非预期加速，引发追尾。
- ASIL等级： ASIL C
- 安全目标： 「车辆在高速行驶时，必须避免因ACC系统误判导致的非预期加速，ASIL C。」
写安全目标时，我建议遵循几个原则：
- 可验证： 你写出来的目标，测试团队要能设计用例去验证。别写「系统要足够安全」这种废话。
- 可追溯： 每个安全目标都要能追溯到具体的危害事件。审计时，审计员会拿着你的安全目标列表，一个一个问：「这个目标对应哪个危害？」
- 粒度适中： 别把安全目标写得太细。比如「MCU的SPI通信必须每10ms进行一次CRC校验」——这是安全机制，不是安全目标。安全目标应该停留在「系统级」。
避坑指南： 我曾经见过一个团队，把安全目标写成了「系统必须满足ISO 26262要求」。审计员当场就笑了：「你这是安全目标还是项目计划？」安全目标一定要具体到「什么场景下，避免什么后果」。
最后，安全目标定义完成后，要形成一份《HARA报告》。这份报告是后续所有安全活动的「宪法」。安全架构、安全机制、测试用例，全都要从这里派生。所以，HARA做得扎实，后面就顺风顺水；HARA做得敷衍，后面全是补丁。
嗯，这一章就到这里。下一章咱们聊聊「功能安全概念与安全架构设计」，看看怎么把安全目标落地成具体的系统方案。