3. 危害分析与风险评估（HARA）

HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车子哪里会出问题？出问题会怎样？后果有多严重？

我刚开始接触 ISO 26262 时，觉得 HARA 就是填表格。后来吃过亏才明白——HARA 是整个功能安全开发的基石。这一步做不好，后面的安全目标、安全需求全是空中楼阁。

3.1 HARA 方法论：从场景到风险

HARA 不是拍脑袋。它有一套标准流程。我个人习惯把它拆成 5 步：

1. 定义项目边界——搞清楚你要分析的系统是什么，功能有哪些。
2. 识别运行场景与操作模式——车会在什么情况下用？
3. 定义危害事件——功能失效后，会发生什么危险？
4. 评估风险参数（S/E/C）——严重度、暴露率、可控性。
5. 确定 ASIL 等级——根据 S/E/C 查表得出安全等级。

我见过一个项目，团队只分析了正常驾驶场景，忽略了「车辆在坡道起步」这个模式。结果电子手刹的失效模式没覆盖到，差点导致溜车事故。嗯，后来整个 HARA 重做了一遍。

3.2 运行场景与操作模式

运行场景，就是车辆在什么环境下运行。操作模式，就是系统处于什么工作状态。

运行场景至少要考虑：

• 道路类型：高速、城市、乡村、停车场
• 环境条件：白天/夜晚、雨/雪/雾、温度范围
• 交通状况：拥堵、畅通、交叉路口
• 车辆状态：静止、匀速、加速、减速、转弯

操作模式包括：

• 正常模式
• 故障模式（降级运行）
• 维护模式
• 初始化/自检模式
• 休眠/唤醒模式

3.3 危害事件定义

危害事件 = 功能失效 + 运行场景。举个例子：

功能	失效模式	运行场景	危害事件
电子助力转向	非预期转向	高速行驶	车辆突然偏离车道，与相邻车道车辆碰撞
制动系统	制动力丧失	下坡路段	车辆无法减速，追尾前车
加速踏板	非预期加速	停车场倒车	车辆失控撞向后方行人

定义危害事件时，我建议用一句话说清楚：什么失效 + 什么场景 = 什么后果。不要写得太抽象，比如「车辆失控」——失控到什么程度？撞车？翻车？撞人？越具体越好。

3.4 风险参数评估：S / E / C

ISO 26262 用三个参数来量化风险：

• S（Severity）——严重度：伤害有多重？
• E（Exposure）——暴露率：场景出现的频率？
• C（Controllability）——可控性：驾驶员能避免事故吗？

3.4.1 严重度（S）

等级	描述	示例
S0	无伤害	轻微颠簸，无人员受伤
S1	轻伤	擦伤、轻微扭伤
S2	重伤（可存活）	骨折、内出血
S3	致命伤	死亡、永久性残疾

评估 S 时，我习惯问自己：最坏情况下，这个事故会造成什么后果？不是平均情况，是最坏情况。因为功能安全要覆盖的是「万一出事」的场景。

3.4.2 暴露率（E）

等级	描述	频率参考
E0	几乎不暴露	每年少于 1 次
E1	低暴露	每年几次
E2	中等暴露	每月几次
E3	高暴露	几乎每次驾驶
E4	极高暴露	持续暴露

E 的评估最容易有争议。为什么？因为「场景频率」很难量化。我的做法是：参考实际路测数据。比如「高速行驶」这个场景，如果车辆 70% 的里程都在高速上，那 E 至少是 E3。别靠猜，靠数据。

3.4.3 可控性（C）

等级	描述	示例
C0	完全可控	驾驶员能轻松应对
C1	简单可控	95% 以上驾驶员能避免事故
C2	一般可控	85% 以上驾驶员能避免事故
C3	难以控制	大部分驾驶员无法避免事故

C 的评估，说白了就是：普通人遇到这个情况，能反应过来吗？我见过一个案例——高速上突然爆胎，C 值给了 C2。但实际测试发现，90% 的驾驶员在爆胎后第一反应是猛踩刹车，反而导致车辆失控。后来改成了 C3。所以，C 值不要拍脑袋，最好有模拟器或实车测试数据支撑。

3.5 ASIL 等级确定

有了 S、E、C，查表就能得到 ASIL 等级：

S	E	C1	C2	C3
S1	E1	QM	QM	QM
S1	E2	QM	QM	ASIL A
S1	E3	QM	ASIL A	ASIL B
S1	E4	ASIL A	ASIL B	ASIL C
S2	E1	QM	QM	ASIL A
S2	E2	QM	ASIL A	ASIL B
S2	E3	ASIL A	ASIL B	ASIL C
S2	E4	ASIL B	ASIL C	ASIL D
S3	E1	ASIL A	ASIL B	ASIL C
S3	E2	ASIL B	ASIL C	ASIL D
S3	E3	ASIL C	ASIL D	ASIL D
S3	E4	ASIL D	ASIL D	ASIL D

QM 表示只需质量管理，不需要功能安全开发流程。ASIL A 到 D，要求逐级递增。

3.6 HARA 整体流程

下面这张图总结了 HARA 的完整流程：

3.7 常见误区与避坑

做了这么多年 HARA，我总结几个常见坑：

• 场景不够全——只分析正常驾驶，忽略停车、充电、维护等场景。我见过一个项目，充电桩的通信失效没分析，结果充电过程中 SOC 显示错误，导致电池过充。
• S/E/C 评估太主观——没有数据支撑，全靠「我觉得」。建议至少用实车数据、事故统计、模拟器测试来校准。
• 危害事件定义太模糊——「车辆失控」这种描述要不得。失控的具体表现是什么？撞什么？速度多少？越具体越好。
• ASIL 等级一刀切——整个系统都给 ASIL D，成本爆炸。合理的做法是：分解到功能、分解到场景，该 QM 的 QM，该 D 的 D。