★ FEATURED ARTICLE 简介面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者这份资料提供预期功能安全SOTIF领域两份核心标准的中文文本即国际标准 ISO 21448 与国家标准 GB/T 43267帮助读者系统理解在无实际故障情形下识别、评估并缓解自动驾驶与辅助驾驶系统潜在危险的方法论。压缩包内为 1 个 PDF 文件约 40.15MB内容涵盖规范定义与设计、危害识别与风险评估、潜在功能不足及触发条件的识别与评估、功能修改措施、验证与确认策略等完整章节并附术语定义与工作成果要求便于按标准结构逐章查阅与对照引用。目前已有 735 人学习下载适合需要将 SOTIF 流程落地到项目开发、或准备标准符合性审查的读者作为案头参考。1. 一份能直接翻的 SOTIF 中文版为什么我把它放在手边做 L2 以上辅助驾驶项目的人大概都遇到过这种场面评审会上有人问“这个感知漏检算功能安全还是预期功能安全”会议室安静三秒然后大家开始翻各自存的英文版 PDF页码对不上术语翻译还不一致。我最早接触 SOTIF 时也是这么过来的ISO 21448 的英文原版啃了三遍真正落地写危害分析和场景清单时还是心里没底。后来拿到这份 GB/T 预期功能安全征求意见稿的中文版情况才好转——它不是把英文逐字机翻而是按国内标准体系的表述习惯重新组织了术语和流程第 3 章的术语定义、第 5 到第 12 章的活动流程、附录 A 到 E 的工程指南基本能对着项目节点直接查。这份资源适合三类人刚接手 SOTIF 工作、需要快速建立流程框架的系统工程师要写危害识别和场景评估文档的安全工程师以及需要跟功能安全团队对齐边界的项目负责人。它解决的核心问题很具体——把“功能不足”和“故障”这两类风险拆开讲清楚让你知道哪些归 GB/T 34590 管哪些必须走 SOTIF 流程。2. 先分清边界SOTIF 和功能安全到底怎么切2.1 从因果模型看两类风险的差异很多人第一次读这份标准卡在“功能不足”这个词上。标准第 3 章把它定义为规范定义不足或性能局限并且明确说功能不足可能被认为是系统性故障但应对措施是 SOTIF 特有的。这句话背后的逻辑是功能安全假设预期功能本身是安全的只处理 E/E 系统失效导致的偏离而 SOTIF 处理的是系统没坏、但就是做不到的情况比如摄像头在逆光下漏检、融合算法对异形车辆识别不稳、决策逻辑对加塞场景响应过慢。标准图 2 到图 4 给的因果模型值得反复看。它把链条拆成触发条件、功能不足、输出不足、危害行为、危害事件、伤害几段并且区分了整车层面和要素层面。整车层面的功能不足被触发后直接产生危害行为要素层面的功能不足先产生输出不足再和其他要素的输出不足叠加才促成整车层面的危害行为。这个区分在写分析文档时非常实用——你可以在要素层记录“某传感器在雨雾下置信度下降”在整车层记录“AEB 未触发”两层分开归因评审时不容易扯皮。我一般会拿一个具体功能做对照练习假设某 L2 高速公路辅助功能感知要素在隧道出入口明暗突变时输出不稳定这是要素层功能不足驾驶员监控摄像头在驾驶员低头看手机时未能及时告警这是另一条要素层功能不足两条叠加驾驶员没接管、系统也没降级才构成整车层面的危害行为。按这个链条写下来触发条件、功能不足、危害行为各归各位比笼统写“感知不可靠”要经得起追问。2.2 用表 1 做标准映射避免重复劳动标准引言里的表 1 是我用得最多的一页。它把危害来源和对应标准列成了一张映射表E/E 系统故障归 GB/T 34590功能不足归本文件HMI 设计不当归本文件加人机交互原则基于 AI 算法的功能不足归本文件信息安全攻击归 ISO/SAE 21434 或 SAE J3061外部基础设施和 V2X 影响归本文件加相关标准环境因素如天气、电磁干扰归本文件加 GB/T 34590 和一系列电磁兼容标准。这张表的实操价值在于做 HARA 的时候团队经常把感知性能局限也塞进功能安全的安全目标里导致安全目标写得又大又空。正确的做法是先按表 1 分类属于功能不足的单独建 SOTIF 风险条目不要和随机硬件失效混在一个安全目标下。我见过一个项目把“摄像头在强光下漏检”写成 ASIL B 的安全目标结果验证时既没法用故障注入覆盖也没法用场景测试量化最后返工重写。如果一开始就按表 1 切开功能安全那边只管失效SOTIF 这边管性能和规范不足验证策略各走各的路工作量反而小。提示表 1 里“合理可预见的误用”同时出现在本文件和 GB/T 34590 两栏别理解成两边都要做全套。我的做法是直接误用比如在非 ODD 场景激活功能归 SOTIF 的触发条件分析间接误用比如驾驶员睡着导致可控性下降归 SOTIF 的无法防止/探测/减轻那条线功能安全只在误用直接引发系统失效时才介入。2.3 接受准则的双层结构怎么落到文档里第 3 章对接受准则的定义给了两层第一层判断车辆行为是否属于危害行为第二层判断残余风险是否处于合理水平。标准图 1 画了评估顺序先看单次行为或事件是否构成有风险的危害行为再看一定里程或时间内危害行为导致的残余风险是否可接受。落到文档里我一般这样组织第一层用场景化的行为判据比如“非预期横向加速度超过某阈值且持续超过某时长”算危害行为第二层用统计口径比如“每万公里危害行为导致的事件数低于某水平”或者跟人类驾驶员在同类场景下的操作分布做对比。标准注 2 提到可以类比横风来定义车道保持辅助的接受准则这个思路很实用——找一个使用中已被证明驾驶员可控的同类扰动作为参照比凭空拍一个数字更有说服力。需要提醒的是双层准则的指标值会随技术演变和场景变化而调整标准注 3 明确说了这一点。所以写接受准则时不要把数值写死成永久条款留一个“指标值依据年度统计和场景库更新复核”的机制后面改起来不至于推翻整份文档。3. 把流程跑起来从危害识别到场景评估的落地路径3.1 规范定义和设计阶段要产出什么第 5 章讲规范定义和设计目的很明确在功能定义阶段就把性能局限和应对措施写进去。标准要求考虑功能规范的定义、系统设计和架构、性能局限和应对措施工作成果是相应的规范文档。这一章容易被当成“写需求”跳过但后面所有分析都依赖这里的输入质量。我的做法是先列一张功能能力边界表把每个感知或决策环节的标称能力、已知局限、局限对应的场景条件写清楚。比如某前视摄像头标称检测距离、在不同照度下的置信度变化、雨雾条件下的衰减曲线这些数据来自供应商规格书和内部测试不是拍脑袋。这张表直接成为第 7 章潜在功能不足分析的输入也避免后面场景评估时找不到量化依据。系统架构层面标准强调要考虑要素之间的交互和冗余。这里有个常见误区以为加了冗余就万事大吉。实际上冗余要素如果共享同一个触发条件比如两个摄像头装在同一位置、同时被泥水遮挡冗余就失效了。所以架构考虑里要写清楚冗余的独立性假设以及假设不成立时的降级策略。3.2 危害识别与风险评估的操作顺序第 6 章给的是危害识别和风险评估的流程。标准没有规定具体方法但给了方向先识别危害再评估风险最后定义残余风险接受准则。我通常按三步走。第一步从功能场景出发做危害识别。把目标功能在 ODD 内的典型场景列出来逐场景问“这个功能在这里可能做出什么危害行为”。这一步不要过早收敛宁可多列。第二步对每个危害行为评估严重度、暴露度和可控性但注意 SOTIF 的风险评估和功能安全的 HARA 不完全一样——这里更关注场景条件和触发条件的组合而不是失效模式。第三步按第 3 章的双层接受准则定义哪些风险可接受、哪些必须改设计或加措施。下面这段伪代码是我用来管理危害条目的结构实际项目里用表格或需求管理工具实现这里用 Python 字典示意字段组织方式# 危害条目结构示意字段对应标准第6章的工作成果要求 hazard_item { id: SOTIF-HZ-012, function: 高速公路辅助驾驶, odd_scene: 隧道出入口明暗突变前车为异形货车, hazardous_behavior: 未保持安全跟车距离纵向减速度不足, trigger_conditions: [照度突变, 异形目标, 前车突然减速], severity: 高, # 按整车层面伤害潜力评估 exposure: 中, # 场景出现频率 controllability: 低, # 驾驶员在该场景下的可控性 acceptance_layer1: 横向/纵向行为判据, # 危害行为接受准则 acceptance_layer2: 每万公里事件数上限, # 残余风险接受准则 measures: [增加隧道场景标定, 融合毫米波雷达距离], status: 待验证 }这段结构的关键在trigger_conditions和measures两个字段。触发条件要写到可复现的程度不能只写“光照变化”要写清楚变化速率和范围措施要对应到具体的设计修改或验证活动不能写“加强测试”这种空话。字段acceptance_layer1和acceptance_layer2分开存是为了后面第 10、11 章评估时能分别引用。3.3 潜在功能不足与触发条件的分析手法第 7 章是整份标准里技术含量最高的部分之一。它要求识别潜在功能不足和潜在触发条件并预估系统对触发条件的响应可接受度。标准附录 B 给了场景和系统分析指南包括推导误用场景的方法、场景因素构建示例、以及 STPA 方法在 ADAS 和自动驾驶 SOTIF 研究中的应用。我常用的组合是先用场景因素分解把 ODD 拆成道路、交通、天气、光照、目标物几类因素每类因素列出取值和组合再对每个功能环节做 STPA 式的控制结构分析找“控制动作在什么条件下会不安全”。STPA 的好处是不依赖失效假设正好契合 SOTIF 处理“没坏但不够好”的场景。举个具体例子某自动紧急制动功能控制结构里感知环节输出目标距离和相对速度决策环节判断是否触发制动。用 STPA 分析时问“感知输出的距离在什么条件下会偏大导致制动过晚”得到的触发条件包括目标物反射率低、雨天镜头水膜、逆光过曝。这些条件再和场景因素组合就形成第 10 章已知场景评估的测试用例来源。标准第 7 章还要求预估系统对触发条件的响应的可接受度。这一步我一般用分级方式响应完全可接受、响应可接受但需监控、响应不可接受需修改设计。分级依据来自第 5 章的能力边界表和第 6 章的接受准则不是主观打分。3.4 修改功能与验证确认策略的衔接第 8 章讲修改功能以解决 SOTIF 相关风险第 9 章讲定义验证和确认策略。这两章要连起来看因为修改措施直接决定验证什么。标准第 8 章列的措施包括改进规范定义、增加冗余、限制 ODD、增加驾驶员监控等每类措施对应的验证方法不同。第 9 章把验证和确认分成集成和测试的定义工作成果是验证确认策略文档。我的经验是策略文档里必须写清楚三件事每个 SOTIF 风险条目对应哪类测试仿真、场地、道路、在环测试的通过判据是什么以及覆盖度怎么算。标准附录 C 给了验证和确认指导包括确认目标的导出、感知系统的验证确认、场景参数化及场景抽样、减少确认测试的考虑这几节在写策略时值得逐条对照。场景抽样那块特别实用。标准 C.5 讲场景参数化意思是把场景拆成可调参数比如车速、距离、光照强度、目标物类型用抽样方法覆盖参数空间而不是穷举。我一般先用拉丁超立方或均匀设计做初筛再对高风险区域加密采样。这样既控制测试量又能说清楚覆盖逻辑。C.6 还讨论了减少确认测试的考虑前提是你有充分的论证支撑不是随便砍用例。4. 已知场景与未知场景两套评估逻辑别混用4.1 已知场景评估的四个层面第 10 章把已知场景的评估拆成感知验证、规划算法验证、执行验证、系统集成验证最后汇总已知危害场景导致的残余风险。这个拆分方式很工程化因为不同层面的验证手段和判据完全不同。感知验证关注检测率、误检率、测距测速精度在不同场景条件下的表现通常用标注数据集加仿真回放场地测试做补充。规划算法验证关注决策逻辑在场景序列中的正确性更多依赖仿真和场景库回放。执行验证关注底盘响应是否跟得上规划指令场地测试为主。系统集成验证看端到端行为道路测试和影子模式数据是主要来源。我踩过的一个坑是把感知验证的指标直接当成系统级通过判据。感知召回率达标不代表端到端行为可接受因为规划环节可能把感知的不确定性放大也可能因为保守策略导致通行效率不可接受。所以第 10 章最后一步的残余风险评估必须站在整车行为层面做不能拿要素层指标凑数。4.2 未知场景评估的现实做法第 11 章讲未知场景评估标准给的方向是评估未知场景残余风险工作成果是相应文档。这一章读起来最“虚”因为未知场景没法穷举。我的理解是它要求两件事一是证明你的已知场景覆盖方法有合理的外推能力二是建立运行阶段的发现机制。外推能力靠场景参数化的覆盖论证比如你证明了在光照强度连续变化维度上采样足够密那么未采样的中间值风险可控。发现机制靠第 13 章的运行阶段活动包括现场监控和 SOTIF 问题评估解决流程。标准附录 D 里对机器学习的建议、OTA 更新的 SOTIF 考虑都是为未知场景留的口子——模型更新可能引入新的未知所以更新流程里要带回归评估。注意未知场景评估不是写一句“持续监控”就交差。评审时会被追问监控什么指标、触发什么动作、多久复盘一次。我一般会定义几个先行指标比如特定场景下的接管率突增、感知置信度分布偏移、影子模式中规划与人类驾驶的偏离度指标越界就触发场景库补充和风险评估更新。4.3 SOTIF 成果评估与发布推荐第 12 章讲 SOTIF 成果的评估包括评估方法和准则、SOTIF 发布推荐。这一章对应项目节点的安全发布决策。标准没有给一刀切的通过线而是要求基于前面各章的工作成果做综合评估。实操上我会准备一份 SOTIF 论证包内容包括功能定义和能力边界、危害条目及措施闭环状态、已知场景验证结果、未知场景评估和外推论证、运行阶段监控方案。发布推荐基于这份包做评审而不是只看某一项测试报告。附录 A.1 给了用 GSN 构建 SOTIF 论证的示例如果团队习惯用 GSN可以直接参考那个结构把论证包组织成目标-策略-证据的树形评审时逻辑链更清楚。5. 避坑与排查五条血泪经验5.1 把功能不足当故障写验证阶段返工现象危害分析文档里把感知性能局限写成失效模式验证计划里安排故障注入测试结果测不出问题评审被质疑覆盖不足。原因没有按标准表 1 做标准映射功能安全和 SOTIF 的条目混在一起。解决回到第 3 章的功能不足定义和第 6 章流程把条目按“失效导致”和“规范/性能导致”分开前者走 GB/T 34590 的验证方法后者走场景测试和触发条件注入。返工成本高最好在危害识别阶段就分栏管理。5.2 触发条件写得太粗场景库建不起来现象触发条件只写“雨天”“逆光”“异形目标”到了建场景库时发现没法参数化测试用例只能靠人拍脑袋。原因第 7 章要求识别潜在触发条件时没有落到可观测、可控制的参数。解决每条触发条件至少带一个可量化维度比如降雨量范围、照度变化速率、目标物长宽比范围。标准附录 C.5 的场景参数化方法可以直接拿来当模板先定参数再写条件。5.3 接受准则只有一层残余风险说不清现象项目评审时被问“单次危害行为可接受但一年跑下来累积风险怎么算”答不上来。原因只定义了危害行为判据没定义残余风险接受准则违反第 3 章双层结构的要求。解决补第二层准则用里程或时间口径统计危害行为导致的事件率参照标准注 2 的类比方法找可比对象。两层准则分开写、分开评别混成一句话。5.4 验证确认策略漏掉在环测试的定位现象验证计划里仿真、场地、道路都有但 SIL/HIL/MIL 的用途说不清楚被问“为什么这个场景要在 HIL 做”时只能答“惯例”。原因第 9 章要求定义集成和测试时没有把在环测试和风险条目对应起来。解决按标准引言示例 2 的思路把在环测试定位为触发条件注入和场景覆盖的手段每个在环测试用例标注它覆盖哪个触发条件和哪个功能不足策略文档里写清楚选择理由。5.5 运行阶段监控指标和 SOTIF 条目脱节现象第 13 章的运行阶段活动写了一套监控指标但和前面的危害条目对不上出了现场问题不知道回溯到哪条分析。原因监控方案独立编写没有和危害条目 ID 关联。解决每个现场监控指标至少挂一个危害条目或触发条件 IDSOTIF 问题评估解决流程里要求回溯到对应条目并更新风险评估。这样运行阶段的数据才能真正反哺设计和验证。6. 进阶用法把附录当工具箱用 GSN 串起论证链这份标准正文给流程附录给方法真正干活时附录的使用频率不比正文低。附录 A.1 的 GSN 论证示例我建议每个做 SOTIF 发布评审的人都看一遍它把“功能安全目标达成”拆成策略和证据正好对应第 12 章的成果评估。附录 B.4 的 STPA 应用示例适合做第 7 章分析时对照尤其是控制结构画法和不安全控制动作的归类。附录 C.4 感知系统验证确认和 C.5 场景参数化抽样是建场景库和定测试量的直接参考。附录 D 里 D.2 机器学习建议、D.5 感知性能目标量化与传感器局限举例、D.6 OTA 更新考虑对应现在项目里最常见的三类新问题遇到时先翻这几节再决定要不要另找资料。我自己的习惯是建一个“标准条款-项目文档”对照表左边列标准章节和附录编号右边列项目里对应的文档或数据库条目每次评审前过一遍看哪些条款还没有落地证据。这个表最初是手写的后来变成需求管理工具里的一个视图。下面是一个简化示例用表格说明对照关系标准条款项目落地物检查要点第 5 章 规范定义和设计功能能力边界表、架构冗余假设局限是否量化冗余独立性是否写明第 6 章 危害识别和评估危害条目库、双层接受准则条目是否按表 1 分类两层准则是否分开第 7 章 功能不足与触发条件触发条件清单、STPA 分析记录触发条件是否可参数化第 9 章 验证确认策略验证确认策略文档、在环测试映射每个风险条目是否有测试归属第 13 章 运行阶段活动监控指标表、问题回溯流程指标是否挂危害条目 ID这张表最大的作用是防止“标准读完了但项目里找不到对应物”。有一次内部评审第 7 章的触发条件清单只有半页对照表一拉出来就发现感知环节的触发条件几乎没写当场补了两周的分析。从那以后我每次做 SOTIF 节点评审前都强制走一遍这张对照表缺哪补哪不靠记忆。希望这份中文版和这套用法能帮到你少走几段我走过的弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
