简介：ISO 21448-2022《道路车辆——预期功能的安全性》是国际标准化组织发布的SOTIF领域核心标准，面向汽车制造商、零部件供应商、软件开发者及道路安全监管人员，用于解决自动驾驶与辅助驾驶系统在无故障条件下因功能局限、传感器识别错误、环境因素或人机交互问题而引发的安全风险。资源包为1份PDF文件，共21.43MB，完整收录标准正文，涵盖术语定义、SOTIF活动组织方式、四类场景区域划分、危害事件模型、风险评估与缓解措施选择，以及开发过程管理、验证确认方法和测试分析流程等支持性内容。该标准与ISO 26262形成互补，侧重系统设计未考虑到的边界与局限情形。目前已有434人学习，适合需要系统理解预期功能安全框架、对照标准条款开展设计评估与合规工作的工程师和研究人员参考。
1. 预期功能安全：为什么“没坏”的系统依然会出事
一辆开启了辅助驾驶的车，传感器没坏、芯片没烧、代码没跑飞，却在某个阳光斜射的傍晚径直撞上前车。传统功能安全（ISO 26262）查遍了所有故障模式，结论是“系统一切正常”。问题出在哪？出在“正常”本身——系统按设计意图运行了，但设计意图没有覆盖真实世界的全部场景。这就是预期功能安全（SOTIF, Safety of the Intended Functionality）要解决的核心问题：不是失效导致的风险，而是功能不足和可预见误用导致的风险。
ISO 21448:2022 就是这套方法论的国际标准。它不替代 ISO 26262，而是补上后者够不着的那块盲区。理解 SOTIF 的底层逻辑，对做自动驾驶、ADAS、甚至任何在开放环境中运行的感知-决策-执行系统的人，都是绕不过去的一课。这份标准文档的价值不在于告诉你“要做什么”，而在于它给出了一套可推演、可验证、可闭环的机制，把“未知的危险”一步步逼成“已知的可控”。
2. SOTIF 的底层模型：四象限与感知-规划-执行链路
2.1 四象限模型：把风险按“已知/未知”和“安全/不安全”切开
ISO 21448 最核心的思维工具是四象限模型。它用两个维度切分场景空间：横轴是“已知/未知”，纵轴是“安全/不安全”。四个象限分别是：已知安全、已知不安全、未知不安全、未知安全。SOTIF 活动的目标非常明确——把“未知不安全”区域尽可能缩小，把“已知不安全”区域通过功能修改转化为“已知安全”，同时防止“已知安全”因误用滑向“已知不安全”。
这个模型的精妙之处在于它承认了一个事实：你不可能证明系统绝对安全，你只能证明“残余风险”低于某个可接受的阈值。标准第 6 章和第 7 章分别处理“已知不安全”的识别和“未知不安全”的探索，第 8 章的功能修改则是把风险从危险区搬到安全区的具体手段。整个标准的结构就是围绕这个四象限的收缩过程展开的。
常见的实现思路是：先通过危害识别找出已知的不安全场景，再用功能不足分析找出可能导致未知不安全的触发条件，然后通过系统修改、功能限制、权限交接等手段把风险降下来。每一步都有对应的验证活动，确保修改本身不会引入新的未知风险。
2.2 感知-规划-执行：SOTIF 分析的三条主线
标准第 7 章把功能不足和触发条件的分析拆成三条线：规划算法、传感器与执行器、以及可合理预见的误用。这三条线对应的是自动驾驶系统的经典链路——感知、规划、执行。为什么这么拆？因为不同环节的不足模式完全不同，触发条件也各异。
感知环节的典型不足是：摄像头在逆光下把白色卡车识别成天空，雷达把金属井盖识别成障碍物，激光雷达在雨雾中测距漂移。这些都不是“故障”，而是物理原理决定的性能边界。规划环节的不足更隐蔽：算法对cut-in车辆的意图预测过于乐观，对行人突然折返的轨迹拟合出现滞后，对施工路段的锥桶排列产生误判。执行环节则涉及制动响应延迟、转向执行器在低温下的力矩衰减等。
标准要求对每条线分别做分析，然后评估系统对触发条件的响应是否可接受。这里的关键参数是“可接受性”——不是“有没有风险”，而是“风险是否低到可以接受”。这个判断需要结合危害的严重度、暴露率和可控性来综合评估，和 ISO 26262 的 ASIL 定级思路有相似之处，但评估对象从“故障”变成了“性能不足”。
2.3 触发条件：从“故障树”到“场景树”的思维转换
传统功能安全用故障树分析（FTA）自顶向下找失效原因，SOTIF 用的是场景分析——自底向上穷举触发条件。触发条件可以是环境性的（大雨、大雪、强光）、道路性的（隧道出口、无标线路口、临时施工）、交通性的（加塞、鬼探头、异常停车）、甚至人机交互性的（驾驶员过度信任、误用脱手功能）。
标准第 7.3 节特别强调“可合理预见的直接或间接误用”。直接误用比如把L2当L4用，间接误用比如在系统提示接管时反应过慢。这些误用不是故障，但会显著改变系统的运行边界。分析时要把误用当作正常输入的一部分来建模，而不是当作异常来处理。
一个实用的做法是建立“触发条件库”，按感知、规划、执行三个维度分类，每个条件标注对应的功能不足模式和可能的危害。这个库不是一次性的，而是随着路测数据、仿真结果和现场事件不断迭代。标准第 10 章和第 11 章分别处理已知场景和未知场景的评估，本质上就是在用数据不断填充和修正这个库。
3. 从危害到功能修改：SOTIF 的闭环是怎么转起来的
3.1 危害识别与风险评估：第 6 章的工程化落地
第 6 章要求识别危害并评估风险，最终输出“残余风险的接受准则”。这一步和 ISO 26262 的 HARA（危害分析与风险评估）很像，但关注点不同。26262 问的是“故障会导致什么危害”，21448 问的是“功能不足在什么场景下会导致危害”。前者从故障出发，后者从场景出发。
具体操作时，通常先定义功能的使用场景和运行设计域（ODD），然后在 ODD 内枚举可能的危害事件。比如“高速公路巡航”这个功能，危害事件包括：未识别前方静止车辆、误识别相邻车道车辆为同车道、对cut-in车辆制动过晚等。每个事件按严重度（S）、暴露率（E）、可控性（C）打分，得出风险等级。
接受准则的设定是这一步的难点。标准没有给出具体数值，而是要求“基于合理可用的最新技术水平和社会的接受程度”。这意味着接受准则会随着技术迭代和社会认知变化而调整。工程上通常采用“尽可能低合理可行”（ALARP）原则，把风险降到可接受区间内，并保留论证材料。
3.2 功能不足分析：第 7 章的三条分析路径
第 7 章是整份标准技术含量最高的部分。它要求对规划算法、传感器与执行器、以及误用分别做功能不足分析。每条路径都有具体的分析方法和输出要求。
规划算法的不足分析要覆盖：轨迹预测的误差边界、决策逻辑的保守性、对异常轨迹的响应策略。比如一个换道决策算法，如果只考虑了目标车道后方车辆的正常接近，没有考虑后方车辆突然加速的情况，这就是一个功能不足。分析时要写出算法的假设条件，然后逐条检查假设在真实场景中是否成立。
传感器与执行器的不足分析要覆盖：物理原理决定的性能边界、环境条件对性能的影响、多传感器融合时的冲突消解策略。比如摄像头在低照度下的信噪比下降、毫米波雷达对静止金属物体的误报、超声波传感器在高速下的失效。这些不足不是故障，但会导致感知输出偏离真实世界。
误用分析要覆盖：可合理预见的直接误用（如脱手驾驶、超速使用）和间接误用（如对系统能力的误解、接管请求响应延迟）。分析时要考虑人机交互界面的设计是否会导致误用，以及系统是否有机制检测并缓解误用。
3.3 功能修改：第 8 章的四种手段
识别出风险后，第 8 章给出了四类功能修改手段：系统修改、功能限制、权限交接、误用应对。这四类手段可以组合使用，目标都是把风险从不可接受降到可接受。
系统修改是最直接的：增加冗余传感器、改进融合算法、调整决策阈值。比如发现摄像头在逆光下性能不足，可以增加毫米波雷达的权重，或者用激光雷达的点云做交叉验证。功能限制是缩小 ODD：如果系统在雨天无法可靠工作，就明确限制在晴天使用，并通过人机界面告知驾驶员。权限交接是在系统能力不足时把控制权交给人：比如检测到施工路段时请求驾驶员接管。误用应对则是通过监控驾驶员状态、设计防呆机制来减少误用。
每种修改都要评估其对 SOTIF 的影响，并更新“规格与设计”的输入信息。标准第 8.4 节特别强调这个反馈回路——修改不是终点，而是下一轮分析的起点。
3.4 验证与确认：第 9 到 11 章的评估框架
第 9 章定义验证与确认策略，第 10 章评估已知场景，第 11 章评估未知场景。这三章构成了 SOTIF 的验证闭环。
已知场景的评估相对直接：用仿真、台架、实车测试覆盖触发条件库中的场景，测量系统响应是否满足接受准则。标准第 10.3 到 10.6 节分别规定了感知、规划、执行和集成系统的验证要求。比如感知验证要覆盖传感器在各类环境条件下的性能边界，规划验证要覆盖算法在各类交通场景下的决策正确性。
未知场景的评估更棘手。标准第 11 章要求用“探索性”方法寻找未知的不安全场景。常用的手段包括：大规模路测、基于场景的仿真模糊测试、对抗性测试、以及现场事件的数据挖掘。目标是发现那些没有出现在触发条件库中的场景，然后把它加入库中，再走一遍分析和修改流程。
残余风险的评估是最后一步。标准要求综合已知场景和未知场景的评估结果，判断残余风险是否满足接受准则。如果不满足，就要继续修改和验证，直到满足为止。
4. 避坑指南：SOTIF 落地时最容易翻车的五个地方
4.1 把 SOTIF 当成 ISO 26262 的附录
现象：团队把 SOTIF 分析塞进功能安全的 FMEA 表格里，用故障模式覆盖功能不足。原因：没有理解两者的本质区别——26262 处理的是“失效”，21448 处理的是“性能不足”。失效可以修复，性能不足只能缓解或规避。解决：单独建立 SOTIF 分析流程，用场景库和触发条件库作为核心工件，不要和 FMEA 混在一起。
4.2 触发条件库建完就锁死
现象：项目初期建了一个触发条件库，之后再也不更新，验证活动只覆盖库里的场景。原因：把 SOTIF 当成了静态的合规检查，而不是动态的风险收敛过程。解决：把触发条件库当作活文档，每次路测、仿真、现场事件都要回写。标准第 11 章明确要求探索未知场景，库不更新就等于放弃了这部分工作。
4.3 接受准则拍脑袋定
现象：团队直接沿用 ISO 26262 的 ASIL 等级来定 SOTIF 的接受准则，或者干脆定一个“零事故”的目标。原因：没有理解 SOTIF 的接受准则是基于“合理可用的最新技术水平”和“社会接受程度”，不是基于故障概率。解决：参考行业实践和监管要求，结合自身系统的 ODD 和功能特点，制定可论证、可迭代的接受准则。零事故不现实，但也不能随意放宽。
4.4 忽略误用分析
现象：分析只覆盖系统正常运行时的情况，不考虑驾驶员脱手、超速使用、误解系统能力等误用场景。原因：把误用当成了“用户的问题”而不是“系统设计要考虑的输入”。解决：标准第 7.3.4 节明确要求分析可合理预见的直接和间接误用。设计时要考虑人机交互界面是否会诱导误用，以及系统是否有机制检测并缓解误用。
4.5 验证只做仿真不做实车
现象：为了省成本，验证活动全部在仿真环境中完成，实车测试只跑几个标准场景。原因：仿真无法完全复现真实世界的物理效应和传感器特性，尤其是光照、天气、电磁干扰等环境因素。解决：仿真和实车测试要互补。仿真覆盖大量场景组合，实车验证关键场景和仿真无法复现的边界条件。标准第 10 章和第 11 章都要求结合多种验证手段。
5. 残余风险的论证：SOTIF 的终点与起点
SOTIF 的最终产出不是“零风险”，而是一份可论证的残余风险评估。这份评估要回答三个问题：已知不安全场景是否都已识别并处理？未知不安全场景的探索是否足够充分？残余风险是否满足接受准则？这三个问题没有标准答案，只有基于当前技术水平和数据的“合理判断”。
我一般会这么理解：SOTIF 的论证材料就像一份“安全案例”，它不需要证明系统绝对安全，但需要说服评审者——在当前的 ODD 内，在合理可预见的场景和误用下，系统的风险已经降到了可接受的水平。这份案例的质量取决于触发条件库的完备性、分析方法的严谨性、验证活动的覆盖度、以及残余风险评估的透明度。
一个实用的验证方法是“红队演练”：让一个独立团队专门尝试找出 SOTIF 分析的漏洞——有没有遗漏的触发条件？有没有被低估的功能不足？有没有被忽略的误用场景？这种对抗性验证往往能发现常规分析漏掉的问题。
从那以后我每次做 SOTIF 分析，都会强制走一遍“四象限收缩”的检查：已知不安全的场景是否都有对应的功能修改？未知不安全的探索是否覆盖了感知、规划、执行三条线？误用分析是否考虑了直接和间接两种模式？残余风险的论证是否有数据支撑？这套习惯帮我避开了很多“看起来合规、实际上漏风”的坑。希望帮到你。
本文还有配套的精品资源，点击获取
