★ FEATURED ARTICLE 简介面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者这份资料提供预期功能安全SOTIF领域两份核心标准的中文文本即国际标准 ISO 21448 与国家标准 GB/T 43267帮助读者系统理解在无实际故障情况下识别、评估并缓解由性能局限、感知偏差和算法约束引发的潜在危险。压缩包共 1 个 PDF 文件约 40.15MB内容为征求意见稿全文涵盖规范定义与设计、危害识别与评估、潜在功能不足与触发条件分析、修改功能以解决 SOTIF 风险、验证与确认策略等章节并附术语定义、工作成果要求及专利反馈说明目录结构完整便于按章节检索查阅。已有 735 人学习下载适合需要对照标准原文开展风险评估、设计审查或合规准备的读者作为案头参考。1. 预期功能安全没有故障的车为什么还会撞人一辆车所有 ECU 自检通过、没有报故障码、没有硬件失效却在高速上径直撞向侧翻的白色货车——这类事故的复盘报告里几乎找不到任何一条“故障”。这正是预期功能安全SOTIF要处理的问题危害不来自“东西坏了”而来自“东西没坏但不够好”。ISO 21448 是这套理念的国际标准版本而 GB/T 43267 是与之对应的国家标准文本把“规范定义不足”和“性能局限”这两类根因拆成了可执行的活动链条。搞懂它的价值在于功能安全GB/T 34590 那一套假定预期功能本身是安全的只防失效SOTIF 反过来追问——如果功能从一开始就定义得不完整、感知在某种光照下就是会漏检你拿什么证明残余风险可接受这个问题的答案不在测试报告的数量里而在因果模型和接受准则的设计里。2. SOTIF 因果模型危害是怎么从“不足”一路传导到伤害的2.1 两类根因规范定义不足与性能局限标准把“功能不足”拆成两个正交的来源这个拆分是整个体系的基石。第一类是规范定义不足需求本身写漏了、写偏了。典型例子是自适应巡航的跟车距离规范不完整导致自车没保持安全距离或者系统压根没把“不常见道路标识”纳入规范范围遇到就处理不了。第二类是性能局限规范写全了但所用组件和技术的固有特性决定了它做不到。摄像头在逆光下的动态范围、毫米波雷达对静止金属的区分能力都属于这一类。这个二分法的设计动机很实在两类根因的应对手段完全不同。规范不足靠改需求、补设计输入性能局限靠架构冗余、传感器融合、降级策略。如果混为一谈团队就会陷入“到底是需求没写清还是传感器不行”的无休止扯皮。我一般会这么理解规范不足是“没想到”性能局限是“想到了也做不到”SOTIF 活动要同时对这两本账。2.2 触发条件把“不足”变成“危害”的那根火柴功能不足本身是静态的、潜伏的它需要一个触发条件才会显形。触发条件可以是场景里的特定条件——强逆光、隧道出口的明暗突变、雨雾、特殊路面反光也可以是合理可预见的误用比如驾驶员在只适用于高速的功能上于城市道路激活它。标准明确触发条件触发功能不足后要么直接产生整车层面的危害行为要么导致系统无法防止、探测及减轻合理可预见的间接误用。这里有个容易被忽略的细节间接误用不被视为潜在触发条件因为它不能导致系统自身的危害行为它降低的是可控性、抬高的是事故严重度。驾驶员睡着间接误用不会让车自己跑偏但会让车跑偏时没人接管。因果模型里这两条路径是分开画的做分析时如果把它们揉在一起危害识别就会漏项。2.3 从要素到整车输出不足的聚合效应要素层面的功能不足被触发后产生的是输出不足输出不足本身、或与其他要素的多个输出不足叠加才促成整车层面的危害行为。这个层级关系决定了分析粒度单个感知模块的漏检率再低融合策略的时序错位也可能把两个“勉强够用”的输出拼成一个错误结论。常见的实现思路是在架构设计阶段就标注每个要素的输出不足如何向上聚合而不是等整车测试暴露问题再回溯。提示因果模型的价值不在于画得漂亮而在于它能逼你把“哪个要素、被什么触发、产生什么输出不足、如何聚合成整车危害”这条链逐段填实。填不实的地方就是分析盲区。3. 双层接受准则残余风险凭什么说“可接受”3.1 第一层与第二层行为判定和风险统计是两件事标准给出的接受准则分两层这是 SOTIF 里最容易被做歪的地方。第一层是危害行为接受准则判断车辆某一行为是否属于可能导致危害事件的危害行为通常是物理量阈值——轨迹扰动多大算危险、跟车距离小于多少算不合理。第二层是残余风险接受准则在给定行驶里程或时间内这类危害行为出现的频率是否处于合理水平。两层不能互相替代。只做第一层你会得到“每次行为都在阈值内”的结论但不知道这种边缘行为一天出现几次只做第二层频率达标了却可能掩盖单次极端行为的严重度。评估顺序是先判行为、再统计残余风险标准里用图 1 明确了这个先后关系。3.2 用交通统计和人类驾驶行为锚定阈值阈值从哪来标准给了两条务实路径一是从交通统计数据反推合理风险水平比如每多少千米一次事故二是与同等整车层面影响下“已证明驾驶员可控”的情形做类比。后者更常用——非预期车道保持辅助引起的轨迹扰动可以类比为横风对车辆的影响用横风的量级来定义该功能的接受准则。这个类比法的设计动机是绝对安全不存在但“人类驾驶员在日常中能稳定处理多大扰动”是一个有统计支撑的锚点。用锚点定义自动驾驶功能的危害行为阈值比拍脑袋定一个数字可信得多。需要注意的是双层准则的指标值会随技术演进、场景变化、交通文明程度漂移准则本身要留出复审机制。3.3 场景化时两层准则可能融合在特定功能场景下两层准则的理念可能融合通过统计某一场景下人类驾驶员操作行为的风险分布直接定义自动驾驶功能在该场景的危害行为接受准则。这不影响双层框架的有效性只是说明在数据充分时行为阈值可以从人类行为分布里直接导出。做 ADAS 项目的团队如果手上有足够的高精轨迹数据这条路比纯类比更扎实。4. 验证与确认已知场景和未知场景是两套打法4.1 已知场景感知、规划、执行分段验证对已知危害场景标准把验证拆到感知、规划算法、执行三个环节再做系统集成验证。分段验证的意义在于定位整车测试只能告诉你“这次没通过”分段验证能告诉你“是感知漏了还是规划决策错了”。感知验证关注在定义的触发条件下输出是否满足性能目标规划验证关注给定正确感知输入时决策是否合理执行验证关注控制指令到车辆运动的保真度。集成验证则专门盯要素间交互产生的聚合问题——也就是 2.3 节说的输出不足叠加。4.2 未知场景靠场景参数化和抽样逼近未知场景的评估是 SOTIF 最“玄学”的部分标准在附录 C 里给了场景参数化及场景抽样指导。核心思路是把场景拆成可参数化的维度光照、天气、道路几何、目标属性等在参数空间里做抽样用统计方法估计未知区域的残余风险。减少确认测试的考虑也在附录里不是所有参数组合都值得实车跑等价类和边界值能砍掉大量冗余。常见的实现思路是用仿真做大规模参数扫描、用实车和场地测试校验仿真置信度、用在环测试SIL/HIL/MIL覆盖危险注入。三层证据链的权重分配没有标准答案但逻辑必须是仿真负责广度实车负责可信度校准在环负责触发条件的可控注入。4.3 运行阶段发布不是终点标准第 13 章把运行阶段的活动纳入 SOTIF 闭环现场监控、SOTIF 问题评估和解决流程。设计动机很直接——未知场景的残余风险只能靠运行数据持续收敛。OTA 更新的 SOTIF 考虑附录 D.6也在这里一次更新可能引入新的功能不足发布前的评估和发布后的监控要配套。把 SOTIF 当成一次性认证的团队往往在第一次 OTA 后就翻车。5. 避坑SOTIF 落地时最容易踩的五个坑5.1 把 SOTIF 当功能安全的附录做现象团队沿用 HARA 的模板做 SOTIF 分析产出物里全是失效模式和 ASIL 等级。原因没理解两者的范围互补——GB/T 34590 假定预期功能安全、只防 E/E 故障SOTIF 处理的是无故障下的规范不足和性能局限。解决危害识别阶段就区分“失效导致的偏离”和“功能不足导致的危害行为”前者走功能安全流程后者进 SOTIF 因果模型两套工作成果分开归档、交叉引用。5.2 触发条件清单只写环境因素现象触发条件表里全是雨雾光照误用一栏空着。原因忽略了合理可预见的误用也是触发条件来源尤其是直接误用——在 ODD 外激活功能、模式混淆。解决按“环境触发 直接误用触发”两类分别建清单直接误用要覆盖用户手册边界外的操作和 HMI 引起的模式混淆间接误用单独列在可控性分析里。5.3 接受准则只定一层现象只定义了危害行为的物理阈值没有残余风险统计口径。原因把“单次行为不危险”等同于“整体风险可接受”。解决两层准则同时定义第一层给物理量阈值和类比依据第二层给单位里程/时间的事件频率上限和统计方法评估时严格按先行为后风险的顺序。5.4 未知场景评估全靠实车里程堆现象指望几十万公里路测覆盖未知场景预算烧完结论还是“没发现”。原因未知场景的参数空间维度高随机路测的覆盖效率极低。解决场景参数化 分层抽样仿真扫广度、实车校准仿真置信度、在环注入触发条件三层证据链各自说明覆盖了参数空间的哪一部分。5.5 OTA 更新不做 SOTIF 增量评估现象一次感知算法更新后直接推送没评估新模型在既有触发条件下的表现变化。原因把 SOTIF 当成车型认证的一次性活动。解决建立更新触发的增量评估清单——新模型引入哪些新的性能局限、原有触发条件清单是否需扩充、运行阶段监控指标是否要调整评估通过再发布。6. 设计取舍SOTIF 的边界在哪里以及怎么验证你读懂了它SOTIF 最值得琢磨的设计取舍是它主动划出的那条边界。标准明确不适用于信息安全威胁、不适用于系统技术直接导致的危害比如激光束对眼睛的伤害、不适用于明显违反预期用途的故意行为。这条边界不是偷懒而是把“可归因于功能不足”的风险单独拎出来让每类风险都有明确的责任标准。表 1 那张危害来源与标准映射表就是这种分工的产物E/E 故障归 GB/T 34590HMI 设计不当归人机交互原则网络攻击归信息安全标准SOTIF 只管功能不足和合理可预见的误用。另一个取舍在验证策略上标准没有给出“跑多少里程算够”的硬指标而是给方法论——场景参数化、抽样、双层准则。这看起来不够“可执行”但恰恰是诚实的不同功能、不同 ODD 的残余风险收敛速度差异巨大硬指标只会诱导团队去凑数字。真正可验证的是你的因果模型链条是否完整、接受准则是否有锚点、未知场景的抽样是否覆盖了参数空间的边界。想检验自己是否读懂了这套体系有个简单方法拿一个具体的 L2 功能试着填完“功能不足 → 触发条件 → 输出不足 → 整车危害行为 → 双层准则判定”这条链每一段都写出依据来源。填不顺的地方就是你对这个功能的理解还停在“它能用”而不是“它为什么安全”的层面。GB/T 43267 这份中文版文本的价值正在于它把 ISO 21448 的完整框架——从因果模型、双层接受准则到附录里的 GSN 论证示例、STPA 应用、场景抽样指导——落成了可以直接对照的中文条款附录 A 到 E 的资料性指南尤其适合拿来当分析模板。从那以后我每次评审一个智驾功能的安全论证都强制自己先问一句这条结论背后是规范不足还是性能局限触发条件写全了没有接受准则是哪一层。问完这三句很多看似完备的报告会立刻露出空洞。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
