企业官网建设流程全解析

简介：ISO 21448-2022《道路车辆——预期功能的安全性》是国际标准化组织发布的SOTIF领域核心标准，面向汽车制造商、零部件供应商、软件开发者及道路安全监管人员，用于解决自动驾驶与辅助驾驶系统在无故障条件下因功能局限、传感器识别错误、环境因素或人机交互问题而引发的安全风险。资源包内含1个PDF文件，大小约21.43MB，完整收录标准正文，涵盖术语定义、SOTIF活动组织方式、四类场景区域模型、危害识别与风险评估、验证确认方法及支持性流程等章节，可与ISO 26262功能安全标准形成互补参照。目前已有434人学习下载，适合从事智能驾驶安全设计、测试验证与合规审查的工程师系统研读，也可作为理解预期功能安全框架、搭建SOTIF开发流程的案头参考。

1. 预期功能安全 SOTIF：一张图看懂 ISO 21448 到底在管什么

如果你正在系统学习自动驾驶安全，或者备考相关认证，ISO 21448 大概率是你绕不开的一份标准。它和 ISO 26262 经常被放在一起讨论，但两者的边界很多人一开始就搞混。ISO 26262 管的是「系统坏了怎么办」——电子电气故障、随机硬件失效、系统性失效，核心思路是靠冗余、诊断、安全机制把故障控制住。而 ISO 21448 管的是另一件事：系统没坏，功能也按设计正常运行，但因为性能局限、场景超出预期、或者人机交互中的合理误用，导致了危险。这就是 SOTIF（Safety of the Intended Functionality）要解决的问题。

这份 2022 年发布的第一版标准，把 SOTIF 活动拆成了一条从「规格设计」到「已知场景评估」再到「未知场景评估」的完整链路。它不教你具体怎么写代码，而是给你一套识别风险、定义验收准则、验证残余风险的框架。适合谁看？做 ADAS 和自动驾驶系统设计的工程师、负责安全论证的评审人员、以及需要理解 SOTIF 与功能安全如何衔接的系统架构师。下面这张知识地图，是我梳理完整份标准后认为最值得先记住的骨架。

2. 核心框架：SOTIF 的四象限与三阶段模型

2.1 四场景区域：把风险按「已知/未知」和「安全/危险」切开

ISO 21448 最核心的一个思维工具，是把所有可能的运行场景按两个维度划分：是否已知，以及是否危险。这样就得到四个区域：

SOTIF 活动的目标很明确：把区域 2 尽量缩小，把区域 3 尽量转化为区域 2 或区域 1。区域 2 靠功能修改和验证来压缩，区域 3 靠场景库扩展、实地测试和论证来转化。梳理下来会发现，整份标准的结构就是围绕这四个区域的迁移来组织的。

注意：区域 3 不可能完全消除，标准要求的是论证残余风险「合理可接受」，而不是追求零风险。

2.2 Sense-Plan-Act 模型：功能不足从哪来

标准用「感知-规划-执行」这条链路来定位功能不足的来源。这个模型看起来简单，但它是后续第 7 章分析潜在功能不足和触发条件的逻辑基础。

• 感知环节：传感器在特定条件下（逆光、雨雾、隧道出入口）输出不准确或不完整。比如摄像头把白色货车车厢误识别为天空，雷达把井盖回波当成障碍物。
• 规划环节：算法对场景的理解出现偏差。比如把相邻车道的静止车辆误判为路边停靠，导致变道决策错误。
• 执行环节：执行器响应不符合预期。比如制动请求发出后，由于执行器延迟或特性曲线非线性，实际减速度不够。

每个环节都可能出现「性能不足」，而性能不足在特定触发条件下就会变成危险。标准第 7 章要求你系统性地识别这些不足和条件，而不是等到路测翻车了再回头补。

2.3 三阶段活动链路：从规格到验证的闭环

整份标准的活动可以归纳为三个阶段：

第一阶段：规格与设计（第 5 章）。定义功能是什么、系统架构怎么搭、性能不足和应对措施在设计阶段就要考虑。这一阶段的输出是后续所有分析的输入。

第二阶段：危害识别与风险评估（第 6 章）。识别功能不足可能导致的危害事件，评估风险等级，并定义残余风险的验收准则。验收准则这一步很关键，它决定了后面验证做到什么程度算「够了」。

第三阶段：功能修改与验证确认（第 8、9、10、11 章）。针对识别出的风险做功能修改，制定验证确认策略，然后分别评估已知场景和未知场景的残余风险。

这三个阶段不是瀑布式的，标准明确要求「更新规格和设计的输入信息」（第 8.4 节），也就是说验证阶段发现的新问题要反馈回设计。这是一个迭代闭环。

3. 规格与设计：SOTIF 活动的起点怎么定

3.1 功能规格要写到什么颗粒度

第 5 章的目标是「定义预期功能及其设计考虑」。很多人看这一章容易一带而过，觉得就是写需求文档。但 SOTIF 对规格的要求比传统功能安全更细，因为它要覆盖的是「正常运行时可能出现的性能局限」，而不是故障。

