2. 危害分析与风险评估(HARA)：HARA方法论、运行场景定义、危害识别、风险分类与ASIL等级确定

好，咱们进入功能安全里最核心、也是最磨人的一个环节——HARA。

说实话，我见过不少团队，一上来就急着写安全需求。结果呢？写到一半发现漏了关键场景，或者ASIL等级定得太低，后期改得想哭。HARA这一步，说白了就是给系统做一次全面的「体检」。你跳过了它，后面全是坑。

2.1 HARA方法论：别把它当成走过场

HARA的全称是 Hazard Analysis and Risk Assessment。它的目标很明确：找出系统在「不正常」的时候，会不会对人造成伤害。

我个人习惯把HARA分成四个步骤：

1. 定义运行场景——车在哪儿开？什么天气？什么路况？
2. 识别危害——系统哪个功能出问题，会导致危险？
3. 评估风险——这个危险发生的概率高不高？后果严不严重？
4. 确定ASIL等级——根据风险，给每个危害定个「安全等级」。

你可能会问：「这不就是FMEA吗？」嗯，有点像，但不一样。FMEA关注的是「功能失效」，而HARA关注的是「危害事件」——也就是失效之后，对人造成的实际伤害。

2.2 运行场景定义：场景不对，分析白费

这一步，我见过太多人翻车了。

举个例子，你分析自动紧急制动（AEB）的HARA。如果你只考虑「晴天、直道、前车静止」这种理想场景，那分析出来的ASIL等级可能只有A或B。但实际中，AEB在「雨天、弯道、前车突然急刹」的场景下失效，后果可能是致命的。

所以，场景定义要覆盖三个维度：

• 环境条件：白天/黑夜、晴天/雨雪/雾、城市/高速/乡村
• 车辆状态：直行/转弯/变道、低速/中速/高速、空载/满载
• 交通参与者：行人、自行车、摩托车、其他车辆、动物

我个人习惯用「场景矩阵」来梳理。比如这样：

场景编号	道路类型	天气	光照	车速	目标物
S-001	城市道路	晴天	白天	30 km/h	行人横穿
S-002	高速公路	雨天	夜间	100 km/h	前车急刹
S-003	乡村道路	雾天	黄昏	50 km/h	自行车

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

场景定义好了，接下来就是找危害。

危害识别，说白了就是问一个问题：「如果这个功能在某个场景下失效了，会发生什么？」

比如，对于「自适应巡航控制（ACC）」功能：

• 失效模式：ACC突然加速到最大设定速度
• 危害事件：在高速上，车辆突然加速，导致追尾前车
• 伤害：车内人员受伤或死亡

这里要注意，危害识别要区分「失效」和「危害」。失效是系统内部的事，危害是系统对外界造成的影响。

我曾经在一个项目里，团队把「传感器故障」直接当成了危害。这不对。传感器故障是失效，它导致的「车辆无法检测到行人」才是危害。

2.4 风险分类与ASIL等级确定：给风险打个分

危害找到了，接下来就是给每个危害定个「风险等级」。ISO 26262里用的是ASIL（Automotive Safety Integrity Level），从A到D，D是最严格的。

ASIL的确定，取决于三个参数：

• S（Severity）：伤害的严重程度。S0是无伤害，S3是致命伤害。
• E（Exposure）：场景发生的概率。E0是几乎不可能，E4是经常发生。
• C（Controllability）：驾驶员能否控制住局面。C0是完全可以控制，C3是几乎无法控制。

然后查表：

S	E	C	ASIL
S2	E3	C2	B
S3	E4	C3	D
S1	E2	C1	A

举个例子：

还是那个ACC突然加速的场景。假设：

• S：高速追尾，大概率致命 → S3
• E：高速场景很常见 → E4
• C：突然加速，驾驶员很难反应 → C3

查表，ASIL = D。嗯，这个结果很合理。

2.5 我的HARA实战经验

最后，分享几个我踩过的坑：

• 别把ASIL定得太低。 我见过有人为了省成本，把S3硬说成S2。结果审核的时候被安全专家怼回来，重新做一遍HARA，浪费了两个月。
• 场景要写清楚。 别写「城市道路」，要写「双向四车道、有红绿灯、有行人横穿、限速60km/h」。越具体，后面的分析越靠谱。
• 团队评审很重要。 HARA不是一个人能搞定的。我一般会拉上系统工程师、软件工程师、测试工程师，甚至项目经理，一起过一遍。每个人视角不同，能发现很多盲点。

嗯，HARA这部分就讲到这里。下一章，我们会聊聊怎么把HARA的结果转化成「安全目标」和「功能安全概念」。那一步，才是真正开始设计安全架构的时候。