3、危害分析与风险评估（HARA）
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：系统哪里会出问题？出问题后果多严重？我们该用多高的安全等级去防？
我刚开始做功能安全那几年，总觉得 HARA 就是走个过场，填几张表完事。直到有一次，一个座舱的黑屏问题在客户路试时差点引发事故……嗯，从那以后，我再也不敢轻视 HARA 了。它是整个安全开发的基石，地基没打好，后面全是白干。
3.1 HARA 方法论：从 ISO 26262 到智能座舱
ISO 26262 第三部分明确要求：所有可能引发危害的功能，都必须做 HARA。智能座舱虽然不像刹车、转向那么直接关乎生命，但想想看——导航突然黑屏、车速显示错误、报警声被音乐覆盖——这些都可能间接导致驾驶员误操作或分心，进而引发事故。
我个人习惯把 HARA 拆成四个步骤：
- 场景定义——搞清楚车在什么情况下运行
- 危害识别——找出所有可能出错的点
- 风险评估——评估每个危害的严重度、暴露率、可控性
- ASIL 定级——算出安全等级，决定后续开发投入
核心原则：HARA 不是一次性工作。每次功能变更、新增场景、法规更新，都要重新审视。我见过太多项目因为「改个小功能懒得重做 HARA」，最后在认证时被审计师问住。
3.2 运行场景定义：别在实验室里想当然
场景定义是 HARA 的第一步，也是最容易被忽略的一步。很多人坐在办公室里，凭想象列几个场景就完事了。我建议你：去跟测试工程师、标定工程师、甚至客户路试司机聊一聊。他们见过的真实场景，比任何标准都丰富。
智能座舱的典型运行场景至少包括：
- 高速巡航——120km/h，驾驶员注意力集中在前方
- 城市拥堵——走走停停，驾驶员频繁操作中控
- 夜间行驶——屏幕亮度自动调节，HUD 信息投射
- 极端天气——暴雨、大雾、高温、低温
- 充电/停车——车辆静止，娱乐系统全功率运行
- OTA 升级——系统后台更新，部分功能暂时不可用
避坑指南：我曾经在一个项目中，只定义了「正常驾驶」和「停车」两个场景。结果路试时发现，车辆在隧道内 GPS 信号丢失，导航直接卡死。隧道场景我们根本没考虑。从那以后，我要求团队必须列出至少 10 个场景，并且每个场景都要有「正常模式」和「故障模式」两个子状态。
3.3 危害识别：把「不可能」变成「可能」
危害识别，说白了就是假设一切都会坏。屏幕会黑、喇叭会破音、触控会失灵、网络会断。你想想看，如果这些同时发生，驾驶员会怎样？
我常用的方法是功能失效分析（FMEA）和头脑风暴。把功能安全工程师、系统工程师、软件工程师、硬件工程师、测试工程师叫到一个房间，对着功能清单一条条过：
- 这个功能如果失效，最坏后果是什么？
- 这个功能如果误动作，最坏后果是什么？
- 这个功能如果部分失效，最坏后果是什么？
举个例子，智能座舱的「车速显示」功能：
| 功能 | 失效模式 | 潜在危害 |
|---|---|---|
| 车速显示 | 显示值比实际低 20km/h | 驾驶员超速，引发追尾或违章 |
| 车速显示 | 显示值比实际高 20km/h | 驾驶员龟速行驶，引发后车追尾 |
| 车速显示 | 完全黑屏 | 驾驶员分心查看手机导航，偏离车道 |
| 车速显示 | 闪烁/跳动 | 驾驶员视觉疲劳，注意力下降 |
注意：危害识别不要只盯着「直接失效」。间接危害往往更隐蔽。比如，座舱的语音助手误唤醒，突然播放音乐，可能掩盖了外部报警声（如后方来车提示）。这种「功能间干扰」在智能座舱里非常常见。
3.4 风险评估：三个维度，一个公式
ISO 26262 把风险评估拆成三个维度：
- S（Severity）严重度——伤害有多重？轻伤、重伤、致命？
- E（Exposure）暴露率——这个场景发生的概率高不高？
- C（Controllability）可控性——驾驶员能不能在失效时自己救回来？
每个维度分 0~3 或 0~4 级。然后查表得出 ASIL 等级：
| S | E | C | ASIL |
|---|---|---|---|
| 3（致命） | 3（高） | 3（不可控） | ASIL D |
| 3（致命） | 2（中） | 2（难控） | ASIL C |
| 2（重伤） | 3（高） | 2（难控） | ASIL B |
| 1（轻伤） | 2（中） | 1（可控） | ASIL A |
| 0（无伤害） | — | — | QM |
举个例子。智能座舱的「导航黑屏」：
- S：高速上突然黑屏，驾驶员可能急打方向或急刹车，导致追尾或侧翻 → S=3
- E：导航黑屏在高温暴晒下概率不低，每年可能遇到几次 → E=2
- C：驾驶员可以靠路牌和手机导航继续行驶，但需要时间反应 → C=2
查表：S3+E2+C2 = ASIL C。这意味着，导航系统的软件开发必须按照 ASIL C 的要求来——包括代码覆盖率、测试深度、安全机制设计等。
我的经验：很多团队在评估 C（可控性）时会过于乐观。总觉得「驾驶员能反应过来」。但你要知道，在高速上 120km/h，1 秒就是 33 米。驾驶员从「发现异常」到「做出正确反应」，平均需要 2~3 秒。这期间车已经跑出去近百米了。所以，可控性评估一定要保守。
3.5 ASIL 等级确定：从 QM 到 ASIL D
ASIL 等级决定了后续开发的安全投入。等级越高，要求越严：
| ASIL | 安全目标 | 开发要求 | 典型座舱功能 |
|---|---|---|---|
| QM | 无安全要求 | 常规质量管理 | 空调温度显示、座椅记忆 |
| ASIL A | 低风险 | 基本安全流程 | 音量调节、氛围灯 |
| ASIL B | 中等风险 | 中等安全流程 | 导航地图、媒体播放 |
| ASIL C | 高风险 | 严格安全流程 | 车速显示、报警提示音 |
| ASIL D | 极高风险 | 最严格安全流程 | 制动辅助、转向控制（座舱一般不涉及） |
这里有个关键点：ASIL 等级可以分解。比如一个 ASIL C 的功能，可以拆成两个 ASIL B 的子系统，只要它们相互独立、互不干扰。这就是所谓的「ASIL 分解」或「安全分解」。我在项目中经常用这招来降低单个模块的开发成本。
避坑指南：我曾经在一个项目中，把 ASIL C 的「车速显示」分解成「车速采集（ASIL B）」和「车速显示（ASIL B）」。结果审计师问：如果采集模块和显示模块跑在同一个 MCU 上，它们真的独立吗？嗯，这个问题问得好。ASIL 分解的前提是自由干扰（FFI）——两个模块之间不能互相影响。如果共享内存、共享中断、共享电源，那分解就无效。所以，分解之前，先做 FFI 分析。
3.6 HARA 输出：安全目标与安全状态
HARA 的最终输出是安全目标（Safety Goal）和安全状态（Safe State）。
- 安全目标：针对每个危害，定义「系统必须做什么来避免危害」。比如，「车速显示误差不得超过 ±5km/h」。
- 安全状态：当系统检测到故障时，应该进入什么状态。比如，「车速显示故障时，显示 '---' 并点亮报警灯」。
安全目标必须可验证、可测试。不能写「系统要安全」，要写「当车速传感器故障时，系统在 100ms 内切换到备用传感器，并显示故障图标」。
下面是我常用的 HARA 流程框架图，帮你把整个逻辑串起来：
3.7 小结：HARA 不是文档，是决策工具
很多团队把 HARA 当成「交差用的文档」。写完了，锁进文件夹，再也没人看。这是最大的浪费。
我个人习惯把 HARA 当成安全开发的路线图。每次做设计决策、写代码、做测试，都回头翻翻 HARA：这个功能的安全目标是什么？ASIL 等级是多少？安全状态怎么触发？
记住一句话：HARA 的质量，决定了整个功能安全开发的成败。花在 HARA 上的时间，永远不会白费。