ISO 21448-2022 SOTIF 预期功能安全标准解读与工程落地实践

简介：ISO 21448-2022《道路车辆——预期功能的安全性》是国际标准化组织发布的SOTIF领域核心标准，面向汽车制造商、零部件供应商、软件开发商及道路安全监管机构，用于评估和缓解自动驾驶与辅助驾驶系统在正常运行条件下因功能局限、传感器失效、识别错误、环境因素及人机交互问题所引发的安全风险。该标准与ISO 26262功能安全形成互补，覆盖感知、判断、执行等自动化系统全链路，并给出SOTIF活动组织、危险识别、风险评估、验证确认及测试分析等完整流程框架。资源包共1个PDF文件，大小约21.43MB，内容为英文原版标准全文，含前言、术语定义、SOTIF活动概览、四类场景区域及支持性流程等章节，目录结构清晰，便于按条款检索查阅。目前已有434人学习下载，适合从事预期功能安全设计、验证与合规工作的工程师及研究人员系统研读与落地参考。

1. 一份让自动驾驶团队集体加班的 PDF：ISO 21448-2022 到底管什么

如果你在做 ADAS 或自动驾驶，大概率遇到过这种场景：功能安全那边 ISO 26262 的文档刚封版，测试团队却报上来一堆「系统没坏、但行为不对」的 case——比如摄像头把白色货车车厢误判成天空、毫米波雷达把井盖回波当成静止车辆、AEB 在隧道出口因为光照突变直接漏检。这些都不是硬件失效，也不是软件 bug，而是「预期功能」本身在特定场景下能力不够。ISO 21448-2022 就是冲着这类问题来的，业内叫它 SOTIF（Safety of the Intended Functionality，预期功能安全）。这份 PDF 是 2022 年 6 月发布的第一版正式标准，全文围绕一个核心问题展开：当系统没有故障、但性能存在局限时，如何把残余风险压到可接受范围。它适合谁？做感知算法、域控制器、功能安全、系统架构、测试验证的工程师，以及需要给项目做 SOTIF 裁剪和合规举证的技术负责人。如果你只做传统 ECU 的 ISO 26262，这份标准可以先放一放；但只要你的系统里有「感知—决策—执行」这条链路，它迟早会出现在你的评审清单里。

2. 从四象限到 Sense-Plan-Act：把标准读成一张可执行地图

2.1 四场景区域：SOTIF 所有活动的坐标系

标准第 4 章给了一张贯穿全文的图，把运行场景分成四个区域，这是后面所有分析、验证、确认活动的锚点。区域 1 是已知安全场景，区域 2 是已知不安全场景，区域 3 是未知不安全场景，区域 4 是未知安全场景。SOTIF 活动的目标很明确：把区域 2 通过功能修改压到区域 1，把区域 3 通过验证和确认活动暴露出来、转成区域 2 再处理。很多团队翻车就翻在把区域 3 当成「测不到就不存在」，结果路测里程堆了几十万公里，长尾场景一个没覆盖。

读这一章时建议直接拿一张白纸，横轴写「已知/未知」，纵轴写「安全/不安全」，然后把你们项目当前能想到的场景往里填。填不满区域 3 是正常的，因为区域 3 的定义就是「你还不知道你不知道」。但填的过程会让团队意识到：SOTIF 不是一份文档，而是一个持续把未知变已知的循环。

2.2 Sense-Plan-Act 模型：定位功能不足的抓手

标准用 Sense-Plan-Act 三段式来拆解功能不足的来源，这个模型比很多公司内部自研的「感知-融合-规划-控制」四段式更粗，但恰好对应 SOTIF 关注的三个层面：感知层面的功能不足（传感器物理局限、算法泛化差）、规划层面的功能不足（决策逻辑在边缘场景下输出不合理）、执行层面的功能不足（执行器响应达不到预期）。第 7 章专门针对这三类给出了分析清单，第 10 章又对应给出验证手段。

