1. SOTIF 概述：到底什么是 SOTIF？

大家好，欢迎来到这门课的第一章。

咱们开门见山。SOTIF，全称是 Safety Of The Intended Functionality，中文叫「预期功能安全」。

听起来有点绕口，对吧？

我换个说法。你想想看，一辆车，它的所有零件都符合功能安全标准（比如 ISO 26262），是不是就绝对安全了？

不一定。

我在项目里就遇到过这种情况。传感器没坏，算法也没跑飞，但车就是在大晴天把路边的白色大卡车当成了「天空」，一头撞了上去。为什么？因为传感器本身的「感知能力」在特定场景下不够用。

这就是 SOTIF 要解决的问题——功能本身没有失效，但它的「预期功能」在特定场景下引发了危害。

1.1 SOTIF 的起源：为什么会有这个标准？

传统汽车安全，主要盯着「东西坏了怎么办」。比如刹车失灵、气囊弹不开，这些属于功能安全范畴。

但到了自动驾驶时代，情况变了。

系统没坏，但「看错了」或者「想错了」。比如：

• 传感器局限：摄像头在逆光下失效，雷达对金属罐误判。
• 算法不足：把路边的塑料袋识别成障碍物，急刹车。
• 场景覆盖不全：系统没学过「施工路段临时改道」，直接懵了。

这些事故，用传统功能安全根本解释不通。于是，ISO 21448 标准应运而生。它专门针对「功能没坏，但功能本身不安全」的问题。

1.2 SOTIF 与功能安全的关系：不是替代，是互补

很多人问我：「有了功能安全，为什么还要搞 SOTIF？」

我打个比方。功能安全是给车配了「安全带和气囊」，保证撞车时人没事。SOTIF 是保证「车别莫名其妙去撞墙」。

两者缺一不可。我整理了一个对比表，方便你理解：

维度	功能安全 (ISO 26262)	SOTIF (ISO 21448)
关注点	系统故障、硬件随机失效、软件系统错误	功能性能不足、场景覆盖不全、合理可预见的误用
核心问题	「东西坏了怎么办？」	「东西没坏，但不够聪明怎么办？」
触发条件	故障发生	触发场景出现（如恶劣天气、特殊路况）
分析方法	FMEA、FTA、FMEDA	STPA、场景分析、触发条件识别
输出物	安全目标、安全机制、ASIL 等级	功能不足清单、触发条件列表、安全措施

1.3 SOTIF 在自动驾驶中的重要性：为什么非学不可？

说实话，L2 级别的辅助驾驶，SOTIF 问题还不算致命。毕竟驾驶员是最终责任人。

但到了 L3 以上，系统承担驾驶任务，驾驶员可以玩手机。这时候，如果系统因为「没见过的场景」出了事故，责任全在车厂。

我举几个真实案例：

• 案例 A：某品牌车辆在高速上，把前方静止的故障车辆误识别为「路牌」，直接撞上去。事后分析，传感器和算法都没坏，只是训练数据里缺少「静止车辆在车道内」的场景。
• 案例 B：夜间行车，摄像头把前方卡车的尾部灯光误判为「远处的城市灯光」，系统认为距离很远，没有减速。这也是典型的 SOTIF 问题——传感器在低照度下的性能不足。

这些事故，用功能安全的方法论根本查不出来。因为系统本身没有「失效」，它只是在「不该工作的时候工作了」。

1.4 本章知识体系：一张图看懂 SOTIF

下面这张图，是我自己画的知识框架。它把 SOTIF 的核心逻辑串起来了。建议你保存下来，后面每学一章，都可以回来对照一下。

1.5 小结：你该带走什么？

这一章，我不希望你记住太多细节。你只需要带走三句话：

1. SOTIF 不是功能安全的替代品，它是功能安全的「好搭档」。一个管「坏」，一个管「蠢」。
2. SOTIF 的核心是「场景」。系统安不安全，不只看它自己，还要看它「在什么场景下工作」。
3. SOTIF 的终极目标：把所有「未知的不安全场景」变成「已知的安全场景」。