企业官网建设流程全解析

简介：ISO 21448-2022《道路车辆——预期功能的安全性》是国际标准化组织发布的SOTIF领域核心标准，面向汽车制造商、零部件供应商、软件开发者及道路安全监管人员，用于解决自动驾驶与辅助驾驶系统在无故障条件下因功能局限、传感器识别错误、环境因素或人机交互问题而引发的安全风险。资源包内含1个PDF文件，即标准英文原版全文，约21.43MB，内容涵盖术语定义、SOTIF活动概览与组织方式、危害识别与风险评估、验证确认方法及支持性流程等章节，可与ISO 26262功能安全标准形成互补参照。目前已有434人学习。读者可借此系统掌握预期功能安全的概念框架与实施路径，对照标准条款梳理感知、判断、执行各环节的潜在危险场景，为产品开发、安全论证与合规审查提供权威依据。

1. 预期功能安全 SOTIF 知识地图：从 ISO 21448 的框架说起

如果你正在系统学习自动驾驶安全，或者正在备考相关认证，ISO 21448 大概率是你绕不开的一份标准。它和 ISO 26262 经常被放在一起讨论，但两者的切入角度完全不同：ISO 26262 管的是「系统坏了怎么办」，ISO 21448 管的是「系统没坏，但它就是做不到怎么办」。这个区别听起来简单，实际梳理下来会发现，它直接决定了整份标准的结构和活动流程。

这份 ISO 21448:2022 是首版正式发布的标准，全文围绕一个核心问题展开：当车辆在正常运行条件下，由于预期功能的局限性或性能不足而引发危险时，如何识别、评估并降低这类风险。它覆盖的范围从感知、规划到执行，涉及技术、人、其他道路用户和基础设施等多个维度。适合谁看？做 ADAS 或自动驾驶系统设计的工程师、负责安全论证的架构师、以及需要理解 SOTIF 与功能安全分工的测试与验证人员。接下来的内容，我会按标准本身的章节逻辑，把这份知识地图拆成可复习的模块。

2. SOTIF 核心模型：四象限场景与三阶段链路

2.1 四象限场景模型：已知/未知与安全/不安全

ISO 21448 最核心的分析工具之一，是把所有可能的运行场景按两个维度切分成四个区域：我们是否知道这个场景，以及这个场景是否安全。这个模型在标准第 4.2.2 节有详细定义，梳理下来会发现，它其实是整份标准所有活动的靶子。

标准的目标很明确：把区域 2 和区域 3 尽量往区域 1 和区域 4 迁移。区域 2 靠的是功能修改和限制，区域 3 靠的是场景探索和验证策略。最容易忽略的是区域 4——它不是一个可以直接测试的目标，而是通过排除区域 3 来间接论证的。很多人在复习时会把区域 4 当成一个可交付的验证结果，实际上它更像是一个残余风险的接受状态。

2.2 Sense-Plan-Act 模型：感知、规划、执行的链路拆解

标准第 4.2.3 节引入了 Sense-Plan-Act 模型，把车辆自动化系统拆成三个环节：感知、规划、执行。这个模型的价值在于，它让功能不足和触发条件的分析有了明确的落脚点。

感知环节的典型功能不足包括：传感器在特定天气下的识别率下降、对非标准物体的分类错误、多传感器融合时的时序偏差。规划环节的典型问题包括：对其他道路使用者意图的误判、路径规划算法在边缘场景下的输出不稳定。执行环节则可能因为执行器的响应延迟或精度限制，导致规划意图无法准确落地。

复习时建议把每个环节的「功能不足」和「触发条件」分开记。功能不足是系统本身的能力边界，触发条件是让这个边界暴露出来的外部场景。比如，摄像头在逆光下的识别率下降是功能不足，而「隧道出口正对夕阳」就是触发条件。标准第 7 章专门讲这两者的识别和分析，后面会展开。

2.3 与 ISO 26262 的分工：为什么需要两份标准

很多人第一次接触 SOTIF 时会问：ISO 26262 不是已经覆盖了汽车安全吗？梳理下来会发现，两者的分工非常清晰。ISO 26262 处理的是 E/E 系统的故障行为——比如传感器短路、芯片失效、软件跑飞。这些问题的共同点是：系统偏离了设计意图。

ISO 21448 处理的是另一类问题：系统完全按照设计意图运行，但设计意图本身在特定场景下不足以避免危险。比如，AEB 系统在设计时假设前方目标都是标准车辆，但实际道路上出现了异形物体，系统没有故障，但就是识别不了。这类风险无法通过 ISO 26262 的故障分析覆盖，因为根本没有故障发生。

两份标准是互补关系，不是替代关系。在实际项目中，SOTIF 活动通常和功能安全活动并行开展，共享部分分析输入，但输出的是不同的安全论证。复习时可以把两者的活动清单并排对比，会发现 SOTIF 更侧重场景分析和性能评估，而功能安全更侧重失效模式和诊断覆盖。