规格里至少要包含：

• 功能的完整定义，包括设计运行域（ODD）的边界条件
• 系统架构中与 SOTIF 相关的元素划分
• 已知的性能局限及其在设计中的应对思路
• 对外部接口的假设（比如对传感器输入质量的假设）

举个例子，如果功能是「高速公路自动跟车」，规格里不能只写「保持安全距离」，还要写清楚：在目标车突然切出、前方出现静止车辆、大雨导致雷达衰减等条件下，系统预期行为是什么。这些条件就是后续触发条件分析的种子。

3.2 系统架构考虑：哪些元素是 SOTIF 相关的

标准第 5.3 节要求识别「SOTIF 相关元素」。不是所有系统组件都和 SOTIF 有关，只有那些其性能不足可能导致危害事件的元素才需要纳入分析。

判断逻辑可以这样走：

1. 该元素是否参与感知、规划或执行链路？
2. 该元素的输出是否直接影响车辆行为？
3. 该元素是否存在已知的性能边界？

如果三个问题都是「是」，那它就是 SOTIF 相关元素。比如前向毫米波雷达是，因为它直接提供目标距离和速度；而车载娱乐系统的显示屏就不是，因为它不影响车辆控制。

提示：SOTIF 相关元素的划分会影响后续危害分析的边界，划得太宽会浪费精力，划得太窄会漏掉风险。建议在架构设计评审时专门过一遍这个清单。

3.3 性能不足与应对措施的设计考量

第 5.4 节要求在设计阶段就考虑性能不足和应对措施。这里有一个容易忽略的点：应对措施本身也可能引入新的性能不足。比如为了应对摄像头逆光失效，增加了雷达权重，但雷达在隧道出口的金属指示牌处容易产生虚假回波，这就引入了新的触发条件。

所以设计阶段的应对措施分析要成对出现：措施是什么，措施本身在什么条件下可能失效。这个思路会贯穿到第 7 章的功能不足分析中。

4. 危害识别与风险评估：验收准则怎么定

4.1 危害识别：从功能不足到危害事件

第 6 章的目标是识别「SOTIF 相关的危害事件」并评估风险。和 ISO 26262 的 HARA 不同，这里的危害不是由故障引发的，而是由性能不足加上触发条件引发的。

识别路径大致是：

1. 列出所有 SOTIF 相关元素
2. 对每个元素，分析其在 Sense-Plan-Act 链路中的功能不足表现
3. 对每种功能不足，找出可能触发它的条件
4. 将功能不足加触发条件组合，推导可能的危害事件

比如：摄像头在低对比度场景下（触发条件）无法识别车道线（功能不足），导致车道保持功能输出错误转向（危害事件）。

4.2 风险评价：和 ISO 26262 的差异在哪

风险评价的维度类似：严重度、暴露率、可控性。但 SOTIF 的风险评价有一个特殊之处：它要考虑合理可预见的误用。标准第 7.3.4 节专门讲「合理可预见的直接或间接误用」。

直接误用比如驾驶员在系统提示接管时没有及时接管；间接误用比如驾驶员过度信任系统，在系统设计运行域之外使用。这些不是故障，但会显著影响风险评价的结果。

4.3 残余风险验收准则：验证做到什么程度算够

第 6.5 节要求定义「残余风险的验收准则」。这是整份标准里最容易被低估的一步。验收准则不是拍脑袋定的，它要基于风险评价的结果，给出可量化或可论证的接受条件。

验收准则可以包括：

• 已知危险场景的残余风险低于某个阈值
• 未知危险场景的论证覆盖率达到某个水平
• 特定触发条件下的功能表现满足定义的最低要求

梳理下来会发现，验收准则定得越具体，后面的验证活动就越有方向。如果只写「风险可接受」，那验证阶段就会陷入无休止的测试。

5. 功能不足与触发条件：最容易漏掉的分析环节

5.1 规划算法相关的功能不足

第 7.3.2 节专门讲规划算法的功能不足。规划算法的输出是决策和轨迹，它的性能不足往往表现为：

• 对场景的语义理解错误（把静止车辆当成背景）
• 对其他交通参与者意图的预测错误
• 在复杂交互场景下的决策逻辑不完整

这些不足很难通过传统的故障注入测试发现，因为它们不是代码 bug，而是算法在特定输入分布下的固有局限。

5.2 传感器与执行器相关的功能不足

第 7.3.3 节覆盖传感器和执行器。传感器的功能不足包括探测距离不足、分辨率不够、在特定天气条件下的性能衰减、以及多传感器融合时的时空对齐误差。执行器的功能不足包括响应延迟、输出非线性、以及长时间工作后的性能漂移。

分析这些不足时，标准建议从「物理原理」出发，而不是从「已知故障模式」出发。比如摄像头在逆光下的性能不足，根源是动态范围限制，而不是某个电子元件坏了。

