2、危害分析与风险评估(HARA)：HARA方法论、运行场景定义、危害识别、风险评估与ASIL等级确定
好，咱们进入正题。HARA，全称 Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。这玩意儿是功能安全开发的起点，也是整个安全架构的基石。说白了，就是回答三个问题：
- 车会不会出危险？（危害识别）
- 这危险有多严重？（风险评估）
- 我们得花多大力气去防它？（ASIL等级确定）
我个人习惯，做HARA之前，先泡杯茶，把脑子清空。因为这一步一旦做偏了，后面所有安全机制都是空中楼阁。我在项目中遇到过，有人为了赶进度，HARA草草了事，结果到了测试阶段发现ASIL等级定低了，整个架构推倒重来。嗯，那滋味，不好受。
2.1 HARA方法论：从ISO 26262说起
ISO 26262 第三部分，专门讲HARA。它给了一套标准流程，但说实话，标准是死的，人是活的。我建议你把它理解成一套「找茬」的方法论。
核心思路就四个字：场景驱动。你想想看，一个故障本身不可怕，可怕的是它在特定场景下被触发了。比如刹车失灵，在空旷的停车场和高速公路上，后果天差地别。
所以，HARA的完整流程是这样的：
- 定义运行场景 —— 车在什么情况下跑？
- 识别危害 —— 哪个功能出问题会要命？
- 评估风险 —— 评估严重度(S)、暴露率(E)、可控性(C)。
- 确定ASIL等级 —— 查表，得出QM、ASIL A/B/C/D。
核心原则：HARA不是一次性的。随着项目推进，发现新场景、新功能，都要回头更新HARA。我管这叫「滚动式HARA」。
2.2 运行场景定义：别让车在真空中跑
很多新手犯的错，就是只考虑「正常行驶」。但现实世界复杂得多。你想想看，下雨、下雪、隧道、地库、行人突然窜出……这些都是场景。
我个人习惯，把场景拆成三个维度：
| 维度 | 举例 |
|---|---|
| 环境条件 | 白天/黑夜、晴天/雨天/雪天、隧道/高架/地库 |
| 车辆状态 | 静止、低速、高速、转弯、倒车、自适应巡航激活 |
| 人为因素 | 驾驶员分心、疲劳、误操作、儿童在车内 |
举个例子，咱们分析「自动紧急制动(AEB)」功能。你不能只写「AEB在行驶中触发」。你得写：
- 场景1：AEB在高速公路上，前方车辆急刹，本车时速120km/h，路面湿滑。
- 场景2：AEB在城市道路，行人突然横穿，本车时速40km/h，驾驶员正在看手机。
- 场景3：AEB在地库出口，坡度较大，传感器视野受限。
你看，同一个功能，不同场景下，危害的严重程度完全不同。我曾经在项目里漏掉了「地库场景」，结果测试时发现AEB在坡道上误触发，差点把测试车搞翻。嗯，从那以后，我每次定义场景都要拉上系统工程师、测试工程师一起「头脑风暴」。
小技巧：场景定义不要贪多。先覆盖「最坏情况」和「最常见情况」。后续迭代再补充边缘场景。
2.3 危害识别：找到那个「万一」
危害识别，说白了就是找「功能失效」导致的「危险事件」。注意，不是找故障本身，而是找故障引发的后果。
比如：
- 「转向助力失效」是故障。
- 「转向助力失效导致驾驶员无法转向，车辆偏离车道，与对向车辆碰撞」——这才是危害。
我常用的方法是HAZOP（危险与可操作性分析）。对每个功能，问几个问题：
- 功能不工作了会怎样？
- 功能工作异常了会怎样？
- 功能在不该工作的时候工作了会怎样？
- 功能输出值错误了会怎样？
举个例子，咱们分析「电子助力转向(EPS)」：
| 功能 | 失效模式 | 危害事件 |
|---|---|---|
| EPS | 无助力输出 | 驾驶员需要施加更大转向力，在低速泊车时可能无法完成转向，碰撞行人或车辆 |
| EPS | 非预期助力输出 | 车辆突然自行转向，偏离车道，与相邻车道车辆碰撞 |
| EPS | 助力方向错误 | 驾驶员向左打方向，车辆向右转，完全失控，后果极其严重 |
注意：危害识别一定要「场景化」。不要只写「车辆失控」，要写清楚「在什么场景下，以什么方式失控」。否则后面风险评估没法做。
2.4 风险评估：三个参数定生死
风险评估，ISO 26262给了三个参数：
- S（Severity） —— 严重度。人员受伤有多重？
- E（Exposure） —— 暴露率。这个场景出现的频率高不高？
- C（Controllability） —— 可控性。驾驶员或其他人员能控制住局面吗？
每个参数分0-3级，3级最严重。我直接给你看分类标准：
| 等级 | S（严重度） | E（暴露率） | C（可控性） |
|---|---|---|---|
| 0 | 无伤害 | 几乎不暴露 | 完全可控 |
| 1 | 轻伤（擦伤、淤青） | 每年几次 | 简单可控（>99%驾驶员能应对） |
| 2 | 重伤（骨折、内伤） | 每月几次 | 一般可控（90%-99%驾驶员能应对） |
| 3 | 致命伤（死亡） | 几乎每次驾驶都暴露 | 难以控制（<90%驾驶员能应对） |
举个例子，评估刚才的「EPS非预期助力输出」：
- S=3：高速上突然转向，大概率致命。
- E=2：这个场景每月可能遇到几次（比如在高速上行驶）。
- C=3：突然的转向，大部分驾驶员反应不过来，难以控制。
这里有个坑，我踩过。评估E（暴露率）时，不要只看「故障发生的概率」，要看「故障发生时，车辆是否处于那个危险场景」。比如，EPS故障可能一年才发生一次，但一旦发生，车辆正好在高速上，那E值就得按高速场景的频率来算。说白了，E评估的是「场景的暴露率」，不是「故障的失效率」。
避坑指南：我曾经在一个项目中，把E值评估错了。我以为「EPS故障概率低，所以E=1」。结果评审时被专家怼了——「你EPS故障概率低，但车辆每天上高速，高速场景的暴露率是E=3。故障一旦发生，就在高速上，所以E应该取3。」从那以后，我每次评估E值，都先问自己：「这个场景，驾驶员每天会遇到几次？」
2.5 ASIL等级确定：查表就完事了？没那么简单
有了S、E、C三个值，查ISO 26262的表格，就能得出ASIL等级。表格长这样：
| S | E | C | ASIL |
|---|---|---|---|
| 1 | 1 | 1 | QM |
| 2 | 2 | 2 | A |
| 3 | 2 | 3 | D |
| 3 | 3 | 3 | D |
| ... | ... | ... | ... |
但实际工作中，查表只是最后一步。真正的难点在于：如何客观地给S、E、C打分？
我个人的经验是：
- S值：参考事故统计数据。比如，高速碰撞的死亡率远高于低速。不要拍脑袋。
- E值：参考车辆使用场景调研。比如，你的车主要在城市跑，还是跑高速？用户群体是新手还是老司机？
- C值：参考人因工程研究。比如，突然的转向，普通人需要0.5秒反应时间，但高速上0.5秒已经冲出十几米了。
举个例子，咱们刚才的EPS非预期助力输出：
- S=3, E=2, C=3 → 查表得 ASIL D。
这意味着，你需要用最高等级的安全机制来防止这个危害。比如，双MCU冗余、安全监控芯片、故障容错时间间隔<10ms等等。
小提示：ASIL D不是终点。有时候，你可以通过「分解」来降低单个组件的ASIL等级。比如，把一个ASIL D的功能，分解成两个ASIL C的组件，互相监控。这个后面章节会细讲。
2.6 实战案例：一个完整的HARA示例
咱们拿「线控制动（Brake-by-Wire）」来练练手。假设功能是：驾驶员踩制动踏板，信号传给ECU，ECU控制制动执行器夹紧刹车盘。
步骤1：定义运行场景
- 场景A：城市道路，时速30km/h，前方红灯，驾驶员正常制动。
- 场景B：高速公路，时速120km/h，前方车辆急刹，驾驶员紧急制动。
- 场景C：下坡路段，满载，连续制动，制动系统可能过热。
步骤2：识别危害
- 危害1：制动信号丢失 → 车辆无法制动 → 碰撞。
- 危害2：制动信号错误（比如信号值偏小） → 制动力不足 → 制动距离延长 → 追尾。
- 危害3：非预期制动（比如ECU误判） → 车辆突然急刹 → 后车追尾。
步骤3：风险评估
| 危害 | 场景 | S | E | C | ASIL |
|---|---|---|---|---|---|
| 制动信号丢失 | 场景B（高速急刹） | 3 | 2 | 3 | D |
| 制动信号错误 | 场景A（城市正常制动） | 2 | 3 | 2 | B |
| 非预期制动 | 场景B（高速行驶） | 3 | 2 | 2 | C |
步骤4：确定安全目标
- 安全目标1：防止制动信号丢失（ASIL D）。
- 安全目标2：防止制动信号错误导致制动力不足（ASIL B）。
- 安全目标3：防止非预期制动（ASIL C）。
你看，同一个功能，不同危害，ASIL等级可能完全不同。所以，HARA一定要细化到「危害事件」级别，不能笼统地说「制动系统是ASIL D」。
最后提醒：HARA文档一定要经过评审。我建议至少拉上系统、软件、硬件、测试、甚至项目经理一起过一遍。因为每个人看问题的角度不同，你漏掉的场景，别人可能一眼就看出来了。别怕被怼，被怼出来的安全，才是真安全。
好，这一章就到这儿。下一章咱们聊聊「功能安全概念设计」，看看怎么把ASIL等级落地成具体的安全机制。