3、SOTIF开发流程总览：V模型在SOTIF中的应用、SOTIF开发阶段划分、与功能安全流程的协同
好，咱们直接切入正题。这一章我打算聊聊SOTIF的开发流程长什么样。你可能会问，功能安全有V模型，SOTIF也有吗？答案是——有，但又不完全一样。
我个人习惯把SOTIF的V模型看作是功能安全V模型的“孪生兄弟”。它们长得像，但内核不同。功能安全盯着系统性失效和随机硬件失效，而SOTIF盯着的是“功能不足”和“可预见的误用”。说白了，一个管“坏了怎么办”，一个管“设计得不够好怎么办”。
核心观点：SOTIF的V模型不是另起炉灶，而是在功能安全V模型的基础上，增加了对“未知不安全场景”的探索和消除。
3.1 V模型在SOTIF中的应用
先看这张图，这是我根据ISO 21448的框架重新梳理的SOTIF开发V模型。你仔细看，它和功能安全的V模型最大的区别在于——左侧多了“功能定义与规范”，右侧多了“功能评估与发布”。
嗯，这里要注意。V模型的左侧不是简单的“写文档”，而是“探索未知”。我在项目中遇到过最典型的例子——一个自动泊车功能，团队花了两周写需求文档，结果路试时发现系统在雨天识别不了地锁。为什么？因为左侧分析时根本没把“地锁被雨水反光”这个场景写进去。
我的经验：V模型左侧的“功能定义”阶段，一定要拉上测试工程师一起做头脑风暴。别让系统工程师闭门造车。你想想看，测试手里有大量实车数据，他们知道哪些场景容易出幺蛾子。
3.2 SOTIF开发阶段划分
ISO 21448把SOTIF开发分成了几个阶段。我习惯用更接地气的方式去理解——其实就是“找茬、评估、修、验证、确认”这五步。
| 阶段 | 核心活动 | 输出物 |
|---|---|---|
| 阶段1：功能定义 | 明确功能范围、运行设计域（ODD）、性能指标 | 功能规范、ODD定义文档 |
| 阶段2：危害识别 | 识别功能不足和可预见误用场景 | 危害清单、场景库 |
| 阶段3：风险评估 | 评估每个危害场景的风险等级 | 风险评估矩阵、SOTIF目标 |
| 阶段4：功能改进 | 通过设计、算法、传感器升级降低风险 | 改进方案、变更记录 |
| 阶段5：验证与确认 | 仿真测试、实车测试、用户验收 | 测试报告、残余风险评估 |
我特别想强调阶段2——危害识别。很多团队在这个阶段容易犯一个错误：只盯着“已知的已知”场景。比如知道大雾天摄像头看不清，但没想过“隧道出口强光+前方静止车辆”这种组合场景。我曾经在一个项目中，就是因为漏掉了“夜间对向远光灯+行人横穿”这个场景，导致AEB功能在测试中失效。后来我们专门建了一个“组合场景库”，把各种环境因素排列组合，才把覆盖率提上去。
避坑指南：我曾经见过一个团队，阶段3的风险评估做得特别粗糙——直接拿功能安全的ASIL等级往SOTIF上套。这是不对的。SOTIF的风险评估要考虑“触发事件发生的概率”和“系统响应的充分性”，和功能安全的“严重度、暴露率、可控性”是两套逻辑。
3.3 与功能安全流程的协同
好，接下来聊一个实际落地时最头疼的问题——SOTIF和功能安全怎么配合？
我的观点很明确：两者不是替代关系，而是互补关系。功能安全管“系统坏了怎么办”，SOTIF管“系统没坏但不够聪明怎么办”。
在实际项目中，我建议这样协同：
- 需求层面：功能安全的需求（比如ASIL等级）和SOTIF的需求（比如ODD边界）要放在同一个需求管理工具里。我习惯用条目化的方式，每条需求打上标签——是“安全需求”还是“SOTIF需求”。
- 测试层面：功能安全的测试用例（比如故障注入测试）和SOTIF的测试用例（比如场景遍历测试）可以共用测试平台。但要注意，SOTIF的测试更强调“未知场景的探索”，所以需要引入基于场景的测试生成工具。
- 评审层面：我建议两个流程的评审会合并开。因为很多问题其实是交叉的——比如一个传感器失效（功能安全）可能导致系统进入降级模式，而这个降级模式本身可能带来新的SOTIF风险（比如降级后感知能力不足）。
一个实用的协同框架：
- 先做功能安全危害分析（HARA），识别出系统性失效和硬件失效的风险。
- 再做SOTIF危害分析，识别出功能不足和误用的风险。
- 把两个清单合并，找出“交叉风险”——比如某个传感器失效后，系统降级运行，但降级后的功能是否足够安全？
- 针对交叉风险，制定联合应对措施。
我记得有一次，我们在做L2级车道保持功能时，功能安全分析发现摄像头故障需要降级到L1。但SOTIF分析发现，降级后系统只提供横向辅助，驾驶员需要突然接管——这个“突然接管”本身就是一个SOTIF风险。最后我们加了一个“渐进式降级”策略，给驾驶员3秒的过渡时间。你看，这就是协同的价值。
小技巧：在项目计划中，把SOTIF和功能安全的里程碑对齐。比如功能安全的“概念阶段评审”和SOTIF的“危害识别评审”放在同一周。这样两个团队可以互相review对方的输出，避免后期返工。
最后说一句，SOTIF和功能安全的协同，说白了就是“安全”这件事的一体两面。别把它们割裂开，也别试图用一个替代另一个。我见过最成功的项目，是两个团队共用同一个测试数据库、同一个问题跟踪系统、同一个评审委员会。这样效率最高，也最不容易漏掉风险。
公众号:蓝海资料掘金营，微信deep3321