企业官网建设流程全解析

SOTIF和ISO 26262最根本的区别：

ISO 26262是“走一遍”——从左到右，走完就定型了。

SOTIF是“转圈圈”——分析→改进→验证→发现新问题→再分析→再改进→再验证……直到残余风险可接受。

为什么SOTIF必须是迭代的？

SOTIF必须迭代的根本原因只有一个——你不知道你不知道什么。

ISO 26262处理的是“已知的故障”——硬件会老化、软件会有bug，这些是已知的、可预测的。你只需要按照标准流程走一遍，该测的测了，该分析的做了，就差不多了。

但SOTIF处理的是“未知的危险场景”——你设计系统的时候，可能根本没想过会有这种场景。

💡SOTIF的流程就像“打地鼠”：你一锤下去，打中了一个“未知危险场景”（区域3），它变成了“已知危险场景”（区域2）。但与此同时，另一个“地鼠”又在别的地方冒出来了——你又得再打一锤。直到所有“地鼠”都被你打了一遍，你才能说“差不多了”。

🏗️ 迭代循环的“四个阶段”：一个标准的闭环

SOTIF的迭代过程可以概括为四个阶段：

阶段一：分析——找FI和TC

做什么：从功能规范出发，系统性地识别“功能不足”和“触发条件”。

这是迭代的“起点”。每一轮迭代都从这里开始——要么是初始分析，要么是上一轮发现新问题后的重新分析。

阶段二：改进——设计方案

做什么：针对识别出的功能不足和触发条件，设计功能改进方案。

改进的方向包括：

阶段三：验证——确认有效

做什么：验证改进方案是否真的有效——重新测试之前失败的那个场景，确认系统现在已经“行了”。

验证的方法：

阶段四：评估——还有新问题吗？

做什么：经过验证后，评估是否还有新的功能不足或触发条件被发现了。

这是迭代循环的关键环节——它决定了你是可以停下来（✅ 没有新问题了），还是需要再来一轮（🔄 又发现了新问题）。

💡为什么验证阶段很可能发现新问题？

因为你在验证“已知危险场景”的时候，可能会触发新的场景、暴露新的功能不足。验证不只是“确认修好了”，它还可能“发现之前没发现的问题”。

🔥 实战：AEB系统的“迭代打怪”之旅

用AEB系统完整走一遍多轮迭代的过程，你就明白“迭代”到底长什么样了。

📋 第0轮：初始状态

🔄 第1轮迭代

分析（阶段一）：对“夜间+白色货车”场景做FI/TC分析

改进（阶段二）：增加毫米波雷达融合——雷达不受光照影响。

验证（阶段三）：重新测试“夜间+白色货车”场景 → ✅ 系统正确制动。

评估（阶段四）：在验证过程中，发现在强逆光+阴影场景下，系统把阴影误检为障碍物，触发了非预期急刹车。

结果：发现了一个新的功能不足（摄像头在强逆光下误识别），以及一个新的触发条件（强逆光+阴影）。

→再来一轮！🔄

🔄 第2轮迭代

分析（阶段一）：对“强逆光+阴影”场景做FI/TC分析

改进（阶段二）：增加时间序列滤波——单帧的“疑似障碍物”不立即触发制动，需要连续多帧确认。

验证（阶段三）：重新测试“强逆光+阴影”场景 → ✅ 系统不再误制动。

评估（阶段四）：在验证过程中，没有发现新的问题。

结果：本轮迭代没有发现新问题。

→可以停了！✅

📋 最终状态

💡这个案例说明：

第1轮迭代解决了“已知危险场景”，但验证过程中发现了新的“未知危险场景”。于是进入第2轮迭代。

第2轮迭代解决了新发现的危险场景，然后没有再发现新的问题，所以迭代停止了。

如果第2轮迭代又发现了新问题，那就还得再来第3轮。

🛑 什么时候可以停下来？——收敛条件

这是迭代最核心的问题——怎么知道“可以停了”？

ISO 21448第12章“SOTIF发布准则”给出了答案：当残余风险可接受时，就可以发布了。

但“残余风险可接受”不是“没有风险了”——是“剩下的风险我们能接受了”。

📌 三个判断标准

📌 一个关键的认知：迭代不是“无限循环”

💡SOTIF的迭代虽然“可能”无限循环，但现实中一定是“有限”的。

为什么？

因为你的资源是有限的——时间、预算、人力。你不可能“无限”地迭代下去。

现实中的SOTIF迭代是在“成本”和“安全性”之间找平衡——不是“绝对安全”才能停，是“足够安全”就可以停了。

收敛的典型表现：

迭代过程中的“不变”与“变”

虽然SOTIF的流程是“转圈圈”，但有些东西是不变的，有些东西是不断更新的。

📌 不变：V模型的整体框架

无论迭代多少轮，V模型的框架不变——左边设计、右边验证，这个“骨架”始终都在。

📌 变：三个关键要素每轮都在更新

⚠️ SOTIF迭代中容易踩的“坑”

坑1：迭代了一轮就觉得“完事了”

❌ “第1轮迭代解决了3个已知危险场景，差不多了”
✅SOTIF的迭代要在验证阶段确认没有新问题才能停，不是“改了几个场景就算完事”

坑2：把“验证”当成“终点”

❌ “验证通过了，不用再看了”
✅验证可能发现新问题——要把验证当成“发现新问题的过程”，而不是“证明自己做完了的过程”

坑3：不知道什么时候该停下来

❌ “感觉差不多了”——没有明确的停止标准
✅定义清晰的发布准则——区域2都处理完了吗？区域3探索了够多吗？残余风险可接受吗？

坑4：迭代了“设计”但没更新“规范”

❌ “加了雷达融合，代码也改了”——但功能规范没更新
✅每一次迭代发现的新对策，都要反馈到功能规范中——规范和设计必须保持同步

🔄 和ISO 26262的“迭代”有什么区别？

ISO 26262也有迭代——比如你发现了新的失效模式，也得回去重新分析、重新设计。但程度完全不同。

💡简单说：

ISO 26262的迭代是“例外情况”——发现了新的失效模式才回去改。

SOTIF的迭代是“常态”——每轮迭代都可能发现新问题，这是SOTIF工作方式本身的一部分。