4、危害分析与风险评估（HARA）：HARA方法论、危害识别、场景分析、风险分类与ASIL等级确定

好，咱们进入功能安全落地最核心的一步——HARA。

说实话，很多团队做功能安全，最后卡住的地方就是HARA。要么是危害识别不全，要么是ASIL等级定得过高或过低。我个人习惯是把HARA看作一次「系统级体检」——你得先知道哪里可能出问题，再判断问题有多严重。

4.1 HARA方法论：从「拍脑袋」到「结构化」

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

• 什么东西会坏？（危害识别）
• 在什么情况下坏？（场景分析）
• 坏了后果多严重？（风险分类与ASIL定级）

我在项目中遇到过一种情况：团队花了两周做HARA，结果评审时发现一半的危害场景都是重复的。为什么？因为没有用结构化的方法论。我建议采用「自上而下+自下而上」的双向分析法：

• 自上而下：从系统功能出发，推导可能的失效行为
• 自下而上：从具体组件故障出发，反推对系统的影响

4.2 危害识别：别漏掉「隐形杀手」

危害识别是HARA的基础。你想想看，如果连危害都没找全，后面的ASIL定级再准也没用。

常见的危害类型包括：

• 功能失效：该刹车时不刹车
• 功能误触发：不该刹车时突然刹车
• 功能降级：刹车力度不够
• 时序问题：刹车信号来得太晚

嗯，这里要注意：危害 ≠ 故障。危害是系统层面的、可能对人员造成伤害的事件。比如「刹车失灵」是危害，但「刹车踏板传感器断线」是故障。HARA关注的是前者。

4.3 场景分析：把危害放到「真实世界」里看

同一个危害，在不同场景下风险等级完全不同。举个例子：

• 「刹车失灵」发生在高速公路上 vs 停车场里，后果天差地别
• 「转向助力消失」发生在弯道上 vs 直道上，风险等级也不同

我建议用「场景矩阵」来系统化分析：

我个人习惯是每个危害至少覆盖3-5个典型场景。太少会漏掉高风险场景，太多又会让分析变得臃肿。

4.4 风险分类与ASIL等级确定

终于到了大家最关心的部分——ASIL定级。ISO 26262定义了三个参数：

• S（Severity）：严重度，分S0-S3
• E（Exposure）：暴露概率，分E0-E4
• C（Controllability）：可控性，分C0-C3

ASIL等级 = S × E × C 的组合结果。具体查表：

这里有个容易混淆的点：ASIL D ≠ 四个A加起来。ASIL D是最高等级，要求最严格的安全机制。我见过有人把ASIL D理解成「四个ASIL A的冗余」，这是不对的。

4.5 避坑指南：HARA常见问题

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

• 场景不够具体：别写「高速行驶」，要写「车速120km/h、夜间、雨天、弯道」——越具体越好
• 忽略组合危害：两个独立危害同时发生怎么办？比如「刹车失灵+转向卡死」——虽然概率低，但后果可能是灾难性的
• ASIL分解滥用：别为了降低开发成本，把ASIL D随意分解成两个ASIL B。分解必须有合理的架构依据
• 文档与实现脱节：HARA做完了，但后续的安全需求、安全机制设计完全没参考HARA结果——这是最常见的「两张皮」问题

我记得有一次评审，对方问我：「你这个HARA里写的场景，在实车上真的会发生吗？」——这个问题问得好。从那以后，我每次做完HARA都会找系统工程师和测试工程师一起过一遍，确认每个场景的「真实性」。

好了，HARA这部分就讲到这里。下一章咱们聊聊安全目标与安全状态——怎么把HARA的结果转化成具体的安全需求。