3. SOTIF开发流程（V模型）：从系统定义到验证确认的全生命周期拆解

大家好，我是老张。今天咱们来聊聊SOTIF开发流程的核心——V模型。

说实话，我刚接触SOTIF那会儿，看到V模型第一反应是：这不就是传统V流程加了个安全壳吗？后来踩了几个坑才明白，事情没那么简单。

SOTIF的V模型，说白了就是把「功能不足」和「触发条件」这两个幽灵，从头到尾盯死。我习惯把它拆成左半边的「分析设计」和右半边的「验证确认」。咱们一步步来看。

3.1 左侧：从系统定义到功能设计

左侧是「定义问题」的阶段。你想想看，如果连系统边界都画不清楚，后面验证什么？

第一步：系统定义

这里要明确三件事：

• 运行设计域（ODD）：车在什么路、什么天气、什么速度下跑？
• 功能定义：系统能做什么？不能做什么？
• 性能指标：比如「在高速上，系统能在10秒内完成变道」这种量化目标。

我记得有个项目，客户说「我们的车能在城市道路跑」。结果ODD里没写「无保护左转」这个场景。后来测试时，系统在无保护左转路口直接罢工了。嗯，这就是定义不清的代价。

第二步：危害分析与风险评估（HARA）

传统功能安全有HARA，SOTIF也有，但侧重点不同。SOTIF的HARA更关注：

• 哪些场景下，系统功能不足？
• 哪些触发条件会导致系统误判？

举个例子：摄像头在逆光下看不清车道线，这是「功能不足」。而「逆光」就是触发条件。我建议把触发条件列成一张表，越细越好。

第三步：功能设计与系统架构

这一步要把安全需求落实到架构里。比如：

• 增加冗余传感器（摄像头+雷达+激光雷达）
• 设计降级策略（当感知置信度低时，系统主动减速）
• 定义人机交互（HMI）的接管请求逻辑

我曾经在一个项目里，架构师拍脑袋说「两个摄像头就够了」。结果在隧道出口，两个摄像头同时被强光干扰，系统直接失明。后来我们加了毫米波雷达做冗余，才把这个问题堵住。

3.2 右侧：从验证到确认

右侧是「验证问题」的阶段。这里有个关键区别：

• 验证（Verification）：系统做对了吗？（对照需求）
• 确认（Validation）：做对了系统吗？（对照用户期望）

说白了，验证是「检查作业」，确认是「考试」。SOTIF特别强调确认，因为很多问题不是「没做对」，而是「根本没想到」。

第四步：集成测试与系统验证

这里要跑大量的场景测试：

• 已知安全场景：比如前车急刹、行人横穿
• 已知危险场景：比如鬼探头、逆光
• 未知场景探索：用随机测试、对抗测试去「撞」出问题

我习惯用一张表来管理测试覆盖度：

场景类型	已知	未知
安全	常规测试覆盖	随机探索
危险	针对性测试	对抗测试

第五步：确认与释放

确认阶段要回答一个问题：系统在真实世界中，风险是否可接受？

这需要：

• 路测数据（比如100万公里无事故）
• 仿真数据（覆盖ODD边界）
• 用户反馈（接管率、舒适度）

3.3 SOTIF V模型的核心逻辑图

下面这张图是我自己画的，帮你理解V模型的左右两侧如何对应：

你看，左侧每个节点都对应右侧一个节点。系统定义对应释放决策——你定义了什么ODD，释放时就只能在这个ODD里跑。HARA对应确认测试——你分析出的风险，最终要通过测试来确认是否被控制住。

3.4 迭代：V模型不是一次性走完的

这里我要强调一点：SOTIF的V模型不是走一遍就完事的。它是个迭代过程。

为什么？因为你在右侧测试时，会发现新的未知场景。这些场景会反馈到左侧，更新HARA、修改设计。然后重新走右侧验证。如此循环，直到风险可接受。

我习惯把这个迭代叫做「SOTIF螺旋」——每转一圈，未知区域就缩小一点。嗯，有点像剥洋葱，一层一层剥到核心。

3.5 实战建议：如何落地V模型

最后，给几个实操建议：

1. 工具链要跟上：我建议用场景管理工具（比如ASAM OpenSCENARIO）来管理测试用例，别用Excel，会疯的。
2. 仿真和路测比例要合理：我个人习惯是仿真占80%，路测占20%。但仿真要覆盖边界，路测要覆盖真实多样性。
3. 文档要可追溯：每个需求、每个测试用例、每个风险，都要能追溯到V模型的对应节点。不然审核时你会哭的。

好了，这一章就到这里。V模型是SOTIF的骨架，理解了它，后面的章节就好办了。

---