4. 危害分析与风险评估（HARA）：HARA的基本流程、ASIL等级确定与SOTIF中的触发事件分析

各位工程师朋友，咱们今天聊点硬核的——HARA。说实话，这玩意儿是功能安全里最让人头疼、也最绕不开的一步。我见过太多项目，前期HARA做得马马虎虎，结果后期改架构改到崩溃。嗯，咱们今天就把这块骨头啃透。

4.1 HARA到底在干什么？

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

• 车子会不会出危险？（危害识别）
• 这危险有多严重？（风险评估）
• 我们得做到多安全？（ASIL定级）

我个人习惯把HARA比作「体检」。你总得先知道身体哪里不舒服，再决定要不要做手术。对吧？

4.2 HARA的基本流程——五步走

我总结了一套五步法，你照着做基本不会漏东西：

1. 功能定义——搞清楚你的系统到底要干嘛。比如ACC自适应巡航，它的功能是「保持设定车速和跟车距离」。
2. 危害识别——功能失效了会怎样？ACC突然加速？突然刹车？还是没反应？
3. 场景分析——在什么情况下这个危害会变成事故？高速上？市区？雨天？
4. 风险评估——用S（严重度）、E（暴露率）、C（可控性）三个参数打分。
5. ASIL定级——根据S、E、C的组合，确定ASIL A/B/C/D或QM。

你想想看，这五步其实跟ISO 26262第3部分的要求完全吻合。我在做第一个量产项目时，就是按这个顺序一步步推的，虽然慢，但心里踏实。

4.3 ASIL等级确定——别被公式吓到

ASIL的确定公式其实很简单：

ASIL = f(S, E, C)

具体怎么查？看这张表：

S（严重度）	E（暴露率）	C（可控性）	ASIL等级
S0	任意	任意	QM
S1	E1	C1	QM
S1	E2	C2	ASIL A
S2	E3	C3	ASIL B
S3	E4	C3	ASIL C
S3	E4	C2	ASIL D

注意，这只是简化版。实际项目中，S、E、C的取值需要团队讨论达成一致。我记得有一次，团队里安全工程师和系统工程师为了一个S2还是S3争了半小时。最后怎么解决的？我们拉上功能安全经理，现场做了个仿真演示——嗯，数据说话最管用。

4.4 SOTIF中的触发事件分析——HARA的「好兄弟」

说到SOTIF（ISO 21448），就不得不提触发事件。HARA管的是「系统故障导致的危害」，而SOTIF管的是「系统没坏，但功能表现不如预期导致的危害」。说白了，一个是硬件/软件坏了，一个是算法/传感器本身就不够聪明。

触发事件分析的核心是找出：

• 功能不足——比如摄像头在逆光下识别不到行人
• 可合理预见的误用——比如驾驶员把水杯放在方向盘上导致转向受阻

我做过一个L2级辅助驾驶项目，HARA做完发现ASIL B就够了。但SOTIF分析一展开，好家伙，触发事件列了30多个。最典型的一个：雨天夜间，车道线模糊，系统误判车道边界——这不是故障，是算法能力不够。怎么办？要么升级传感器，要么限制功能使用场景。

4.5 HARA与SOTIF的协同——实战中的「双轨制」

在实际项目中，我建议这样操作：

1. 先做HARA——确定功能安全目标，定ASIL等级
2. 再做SOTIF分析——识别触发事件，评估可接受性
3. 交叉检查——有些触发事件可能同时涉及功能安全（比如传感器故障导致性能下降），这时候需要联合评审

举个例子：自动紧急制动（AEB）系统。

• HARA发现：制动指令丢失 → 可能导致追尾 → ASIL B
• SOTIF发现：摄像头在强光下无法识别前方车辆 → 触发事件 → 需要增加雷达冗余或限制使用条件

你看，两者是互补的。HARA告诉你「系统坏了要安全」，SOTIF告诉你「系统没坏但不够聪明也要安全」。

4.6 实战中的常见误区

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

• 误区一：HARA只做一次——系统设计变了，危害场景也会变。我建议每个里程碑都回顾一次。
• 误区二：ASIL定得越高越好——ASIL D意味着开发成本翻倍。合理定级才是高手。
• 误区三：忽略SOTIF——现在很多OEM要求HARA和SOTIF一起过审。别等评审时才发现漏了。
• 误区四：触发事件分析太粗——「天气不好」这种描述太笼统。要具体到「暴雨天，能见度低于50米，摄像头识别率下降至60%以下」。