2. 危害分析与风险评估（HARA）
各位同学，咱们今天聊HARA。说白了，这就是功能安全开发的“第一道安检”。你连车上有啥危险都不知道，后面的安全设计就是瞎忙活。我见过不少项目，HARA做得马马虎虎，结果到后期测试才发现安全目标定错了，那返工成本，啧啧……
2.1 HARA的目的与流程
HARA要回答三个问题：
- 什么东西会坏？（危害识别）
- 坏起来有多严重？（风险评估）
- 怎么才算安全？（安全目标）
整个流程我习惯分成五步走：
- 功能定义 – 搞清楚系统到底要干啥。比如“电子助力转向”，你得知道它什么时候助力、助力多大、失效了会怎样。
- 运行场景分析 – 车在什么情况下跑？高速？市区？停车场？每种场景风险不一样。
- 危害识别 – 找出所有可能出问题的地方。别漏，漏一个可能就是人命。
- 风险等级评估 – 给每个危害打三个分：S（严重度）、E（暴露概率）、C（可控性）。
- 制定安全目标 – 针对每个危害，写清楚“系统必须做到什么才能避免这个危害”。
核心原则：HARA不是一次性的。设计变了、场景变了、法规变了，都得回头重新做。我有个项目，就因为后期加了个“自动泊车”功能没重做HARA，差点被审核员打回来重做。
2.2 危害识别方法
危害识别，说白了就是“找茬”。你得把系统可能出的所有幺蛾子都翻出来。我常用的方法有几种：
| 方法 | 适用场景 | 我的经验 |
|---|---|---|
| 头脑风暴 | 项目早期，团队聚在一起天马行空 | 别让领导先发言，否则大家都不敢说真话 |
| 检查表法 | 有历史项目可参考时 | 我习惯把之前项目的危害清单整理成模板，新项目直接对照 |
| FMEA | 需要系统化分析时 | FMEA和HARA可以互补，但别混为一谈 |
| 情景分析 | 针对特定运行场景 | 比如“高速上突然断电”，这种极端场景最容易漏 |
我的小技巧：做危害识别时，我习惯先画一张系统功能框图，把输入、输出、控制逻辑、执行器、传感器全标出来。然后对着每个模块问：“如果这个坏了，会发生什么？” 这样不容易漏。
2.3 风险等级评估（S/E/C参数）
ISO 26262 给了三个参数来量化风险：
- S（Severity）严重度 – 伤害有多重？轻伤？重伤？死亡？
- E（Exposure）暴露概率 – 这个场景发生的频率高不高？每天一次？一年一次？
- C（Controllability）可控性 – 驾驶员能不能在故障发生时控制住局面？
三个参数组合起来，就得到 ASIL（Automotive Safety Integrity Level） 等级。从低到高：QM、ASIL A、ASIL B、ASIL C、ASIL D。
| 参数 | 等级 | 描述 | 举例 |
|---|---|---|---|
| S | S0 | 无伤害 | 仪表盘显示错误 |
| S1 | 轻伤 | 刹车灯不亮，后车追尾但速度慢 | |
| S2 | 重伤 | 安全气囊误爆 | |
| S3 | 致命 | 刹车完全失效 | |
| E | E0 | 几乎不可能 | 车辆被陨石击中 |
| E1 | 很少发生 | 每年一次 | |
| E2 | 偶尔发生 | 每月一次 | |
| E3 | 频繁发生 | 每次驾驶都可能遇到 | |
| C | C1 | 容易控制 | 转向助力减弱，驾驶员仍可转向 |
| C2 | 一般可控 | 油门卡滞，但可刹车 | |
| C3 | 难以控制 | 刹车完全失效 |
⚠️ 避坑指南：我曾经在一个项目里，把E参数估低了。原因是团队觉得“这个场景很少见”，但没考虑到用户可能天天在那种场景下开车。结果审核员一句话怼回来：“你凭什么说这个场景不常见？有数据支撑吗？” 从那以后，我每次估E都要求团队拿出真实数据或至少是合理的假设依据。
2.4 安全目标（Safety Goal）的制定
安全目标，就是针对每个危害，写一句“系统必须做到什么”。格式很简单：
“危害 [危害名称] 应被避免，通过 [安全机制] 实现，达到 [ASIL等级]。”
举个例子：
- 危害：电子助力转向在高速行驶时突然失去助力
- 安全目标：转向系统在高速行驶时，即使发生单点故障，也应保持至少50%的助力输出，达到ASIL D。
写安全目标时，我习惯注意几点：
- 可验证 – 目标要能测试。比如“保持50%助力”就能测，“保持足够助力”就太模糊。
- 可追溯 – 每个安全目标都要能追溯到具体的危害和场景。
- 不重叠 – 两个安全目标不要覆盖同一个危害，否则后面设计会打架。
我的经验：安全目标写完后，我建议团队做一次“交叉评审”。让做硬件的人看软件的安全目标，让做软件的人看硬件的。为什么？因为很多安全目标写出来才发现，硬件根本实现不了，或者软件做不到那个响应时间。早发现早修改，别等到设计完了再回头。
好了，HARA这部分就聊到这儿。记住，HARA不是走过场，它是整个功能安全开发的基石。你花在HARA上的每一分钟，后面都会十倍百倍地省回来。