1. 功能安全概述：预期功能安全（SOTIF）到底是什么？
大家好，我是老张。在功能安全这个圈子里摸爬滚打了十几年，今天咱们来聊聊预期功能安全——也就是SOTIF。说实话，这个概念刚出来那会儿，我也觉得有点绕。但等你真正理解了，就会发现它其实是自动驾驶安全里绕不开的一环。
1.1 什么是预期功能安全（SOTIF）？
先问大家一个问题：一辆车明明没有硬件故障，也没有软件bug，为什么还会出事故？
我遇到过这样一个案例。某款L2级辅助驾驶系统，在高速上遇到前方静止的白色卡车，摄像头愣是没识别出来——因为卡车和天空的颜色太接近了。传感器没坏，算法也没崩溃，但就是没检测到。这就是典型的SOTIF问题。
预期功能安全，英文叫Safety of the Intended Functionality，简称SOTIF。它关注的是：当系统在预期功能范围内运行时，由于功能本身的局限性或性能不足，导致的安全风险。
说白了，就是系统“能力不够”引发的问题。比如：
- 传感器在雨雾天气性能下降
- 算法对罕见场景的识别率低
- 系统对驾驶员行为的误判
核心定义：SOTIF关注的是“功能本身是否足够安全”，而不是“功能是否被正确实现”。
1.2 为什么需要SOTIF？
你可能会问：ISO 26262不是已经覆盖了功能安全吗？为什么还要搞个SOTIF？
嗯，这里有个关键区别。ISO 26262处理的是“系统故障”——比如芯片烧了、代码跑飞了、线路断了。但自动驾驶面临的最大挑战，其实是“系统没坏，但能力不够”。
我举个例子你就明白了。传统汽车的安全气囊，只要传感器和控制器正常工作，该爆的时候就会爆。但自动驾驶不一样——摄像头可能因为逆光而“失明”，雷达可能因为多径反射而“看花眼”。这些都不是故障，而是功能的固有局限。
所以，SOTIF的出现，就是为了填补这个空白。它专门处理：
- 传感器性能不足：比如激光雷达在浓雾中探测距离下降
- 算法局限性：比如对“鬼探头”场景的预测能力有限
- 系统边界模糊：比如ODD（运行设计域）的边界定义不清晰
- 人机交互误判：比如驾驶员过度依赖系统导致接管不及时
我的经验：曾经有个项目，我们花了大量精力做ISO 26262的硬件随机故障分析，结果路测时发现，90%的安全事件都来自传感器性能衰减——而不是硬件故障。从那以后，SOTIF就成了我团队的重点关注对象。
1.3 SOTIF与ISO 26262的区别与联系
这两个标准的关系，我习惯用一个比喻来解释：
ISO 26262是“别生病”，SOTIF是“别犯傻”。
具体来说：
| 维度 | ISO 26262（功能安全） | SOTIF（预期功能安全） |
|---|---|---|
| 关注对象 | 系统故障（硬件/软件） | 功能局限（性能/场景） |
| 风险来源 | 随机硬件失效、系统故障 | 传感器局限、算法不足、场景覆盖不全 |
| 分析方法 | FMEA、FTA、FMEDA | STPA、场景分析、触发条件分析 |
| 安全目标 | 避免因故障导致危害 | 避免因功能不足导致危害 |
| 适用阶段 | 全生命周期 | 概念阶段、开发阶段、验证阶段 |
但两者不是割裂的。实际上，它们有很强的互补性：
- 共同目标：都是为了让车辆更安全
- 相互依赖：SOTIF分析的结果，会影响ISO 26262的安全目标定义
- 验证互补：ISO 26262的故障注入测试，和SOTIF的场景覆盖测试，缺一不可
注意：千万不要把SOTIF当成ISO 26262的“替代品”。它们是两条腿走路，缺一条都站不稳。
1.4 SOTIF的核心目标
SOTIF的核心目标，用一句话概括就是：确保系统在预期功能范围内，不会因为功能本身的局限性而导致不可接受的风险。
具体来说，有四个关键目标：
- 识别功能局限：搞清楚系统在哪些场景下“能力不够”
- 评估风险等级：判断这些局限是否会导致不可接受的风险
- 降低风险至可接受水平：通过设计改进、功能限制、驾驶员监控等手段
- 验证剩余风险：通过大量测试和仿真，证明风险已经足够低
你想想看，如果一个自动驾驶系统在99%的场景下都表现完美，但就是那1%的“长尾场景”会出问题——那它依然是不安全的。SOTIF要做的，就是把这1%也找出来，并且处理掉。
下面这张图，是我自己总结的SOTIF核心逻辑框架，你可以看看：
一句话总结：SOTIF不是要消灭所有风险，而是要把风险降低到“可接受”的水平。这个“可接受”的标准，取决于你的ODD定义、功能设计以及验证的充分性。
好了，关于SOTIF的基本概念，咱们就聊到这儿。记住一句话：没有完美的传感器，也没有完美的算法。SOTIF要做的，就是承认不完美，然后想办法让不完美的系统依然安全。
公众号:蓝海资料掘金营，微信deep3321