1. 课程导入
1.1 从一次“幽灵刹车”说起
2018年，我参与的一个L2级辅助驾驶项目在高速路测时，系统突然对路侧的一个广告牌急刹车。车内工程师们面面相觑——传感器明明没坏，算法也没报错，但车就是“抽风”了。
这就是典型的预期功能安全（SOTIF）问题。不是硬件故障，不是软件bug，而是系统在设计预期之外的场景下做出了危险行为。
核心定义：预期功能安全（SOTIF）关注的是——当系统没有发生故障时，由于功能不足或设计局限导致的安全风险。
说白了，传统功能安全（ISO 26262）管的是“系统坏了怎么办”，而SOTIF管的是“系统没坏但不够聪明怎么办”。
1.2 SOTIF的起源：为什么我们需要它？
2016年，特斯拉Autopilot在佛罗里达发生致命事故——系统把白色卡车车身误识别为天空。传感器没坏，算法在跑，但就是没“看懂”场景。
这件事在行业内炸开了锅。我当时的团队正在做AEB（自动紧急制动）系统标定，老板连夜开会问：“我们的车会不会也这样？”
答案是：会。只要系统依赖传感器感知环境，就必然存在感知盲区、算法局限、场景覆盖不全的问题。
于是，ISO 21448标准应运而生。它的全称是：
Road vehicles — Safety of the intended functionality
（道路车辆 — 预期功能安全）
标准第一版发布于2019年，2022年更新为第二版。它专门解决“无故障但危险”的问题。
| 对比维度 | ISO 26262（功能安全） | ISO 21448（SOTIF） |
|---|---|---|
| 关注对象 | 系统故障（硬件/软件） | 功能不足/设计局限 |
| 触发条件 | 故障发生 | 场景超出设计范围 |
| 典型问题 | 传感器失效、内存溢出 | 误识别、漏检、控制策略不当 |
| 分析方法 | FMEA、FTA、FMEDA | 场景分析、触发条件识别 |
| 验证手段 | 故障注入测试 | 场景库测试、仿真验证 |
我的经验：很多团队一开始把SOTIF当成“功能安全的补充”，结果做着做着发现——SOTIF的工作量比功能安全还大。因为场景是无限的，而故障模式是有限的。
1.3 SOTIF的核心逻辑：三个关键问题
ISO 21448把SOTIF问题归结为三个层次：
- 功能不足——系统能力不够。比如摄像头在逆光下看不清行人。
- 触发条件——什么场景下会暴露功能不足。比如“傍晚+逆光+穿深色衣服的行人”。
- 危害事件——最终导致什么后果。比如“AEB未触发，车辆撞人”。
我习惯用一个公式来理解：
SOTIF风险 = 功能不足 + 触发条件 → 危害事件
举个例子：
- 功能不足：毫米波雷达对静止目标置信度低
- 触发条件：高速公路上前方有静止故障车辆
- 危害事件：ACC未减速，追尾
你看，传感器没坏，算法没报错，但就是没识别出来。这就是SOTIF要解决的问题。
1.4 ISO 21448标准框架速览
标准的核心流程可以用一张图概括。我画了一个简化版：
这个流程不是线性的。我做过好几个项目，每次都是“场景分析→发现新问题→改功能→重新分析”的循环。标准也明确说了：SOTIF是一个迭代过程。
1.5 避坑指南：新手最容易犯的三个错误
错误一：把SOTIF当成功能安全的子集
我曾经见过一个团队，拿着ISO 26262的FMEA表格直接套到SOTIF上。结果分析出来的全是“传感器故障”、“通信中断”这类东西，真正的场景问题一个没抓到。
正确做法：SOTIF的分析对象是“场景”和“触发条件”，不是“故障模式”。工具和方法都要换。
错误二：只分析已知场景
有个项目做了2000多个场景的测试，自认为覆盖很全。结果上路第一天就遇到了“洒水车+彩虹+逆光”的组合场景——系统直接失明。
正确做法：用“场景参数组合”的方法生成未知场景，而不是只靠经验列举。
错误三：忽视人的因素
SOTIF标准明确要求考虑“合理可预见的误用”。比如驾驶员把饮料洒在中控台上、儿童把玩具放在方向盘上——这些不是故障，但会触发危险。
正确做法：在场景分析中纳入“人-机交互”维度。
1.6 本章小结：你需要记住的三句话
| 序号 | 核心要点 | 一句话记忆 |
|---|---|---|
| 1 | SOTIF的定义 | 系统没坏，但不够聪明导致危险 |
| 2 | SOTIF的起源 | 自动驾驶场景复杂，故障安全不够用 |
| 3 | ISO 21448的核心 | 找功能不足→找触发条件→评估风险→迭代改进 |
我的建议：如果你刚开始接触SOTIF，别急着啃标准全文。先找你们系统的一个典型功能（比如AEB、ACC），试着用“功能不足+触发条件”的框架分析一遍。做完一个功能，你就知道SOTIF到底在干什么了。