一、预期功能安全（SOTIF）概述
大家好，我是老张。在功能安全领域摸爬滚打了十几年，今天咱们来聊聊SOTIF——预期功能安全。
说实话，我第一次接触这个概念时，也觉得它跟功能安全差不多。但做着做着就发现，这里面的坑，远比想象的多。
1.1 什么是预期功能安全？
先给个官方定义：预期功能安全（SOTIF，Safety Of The Intended Functionality），指的是系统在无故障情况下，由于功能本身的设计局限或性能不足，导致的安全风险。
你想想看，传统功能安全处理的是“系统坏了怎么办”。比如刹车失灵、传感器断线——这些都是硬件或软件的随机故障。但SOTIF处理的是什么呢？是“系统没坏，但就是干不好活”。
核心区别一句话：
- 功能安全：系统坏了，出事了
- 预期功能安全：系统没坏，但能力不够，出事了
举个例子。我在做L3级自动驾驶项目时，遇到过这么个情况：摄像头没坏，算法也没报错，但傍晚逆光行驶时，系统就是没识别出前方静止的卡车。嗯，这就是典型的SOTIF问题——传感器性能在特定场景下不足。
1.2 为什么它比功能安全更复杂？
这个问题，我经常被刚入行的同事问起。说白了，原因有三：
- 边界模糊：功能安全的故障模式是有限的（芯片烧了、线路断了），但SOTIF的触发条件几乎是无限的。你想想看，天气、光照、道路标线磨损、行人穿奇装异服……这些都可能成为触发条件。
- 难以穷举：我记得有个项目，我们花了三个月做SOTIF场景分析，最后发现还有30%的场景根本没想到。为什么？因为真实世界的组合太多了。
- 验证困难：功能安全可以用故障注入来测试，但SOTIF呢？你怎么模拟“一个穿着Cosplay服装的小孩突然从路边窜出来”？
避坑指南：
我曾经犯过一个错误——把SOTIF分析当成功能安全分析来做。结果呢？场景库建得很大，但真正有效的场景没几个。后来我才明白，SOTIF的核心不是“找故障”，而是“找能力边界”。
1.3 SOTIF的起源与ISO 21448标准框架
SOTIF这个概念，其实是从实际事故中“长”出来的。2016年特斯拉Autopilot事故后，整个行业都在反思：系统没坏，但为什么出事了？
ISO 21448就是在这样的背景下诞生的。它于2022年正式发布，专门针对预期功能安全。
这个标准的核心框架，我习惯用一张图来理解：
ISO 21448核心流程：
- 功能定义与场景分析：搞清楚系统要干什么，在什么环境下干
- 危害识别与风险评估：找出功能不足可能导致的危害
- 功能改进与验证：通过设计优化或感知增强来降低风险
- 残余风险评估：确认剩下的风险是否可接受
下面这张图，是我自己总结的SOTIF知识体系框架，你看完应该能有个整体印象：
这张图你看懂了吗？SOTIF不是孤立存在的，它跟功能安全是互补关系。功能安全管“坏了怎么办”，SOTIF管“没坏但不够用怎么办”。
1.4 标准框架的核心要点
ISO 21448里，我个人觉得最值得关注的是这几个点：
| 阶段 | 核心活动 | 输出物 |
|---|---|---|
| 阶段1 | 功能定义与场景分析 | 功能描述、场景库 |
| 阶段2 | 危害识别与风险评估 | 危害清单、风险等级 |
| 阶段3 | 功能改进与验证 | 改进方案、验证报告 |
| 阶段4 | 残余风险评估 | 残余风险接受声明 |
个人经验：
我建议你在做SOTIF分析时，一定要把场景库建得足够细。别只写“雨天行驶”，要写“雨天、夜间、路面有积水、对向车辆远光灯”。因为真正出问题的，往往是这些细节的组合。
好了，这一章的内容就到这里。SOTIF这个概念，说白了就是让我们正视一个事实：自动驾驶系统不是万能的。承认它的局限，然后想办法弥补，这才是安全之道。
公众号:蓝海资料掘金营，微信deep3321