我一般建议团队在做 SOTIF 分析时，先把每个功能按 Sense-Plan-Act 拆成三段，每段单独列「可能的功能不足」和「可能的触发条件」。比如 AEB 功能，Sense 段可能的功能不足是「逆光下目标识别置信度下降」，触发条件是「低太阳角+高反射路面」；Plan 段可能是「对横穿目标的 TTC 计算未考虑目标加速度」，触发条件是「目标突然加速横穿」。这样拆完，第 7 章的分析表就有了输入，而不是对着空白表格硬编。

2.3 规范性与资料性条款：别在非强制内容上浪费工时

标准第 4.3.2 条明确区分了规范性条款和资料性条款。规范性条款用「shall」表述，是必须满足的；资料性条款用「should」「may」「can」表述，是建议或参考。很多团队第一次读标准时把附录里的示例当成强制要求，花大量时间去做一套根本不适用的分析模板，结果主线活动反而滞后。

一个实用的做法是：先把全文所有含「shall」的句子抽出来，做成一张合规检查表，按章节编号排序。这张表就是你后续做 SOTIF 裁剪和举证的核心依据。含「should」的内容可以作为方法论参考，但不必逐条对应。标准第 4.3.3 条还专门讲了表格的解读方式，表格里的「X」表示该活动适用，「—」表示不适用，读表时先看表头再看行列，别上来就从左上角逐格读。

2.4 分布式开发下的接口定义：谁负责哪块功能不足

第 4.4.2 条讲分布式 SOTIF 开发活动，这是供应商和主机厂之间最容易扯皮的地方。标准要求把 SOTIF 相关的职责在开发接口上写清楚：哪些功能不足由供应商负责分析和缓解，哪些由主机厂在整车层面处理，哪些需要联合评审。现实中常见的情况是：供应商交了一个感知模块，声称「功能不足已在模块内缓解」，但主机厂装车后发现新的触发条件，双方对「谁该为这个场景负责」各执一词。

标准给出的思路是在 DIA（开发接口协议）里增加 SOTIF 相关条目，至少覆盖：功能不足的描述、触发条件的假设、验证证据的交付物、残余风险的接受准则。我见过做得比较扎实的团队，会在 DIA 里附一张「SOTIF 假设清单」，逐条列出供应商做分析时假设的 ODD（运行设计域）边界，主机厂拿到后逐条确认是否与实际使用条件一致。不一致的条目就是联合评审的输入。

2.5 第 5 章到第 8 章：一条从规格到功能修改的流水线

第 5 章讲规格和设计，要求在第 5.2 条明确功能规格和设计考虑，第 5.3 条讲系统架构层面的考虑，第 5.4 条专门讲性能不足和对策的考虑。这一章的产出是后续所有分析的输入，如果规格写得含糊，后面第 6 章的危险识别和第 7 章的功能不足分析都会变成空中楼阁。

第 6 章讲危害识别和风险评估，第 6.5 条要求定义残余风险的接受准则。这里有个容易忽略的点：接受准则不是拍脑袋定的，要结合第 6.4 条的风险评估结果来定，而且要在项目早期就定，不能等测试做完再补。

第 7 章是全文最厚的一章，讲潜在功能不足和触发条件的识别与评估。第 7.3.2 条针对规划算法，第 7.3.3 条针对传感器和执行器，第 7.3.4 条讲合理可预见的误用。第 7.4 条要求评估系统对触发条件响应的可接受性。这一章的分析方法标准没有指定具体工具，常见做法是结合 HAZOP、FMEA 和场景分析法，但标准更强调「从功能不足出发」而不是「从失效模式出发」，这是和 ISO 26262 最大的思维差异。

第 8 章讲功能修改，第 8.3 条列了几类措施：系统修改、功能限制、权限移交、处理合理可预见的误用。第 8.4 条要求把修改后的信息更新回第 5 章的规格和设计，形成一个闭环。很多团队做到第 8 章就停了，忘了回写规格，导致下一轮迭代时规格和实际设计对不上，SOTIF 活动变成一次性运动。

3. 把标准落成工程动作：分析表、验证策略与测试用例

3.1 第 7 章分析表怎么填：从功能不足到触发条件

第 7 章的分析是 SOTIF 工作量最大的部分。标准没有给固定模板，但给出了分析维度。我一般用下面这张表来组织，字段可以根据项目裁剪，但核心逻辑不变：

