1. 课程导入
1.1 为什么会有 ISO 21448？—— 标准背景
说实话，我刚入行做功能安全那会儿，市面上只有 ISO 26262。大家脑子里想的都是「硬件随机失效」、「软件系统性失效」。那时候做 ADAS 项目，只要把 26262 的流程跑通了，就觉得万事大吉。
但后来出了问题。我记得 2016 年左右，有个 L2 级别的量产车在高速上把白色卡车车厢识别成了云朵，直接撞了上去。这事跟硬件故障没关系，传感器没坏，芯片没烧，软件也没跑飞。问题出在——场景超出了系统的「预期功能」范围。
这就是 SOTIF 要管的事。ISO 21448 的诞生，说白了就是补上 ISO 26262 管不到的那块盲区：没有故障，但系统依然不安全。
标准正式版在 2022 年发布，但行业里从 2019 年草案阶段就开始试跑了。我参与的第一个 SOTIF 项目，就是拿着 draft 版本边学边干，踩了不少坑。
核心驱动力：
- L2+ / L3 自动驾驶量产需求爆发
- 传统功能安全（ISO 26262）无法覆盖「性能局限」
- 多起与传感器/算法相关的重大事故推动监管
1.2 SOTIF 到底是什么？—— 定义拆解
SOTIF 全称是 Safety Of The Intended Functionality，中文叫「预期功能安全」。我习惯把它理解为：系统在正常工作状态下，会不会因为「想错了」或「没看到」而导致危险。
你想想看，一个 AEB 系统，硬件完好、软件无 bug，但就是没识别出横穿马路的行人——这不是故障，这是功能本身的局限性。SOTIF 就是专门处理这类问题的。
标准里把风险来源分成两类：
| 风险来源 | 典型例子 |
|---|---|
| 功能不足（Performance Insufficiency） | 传感器探测距离不够、算法在雨雾天气性能下降 |
| 触发条件（Triggering Conditions） | 逆光、隧道出入口、特殊交通标志、异形车辆 |
我的经验： 很多团队一开始只盯着「功能不足」，忽略了「触发条件」的组合效应。我曾经遇到一个项目，单看每个触发条件都没问题，但「雨天 + 夜间 + 对向远光灯」三个条件叠加，系统直接失效。SOTIF 分析一定要考虑条件组合。
1.3 与 ISO 26262 的关系 —— 不是替代，是互补
这是新人最容易搞混的地方。我经常被问到：「有了 21448，是不是就不用做 26262 了？」
答案很明确：两个都要做，而且必须配合。
我画了一张图来说明它们的关系：
我个人的理解是：ISO 26262 管的是「系统坏了怎么办」，ISO 21448 管的是「系统没坏但不够聪明怎么办」。一个完整的自动驾驶安全方案，两者缺一不可。
避坑提醒： 我曾经见过一个团队，在 SOTIF 分析中发现了传感器性能不足的问题，却试图用 ISO 26262 的「安全机制」来兜底——比如加冗余传感器。这方向就偏了。SOTIF 的核心是提升功能本身的能力，而不是靠故障容错来掩盖性能缺陷。
1.4 标准适用范围 —— 哪些项目需要做？
ISO 21448 的适用范围，标准原文写的是：L1 及以上驾驶自动化系统，且包含感知、决策、执行全链路。
但实际落地时，我建议你按这个标准来判断：
- 必须做： L2+ 以上的 ADAS / AD 系统（AEB、LKA、ACC、NOA、HWP）
- 建议做： L2 级系统，尤其是涉及视觉/雷达感知的（如 FCW、LDW）
- 可选择性做： L1 级单一功能（如单纯的 CMB），但如果有感知输入，还是建议覆盖
嗯，这里要注意：标准不适用于纯执行器类功能（比如 ESP、EPS 的底层控制），这些还是归 ISO 26262 管。
| 功能等级 | 典型功能 | SOTIF 必要性 |
|---|---|---|
| L0 | 信息报警（如 LDW 仅报警） | 可选 |
| L1 | ACC（纵向控制） | 建议 |
| L2 | ACC + LKA（组合辅助） | 必须 |
| L2+ / L3 | NOA、HWP、TJP | 强制 |
我的建议： 如果你的系统包含环境感知（摄像头、雷达、激光雷达）或行为决策（路径规划、意图预测），就老老实实把 SOTIF 纳入开发流程。别等到测试阶段才发现场景覆盖不全，那时候改成本就高了。
1.5 本章小结
ISO 21448 不是凭空冒出来的标准，它是自动驾驶行业「用事故换来的教训」。它跟 ISO 26262 是互补关系，一个管故障，一个管能力局限。适用范围上，只要你的系统有感知和决策，就逃不掉 SOTIF。