第3章 HARA分析：危害分析与风险评估方法
HARA，全称是 Hazard Analysis and Risk Assessment。说白了，就是找出系统可能出什么危险，然后评估这个危险有多严重。我见过不少团队，一上来就急着写代码、搭架构，结果做到一半发现某个危害根本没法处理，只能推倒重来。嗯，HARA 就是用来避免这种悲剧的。
3.1 什么是HARA？
HARA 是 ISO 26262 的起点。没有它，后面的所有工作都是空中楼阁。它的核心目标就三个：
- 识别危害：系统在什么情况下会出问题？
- 评估风险：这个危害有多大概率发生？后果有多严重？
- 确定ASIL：根据风险等级，决定需要多严格的安全措施。
我个人习惯把 HARA 比作「体检」。你不体检，就不知道身体哪里有问题。等出了问题再治，成本就高了。HARA 就是给系统做一次全面体检。
核心原则：HARA 必须在项目早期完成，最好在概念阶段就开始。越往后拖，改造成本越高。
3.2 运行场景定义
做 HARA 之前，你得先搞清楚系统会在什么场景下运行。你想想看，一辆车在高速公路上和在小巷子里，危险程度能一样吗？
运行场景包括：
- 环境条件：白天/黑夜、晴天/雨天/雪天、城市/乡村/高速
- 车辆状态：静止、低速、中速、高速、转弯、刹车
- 驾驶员行为：正常驾驶、分心、疲劳、误操作
- 其他交通参与者：行人、自行车、其他车辆、动物
我记得有一次做 EPS（电动助力转向）的 HARA，我们漏掉了「冰雪路面」这个场景。结果后来测试发现，在冰雪路面上，转向助力突然失效会导致车辆失控。嗯，从那以后，我每次都会把环境条件列得特别细。
小技巧：运行场景不要只列常见的，极端情况往往才是真正的风险点。比如「暴雨+夜间+高速+弯道」这种组合场景，一定要覆盖到。
3.3 严重度（S）评估
严重度，就是危害发生后，对人员造成的伤害程度。ISO 26262 把严重度分为 4 个等级：
| S等级 | 描述 | 示例 |
|---|---|---|
| S0 | 无伤害 | 轻微不适，无需医疗 |
| S1 | 轻伤 | 擦伤、扭伤，可自行恢复 |
| S2 | 重伤 | 骨折、内出血，需要住院 |
| S3 | 致命伤 | 死亡或永久性残疾 |
评估严重度时，我建议你考虑最坏情况。比如刹车失灵，最坏情况就是车毁人亡，那 S 就是 3。不要想着「也许驾驶员反应快能避开」，那是可控性（C）的事，不是严重度的事。
注意：严重度只考虑伤害程度，不考虑发生概率。这是新手最容易搞混的地方。S 评估的是「如果发生了，后果有多严重」，而不是「发生的可能性有多大」。
3.4 暴露率（E）评估
暴露率，就是危害场景发生的概率。ISO 26262 把暴露率分为 4 个等级：
| E等级 | 描述 | 示例 |
|---|---|---|
| E0 | 几乎不可能 | 车辆被陨石击中 |
| E1 | 非常低 | 每年发生一次 |
| E2 | 低 | 每月发生一次 |
| E3 | 中等 | 每周发生一次 |
| E4 | 高 | 每天发生一次 |
暴露率评估，说白了就是看这个场景「常见不常见」。比如「雨天行驶」这个场景，在南方可能 E4，在沙漠地区可能 E1。所以，暴露率跟车辆的目标市场有很大关系。
我曾经做过一个项目，客户要求 E 等级按全球平均数据来。结果产品在印度市场出了问题——印度雨季的暴雨频率远超全球平均。嗯，从那以后，我每次都会问清楚：这车卖到哪？
建议：暴露率最好用实际数据支撑，比如路况统计、气候数据、用户行为调研。不要拍脑袋。
3.5 可控性（C）评估
可控性，就是驾驶员或其他人员能否控制住局面，避免伤害。ISO 26262 把可控性分为 3 个等级：
| C等级 | 描述 | 示例 |
|---|---|---|
| C0 | 完全可控 | 驾驶员可以轻松应对 |
| C1 | 简单可控 | 大多数驾驶员可以应对 |
| C2 | 一般可控 | 部分驾驶员可以应对 |
| C3 | 难以控制 | 几乎无法应对 |
可控性评估，我个人的经验是：不要假设驾驶员是赛车手。你要考虑的是「普通驾驶员」，甚至「新手驾驶员」。比如刹车失灵，就算老司机也很难控制，那 C 就是 3。
避坑指南：我曾经见过有人把 C 等级评估得很低，理由是「驾驶员可以踩刹车」。但问题是，如果危害本身就是刹车失灵呢？所以，评估可控性时，一定要考虑危害发生的具体场景，不要想当然。
3.6 ASIL等级确定
有了 S、E、C 三个参数，就可以查表确定 ASIL 等级了。ISO 26262 给出了一个 4x5x4 的矩阵，我把它简化成下面这个表格：
| S | E | C | ASIL |
|---|---|---|---|
| S1 | E1 | C1 | QM |
| S1 | E2 | C2 | ASIL A |
| S2 | E2 | C2 | ASIL B |
| S2 | E3 | C2 | ASIL C |
| S3 | E3 | C3 | ASIL D |
你想想看，如果 S=3（致命）、E=4（每天发生）、C=3（难以控制），那 ASIL 就是 D，最高等级。反过来，如果 S=1（轻伤）、E=1（几乎不可能）、C=1（完全可控），那就是 QM，不需要额外安全措施。
关键点：ASIL 等级越高，开发流程越严格，成本也越高。所以，不要盲目追求高 ASIL，合理评估才是正道。
3.7 HARA分析流程
下面这张图是我自己总结的 HARA 分析流程，你可以参考一下：
这个流程看起来简单，但实际操作中，每个环节都需要反复讨论和确认。我建议你至少组织 3 次评审：第一次是场景定义评审，第二次是 S/E/C 评估评审，第三次是 ASIL 确定评审。
3.8 实战案例：电动助力转向（EPS）
拿 EPS 举个例子。假设我们识别出一个危害：转向助力突然失效。
- 运行场景：高速行驶（120km/h），夜间，雨天
- S 评估：转向失效可能导致车辆失控，造成严重事故 → S3
- E 评估：高速+夜间+雨天，虽然不是每天发生，但也不算罕见 → E3
- C 评估：突然失去助力，普通驾驶员很难控制 → C3
- ASIL：S3 + E3 + C3 = ASIL D
你看，一个看似简单的转向助力失效，最终 ASIL 等级是 D。这意味着你需要非常严格的安全措施，比如冗余设计、故障诊断、降级模式等等。
经验之谈：ASIL D 的项目，开发成本通常是 QM 项目的 3-5 倍。所以，HARA 做得越准确，你省的钱就越多。不要为了省事而低估风险，也不要为了安全而过度设计。
3.9 常见误区
做 HARA 时，我见过不少翻车案例。这里列几个常见的：
- 场景定义太粗：只写「行驶中」，不写具体环境。结果评估出来的 S/E/C 没有参考价值。
- S/E/C 混淆：把暴露率当成严重度，或者把可控性当成暴露率。记住，它们是三个独立的维度。
- 忽略组合场景：只考虑单一故障，不考虑多个故障同时发生。比如「刹车失灵+转向卡死」这种组合。
- 过度依赖经验：没有数据支撑，全凭感觉。我建议你至少找 3 个不同背景的人一起评估，互相挑战。
避坑指南：我曾经见过一个团队，把 EPS 的 ASIL 定成了 B，理由是「转向失效不会直接导致死亡」。但他们忽略了——转向失效可能导致车辆撞上行人。所以，评估严重度时，一定要考虑对所有人的伤害，不只是驾驶员。
3.10 小结
HARA 是功能安全的基石。它不复杂，但需要细心和严谨。记住三个关键词：场景、参数、等级。把场景定义清楚，把 S/E/C 评估准确，ASIL 自然就出来了。
嗯，这一章就到这里。内容不多，但都是干货。你可以在实际项目中多练练，慢慢就有感觉了。