填这张表时有两个坑。第一个坑是把「功能不足」写成「失效模式」，比如写「摄像头失效」而不是「摄像头在逆光下动态范围不足」。前者是 ISO 26262 的语境，后者才是 SOTIF 的语境。第二个坑是触发条件写得太笼统，比如只写「恶劣天气」，这种写法后面没法设计测试用例。要细到「中雨以上、路面有积水反光、目标为两轮车」这种颗粒度。

3.2 第 9 章验证策略：先定策略再写用例

第 9 章要求定义验证和确认策略，第 9.3 条讲集成和测试的规格。这里的关键是：验证策略要在写测试用例之前定，而不是反过来。标准把验证活动分成两类：一类是针对已知场景的验证（第 10 章），一类是针对未知场景的确认（第 11 章）。第 10 章又细分为感知验证、规划算法验证、执行验证、集成系统验证，最后评估已知危险场景的残余风险。第 11 章则要求评估未知危险场景的残余风险，第 11.4 条给出了验证结果的交付要求。

一个常见的误区是把第 10 章和第 11 章当成两个独立阶段，先做完已知场景再做未知场景。实际上标准的设计意图是两者并行迭代：第 10 章的验证结果会暴露新的未知场景，第 11 章的确认活动又会把部分未知场景转成已知场景，再回到第 10 章做针对性验证。我一般建议团队按「场景库版本」来管理，每个版本包含已知场景清单和未知场景探索计划，版本迭代时同步更新。

3.3 测试用例设计：从触发条件反推

测试用例不是从功能列表正推出来的，而是从第 7 章的触发条件反推出来的。每个触发条件至少对应一个测试用例，用例里要明确：初始状态、触发条件注入方式、预期响应、可接受判据。下面是一个用 Python 组织测试用例的示例，把触发条件和用例参数化，方便批量生成和回归：

# SOTIF 触发条件参数化测试用例生成示例 # 每个触发条件对应一组参数，批量生成测试场景 trigger_conditions = [ { "id": "TC-SENSE-001", "desc": "逆光下白色货车识别", "params": { "sun_angle": [5, 10, 15], # 太阳低角度，单位度 "target_color": ["white"], # 目标颜色 "target_type": ["truck"], # 目标类型 "road_reflectance": [0.6, 0.8], # 路面反射率 }, "expected": "识别置信度 >= 0.9", "acceptance": "无漏检，TTC 计算误差 < 10%", }, { "id": "TC-PLAN-003", "desc": "横穿目标突然加速", "params": { "target_accel": [2.0, 3.5, 5.0], # 目标加速度 m/s^2 "initial_ttc": [1.5, 2.0, 2.5], # 初始 TTC 秒 "crossing_angle": [90], # 横穿角度 }, "expected": "AEB 触发时机不晚于 TTC=1.2s", "acceptance": "未发生碰撞或碰撞速度 < 10 km/h", }, ] def generate_test_cases(conditions): """把触发条件展开成参数组合，生成测试用例列表""" cases = [] for cond in conditions: # 对每个参数做笛卡尔积展开 keys = list(cond["params"].keys()) values = list(cond["params"].values()) for combo in itertools.product(*values): case = { "case_id": f"{cond['id']}-{len(cases):03d}", "description": cond["desc"], "parameters": dict(zip(keys, combo)), "expected": cond["expected"], "acceptance": cond["acceptance"], } cases.append(case) return cases

这段代码的逻辑是：把第 7 章分析出的触发条件转成参数化结构，每个参数给一组候选值，用笛卡尔积展开成具体测试用例。参数说明：sun_angle控制光照条件，target_accel控制目标运动特性，initial_ttc控制初始危险程度。实际使用时，参数值范围要结合 ODD 定义和事故统计数据来定，不能随意拍。生成后的用例列表可以直接对接仿真平台或台架测试脚本，实现回归自动化。

3.4 第 10 章各验证环节的交付物

