4. 危害分析与风险评估（HARA）在SOTIF中的应用：如何识别和评估预期功能不足导致的危害
各位工程师朋友，咱们今天聊点实在的。
HARA，也就是危害分析与风险评估，在功能安全（ISO 26262）里是老朋友了。但到了SOTIF（ISO 21448）里，它的玩法有点不一样。说白了，功能安全防的是“系统坏了怎么办”，而SOTIF要防的是“系统没坏，但干的事不对怎么办”。
我刚开始接触SOTIF时，总觉得HARA这步跟功能安全差不多，直接拿过来用就行。结果第一个项目就踩了坑——我们分析了一堆电子电气故障，却漏掉了最关键的感知偏差问题。嗯，从那以后，我再也不敢小看SOTIF下的HARA了。
4.1 为什么SOTIF需要独立的HARA？
你可能会问：功能安全不是已经有HARA了吗？为什么SOTIF还要再做一遍？
原因很简单：危害源不同。
- 功能安全HARA：关注系统故障（硬件随机失效、系统失效）。比如刹车踏板断了、传感器短路了。
- SOTIF HARA：关注预期功能不足和触发条件。比如摄像头没坏，但逆光时看不清行人；算法没崩溃，但把白色卡车当成了天空。
我在一个L4级园区物流项目里就遇到过这种情况。车辆在雨天行驶，激光雷达的探测距离明显下降，但系统没有报任何故障——它“以为”自己看得清。结果就是，车辆在十字路口没能及时检测到横向来车。你说这是故障吗？不是。但危害实实在在发生了。
核心观点：SOTIF的HARA不是功能安全HARA的替代，而是补充。两者共同覆盖“系统故障”和“功能不足”两类危害。
4.2 SOTIF HARA的核心步骤
我个人习惯把SOTIF的HARA拆成四个步骤。你想想看，每一步其实都是在回答一个关键问题。
步骤一：场景分析与触发条件识别
这一步是SOTIF HARA的起点，也是最容易被忽视的。很多人上来就分析危害，却忘了问一句：什么情况下功能会不足？
常见的触发条件包括：
- 环境因素：雨、雪、雾、逆光、夜间、隧道出入口
- 道路因素：车道线模糊、施工区域、急弯、坡顶
- 目标物因素：异形车辆、行人穿深色衣服、动物横穿
- 系统自身因素：传感器遮挡、算法边界、计算资源不足
我记得有一次做高速公路领航辅助的HARA，团队列了30多个触发条件。但真正让我警觉的是“隧道出口强光”这个场景——车辆刚出隧道，摄像头还在适应亮度变化，前方突然出现一辆静止的故障车。这个场景在功能安全里根本不会出现，但在SOTIF里，它是实实在在的高危场景。
步骤二：危害识别
基于触发条件，我们要识别出具体的危害事件。这里要注意：危害不是“功能失效”，而是“对人员造成的伤害”。
举个例子：
- ❌ 错误写法：摄像头在逆光下无法检测行人
- ✅ 正确写法：车辆在逆光场景下未能检测到横穿行人，导致碰撞行人
你看，后者才是一个完整的危害描述。它包含了场景、功能不足、以及最终的人身伤害。
步骤三：风险评估
SOTIF的风险评估，我建议沿用功能安全的三个维度，但评估标准要调整：
| 维度 | 功能安全（ISO 26262） | SOTIF（ISO 21448） |
|---|---|---|
| S（严重度） | 基于伤害的严重程度 | 相同，但需考虑功能不足导致的特殊伤害（如误加速） |
| E（暴露率） | 基于场景的暴露概率 | 需额外考虑触发条件的暴露概率 |
| C（可控性） | 驾驶员能否控制 | 需考虑驾驶员对功能不足的预期和反应时间 |
这里有个坑：SOTIF里的可控性评估比功能安全更复杂。为什么？因为功能安全里，系统故障通常是突然发生的，驾驶员能立刻感知到异常。但SOTIF里，功能不足可能是渐进的——比如车道保持能力在雨天逐渐下降，驾驶员可能根本没意识到系统已经“力不从心”了。
避坑指南：我曾经在一个项目中，把SOTIF的可控性直接照搬了功能安全的评估结果。结果评审时被专家质疑：驾驶员在逆光场景下，根本不知道摄像头已经失效了，你凭什么说可控性高？从那以后，我每次评估可控性都会问自己一个问题：驾驶员能意识到功能不足正在发生吗？
步骤四：风险等级判定与接受准则
根据S、E、C的评分，我们可以得到风险等级。但SOTIF和功能安全有一个重要区别：功能安全要求所有风险必须降低到可接受水平（ASIL等级），而SOTIF允许部分风险在“合理可预见”的前提下被接受。
什么意思呢？就是说，有些场景下的功能不足，你没办法完全消除，但只要发生的概率足够低、后果足够轻，就可以接受。比如，车辆在极端罕见的暴雪天气下，感知性能下降导致短暂的车道偏离——如果系统能及时提醒驾驶员接管，这个风险可能就是可接受的。
4.3 知识体系框架
下面这张图，是我自己总结的SOTIF HARA知识体系。它把整个流程串起来了，你一看就明白。
4.4 实战案例：自动紧急制动（AEB）的HARA
光讲理论没意思，咱们来看个实际案例。我参与过一个AEB系统的SOTIF HARA，这里分享一个典型危害的分析过程。
场景：车辆在城市道路以40km/h行驶，前方有一辆静止的白色厢式货车。时间是下午4点，太阳位于车辆正前方，属于逆光场景。
触发条件：逆光导致摄像头动态范围不足，无法清晰识别白色货车与背景天空的边界。
危害：车辆未能检测到前方静止货车，未触发AEB制动，导致追尾碰撞，可能造成乘员颈部受伤。
接下来是风险评估：
- S（严重度）：S2（中等伤害，可能需就医）—— 40km/h追尾静止车辆，乘员可能颈部扭伤
- E（暴露率）：E3（中等暴露）—— 逆光场景在城市道路中每天都会出现，但并非每次都有静止货车
- C（可控性）：C2（一般可控）—— 驾驶员如果注意力集中，可以观察到前方货车并自行制动；但如果驾驶员分心，则无法控制
综合评分：S2 × E3 × C2 = 风险等级为“高”，需要采取措施降低风险。
个人经验：在这个案例中，我们最初把可控性评为了C1（容易控制），理由是“驾驶员应该能看到前方货车”。但后来我们做了实车测试，发现逆光时驾驶员也会被晃眼，反应时间比正常场景慢了0.8秒。这个0.8秒的差距，在40km/h下就是将近9米的制动距离。所以，不要凭直觉评估可控性，一定要用数据说话。
4.5 常见误区与避坑指南
做了几个SOTIF项目后，我总结了几个常见误区，分享给你：
- 误区一：把功能安全HARA直接拿来用
我曾经犯过这个错。功能安全的HARA关注的是“系统故障”，而SOTIF关注的是“功能不足”。两者的危害清单完全不同。我的建议是：重新做，不要偷懒。
- 误区二：忽略触发条件的组合效应
单个触发条件可能风险不高，但多个条件叠加就危险了。比如“雨天+夜间+施工区域”，三个条件叠加，感知系统的性能可能下降80%以上。我在一个项目中就吃过这个亏，只分析了单一触发条件，结果漏掉了组合场景。
- 误区三：可控性评估过于乐观
很多工程师觉得“驾驶员总能接管”。但实际情况是，驾驶员对系统的信任度会影响接管意愿。如果系统平时表现很好，驾驶员就会放松警惕。一旦功能不足发生，驾驶员可能来不及反应。我的建议是：假设驾驶员是最差情况——分心、疲劳、对系统过度信任。
4.6 小结
好了，这一章的内容就到这里。咱们回顾一下核心要点：
- SOTIF的HARA和功能安全的HARA是互补关系，不是替代关系
- 核心四步：场景与触发条件识别 → 危害识别 → 风险评估 → 风险等级判定
- 风险评估的三个维度（S/E/C）在SOTIF下需要重新审视，尤其是可控性
- 实战中要注意触发条件的组合效应，以及可控性评估的客观性
下一章，我们会深入讨论如何通过系统设计来降低这些风险。到时候我会分享一些具体的算法改进和传感器融合策略，都是实战干货。
公众号:蓝海资料掘金营，微信deep3321