3、危害分析与风险评估(HARA)：HARA方法论、危害识别、风险评估与ASIL等级确定
好，咱们进入HARA环节。
说实话，HARA是整个功能安全开发里，最考验工程师经验的一步。为什么？因为后面的所有安全目标、安全机制，全是从这里长出来的。你HARA做歪了，后面全白干。我在项目里见过不少团队，上来就急着写代码、搭模型，结果HARA草草了事，最后评审被怼得哑口无言。
嗯，咱们今天就把HARA的底裤扒干净。
3.1 HARA到底在干什么？
HARA的全称是Hazard Analysis and Risk Assessment。说白了，就是三件事：
- 找出危害——系统哪些故障会导致危险事件？
- 评估风险——这个危险事件发生的概率和后果有多严重？
- 定ASIL等级——根据风险，给每个危险事件定个安全等级。
我个人习惯把HARA比作「体检」。你想想看，车在路上跑，就像人活着。你得先知道哪些地方容易出毛病，毛病出了会怎样，然后决定要不要动手术、用什么药。HARA就是这个体检报告。
核心原则：HARA只关注功能失效导致的危害，不关心硬件随机失效或软件bug。比如刹车失灵是功能失效，但电阻短路那是硬件的事，后面再说。
3.2 危害识别——先把「坏蛋」揪出来
危害识别是HARA的第一步。怎么做？我一般用HAZOP（Hazard and Operability Study）方法。说白了，就是对着系统的每个功能，问一句：「如果这个功能不干活或者乱干活，会怎样？」
举个例子，ACC自适应巡航。它的功能是「保持设定车速和跟车距离」。那我们就问：
- 如果ACC意外加速呢？——危害：车辆非预期加速，可能追尾。
- 如果ACC无法减速呢？——危害：制动失效，撞上前车。
- 如果ACC错误识别目标呢？——危害：对静止车辆不制动，直接撞。
你看，每个功能失效，对应一个危害事件。这里有个坑——危害事件一定要描述到「车辆行为 + 场景」。别只写「系统故障」，要写「车辆在高速上以120km/h行驶时，ACC突然加速导致追尾」。场景越具体，后面的风险评估越准。
我的小技巧：做危害识别时，拉上系统工程师、软件工程师、测试工程师一起头脑风暴。一个人想不全的。我曾经有一次，测试同事提了个「如果ACC在隧道里把墙壁识别成前车」的场景，我们所有人都没想到。嗯，这就是团队的价值。
3.3 风险评估——三个参数定生死
危害找到了，接下来评估风险。ISO 26262给了三个参数：
| 参数 | 全称 | 含义 | 等级 |
|---|---|---|---|
| S | Severity | 伤害的严重程度 | S0~S3 |
| E | Exposure | 危险场景发生的概率 | E0~E4 |
| C | Controllability | 驾驶员能否控制住局面 | C0~C3 |
咱们一个一个说。
3.3.1 严重度（S）
说白了，就是「撞了会多惨」。S0是无伤害，S1是轻伤，S2是重伤但能活，S3是致命。我一般这么判断：
- S0：系统故障但车辆安全停下，没人受伤。
- S1：轻微碰撞，比如停车场刮蹭。
- S2：中等碰撞，比如城市道路追尾，可能骨折。
- S3：高速碰撞，比如120km/h追尾大货车，基本没救。
注意：严重度评估要基于最坏情况。别想着「也许驾驶员反应快」，要假设最倒霉的场景。我见过有人把高速追尾定成S2，理由是「现在车都有安全带和气囊」。但你想，如果对方是大货车，后防撞梁都没装呢？所以，老老实实定S3。
3.3.2 暴露概率（E）
这个参数评估的是「危险场景出现的频率」。E0几乎不出现，E4几乎天天遇到。举个例子：
- E1：一年可能遇到一两次，比如在结冰路面行驶。
- E3：每周都会遇到，比如在城市道路跟车。
- E4：每次开车都会遇到，比如在高速上巡航。
我个人习惯参考真实路测数据。比如我们做ACC，统计过用户平均每天有30%的时间在高速上，那高速场景的E值至少是E3。
3.3.3 可控性（C）
这个最考验经验。可控性指的是「驾驶员能不能在故障发生后，通过自己的操作避免事故」。C0是完全可以控制，C3是完全失控。
举个例子：
- C1：系统报警，驾驶员有足够时间接管。比如车道偏离预警，你轻轻打一下方向盘就行。
- C2：系统突然失效，驾驶员需要紧急反应。比如ACC突然退出，你得自己踩刹车。
- C3：系统失效后，驾驶员根本来不及反应。比如高速上突然爆胎，或者制动完全失效。
避坑指南：我曾经把一个场景的可控性定成C1，觉得「驾驶员肯定能反应过来」。结果评审专家问我：「如果驾驶员当时在喝水呢？在看手机呢？在跟后排孩子说话呢？」嗯，从那以后，我评估可控性时，默认驾驶员注意力不在路上。这样定出来的等级才安全。
3.4 ASIL等级确定——一张表搞定
三个参数都定好了，接下来查表。ISO 26262给了这么个矩阵：
| 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 B |
| 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 C |
| S3 + E1 | ASIL A | ASIL B | ASIL C |
| S3 + E2 | ASIL B | ASIL C | ASIL D |
| S3 + E3 | ASIL B | ASIL C | ASIL D |
| S3 + E4 | ASIL C | ASIL D | ASIL D |
QM就是Quality Management，不需要按功能安全开发，按正常质量流程走就行。ASIL A到D，等级越来越高，开发要求也越来越严。
举个例子，咱们刚才说的「ACC在高速上意外加速导致追尾」：
- S：高速追尾，大概率致命 → S3
- E：高速场景，用户每周都跑 → E3
- C：突然加速，驾驶员可能来不及反应 → C2或C3
查表：S3+E3+C2 → ASIL C。嗯，这个等级不低，意味着后面要做很多安全机制。
重要提醒：ASIL等级不是越高越好。ASIL D的开发成本是QM的10倍以上。你想想看，一个车窗升降功能定成ASIL D，那不是浪费钱吗？所以，合理评估，别过度设计。
3.5 一个完整的HARA示例
咱们拿「自动紧急制动（AEB）」来走一遍完整流程。
功能描述：AEB在检测到前方障碍物时，自动施加制动，避免或减轻碰撞。
危害识别：
- AEB意外触发——车辆在无障碍物时突然急刹车。
- AEB无法触发——前方有障碍物，但AEB不制动。
- AEB制动不足——制动力太小，还是撞上了。
风险评估（以「意外触发」为例）：
- 场景：车辆在高速上以120km/h行驶，后方有车跟车。AEB突然急刹车。
- S：高速急刹可能导致后车追尾，可能造成重伤 → S2
- E：高速场景常见，但AEB误触发概率低 → E2
- C：后车驾驶员如果保持安全距离，可以避免追尾 → C1
查表：S2+E2+C1 → QM。嗯，这个危害等级不高，按正常质量开发就行。
再评估「无法触发」：
- 场景：车辆以80km/h接近静止前车，AEB不制动。
- S：直接追尾，可能致命 → S3
- E：城市快速路常见 → E3
- C：驾驶员如果分心，根本来不及反应 → C3
查表：S3+E3+C3 → ASIL D。这个就严重了，必须按最高安全等级开发。
我的经验：同一个功能的不同失效模式，ASIL等级可能天差地别。所以HARA一定要逐条分析，别偷懒合并。我见过有人把AEB的所有失效模式都定成ASIL D，结果开发成本爆炸。也见过有人都定成QM，结果评审被直接打回。嗯，平衡很重要。
3.6 HARA文档长什么样？
最后，咱们看看HARA的输出物。一般是一个表格，每行一个危害事件，包含：
- 危害事件描述
- 运行场景
- S/E/C等级
- ASIL等级
- 安全目标（Safety Goal）——后面章节会细讲
举个例子：
| 危害事件 | 场景 | S | E | C | ASIL | 安全目标 |
|---|---|---|---|---|---|---|
| AEB无法触发 | 城市道路，80km/h接近静止前车 | 3 | 3 | 3 | D | AEB必须在检测到碰撞风险时施加制动 |
| AEB意外触发 | 高速，120km/h，后方有跟车 | 2 | 2 | 1 | QM | （无，按质量流程） |
嗯，到这里，HARA的核心内容就讲完了。你想想看，其实没那么玄乎，就是「找危害、估风险、定等级」三步走。但每一步都有细节，都有坑。我建议你做完HARA后，找几个没参与的人来评审一下，往往能发现盲区。
下一章，咱们聊聊怎么从HARA导出安全目标，以及怎么把安全目标分解到系统架构里。到时候见。