第三章 危害分析与风险评估（HARA）：SOTIF场景定义、危害识别方法、风险评估矩阵
HARA，全称是 Hazard Analysis and Risk Assessment。翻译过来就是危害分析与风险评估。
说实话，这是整个 SOTIF 流程里最考验功底的环节。我见过太多团队，上来就对着功能清单猛写危害，结果评审时被问得哑口无言——「你这个场景怎么来的？」「这个严重度凭什么打 S3？」
嗯，这一章我们就把它彻底讲透。
3.1 SOTIF 场景定义：你得先知道「车在哪儿」
危害不是凭空产生的。它一定发生在某个具体的场景里。
什么叫场景？简单说就是：车在什么路上跑、周围有什么、驾驶员在干嘛、天气怎么样。
我个人习惯把场景拆成三个维度：
- 运行场景：高速公路、城市道路、乡村小路、停车场……
- 环境条件：白天/黑夜、晴天/雨雪/大雾、直道/弯道/坡道……
- 动态要素：行人、自行车、其他车辆、动物、施工区域……
核心原则：场景定义要「够用但不冗余」。你不需要穷举所有可能，但必须覆盖高风险的典型场景。
举个例子。我在做某个 L3 级高速公路领航功能时，团队一开始只定义了「晴天直道」和「雨天直道」两个场景。评审时我问了一句：「如果前方有事故车斜停在车道上，而且下着大雨呢？」全场沉默了。
后来我们补了至少 20 个边缘场景，其中 3 个在实车测试中真的触发了系统异常。
我的建议：场景定义阶段，拉上测试工程师和系统工程师一起 brainstorm。一个人想不全的。
3.2 危害识别方法：怎么找到那些「要命」的问题
场景有了，接下来就是找危害。
危害识别，说白了就是回答一个问题：在这个场景下，系统如果出现功能不足或误触发，会导致什么后果？
常用的方法有几种：
- 头脑风暴法：召集专家，对着场景列表逐个过。效率高，但依赖经验。
- 检查表法：基于历史项目或行业标准（如 ISO 21448 附录）的检查项。适合新手团队。
- 结构化分析（如 STPA）：从控制结构出发，分析不安全控制行为。更系统，但耗时。
我个人偏爱「头脑风暴 + 检查表」的组合。先用检查表兜底，再用头脑风暴查漏补缺。
注意：危害识别时，不要只盯着「传感器失效」这种硬件故障。SOTIF 关注的是功能不足——比如摄像头没坏，但逆光时看不清；雷达没坏，但金属护栏反射导致误检。这些才是 SOTIF 的核心。
我曾经在一个项目中，团队花了三周列了 80 多条危害，结果一审查，一半都是「传感器完全失效」——那其实是功能安全（ISO 26262）的范畴。白白浪费了时间。
3.3 风险评估矩阵：Severity, Exposure, Controllability
危害找到了，接下来要评估它的风险等级。SOTIF 用的是经典的三维矩阵：
- Severity（严重度 S）：如果危害发生，对人员造成的伤害程度。
- Exposure（暴露率 E）：这个场景在真实世界中出现的概率。
- Controllability（可控性 C）：驾驶员或其他道路使用者能否避免危害。
三个维度组合，决定这个危害是否需要进一步降低风险。
下面是我常用的评分标准（参考 ISO 21448）：
| 等级 | Severity（严重度） | Exposure（暴露率） | Controllability（可控性） |
|---|---|---|---|
| S0 | 无伤害 | — | — |
| S1 | 轻伤（如擦伤） | — | — |
| S2 | 重伤（如骨折） | — | — |
| S3 | 致命或危及生命 | — | — |
| E1 | — | 极低（如每年一次） | — |
| E2 | — | 低（如每月一次） | — |
| E3 | — | 中（如每周一次） | — |
| E4 | — | 高（如每天一次） | — |
| C1 | — | — | 容易控制（驾驶员有充足时间反应） |
| C2 | — | — | 一般可控（需要驾驶员及时反应） |
| C3 | — | — | 难以控制（反应时间极短或无法干预） |
风险等级判定逻辑：
- 如果 S ≥ S2 且 E ≥ E3 且 C ≥ C2 → 高风险，必须采取措施降低。
- 如果 S = S3 且 E ≥ E2 → 即使 C = C1，也建议降低。
- 其他组合 → 可接受或需进一步分析。
你可能会问：为什么可控性这么重要？
我举个例子。假设系统在高速上突然误刹车，如果后面没车，驾驶员一脚油门就解除了——可控性高，风险低。但如果后面紧跟着一辆大货车，驾驶员根本来不及反应——可控性低，风险极高。
避坑指南：我曾经在评估一个「弯道中车道保持退出」的危害时，把可控性打成了 C1。后来实车测试发现，在曲率半径很小的弯道上，系统突然退出，驾驶员需要 1.5 秒才能接管——而弯道只有 2 秒。最后改成了 C2。所以，可控性一定要结合具体场景的动力学特性来评估，别想当然。
3.4 知识体系总览
下面这张图是我自己整理的 HARA 核心流程。你可以把它当作一个检查清单：
3.5 实战中的几个关键提醒
最后，分享几个我在项目中踩过的坑：
- 别把 HARA 做成一次性活动。系统设计变了、场景变了、甚至法规变了，HARA 都要跟着更新。我见过一个项目，HARA 做完后两年没动过，最后测试时发现一半的危害已经不存在了，又冒出一堆新的。
- Severity 的评分要基于「最坏合理情况」。不是最坏情况（那会导致所有危害都是 S3），也不是平均情况（那会低估风险）。「最坏合理」——比如高速上误刹车，后面有车但距离足够——这个就是合理的最坏。
- 暴露率不要只看「场景频率」，还要看「系统在该场景下的运行时间占比」。比如「夜间暴雨」场景本身频率低，但如果你的车主要在夜间跑长途，那暴露率就得往上调。
- 可控性评估一定要有驾驶员在环测试数据。别光靠拍脑袋。我曾经在一个项目中，工程师认为「系统突然退出」驾驶员肯定能接管，结果实测发现平均接管时间比预期多了 0.8 秒——这个差距足以让可控性从 C1 变成 C2。
最后一句：HARA 不是写文档，是帮团队找到「哪里会出事」。如果你做完 HARA 后，团队对系统的薄弱点有了清晰的共识，那这步就值了。
公众号:蓝海资料掘金营，微信deep3321