3、HARA分析：危害分析与风险评估、运行场景定义、安全目标导出
好，咱们进入系统级开发的第一个硬核环节——HARA。全称是Hazard Analysis and Risk Assessment，危害分析与风险评估。
说实话，我见过不少工程师一上来就急着写安全目标，结果写到一半发现场景没定义清楚，又回头改。嗯，这其实挺浪费时间的。HARA的核心逻辑其实很简单：先搞清楚车在什么情况下会出问题，再评估这个问题有多严重，最后定一个安全目标来兜底。
3.1 运行场景定义——你得知道车在干嘛
很多人忽略这一步，觉得「不就是开车嘛」。但你想想看，同样是「刹车失灵」，在高速上和在地库里，后果完全不一样。
我个人习惯把运行场景拆成三个维度：
- 运行模式：车辆处于什么状态？行驶中、停车、充电、还是自动驾驶？
- 环境条件：白天还是黑夜？雨天还是晴天？隧道里还是开阔路面？
- 系统状态：传感器是否正常？通信有没有延迟？电源电压稳不稳？
举个例子，我在做某个L2级辅助驾驶项目时，团队一开始只定义了「高速行驶」场景。结果测试时发现，车辆在进出隧道时，摄像头因为光线突变导致车道线丢失，系统直接退出——这其实是一个典型的运行场景遗漏。
场景定义小技巧：
- 每个场景至少覆盖一种「异常组合」
- 不要只写「正常驾驶」，要写「雨夜、无路灯、路面湿滑」
- 场景数量不是越多越好，关键是覆盖度
3.2 危害识别——找出哪里会出事
场景定义好了，接下来就是找危害。危害不是故障，而是「系统行为导致的人身伤害」。比如：
- unintended acceleration（非预期加速）
- loss of steering（转向丧失）
- brake not applied when requested（请求制动但未响应）
这里有个坑，我踩过。有一次我们识别出一个危害叫「车速过快」，但评审时被安全经理怼了——「车速过快」不是危害，是后果。真正的危害应该是「加速功能在非预期条件下被激活」。你想想看，危害一定要落到系统功能的异常行为上，而不是描述事故结果。
注意：危害识别时，不要和故障模式混淆。危害是「系统对外界的危险行为」，故障是「内部失效」。比如「传感器输出错误信号」是故障，而「车辆在行人横穿时未制动」才是危害。
3.3 风险评估——三个维度定等级
ISO 26262 给了我们三个评估维度：
| 参数 | 含义 | 等级范围 |
|---|---|---|
| S（Severity） | 伤害的严重程度 | S0 ~ S3 |
| E（Exposure） | 场景发生的概率 | E0 ~ E4 |
| C（Controllability） | 驾驶员能否控制 | C0 ~ C3 |
最终的安全等级 ASIL 由 S、E、C 组合决定。比如 S3+E4+C3 就是 ASIL D，最高等级。
我记得有一次评审会上，大家对一个危害的 E 值争论不休。有人觉得「高速爆胎」概率很低，给 E2；但另一个工程师说「我们统计过，高速爆胎在商用车中并不罕见」。最后我们调出了实际路采数据，发现确实比想象中高，改成了 E3。所以我的建议是：能拿数据说话就别拍脑袋。
避坑指南：我曾经在一个项目里，把 C 值估得太乐观，觉得「驾驶员肯定能反应过来」。结果仿真测试发现，在 80km/h 下，系统突然失效，驾驶员平均反应时间超过 1.5 秒，根本来不及。从那以后，我评估 C 值时都会参考人因工程的数据，而不是凭感觉。
3.4 安全目标导出——把风险变成要求
风险评估完了，就该写安全目标了。安全目标说白了就是一句话：「系统必须避免某种危害」。
格式上，我习惯这样写：
安全目标 ID：SG-001
关联危害：非预期加速
ASIL 等级：ASIL C
安全状态：车辆进入跛行模式，限制最高车速 30 km/h
FTTI（故障容错时间间隔）：≤ 100 ms
这里要注意，安全目标不是功能需求。它不告诉你「怎么实现」，只告诉你「必须达到什么安全状态」。比如：
- ✅ 正确：系统应检测到加速踏板传感器故障，并在 100ms 内限制扭矩输出
- ❌ 错误：系统应使用三冗余传感器来检测加速踏板故障（这是实现方案，不是目标）
我见过很多新手把安全目标写成设计文档，结果评审时被要求重写。记住：安全目标是「什么」，不是「怎么」。
3.5 实战中的常见问题
最后聊几个我实际项目中踩过的坑：
- 场景遗漏：只考虑了正向场景，没考虑反向（比如倒车时）或特殊场景（比如拖车模式）。
- ASIL 分解过早：有些人一上来就把 ASIL D 分解成 ASIL B+B，但没验证独立性。结果审核时被 challenge。
- 安全目标太模糊：比如「系统应保证安全」，这种话等于没说。要具体到「什么条件下、什么时间内、达到什么状态」。
- 忽略 FTTI：很多安全目标没写 FTTI，导致后续设计时不知道要多快响应。这个时间值直接影响硬件选型和软件架构。
总结一句话：HARA 做得好不好，直接决定了后续所有安全活动的质量。我建议每做完一轮 HARA，至少做一次 peer review，让不同背景的工程师来挑刺。你会发现，一个人看永远看不全。
好，这一章就到这里。下一章我们讲安全需求导出，到时候会用到今天定义的安全目标，咱们一步步往下走。