3. 危害分析与风险评估（HARA）：从零开始把风险量化
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：系统哪里会出问题？出问题后果多严重？我们该花多大力气去防？
我入行那会儿，HARA 还没这么规范。大家靠经验拍脑袋，结果项目后期发现安全目标定得太松，或者定得太死。后来 ISO 26262 把 HARA 标准化了，我才真正体会到——前期花一周做 HARA，后期能省一个月返工。
3.1 HARA 方法论：从场景到目标
HARA 不是一次性的文档工作。它贯穿概念阶段和系统开发。我个人习惯把它拆成四个步骤：
- 场景分析——车在什么情况下运行？
- 危害识别——哪些故障会导致危险？
- 风险评估——后果有多严重？发生概率多大？
- 安全目标定义 + ASIL 定级——我们要防到什么程度？
下面这张图，是我每次做 HARA 都会贴在白板上的流程骨架：
3.2 危害识别：别漏掉那些“不可能”的场景
危害识别，核心是场景驱动。你不能坐在办公室里凭空想。你得把车放到真实路况里：
- 运行模式：正常行驶、泊车、充电、OTA 升级、紧急制动
- 环境条件：白天/黑夜、雨雪/晴天、隧道/高速/市区
- 用户行为：正常操作、误操作、恶意操作、系统故障后的人为干预
危害识别常用的方法：
- HAZOP（Hazard and Operability Study）——引导词法（无、多、少、反向、早、晚等）
- FMEA（Failure Mode and Effects Analysis）——从故障模式出发
- 头脑风暴 + 检查表——最接地气，但依赖经验
我个人偏爱 HAZOP。因为它系统化，不容易漏。比如对“转向扭矩传感器信号”做 HAZOP：
| 引导词 | 偏差 | 潜在危害 |
|---|---|---|
| 无 | 信号丢失 | 转向助力突然消失 |
| 多 | 信号超量程 | 转向过度助力，车辆失控 |
| 反向 | 信号极性错误 | 转向方向相反，驾驶员无法控制 |
| 早 | 信号提前 | 转向响应超前，驾驶员困惑 |
3.3 风险评估：三个维度定生死
ISO 26262 用三个参数来评估每个危害事件的风险：
- S（Severity）——严重度。对驾驶员、乘客、路人造成的伤害程度
- E（Exposure）——暴露概率。该场景在车辆生命周期中出现的频率
- C（Controllability）——可控性。驾驶员或其他人员能否避免伤害
每个参数分 0~3 或 0~4 级。组合起来查表得到 ASIL 等级。
举个例子。我做过一个线控制动（Brake-by-Wire）项目。其中一个危害事件是“制动踏板位置传感器失效，导致制动指令丢失”。
| 参数 | 等级 | 理由 |
|---|---|---|
| S（严重度） | S3 | 高速下无制动，可能造成多人伤亡 |
| E（暴露概率） | E4 | 车辆每次行驶都会用到制动，场景高频 |
| C（可控性） | C2 | 驾驶员可尝试手刹或紧急制动，但反应时间短 |
查 ISO 26262-3 的 ASIL 判定表：S3 + E4 + C2 → ASIL D。
3.4 安全目标定义：把危害翻译成工程语言
安全目标（Safety Goal, SG）是 HARA 的最终输出。它描述的是：系统必须避免什么。
格式很简单：避免 [危害事件] 导致 [后果]。
比如上面线控制动的例子：
- SG-01：避免因制动踏板位置传感器失效导致制动指令丢失，造成车辆无法减速。
ASIL：D - SG-02：避免因制动指令传输延迟超过 100ms 导致制动响应滞后，造成追尾。
ASIL：C
每个安全目标必须：
- 可验证——能通过测试或分析证明它被满足
- 可追溯——能追溯到具体的危害事件
- 无歧义——不同工程师读到的理解一致
FTTI（Fault Tolerant Time Interval） 的初步估计。比如“制动指令丢失后，系统必须在 50ms 内检测并进入安全状态”。这样后续做安全架构时，时间预算就清晰了。
3.5 ASIL 等级确定：不是终点，是起点
ASIL 等级决定了后续开发的安全措施力度：
| ASIL | 硬件指标 | 软件要求 | 测试覆盖 |
|---|---|---|---|
| QM | 无特殊要求 | 质量管理体系 | 常规测试 |
| ASIL A | 低诊断覆盖率 | 部分安全机制 | 部分覆盖 |
| ASIL B | 中等诊断覆盖率 | 较多安全机制 | 较高覆盖 |
| ASIL C | 高诊断覆盖率 | 严格安全机制 | 高覆盖 |
| ASIL D | 极高诊断覆盖率 | 最严格安全机制 | 全覆盖 + 独立验证 |
但要注意：ASIL 等级不是一成不变的。你可以通过架构设计来分解 ASIL。比如一个 ASIL D 的功能，分解成两个独立的 ASIL C 通道，每个通道满足 ASIL C 即可。这叫 ASIL 分解（ASIL Decomposition）。
嗯，这里要特别提醒：ASIL 分解不是偷懒的手段。它要求两个通道真正独立——独立的硬件、独立的软件、独立的供电、独立的通信。我在一个项目中见过团队把 ASIL D 分解成两个 ASIL B，结果两个通道共用同一个 MCU 的 ADC 模块。审计时直接被判定为“不独立”，全部重做。
3.6 避坑指南：HARA 常见问题
- 场景不够全——只考虑正常驾驶，忽略维护模式、出厂模式、故障模式
- 危害定义太笼统——比如“系统失效”，没有具体到哪个功能、哪个信号
- ASIL 评分主观——没有数据支撑，全靠“我觉得”
- 安全目标写成了功能需求——SG 是“避免什么”，不是“做什么”
- 忽略多故障组合——ISO 26262 要求考虑单点故障，但双点故障也要评估
HARA 做扎实了，后面的安全架构、安全机制设计、测试验证才有根。别把它当成文档任务，它其实是整个功能安全工程的地基。