📚 课程目录第3章危害分析与风险评估（HARA）基础

3. 危害分析与风险评估（HARA）基础：HARA的目的与流程、运行场景与运行模式分析、危害识别方法

HARA，全称 Hazard Analysis and Risk Assessment。中文叫危害分析与风险评估。

说实话，这是功能安全概念阶段最核心的一步。没有它，你后面所有的安全机制、安全目标都是空中楼阁。我见过不少项目，上来就拍脑袋定 ASIL 等级，结果评审时被怼得哑口无言。嗯，HARA 就是用来堵住这些质疑的。

简单说，HARA 就做三件事：

你想想看，如果连危险都找不全，后面的安全设计就是瞎忙活。我个人习惯，在 HARA 阶段至少花 30% 的时间在危害识别上，而不是急着去算 ASIL。

核心产出：危害事件清单 + 对应的 ASIL 等级。这是后续定义安全目标的输入。

ISO 26262 没有规定你必须用什么工具，但流程是固定的。我把它拆成 5 步：

下面这张图把流程串起来了，你可以对照着看。

这一步很多人会忽略，觉得差不多就行。但我告诉你，这是 HARA 翻车最多的地方。

运行场景指的是车辆在什么环境下运行。比如：

运行模式指的是系统本身处于什么状态。比如：

为什么要区分？因为同一个故障，在不同场景下后果完全不同。举个例子：

故障	场景	后果	ASIL
转向助力丢失	高速行驶	车辆失控，严重碰撞	ASIL D
转向助力丢失	低速泊车	驾驶员费力，但可控	ASIL A

看到了吧？同一个故障，场景一变，ASIL 等级天差地别。我建议你做一个场景矩阵，把所有的运行场景和模式组合列出来，再逐个分析。

我的经验：场景分析时，一定要拉上系统工程师和测试工程师一起 brainstorm。一个人想不全的。我曾经在一个项目中，漏掉了「车辆在隧道中 GPS 信号丢失」这个场景，结果导致后续的定位安全目标定低了，后期不得不返工。

危害识别说白了就是「找茬」。但找茬也要有方法，不能瞎找。

常用的方法有这几种：

头脑风暴（Brainstorming）——最常用，但容易漏。适合早期快速扫一遍。
检查表法（Checklist）——基于历史项目经验整理。效率高，但依赖清单质量。
HAZOP（Hazard and Operability Study）——用引导词（如：无、多、少、反向等）系统性地分析。我比较推荐这个方法，因为它结构化，不容易漏。
FMEA（Failure Mode and Effects Analysis）——从功能失效出发，分析影响。适合后期细化。

我个人习惯，在概念阶段先用 HAZOP 做一轮系统性的危害识别，再用头脑风暴补充一些「奇葩场景」。比如：

HAZOP 示例（针对「加速」功能）：

你看，一个简单的「加速」功能，用 HAZOP 就能挖出 4 种不同的危害。这就是方法的价值。

避坑指南：我曾经见过一个团队，危害识别只做了 2 个小时，列了 10 条危害就觉得够了。结果评审时被安全专家问住了——「如果电池在低温下内阻增大，导致供电电压跌落，你们考虑了吗？」全场沉默。所以，危害识别一定要给够时间，至少 1-2 天，而且要分多次迭代。

识别出危害后，要把它写成「危害事件」。格式是固定的：

[故障] + [运行场景] + [后果]

举个例子：

为什么要写这么细？因为后面的 Severity、Exposure、Controllability 打分，全靠这个描述。描述不清，打分就是拍脑袋。