3. 功能不足与触发条件：第 7 章的分析方法

3.1 功能不足的分类：感知、规划、执行

标准第 7.3 节把潜在功能不足按 Sense-Plan-Act 三个环节展开。感知相关的不不足包括：传感器在特定环境条件下的性能下降、对特定目标类别的识别能力不足、传感器覆盖范围的物理限制。规划相关的不不足包括：算法对复杂交互场景的处理能力不足、对不确定性输入的响应策略不完善。执行相关的不不足包括：执行器动态响应与规划输出的匹配偏差、执行器在极端工况下的性能衰减。

复习时建议按这个分类建一张检查表，每个环节下列出典型的功能不足模式。标准里给出的例子是分析起点，实际项目中需要根据具体系统的设计来扩展。最容易漏的是规划环节——很多人会把注意力集中在感知上，因为感知的问题更容易可视化，但规划算法在交互场景中的不足往往更难发现，也更难通过测试覆盖。

3.2 触发条件的识别：从环境到人因

触发条件是让功能不足暴露出来的外部条件。标准第 7.3.3 节把触发条件分为几类：环境条件（天气、光照、道路几何）、其他道路参与者的行为（突然切入、异常姿态）、基础设施相关（标志缺失、标线模糊）、以及人机交互相关（驾驶员误用、接管延迟）。

识别触发条件时，标准建议采用系统化的方法，而不是依赖零散的头脑风暴。常用的手段包括：基于场景库的遍历分析、基于事故数据的反向推导、以及基于仿真的大规模场景探索。梳理下来会发现，触发条件的识别质量直接决定了后续验证活动的有效性——如果触发条件没找全，后面的测试就是在验证一个不完整的假设。

提示：触发条件不等于危险场景。触发条件是外部输入，危险场景是触发条件与功能不足组合后产生的风险状态。分析时要保持这个区分，否则容易把外部条件和内部不足混为一谈。

3.3 可合理预见的误用：直接与间接

标准第 7.3.4 节专门讨论了可合理预见的误用。直接误用是指用户主动绕过或关闭系统的安全功能，比如在系统警告时仍然强行激活。间接误用是指用户因为对系统能力的误解而采取了不恰当的操作，比如过度信任系统的感知能力，在系统设计运行范围之外使用。

这类误用的分析不能只靠工程团队，需要引入人因工程的方法。标准建议从用户手册、培训材料、以及实际使用数据中提取误用模式。复习时要注意：误用分析的范围是「可合理预见」，不是「所有可能」。判断标准是：一个有正常认知能力的用户，在正常使用场景下，是否可能做出这种行为。过度扩展误用范围会导致分析失去焦点。

4. 功能修改与验证策略：第 8 章到第 11 章的落地

4.1 功能修改的六类措施

标准第 8.3 节列出了改进 SOTIF 的几类措施：系统修改、功能限制、权限移交、误用应对、以及支持措施。系统修改包括增加冗余传感器、改进算法、调整执行器响应策略。功能限制包括定义系统的运行设计域，在条件不满足时限制功能激活。权限移交包括在系统能力不足时，将控制权交还给驾驶员或其他系统。

梳理下来会发现，这些措施的选择不是随意的，而是要和前面识别的功能不足和触发条件对应。比如，如果功能不足是感知在特定天气下的性能下降，对应的措施可能是功能限制（在该天气下不激活）或系统修改（增加不受天气影响的传感器）。标准第 8.4 节还提到，这些修改需要反馈到「规格与设计」阶段，形成一个迭代闭环。

4.2 验证与确认策略：已知场景与未知场景

标准第 9 章到第 11 章分别覆盖了验证策略的定义、已知场景的评估、以及未知场景的评估。已知场景的评估包括感知验证、规划算法验证、执行验证、以及集成系统验证。未知场景的评估则更侧重残余风险的论证，标准第 11.3 节给出了评估未知危险场景残余风险的方法。

复习时要注意：已知场景的验证是可以直接设计和执行的，未知场景的评估则更多依赖论证和间接证据。标准第 11.4 节的工作产品包括未知危险场景的验证结果和残余风险评估。这部分最容易出错的地方是：把未知场景的评估当成一个可以完全量化的过程。实际上，标准承认未知场景的评估存在不确定性，要求的是基于现有证据的合理判断，而不是绝对的证明。

4.3 残余风险的接受准则

标准第 6.5 节要求定义残余风险的接受准则。这个准则不是拍脑袋定的，而是基于风险评价的结果。风险评价要考虑暴露度、可控性、以及严重度。梳理下来会发现，SOTIF 的残余风险接受准则和功能安全的接受准则在逻辑上是一致的，但输入不同：功能安全关注的是故障发生的概率，SOTIF 关注的是场景发生的概率和系统在该场景下的表现。

复习时建议把接受准则的定义过程和前面的危害识别、风险评估串起来看。接受准则不是独立的一步，而是整个分析链条的收口。如果前面的危害识别不完整，接受准则就失去了意义。

