4. 危害分析与风险评估：HARA方法在SOTIF中的应用
各位同学，今天我们来聊聊HARA——危害分析与风险评估。说实话，这个方法是功能安全领域的基石，但在SOTIF（预期功能安全）里，它的用法有些微妙的不同。
我最早接触HARA是在做ADAS项目的时候。那时候刚入行，觉得这玩意儿就是个填表游戏。后来踩过坑才明白，HARA做得好不好，直接决定了你后续所有工作的方向。嗯，咱们今天就把这块掰开揉碎了讲。
4.1 HARA在SOTIF中的定位
传统功能安全里的HARA，针对的是系统故障。比如传感器坏了、线束断了、芯片挂了。但SOTIF要处理的是另一类问题——系统本身没坏，但就是表现不对。
说白了，就是「功能不足」和「触发条件」导致的危害。我举个例子：
- 功能不足：摄像头在逆光下看不清行人
- 触发条件：突然从大货车后面窜出来的小孩
这两种情况，系统硬件都是好的，但结果可能很危险。HARA在SOTIF里的任务，就是把这些场景找出来，评估风险等级。
核心区别一句话：传统HARA看「坏了会怎样」，SOTIF的HARA看「没坏但不够好会怎样」。
4.2 危害识别——你得先知道怕什么
危害识别是第一步。我个人习惯的做法是，先拉一个「场景清单」。你想想看，自动驾驶系统可能遇到的所有情况，哪些会导致危险？
我建议从三个维度入手：
- 感知能力边界：传感器在什么条件下会失效？比如暴雨、黑夜、隧道出入口
- 算法局限性：模型在什么场景下会误判？比如罕见车型、异形障碍物
- 环境干扰：外部因素如何影响系统？比如强电磁干扰、路面反光
我在项目中遇到过最典型的案例：某款车的AEB系统在雨天误触发。原因是雨滴被雷达误判为障碍物。你说硬件坏了吗？没有。但危害确实存在——后车追尾风险。
我的小技巧：做危害识别时，别只盯着「最坏情况」。中等风险场景往往更容易被忽略，但实际发生频率更高。
4.3 风险评估矩阵——给危险排个队
识别出危害之后，得给它们排个优先级。风险评估矩阵就是干这个的。传统ISO 26262用S（严重度）、E（暴露率）、C（可控性）三个参数。SOTIF基本沿用这个框架，但有些调整。
我常用的矩阵是这样的：
| 严重度(S) | 描述 | 示例 |
|---|---|---|
| S0 | 无伤害 | 系统误报警，但驾驶员及时接管 |
| S1 | 轻伤 | 轻微碰撞，无人员受伤 |
| S2 | 重伤 | 碰撞导致骨折等伤害 |
| S3 | 致命 | 碰撞导致死亡 |
暴露率(E)和可控性(C)也类似，我就不一一列了。关键是三个参数组合后，会得到一个风险等级：
- QM：质量管理级，常规开发即可
- ASIL A/B/C/D：安全等级递增，D最高
但注意！SOTIF里有个特殊点：有些场景虽然风险等级不高，但发生频率极高。比如城市道路中「鬼探头」场景，单次风险可能只有S1，但每天遇到几十次，累积风险就很大了。
我曾经踩过的坑：只按单次场景评估风险，忽略了频率因素。结果某个低风险场景在路测中频繁触发，差点导致项目延期。后来我养成了习惯——评估时加上「发生频率」这个隐性参数。
4.4 知识体系与核心逻辑
为了让大家更直观地理解HARA在SOTIF中的全貌，我画了一张流程图。这张图我反复改过好几版，现在这个版本比较清晰：
这张图的核心逻辑是：从场景出发，识别危害，然后综合评估。注意右侧那个「发生频率」分支——这是SOTIF特有的考量点。
4.5 实战中的注意事项
最后，我分享几个实战中的经验：
- 别贪多：一次HARA分析不要覆盖太多场景。我建议每次聚焦一个ODD（运行设计域），比如「高速公路白天」或「城市夜间」。
- 留证据：每个危害的识别过程、评估依据都要记录。审计的时候，这些就是你的护身符。
- 迭代做：HARA不是一次性的。随着系统迭代、新场景发现，要反复更新风险评估矩阵。
一句话总结：HARA在SOTIF里，就是帮你在「系统没坏但不够好」的情况下，找出最该优先解决的那些问题。
好了，这一章的内容就到这里。记住，风险评估不是目的，改进才是。下一章我们会讲如何根据HARA的结果，制定具体的改进策略。