第2章：危险与风险分析：HARA方法、风险等级评估、安全目标的制定

2.1 为什么HARA是功能安全的基石？

说实话，我刚入行那会儿，觉得HARA就是个走形式的文档工作。直到有一次，我在一个ADAS项目中，因为漏掉了一个危险场景，差点导致项目延期三个月。嗯，从那以后，我再也不敢小看HARA了。

HARA，全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：

• 什么东西会坏？——识别潜在的危险事件
• 坏了会怎样？——评估风险等级
• 怎么防止它坏？——制定安全目标

你想想看，如果连车上的刹车系统在什么情况下会失效都搞不清楚，后面的安全设计根本无从谈起。我个人习惯，在项目启动的第一周，就把HARA做完。哪怕需求文档还不完整，也要先做一轮初步分析。

2.2 HARA的四个步骤

我在项目中总结了一套HARA的实操流程，一共四步。每一步都有坑，我一个个说。

步骤一：功能定义与场景分析

首先，你得搞清楚系统到底要干什么。比如一个电动助力转向系统，它的功能是「根据驾驶员转向输入，提供助力扭矩」。

但光有功能描述不够。你得想：在什么场景下，这个功能会出问题？

• 正常驾驶场景：城市道路、高速、雨雪天气
• 故障场景：传感器失效、电源掉电、通信中断
• 极端场景：驾驶员误操作、系统过载

我记得有个项目，团队只分析了正常驾驶场景，结果忽略了「车辆在冰雪路面行驶时，转向助力突然消失」这个危险。后来测试时发现了，不得不返工。所以，场景分析一定要全面。

步骤二：危险事件识别

这一步，我们要找出「功能失效」和「危险场景」的组合。常用的方法是HAZOP（危险与可操作性分析），或者直接基于经验头脑风暴。

举个例子，对于转向系统：

功能	失效模式	危险场景	危险事件
提供助力扭矩	助力突然消失	高速行驶中	驾驶员无法转向，车辆偏离车道
提供助力扭矩	助力过大	低速泊车	方向盘突然打偏，碰撞障碍物
提供助力扭矩	非预期助力	直道行驶	车辆突然转向，引发事故

这里要注意：同一个失效模式，在不同场景下，危险程度完全不同。比如助力消失，在高速上可能是致命的，但在低速泊车时风险就低很多。

步骤三：风险等级评估（ASIL等级）

这是HARA里最核心的一步。ISO 26262定义了三个参数来评估风险：

• S（Severity）：严重度——人员受伤的严重程度
• E（Exposure）：暴露概率——危险场景发生的频率
• C（Controllability）：可控性——驾驶员能否避免伤害

每个参数分4个等级（S0-S3, E0-E4, C0-C3），组合起来得到ASIL等级（A、B、C、D）。ASIL D是最严格的，比如刹车系统；ASIL A相对宽松，比如车窗升降。

评估C值（可控性）时，有个常见的误区：不要假设驾驶员是完美的。我曾经见过一个项目，评估转向失效的可控性时，认为「驾驶员可以握紧方向盘」。但实际情况是，在高速上突然失去助力，很多驾驶员会惊慌失措。所以，C值要往严了评。

步骤四：制定安全目标

安全目标，就是一句话：「系统必须避免XXX危险事件发生」。每个危险事件对应一个安全目标，并且要分配ASIL等级。

比如：

• 安全目标1：转向助力不得在高速行驶中突然消失（ASIL D）
• 安全目标2：转向助力不得在低速泊车时突然增大（ASIL B）

安全目标要写得具体、可验证。别写「系统要安全」这种废话。我一般会加上时间要求，比如「在故障发生后100ms内，系统必须进入安全状态」。

2.3 HARA的核心逻辑图

下面这张图，是我自己总结的HARA核心逻辑。你看一遍，基本就明白整个流程了。

2.4 常见问题与避坑指南

做HARA这么多年，我踩过的坑不少。挑几个典型的说说：

2.5 总结

HARA是功能安全的第一步，也是最关键的一步。它决定了后续所有安全设计的输入。说白了，HARA做得好，后面的工作就顺；HARA做得糙，后面全是坑。

我个人建议，每个项目至少做两轮HARA：第一轮在概念阶段，快速识别主要风险；第二轮在详细设计阶段，补充遗漏的场景。中间如果需求有变更，随时更新。

嗯，这一章就到这里。记住：安全不是测试出来的，而是从HARA开始设计出来的。