1. SOTIF概述：什么是预期功能安全？

大家好，我是你们这期课程的主讲。在自动驾驶领域摸爬滚打了十几年，我见过太多「功能正常但事故照出」的案例。今天咱们就来聊聊这个让无数工程师头疼的话题——预期功能安全，也就是SOTIF。

先问大家一个问题：一辆车的刹车系统，硬件没坏、软件没bug，但就是在某个特定场景下没刹住车，这算不算安全问题？

算。而且这种问题，传统功能安全（ISO 26262）管不了。为什么？因为它不是「失效」导致的，而是「功能本身在特定场景下表现不足」导致的。这就是SOTIF要解决的核心矛盾。

1.1 从「功能安全」到「预期功能安全」

传统功能安全关注的是「系统出了故障怎么办」。比如传感器坏了、线束断了、芯片死机了——这些都是系统性失效或随机硬件失效。

但自动驾驶不一样。摄像头没坏，但逆光时看不清；雷达正常工作，但遇到金属护栏反射出假目标；算法没bug，但训练数据里没见过这种异形车……这些都不是「失效」，而是「功能在预期使用场景下，性能达不到安全要求」。

我个人习惯把这两者的区别总结成一句话：

说白了，SOTIF就是给自动驾驶系统做「能力边界测试」——你得知道你的系统在什么情况下会「力不从心」。

1.2 SOTIF的起源：一场事故引发的标准

SOTIF这个概念真正被行业重视，跟几起自动驾驶测试事故有关。我记得2016年那起特斯拉Autopilot事故，车辆在强光背景下没能识别出白色卡车车厢——传感器没坏、算法没报错，但就是没「看见」。这种事故，传统功能安全分析根本覆盖不到。

于是ISO开始着手制定专门针对「预期功能不足」的安全标准。2019年，ISO 21448第一版发布。2022年，更新版正式成为国际标准。

这个标准的核心逻辑其实很朴素：

• 场景是无限的，但测试是有限的——你不可能跑遍所有路况
• 系统性能有边界——传感器有物理极限，算法有能力上限
• 安全不是「不出错」——而是「在出错时，风险可接受」

1.3 ISO 21448标准框架：一张图看懂

下面这张图是我自己画的ISO 21448核心流程框架。你仔细看，它其实就回答了三个问题：

1. 系统在什么场景下会「不够好」？（场景分析与危害识别）
2. 这种「不够好」会导致什么后果？（风险评估）
3. 怎么让它「够好」？（功能改进与验证确认）

1.4 SOTIF与传统功能安全的关系

很多新手会问：SOTIF是不是要取代ISO 26262？不是。它们是互补关系。

对比维度	ISO 26262（功能安全）	ISO 21448（预期功能安全）
关注对象	系统性失效、随机硬件失效	功能性能不足、场景理解局限
典型问题	传感器坏了、线束断了、芯片死机	逆光看不清、雨雾遮挡、未见过场景
分析方法	FMEA、FTA、FMEDA	场景分析、触发条件分析、STPA
验证手段	故障注入、硬件加速测试	场景库测试、仿真、路测
安全目标	避免因失效导致危害	避免因功能不足导致危害

1.5 为什么自动驾驶必须做SOTIF？

你想想看，传统汽车的功能是「确定的」——踩刹车就减速，打方向盘就转向。但自动驾驶是「基于感知和决策的」，它面对的是无限变化的真实世界。

这就带来几个SOTIF特有的挑战：

• 传感器物理极限： 摄像头在黑夜、逆光、雨雾下性能会下降，这不是故障，是物理规律
• 算法认知局限： 深度学习模型对「没见过」的场景可能给出错误输出，而且你不知道它什么时候会错
• 场景组合爆炸： 天气、光照、道路、交通参与者、自车状态……这些因素组合起来，测试永远做不完

所以，SOTIF的核心方法论就是：承认系统有边界，然后通过系统化的方法找到这些边界，最后在边界内确保安全。