3. SOTIF开发流程：V模型在SOTIF中的应用、SOTIF开发的生命周期阶段
聊到SOTIF开发流程，我第一个想到的就是V模型。说实话，这个模型在功能安全领域已经用了很多年，但到了SOTIF这里，它被赋予了新的含义。我个人习惯把V模型比作一座桥——左边是设计，右边是验证，中间是你要解决的那个核心问题：系统到底安不安全？
3.1 为什么SOTIF离不开V模型？
你想想看，传统的V模型强调的是“需求-设计-实现-测试”的闭环。但SOTIF关注的是什么呢？是那些功能本身没问题、但场景一复杂就出事的场景。比如自动驾驶在雨雪天、隧道口、强光逆光下的表现。这些场景，传统功能安全不太管，但SOTIF必须管。
我在项目中遇到过一件事：一个L2级别的辅助驾驶系统，在高速上遇到前方静止车辆，系统居然没识别出来。后来一查，不是传感器坏了，也不是算法写错了，而是那个场景——阳光直射、前车颜色和路面接近——系统“没认出来”。这就是典型的SOTIF问题。V模型在这里的作用，就是帮你把这类场景从“未知不安全”变成“已知安全”。
核心观点：SOTIF的V模型不是照搬功能安全，而是把重点从“功能失效”转向“功能不足”和“场景覆盖”。
3.2 SOTIF开发的生命周期阶段
SOTIF的生命周期，说白了就是六个阶段。我一个个讲给你听，每个阶段我都会结合自己的经验说点实在的。
阶段一：功能定义与系统设计
这个阶段，你要把系统的功能边界画清楚。比如“自动紧急制动”这个功能，它的触发条件是什么？车速范围？目标类型？光照条件？
我曾经见过一个项目，功能定义里只写了“检测前方障碍物并制动”，结果到了测试阶段才发现，系统对“前方”的定义是正前方±5度，而实际驾驶中很多碰撞都是从侧前方来的。嗯，这里要注意：功能定义越模糊，后面的坑就越多。
阶段二：危害分析与风险评估（HARA）
这是SOTIF最核心的一步。你要找出所有可能的危害场景，然后评估它们的严重度、暴露率和可控性。和功能安全不同的是，SOTIF的HARA更关注“非故障场景”。
举个例子：系统在隧道出口突然减速，不是因为传感器坏了，而是因为光线突变导致摄像头“晃了一下”。这种场景，传统HARA不会管，但SOTIF必须管。
我的经验：做HARA时，别只盯着“最坏情况”。很多团队喜欢把所有场景都标成S3/E4/C3，结果最后发现根本测不过来。我建议你按“实际发生概率”来排序，先搞定那些大概率会遇到的场景。
阶段三：功能改进与系统优化
找到问题之后，就要改。改的方式有两种：一是改功能逻辑，比如增加冗余判断；二是加传感器，比如在摄像头之外再加个毫米波雷达。
我记得有个项目，系统在夜间对行人识别率很低。我们没急着换传感器，而是先优化了算法——把红外热成像的数据融合进来。效果立竿见影。说白了，有时候不是硬件不够，而是你没用好它。
阶段四：验证与确认策略制定
这个阶段，你要回答一个问题：我怎么证明系统是安全的？
验证（Verification）是“我做得对不对”，确认（Validation）是“我做的是不是对的”。在SOTIF里，确认更重要。因为你要证明的是：在所有已知和未知的场景下，系统都不会导致危害。
| 验证类型 | 关注点 | 典型方法 |
|---|---|---|
| 功能验证 | 功能是否按设计实现 | 单元测试、集成测试 |
| 场景验证 | 是否覆盖了所有已知场景 | 场景库测试、仿真 |
| 安全确认 | 系统在实际环境中是否安全 | 实车路测、用户测试 |
阶段五：验证与确认执行
这个阶段就是“真刀真枪”地干了。你要跑仿真、做台架测试、上路实测。我建议你从“最危险的场景”开始测，比如鬼探头、大雾天气、强光直射。因为这些场景一旦出事，后果很严重。
避坑指南：我曾经见过一个团队，仿真跑了十万公里，结果上路第一天就出问题。为什么？因为仿真场景太“干净”了，没有考虑真实道路上的各种“脏数据”——比如树叶遮挡、泥水溅到镜头上。所以，仿真要加“噪声”，要加“干扰”。
注意：验证和确认不是一次性的。SOTIF要求你持续迭代——测出问题，改完再测，直到所有已知场景都通过。这个过程可能很漫长，但绝对不能跳过。
阶段六：发布与持续监控
系统上线了，不代表SOTIF工作就结束了。你要持续监控系统在实际使用中的表现，收集边缘场景，然后反馈到下一轮迭代中。
我参与过一个项目，系统发布后三个月，我们通过OTA收集到了上千个新的边缘场景。其中有一个场景——夜间、雨天、对面来车开远光——系统直接“失明”了。我们连夜改算法，第二天就推送了更新。这就是持续监控的价值。
3.3 V模型在SOTIF中的具体应用
V模型在SOTIF中的应用，我总结成一句话：左边是“我要做什么”，右边是“我做得怎么样”。
- 左侧（设计阶段）：功能定义 → 系统设计 → 详细设计
- 底部（实现阶段）：编码、硬件实现、传感器选型
- 右侧（验证阶段）：单元测试 → 集成测试 → 系统测试 → 实车确认
你想想看，这个模型的好处是什么？是“早发现、早解决”。如果你在功能定义阶段就发现某个场景覆盖不了，那改起来成本很低。但如果你等到实车测试才发现，那可能整个硬件平台都要换。
关键点：V模型的左右两侧要一一对应。左侧定义了“系统在隧道口不能误减速”，右侧就要有对应的测试用例来验证这一点。少一个都不行。
3.4 我画的一张SOTIF V模型流程图
下面这张图，是我自己总结的SOTIF V模型流程。它把六个阶段和V模型的左右两侧对应起来了。你仔细看看，应该能一目了然。
3.5 几个实用的避坑指南
最后，我把自己这些年踩过的坑总结一下，希望能帮你少走弯路。
- 别把SOTIF当成功能安全的“附属品”。我见过很多团队，做功能安全时顺带做一下SOTIF，结果两边都没做好。SOTIF有自己的方法论，必须独立对待。
- 场景库要“脏”一点。干净的场景只能证明系统在理想条件下能用，但真实世界是充满噪声的。我建议你在场景库里加入各种“脏数据”——比如镜头上有泥点、传感器被遮挡、GPS信号丢失。
- 验证不是终点，是起点。很多团队把验证当成“交差”的环节，测完就完事了。但SOTIF要求你持续迭代——系统上线后，还要通过OTA收集数据，不断优化。
- 别忽视“已知不安全”场景。有些场景你明知道系统处理不好，但觉得“概率低”就放过去了。我曾经吃过这个亏——一个“概率低”的场景，在实际使用中一个月就出现了三次。所以，别赌概率。
我的建议：如果你刚开始做SOTIF，先从“最痛”的场景入手。别想着一步到位覆盖所有场景，那是不可能的。先搞定那些“不出事则已，一出事就是大事”的场景，然后再慢慢扩展。
好了，关于SOTIF开发流程和V模型的应用，我就讲到这里。记住一句话：V模型不是束缚你的框架，而是帮你系统化思考的工具。用好了，它能帮你省下大量时间和成本。