第3章 危害分析与风险评估（HARA）：从场景到ASIL的完整链路
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：系统哪里会出问题？在什么情况下出问题？后果有多严重？
我在多个座舱项目里都发现，很多团队把HARA当成“填表任务”。填完就扔一边，等评审时再翻出来。这是大忌。HARA的结论会直接影响后续所有安全设计，包括安全目标、功能安全概念、甚至硬件架构。
这一章，我带你走一遍完整的HARA流程。从方法论到实战细节，咱们一步步拆开看。
3.1 HARA方法论：三步走框架
ISO 26262-3:2018 第7章给出了HARA的标准流程。我个人习惯把它归纳为三个核心步骤：
- 场景定义 —— 搞清楚车辆在什么运行情况下可能出问题
- 危害识别 —— 找出系统级的功能失效会带来什么危害
- 风险评估与ASIL定级 —— 用S、E、C三个参数算出安全等级
核心原则：HARA必须基于功能，而不是基于实现。你分析的是“中控屏黑屏”这个功能失效，而不是“LCD驱动芯片坏了”这个硬件故障。先有功能，后有实现，顺序不能乱。
下面这张图展示了HARA的完整逻辑链路。我建议你把它贴在工位上，每次做HARA前看一眼。
3.2 运行场景定义：别漏掉“阴雨天高速上小孩乱按”
运行场景，就是车辆可能处于的所有状态组合。ISO 26262 要求覆盖正常运行和故障运行两种模式。
我见过最典型的翻车案例：某团队做仪表盘HARA时，只考虑了“白天、正常驾驶”的场景。结果评审时被安全专家追问：“晚上在高速上，仪表突然黑屏，驾驶员怎么知道车速？” 当场哑火。
场景定义需要覆盖三个维度：
| 维度 | 典型参数 | 举例 |
|---|---|---|
| 车辆状态 | 车速、驾驶模式、转向/制动状态 | 静止、低速(0-30km/h)、中速(30-80km/h)、高速(>80km/h) |
| 环境条件 | 光照、天气、路况、时间 | 白天/夜晚、晴天/暴雨、城市/高速/隧道 |
| 用户行为 | 驾驶员操作、乘客操作、系统交互 | 正常驾驶、分心操作、儿童误触、语音指令 |
我的经验：场景定义阶段，拉上系统工程师、测试工程师、甚至产品经理一起脑暴。一个人想不全所有场景。我曾经在评审会上被测试同事一句话点醒：“如果副驾在调空调，同时导航在播报，中控死机了会怎样？” 这个场景我之前完全没想过。
场景定义完成后，输出一份运行场景清单。每个场景要有唯一编号，方便后续追溯。格式参考：
SC-001: 车辆在高速(>80km/h)正常行驶，白天，晴天，驾驶员专注前方
SC-002: 车辆在城市道路(30-50km/h)行驶，夜晚，小雨，驾驶员正在查看导航
SC-003: 车辆静止(P挡)，乘客正在使用娱乐系统观看视频
SC-004: 车辆在高速(>80km/h)行驶，突然进入隧道，光照骤变
3.3 危害事件识别：从功能失效到危害的映射
有了场景，下一步就是识别危害事件。注意，这里说的是危害事件，不是单纯的危害。
危害（Hazard）是系统层面的潜在危险源，比如“中控屏显示错误车速”。危害事件（Hazardous Event）是危害在特定运行场景下实际发生的情况，比如“在高速上中控屏显示的车速比实际低20km/h”。
识别步骤：
- 列出所有功能 —— 比如导航、仪表显示、空调控制、语音交互
- 分析功能失效模式 —— 输出错误、无输出、输出延迟、输出抖动
- 关联运行场景 —— 每个失效模式在哪些场景下会变成危害
- 形成危害事件 —— 描述格式：
[失效模式] + [场景] → [危害后果]
举个例子：
| 功能 | 失效模式 | 运行场景 | 危害事件描述 |
|---|---|---|---|
| 仪表盘车速显示 | 显示值比实际低20km/h | 高速行驶(>80km/h)，夜晚 | 驾驶员误判车速，可能导致超速或追尾 |
| 360°全景影像 | 画面延迟超过2秒 | 倒车入库，后方有行人 | 驾驶员未发现后方行人，导致碰撞 |
| 语音导航 | 播报错误转弯方向 | 城市道路，复杂路口 | 驾驶员急转弯或逆行，引发事故 |
⚠️ 避坑指南：我曾经在一个项目中，把“中控屏死机”直接写成了危害事件。评审时被指出：死机本身不是危害，死机导致驾驶员无法查看导航、在高速上错过出口、突然变道才是危害。一定要把后果写清楚，否则ASIL定级会偏。
3.4 ASIL等级确定：S、E、C三参数详解
ASIL，Automotive Safety Integrity Level，汽车安全完整性等级。分四个等级：ASIL A、B、C、D，D是最严格的。QM（Quality Management）表示无需安全措施，按普通质量管控即可。
ASIL由三个参数决定：
- S（Severity）严重度 —— 危害发生时，对人员伤害的严重程度
- E（Exposure）暴露率 —— 运行场景发生的概率
- C（Controllability）可控性 —— 驾驶员或其他人员能否控制住局面
每个参数分4个等级（0-3），查表得出最终ASIL。
3.4.1 严重度 S
| S等级 | 伤害程度 | 典型场景举例 |
|---|---|---|
| S0 | 无伤害 | 娱乐系统音量突然变大，但驾驶员可忽略 |
| S1 | 轻伤（可治疗） | 空调误启动导致驾驶员轻微分心 |
| S2 | 重伤（需住院） | 导航误导导致车辆驶入逆行车道 |
| S3 | 致命伤 | 仪表盘显示错误车速导致高速追尾 |
3.4.2 暴露率 E
| E等级 | 暴露概率 | 典型场景举例 |
|---|---|---|
| E0 | 几乎不可能 | 车辆在赛道上以200km/h行驶 |
| E1 | 很少发生（<1% 驾驶时间） | 在无人路段倒车 |
| E2 | 偶尔发生（1%-10% 驾驶时间） | 在雨天行驶 |
| E3 | 频繁发生（>10% 驾驶时间） | 在城市道路行驶、在白天行驶 |
3.4.3 可控性 C
| C等级 | 可控程度 | 典型场景举例 |
|---|---|---|
| C0 | 完全可控 | 中控屏亮度异常，驾驶员可手动调节 |
| C1 | 简单可控 | 导航语音播报错误，驾驶员可凭经验判断 |
| C2 | 一般可控 | 仪表盘显示异常，但驾驶员可通过其他方式获取车速 |
| C3 | 难以控制 | 高速上仪表盘黑屏，驾驶员无法获知车速 |
3.4.4 ASIL查表
有了S、E、C三个值，查下表得到最终ASIL等级：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| E2 | QM | QM | ASIL A | |
| E3 | QM | ASIL A | ASIL B | |
| S2 | E1 | QM | QM | ASIL A |
| E2 | QM | ASIL A | ASIL B | |
| E3 | ASIL A | ASIL B | ASIL C | |
| S3 | E1 | QM | ASIL A | ASIL B |
| E2 | ASIL A | ASIL B | ASIL C | |
| E3 | ASIL B | ASIL C | ASIL D |
实战技巧：定级时，我习惯先定S和E，再讨论C。因为S和E相对客观，C容易有争议。比如“驾驶员能不能控制”，不同人看法可能完全不同。我的建议是：按最坏情况定C。如果评审时有人质疑，再提供数据或引用场景来降级。
3.5 实战案例：中控屏车速显示功能HARA
咱们拿一个真实场景练练手。假设某智能座舱项目中，仪表盘和中控屏都显示车速。中控屏作为辅助显示，仪表盘是主显示。
功能：中控屏显示当前车速
失效模式：显示值比实际车速高20km/h
运行场景：高速行驶(100km/h)，白天，驾驶员偶尔扫一眼中控屏确认车速
分析过程：
- S（严重度）：驾驶员看到车速120km/h，实际只有100km/h。他可能减速，但不会造成直接伤害。但如果有其他车辆突然切入，驾驶员基于错误车速判断刹车距离，可能导致追尾。定级：S2（重伤可能）
- E（暴露率）：高速行驶在总驾驶时间中占比约15%-20%。定级：E3
- C（可控性）：驾驶员还有仪表盘作为主参考，中控屏只是辅助。如果发现异常，可以切换看仪表盘。定级：C1（简单可控）
查表：S2 + E3 + C1 = ASIL A
注意：如果这个功能是仪表盘车速显示，同样的失效模式，S和E不变，但C会变成C2甚至C3（因为仪表盘是主参考，驾驶员没有其他可靠来源）。最终ASIL可能升到B或C。同一个失效，放在不同功能上，等级完全不同。这就是为什么HARA必须基于具体功能+具体场景。
3.6 HARA常见错误与避坑
做了这么多年HARA，我踩过不少坑。挑几个最常见的说说：
- 场景定义太粗 —— 只写“行驶中”，不写车速、路况、环境。评审时会被追问到崩溃。
- 危害和失效混为一谈 —— 失效是“中控屏不亮”，危害是“驾驶员看不到导航导致走错路”。两者要分开写。
- ASIL定级凭感觉 —— 没有数据支撑。比如E值，最好有实际驾驶数据或行业参考，而不是拍脑袋。
- 遗漏组合场景 —— 比如“夜晚+暴雨+高速”，三个低概率事件组合起来，概率可能不低，但容易被忽略。
⚠️ 我曾经犯过的错：在一个项目中，我把“语音助手误唤醒”的ASIL定成了QM，觉得只是烦人而已。结果客户投诉说，在高速上语音助手突然开始播报音乐，分散了驾驶员注意力，差点出事。后来重新评估，改成了ASIL A。所以，不要轻视任何与驾驶员交互的功能。
3.7 HARA输出物清单
HARA做完后，需要交付以下文档：
| 输出物 | 内容 | 格式 |
|---|---|---|
| 运行场景清单 | 所有定义的运行场景，含编号和描述 | Excel 或 需求管理工具 |
| 危害事件清单 | 每个危害事件的完整描述，含关联场景 | Excel 或 需求管理工具 |
| ASIL定级表 | 每个危害事件的S、E、C值及最终ASIL | Excel 或 表格 |
| 安全目标草案 | 每个ASIL等级对应的初步安全目标 | 需求管理工具 |
| HARA报告 | 方法论、假设、分析过程、结论 | Word 或 PDF |
嗯，HARA这部分内容比较多，但它是整个功能安全设计的基石。你花在HARA上的每一分钟，都会在后续开发中省回来。别急，慢慢来，把场景想全，把等级定准，后面就顺了。