4、危害分析与风险评估（HARA）：HARA的目的、HARA的步骤、危害识别、风险评估（严重度、暴露率、可控性）、安全目标定义
好，咱们进入功能安全最核心的一步——HARA。
说实话，很多工程师觉得HARA就是填表格、走流程。但我做了这么多年项目，可以负责任地告诉你：HARA的质量，直接决定了整个功能安全开发的成败。你想想看，如果危害都没找全，后面的安全措施做得再好，也是白搭。
4.1 HARA的目的：我们为什么要做这件事？
HARA的全称是Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。
它的目的其实很简单：找出车辆在运行过程中可能出现的危害，评估这些危害的风险等级，然后为每个危害制定安全目标。
我个人习惯把HARA比作「排雷」——在系统还没出问题之前，先把可能炸的雷找出来，然后决定怎么处理它。
核心目的总结：
- 识别所有与功能相关的潜在危害
- 评估每个危害的风险等级（ASIL等级）
- 为每个危害定义安全目标（Safety Goal）
4.2 HARA的步骤：一步一步来，别跳步
HARA的流程，我建议严格按照ISO 26262第3部分的要求来走。跳步？我吃过这个亏，后面会讲。
标准的HARA步骤包括：
- 功能定义——搞清楚系统是干什么的
- 危害识别——找出所有可能的危害事件
- 风险评估——评估严重度(S)、暴露率(E)、可控性(C)
- 安全目标定义——为每个危害制定安全目标
嗯，这里要注意：功能定义是HARA的前提。如果功能都没定义清楚，后面的危害识别就是瞎猜。
4.3 危害识别：找全，别漏
危害识别，说白了就是头脑风暴。但这不是随便想想，而是有方法论的。
我常用的方法包括：
- HAZOP分析（危险与可操作性分析）——用引导词来触发思考
- FMEA（失效模式与影响分析）——从失效模式反推危害
- 头脑风暴会议——拉上系统、软件、硬件、测试的人一起聊
举个例子，一个电子助力转向系统（EPS），它的危害可能包括：
- 非预期的转向助力输出（比如突然打方向）
- 转向助力丢失（方向盘变重）
- 转向角度错误（方向盘转了但车轮没转对）
我的经验：危害识别时，一定要考虑车辆运行场景。同一个失效，在高速上和停车场里，风险等级完全不同。我曾经有个项目，团队只考虑了城市工况，结果高速场景下的危害全漏了……嗯，后来补了三个月。
4.4 风险评估：严重度、暴露率、可控性
风险评估是HARA中最「技术」的部分。我们需要对每个危害事件，评估三个参数：
| 参数 | 含义 | 等级范围 |
|---|---|---|
| S（Severity） | 严重度——危害发生时，对人员造成的伤害程度 | S0 ~ S3 |
| E（Exposure） | 暴露率——危害场景发生的概率（车辆运行中的暴露程度） | E0 ~ E4 |
| C（Controllability） | 可控性——驾驶员或其他人员能否控制住危害 | C0 ~ C3 |
这三个参数组合起来，就决定了ASIL等级（Automotive Safety Integrity Level，汽车安全完整性等级）。
ASIL等级判定规则：
ASIL = f(S, E, C)，具体查ISO 26262的表格。
简单说：S越高、E越高、C越低，ASIL等级越高（从ASIL A到ASIL D）。
如果S、E、C中有一个为0，则危害等级为QM（质量管理级，无需功能安全措施）。
举个例子：
还是那个EPS系统，假设我们识别到一个危害：高速行驶时非预期转向助力输出。
- S（严重度）：高速失控可能导致严重伤亡，S = 3
- E（暴露率）：高速行驶是常见场景，E = 3
- C（可控性）：突然转向，普通驾驶员很难控制，C = 3
查表：S3 + E3 + C3 → ASIL D（最高等级）。
避坑指南：我曾经在评估可控性时犯过一个错误——假设「驾驶员反应很快」。结果后来测试发现，在特定场景下（比如雨夜），驾驶员根本来不及反应。所以，可控性评估一定要保守，别高估人的能力。
4.5 安全目标定义：把风险变成可执行的要求
评估完风险，下一步就是定义安全目标。
安全目标，说白了就是一句话：「系统必须避免某某危害」。
但这句话不能太笼统，要具体到可以验证的程度。
比如，针对上面那个EPS的ASIL D危害，安全目标可以定义为：
安全目标：避免在高速行驶时（车速 > 80 km/h）出现非预期的转向助力输出。
ASIL等级：ASIL D
安全状态：切断转向助力，进入手动模式
容错时间间隔：< 100 ms
你看，这个安全目标包含了：
- 触发条件（车速 > 80 km/h）
- 危害描述（非预期转向助力输出）
- ASIL等级（D）
- 安全状态（切断助力，手动模式）
- 容错时间（100 ms内必须响应）
我的习惯：每个安全目标，我都会加一个「安全状态」和「容错时间间隔」。这两个参数，是后面做系统设计和验证的关键输入。没有它们，安全目标就是一句空话。
4.6 总结：HARA做得好，后面少烦恼
HARA是整个功能安全开发的地基。地基没打好，上面盖的房子再漂亮，也是危房。
我个人建议：
- 别赶时间——HARA阶段多花一周，后面可能省下一个月
- 多拉人参与——系统、硬件、软件、测试、甚至市场的人，都叫来一起讨论
- 文档要写清楚——每个危害的S、E、C评估理由，都要记录在案，方便后续追溯
好了，HARA的内容就到这里。下一章，我们会讲功能安全概念（FSC）——如何把安全目标变成具体的技术方案。