4、危害分析与风险评估（HARA）：从场景到风险的实战拆解
大家好，我是你们的老朋友。今天我们来聊聊HARA——危害分析与风险评估。说实话，这是整个SOTIF落地过程中最考验「功力」的一步。我见过不少团队，前面场景分析做得漂漂亮亮，一到HARA就卡壳，要么风险等级评得乱七八糟，要么漏掉关键危害。嗯，今天我就把这块掰开揉碎了讲清楚。
4.1 HARA基础概念：到底在分析什么？
HARA，全称Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 什么东西会坏？（危害识别）
- 在什么情况下坏？（场景关联）
- 坏了有多严重？（风险评级）
我个人习惯把HARA比作「交通警察查酒驾」——你得先知道哪些行为是危险的（危害），然后看什么路段、什么时间容易出事（场景），最后判断撞了人后果有多重（风险）。
核心要点：HARA不是一次性的工作。随着系统设计迭代，场景库更新，HARA需要反复做。我见过最惨的项目，就是HARA做完就扔一边，结果测试时发现新场景，回头一看——危害根本没覆盖到。
4.2 场景分析与危害识别：从「可能出事」到「一定会出事」
场景分析是HARA的「弹药库」。没有场景，危害就是空谈。你想想看，一个自动驾驶系统在高速上「误刹车」和在小区里「误刹车」，危害能一样吗？
我建议按以下步骤来：
- 提取场景要素：从ODD中抠出关键参数——道路类型、天气、交通参与者、自车状态。
- 识别功能异常：系统该做的没做（漏报），不该做的做了（误报），或者做得不对（时序/精度问题）。
- 关联危害事件：把功能异常放到具体场景里，看会导致什么后果。比如「AEB在雨天误触发」→「后车追尾」。
避坑指南：我曾经犯过一个错误——只分析「典型场景」，忽略了「边界场景」。结果测试时发现，系统在隧道出口处因为光照突变导致感知丢失，这个场景在HARA里根本没出现。后来我学乖了，场景分析一定要覆盖ODD的边界条件。
这里我画了一张图，帮你理清HARA的整体逻辑：
4.3 风险等级评定：S/E/C 三要素详解
风险评级是HARA的「判决环节」。ISO 26262和SOTIF都用了S/E/C框架，但SOTIF里更强调场景的多样性。我直接上干货：
4.3.1 S（Severity）—— 严重度
严重度看的是「最坏情况下」的伤害程度。注意，不是平均情况，是最坏情况。为什么？因为功能安全要兜底。
| 等级 | 描述 | 典型场景举例 |
|---|---|---|
| S0 | 无伤害 | 系统误报警，但驾驶员及时接管 |
| S1 | 轻伤（可恢复） | 低速碰撞，轻微擦伤 |
| S2 | 重伤（不可恢复） | 高速追尾，骨折或内伤 |
| S3 | 致命 | 行人碰撞，或高速多车连环撞 |
注意：S评级不能只看「系统本身」，要看「系统失效后与场景交互的结果」。举个例子，AEB在高速上误触发，如果后车是大货车且跟车距离近，S3没跑。但如果后车是智能车且距离远，可能只有S1。所以场景细节决定S等级。
4.3.2 E（Exposure）—— 暴露度
暴露度看的是「这个场景出现的频率」。说白了，就是「这事儿多大概率碰上」。
| 等级 | 描述 | 典型场景举例 |
|---|---|---|
| E0 | 几乎不出现 | 极地暴风雪中自动驾驶 |
| E1 | 很少出现（<1%运行时间） | 夜间乡间小路会车 |
| E2 | 偶尔出现（1%~10%） | 雨天城市道路行驶 |
| E3 | 经常出现（10%~50%） | 白天城市拥堵路段 |
| E4 | 持续出现（>50%） | 高速巡航（L2/L3常用场景） |
我个人习惯，E评级一定要结合ODD的统计数据。比如你的车主要在长三角跑，那「雨雾天气」的E值就得调高。我见过一个项目，把「雪地场景」的E值评得很低，结果车卖到东北后，雪地场景成了主要投诉点——这就是典型的数据没对齐。
4.3.3 C（Controllability）—— 可控度
可控度看的是「驾驶员或周围交通参与者能不能避开危险」。这是SOTIF里最容易被低估的一项。
| 等级 | 描述 | 典型场景举例 |
|---|---|---|
| C0 | 完全可控 | 系统提示「请接管」，驾驶员有3秒以上反应时间 |
| C1 | 简单可控 | 系统缓慢减速，驾驶员有1~3秒反应时间 |
| C2 | 一般可控 | 系统突然转向，但驾驶员能通过紧急操作避免碰撞 |
| C3 | 不可控 | 系统在高速上突然急刹，后车无法避让 |
避坑指南：我曾经评估一个「车道保持失效」的场景，觉得驾驶员能轻松接管，给了C1。结果实测发现，系统在弯道中突然退出，驾驶员根本来不及反应——因为方向盘力矩突变，人需要时间适应。后来我把这类场景统一提到C2。记住：可控度不是「理论上能控」，而是「实际中大概率能控」。
4.4 综合评级：从S/E/C到ASIL/风险等级
有了S/E/C三个值，就可以查表得到风险等级了。ISO 26262里是查ASIL表，SOTIF里则更灵活——通常用「风险矩阵」来判定是否需要进一步安全措施。
举个例子：
- 场景：高速上AEB误触发（后车跟车距离近）
- S：3（致命风险）
- E：3（经常出现，高速场景占比高）
- C：2（驾驶员有一定反应时间，但后车难控）
- 综合：高风险，必须设计安全机制（比如增加误触发抑制逻辑，或提高触发阈值）
再比如：
- 场景：停车场内自动泊车误加速（周围无人）
- S：1（轻伤，低速）
- E：2（偶尔出现）
- C：1（驾驶员可随时刹车）
- 综合：低风险，可接受，但建议监控
核心原则：风险评级不是「算分游戏」。我见过有人把S/E/C三个数乘起来得到一个「风险值」，然后一刀切——超过某个值就改，低于就不改。这种做法很危险。因为S/E/C本身是离散的，乘出来的值没有物理意义。正确的做法是：每个组合都要单独讨论，结合工程判断。
4.5 实战建议：HARA文档怎么写才不「翻车」？
最后，我分享几个写HARA文档的实战经验：
- 场景编号要唯一：每个危害-场景组合给一个ID，方便追溯。我习惯用「HARA-功能缩写-序号」的格式。
- S/E/C的赋值理由要写清楚：别只写个数字，要写「为什么是S3不是S2」。比如「因为场景中后车为大货车，制动距离长，碰撞速度>80km/h，故S3」。
- 风险接受准则要提前定：哪些等级必须改，哪些可以接受，团队内部要达成一致。否则评审时吵半天。
- HARA要跟测试用例挂钩：每个高风险场景，都应该有对应的测试用例来验证安全措施的有效性。
好了，HARA这块就讲到这里。内容不少，但核心就一句话：场景是土壤，危害是种子，风险是果实——土壤不对，种子再好也白搭。 希望大家在实际项目中，能把HARA做扎实，别让它变成「纸面功夫」。
公众号:蓝海资料掘金营，微信deep3321