3、SOTIF生命周期：V模型开发流程、SOTIF活动在V模型中的映射、安全生命周期阶段划分

3.1 为什么SOTIF也要讲生命周期？

说实话，我刚接触SOTIF的时候，第一反应是：这不就是功能安全的另一套说法吗？

后来踩了坑才明白——功能安全（ISO 26262）管的是“系统故障”和“随机硬件失效”，而SOTIF管的是“功能不足”和“可预见的人为误用”。这两者的根因完全不同，生命周期自然也要单独设计。

我个人习惯把SOTIF生命周期看作一个“找茬”的过程：从设计阶段就开始找系统的漏洞，一直找到量产后的运行数据反馈。你想想看，如果等到车都上路了才发现某个场景下系统会误判，那代价就太大了。

3.2 V模型开发流程——SOTIF的骨架

V模型在汽车行业已经用了很多年。我参与过的项目中，大部分团队对V模型的理解停留在“左边设计、右边验证”这个层面。但对于SOTIF来说，V模型的意义更深远——它要求我们在每个阶段都问自己：“这个阶段有没有引入新的未知风险？”

下面这张图是我自己整理的SOTIF活动在V模型中的映射关系，你可以把它当作一个“导航地图”来用：

这张图里，左侧是“设计活动”，右侧是“验证活动”。注意看：SOTIF的V模型不是简单的“设计→验证”单向流动，而是每个左侧活动都对应右侧的验证活动。比如，你在左侧做了“风险分析”，右侧就必须有“针对这些风险的测试用例”。

3.3 SOTIF活动在V模型中的详细映射

下面这张表是我在实际项目中总结的映射关系，你可以直接拿来当检查清单用：

嗯，这里要注意：“未知场景探索”是SOTIF特有的活动，功能安全里没有这个环节。为什么？因为功能安全假设“所有故障模式都是已知的”，而SOTIF承认“我们不可能预知所有危险场景”。

3.4 安全生命周期阶段划分——从概念到退役

我个人习惯把SOTIF生命周期分成四个大阶段，每个阶段都有明确的入口和出口标准：

阶段一：概念阶段

• 输入：系统需求、功能描述、目标ODD
• 活动：危害识别、风险评估、定义SOTIF安全目标
• 输出：SOTIF安全目标、ODD规范、场景库初版
• 避坑指南：我曾经在这个阶段犯过一个错误——ODD定义得太宽泛。比如“城市道路”这个描述，实际上包含了高架、隧道、施工区等几十种子场景。后来我学乖了，ODD一定要细化到“可测试”的粒度。

阶段二：开发阶段

• 输入：SOTIF安全目标、系统架构
• 活动：功能改进设计、安全机制实现、验证策略制定
• 输出：改进后的系统、测试用例、仿真模型
• 注意：这个阶段最容易出现的问题是“过度设计”。我见过一个团队给AEB系统加了7层冗余，结果系统响应延迟从200ms变成了500ms——反而更不安全了。

阶段三：验证与确认阶段

• 输入：开发完成的系统、测试计划
• 活动：已知场景验证、未知场景探索、实车路试
• 输出：验证报告、残余风险清单、确认声明
• 核心指标：场景覆盖率、误报率、漏报率

阶段四：运行与退役阶段

• 输入：量产系统、运行数据
• 活动：数据监控、事件分析、OTA升级、退役处理
• 输出：运行报告、安全档案、退役报告
• 我的建议：很多公司把SOTIF活动止步于量产，这是不对的。你想想看，系统在路上跑，每天都会遇到新的场景。如果不持续收集数据，你怎么知道当初的ODD假设还成立？

3.5 一个真实案例：V模型映射的坑

我曾经参与过一个L3级自动驾驶项目，团队严格按照V模型推进。但到了验证阶段，我们发现一个问题：左侧的“危害识别”和右侧的“验证测试”之间缺少对应关系。

具体来说，危害识别列出了50个危险场景，但测试团队只设计了30个测试用例。剩下的20个场景为什么没测？因为测试团队说“这些场景在仿真里复现不了”。

你看，这就是V模型映射没做好的典型问题。后来我们怎么解决的？我们建立了一个“双向追溯矩阵”：每个危害场景必须对应至少一个测试用例，如果某个场景确实无法测试，那就必须给出书面理由，并记录到“残余风险清单”中。