1. SOTIF概述：什么是预期功能安全？为什么需要SOTIF？SOTIF与功能安全的区别与联系
1.1 先聊聊我为什么开始关注SOTIF
几年前，我参与了一个L3级自动驾驶项目。测试时发现，车辆在暴雨天突然急刹车——明明前方没有任何障碍物。查来查去，不是传感器坏了，也不是算法算错了。问题出在哪？
说白了，系统本身没故障，但环境超出了它的「理解能力」。这就是预期功能安全要解决的事。
你可能也遇到过类似情况。功能安全（ISO 26262）管的是「系统坏了怎么办」，但SOTIF管的是「系统没坏，但表现不对怎么办」。这两者，缺一不可。
1.2 什么是预期功能安全？
预期功能安全，英文叫Safety of the Intended Functionality，简称SOTIF。它关注的是：系统在没有故障的情况下，会不会因为功能设计缺陷或环境感知局限，导致危险发生。
我习惯用一个比喻来理解：
- 功能安全：就像你开车时刹车突然失灵——这是硬件/软件故障，需要冗余和监控。
- SOTIF：就像你开车时遇到大雾，摄像头看不清路标——设备没坏，但环境让它「瞎了」。
嗯，这里要注意：SOTIF不是替代功能安全，而是补上功能安全管不到的那块。
核心定义（ISO 21448）：
预期功能安全是指，在系统没有故障的情况下，由于功能不足或可预见的人员误用，导致危害发生的风险被控制在可接受范围内。
1.3 为什么需要SOTIF？
你想想看，现在的智能驾驶系统越来越复杂。传感器有摄像头、雷达、激光雷达……每个都有局限性。
举个例子：
- 摄像头在强光下可能过曝
- 雷达对静止物体识别不稳定
- 激光雷达在雨雪天气性能下降
这些都不是「故障」，但确实可能引发事故。我在项目中就遇到过：一辆测试车在隧道出口，因为光线突变，摄像头把阴影误判成了障碍物，直接刹停。后车差点追尾。
所以，SOTIF的必要性在于：
- 传统功能安全覆盖不了——它只管故障，不管「能力不足」
- 自动驾驶场景太复杂——你没法穷举所有边缘场景
- 法规要求越来越严——ISO 21448已经成为行业标配
我的建议：做SOTIF分析时，别只盯着传感器。算法、执行器、甚至驾驶员的误操作，都要考虑进去。我曾经吃过亏，只分析了感知层，结果决策层出了漏洞。
1.4 SOTIF与功能安全的区别与联系
很多新手会混淆这两个概念。我整理了一张对比表，帮你快速理清：
| 对比维度 | 功能安全（ISO 26262） | 预期功能安全（ISO 21448） |
|---|---|---|
| 关注对象 | 系统故障（随机硬件失效、系统失效） | 功能不足、性能局限、可预见误用 |
| 触发条件 | 硬件/软件出现故障 | 系统无故障，但环境或场景超出设计范围 |
| 典型场景 | 传感器突然断电、通信中断 | 强光导致摄像头过曝、雨雪遮挡雷达 |
| 分析方法 | FMEA、FTA、FMEDA | STPA、HAZOP、场景分析 |
| 安全目标 | 避免因故障导致危害 | 避免因功能不足导致危害 |
| 标准状态 | 成熟，已广泛应用 | 较新，正在快速普及 |
它们的联系也很紧密：
- 目标一致：都是为了降低系统风险
- 互为补充：功能安全管「坏了」，SOTIF管「没坏但不行」
- 分析流程相似：都从危害识别开始，到风险接受结束
注意：不要以为做了功能安全，SOTIF就可以忽略。我见过不少项目，功能安全等级做到ASIL D，结果SOTIF分析没做，上路测试时频频出问题。两者必须并行推进。
1.5 SOTIF的核心逻辑框架
下面这张图，是我自己总结的SOTIF核心逻辑。它帮你理解整个分析过程：
这个框架的核心逻辑是：先搞清楚系统「想做什么」「在什么环境下做」「有什么局限」，然后分析这些局限会不会导致危害，最后通过措施把风险降到可接受水平。
1.6 一个真实案例帮你理解
我参与过一个AEB（自动紧急制动）项目。功能安全分析做了很多，但SOTIF分析一开始没重视。
后来测试发现：
- 在雨天，雷达对前方静止车辆的检测距离从150米降到40米
- 在隧道出口，摄像头需要2-3秒才能适应光线变化
- 在弯道，系统可能把路边的金属护栏误判为车辆
这些都不是故障，但确实会导致AEB失效或误触发。我们后来通过SOTIF分析，增加了传感器融合策略，优化了算法，才把风险降下来。
经验之谈：做SOTIF分析时，一定要结合真实场景数据。光靠头脑风暴，你永远想不到「洒水车经过时，水雾会让激光雷达产生虚警」这种场景。
1.7 小结
预期功能安全，说白了就是：系统没坏，但能力不够，怎么办？
它和功能安全是「兄弟关系」，一个管故障，一个管局限。两者结合，才能构建真正安全的智能系统。
下一章，我们会深入SOTIF的分析方法——STPA和HAZOP。到时候我会分享一些实际项目中的踩坑经验。
公众号:蓝海资料掘金营，微信deep3321