4. 危害分析与风险评估（HARA）：把“可能出事”变成“必须解决”

各位工程师，咱们今天聊一个核心话题——HARA。说实话，我刚入行那会儿，觉得HARA就是走个过场，填几张表就完事了。直到有一次，我在一个项目里漏掉了一个“低速行人碰撞”的场景，结果测试阶段差点出事故。从那以后，我再也不敢小看HARA了。

HARA的全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车会不会出事？出事了多严重？我们该怎么防？

4.1 HARA的目的：不是为了填表，是为了保命

HARA的目的很直接——找出所有可能因为系统故障导致的危害，然后给每个危害定个“危险等级”。这个等级就是ASIL（汽车安全完整性等级），从A到D，D最要命。

我个人习惯把HARA比作“排雷”。你想想看，一辆车上路，面对的是各种路况、天气、驾驶员行为。如果某个电子控制单元（ECU）突然抽风，比如刹车信号丢了、转向助力没了，后果可能是车毁人亡。HARA就是把这些“雷”一个个标出来，然后决定哪些雷必须拆，哪些可以绕过去。

4.2 HARA的流程：五步走，一步不能少

HARA的流程，我总结为五步。每一步都有坑，我一个个说。

1. 定义运行场景与操作模式——车在什么情况下跑？高速？市区？倒车？充电？
2. 危害识别——系统出故障了，会导致什么危险？比如刹车失灵、转向卡死。
3. 危害分类——这个危害有多严重？暴露概率高不高？驾驶员能不能救回来？
4. ASIL等级确定——根据严重度（S）、暴露概率（E）、可控性（C）三个参数，查表得出ASIL。
5. 安全目标定义——针对每个危害，写一条“安全目标”，比如“刹车信号丢失后，必须在100ms内进入安全状态”。

嗯，这里要注意：安全目标不是HARA的直接输出，但HARA是安全目标的前提。没有HARA，你连安全目标该写多严都不知道。

4.3 运行场景与操作模式：别漏掉“奇葩”情况

运行场景，就是车在实际使用中可能遇到的所有情况。操作模式，就是系统的工作状态——上电、运行、休眠、故障模式等等。

我见过最坑的项目，是有人只考虑了“正常行驶”场景，完全没考虑“倒车入库”和“坡道起步”。结果呢？倒车时雷达失效，撞了。所以，场景要覆盖全。

常见的场景维度包括：

• 道路类型：高速、城市、乡村、停车场、隧道
• 环境条件：白天、夜晚、雨、雪、雾、强光
• 车辆状态：静止、低速、中速、高速、倒车、转弯
• 驾驶员行为：正常驾驶、分心、疲劳、紧急操作
• 系统模式：正常模式、降级模式、诊断模式、刷写模式

4.4 危害识别与分类：从“故障”到“危害”的跳跃

危害识别，不是让你列故障清单，而是让你想：这个故障，在某个场景下，会导致什么后果？

举个例子：

• 故障： 转向角传感器输出错误值。
• 场景： 车辆在高速公路上以120km/h行驶。
• 危害： 车辆意外转向，偏离车道，可能与其他车辆碰撞。

你看，同一个故障，在不同场景下，危害可能完全不同。如果是在停车场低速挪车，危害就小得多。

危害分类，就是用三个参数来量化：

参数	含义	等级范围
S（Severity）	对人员伤害的严重程度	S0（无伤害）~ S3（生命危险）
E（Exposure）	危害场景发生的概率	E0（几乎不）~ E4（非常高）
C（Controllability）	驾驶员能否避免危害	C0（完全可控）~ C3（几乎不可控）

我曾经在一个项目中，遇到一个危害：刹车助力突然失效。S等级很高（S3），因为可能追尾。E等级呢？助力失效的概率其实不高，但考虑到每天开车都会用到刹车，E我给到了E3。C等级呢？驾驶员如果反应快，还能用力踩刹车，但效果差很多，所以C我给C2。最后查表，ASIL C。

4.5 ASIL等级确定方法：查表，但别死查表

ASIL等级由S、E、C三个参数组合决定。ISO 26262给了一张表，直接查就行。

S	E	C	ASIL
S1	E1	C1	ASIL A
S1	E2	C2	ASIL B
S2	E2	C2	ASIL C
S3	E3	C2	ASIL D
S3	E4	C3	ASIL D
...（完整表格见ISO 26262-3:2018 Table 1）

但我要提醒你：ASIL不是数学题。有时候S、E、C的取值会有争议。比如，你觉得C是C2，我觉得是C3。怎么办？我的建议是：取保守值。安全设计，宁可过，不可不及。

另外，如果三个参数中有一个是S0、E0或C0，那这个危害就是QM（质量管理），不需要按功能安全流程处理。但别高兴太早——QM不代表可以不管，只是说不需要ASIL级别的开发流程。

4.6 HARA的常见误区：我踩过的坑

做HARA这么多年，我总结了几条血泪教训：

• 场景不全： 只考虑“正常驾驶”，忽略“维修模式”、“充电模式”、“拖车模式”。
• 危害描述模糊： 写“系统故障”而不是“刹车助力丢失导致制动距离增加”。要具体。
• ASIL定级拍脑袋： 没有数据支撑，全靠“我觉得”。建议拉上功能安全经理、系统工程师一起评审。
• 忽略组合危害： 两个故障同时发生，可能比单个更危险。比如“转向失效+制动失效”。

4.7 HARA核心流程框架图

下面这张图，是我自己画的一个HARA流程框架。你看一眼，就能明白整个逻辑。

这张图把HARA的五个步骤串起来了。你从“定义场景”开始，一步步往下走，最后输出安全目标。每一步都有输入和输出，不能跳步。

好了，HARA的内容就讲到这里。记住，HARA不是一次性的工作。当系统设计变更、场景新增、或者发现新的故障模式时，HARA要重新做。安全，永远在路上。