3. 危害分析与风险评估（HARA）：HAZOP、FMEA、FTA方法，ASIL/SIL等级确定
说实话，HARA 是整个功能安全开发的起点，也是我最怕看到团队敷衍了事的一步。你想想看，如果连风险都没识别清楚，后面的设计、测试、验证全都是在赌运气。我见过太多项目，前期 HARA 随便写写，到了系统集成阶段才发现某个关键失效模式没覆盖到，结果整个安全机制要推倒重来——那滋味，真不好受。
这一章，咱们就把 HARA 的底牌翻个底朝天。我会结合自己踩过的坑，把 HAZOP、FMEA、FTA 这三板斧讲透，再手把手教你定 ASIL/SIL 等级。
3.1 HARA 到底在干什么？
HARA 的全称是 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 系统会出什么危险？（识别危害）
- 这些危险有多严重？（评估风险）
- 需要做到多安全？（确定安全目标）
我个人习惯把 HARA 比作「体检」。你不能等病倒了再查，得提前把隐患找出来。功能安全也一样——在产品定义阶段就要做 HARA，而不是等到代码写完了再补。
核心原则：HARA 的输出是安全目标（Safety Goal），每个安全目标对应一个 ASIL 等级。后续所有安全机制的设计、验证、测试，都要围绕这些安全目标展开。
3.2 HAZOP：系统级的「头脑风暴」
HAZOP（Hazard and Operability Study）起源于化工行业，后来被功能安全领域广泛采用。它的核心思路是：用一组引导词（Guide Words）去「拷问」系统的每个功能。
常用的引导词包括：
| 引导词 | 含义 | 举例（汽车制动系统） |
|---|---|---|
| No / Not | 功能缺失 | 踩刹车但没制动力 |
| More | 过量 | 刹车力过大导致车轮抱死 |
| Less | 不足 | 刹车力不足，制动距离变长 |
| Reverse | 反向 | 踩刹车反而加速 |
| Other Than | 其他功能干扰 | ACC 巡航误触发了制动 |
我在做 HAZOP 时，习惯拉上系统工程师、硬件工程师、软件工程师、测试工程师一起开会。为什么？因为不同角色看问题的角度完全不同。软件工程师觉得「这个故障不可能发生」，硬件工程师可能已经见过三次了。
我的经验：HAZOP 会议最好控制在 2 小时以内，每次只分析 1-2 个功能。时间太长，大家注意力会下降，容易漏掉关键危害。
3.3 FMEA：自下而上的「故障排查」
FMEA（Failure Mode and Effects Analysis）和 HAZOP 是互补的。HAZOP 从功能出发，FMEA 从元器件或模块出发。我习惯先做 HAZOP 确定系统级危害，再用 FMEA 细化到具体部件。
FMEA 的核心要素：
- 失效模式：这个部件会怎么坏？
- 失效原因：为什么会坏？
- 失效影响：坏了之后会怎样？
- 严重度（S）：影响有多严重？
- 发生度（O）：发生的概率？
- 探测度（D）：能不能在出厂前发现？
RPN（风险优先级数）= S × O × D。但我要提醒你：别迷信 RPN 数值。我曾经在一个项目里看到团队把 RPN 算得很漂亮，结果现场故障率还是很高。为什么？因为严重度 S 是 10 的故障，哪怕 O 和 D 都很低，也必须处理，不能靠 RPN 排名来决定优先级。
避坑指南：我曾经见过一个团队，把某个失效模式的 O 值从 3 改成 2，就为了把 RPN 降到阈值以下。这是典型的自欺欺人。FMEA 是分析工具，不是 KPI 考核表。
3.4 FTA：自上而下的「逻辑推理」
FTA（Fault Tree Analysis）和 FMEA 正好相反。FMEA 是从下往上推，FTA 是从上往下拆。你先定义顶层事件（比如「制动失效」），然后一层层拆解，直到找到基本事件。
FTA 的符号很简单：
- 与门（AND）：所有子事件同时发生，顶层事件才发生
- 或门（OR）：任意一个子事件发生，顶层事件就发生
- 基本事件：最底层的故障原因
我个人觉得 FTA 最大的价值在于：它能帮你发现「共因失效」。比如两个冗余传感器都失效了，FMEA 可能只看到各自独立的失效模式，但 FTA 会追问：它们是不是因为同一个原因（比如电源过压）同时坏的？
实战建议：FTA 的深度一般控制在 3-5 层。太浅了找不到根因，太深了分析成本太高。我一般拆到「这个故障可以通过设计或测试覆盖」为止。
3.5 ASIL/SIL 等级确定
ASIL（Automotive Safety Integrity Level）是汽车行业用的，SIL（Safety Integrity Level）是 IEC 61508 通用标准用的。两者本质一样，只是参数略有差异。咱们以 ASIL 为例展开。
ASIL 由三个参数决定：
| 参数 | 全称 | 等级范围 | 含义 |
|---|---|---|---|
| S | Severity | S0 - S3 | 伤害的严重程度 |
| E | Exposure | E0 - E4 | 暴露在危险场景中的概率 |
| C | Controllability | C0 - C3 | 驾驶员或人员能否控制局面 |
ASIL 等级 = f(S, E, C)。具体查 ISO 26262 的表格，我直接给你总结：
- ASIL A：轻微伤害，暴露概率低，可控性好
- ASIL B：中等伤害，需要一定的安全机制
- ASIL C：严重伤害，安全机制要求较高
- ASIL D：致命伤害，最高安全等级
- QM：仅需质量管理，无需功能安全措施
举个例子：电动助力转向系统。如果转向失效，车辆可能失控，S 可以给到 S3（致命伤害）。这种故障在行驶中随时可能发生，E 给 E4。驾驶员在高速上突然失去转向，几乎无法控制，C 给 C3。查表：S3 + E4 + C3 = ASIL D。
我的习惯：定 ASIL 时，我会先按最坏情况给一个初值，然后和团队逐条讨论。如果某个参数有争议，就按「最保守」的原则来。安全等级定高了可以降，定低了后面补不回来。
3.6 一张图看懂 HARA 全流程
下面这张 SVG 图，是我自己梳理的 HARA 执行流程。每次做新项目，我都会把它打印出来贴在白板上。
3.7 实战中的常见误区
做了这么多年功能安全，我总结了几条 HARA 阶段最容易犯的错：
- 误区一：HARA 一次做完就完事。系统设计变了、场景变了，HARA 必须跟着更新。我见过一个项目，HARA 文档是两年前的，系统架构已经改了四版，安全目标还挂着原来的 ASIL 等级——这比不做 HARA 还危险。
- 误区二：ASIL 等级定得越高越好。ASIL D 意味着开发成本翻倍。如果某个危害的 S 是 S2，E 是 E2，C 是 C2，算出来是 ASIL B，你非要提到 ASIL D，那就是过度设计。安全不是越贵越好，是「刚刚好」。
- 误区三：FMEA 和 FTA 只选一个做。两者是互补的。FMEA 帮你覆盖广度，FTA 帮你挖深度。我习惯的做法是：先用 FMEA 扫一遍所有部件，再用 FTA 对高风险项做深度分析。
我曾经踩过的坑：在一个 ADAS 项目中，我们只做了 FMEA，没做 FTA。结果某个失效模式在 FMEA 里被标记为「低风险」，因为两个传感器冗余设计，单个失效不影响功能。但现场测试发现，两个传感器共用同一个电源模块，电源失效时两个传感器同时掉电。FTA 能发现这种共因失效，FMEA 很难。从那以后，我再也不敢只做 FMEA 了。
3.8 小结
HARA 不是走流程，是真正在「保命」。HAZOP 帮你找危害，FMEA 帮你查细节，FTA 帮你挖根因，ASIL 帮你定目标。四者缺一不可。
记住一句话：HARA 做得越扎实，后面的开发越顺畅。别急着写代码，先把风险搞清楚。