4. 危害分析与风险评估(HARA)：HARA方法论、运行场景定义、危害事件识别、ASIL等级确定
好，咱们进入功能安全最核心的一步——HARA。
说实话，我见过不少项目，前期架构设计得漂漂亮亮，一到HARA就开始糊弄。结果呢？后期ASIL等级定错了，安全机制要么过度设计浪费成本，要么不足导致项目返工。所以这一章，咱们得把HARA的每个环节掰开揉碎了讲清楚。
4.1 HARA到底是什么？
HARA，全称Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 车会不会出危险？（危害识别）
- 在什么情况下出危险？（运行场景定义）
- 危险有多严重？（ASIL等级确定）
我个人习惯把HARA比作「排雷」。你想想看，域控制器就像一辆车的「大脑」，它要是出了错，后果可能是灾难性的。HARA就是提前把这些「雷」找出来，然后决定怎么处理。
核心原则：HARA不是一次性的工作。随着项目推进，架构变了、功能变了，HARA也要跟着更新。我见过最惨的项目，HARA做完就锁进柜子里，最后审核时被开了十几个不符合项。
4.2 运行场景定义——别小看这一步
很多人觉得运行场景就是「车在跑」。错了。场景定义得越细，后面的分析越准。
我一般把场景拆成三个维度：
- 车辆状态：车速、转向角、制动状态、挡位
- 环境条件：白天/黑夜、雨/雪/雾、道路类型（高速/城市/乡村）
- 人员因素：驾驶员注意力、是否疲劳、是否分心
我的经验：有一次做ACC（自适应巡航）的HARA，我们只考虑了「高速跟车」场景。结果审核时被问到：「如果前车突然变道，你的系统怎么反应？」我们当场愣住了。从那以后，我要求团队必须列出至少20个典型场景。
举个例子，对于「自动紧急制动（AEB）」功能，运行场景至少包括：
| 场景编号 | 车辆状态 | 环境条件 | 人员因素 |
|---|---|---|---|
| S-01 | 车速60km/h，直行 | 白天，干燥路面 | 驾驶员注意力集中 |
| S-02 | 车速80km/h，弯道 | 夜间，湿滑路面 | 驾驶员分心（看手机） |
| S-03 | 车速30km/h，拥堵 | 雨天，能见度低 | 驾驶员疲劳 |
| S-04 | 车速0km/h，等红灯 | 白天，交叉路口 | 驾驶员正常 |
4.3 危害事件识别——从功能失效到人身伤害
这一步的核心逻辑是：功能失效 → 车辆行为异常 → 危害事件 → 人身伤害。
举个例子，对于「电子助力转向（EPS）」功能：
- 功能失效：转向助力突然消失
- 车辆行为：方向盘变得很重，驾驶员无法及时转向
- 危害事件：车辆偏离车道，与相邻车道车辆碰撞
- 人身伤害：乘员受伤，甚至死亡
注意：危害事件必须描述「谁受伤了？怎么受伤的？」。不能说「车辆失控」，要说「车辆偏离车道后与对向车辆发生正面碰撞，导致乘员重伤」。
我习惯用「危害事件表」来记录：
| ID | 功能 | 失效模式 | 危害事件 | 潜在后果 |
|---|---|---|---|---|
| H-01 | AEB | 未触发制动 | 车辆未减速，追尾前车 | 乘员颈部受伤 |
| H-02 | AEB | 误触发制动 | 高速急刹，后车追尾 | 乘员挥鞭伤 |
| H-03 | EPS | 转向卡滞 | 无法避让障碍物 | 碰撞导致骨折 |
4.4 ASIL等级确定——S×E×C的魔法
ASIL等级由三个参数决定：
- S（Severity）：伤害严重度。S0（无伤害）→ S1（轻伤）→ S2（重伤）→ S3（致命）
- E（Exposure）：暴露概率。E0（几乎不）→ E1（低）→ E2（中）→ E3（高）→ E4（极高）
- C（Controllability）：可控性。C0（完全可控）→ C1（简单可控）→ C2（一般可控）→ C3（难以控制）
ASIL等级 = f(S, E, C)。具体查表：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | ASIL A |
| S1 | E2 | QM | ASIL A | ASIL B |
| S2 | E2 | ASIL A | ASIL B | ASIL C |
| S3 | E3 | ASIL B | ASIL C | ASIL D |
避坑指南：我曾经在一个项目中，把AEB的S定成了S3（致命），E定成了E2（中等暴露），C定成了C2（一般可控）。结果查表是ASIL C。但后来发现，这个场景只在「高速+前车静止」时才成立。实际上，前车静止的概率很低，E应该降到E1。最终ASIL等级从C降到了B。你想想看，这省了多少开发成本！
4.5 实战中的常见误区
做了这么多年HARA，我总结出几个最容易踩的坑：
- 场景定义太粗：只写「车辆行驶中」，不写车速、路况、环境。结果ASIL等级要么过高要么过低。
- 忽略组合失效：只考虑单一失效，不考虑多个失效同时发生。比如「制动失效+转向卡滞」同时发生怎么办？
- 可控性评估太乐观：总觉得「驾驶员能反应过来」。实际上，在高速上突然失去转向助力，99%的驾驶员都控制不住。
- HARA做完不更新：项目中期架构改了，HARA还是老版本。审核时直接被判不合格。
我的建议：每次架构评审后，花半天时间过一遍HARA。哪怕只改了一个传感器，也要重新评估相关危害事件的ASIL等级。别嫌麻烦，这比后期改安全机制省事多了。
好了，HARA的核心内容就这些。记住一句话：HARA做得好，安全开发就成功了一半。下一节咱们聊聊怎么把HARA的结果转化成具体的安全需求。