第2章：SOTIF开发流程：V模型在SOTIF中的应用

说实话，做功能安全的人对V模型都不陌生。但SOTIF的V模型，跟传统功能安全的V模型，其实有挺大区别的。我刚开始接触SOTIF时，也犯过糊涂——以为直接把ISO 26262那套V模型搬过来就行。结果呢？项目做到一半发现，很多活动根本对不上号。

今天我就把SOTIF的V模型掰开揉碎了讲。你想想看，SOTIF的核心是处理「未知的不安全场景」，而功能安全处理的是「已知的风险」。这两者的V模型，侧重点自然不一样。

2.1 V模型在SOTIF中的定位

V模型在SOTIF里，说白了就是一个「双向验证」的框架。左边是设计阶段，右边是验证阶段，中间是系统实现。我个人习惯把SOTIF的V模型分成三层：

• 顶层：整车级SOTIF活动（ODD定义、功能定义）
• 中间层：系统级SOTIF活动（HARA、安全概念）
• 底层：软硬件级SOTIF活动（实现与测试）

嗯，这里要注意：SOTIF的V模型不是凭空造出来的。它是在ISO 26262的V模型基础上，增加了专门针对「未知场景」的处理环节。我在项目中遇到过，很多团队直接把功能安全的V模型拿来用，结果SOTIF的验证活动完全没覆盖到——比如ODD的边界测试、未知场景的探索性测试。

2.2 SOTIF开发阶段划分

按照ISO 21448的推荐，SOTIF的开发阶段可以划分为6个主要阶段。我习惯把它们对应到V模型的左右两侧：

阶段	V模型左侧（设计）	V模型右侧（验证）
阶段1	ODD定义与功能定义	ODD覆盖性验证
阶段2	HARA与风险识别	风险分析完整性验证
阶段3	安全概念设计	安全概念有效性验证
阶段4	功能实现与集成	功能实现验证
阶段5	未知场景分析	未知场景探索性测试
阶段6	残余风险接受	残余风险评估

你看这个表格，阶段5是SOTIF特有的。功能安全里没有「未知场景分析」这个阶段。我曾经在一个L3级自动驾驶项目里，就是因为忽略了阶段5，结果在实车测试时遇到了一个从未见过的场景——雨夜中的反光路锥。嗯，从那以后，我再也不敢跳过未知场景分析了。

2.3 SOTIF活动与功能安全活动的集成

这是实际项目中最容易出问题的地方。SOTIF和功能安全不是两个独立的活动，它们需要紧密集成。我建议的做法是：

1. 共享HARA结果：功能安全的HARA结果可以直接用于SOTIF的风险分析。但要注意，SOTIF需要额外关注「未知场景」的风险。
2. 统一安全概念：功能安全的安全概念（如故障容错）和SOTIF的安全概念（如功能降级）需要在一个框架下设计。
3. 联合验证策略：功能安全的验证（如故障注入测试）和SOTIF的验证（如场景探索测试）可以共用测试平台。

举个例子，我在一个自动紧急制动（AEB）项目中，功能安全团队做了故障注入测试，SOTIF团队做了场景探索测试。两个团队各自为政，结果发现：故障注入测试覆盖的场景，SOTIF团队已经测过了；而SOTIF团队发现的未知场景，功能安全团队根本没考虑过。后来我们合并了测试计划，效率提升了至少30%。

2.4 避坑指南：V模型应用中的常见问题

我曾经踩过不少坑，这里分享几个典型的：

• 坑1：V模型左右不对称——左侧设计太粗，右侧验证太细。结果验证时发现设计缺陷，返工成本极高。
• 坑2：忽略迭代——SOTIF的V模型不是一次性的。发现新场景后，需要回到左侧重新分析。
• 坑3：ODD定义模糊——ODD定义得不够精确，导致验证时不知道哪些场景该测，哪些不该测。

好了，这一章的内容就到这里。下一章我会详细讲ODD的定义与分析——这是SOTIF的基石，也是很多项目翻车的地方。