3. 危害分析与风险评估（HARA）
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车会不会出危险？危险有多严重？我们该怎么定目标？
我刚开始做功能安全那会儿，总觉得HARA就是走个过场，填几张表完事。直到有一次，一个网关项目因为运行场景定义漏了“高速路上突然断网”这个场景，导致ASIL等级定低了。嗯，从那以后，我再也不敢小看这一步。
3.1 HARA方法论：从顶层到底层
HARA不是拍脑袋，它有一套标准流程。我个人习惯把它拆成四个阶段：
- 功能定义 – 搞清楚网关到底要干什么。
- 运行场景定义 – 车会在什么环境下跑？
- 危害事件识别 – 哪些故障会导致危险？
- ASIL等级确定 – 定级，然后定安全目标。
你想想看，这四个阶段就像盖楼打地基。前面漏了，后面全得返工。
核心原则：HARA必须基于功能行为，而不是基于硬件故障。我们分析的是“功能失效后会发生什么”，而不是“这个电阻会不会烧”。
3.2 运行场景定义：别让车在真空中跑
很多工程师容易犯一个错：只考虑“正常驾驶”。但真实世界哪有那么理想？
运行场景至少要考虑三个维度：
- 环境条件：白天/黑夜、雨雪/晴天、隧道/开阔地。
- 车辆状态：静止、低速、高速、倒车、充电。
- 通信场景：CAN总线正常、CAN总线过载、以太网断开、无线信号丢失。
我记得有个项目，网关在地下车库场景下出现了CAN报文延迟。测试团队一开始没把这个场景写进HARA，结果ASIL等级定低了。后来补测，发现延迟会导致刹车信号晚到200ms——这在高速上就是十几米的制动距离。
我的建议：运行场景清单至少列20个以上。别怕多，后面可以合并。漏一个，可能就要改架构。
3.3 危害事件识别：从故障到事故
危害事件 = 故障 + 运行场景 + 危害后果。
举个例子：
- 故障：网关转发CAN报文时，数据位翻转。
- 场景：车辆在高速上以120km/h巡航。
- 后果：发动机控制器收到错误的扭矩请求，突然加速，导致追尾。
这个链条必须完整。我曾经见过有人只写“网关故障导致车辆失控”——太笼统了，没法定级。
识别危害事件时，我习惯用“如果…那么…”句式来推演：
- 如果网关丢了一条关键CAN报文，那么制动系统会不会无响应？
- 如果网关转发延迟超过100ms，那么转向指令会不会滞后？
- 如果网关被恶意报文攻击，那么车辆会不会进入错误模式？
注意：不要只分析单一故障。组合故障（比如CAN总线断线 + 网关看门狗失效）也要考虑。ISO 26262要求覆盖合理可预见的误用。
3.4 ASIL等级确定：三个参数的博弈
ASIL等级由三个参数决定：
| 参数 | 全称 | 等级范围 | 说明 |
|---|---|---|---|
| S | Severity（严重度） | S0 ~ S3 | 对人员伤害的严重程度 |
| E | Exposure（暴露概率） | E0 ~ E4 | 场景发生的概率 |
| C | Controllability（可控性） | C0 ~ C3 | 驾驶员能否避免事故 |
最终ASIL等级 = f(S, E, C)。查表即可：
| S | E | C | ASIL |
|---|---|---|---|
| S1 | E1 | C1 | QM |
| S2 | E3 | C2 | ASIL B |
| S3 | E4 | C3 | ASIL D |
| S3 | E2 | C1 | ASIL A |
这里有个坑：C（可控性）很容易被低估。我见过一个案例，网关丢了一条车窗控制报文，工程师觉得“车窗关不上而已，没什么危险”，给了C1。但后来发现，如果车窗在高速上突然打开，风噪会干扰驾驶员，导致分心——实际可控性应该至少C2。
避坑指南：我曾经把一个网关的ASIL等级定成QM，因为我觉得“丢一条报文不会死人”。后来安全评审时，专家问了一句：“如果丢的是制动灯信号呢？”我当场就愣住了。从那以后，我定级时都会问自己：最坏情况下，这个故障会导致什么？
3.5 HARA输出：安全目标
HARA的最终产物不是一张表，而是安全目标（Safety Goal）。每个危害事件都要对应一个安全目标。
举个例子：
- 危害事件：网关转发CAN报文延迟导致制动指令滞后。
- ASIL等级：ASIL D。
- 安全目标：网关必须在10ms内转发制动相关CAN报文，否则进入安全状态。
安全目标要满足三个条件：
- 可验证 – 能不能通过测试证明？
- 可分配 – 能不能落实到具体模块？
- 无歧义 – 团队每个人理解一致。
我的习惯：安全目标写完后，我会让测试工程师和系统工程师各读一遍。如果他们理解不一样，说明目标写得不够清楚。
3.6 HARA流程全景图
下面这张图是我自己总结的HARA流程，每次做新项目都会贴到墙上：
3.7 常见误区与避坑
做HARA这么多年，我踩过不少坑。挑几个典型的说说：
- 误区一：ASIL等级越高越好。 不是的。ASIL D意味着开发成本翻倍。合理定级，够用就好。
- 误区二：只分析网关本身。 网关是通信枢纽，它的故障会影响其他ECU。分析时要考虑上下游。
- 误区三：忽略时间因素。 网关的延迟、丢包、重传，这些时间特性直接影响危害严重度。
警告：HARA文档不是写一次就完事的。项目过程中，如果功能变更、场景新增、架构调整，HARA必须重新评审。我见过一个项目，HARA写完就锁进柜子，结果功能改了三次，安全目标还是原来的——最后审核没过，全部重来。
好了，HARA这部分就聊到这儿。记住一句话：HARA不是负担，是保护伞。 做扎实了，后面开发、测试、集成都会顺很多。