4. 危害分析与风险评估（HARA）在SOTIF中的应用
聊到SOTIF，就绕不开HARA。说实话，很多工程师一听到「危害分析」四个字就头大，觉得这是安全工程师的专属活。但我在实际项目中踩过坑之后才发现——HARA不是安全部门的独角戏，而是整个系统团队必须掌握的基本功。
今天我就结合自己的工程经验，聊聊HARA在SOTIF里到底怎么用。嗯，咱们不整那些虚的理论，直接上干货。
4.1 为什么SOTIF需要HARA？
先问一个问题：传统功能安全（ISO 26262）里也有HARA，SOTIF（ISO 21448）为什么还要再做一遍？
原因很简单——两者的关注点完全不同。
- 功能安全HARA：关注的是系统故障（比如传感器坏了、线束断了）导致的危害。
- SOTIF HARA：关注的是系统在没有故障的情况下，因为性能局限或场景复杂导致的危害。
举个例子。我在做AEB项目时遇到过这种情况：摄像头没坏，雷达也没坏，但雨天+逆光+前车突然变道，系统就是没刹住。这不是故障，这是SOTIF问题。传统HARA根本覆盖不到这种场景。
核心观点：SOTIF的HARA，本质上是把「场景」和「性能局限」纳入风险评估的范畴。
4.2 SOTIF HARA的核心流程
我个人习惯把SOTIF的HARA分成四个步骤。你想想看，其实跟做饭差不多——先备菜（定义场景），再切菜（识别危害），然后试吃（评估风险），最后调整配方（确定可接受标准）。
- 场景定义与触发条件分析
- 危害识别与分类
- 风险评估（严重度、暴露率、可控性）
- 风险可接受性判断
下面我一个个展开说。
4.3 场景定义——HARA的基石
这一步做不好，后面全是白搭。我在项目中见过太多团队，上来就拍脑袋写危害，结果评审时发现场景根本不对。
SOTIF的场景定义，我建议从三个维度入手：
| 维度 | 内容 | 举例 |
|---|---|---|
| 环境条件 | 光照、天气、道路类型、交通密度 | 夜间、暴雨、城市快速路、拥堵 |
| 系统状态 | 传感器配置、算法模式、执行器能力 | 单摄像头模式、L2级辅助、制动衰退 |
| 行为交互 | 自车行为、目标物行为、V2X信息 | 自车变道、前车急刹、行人横穿 |
小技巧：别试图穷举所有场景。先抓「高暴露率+高严重度」的组合。我曾经在项目中用「场景矩阵」的方法，把1000+场景压缩到30个关键场景，效率提升明显。
4.4 危害识别——别漏掉「隐形杀手」
危害识别阶段，最容易犯的错误是——只盯着「撞车」这种显性危害。
SOTIF里有很多「隐形杀手」。比如：
- 系统误触发导致驾驶员恐慌（心理危害）
- 系统频繁报警导致驾驶员忽略真实危险（脱敏效应）
- 系统在关键场景下「静默退出」导致驾驶员措手不及（接管风险）
我记得有一次做LCC（车道居中控制）的HARA，团队只识别了「偏离车道」的危害。但我追问了一句：「如果系统在弯道突然退出，驾驶员需要多少时间接管？」结果发现，这个场景的风险等级比偏离车道还高。
注意：SOTIF的危害识别，一定要包含「人机交互」相关的危害。这是传统HARA容易忽略的盲区。
4.5 风险评估——三个参数的博弈
SOTIF的风险评估，沿用了功能安全的三个参数：
- 严重度（S）：危害发生后，对人员伤害的严重程度
- 暴露率（E）：触发条件在真实场景中出现的概率
- 可控性（C）：驾驶员或周围人员避免伤害的能力
但这里有个坑——SOTIF的暴露率评估比功能安全复杂得多。
功能安全的暴露率，主要看「故障发生频率」。而SOTIF的暴露率，要看「场景出现的频率」+「系统性能局限被触发的概率」。说白了，你得知道「雨天+逆光+前车变道」这种组合场景，一年能遇到几次。
我建议的做法是：
- 先用自然驾驶数据（NDS）统计场景频率
- 再用仿真工具模拟性能局限的触发概率
- 最后结合专家判断做修正
经验之谈：可控性评估在SOTIF里特别容易「乐观」。工程师总觉得自己设计的系统很安全，驾驶员一定能接管。但真实情况是——驾驶员可能在刷手机、可能在睡觉、可能根本不知道系统要退出。所以，我一般建议把可控性往严了估。
4.6 风险可接受性——到底多安全才算够？
这是HARA的最后一关，也是最难的一关。
功能安全有明确的ASIL等级，告诉你什么风险可以接受。但SOTIF没有这么清晰的边界。ISO 21448只说了「合理可预见的误用」和「已知危害场景」需要被处理，但没说处理到什么程度。
我个人习惯用「GAMAB原则」（Globalement Au Moins Aussi Bon，整体至少同样好）。说白了就是：智能驾驶系统的风险，不能高于人类驾驶的平均风险水平。
举个例子。人类驾驶的致命事故率大约是每亿公里1-2起。如果你的智能驾驶系统能做到每亿公里0.5起，那就算可接受。如果做不到，那就得继续优化。
避坑指南：我曾经在项目里直接用「零事故」作为目标，结果被安全评审专家怼了——「零事故」在工程上不可实现，而且会导致过度设计。后来我们改用「与人类驾驶水平相当」作为基准，评审顺利通过。
4.7 知识体系总览
下面这张图，是我自己总结的SOTIF HARA知识体系。你可以把它当作一个检查清单，做项目时对照着看，不容易漏项。
4.8 实战中的几个坑
最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路。
坑1：场景定义太粗
我曾经在项目里只定义了「雨天」场景，结果测试时发现——小雨、中雨、暴雨、雨+雾、雨+夜晚，系统表现完全不同。后来我们不得不把场景细化到「光照强度+降雨量+路面附着系数」的组合。
坑2：忽略组合危害
单个危害可能风险不高，但组合起来就危险了。比如「摄像头脏污」+「弯道曲率过大」+「前车急刹」，三个条件单独看都还好，但凑在一起就是致命场景。HARA时一定要做组合分析。
坑3：过度依赖仿真数据
仿真数据只能告诉你「场景出现的概率」，但无法告诉你「驾驶员在真实场景中的反应」。可控性评估，一定要结合实车测试和用户调研。我见过一个项目，仿真显示可控性为C1（完全可控），但实车测试发现驾驶员接管时间平均需要3秒——这已经是C2了。
好了，关于HARA在SOTIF中的应用，今天就聊到这里。记住一句话：HARA不是一次性的工作，而是贯穿整个开发周期的迭代过程。随着场景库的丰富和系统能力的提升，HARA的结果也需要不断更新。
公众号:蓝海资料掘金营，微信deep3321