3、危害分析与风险评估（HARA）
各位工程师朋友，咱们今天聊聊HARA。说实话，这是功能安全里最让我「又爱又恨」的环节。爱它，是因为它决定了整个项目的安全目标；恨它，是因为一旦做不好，后面全是坑。
我个人的习惯是，拿到一个新项目，先不急着写代码。先花一周时间，把HARA做扎实。为什么？因为后面所有的设计、测试、验证，都得围着它转。你想想看，如果方向错了，跑得再快也没用。
3.1 HARA方法论：从「拍脑袋」到「有章法」
HARA，全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 车会不会出事儿？（危害识别）
- 在什么情况下出事儿？（运行场景定义）
- 出事儿有多严重？（风险分类与ASIL等级）
我在做第一个功能安全项目时，犯过一个低级错误。当时觉得「刹车系统嘛，肯定是最高的ASIL D」，结果评审时被专家怼了回来：「你连场景都没分析，凭什么定D？」嗯，从那以后，我再也不敢跳过方法论了。
HARA的流程，我习惯用五步法：
- 功能定义：搞清楚这个ECU到底要干什么
- 场景分析：列出所有可能的运行场景
- 危害识别：找出功能失效后会导致什么危害
- 风险评估：评估危害的严重度、暴露率、可控性
- ASIL定级：根据评估结果确定安全等级
核心原则：HARA不是一次性的工作。随着项目深入，你会发现新的场景、新的危害。所以，保持迭代的心态很重要。
3.2 运行场景定义：别让「意外」变成「意料之外」
运行场景，就是你的ECU在真实世界中会遇到的「环境」。我见过很多团队，场景定义得特别「理想化」——永远在平坦的柏油路上，永远有充足的阳光，永远没有其他车辆干扰。
现实呢？
- 暴雨天，路面湿滑，能见度低
- 隧道里，GPS信号丢失
- 高速上，突然有动物窜出
- 地下车库，手机信号弱，蓝牙连接不稳定
我曾经参与过一个ADAS项目，团队只定义了「正常行驶」场景。结果路测时，车辆在隧道出口处出现了误制动。为什么？因为场景里没考虑「光线突变」这个因素。后来我们补了20多个场景，才把这个问题覆盖掉。
定义场景时，我建议从三个维度入手：
| 维度 | 典型因素 | 举例 |
|---|---|---|
| 环境 | 天气、光照、路况、信号 | 暴雨、夜间、冰雪路面、隧道 |
| 车辆 | 车速、负载、系统状态 | 高速巡航、满载、系统降级模式 |
| 驾驶员 | 注意力、操作、反应时间 | 分心驾驶、疲劳驾驶、紧急避让 |
小技巧：我习惯用「场景卡片」的方式，把每个场景写在一张卡片上。评审时，大家拿着卡片讨论，效率特别高。而且，卡片可以随时增删，方便迭代。
3.3 危害识别：找到那些「要命」的失效
危害识别，就是找出「功能失效后，会导致什么危险情况」。注意，这里说的是「危害」，不是「失效」。失效是技术层面的（比如传感器坏了），危害是系统层面的（比如车辆失控）。
举个例子：
- 功能：电子助力转向系统
- 失效：扭矩传感器输出错误
- 危害：驾驶员需要施加更大的力才能转向，可能导致碰撞
我常用的方法是「HAZOP分析」——引导词法。用「没有、更多、更少、相反、错误」等引导词，去触发思考。
比如，针对「制动辅助」功能：
- 没有：需要制动时，辅助功能没有介入
- 更多：辅助制动过度，导致车轮抱死
- 更少：辅助制动力不足，制动距离变长
- 相反：应该制动时，反而加速
- 错误：在不需要制动时，错误地施加制动
你看，一个简单的功能，就能衍生出这么多危害。所以，别偷懒，老老实实把每个引导词都过一遍。
避坑指南：我曾经遇到一个团队，把「危害」和「失效」混为一谈。结果他们的HARA文档里，全是「传感器故障」「通信超时」这类技术问题。评审时被安全专家批得一无是处。记住，危害是「车辆层面的危险事件」，不是「ECU内部的失效模式」。
3.4 风险分类与ASIL等级确定：给危害「打分」
找到危害之后，就要给每个危害「打分」。这个分数，就是ASIL等级。ASIL有四个等级：A、B、C、D，D是最严格的。
打分依据三个参数：
- S（Severity）：严重度。人员受伤的程度。
- E（Exposure）：暴露率。危害场景发生的概率。
- C（Controllability）：可控性。驾驶员或其他人员能否控制住局面。
每个参数都有具体的分级标准。我直接给个表格，大家一看就明白：
| 参数 | 等级 | 描述 | 举例 |
|---|---|---|---|
| S | S0 | 无伤害 | 轻微颠簸 |
| S1 | 轻伤（可治疗） | 擦伤、扭伤 | |
| S2 | 重伤（需住院） | 骨折、内出血 | |
| S3 | 致命伤 | 死亡、永久性残疾 | |
| E | E0 | 几乎不可能 | 车辆被陨石击中 |
| E1 | 很少发生 | 每年一次 | |
| E2 | 偶尔发生 | 每月一次 | |
| E3 | 频繁发生 | 每次驾驶都可能遇到 | |
| C | C0 | 完全可控 | 驾驶员轻松应对 |
| C1 | 简单可控 | 95%的驾驶员能应对 | |
| C2 | 难以控制 | 只有少数专业驾驶员能应对 | |
| C3 | 不可控 | 任何驾驶员都无法避免伤害 |
有了这三个参数，就可以查表确定ASIL等级了。ISO 26262里有个标准矩阵，我直接贴出来：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| E2 | QM | QM | A | |
| E3 | QM | A | B | |
| S2 | E1 | QM | QM | A |
| E2 | QM | A | B | |
| E3 | A | B | C | |
| S3 | E1 | QM | A | B |
| E2 | A | B | C | |
| E3 | B | C | D |
举个例子：
- 危害：车辆在高速行驶时，转向系统突然失效，导致车辆偏离车道
- S：S3（高速碰撞，很可能致命）
- E：E2（转向失效虽然不常见，但高速行驶是常见场景）
- C：C2（普通驾驶员很难在瞬间控制住偏离的车辆）
- 查表：S3+E2+C2 = ASIL C
注意：QM（Quality Management）表示不需要功能安全措施，按普通质量管理即可。但别以为QM就万事大吉了——如果后续分析发现新的场景，QM可能会变成ASIL A甚至更高。
3.5 实战经验：HARA文档的「灵魂三问」
最后，分享一个我自己的检查清单。每次做完HARA，我都会问自己三个问题：
- 场景够全吗？——有没有遗漏「边界情况」？比如极端天气、特殊路况、驾驶员异常状态。
- 危害够具体吗？——每个危害是否都描述到了「车辆层面」？有没有停留在「ECU失效」层面？
- ASIL定级合理吗？——有没有「拍脑袋」定D？有没有「偷懒」定QM？
我曾经有一个项目，HARA做了三版才通过评审。第一版，场景太少；第二版，危害描述不准确；第三版，ASIL定级有争议。说实话，当时挺崩溃的。但后来发现，正是这种反复打磨，才让后面的设计阶段少走了很多弯路。
所以，别怕HARA花时间。你在这里花的时间，后面都会加倍还给你。
最后一个小建议：HARA文档不是写给别人看的，是写给自己团队用的。所以，语言要清晰，逻辑要严谨，但别搞得太「学术」。能用一句话说清楚的，别用三段话。毕竟，功能安全的目的是「安全」，不是「炫技」。