5.3 合理可预见的误用怎么分析

第 7.3.4 节要求分析「合理可预见的直接或间接误用」。这一块在传统功能安全里很少涉及，但在 SOTIF 里是重点。

直接误用的例子：系统发出接管请求后，驾驶员延迟接管或接管动作不充分。间接误用的例子：驾驶员因为系统在大多数情况下表现良好，而在系统设计运行域之外启用功能。

分析误用时，要考虑：

• 人机交互界面是否清晰传达了系统边界
• 接管请求的时机和方式是否合理
• 驾驶员监控系统是否能有效识别注意力状态

注意：误用分析不是为了让驾驶员背锅，而是为了在设计阶段就考虑如何降低误用发生的概率和后果。

5.4 触发条件的估计与可接受性判断

第 7.4 节要求估计系统对触发条件响应的可接受性。这一步是把前面的分析收拢：对每个识别出的触发条件，判断系统当前的响应是否可接受，如果不可接受，就需要进入第 8 章的功能修改。

判断可接受性时，要结合第 6 章定义的验收准则。如果验收准则要求「在触发条件下系统应能维持安全状态或发出有效接管请求」，那就要验证系统是否真的能做到。

6. 易漏点与易错点：SOTIF 实施中最容易翻车的地方

6.1 易漏点一：把 SOTIF 当成 ISO 26262 的附录

为什么漏：两份标准经常一起出现，很多人觉得 SOTIF 就是功能安全的一个补充章节，做 HARA 的时候顺带看一眼就行。

怎么补：SOTIF 有独立的危害识别方法、独立的风险评价维度和独立的验证策略。它管的是「无故障情况下的风险」，这个范围 ISO 26262 完全不覆盖。建议在项目计划里把 SOTIF 活动单独列一条工作流，有独立的里程碑和交付物。

6.2 易漏点二：触发条件分析只做传感器，不做规划

为什么漏：传感器的性能局限比较直观，容易想到；规划算法的不足往往被归为「算法优化问题」，不纳入安全分析。

怎么补：第 7.3.2 节明确要求分析规划算法的功能不足。建议在分析时把规划算法当成一个「有性能边界的组件」，像对待传感器一样列出它的已知局限和触发条件。

6.3 易漏点三：验收准则定得太模糊

为什么漏：项目早期信息不足，很难定出具体的验收准则，于是写一句「残余风险可接受」就过去了。

怎么补：验收准则可以分阶段细化。早期先定框架和维度，随着设计和分析深入，逐步填入具体指标。关键是每一条准则都要有对应的验证方法，否则就是空话。

6.4 易漏点四：忽略合理可预见的误用

为什么漏：误用分析需要人机交互、心理学、用户行为方面的输入，纯技术团队容易忽略。

怎么补：在危害分析阶段引入人因工程视角，或者参考同类功能在实际使用中的误用案例。标准第 8.3.5 节专门讲了「应对合理可预见的误用」的措施，包括功能限制、接管策略、驾驶员监控等。

6.5 易漏点五：未知场景评估没有方法论支撑

为什么漏：未知场景顾名思义就是「不知道的场景」，很多人觉得没法系统评估，只能靠路测里程堆。

怎么补：标准第 11 章给出了评估框架，核心思路是通过场景库扩展、仿真测试、实地测试和论证来逐步转化未知场景。关键是要建立「场景发现」的机制，而不是被动等待。

7. 复习清单：从已知到未知的查漏补缺路径

如果你正在复习 ISO 21448，或者准备在项目里落地 SOTIF 活动，下面这条查漏补缺路径可以帮你快速定位薄弱环节。

第一步：确认四象限模型是否理解到位。拿一个你熟悉的 ADAS 功能，试着把它的场景分别归入四个区域。如果区域 2 和区域 3 的边界说不清楚，回到第 4 章重新梳理。

第二步：检查规格和设计阶段的输出。功能规格里有没有写清楚 ODD 边界和已知性能局限？系统架构里有没有识别出 SOTIF 相关元素？如果这两项缺失，后面的分析都会悬空。

第三步：过一遍危害识别和风险评估。危害事件是不是从「功能不足加触发条件」推导出来的？验收准则有没有落到可验证的指标？误用分析有没有覆盖直接和间接两类？

第四步：核对功能不足分析的完整性。感知、规划、执行三个环节都覆盖了吗？触发条件的估计有没有结合验收准则做可接受性判断？

第五步：验证策略是否闭环。已知场景评估和未知场景评估分别对应哪些验证活动？验证发现的新问题有没有反馈回规格和设计？

下面这张表可以作为快速自检的对照：

我自己的习惯是，每次项目进入验证阶段之前，强制把这张表过一遍，尤其是「误用分析」和「未知场景评估」这两行，因为它们最容易被进度压力挤掉。从那以后我每次做 SOTIF 评审都强制走一遍这个清单，翻车的次数明显少了。希望帮到你。

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