3. SOTIF开发流程：V模型在SOTIF中的应用、开发阶段划分、关键里程碑

好，我们进入第三章。前两章我们把SOTIF的“为什么”和“是什么”讲清楚了。这一章，咱们聊聊“怎么做”——也就是SOTIF的开发流程。

很多人一听到“流程”就觉得是走形式、填表格。说实话，我早年也这么想。直到有一次，我在一个L3级泊车项目里，因为功能定义阶段漏了一个“车位线模糊”的场景，导致量产前三个月紧急改算法……那滋味，真不好受。从那以后，我对流程的态度就变了——流程不是束缚，是帮你兜底的网。

3.1 V模型在SOTIF中的应用

传统功能安全（ISO 26262）用V模型，大家都很熟了。SOTIF也沿用V模型，但侧重点完全不同。

传统V模型关注的是“系统是否按设计运行”——也就是“有没有坏”。而SOTIF的V模型关注的是“系统在未知场景下是否还能安全运行”——也就是“够不够好”。

我习惯把SOTIF的V模型叫做“双V模型”的变体。为什么？因为它在传统V模型的左侧（开发侧）和右侧（验证侧）都增加了针对未知场景的活动。

下面这张图，是我自己项目里常用的SOTIF V模型框架，你一看就明白。

你看，左侧是“定义+设计”，右侧是“验证+确认”。但SOTIF多了一个维度——场景的已知/未知。这个维度贯穿整个V模型。

3.2 开发阶段划分

根据ISO 21448的附录和我的实战经验，我把SOTIF开发分为6个阶段。每个阶段都有明确的输入、输出和退出准则。

阶段	名称	核心活动	关键输出
1	系统定义与场景分析	定义ODD、功能边界、场景分类	ODD描述、场景目录
2	危害识别与风险评估	识别功能不足、评估风险等级	危害清单、风险矩阵
3	功能改进与安全措施	设计冗余、降级策略、人机交互	安全措施规范
4	验证策略制定	定义测试场景、仿真/实车比例	验证计划
5	验证与确认执行	仿真测试、场地测试、路测	测试报告、覆盖率分析
6	残余风险确认与释放	评估残余风险、决策是否可接受	安全论证报告

3.3 关键里程碑

每个阶段都有对应的里程碑。我习惯用M1~M6来标记。这些里程碑不仅是时间节点，更是决策关口——过不了，就不能进入下一阶段。

M1：系统定义冻结

ODD、功能边界、场景目录必须经过评审。我记得有一次，一个客户说“我们的ODD就是‘高速公路’”，我追问了一句：“高速公路包含匝道吗？包含隧道吗？包含施工区吗？”对方沉默了。嗯，ODD不写清楚，后面全是坑。

M2：危害清单确认

所有识别的功能不足和触发条件都要记录在案。这个里程碑的退出准则是：每个危害都有对应的风险等级和初步应对方案。

M3：安全措施设计完成

功能改进方案、降级策略、人机交互方案都要定下来。这里有个坑——不要过度设计。我曾经在一个项目里，为了覆盖一个概率极低的场景，加了三层冗余，结果系统复杂度爆炸，反而引入了新的未知风险。

M4：验证计划发布

测试场景、测试方法、通过准则、覆盖率目标都要明确。我建议在这个节点做一次“验证计划评审”，让测试团队和开发团队坐在一起，把场景过一遍。你想想看，如果测试团队不知道开发团队的设计意图，测出来的结果能信吗？

M5：验证执行完成

所有计划内的测试都执行完毕，覆盖率达标。这个里程碑最容易出问题的是“测试通过率100%”——别高兴太早，可能只是你的测试场景不够刁钻。

M6：残余风险可接受

这是最后的决策关口。需要回答三个问题：

• 已知场景是否全部覆盖？
• 未知场景的残余风险是否在可接受范围内？
• 是否有明确的监控和响应机制？

3.4 阶段间的迭代关系

V模型不是一条直线走到底的。实际项目中，阶段之间会有多次迭代。比如：

• 验证阶段发现新的未知场景 → 回到阶段1补充场景分析
• 功能改进后 → 需要重新验证
• 残余风险不可接受 → 回到阶段3加强安全措施

说白了，SOTIF开发是一个不断收敛的过程。每次迭代，未知场景的边界都在缩小，直到残余风险可接受。

好，这一章的内容就是这些。记住：V模型是骨架，阶段划分是血肉，里程碑是关节。三者缺一不可。