5. 易漏点与易错点：SOTIF 复习中最容易翻车的地方

5.1 易漏点一：把 SOTIF 当成功能安全的子集

这是最常见的理解偏差。SOTIF 不是功能安全的补充章节，而是一个独立的分析维度。功能安全问的是「系统坏了会不会危险」，SOTIF 问的是「系统没坏但能力不够会不会危险」。两者的分析对象、方法、输出都不同。如果把 SOTIF 活动塞进功能安全的框架里做，会漏掉大量场景相关的分析。

为什么漏：因为两份标准都涉及「安全」，而且经常在同一个项目里并行开展，容易在流程上混在一起。怎么补：在项目策划阶段就明确区分两份标准的活动清单，分别指定负责人和交付物。复习时把两份标准的目录并排对比，找出各自独有的章节。

5.2 易漏点二：触发条件识别不完整

触发条件的识别需要覆盖环境、其他道路参与者、基础设施、人因等多个维度。实际项目中，团队往往对环境和道路参与者分析得比较充分，但对基础设施和人因的分析容易流于表面。

为什么漏：基础设施相关的问题（比如标线磨损、标志被遮挡）往往被认为是「道路维护问题」，不被纳入系统设计的考虑范围。人因相关的问题则因为缺乏数据和方法，容易被简化处理。怎么补：在触发条件识别阶段引入多学科团队，包括人因工程和道路工程背景的人员。使用场景库和事故数据作为输入，而不是只靠工程团队的头脑风暴。

5.3 易漏点三：区域 4 的论证逻辑

区域 4 是「未知且安全」的场景。标准的目标是把区域 3 尽量缩小，但区域 4 本身无法直接验证。很多人在复习时会试图为区域 4 设计测试用例，这是逻辑上的错误。

为什么漏：因为「未知」的定义就是无法直接枚举，试图测试未知场景会陷入无限枚举的困境。怎么补：理解区域 4 是通过排除区域 3 来间接论证的。验证活动的目标是尽可能覆盖区域 3，然后用残余风险的接受准则来论证区域 4 的可接受性。复习时把第 11 章的评估逻辑和第 6 章的接受准则连起来看。

5.4 易漏点四：功能修改的闭环反馈

标准第 8.4 节明确要求，功能修改的结果要反馈到「规格与设计」阶段。这个反馈闭环在实际项目中容易被忽略，因为修改措施往往在开发后期才确定，此时重新走设计流程的成本很高。

为什么漏：项目进度压力导致团队倾向于在现有设计上打补丁，而不是回到设计阶段重新审视。怎么补：在项目策划时就为 SOTIF 迭代预留时间窗口。复习时注意第 8 章和第 5 章之间的输入输出关系，理解为什么标准强调这个闭环。

5.5 易漏点五：验证策略与触发条件的对应关系

验证策略的设计需要和前面识别的触发条件对应。如果触发条件识别不完整，验证策略就会覆盖不全。这个对应关系在标准第 9 章和第 7 章之间，复习时容易只关注第 9 章的方法，而忘了它的输入来自第 7 章。

为什么漏：第 9 章的内容更偏工程实施，看起来更「实用」，而第 7 章的分析性内容容易被当成理论铺垫。怎么补：把第 7 章的触发条件清单和第 9 章的验证活动做交叉对照，确保每个触发条件都有对应的验证手段。复习时用一张表把两者映射起来。

6. 复习清单与查漏补缺：一份可执行的检查流程

到了复习收口阶段，最有效的方式不是重新读一遍标准，而是用一份检查清单来定位自己的薄弱环节。下面这份清单按标准的章节顺序组织，每一项都可以作为自测问题。

这份清单的使用方法是：先不看标准，逐项自问，能清晰回答的跳过，卡住的标记出来，再回到对应章节精读。梳理下来会发现，卡住的地方往往不是记忆问题，而是逻辑链条没打通。比如，如果「功能修改措施」这一项卡住，大概率是因为前面的「功能不足分类」没理清，导致不知道修改措施要对应什么。

还有一个容易被忽略的复习技巧：把第 7 章的分析输出和第 9 章的验证输入做一次完整的映射练习。具体做法是，取一个具体的功能不足例子，比如「摄像头在强逆光下的识别率下降」，然后写出它的触发条件、对应的功能修改措施、以及验证这个修改是否有效的测试方案。这个练习能把标准从第 7 章到第 11 章的链条串起来，比单独背章节要点有效得多。

注意：复习时不要跳过第 4 章。很多人觉得第 4 章是概述，直接跳到第 5 章以后。但第 4 章的四象限模型和 Sense-Plan-Act 模型是后续所有分析的基础框架，跳过它会导致后面的章节缺乏组织逻辑。

从那以后我每次复习这份标准，都会先花十分钟把四象限模型默画一遍，再顺着 Sense-Plan-Act 把功能不足和触发条件的检查表过一遍。这个习惯帮我避免了很多次「以为自己懂了，一做题就卡住」的情况。希望这份梳理能帮到你。

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