第 10 章按 Sense-Plan-Act 分段给出验证要求，每段都有对应的交付物。感知验证（10.3）要交付传感器性能边界报告和触发条件覆盖分析；规划算法验证（10.4）要交付决策逻辑在边缘场景下的响应评估；执行验证（10.5）要交付执行器响应特性与预期功能的匹配分析；集成系统验证（10.6）要交付端到端场景测试结果；最后 10.7 要评估已知危险场景的残余风险。这些交付物不是一次性文档，而是随场景库迭代持续更新的活文档。我见过把交付物做成静态 PDF 的团队，评审时被问「这个场景库版本对应哪次代码提交」直接卡住。建议交付物里强制包含版本号和基线信息。

4. 避坑与排查：SOTIF 落地时最容易翻车的五件事

4.1 把 SOTIF 当成 ISO 26262 的附录

现象：团队在 FMEA 表格里加了一列「SOTIF 相关」，就算完成了 SOTIF 分析。原因：ISO 26262 的思维是「失效导致危害」，SOTIF 的思维是「功能不足导致危害」，两者的分析起点不同。解决：单独建 SOTIF 分析表，从功能不足出发，不要复用 FMEA 的失效模式字段。两个分析可以共享危害清单，但分析路径必须分开。

4.2 触发条件写得太粗，测试用例没法落地

现象：分析表里写「雨天可能触发感知功能不足」，测试团队反馈无法设计用例。原因：触发条件没有量化到可注入的参数级别。解决：每个触发条件至少拆到「环境参数+目标参数+自车参数」三个维度，每个维度给出可测量的范围。比如「雨天」要拆成「降雨量 10-20mm/h、路面水膜厚度 0.5-1mm、目标为深色两轮车」。

4.3 忽略第 8.4 条的回写要求

现象：功能修改做完后，规格文档没有更新，下一轮迭代时设计和规格对不上。原因：团队把 SOTIF 当成一次性合规活动，做完就归档。解决：把第 8.4 条的回写动作纳入变更管理流程，每次功能修改后强制更新第 5 章的规格和设计输入，并在配置管理里建立追溯关系。

4.4 未知场景确认活动流于形式

现象：第 11 章的未知场景评估只写了一句「通过路测未发现未知危险场景」。原因：没有系统化的未知场景探索方法。解决：常见做法是结合场景库采样、对抗测试、影子模式数据挖掘三种手段，每种手段给出覆盖度指标和发现的新场景清单。路测里程不是唯一证据，甚至不是主要证据。

4.5 分布式开发接口里 SOTIF 职责空白

现象：供应商和主机厂在项目后期才发现某些功能不足没人负责分析。原因：DIA 里只写了功能安全和质量条款，没有 SOTIF 条目。解决：在 DIA 里增加 SOTIF 职责矩阵，至少覆盖功能不足识别、触发条件假设、验证证据交付、残余风险接受四项。每项明确责任方和交付物格式。

5. 进阶技巧：用场景库版本管理把 SOTIF 变成持续活动

SOTIF 最难的不是读标准，而是让它在项目里持续运转。我自己的习惯是把场景库当成一个版本化管理的资产，每个版本包含四样东西：已知场景清单、未知场景探索计划、触发条件参数集、验证结果基线。版本号跟代码基线挂钩，每次代码合并到主分支，场景库至少要做一次增量评审。

具体操作上，我会用一张场景库版本表来跟踪：

这张表的价值在于：评审时可以直接回答「当前残余风险对应哪个代码版本、覆盖了哪些场景、还有哪些未知」。标准第 11.4 条要求交付未知场景的验证结果，这张表就是最直接的证据。

另一个技巧是把第 7 章的分析表和第 10 章的验证结果做双向追溯。每个触发条件要有对应的验证用例，每个验证用例要能追溯到触发条件。追溯断了的地方，要么是分析漏了，要么是测试多做了，两种情况都值得查。我一般用脚本做追溯检查，把分析表和测试用例表都导出成结构化数据，跑一遍匹配，输出未覆盖的触发条件和无来源的测试用例。

最后说一个血泪经验：SOTIF 的残余风险接受准则一定要在项目早期和客户或监管方对齐，不要等测试做完再谈。我见过一个项目，测试做了大半年，最后评审时对方说「这个残余风险我们不接受」，整个验证策略推倒重来。从那以后我每次启动 SOTIF 活动，都强制先走一遍接受准则的确认，哪怕只是邮件确认，也比后期返工强。希望帮到你。

本文还有配套的精品资源，点击获取