3. SOTIF验证的总体工程框架

SOTIF（Safety of the Intended Functionality，预期功能安全）验证不是一次性测试活动，而是一条贯穿产品全生命周期的工程主线。ISO 21448 给出的核心思想是：对于没有硬件随机失效、却因性能局限、场景理解不足或可合理预见误用而导致的不安全行为，必须在概念阶段就定义可接受准则，并沿着开发V模型逐层分解、逐层验证，最终在运行阶段通过现场数据闭环反馈。Bosch在L2/L2+驾驶辅助项目的实践中，把这条主线固化为"概念—系统—组件—集成—整车—运行"的六层结构。

理解这条主线，关键要抓住两个方向：左侧下行是"需求与约束的分解"，右侧上行是"证据与结果的汇聚"。左侧每一层都要回答"这一层允许出现什么、不允许出现什么"，右侧每一层都要回答"我拿什么证据证明它做到了"。SOTIF的特殊之处在于，它的验证对象不是"是否失效"，而是"是否足够好"——因此每一层的可接受准则都必须可度量、可追溯。

验证与确认：两条不同的证据链

在SOTIF语境下，"验证"（Verification）与"确认"（Validation）常被混用，但它们的证据链完全不同。验证回答的是"我是否按需求正确地构建了系统"，对象是需求、设计、组件，手段以评审、分析、SIL/HIL为主，输出的是符合性证据。确认回答的是"我是否构建了正确的功能"，对象是整车与真实场景，手段以实车测试、场景库回放、现场监控为主，输出的是可接受性证据。

举例说明：某AEB功能的感知模块要求"在80m内识别静止车辆，漏检率低于1%"。在组件阶段用SIL注入1000个静止车辆场景，测得漏检率0.8%，这是验证——证明组件满足了下发的指标。但整车阶段在黄昏逆光、雨天湿滑路面下实测，发现漏检率升至3.5%，这是确认——证明"1%漏检率"这个需求本身在真实ODD下可能不够充分。SOTIF的难点恰恰在于：验证通过不等于确认通过，因为需求本身可能对场景理解不足。

SOTIF活动裁剪原则

并非所有项目都需要完整执行六层活动。Bosch的裁剪原则基于三个维度：ODD复杂度、场景风险等级、以及功能与SOTIF的相关性。对于ODD简单（如封闭园区低速泊车）、场景风险低的功能，可以合并系统与组件阶段的活动，复用已有场景库；对于ODD复杂（如城市NOA）、涉及行人交互的高风险功能，则必须完整执行，并增加边界场景探索的深度。

裁剪不是删减，而是"有依据的简化"。任何裁剪结论都必须记录在SOTIF计划中，说明裁剪理由、替代证据、以及残余风险评估，并经安全经理评审。常见的裁剪错误是"因为时间紧所以跳过整车确认"，这会导致未知不安全场景无法暴露，属于不可接受的裁剪。

Bosch项目中的SOTIF工作产品清单

在Bosch的L2+项目中，SOTIF工作产品按阶段组织，每个产品都有明确的输入、输出与责任人。以下清单为示例性结构，实际项目会根据裁剪结果调整：

需要强调的是，工作产品清单不是"交文档"的清单，而是"证据链"的清单。每一份产品都必须能回答：它支撑了哪一条可接受准则？它的证据强度是否足够？如果运行阶段发现新的触发条件，能否快速回溯到概念阶段的哪一条假设？只有形成这样的闭环，SOTIF验证才真正落地。