一、SOTIF 概述：从「功能安全」到「预期功能安全」

大家好，我是这次课程的主讲。咱们直接进入正题——SOTIF。

先问一个问题：你开着一辆带自适应巡航的车，前面突然窜出一只猫。传感器没识别出来，车没减速。这是功能安全的问题吗？

不是。传感器正常工作，控制器没坏，执行器也没卡滞。但系统就是没「理解」那个场景。这就是 SOTIF 要管的事。

1.1 什么是 SOTIF？

SOTIF，全称 Safety of the Intended Functionality，中文叫「预期功能安全」。说白了，就是系统在正常工作时，因为功能本身的设计局限或性能不足，导致的安全风险。

我个人的理解更直白：功能安全管「坏了怎么办」，SOTIF 管「没坏但不好使怎么办」。

举个例子：

• 功能安全场景：摄像头供电断了，系统检测到故障，降级或报警。
• SOTIF 场景：摄像头没坏，但逆光时白茫茫一片，啥也看不见。系统没报警，因为它「以为」自己工作正常。

你看，后者更隐蔽，也更危险。我在项目中遇到过好几次，测试工程师报「功能正常，但就是刹不住」。查到最后，都是传感器在特定场景下「瞎了」。

1.2 SOTIF 与功能安全的区别

很多刚接触的同学容易搞混。我习惯用一个表格来对比，清晰明了：

对比维度	功能安全 (ISO 26262)	SOTIF (ISO 21448)
核心问题	系统故障（硬件随机失效、系统失效）	功能局限（性能不足、设计缺陷、场景误判）
触发条件	故障发生（如传感器断路、芯片锁死）	触发事件出现（如强光、雨雾、异形车辆）
安全机制	故障检测、冗余、降级、安全状态	功能改进、性能提升、ODD 限制、用户提醒
验证方法	FMEA、FTA、故障注入测试	场景库测试、仿真、实车路采、长尾问题分析
标准	ISO 26262 (2018)	ISO 21448 (2022)

嗯，这里要注意：两者不是替代关系，是互补关系。一辆安全的自动驾驶车，既不能有硬件故障，也不能在正常工作时犯傻。

1.3 SOTIF 标准 ISO 21448 简介

ISO 21448 是 SOTIF 的专用标准，2022 年发布了正式版。它不像 ISO 26262 那么「重」，但逻辑链条非常清晰。

我把它拆成几个关键阶段：

1. 功能定义与场景分析：明确系统「该干什么」，以及「在什么场景下干」。
2. 识别触发事件：找出那些「功能正常但可能出问题」的场景条件。
3. 评估风险：判断这些触发事件是否会导致不可接受的风险。
4. 功能改进与验证：通过修改设计、增加限制或提升性能来降低风险。
5. 确认与释放：证明剩余风险可接受，系统可以上路。

标准里反复强调一个概念——触发事件 (Triggering Event)。这是 SOTIF 的核心分析单元。它指的是：在系统功能正常的前提下，某个场景条件导致系统输出不安全行为。

举个例子：

• 功能：自动紧急制动 (AEB)
• 触发事件：前方静止车辆 + 雨天 + 路面反光 + 摄像头对比度下降
• 结果：AEB 未触发，追尾

你看，每个部件都没坏，但组合在一起就出事了。这就是 SOTIF 要解决的「组合爆炸」问题。

1.4 SOTIF 知识体系框架

下面这张图是我自己整理的 SOTIF 知识体系，方便大家建立整体认知：

1.5 为什么实车验证离不开 SOTIF 场景设计？

你想想看，仿真能跑几百万公里，但永远跑不出真实世界的「意外」。实车验证的核心价值，就是发现那些仿真里没出现、设计时没想到、测试时没覆盖到的触发事件。

我个人的经验是：实车验证中的 SOTIF 场景设计，本质上是在「已知的未知」和「未知的未知」之间搭一座桥。已知的未知，比如雨雾天气，我们可以设计场景去测。未知的未知，比如某个城市特有的交通标识，只能靠实车路采去发现。

所以，这门课的核心就是教大家：如何系统性地设计实车验证场景，把 SOTIF 风险从「未知」变成「已知」，再从「已知」变成「可控」。