4. 危害分析与风险评估（HARA）：目的、方法与风险等级评定

好，咱们今天聊聊HARA。说实话，这是整个预期功能安全里最“烧脑”的一步，但也是最有价值的一步。我个人的经验是，很多团队在HARA上花的时间不够，后面测试阶段才发现一堆坑，返工成本极高。

4.1 HARA到底想干嘛？

HARA的全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：

• 系统会不会出问题？（识别危害）
• 出问题会多严重？（评估风险）
• 我们能不能接受？（确定风险等级）

嗯，这里要注意，HARA不是做一次就完事的。随着系统设计深入，你会发现新的危害场景。我建议至少做三轮：概念阶段一轮，系统设计阶段一轮，集成测试前再一轮。

4.2 两种主流方法：HAZOP vs STPA

做HARA有两种主流方法，我两种都用过，各有千秋。你想想看，选哪个取决于你的系统复杂度和团队习惯。

4.2.1 HAZOP（危险与可操作性分析）

HAZOP是化工行业传过来的老方法，但用在汽车上也很成熟。它的核心思路是：用“引导词”去“拷问”每个系统功能。

引导词有哪些？比如：

• 无（功能不执行）
• 多（功能过度执行）
• 少（功能执行不足）
• 反向（功能反向执行）
• 早/晚（功能时序错误）

举个例子，对于“自动紧急制动（AEB）”功能：

• 引导词“无”：AEB该刹车时不刹车 → 碰撞风险
• 引导词“多”：AEB误触发 → 后车追尾风险
• 引导词“少”：AEB制动力不足 → 碰撞风险

我的经验：HAZOP适合功能边界清晰的系统。我曾经在一个ADAS项目中用HAZOP，半天就梳理出30多个危害场景。但它的缺点是容易漏掉“组合故障”场景。

4.2.2 STPA（系统理论过程分析）

STPA是MIT Nancy Leveson教授提出的新方法。它不盯着“功能失效”，而是盯着“控制回路”。说白了，就是看控制器有没有给执行器发错指令，或者传感器有没有给控制器传错信息。

STPA的步骤：

1. 画出系统的控制结构图（谁控制谁，谁反馈谁）
2. 识别不安全的控制行为（UCA）
3. 分析导致UCA的原因
4. 制定安全约束

我个人的习惯：对于复杂的自动驾驶系统（比如L3以上），我更倾向于用STPA。因为它能更好地处理“人-车-环境”的交互问题。但STPA的学习曲线比较陡，团队需要培训。

4.3 风险等级评定

找到危害事件后，怎么定等级？ISO 21448里用的是ASIL等级（和ISO 26262一样）。评定依据三个参数：

参数	含义	等级
S（Severity）	伤害的严重程度	S0（无伤害）~ S3（致命）
E（Exposure）	场景发生的概率	E0（几乎不）~ E4（非常高）
C（Controllability）	驾驶员能否控制	C0（完全可控）~ C3（不可控）

然后查表得出ASIL等级：

S	E	C	ASIL
S1	E1	C1	QM
S2	E2	C2	ASIL B
S3	E3	C2	ASIL C
S3	E4	C3	ASIL D

4.4 知识体系框架图

下面这张图是我自己整理的HARA核心逻辑，你一看就明白：

4.5 实战中的几个坑

最后，分享几个我踩过的坑：

• 别把HARA做成“一次性”工作。系统设计变了，HARA就得跟着更新。我见过一个项目，HARA文档是半年前的，完全对不上现在的设计。
• 别忽视“正常场景下的异常行为”。比如，AEB在正常行驶时误触发，这比“该触发时不触发”更危险。因为驾驶员没有心理准备。
• 风险评定要多人评审。一个人定的S/E/C等级往往有偏差。我建议至少三个人背靠背评定，然后取共识。