3、HARA分析流程：场景识别、危害识别、风险评估、安全目标定义

好，咱们直接进入正题。HARA，全称是 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车会出什么事？后果多严重？我们该怎么办？

我做了这么多年功能安全，见过太多团队一上来就写安全目标。结果呢？写到一半发现场景漏了，危害没识别全，回头再补。浪费时间不说，还容易出漏洞。所以，咱们一步步来。

3.1 场景识别：把车放在真实世界里

场景识别是HARA的起点。你不能只想着「车在跑」，得想「车在什么情况下跑」。

我个人习惯把场景拆成三块：

• 运行场景：高速、城市、乡村、隧道、停车场……
• 环境条件：白天、黑夜、雨、雪、雾、强光……
• 车辆状态：直行、转弯、变道、加速、减速、静止……

举个例子。你分析一个自动紧急制动（AEB）系统。场景不能只写「前方有车，AEB触发」。你得想：

• 如果是在湿滑路面上呢？
• 如果前方是一辆静止的摩托车呢？
• 如果系统误识别了路边的广告牌呢？

3.2 危害识别：找到那个「万一」

场景有了，接下来就是找危害。危害是什么？是系统功能异常或失效，导致对人的伤害。

这里有个常见的误区：很多人把「故障」当成了「危害」。比如「传感器失效」是故障，不是危害。危害应该是「传感器失效导致无法检测障碍物，造成碰撞」。

我建议用这个思路来梳理：

1. 系统在某个场景下，本该做什么？
2. 如果它没做，或者做错了，会发生什么？
3. 这个「发生什么」是否会导致人员受伤？

举个例子，还是AEB：

场景	功能异常	危害
高速跟车，前车急刹	AEB未触发	追尾碰撞，乘员受伤
城市路口，行人横穿	AEB误触发	急刹导致后车追尾，乘员颈部受伤
隧道内，光线突变	AEB误识别障碍物	非必要急刹，乘员失衡摔倒

3.3 风险评估：给危害「打分」

危害找到了，但并不是所有危害都需要同等对待。风险评估就是给每个危害定个「危险等级」。ISO 26262 里用的是三个参数：

• S（Severity）：伤害的严重程度。S0（无伤害）到 S3（致命）。
• E（Exposure）：场景发生的概率。E0（几乎不可能）到 E4（非常高）。
• C（Controllability）：驾驶员或其他人员能否控制住局面。C0（可控）到 C3（难以控制）。

然后查表，得到 ASIL（Automotive Safety Integrity Level） 等级：QM、ASIL A、ASIL B、ASIL C、ASIL D。

你想想看，一个危害如果 S3（致命）、E4（经常发生）、C3（无法控制），那妥妥的 ASIL D，最高等级。反过来，如果 S1（轻伤）、E1（很少发生）、C1（容易控制），可能 QM 就够了。

这里有个坑。我见过有人把 E 和 C 搞混。E 是「场景发生的概率」，C 是「出事后能不能救回来」。举个例子：

• 「在高速上爆胎」——E 不高（爆胎概率低），但 C 很高（爆胎后很难控制）。
• 「在停车场倒车撞到柱子」——E 很高（天天倒车），但 C 很低（速度慢，能刹住）。

别搞混了，不然 ASIL 等级会偏。

3.4 安全目标定义：把「不要出事」变成「必须做到」

最后一步，也是最关键的一步：把每个危害转化成安全目标（Safety Goal）。

安全目标长什么样？它必须是一个可验证的、顶层的安全要求。格式一般是：

「系统应避免 [危害描述]，在 [场景] 下。」

并且要带上 ASIL 等级。

举个例子：

危害	ASIL	安全目标
高速跟车时AEB未触发导致追尾	ASIL C	在高速跟车场景下，AEB系统应能在前车急刹时触发制动，避免或减轻碰撞（ASIL C）
城市路口AEB误触发导致后车追尾	ASIL B	在城市路口场景下，AEB系统不应在无真实碰撞风险时触发制动（ASIL B）

嗯，到这里，HARA 的四个步骤就走完了。你可能会问：「这就完了？」

不，这只是开始。安全目标定义出来后，你还要做 FSC（功能安全概念）、TSC（技术安全概念），然后才是具体的开发和测试。但那是后面章节的事了。

最后说一句：HARA 不是一次性工作。随着项目推进，你可能会发现新的场景、新的危害。别怕，回头更新 HARA 文档就好。我见过最夸张的项目，HARA 迭代了 7 个版本。很正常，安全是迭代出来的。