3、危害分析与风险评估(HARA)：HARA方法、运行场景定义、安全目标导出
好，咱们进入功能安全里最核心、也是最容易翻车的一步——HARA。
HARA 全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
“我的系统会不会出危险？在什么情况下出？出了以后后果多严重？”
我见过不少团队，上来就写安全目标，结果写到一半发现场景没定义清楚，又回头重做。嗯，HARA 这件事，顺序错了，后面全是补丁。
3.1 HARA 的核心方法
HARA 不是拍脑袋，它有一套标准流程。我个人习惯把它拆成四步走：
- 功能分析 —— 搞清楚系统到底有哪些功能。
- 危害识别 —— 每个功能失效了会怎样？
- 场景定义 —— 失效发生在什么环境、什么工况下？
- 风险评估 —— 用 ASIL 等级量化风险。
这里有个坑：很多人把“危害”和“失效”混为一谈。我纠正一下——失效是功能没了或错了，危害是失效导致的人身伤害。比如“刹车灯不亮”是失效，“后车追尾”才是危害。
关键原则：HARA 只关注与人身伤害相关的危害。财产损失、环境破坏，ISO 26262 不管。
3.2 运行场景定义 —— 最容易被忽视的一步
运行场景，就是你的 ECU 在什么情况下会出事。我刚开始做 HARA 时，觉得场景随便写几个就行。直到有一次评审，专家问我：“你这个‘车辆行驶中’到底是多少速度？路面是干是湿？周围有没有行人？”
问得我哑口无言。从那以后，我定了个规矩：每个危害至少写三个场景维度。
| 维度 | 示例 | 说明 |
|---|---|---|
| 车辆状态 | 静止、低速、高速、倒车 | 车速直接影响危害严重度 |
| 环境条件 | 白天/黑夜、雨/雪/雾、路面附着系数 | 环境决定可控性 |
| 人员/交通参与者 | 驾驶员、乘客、行人、其他车辆 | 暴露对象不同，风险不同 |
我的习惯：用“场景卡片”的方式，每个危害写 3~5 张卡片。比如“高速公路上，夜间下雨，前车急刹，本车 ACC 未响应”。卡片越具体，安全目标越精准。
3.3 安全目标导出 —— 从危害到约束
安全目标，就是一句话：“系统必须避免某某危害发生”。它不涉及具体实现，只描述“要什么结果”。
举个例子：
- 危害：EPS 非预期转向导致车辆偏离车道，与相邻车道车辆碰撞。
- 安全目标：EPS 系统应避免在非驾驶员意图下产生转向力矩，防止车辆非预期偏离车道。
这里要注意，安全目标要带ASIL 等级。怎么定？看三个参数：
- S（Severity）：伤害严重度，S0~S3
- E（Exposure）：场景暴露概率，E0~E4
- C（Controllability）：驾驶员可控性，C0~C3
ASIL 等级 = S × E × C 的组合查表结果。QM 表示无需安全措施，ASIL A/B/C/D 逐级严格。
我曾经踩过的坑：把 ASIL 定得太高。比如一个场景几乎不可能发生（E1），但团队硬给了 ASIL C，导致后续开发成本翻倍。记住：ASIL 不是越高越好，合适才是。
3.4 HARA 整体流程框架
下面这张图，是我每次做 HARA 时贴在墙上的流程。你照着走，基本不会漏。
3.5 实战避坑指南
最后，分享几个我这些年总结的教训：
- 场景别太笼统。“车辆行驶中”这种描述，评审时会被打回来。要具体到“城市道路，时速30km/h，跟车距离5米”。
- 安全目标别写解决方案。比如“增加冗余传感器”是方案，不是目标。目标应该是“系统应避免非预期加速”。
- ASIL 分解要谨慎。一个 ASIL D 的安全目标，可以分解成 ASIL C + ASIL A 的独立要素。但分解后要证明独立性，否则白做。
一个小技巧：HARA 文档写完后，找两个没参与项目的人来评审。他们往往能发现你“想当然”的场景漏洞。我吃过这个亏，后来每次 HARA 都强制做“盲审”。
好了，HARA 这部分就聊到这儿。记住：HARA 的质量，决定了整个功能安全开发的根基。根基不稳，后面全是空中楼阁。