3. 危害分析与风险评估（HARA）：场景识别、危害事件定义、风险参数评估（S/E/C）
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：「车会怎么坏？」「坏的时候人在哪？」「后果有多严重？」。这是整个功能安全开发的起点，也是后续所有安全目标的来源。
我见过不少团队，上来就写安全目标，结果评审时发现场景没覆盖全，ASIL等级定低了。嗯，HARA做不扎实，后面全是补丁。所以这一章，咱们把HARA的每个环节拆开揉碎，讲清楚。
3.1 场景识别：你得知道车在什么情况下会出事
场景识别，不是让你天马行空地想象。它是有套路的。我个人习惯，把场景拆成三个维度：
- 运行场景：车在开、在停、在充电、在泊车？
- 环境条件：白天/黑夜、晴天/雨雪、隧道/高架？
- 人员状态：驾驶员在专注驾驶、分心、还是睡着了？
举个例子。你分析一个「自动紧急制动（AEB）」系统。场景不能只写「车辆行驶中前车急刹」。你得考虑：
- 前车急刹时，路面是湿滑的（环境条件变化）
- 驾驶员正在看手机（人员状态变化）
- 车辆正在下坡（运行场景变化）
这三个维度组合起来，才是完整的场景。我在项目中遇到过，有人只写了「高速行驶中AEB失效」，结果评审时被问到「那低速跟车场景呢？倒车场景呢？」——当场哑火。
3.2 危害事件定义：把「故障」和「场景」绑在一起
场景识别完了，下一步是定义「危害事件」。注意，不是「危害」，是「危害事件」。区别在哪？
危害：系统本身出了什么故障。比如「制动助力完全丧失」。
危害事件：这个故障，在某个具体场景下，导致了什么后果。比如「制动助力完全丧失，在高速行驶中导致车辆无法减速，发生追尾」。
你看，危害事件 = 故障 + 场景 + 后果。三者缺一不可。
我建议，每个危害事件用一句话说清楚。格式可以固定：
[故障] + 发生在 [场景] + 导致 [后果]举个例子：
| 故障 | 场景 | 后果 | 危害事件 |
|---|---|---|---|
| 转向助力失效 | 车辆以60km/h在城市道路转弯 | 驾驶员无法完成转向，车辆偏离车道，撞上护栏 | 转向助力失效，在城市道路转弯时导致车辆偏离车道并碰撞 |
| 电池热失控 | 车辆在室内停车场充电 | 电池起火，引燃周围车辆，造成人员伤亡 | 电池热失控，在室内停车场充电时引发火灾 |
为什么要这么严格？因为后续的S/E/C评估，全部基于这个「危害事件」定义。定义模糊，评估就失真。
3.3 风险参数评估（S/E/C）：给每个危害事件打分
ISO 26262 给了三个参数：
- S（Severity）：严重度。人员受伤的严重程度。
- E（Exposure）：暴露概率。这个场景发生的概率。
- C（Controllability）：可控性。驾驶员或其他人员能控制住局面的能力。
三个参数组合，最终确定ASIL等级（A/B/C/D）或QM。
3.3.1 S（严重度）
S分为S0、S1、S2、S3。标准里写得很清楚：
| 等级 | 描述 | 典型伤害 |
|---|---|---|
| S0 | 无伤害 | 轻微刮擦，无人受伤 |
| S1 | 轻伤 | 擦伤、骨折（可恢复） |
| S2 | 重伤 | 截肢、内出血（危及生命但可存活） |
| S3 | 致命伤 | 当场死亡或无法救治 |
这里有个容易踩的坑：S等级是基于「最坏情况」还是「典型情况」？标准要求是最坏合理情况。比如，同样是制动失效，在空旷场地可能只是S1，但在高速上就是S3。你评估时，要基于你定义的场景。
3.3.2 E（暴露概率）
E分为E0到E4。它评估的是：这个场景，在车辆整个生命周期里，发生的概率有多大？
| 等级 | 描述 | 典型频率 |
|---|---|---|
| E0 | 几乎不可能 | 一生可能都遇不到一次 |
| E1 | 很低 | 每年几次 |
| E2 | 低 | 每月几次 |
| E3 | 中等 | 每周几次 |
| E4 | 高 | 几乎每次驾驶都会遇到 |
你想想看，「高速行驶中前车急刹」这个场景，E值大概是多少？如果你在市区开，可能E3；如果你在郊区，可能E2。这个评估需要基于实际数据，不能拍脑袋。
3.3.3 C（可控性）
C分为C0到C3。它评估的是：当危害事件发生时，驾驶员或其他人能通过正常反应避免伤害吗？
| 等级 | 描述 | 典型情况 |
|---|---|---|
| C0 | 完全可控 | 驾驶员可以轻松应对 |
| C1 | 简单可控 | 大多数驾驶员能控制 |
| C2 | 一般可控 | 部分驾驶员能控制，部分不能 |
| C3 | 难以控制 | 几乎无法控制，伤害不可避免 |
举个例子。转向助力失效，在低速时C1，驾驶员用力打方向还能转。但在高速时，可能就是C3，因为突然失去助力，驾驶员根本来不及反应。
3.4 ASIL等级确定：S、E、C的排列组合
有了S、E、C的值，查表就能得到ASIL等级。标准里给了这个矩阵：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| S1 | E2 | QM | QM | ASIL A |
| S1 | E3 | QM | ASIL A | ASIL B |
| S1 | E4 | ASIL A | ASIL B | ASIL C |
| S2 | E1 | QM | QM | ASIL A |
| S2 | E2 | QM | ASIL A | ASIL B |
| S2 | E3 | ASIL A | ASIL B | ASIL C |
| S2 | E4 | ASIL B | ASIL C | ASIL D |
| S3 | E1 | ASIL A | ASIL B | ASIL C |
| S3 | E2 | ASIL B | ASIL C | ASIL D |
| S3 | E3 | ASIL C | ASIL D | ASIL D |
| S3 | E4 | ASIL D | ASIL D | ASIL D |
举个例子。一个危害事件评估为S2、E3、C2，查表得到ASIL B。就这么简单。
但注意，这个表不是死的。标准允许你根据实际情况做调整，但必须有充分理由。我建议，第一次做HARA时，严格按表来，别自己发明规则。
3.5 HARA的完整流程（SVG流程图）
下面这张图，把HARA的完整流程串起来了。从系统定义开始，到输出安全目标结束。你可以把它贴在工位上，每次做HARA时对照着走一遍。
3.6 实战中的常见问题
最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路。
我曾经有一个项目，只分析了「正常行驶」场景，忽略了「维修模式」和「充电模式」。结果在TÜV评审时，被指出「充电过程中电池管理系统失效」这个危害事件没有覆盖。补了整整一周的HARA。
同一个危害事件，不同工程师评估出来的S/E/C值可能不一样。我建议，HARA一定要团队评审，至少三个人背靠背评估，然后取共识。别一个人拍脑袋。
标准给的S/E/C表格是参考，不是圣经。如果你的场景特殊（比如自动驾驶L4级，没有驾驶员），C值可能永远是C3。这时候需要基于实际情况做调整，并在文档中说明理由。