简介：ISO 21448-2022《道路车辆——预期功能的安全性》是国际标准化组织发布的SOTIF领域核心标准，面向汽车制造商、零部件供应商、软件开发者及道路安全监管人员，用于解决自动驾驶与辅助驾驶系统在无故障条件下因功能局限、传感器识别错误或环境因素引发的安全风险。资源包内含1个PDF文件，大小约21.43MB，完整收录标准正文，涵盖术语定义、SOTIF活动组织框架、四类场景区域划分、危害事件模型、风险评估与缓解措施，以及开发过程管理、验证确认方法和测试分析流程等支持性内容。该标准作为ISO 26262功能安全的重要补充，强调对设计未考虑场景的识别与管控。目前已有434人学习下载，适合需要深入理解预期功能安全概念、构建SOTIF开发流程或对照标准开展合规工作的技术人员参考使用。
1. 预期功能安全到底在防什么：一个让新手秒懂的类比
你刚提了一辆带辅助驾驶的新车，高速上开着自适应巡航，前方弯道突然出现一辆静止的故障车。雷达和摄像头都“看见”了它，系统也没有任何零件坏掉，但车子就是没减速——因为它压根没把“静止车辆”当成需要刹车的障碍物。这种“所有零件都正常，功能却闯了祸”的场景，正是预期功能安全要解决的问题。
ISO 21448 就是专门管这类风险的。它的全称是《道路车辆——预期功能的安全性》，英文缩写 SOTIF，读作“索提夫”。一句话说清：它防的不是零件坏了，而是功能本身“没想到”。传统功能安全管的是“东西坏了怎么办”，SOTIF 管的是“东西没坏，但它理解错了、能力不够、或者被环境骗了怎么办”。搞懂这个概念，你就能看懂为什么自动驾驶事故报告里经常出现“系统未识别”而不是“传感器故障”。
2. 为什么有了功能安全还不够：SOTIF 补上的那块拼图
2.1 功能安全的边界在哪里
功能安全对应的标准是 ISO 26262，它的核心逻辑是：电子电气系统可能发生随机硬件失效或系统性失效，我们要把风险降到可接受水平。比如刹车控制器的芯片坏了，系统要能检测到并进入安全状态。这套逻辑非常有效，但它有一个前提假设——系统在正常工作时，功能本身是“对的”。
打个比方，功能安全像是给汽车装了一堆保险丝和备用电路，确保电线短路时不会起火。但如果问题出在“驾驶员看错了路牌”这种层面，保险丝再多也没用。ISO 26262 管不了“摄像头把白色卡车误判成天空”这种事，因为摄像头没坏，算法也在正常运行，只是它的能力边界被现实场景击穿了。
2.2 SOTIF 要处理的三种“正常却危险”
ISO 21448 把这类风险拆得很清楚。第一种是性能局限：传感器在逆光、大雨、隧道出口等条件下探测距离骤降，这是物理规律决定的，不是故障。第二种是算法不足：规划算法没有考虑到“前方车辆突然掉落货物”这种场景，训练数据里没见过。第三种是可合理预见的误用：驾驶员把辅助驾驶当成完全自动驾驶，手离开方向盘去拿手机。
这三种情况的共同点是：系统没有失效，但危险已经发生。SOTIF 的目标就是把这些“已知的不安全场景”尽量变成“已知的安全场景”，同时把“未知的不安全场景”压缩到可接受的残余风险范围内。它不追求零风险，而是追求风险被识别、被评估、被控制。
2.3 一个具体例子看懂两者分工
假设一辆车在高速上以 120 km/h 行驶，前方 200 米处有一辆静止的清扫车。功能安全的视角会检查：雷达供电正常吗？CAN 通信有没有丢帧？制动执行器有没有卡滞？如果这些都正常，功能安全就认为“不关我事”。
SOTIF 的视角则会追问：雷达对静止物体的过滤逻辑是什么？摄像头在强光下能否分辨清扫车和天空？融合算法有没有把静止目标标记为“噪声”？如果系统设计时默认“高速上不会有静止车辆”，那这个设计假设本身就是 SOTIF 要挑战的对象。ISO 21448 要求你把这类场景找出来，评估它的风险，然后要么改设计，要么限制功能使用条件，要么在用户手册里写清楚边界。
注意：SOTIF 不是功能安全的替代品，两者是互补关系。一辆车既要满足 ISO 26262 的故障安全要求，也要满足 ISO 21448 的预期功能安全要求，缺一不可。
3. 四象限模型：SOTIF 怎么把“不知道”变成“知道”
3.1 已知安全、已知不安全、未知不安全
ISO 21448 最核心的思维工具是“四场景区域”模型。它用两个维度切分世界：横轴是“场景是否已知”，纵轴是“场景是否安全”。这样就有了四个象限。
第一象限是已知安全：比如白天高速跟车，系统表现稳定，这是你验证过的场景。第二象限是已知不安全：比如隧道出口强光导致摄像头短暂致盲，你知道它会出问题，也做了对策。第三象限是未知不安全：这是最危险的区域，你不知道什么场景会触发危险，事故往往发生在这里。第四象限是未知安全：你还没分析到，但实际上不会出问题的场景，这个区域可以暂时不管。
SOTIF 活动的本质，就是通过分析和测试，把第三象限的“未知不安全”尽量挪到第二象限的“已知不安全”，然后针对第二象限设计缓解措施，把它变成第一象限的“已知安全”。每挪动一次，残余风险就降低一分。
3.2 感知、规划、执行：风险从哪来
ISO 21448 把车辆自动化系统拆成“感知-规划-执行”三个环节，每个环节都有典型的 SOTIF 风险。
感知环节的风险最直观：摄像头把广告牌上的汽车图片当成真车、毫米波雷达把井盖回波当成障碍物、激光雷达在雨雾中回波衰减。这些都不是硬件故障，而是物理原理和算法能力的边界。标准里专门有一章讲“感知验证”，要求你证明传感器在各类环境条件下的表现是可接受的。
规划环节的风险更隐蔽：算法可能对“他车突然切入”反应过度，猛打方向导致失控；也可能对“前方静止车辆”反应不足，因为训练数据里高速静止目标太少。标准要求分析规划算法的功能不足和触发条件，比如“当目标车辆横向速度超过某个阈值时，规划器输出延迟”。
执行环节的风险常被忽略：制动系统响应正常，但执行器的延迟特性导致实际减速度比预期低；转向系统在低温下阻尼增大，导致路径跟踪偏差。这些也不是故障，而是执行器在真实环境中的性能局限。
3.3 触发条件：压垮骆驼的那根稻草
SOTIF 里有一个关键概念叫“触发条件”。它指的是那些把潜在功能不足暴露出来的具体场景或环境因素。比如“摄像头在逆光下动态范围不足”是功能不足，“下午五点太阳正对摄像头行驶方向”就是触发条件。两者单独存在都不一定出事，但碰在一起就可能出问题。
识别触发条件是 SOTIF 分析的核心工作。ISO 21448 建议从多个维度去扫：环境维度（光照、天气、路面）、交通维度（他车行为、行人、障碍物）、车辆维度（载荷、轮胎磨损、传感器脏污）。每个维度都要问：这个因素会不会让某个功能的表现降到不可接受的水平？
提示：触发条件不一定是极端情况。日常场景里的“隧道出口强光”“雨天前车溅起水雾”“夜间对向车灯眩光”都是高频触发条件，比极端天气更值得优先处理。
4. 容易搞混的几个概念：SOTIF、功能安全、网络安全
4.1 SOTIF 和功能安全的区别
最容易混的就是这两个。功能安全（ISO 26262）处理的是“失效”导致的风险，SOTIF（ISO 21448）处理的是“性能局限”导致的风险。失效是“东西坏了”，性能局限是“东西没坏但不够好”。
举个例子：刹车片磨损到极限导致制动失效，这是功能安全问题。刹车片正常但雨天制动距离比预期长 20%，这是 SOTIF 问题。功能安全要求你设计冗余和故障检测，SOTIF 要求你识别性能边界并告知用户或限制功能。
区分方法很简单：问一句“有没有东西坏了？”如果答案是“没有，但就是不行”，那大概率是 SOTIF 的范畴。
4.2 SOTIF 和网络安全的区别
网络安全处理的是“被恶意攻击”导致的风险，比如 CAN 总线被注入虚假刹车指令、摄像头被激光致盲攻击。SOTIF 处理的是“非恶意”的性能局限，比如摄像头被太阳光致盲。
两者在“传感器致盲”这个点上会交叉，但动机不同。网络安全假设有攻击者，SOTIF 假设没有攻击者，只是环境太复杂。ISO 21448 明确把恶意攻击排除在范围之外，那是 ISO/SAE 21434 的地盘。
4.3 SOTIF 和“可靠性”的区别
可靠性关心的是“东西能用多久不出故障”，比如平均无故障时间。SOTIF 关心的是“东西在寿命期内，功能表现是否足够安全”。一个可靠性极高的传感器，可能在特定场景下性能骤降，这仍然是 SOTIF 问题。
可靠性是“不出故障的概率”，SOTIF 是“出了边界场景也不出危险的概率”。两者维度不同，不能互相替代。
4.4 常见误区：SOTIF 只跟自动驾驶有关
很多人以为 SOTIF 只适用于 L3 以上的自动驾驶。实际上 ISO 21448 的适用范围包括所有带电子电气功能的道路车辆，只要这个功能可能因为性能局限导致危险。自适应巡航、自动紧急制动、车道保持，甚至电子稳定程序，都在范围内。
只要你的功能需要感知环境、做判断、然后执行动作，并且这个动作可能影响安全，SOTIF 就适用。区别只是复杂度和分析深度不同。
4.5 常见误区：SOTIF 能保证绝对安全
SOTIF 的目标不是零风险，而是把残余风险降到可接受水平。标准里反复出现“可合理预见”“可接受”这类词，说明它承认未知场景永远存在。你能做的是把已知的坑填上，把未知的坑尽量找出来，然后诚实地告诉用户还有哪些坑可能踩。
注意：如果有人告诉你“过了 SOTIF 就绝对安全”，那是不负责任的。SOTIF 是一套降低风险的方法论，不是安全保证书。
5. 什么时候用 SOTIF，什么时候别硬套
5.1 该用 SOTIF 的典型场景
如果你在做以下事情，ISO 21448 就是你的必读材料：开发任何需要感知环境的驾驶辅助功能，比如自动紧急制动、自适应巡航、车道保持；设计自动驾驶系统的感知或规划模块；评估一个已上市功能在边缘场景下的安全表现；或者你是监管机构，需要判断某个功能的安全论证是否充分。
标准里给出的流程很实用：先定义功能规格和设计，然后识别危害，再分析潜在功能不足和触发条件，接着设计修改措施，最后定义验证和确认策略。这套流程可以直接套到项目里，每一步都有对应的输出物要求。
5.2 什么时候别硬套
如果你的功能完全不依赖环境感知，比如纯机械的门锁、不涉及外部感知的座椅加热，SOTIF 基本用不上。如果你的系统只有简单的逻辑判断，没有传感器输入，也没有复杂算法，那功能安全就够了。
还有一种情况：项目处于概念阶段，功能定义还没冻结。这时候硬做 SOTIF 分析会浪费大量精力，因为场景和触发条件都还没确定。更合理的做法是先做初步危害分析，等设计稳定后再展开完整的 SOTIF 活动。
5.3 一个具体判断例子
假设你在开发一个“自动泊车”功能。它用超声波雷达和摄像头找车位，然后控制方向盘和刹车完成泊入。这个功能要不要做 SOTIF？
答案是必须做。因为超声波雷达在雨天可能被水膜干扰，摄像头在低矮障碍物（比如地锁、锥桶）面前可能识别失败，泊车路径规划可能没考虑到“车位旁边突然有行人经过”。这些都是典型的 SOTIF 风险，不是硬件故障，但足以造成事故。
反过来，如果你在做的是“座椅记忆功能”，它只读取存储的位置数据然后驱动电机，不感知外部环境，也不影响行车安全，那就不需要 SOTIF。
5.4 从标准到实践：一份 PDF 能帮你什么
ISO 21448:2022 这份标准文档本身有 50 多页，包含术语定义、活动框架、分析方法和验证要求。它不会给你现成的代码或模板，但会给你一套完整的思考框架。比如第 7 章讲怎么识别功能不足和触发条件，第 8 章讲怎么改设计，第 10 章和第 11 章分别讲已知场景和未知场景的评估方法。
我自己的习惯是：每次启动一个新功能的安全分析，先把第 4 章的四象限模型画在白板上，然后把团队能想到的所有场景往四个象限里填。填完之后，重点看第三象限——那些“不知道会不会出事”的场景。这份 PDF 的价值就在于，它把“怎么找第三象限的坑”变成了一套可执行的动作，而不是靠拍脑袋。
从那以后我每次做安全分析，都强制走一遍“感知-规划-执行”的拆解，再对照四象限填场景，最后问一句“这个触发条件有没有被覆盖”。这套流程帮我省掉了很多返工。希望帮到你。
本文还有配套的精品资源，点击获取
