第3章危害分析与风险评估（HARA）

3. 危害分析与风险评估（HARA）

好，咱们进入功能安全里最核心的一步——HARA。说实话，我见过不少团队，一上来就急着写安全需求，结果做到一半发现漏了关键场景，回头再补HARA，那叫一个痛苦。所以我的习惯是：HARA做得越扎实，后面的路就越顺。

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

我习惯把HARA比作「给自动驾驶系统做体检」。你不能光说「这车可能撞人」，你得说清楚：在什么路上、什么速度、什么天气下，撞了人会怎样。嗯，这就是场景定义的重要性。

核心原则：HARA不是一次性的。每次系统功能变更、新增ODD场景，都得重新跑一遍。我曾经在一个项目中，因为没及时更新HARA，导致后期安全评审被卡了两个月。

场景定义是HARA的起点。你想想看，如果连「车在什么情况下会出事」都没想清楚，后面的分析全是空中楼阁。

我一般把场景拆成三个维度：

举个例子，我在做某个L3级高速领航项目时，团队一开始只考虑了「前车急刹」这种典型场景。后来我坚持加上了「施工路段锥桶突然出现」的场景——结果发现，这个场景下的危害严重程度比前车急刹高得多。

我的小技巧：场景定义时，多拉上系统工程师、测试工程师一起 brainstorm。一个人想不全的，三个臭皮匠顶个诸葛亮。

危害识别呢，就是找出「系统在什么故障下会导致危险事件」。比如：

这里要注意：危害识别要基于功能，而不是基于具体实现。你不需要一开始就纠结「是摄像头坏了还是雷达坏了」，先问「如果感知不到行人，会怎样？」

好，场景和危害都列出来了。接下来就是给每个危害「打分」。ISO 26262给了三个维度：

参数	全称	含义	等级（0~3）
S	Severity	危害的严重程度	S0（无伤害）~ S3（致命）
E	Exposure	场景发生的概率	E0（几乎不）~ E4（非常高）
C	Controllability	驾驶员/系统能否控制	C0（完全可控）~ C3（几乎不可控）

我见过很多新手工程师，一上来就给S3、E4、C3，结果ASIL D满天飞。其实没必要。你想想看，如果某个场景一年都遇不到一次（E1），就算危害再大，ASIL等级也不会太高。

避坑指南：我曾经在一个项目中，把「高速上行人突然横穿」的E值打到了E3。后来被安全审计官怼了：「你告诉我，高速上行人横穿的概率有多高？」——确实，这种场景E值给到E1都算高了。所以，E值的评估一定要基于真实数据，别拍脑袋。

有了S、E、C三个值，ASIL等级就可以查表得到了。ISO 26262 Part 3里有个标准矩阵：

当然，这只是简化版。实际项目中，组合情况多得很。我的做法是：先按最坏情况给一个初步ASIL，然后看有没有合理的「减轻措施」可以降级。比如，如果系统有冗余感知，那C值可能可以从C3降到C2。

关键点：ASIL等级不是越高越好。ASIL D意味着你要做大量的验证、测试、冗余设计，成本翻倍都不止。所以，合理的ASIL分配，是功能安全工程师的核心能力。

下面这张图，是我自己总结的HARA核心逻辑。每次做新项目，我都会先对着这张图捋一遍思路：

你看，整个流程是线性的：从功能定义出发，到场景和危害识别，再到风险参数打分，最后推导出ASIL等级，输出安全目标。每一步都环环相扣。

我的经验：HARA文档写完后，一定要找不同角色的人做评审。系统工程师看场景全不全，安全工程师看参数合不合理，测试工程师看可不可测。我曾经有一次，评审会上被测试同事问「你这个场景怎么复现？」——结果发现场景定义里少了关键的环境参数。所以，多一个人看，就多一双眼睛。

好了，HARA这部分就聊到这儿。记住：HARA不是走过场，它是整个功能安全工程的基石。你花在HARA上的每一分钟，都会在后面省下十倍的时间。