预期功能安全SOTIF：无故障车辆为何仍会撞人？
简介：面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者，这份资料提供预期功能安全（SOTIF）领域的核心标准文本，重点解决自动驾驶与辅助驾驶系统在无故障情况下因性能局限、感知偏差和算法约束而引发的安全风险识别与评估问题。压缩包共1个PDF文件，约40.15MB，为GB/T标准征求意见稿版本，内容涵盖术语定义、功能规范与设计、危害识别与风险评估、潜在功能不足及触发条件分析、修改功能以解决SOTIF相关风险、验证与确认策略等完整章节，并附目次与引言，便于按标准结构系统研读。已有747人学习下载，适合作为理解ISO 21448与国内标准衔接、搭建SOTIF流程框架的案头参考，也可用于跨学科团队在危害分析、残余风险接受准则定义等环节的对照查阅。
1. 预期功能安全：没有故障的车，为什么还会撞人
一辆车所有零部件都正常工作，传感器没坏、芯片没烧、代码没崩，它依然可能撞上护栏。这不是玄学，而是 SOTIF（Safety of the Intended Functionality，预期功能安全）要处理的核心问题。传统功能安全问的是“东西坏了怎么办”，SOTIF 问的是“东西没坏，但它看错了、想错了、能力不够，怎么办”。ISO 21448 是这套思路的国际标准，GB/T 43267 是它的国内对应版本，两者共同补上了功能安全标准覆盖不到的那块盲区——由规范定义不足和性能局限引发的危害。搞懂这套机制，才能理解为什么 L2 以上的辅助驾驶，光靠“零故障”根本不够。
2. SOTIF 的因果模型：危害行为到底从哪来
2.1 功能安全与预期功能安全的分工边界
要理解 SOTIF，先得把它的边界划清楚。GB/T 34590（对应 ISO 26262）处理的是 E/E 系统的故障——随机硬件失效、系统性失效，这些是“东西坏了”引发的问题。而 SOTIF 处理的是另一类：系统按设计正常工作，但设计本身的能力不够，或者规范定义有缺口，导致输出不符合实际场景的需要。
标准里给了一个很清晰的映射表：电气/电子系统故障归 GB/T 34590 管；功能不足归 SOTIF 管；不正确的人机交互设计归 SOTIF 管；基于人工智能算法的功能不足归 SOTIF 管；合理可预见的误用归 SOTIF 管；信息安全攻击归 ISO/SAE 21434 管；车辆周围环境的影响归 SOTIF 和一系列电磁兼容标准共同管。
这个分工的关键在于：功能安全假定“预期功能本身是安全的”，它只防故障导致的偏离；SOTIF 则反过来，假定“没有故障”，专门审视预期功能本身在真实场景下够不够用。两者互补，缺一不可。常见的实现思路是，在项目早期就把两份标准的活动并行铺开，而不是先做完功能安全再补 SOTIF——因为 SOTIF 的很多分析结果会反过来修改功能规范，越晚介入改动成本越高。
2.2 从触发条件到伤害的完整链条
标准用图 2 到图 4 描述了一条完整的因果链，这条链是整份文件的分析骨架。链条的起点是触发条件（triggering condition），它可以是环境因素（逆光、大雨、隧道出入口的光照突变）、可以是其他交通参与者的行为（突然加塞、异常姿态的行人）、也可以是合理可预见的误用（在非设计运行范围内激活功能）。
触发条件本身不产生危害，它只是“扣动扳机”。真正被触发的是功能不足（functional insufficiency），标准把它拆成两类：规范定义不足（insufficiency of specification）和性能局限（performance limitation）。前者是“该写的没写清楚”，比如自适应巡航的跟车距离规范定义不完整，导致自车没和前车保持安全距离；后者是“写了但做不到”，比如摄像头在强逆光下动态范围不够，识别不出前车尾灯。
功能不足被触发后，在整车层面表现为危害行为（hazardous behavior），比如非预期的轨迹偏离、该刹车没刹车。危害行为在特定场景下演变成危害事件（hazardous event），最终可能导致伤害。标准特别强调，场景是伤害发生的“助推因素”而不是“来源”——危害的来源始终是整车层面的危害行为。
还有一条容易被忽略的支线：间接误用。比如 L2 系统要求驾驶员持续监控，但驾驶员睡着了。这里涉及两类功能不足——一类导致系统产生危害行为，另一类导致驾驶员监控系统没能探测并减轻这个误用。两条链同时断裂，伤害才会发生。这个双链模型是 SOTIF 分析里最容易翻车的地方，后面会专门讲。
2.3 要素级不足如何汇聚成整车级危害
标准区分了整车层面和要素层面的功能不足。整车层面的不足被触发，直接导致危害行为；要素层面的不足被触发，先产生输出不足（insufficient output），然后一个或多个输出不足组合起来，才促成整车层面的危害行为。
这个分层不是文字游戏，它直接决定了分析该在哪一层做。举个例子：某跨平台系统的感知模块里，单个毫米波雷达在金属护栏密集的路段产生多径反射，输出了一批虚假目标——这是要素级的输出不足。融合模块如果没设计足够的交叉验证逻辑，虚假目标被采纳，规划模块据此做出急刹决策——这就汇聚成了整车级的危害行为。
我一般会这么理解：要素级分析回答“这个传感器/算法在什么条件下会给出不可信的输出”，整车级分析回答“这些不可信输出组合起来，车会做出什么危险动作”。两层之间需要一个明确的接口——标准里叫“预估系统对触发条件的响应的可接受度”，说白了就是给每个要素的输出定一个可信度门槛，低于门槛的输出不能直接进决策链。
3. 双层接受准则：残余风险凭什么说“可以接受”
3.1 危害行为准则与残余风险准则的分层
SOTIF 里最反直觉的设计之一，是接受准则（acceptance criterion）被拆成了两层。第一层判断“某个车辆行为算不算危害行为”，第二层判断“运行过程中残余的安全风险是否处于合理水平”。标准给了一个很接地气的类比：非预期车道保持辅助引起的轨迹扰动，可以类比成横风来定准则——因为驾驶员对横风是可控的，那么对同等程度的轨迹扰动也应当可控。
这个类比的背后是一套务实的方法论：SOTIF 不追求“零风险”，它追求的是“风险不比一个可参照的基准更差”。基准可以来自交通统计数据（每 X 千米发生一次事故），也可以来自人类驾驶员在同等场景下的操作行为统计。对于自动驾驶功能，标准甚至允许直接用人类驾驶员在特定场景下的风险统计来定义危害行为接受准则。
两层准则的评估顺序是先行为后风险：先逐个判断车辆行为是否构成有风险的危害行为或危害事件，再针对一定行驶里程或行驶时间内出现的危害行为，评估其可能导致的残余危害风险是否可以接受。这个顺序不能反——先算总账再拆单项，很容易把某个高频但单次后果轻的危害行为稀释掉。
3.2 指标值为什么会随技术和场景漂移
标准在注 3 里写了一句很关键的话：双层接受准则的指标值可能受技术演变、场景变化、交通文明程度提升等多方面因素影响，因而在应用过程中也可能伴随接受准则及其指标值的变化。
这句话的工程含义是：接受准则不是一次定死、终身有效的常量。三年前某类感知局限在当时的传感器水平下算“可接受”，三年后同类局限在竞品普遍做得更好的情况下就可能不再可接受。常见的做法是把接受准则写进配置库，和场景库、传感器规格一起做版本管理，每次 OTA 更新或场景库扩充时重新审视一遍。
提示：接受准则的指标值一旦写进安全论证文档，就要同步记录它的推导依据和适用版本。否则几年后回头看，没人说得清这个数字是怎么来的，安全论证就变成了黑匣子。
3.3 用 GSN 把论证链固定下来
标准附录 A.1 给了用 GSN（Goal Structuring Notation）构建 SOTIF 论证的示例。GSN 的核心是把“结论”和“支撑证据”显式连起来：顶层目标是“该功能的残余风险可接受”，下面挂子目标，每个子目标挂解决方案（测试报告、分析记录、统计数据）。
这套结构解决的是 SOTIF 论证里最头疼的问题——证据和结论对不上。血泪经验是：很多团队测试做了几千个场景，报告堆了一摞，但没人能说清哪个场景支撑哪条结论。用 GSN 强制建链之后，每条证据都必须挂在某个子目标下，挂不上去的证据要么是冗余的，要么说明论证结构有缺口。缺口一旦显式化，补测就有了方向，而不是盲目加场景数量。
4. 已知场景与未知场景：验证和确认怎么分兵
4.1 已知场景的评估：感知、规划、执行逐层验证
标准第 10 章把已知场景的评估拆成感知验证、规划算法验证、执行验证、系统集成验证四层。这个拆法和第 2 章的因果模型是对应的——要素级不足在感知层暴露，汇聚后的危害行为在规划和执行层暴露，集成验证则检查层与层之间的接口有没有漏掉不可信输出。
感知验证的重点不是“识别率多高”，而是“在哪些触发条件下识别率会掉、掉到什么程度、掉了之后下游知不知道”。常见的实现思路是给感知输出附带置信度和失效标志，规划层根据这些标志决定降级策略。规划算法验证则要覆盖那些“感知正确但决策仍可能危险”的场景，比如前车突然消失（可能是被遮挡而非驶离）时，规划是加速还是保守减速。
执行验证容易被轻视，因为执行机构相对成熟。但标准特意提到，传感器在车辆上的位置和安装可能与振动导致的输出噪声有关，挡风玻璃的光学特性会影响摄像头——这些都属于执行/安装层面的 SOTIF 因素，不能只盯着算法。
4.2 未知场景的评估：残余风险的另一半
第 11 章处理未知场景，逻辑上很坦诚：你不可能测试你没见过的场景，所以未知场景的残余风险只能通过间接手段评估。标准给的路径包括：用已知场景的覆盖率和外推能力推断未知区域的边界、通过运行阶段的现场监控发现新的触发条件、以及用场景参数化和抽样方法估计未测区域的 risk 水平。
附录 C.5 的场景参数化及场景抽样指导是这一章的操作核心。思路是把场景拆成可参数化的维度（光照、天气、道路曲率、交通密度、目标类型等），在每个维度上定义取值范围和采样策略，用有限的测试预算覆盖尽可能大的参数空间。C.6 还专门讨论了“减少确认测试的考虑”——不是所有参数组合都值得实测，有些可以用仿真或分析替代，前提是替代的有效性本身要被论证。
这里有个设计取舍值得说透：已知场景测的是“深度”，未知场景估的是“广度”。预算有限时，两者是竞争关系。我见过的翻车案例是团队把 80% 预算砸在已知场景的回归测试上，未知场景的抽样几乎没做，结果量产后的现场监控报上来一批从没测过的触发条件，整改周期被压得极短。
4.3 场景库与 ODD 的映射关系
标准第 5 章要求定义功能规范时同步考虑性能局限和应对措施，第 3 章定义了 ODD（设计运行范围）。场景库和 ODD 之间需要一张显式的映射表：每个场景属于 ODD 内、ODD 边界还是 ODD 外，对应的系统响应是什么（正常工作、降级、请求后援、进入最小风险状态）。
这张表的价值在于把“合理可预见的误用”变成可检测的条件。比如城市环境里激活了为高速公路设计的功能，这属于直接误用，是潜在的触发条件。如果系统有定位组件能判断当前不在 ODD 内，就应当拒绝激活或主动退出。标准在误用的示例里特意区分了“系统是否包含防止 ODD 外激活的组件”——有没有这个组件，误用的处理路径完全不同。
5. 避坑：SOTIF 落地时最容易踩的五个坑
5.1 把 SOTIF 当成功能安全的附录
现象：项目里先做完 HARA 和功能安全活动，最后留两周“补一下 SOTIF 文档”。原因：把 SOTIF 理解成功能安全的补充章节，而不是并行的分析主线。后果是 SOTIF 分析发现的规范定义不足来不及反馈到设计阶段，只能靠测试兜底，成本翻几倍。解决：在概念阶段就把 SOTIF 的规范定义审查和功能安全的 HARA 并行启动，两份分析共享场景库，但结论分别归档。
5.2 触发条件清单只写环境因素
现象：触发条件表里全是雨、雾、逆光，没有一条涉及其他交通参与者的异常行为或人机交互。原因：把触发条件窄化成了“传感器干扰项”。实际上标准明确把合理可预见的误用、模式混淆（功能未激活但驾驶员以为已激活）都列为触发条件。解决：按“环境 / 交通参与者 / 系统自身状态 / 用户行为”四个维度建触发条件清单，每个维度至少做一轮头脑风暴再收敛。
5.3 间接误用的双链只分析了一条
现象：分析了感知不足导致的危害行为，但没分析驾驶员监控系统为什么没兜住。原因：第 2 章说的双链模型——间接误用需要两类功能不足同时存在才导致伤害，只分析一条链会低估风险。解决：对每个涉及后援用户的 L2/L3 功能，强制画两条链：一条是“系统产生危害行为”，一条是“系统未能探测并减轻误用”，两条链的触发条件分别列。
5.4 接受准则拍脑袋定数字
现象：残余风险准则直接写“每万公里不超过 0.1 次”，问依据是什么，答“参考了同行”。原因：没有走标准第 6 章要求的风险评估和准则定义流程，缺少可追溯的推导依据。解决：准则的每个数字都要挂推导链——来自交通统计、来自人类驾驶员行为类比、还是来自同等整车层面影响的对比，写清楚适用版本和假设条件。
5.5 运行阶段监控只做故障报警
现象：量产后的现场监控只报硬件故障和软件崩溃，SOTIF 相关的事件（非预期急刹、异常轨迹、驾驶员接管）没有结构化采集。原因：把第 13 章的运行阶段活动理解成了传统售后质量监控。解决：定义 SOTIF 事件的数据 schema，至少包含触发条件标签、系统响应、驾驶员干预动作、场景快照，回传后进入触发条件库做闭环分析。
6. 设计取舍：SOTIF 的边界在哪里，怎么验证它真的在工作
SOTIF 这套框架最值得琢磨的设计取舍，是它对“未知”的处理方式。功能安全可以靠 FMEA 和故障树把失效模式穷举得比较干净，SOTIF 面对的是开放世界的场景空间，穷举不可能。标准没有假装能穷举，而是把未知场景的残余风险交给运行阶段的持续监控来兜——这是一种承认边界的务实设计，代价是把安全责任从“出厂即定型”延伸到了全生命周期。
这个取舍带来的工程后果是：SOTIF 的验证不能只看测试报告，还要看运行阶段的闭环能力。判断一套 SOTIF 流程是否真的在工作，我一般看三个信号：一是触发条件库是否在量产后持续增长（只减不增说明监控没起作用）；二是每次 OTA 更新是否触发了接受准则的重新审视（准则版本和功能版本是否同步）；三是 GSN 论证里是否存在挂不上证据的子目标（存在缺口说明论证结构还在演进，这是正常的，但缺口必须被记录和跟踪）。
标准附录 D 里对机器学习、地图、V2X、OTA 更新的专门讨论，其实都在回应同一个问题：这些技术的“功能不足”很难在出厂前完全刻画，所以它们的 SOTIF 论证必须依赖运行阶段的证据补充。D.6 关于 OTA 更新的 SOTIF 考虑尤其关键——每次更新都可能改变功能的行为边界，更新本身就是一个需要重新走 SOTIF 评估的变更事件。
从那以后我每次评审 SOTIF 文档，都强制先翻两样东西：触发条件库的版本历史，和接受准则的推导依据。这两样对不上，后面的测试报告再厚我也不敢签字。希望帮到你。
本文还有配套的精品资源，点击获取