SOTIF和ISO 26262最根本的区别ISO 26262是“走一遍”——从左到右走完就定型了。SOTIF是“转圈圈”——分析→改进→验证→发现新问题→再分析→再改进→再验证……直到残余风险可接受。为什么SOTIF必须是迭代的SOTIF必须迭代的根本原因只有一个——你不知道你不知道什么。ISO 26262处理的是“已知的故障”——硬件会老化、软件会有bug这些是已知的、可预测的。你只需要按照标准流程走一遍该测的测了该分析的做了就差不多了。但SOTIF处理的是“未知的危险场景”——你设计系统的时候可能根本没想过会有这种场景。标准处理的对象特性流程️ISO 26262故障故障模式是已知的已知的、可预测的走一遍SOTIF功能不足很多是未知的未知的、不可预测的转圈圈SOTIF的流程就像“打地鼠”你一锤下去打中了一个“未知危险场景”区域3它变成了“已知危险场景”区域2。但与此同时另一个“地鼠”又在别的地方冒出来了——你又得再打一锤。直到所有“地鼠”都被你打了一遍你才能说“差不多了”。️ 迭代循环的“四个阶段”一个标准的闭环SOTIF的迭代过程可以概括为四个阶段阶段一分析——找FI和TC做什么从功能规范出发系统性地识别“功能不足”和“触发条件”。这是迭代的“起点”。每一轮迭代都从这里开始——要么是初始分析要么是上一轮发现新问题后的重新分析。阶段二改进——设计方案做什么针对识别出的功能不足和触发条件设计功能改进方案。改进的方向包括改进方向大白话算法优化“让算法在更多场景下都能正确处理”传感器增强/冗余“增加传感器种类或数量覆盖感知盲区”降级与接管策略“不行的时候怎么安全地停下来”️ODD限制“不安全的场景我就不去了”阶段三验证——确认有效做什么验证改进方案是否真的有效——重新测试之前失败的那个场景确认系统现在已经“行了”。验证的方法方法大白话已知场景验证“之前出问题的那个场景现在再测一遍看过了没”回归测试“改了这儿别的地方没出问题吧”阶段四评估——还有新问题吗做什么经过验证后评估是否还有新的功能不足或触发条件被发现了。这是迭代循环的关键环节——它决定了你是可以停下来✅ 没有新问题了还是需要再来一轮 又发现了新问题。为什么验证阶段很可能发现新问题因为你在验证“已知危险场景”的时候可能会触发新的场景、暴露新的功能不足。验证不只是“确认修好了”它还可能“发现之前没发现的问题”。 实战AEB系统的“迭代打怪”之旅用AEB系统完整走一遍多轮迭代的过程你就明白“迭代”到底长什么样了。 第0轮初始状态区域内容状态区域1晴天、白天、前方普通轿车✅ 已知安全区域2夜间 白色货车识别率下降⚠️ 已知危险区域3还不知道❓ 未知危险 第1轮迭代分析阶段一对“夜间白色货车”场景做FI/TC分析要素内容FI摄像头在低照度下对白色物体的识别能力不足️TC夜间 白色货车改进阶段二增加毫米波雷达融合——雷达不受光照影响。验证阶段三重新测试“夜间白色货车”场景 → ✅ 系统正确制动。评估阶段四在验证过程中发现在强逆光阴影场景下系统把阴影误检为障碍物触发了非预期急刹车。结果发现了一个新的功能不足摄像头在强逆光下误识别以及一个新的触发条件强逆光阴影。→再来一轮 第2轮迭代分析阶段一对“强逆光阴影”场景做FI/TC分析要素内容FI摄像头在强逆光下的动态范围不足容易把阴影误检为障碍物️TC强逆光 地面阴影改进阶段二增加时间序列滤波——单帧的“疑似障碍物”不立即触发制动需要连续多帧确认。验证阶段三重新测试“强逆光阴影”场景 → ✅ 系统不再误制动。评估阶段四在验证过程中没有发现新的问题。结果本轮迭代没有发现新问题。→可以停了✅ 最终状态区域初始状态经过2轮迭代后变化区域1小大⬆️ 扩大了区域2中小⬇️ 缩小了区域3大小⬇️ 缩小了区域4中中➡️ 不变这个案例说明第1轮迭代解决了“已知危险场景”但验证过程中发现了新的“未知危险场景”。于是进入第2轮迭代。第2轮迭代解决了新发现的危险场景然后没有再发现新的问题所以迭代停止了。如果第2轮迭代又发现了新问题那就还得再来第3轮。 什么时候可以停下来——收敛条件这是迭代最核心的问题——怎么知道“可以停了”ISO 21448第12章“SOTIF发布准则”给出了答案当残余风险可接受时就可以发布了。但“残余风险可接受”不是“没有风险了”——是“剩下的风险我们能接受了”。 三个判断标准判断标准问的问题✅区域2已处理“所有已知危险场景都被解决了吗”✅区域3已充分探索“未知场景的探索达到足够覆盖率了吗”✅残余风险可接受“剩下的风险我们能接受了吗” 一个关键的认知迭代不是“无限循环”SOTIF的迭代虽然“可能”无限循环但现实中一定是“有限”的。为什么因为你的资源是有限的——时间、预算、人力。你不可能“无限”地迭代下去。现实中的SOTIF迭代是在“成本”和“安全性”之间找平衡——不是“绝对安全”才能停是“足够安全”就可以停了。收敛的典型表现表现说明发现新问题的频率下降从“每轮都发现”变成“好几轮才偶尔发现一个”区域2的规模不再变化已知危险场景已经被逐个消除区域3的探索覆盖率足够已经投入了足够的测试资源⚖️残余风险评估通过剩下的风险被判断为“可接受”迭代过程中的“不变”与“变”虽然SOTIF的流程是“转圈圈”但有些东西是不变的有些东西是不断更新的。 不变V模型的整体框架无论迭代多少轮V模型的框架不变——左边设计、右边验证这个“骨架”始终都在。 变三个关键要素每轮都在更新要素变什么例子功能规范增加新的对策“AEB系统增加雷达融合”危害列表增加新的危害“强逆光阴影 → 非预期急刹车”验证用例库增加新的场景“新增‘夜间白色货车’验证用例”⚠️ SOTIF迭代中容易踩的“坑”坑1迭代了一轮就觉得“完事了”❌ “第1轮迭代解决了3个已知危险场景差不多了”✅SOTIF的迭代要在验证阶段确认没有新问题才能停不是“改了几个场景就算完事”坑2把“验证”当成“终点”❌ “验证通过了不用再看了”✅验证可能发现新问题——要把验证当成“发现新问题的过程”而不是“证明自己做完了的过程”坑3不知道什么时候该停下来❌ “感觉差不多了”——没有明确的停止标准✅定义清晰的发布准则——区域2都处理完了吗区域3探索了够多吗残余风险可接受吗坑4迭代了“设计”但没更新“规范”❌ “加了雷达融合代码也改了”——但功能规范没更新✅每一次迭代发现的新对策都要反馈到功能规范中——规范和设计必须保持同步 和ISO 26262的“迭代”有什么区别ISO 26262也有迭代——比如你发现了新的失效模式也得回去重新分析、重新设计。但程度完全不同。对比维度️ISO 26262SOTIF迭代频率偶尔发现新失效时常态化每轮都可能发现新问题迭代深度局部修改某个组件可能全局发现新的功能不足迭代终点相对明确失效模式已穷举相对模糊未知风险永远存在核心驱动力发现新的失效模式发现新的危险场景简单说ISO 26262的迭代是“例外情况”——发现了新的失效模式才回去改。SOTIF的迭代是“常态”——每轮迭代都可能发现新问题这是SOTIF工作方式本身的一部分。