第4章 危害分析与风险评估(HARA)：HARA方法、危害识别、风险评估与ASIL等级确定
好，咱们进入功能安全里最核心的一步——HARA。
说实话，我见过不少项目，前期设计做得挺漂亮，一到HARA就开始糊弄。结果呢？后期改架构改到崩溃。所以这一章，我建议你认真看。
4.1 HARA到底是什么？
HARA，全称是Hazard Analysis and Risk Assessment。翻译过来就是危害分析与风险评估。
它的目标很明确：找出系统所有可能的危害，评估这些危害的风险，然后给每个危害定一个安全等级——也就是ASIL等级。
你想想看，一辆车在路上跑，如果某个功能出故障了，会不会导致人受伤？会伤得多重？发生的概率大不大？这些就是HARA要回答的问题。
核心要点：HARA不是一次性的工作。它贯穿整个开发周期。需求变了、架构改了、甚至法规更新了，你都得回头看看HARA需不需要更新。
4.2 HARA的三大步骤
我个人习惯把HARA拆成三步走：
- 危害识别——找出所有可能的危害事件
- 风险评估——评估每个危害的严重度、暴露概率和可控性
- ASIL等级确定——根据评估结果定级
这三步环环相扣。第一步漏了，后面全白干。
4.3 危害识别——别漏掉任何一个角落
危害识别，说白了就是问自己一个问题：这个功能如果出故障，最坏会怎样？
举个例子。你做一个电动助力转向系统。正常情况，方向盘打左，车轮往左转。但如果控制器坏了，输出一个反向的力矩呢？那就是车辆往右转，但驾驶员在往左打方向。这叫什么？这叫危害事件。
我在项目中遇到过一件事。有个同事做电池管理系统，他列了过压、欠压、过温这些危害。我问他：「如果BMS和充电机通信中断了呢？」他愣了一下。你看，这就是典型的遗漏。
我的小技巧：做危害识别时，别只盯着单一故障。组合故障、通信故障、甚至软件跑飞都要考虑进去。我曾经吃过这个亏，后来养成了习惯——每次做完第一版，都拉上系统、硬件、软件的人一起过一遍。
危害识别常用的方法有：
- 头脑风暴——团队一起想，别一个人闷头干
- 检查表法——基于以往项目的经验积累
- FMEA——失效模式与影响分析，这个后面会细讲
- HAZOP——引导词法，比如「无」、「多」、「少」、「反向」等
4.4 风险评估——三个维度定生死
找到危害事件后，就要评估风险了。ISO 26262用了三个参数：
| 参数 | 全称 | 含义 | 等级 |
|---|---|---|---|
| S | Severity | 严重度——伤害有多重 | S0~S3 |
| E | Exposure | 暴露概率——这种情况多常见 | E0~E4 |
| C | Controllability | 可控性——驾驶员能控制住吗 | C0~C3 |
嗯，这里要注意。这三个参数不是随便拍脑袋定的。标准里给了详细的判定准则。比如严重度S3，指的是「危及生命的伤害，存活概率低」。你想想看，高速上刹车失灵，那就是S3。
暴露概率E4呢？指的是「每次驾驶都会遇到的情况」。比如在城市道路行驶，几乎每次都会遇到红灯、行人。而E1可能是「一年都遇不到几次」的情况。
可控性C3，指的是「驾驶员几乎无法控制」。比如转向系统突然锁死，你方向盘根本打不动，那就是C3。
避坑指南：我曾经见过有人把E和C搞混。E是「危害场景出现的概率」，C是「驾驶员能不能补救」。这是两码事。举个例子：爆胎。爆胎本身概率不高（E2左右），但一旦发生，普通驾驶员很难控制（C3）。别搞混了。
4.5 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就是质量管理，不需要按功能安全流程开发。ASIL A最低，ASIL D最高。ASIL D的要求最严格，比如刹车系统、转向系统，通常都是ASIL D。
为什么会这样？因为S3+E3+C3的组合，意味着「严重伤害+常见场景+无法控制」，那必须用最严格的开发流程来保证安全。
4.6 一个完整的例子
咱们拿「电动尾门」来练练手。
危害事件：尾门在关闭过程中，如果防夹功能失效，可能会夹到人。
- S（严重度）：夹到手指，可能骨折，但不致命。我一般给S1或S2。这里给S1吧。
- E（暴露概率）：每次停车都可能用到尾门，但夹到人的场景呢？嗯，如果有人在尾门关闭路径上，这个概率不算高。给E2。
- C（可控性）：如果夹到人，旁边的人可以喊停，或者按遥控器停止。驾驶员有一定控制能力。给C2。
查表：S1+E2+C2 = QM。也就是说，这个危害只需要按普通质量管理来做就行，不需要额外的功能安全措施。
但如果你换一个场景：尾门在高速行驶时意外打开？那S可能变成S3，E变成E1，C变成C3。查表就是ASIL B。你看，同一个功能，不同场景，ASIL等级完全不同。
我的经验：做HARA时，场景描述一定要具体。别写「尾门故障」这种笼统的话。要写「车辆以120km/h行驶在高速公路上，尾门锁扣失效导致尾门突然打开」。场景越具体，评估越准确。
4.7 常见误区与避坑
最后，我总结几个我踩过的坑：
- 别把ASIL定得太高或太低。定高了，开发成本飙升；定低了，安全不达标。我见过有人把所有危害都定成ASIL D，结果项目预算直接翻倍。
- 别忘了考虑「合理可预见的误用」。比如用户把儿童安全座椅装反了，或者用脚踢尾门。这些不是正常使用，但标准要求你考虑。
- HARA文档要可追溯。每个危害都要能追溯到对应的安全目标和安全需求。不然审核的时候你会很痛苦。
好了，这一章就到这里。HARA是功能安全的基石，花再多时间都值得。下一章咱们聊聊安全目标的定义和分解，那又是另一门学问了。