1. SOTIF概述：预期功能安全（SOTIF）的定义、与功能安全的区别、ISO 21448标准框架
大家好，我是老张。今天咱们开始聊预期功能安全，也就是SOTIF。说实话，这个概念在自动驾驶圈子里，这几年越来越热。我记得2018年我刚接触这个领域时，很多人还分不清SOTIF和功能安全到底有啥区别。嗯，今天咱们就把这事儿彻底捋清楚。
1.1 什么是预期功能安全？
先给个官方定义。预期功能安全，英文叫Safety of the Intended Functionality，简称SOTIF。它指的是：在系统没有故障的情况下，由于功能本身的局限性或环境干扰，导致的安全风险。
你想想看，传统功能安全（ISO 26262）解决的是“系统坏了怎么办”。比如传感器坏了、芯片失效了、软件跑飞了。但SOTIF解决的是另一个问题——系统没坏，但就是干不好活。
核心区别一句话：
- 功能安全：系统坏了，要保证安全
- 预期功能安全：系统没坏，但能力不够，也要保证安全
举个例子。我在一个L4级自动驾驶项目中遇到过这种情况：摄像头没坏，算法也没报错，但就是没识别出前方白色卡车——因为那天是大雾天，卡车和背景融为一体。这就是典型的SOTIF问题。系统功能是正常的，但感知能力在特定场景下不够用。
1.2 SOTIF与功能安全的区别
很多工程师刚接触时容易混淆。我建议用一张表来对比，这样更直观。
| 对比维度 | 功能安全（ISO 26262） | 预期功能安全（ISO 21448） |
|---|---|---|
| 关注点 | 系统故障（硬件随机失效、系统失效） | 功能局限、性能不足、环境干扰 |
| 系统状态 | 系统存在故障 | 系统无故障，但能力不足 |
| 典型场景 | 传感器断路、芯片死机、软件跑飞 | 传感器被遮挡、算法误检、极端天气 |
| 分析方法 | FMEA、FTA、FMEDA | STPA、触发条件分析、场景分析 |
| 安全目标 | 避免因故障导致危害 | 避免因功能局限导致危害 |
说白了，功能安全是“防坏”，SOTIF是“防蠢”。系统没坏但不够聪明，一样会出事故。我曾经在一个项目中吃过亏——我们花了大量精力做功能安全，结果路测时发现，系统在隧道出口处频繁误刹车。原因很简单：GPS信号丢失后，定位漂移了。系统没坏，但定位功能在隧道场景下就是不行。这就是SOTIF的典型问题。
⚠️ 避坑指南：
我曾经见过一个团队，把SOTIF问题当成功能安全来处理。他们给感知算法加了一堆冗余校验，结果误检率反而更高了。记住：SOTIF问题的根因是“能力不足”，不是“系统故障”。加冗余解决不了能力问题，你得从算法、传感器选型、场景覆盖这些角度入手。
1.3 ISO 21448标准框架
ISO 21448是专门针对预期功能安全的标准。它和ISO 26262是互补关系，不是替代关系。我个人的理解是：26262管“硬件坏了怎么办”，21448管“功能不够用怎么办”。
标准的核心框架，我画了一张图，大家看看。
这个框架其实挺直观的。第一步是定义你的功能到底要干什么。比如“自动紧急制动（AEB）”，你得说清楚：在什么车速范围内工作？能识别哪些目标？最大减速度是多少？
第二步是找触发条件。说白了，就是找“什么情况下系统会掉链子”。我习惯把触发条件分成三类：
- 环境因素：雨雾、逆光、夜间、隧道
- 场景因素：十字路口、环岛、施工区
- 目标因素：异形车、行人打伞、动物横穿
第三步是评估风险。标准里用了S（严重度）、E（暴露率）、C（可控性）三个维度。这和功能安全有点像，但评估的是“功能局限”带来的风险，不是“故障”带来的风险。
第四步是改进。怎么改？我总结了几种常见手段：
- 传感器升级：比如加激光雷达，解决摄像头在暗光下的问题
- 算法优化：比如增加数据增强，提升模型在雨雾天的鲁棒性
- 功能降级：比如感知置信度低时，主动降低车速
- ODD限制：比如明确告诉用户，这个功能不能在夜间使用
💡 个人经验：
我在做SOTIF分析时，最常用的工具是STPA（系统理论过程分析）。它比传统FMEA更适合分析“功能不足”的问题。举个例子，用FMEA分析AEB，你可能会写“传感器故障导致不制动”。但用STPA，你会分析“传感器在逆光场景下输出不稳定，导致控制器误判”。后者才是SOTIF真正关心的。
最后一步是确认和释放。标准要求，你得有证据证明：已知的风险已经降到可接受水平，未知的风险也在持续降低。说白了，不能拍脑袋说“我觉得没问题”，你得有测试数据、仿真结果、场景覆盖率报告。
1.4 为什么SOTIF对感知系统特别重要？
这个问题我经常被问到。我的回答很简单：感知系统是SOTIF问题的重灾区。
你想想看，决策规划系统出问题，往往是逻辑错误，可以靠规则修复。执行器出问题，往往是机械故障，可以靠冗余解决。但感知系统呢？它面对的是无限多的场景、无限多的环境变化。你永远无法穷举所有可能的输入。
我记得有一次，我们测试一个行人检测模型。在标准数据集上，mAP（平均精度）高达95%。但一上路，问题就来了：
- 穿黑色衣服的行人在夜间几乎检测不到
- 打伞的行人经常被漏检
- 骑自行车的人被误检成摩托车
这些都不是故障，都是“能力不足”。这就是SOTIF要解决的问题。
总结一下本章核心：
- SOTIF解决的是“系统没坏但能力不够”的安全问题
- 与功能安全的区别：一个防故障，一个防局限
- ISO 21448框架：定义→分析→评估→改进→确认
- 感知系统是SOTIF的重灾区，需要重点分析
好了，这一章就聊到这儿。SOTIF这个概念，说白了就是让我们正视一个事实：再好的系统也有局限性。关键不是追求完美，而是把已知的局限管好，把未知的风险降到最低。下一章咱们深入聊聊触发条件分析，那是SOTIF最核心的活儿。
公众号:蓝海资料掘金营，微信deep3321