预期功能安全SOTIF：无故障车辆为何仍会撞人？

简介面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者这份资料提供预期功能安全SOTIF领域的核心标准文本重点解决自动驾驶与辅助驾驶系统在无故障情况下因性能局限、感知偏差和算法约束而引发的安全风险识别与评估问题。压缩包共1个PDF文件约40.15MB为GB/T标准征求意见稿版本内容涵盖术语定义、功能规范与设计、危害识别与风险评估、潜在功能不足及触发条件分析、修改功能以解决SOTIF相关风险、验证与确认策略等完整章节并附目次与引言便于按标准结构系统研读。已有747人学习下载适合作为理解ISO 21448与国内标准衔接、搭建SOTIF流程框架的案头参考也可用于跨学科团队在危害分析、残余风险接受准则定义等环节的对照查阅。1. 预期功能安全没有故障的车为什么还会撞人一辆车所有零部件都正常工作传感器没坏、芯片没烧、代码没崩它依然可能撞上护栏。这不是玄学而是 SOTIFSafety 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 给了用 GSNGoal 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 文档都强制先翻两样东西触发条件库的版本历史和接受准则的推导依据。这两样对不上后面的测试报告再厚我也不敢签字。希望帮到你。本文还有配套的精品资源点击获取