4、危害分析与风险评估（HARA）：HARA的目的、HARA的步骤、风险参数（严重度、暴露率、可控性）
4.1 我们为什么要做HARA？
说实话，HARA（Hazard Analysis and Risk Assessment）是整个功能安全流程的起点。没有它，后面的所有工作都是空中楼阁。
我见过不少团队，一上来就急着写代码、做测试。结果呢？做到一半发现某个故障场景根本没考虑到，只能推倒重来。嗯，这就是典型的「先开枪后瞄准」。
HARA的核心目的就三个：
- 找出所有可能的危害——系统在什么情况下会出问题？
- 评估风险等级——这个危害到底有多严重？
- 确定安全目标——我们需要把风险降到什么程度？
说白了，HARA就是给整个项目画一张「风险地图」。有了这张地图，你才知道哪里是雷区，该怎么绕过去。
重要提醒：HARA不是一次性的工作。随着项目推进，你会发现新的风险点。我建议在每个里程碑节点都重新审视一下HARA结果。
4.2 HARA的五个步骤
HARA的流程，我习惯把它拆成五步走。每一步都有它的意义，少一步都不行。
步骤一：功能定义
先搞清楚你的系统是干什么的。比如一个刹车系统，它的功能是「根据踏板位置产生制动力」。听起来简单，但你要考虑所有工作模式：正常模式、失效模式、维护模式……
我记得有一次，一个团队做转向系统的HARA，漏掉了「低速泊车模式」。结果分析出来的风险等级完全不对。你想想看，高速和低速下的危害能一样吗？
步骤二：识别危害事件
这一步要回答一个问题：系统在什么情况下会失效？
常用的方法是HAZOP（Hazard and Operability Study）。用引导词去「拷问」每个功能：
- 没有——功能完全不执行会怎样？
- 过多——输出超出预期范围呢？
- 过少——输出不足呢？
- 相反——方向搞反了呢？
- 错误时机——该动的时候不动，不该动的时候乱动？
举个例子，对于「自动紧急制动」功能：
- 「没有」→ 该刹车时不刹车 → 追尾
- 「过多」→ 刹车力度过大 → 后车追尾
- 「错误时机」→ 无故急刹车 → 引发事故
步骤三：分析运行场景
同一个危害，在不同场景下风险完全不同。比如：
| 危害事件 | 场景A：高速公路上 | 场景B：停车场里 |
|---|---|---|
| 转向失效 | 严重度S3，暴露率E4 | 严重度S1，暴露率E3 |
| 刹车失灵 | 严重度S3，暴露率E3 | 严重度S2，暴露率E2 |
看到了吧？同一个故障，场景一变，风险等级天差地别。
步骤四：评估风险参数
这一步就是给每个危害事件打三个分：严重度（S）、暴露率（E）、可控性（C）。
我习惯先打S，再打E，最后打C。为什么？因为严重度最直观，先把这个定下来，后面两个参数就好办了。
步骤五：确定ASIL等级
根据S、E、C三个参数，查ISO 26262的表格，就能得到ASIL等级（A、B、C、D）或者QM（质量管理）。
我的小技巧：ASIL等级确定后，别急着往下走。先问问自己：「这个等级合理吗？」如果感觉不对劲，回头检查一下参数打分。我曾经把一个ASIL D的项目硬生生降到了ASIL B，就是因为发现暴露率打高了。
4.3 风险参数详解
严重度（Severity, S）
严重度衡量的是「如果危害发生了，对人员造成的伤害程度」。ISO 26262把它分成三个等级：
| 等级 | 描述 | 举例 |
|---|---|---|
| S0 | 无伤害 | 信息娱乐系统卡顿 |
| S1 | 轻伤（可恢复） | 安全带预紧器误触发 |
| S2 | 重伤（可能危及生命） | 安全气囊未展开 |
| S3 | 致命伤害 | 刹车完全失效 |
这里有个坑：很多人会把「系统损坏」和「人员伤害」搞混。记住，HARA只关心对人的伤害。系统坏了可以修，人伤了就晚了。
暴露率（Exposure, E）
暴露率衡量的是「人员在危害场景中出现的频率」。说白了，就是「这个倒霉事发生的概率有多大」。
| 等级 | 描述 | 典型场景 |
|---|---|---|
| E1 | 极低（每年几次） | 在结冰路面上行驶 |
| E2 | 低（每月几次） | 夜间在乡间小路行驶 |
| E3 | 中（每周几次） | 在城市拥堵路段行驶 |
| E4 | 高（几乎每次驾驶） | 在干燥柏油路上行驶 |
我曾经犯过一个错误：把「高速公路上爆胎」的暴露率打成了E2。后来一想不对，爆胎虽然不常见，但「在高速上行驶」这个场景本身是E4啊！暴露率评估的是场景，不是故障本身。
注意：暴露率评估的是「场景出现的频率」，不是「故障发生的概率」。这两个概念千万别搞混了。
可控性（Controllability, C）
可控性衡量的是「驾驶员或其他人员能否避免伤害」。这是三个参数里最主观的一个，也是最容易引起争议的。
| 等级 | 描述 | 举例 |
|---|---|---|
| C1 | 容易控制 | 仪表盘背光熄灭（不影响驾驶） |
| C2 | 一般可控 | 转向助力突然消失（多数人能应对） |
| C3 | 难以控制 | 刹车踏板踩下去没反应（很难应对） |
评估可控性时，我通常会问自己三个问题：
- 驾驶员有没有足够的时间反应？
- 驾驶员有没有足够的信息判断问题？
- 驾驶员有没有能力采取正确的行动？
如果三个答案都是「是」，那可控性就是C1。如果有一个「否」，就要往C2或C3靠了。
4.4 从参数到ASIL等级
有了S、E、C三个参数，查表就能得到ASIL等级：
| 严重度(S) | 暴露率(E) | 可控性(C) | ASIL等级 |
|---|---|---|---|
| S1 | E1 | C1 | QM |
| S2 | E2 | C2 | ASIL A |
| S3 | E3 | C2 | ASIL B |
| S3 | E4 | C2 | ASIL C |
| S3 | E4 | C3 | ASIL D |
注意，这只是简化版。实际查表时，ISO 26262第3部分有完整的矩阵。我建议你把那张表打印出来贴在工位上，随时参考。
4.5 实战中的避坑指南
做了这么多年HARA，我总结了几条血泪教训：
- 别一个人闷头做——HARA需要团队协作。我建议至少拉上系统工程师、硬件工程师、软件工程师和测试工程师一起讨论。
- 文档要写清楚——每个参数打分都要有理由。我曾经因为文档写得太简略，被审核老师追着问了一个下午。
- 别怕修改——HARA不是一锤子买卖。随着设计深入，你可能会发现新的危害，或者原来的参数打错了。改就是了。
- 关注「组合故障」——单个故障可能风险不高，但两个故障同时发生呢？比如「传感器失效」+「驾驶员分心」，这个组合风险就大了。
我的习惯：每次做完HARA，我都会把结果拿给一个没参与项目的人看。让他挑毛病。往往能发现一些「灯下黑」的问题。
好了，HARA这部分就讲到这里。下一章我们聊聊「安全目标」——有了HARA的结果，怎么把它转化成具体的技术要求。这是从「分析」到「实现」的关键一步，别错过。