第三章：危害分析与风险评估（HARA）——SOTIF中的特殊要求

好，咱们进入第三章。这一章是SOTIF的硬骨头，也是我个人觉得最有意思的部分。HARA这东西，在功能安全里大家都不陌生，但在SOTIF里，玩法完全不一样。

说白了，传统功能安全的HARA，盯着的是系统故障。比如传感器坏了、线束断了、芯片挂了。但SOTIF的HARA，盯着的是系统本身没坏，但就是干蠢事。你想想看，一个摄像头没坏，但大雾天它看不清，这算不算危害？当然算。

3.1 HARA在SOTIF中的特殊要求

我刚开始接触SOTIF时，犯过一个低级错误。我拿着ISO 26262那套HARA模板直接套用，结果评审时被专家怼了回来。为什么？因为SOTIF的HARA，有几个关键差异点。

具体来说，SOTIF的HARA要求我们考虑：

• 性能局限：传感器在极端天气下的性能衰减
• 场景复杂性：系统在罕见场景下的决策能力
• 可预见误用：用户会不会故意或无意地让系统超出设计范围
• 功能不足：算法本身就没法处理某些情况，不是它坏了

嗯，这里要注意。SOTIF的HARA不是要替代功能安全的HARA，而是补充。两个HARA要并行做，最后合并评估。我在项目里习惯的做法是：先做功能安全的HARA，再做SOTIF的HARA，然后对比两者的危害清单，看看有没有重叠或遗漏。

3.2 场景分析与危害识别

场景分析是SOTIF HARA的起点。没有场景，你根本不知道系统会在什么情况下出问题。

我个人习惯把场景分为三类：

场景类型	说明	举例
标称场景	系统设计时预期的正常场景	晴天、高速公路、车道线清晰
边缘场景	系统设计边界附近的场景	黄昏、隧道出入口、雨量中等
未知场景	设计时未考虑到的罕见场景	路面有反光水洼、动物突然横穿

危害识别怎么做？我建议从场景出发，问三个问题：

1. 这个场景下，系统可能感知不到什么？（感知局限）
2. 这个场景下，系统可能做出什么错误决策？（决策错误）
3. 这个场景下，用户可能怎么误操作？（可预见误用）

举个例子。有一次我在做自动紧急制动（AEB）系统的HARA。场景是“夜间、雨天、前方有一辆没开尾灯的货车”。

• 感知局限：摄像头在低光照+雨滴干扰下，可能检测不到货车
• 决策错误：如果雷达检测到了，但算法认为“目标置信度低”，选择不制动
• 可预见误用：用户可能以为AEB能处理所有情况，放松了警惕

你看，三个问题一过，危害清单就出来了。

3.3 风险接受准则定义

这是HARA里最容易被忽视的一步。很多人做完危害识别，就急着去定ASIL等级或SOTIF的触发条件。但风险接受准则没定，后面的工作都是空中楼阁。

风险接受准则，说白了就是：我们觉得多危险是可以接受的？

在SOTIF里，风险接受准则通常从两个维度来定义：

• 严重度（Severity）：危害发生时，对人员伤害的严重程度
• 暴露率（Exposure）：该场景在实际运行中出现的频率

注意，SOTIF里没有“可控性”这个维度。为什么？因为SOTIF处理的是系统功能不足，用户往往无法控制。你想想看，系统突然误刹车，用户能怎么控制？

我见过一个项目，团队把风险接受准则定得太宽松。结果呢？系统在高速上因为一个塑料袋就急刹车，差点造成追尾。评审时大家才发现，当初定的“暴露率低于1e-6”根本不合理——塑料袋在高速上出现的频率远高于这个值。

风险接受准则的制定，我建议遵循以下步骤：

1. 定义严重度等级：S0（无伤害）到S3（致命伤害）
2. 定义暴露率等级：E0（几乎不出现）到E4（经常出现）
3. 建立风险矩阵：确定哪些组合是可接受的，哪些是不可接受的
4. 定义不可接受风险的缓解措施：要么降低严重度，要么降低暴露率

这里有个实际案例。我做泊车辅助系统时，发现“系统在狭窄车位误识别障碍物”这个危害。严重度是S2（轻伤），暴露率是E3（中等频率）。按照风险矩阵，这属于不可接受风险。

怎么缓解？两个方向：

• 降低严重度：限制泊车速度，即使误识别也不会造成严重碰撞
• 降低暴露率：增加超声波和视觉的融合算法，减少误识别概率

你看，风险接受准则不是定完就完事了。它直接指导你下一步的验证和确认工作。

最后说一句。HARA不是一次性的工作。随着系统迭代、场景库更新、实际运行数据反馈，HARA需要持续更新。我每个季度都会把HARA文档翻出来，看看有没有新的场景需要补充，有没有旧的准则需要调整。

嗯，这一章就到这。下一章我们聊聊验证策略的具体设计，那才是真正动手干活的部分。