简介面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者这份资料提供预期功能安全SOTIF领域的核心标准文本重点解决自动驾驶与辅助驾驶系统在无故障情形下因性能局限、感知偏差和算法约束所引发风险的识别与管控问题。包内共1个PDF文件约40.15MB为GB/T标准征求意见稿正文涵盖规范定义与设计、危害识别与评估、潜在功能不足及触发条件分析、功能修改措施、验证与确认策略等章节并附术语定义、工作成果清单与目次结构便于按流程查阅。已有747人学习适合作为理解ISO 21448与国内标准衔接、搭建SOTIF开发流程的案头参考也可用于跨学科团队对齐风险评估与残余风险接受准则的讨论依据。1. 预期功能安全没有故障的车为什么还会撞人一辆车所有 ECU 自检通过、没有故障码、没有硬件失效却在高速上径直撞向侧翻的白色货车——这类事故的复盘报告里往往找不到任何“坏了”的部件。这正是预期功能安全SOTIF要处理的问题危害不来自失效而来自“功能本身就不够好”。ISO 21448 是首个系统化应对这一问题的国际标准而 GB/T 43267 是它在国内落地的国家标准版本两者共同回答一个问题——当系统按设计正常工作却仍然产生危害时我们该拿什么去论证它是安全的。搞懂这套机制你才能明白为什么“零故障”不等于“零风险”也才能看懂自动驾驶安全论证里那些看似繁琐的流程到底在防什么。2. SOTIF 的因果模型危害到底从哪条链路长出来2.1 功能不足把“没坏”和“不够好”拆开功能安全标准假定预期功能是安全的只盯着 E/E 系统的故障SOTIF 反过来假定系统没有故障只盯着功能本身的不足。标准把“功能不足”定义成两样东西的并集规范定义不足和性能局限。前者是“该写的没写全”比如自适应巡航的跟车距离规范定义不完整导致自车没和前车保持安全距离后者是“写了但物理上做不到”比如摄像头在逆光下动态范围不够感知输出就是偏的。这个拆分很关键因为它决定了后续所有活动的走向。规范定义不足可以通过改需求、改设计来消除属于“人没想周全”性能局限只能通过约束使用场景、加冗余、加降级策略来管理属于“技术天花板”。标准在术语里还特意区分了“潜在功能不足”——当“促成危害行为的能力尚未被建立”时用这个词意思是我们怀疑这里有问题但还没证明它真的会在某个场景下触发危害。这个“潜在”二字贯穿整个 SOTIF 流程因为绝大多数工作就是在把“潜在”变成“已知”再把“已知”消灭掉或管住。常见的实现思路是把功能不足按整车层和要素层分开建模。整车层的功能不足被触发条件触发后直接导致危害行为或者导致系统无法防止、探测、减轻合理可预见的间接误用要素层的功能不足被触发后先产生“输出不足”输出不足本身或与其他要素的输出不足叠加才促成整车层的危害行为。这个两层结构在标准的因果模型图里画得很清楚也是后面危害识别和场景分析的骨架。2.2 触发条件与场景危害的“点火器”功能不足是火药触发条件是火星。标准把触发条件定义为场景中能触发功能不足的特定条件它可以是环境因素大雨、逆光、隧道出入口的光照突变可以是道路因素不常见的道路标识、施工区的临时标线也可以是其他交通参与者的行为前车突然切出、非机动车逆行还可以是合理可预见的误用在 ODD 外激活功能、驾驶员脱手后睡着。这里有个容易翻车的点误用分直接和间接。直接误用本身可能就是触发条件比如在城市环境里激活了为高速设计的辅助驾驶功能系统没识别停车标志间接误用不触发系统自身的危害行为而是降低可控性或加重事故严重度比如 L2 系统要求驾驶员持续监控驾驶员却睡着了。标准明确说间接误用不算潜在触发条件因为它不能导致系统自己产生危害行为——这个区分在做危害分析时如果搞混会把因果链画错后面风险评估全跟着偏。场景的定义在标准里是“场景快照 行为/事件的时序”也就是说一个场景不只是某一帧的画面还包含参与者动作的先后顺序。这解释了为什么 SOTIF 的验证不能只靠单帧图像测试集必须做时序化的场景回放和注入。我一般会这么理解功能不足是静态的缺陷触发条件是动态的输入序列两者在时间轴上对齐的那一刻危害行为才真正发生。2.3 双层接受准则先判“是不是危害行为”再判“残余风险能不能接受”标准给接受准则定义了两个层次这是整个 SOTIF 评估的度量尺。第一层是危害行为接受准则判断车辆某一行为或事件是否构成有风险的危害行为指标往往是物理参数比如轨迹扰动的幅度、减速度的大小。第二层是残余风险接受准则判断在一定行驶里程或时间内这些危害行为导致的残余危害风险是否处于合理水平指标可能是每小时最大事件数、ALARP 水平等。为什么非要分两层因为单层判据会陷入两难如果只看单次行为任何一次轻微的画龙都可能被判为不可接受工程上没法收敛如果只看总体事故率又会漏掉那些低频但单次后果极重的行为。双层结构把“行为合不合格”和“总体风险合不合理”解耦先逐事件筛再按里程统计。标准还给了个很实用的类比思路用同等整车层面、已被证明驾驶员可控的影响来定义准则比如非预期车道保持辅助引起的轨迹扰动可以类比横风来定接受准则。这个思路的血泪经验是类比对象选错了准则就形同虚设——拿市区低速场景的横风去类比高速场景的扰动量级差一个数量级评估结论会完全失真。3. 从规范定义到功能修改SOTIF 怎么在设计和验证之间闭环3.1 规范定义和设计把“预期行为”写死SOTIF 活动的起点是规范定义和设计。标准要求在这一步定义功能规范、考虑系统设计和架构、考虑性能局限及应对措施。核心概念是“预期行为”——开发者考虑了组件和技术固有局限之后的标称功能行为。注意预期行为不代表没有不合理风险它只是开发者认为合理的那个行为它可能和驾驶员对系统的期望不匹配这个错位本身就是 SOTIF 要处理的风险来源。这一步的产出是后续所有分析的输入。常见的实现思路是把功能规范、系统架构假设、性能局限、应对措施都落到一个可追溯的需求库里因为标准在术语注里明确说从规范定义、其他系统假设或系统性分析中衍生出的要求很多组织不认为它们是“规范定义”但对确保 SOTIF 是必要的标准把这类衍生要求的不足也纳入“规范定义不足”。换句话说需求库漏了一条衍生要求后面就可能变成一个没被识别的功能不足。性能局限的应对措施在这一步就要想清楚是加传感器冗余是限制 ODD是设计降级策略还是靠人机交互把局限告知用户。这几种手段的成本和残余风险完全不同选型时要把后面的验证成本一起算进去否则设计阶段省的事验证阶段要加倍还。3.2 危害识别与风险评估HARA 之外还要做什么危害识别和评估这一章的目的是识别整车层面的危害、做风险评估、定义残余风险接受准则。它和功能安全的 HARA 长得像但输入不同功能安全的 HARA 从功能失效出发SOTIF 的危害识别要从“功能在正常工作时可能产生的危害行为”出发还要覆盖合理可预见的误用。风险评估之后要定义残余风险接受准则也就是前面说的双层准则。这一步的难点在于量化。标准在附录里给了风险接受准则的示例但没给万能公式因为不同功能、不同 ODD 的可接受水平本来就不一样。工程上常见的做法是先用定性方法把危害行为排序再对高优先级项做定量分析定量数据来源包括交通统计数据、自然驾驶数据、仿真统计。这里有个坑用交通统计数据推合理风险水平时要确认统计口径和你的 ODD 匹配拿全路况事故率去套一个只在高速白天运行的功能结论会偏保守到没法用。3.3 潜在功能不足与触发条件的识别STPA 和场景因素怎么用这一章是 SOTIF 的技术核心识别潜在功能不足和潜在触发条件并预估系统对触发条件的响应的可接受度。标准在附录里给了方法指引包括推导误用场景的方法、场景因素构建示例、以及把 STPA 应用到 ADAS 和自动驾驶 SOTIF 研究中的示例。STPA 的思路是从控制结构出发找“不安全的控制行为”再倒推是什么上下文让这个控制行为发生。放到 SOTIF 语境里就是把感知、规划、执行各层的输出当成控制行为分析在什么触发条件下这些输出会不足。比如感知层把白色货车和天空混在一起输出“前方无障碍”规划层据此维持车速执行层照做——整条链路上没有故障但危害行为发生了。用 STPA 的好处是它不依赖失效模式库能覆盖“设计时没想到的组合”。场景因素构建则是把触发条件拆成可枚举的维度光照、天气、道路几何、交通流、基础设施状态、传感器安装状态等。每个维度取值组合出场景空间再用风险排序挑出要重点分析的组合。这一步的产出直接喂给后面的验证确认策略所以场景因素的粒度和正交性很关键——维度之间强相关比如暴雨必然伴随低光照时组合数会爆炸但有效信息不多需要做剪枝。预估系统对触发条件的响应的可接受度本质上是问这个触发条件出现时系统的反应是“还能接受”还是“已经越界”。这一步往往要靠仿真和封闭场地测试先给初步结论再在后面的已知场景评估里做实车确认。3.4 功能修改把风险摁回设计里识别出 SOTIF 相关风险后第 8 章要求修改功能来解决它们。措施分几类改规范定义把漏掉的场景补进需求、改系统架构加冗余通道、加监控、改性能换传感器、加融合策略、改人机交互把局限告知用户、设计接管提示。修改之后要更新“规范定义和设计”的输入信息形成闭环。这个闭环的意义在于SOTIF 不是一次性评估而是设计、分析、修改、再分析的迭代。常见的翻车是改完设计不回头更新需求库和场景库导致下一轮分析还在用旧假设评估结论和实际系统对不上。我一般会要求每次功能修改都同步更新三样东西需求条目、触发条件清单、对应的验证用例缺一样这个闭环就是断的。4. 验证与确认已知场景和未知场景怎么分别对付4.1 验证确认策略集成和测试怎么定义第 9 章要求定义验证和确认策略包括集成和测试的定义。这里的核心思想是分层要素级测试、系统集成测试、整车级测试每层验证的目标不同。要素级看感知、规划、执行各自的输出是否满足规范集成级看输出不足叠加后整车行为是否可接受整车级看在真实交通流里的表现。测试手段标准里列了 SIL、HIL、MIL、车辆场地测试、长期道路测试、仿真测试。选型的关键是覆盖率和成本的平衡仿真能跑海量场景但保真度有限场地测试保真度高但场景数有限道路测试最真实但不可控且里程成本高。常见的实现思路是用仿真做场景筛选和回归用场地测试确认关键场景用道路测试做长尾观察三者数据互相校准。这里要注意仿真模型的置信度问题——感知仿真如果没建模传感器的真实噪声特性仿真里通过率再高也不能直接采信。4.2 已知场景评估感知、规划、执行分别验什么第 10 章针对已知场景做评估拆成感知验证、规划算法验证、执行验证、系统集成验证最后评估已知危害场景导致的残余风险。感知验证看的是在定义的场景因素组合下感知输出的准确率和漏检率是否满足性能目标规划验证看的是给定感知输入规划出的轨迹是否满足驾驶策略规范执行验证看的是车辆对规划指令的跟踪精度集成验证看的是整条链路在时序上的配合。标准在附录里给了感知系统性能目标量化和常见传感器性能局限的举例这部分很实用因为它把“感知要有多准”从口号变成了可测指标。比如某类目标在特定距离和光照下的检测率下限、误检率上限。做已知场景评估时测试用例的覆盖率是硬指标标准提到对相关场景具有高覆盖率的测试用例以及潜在触发条件的注入。触发条件注入是个容易被忽略的手段不是等场景自然出现而是主动在测试里构造触发条件看系统反应。4.3 未知场景评估残余风险怎么估第 11 章处理未知场景——那些分析阶段没识别出来的场景。逻辑上你没法枚举未知所以方法转向统计和探索用大规模自然驾驶数据、影子模式、现场监控来发现“计划外”的危害行为再用这些发现反哺场景库。标准在这一章给的是残余风险评估的框架而不是具体算法。工程上的常见做法是设定一个可接受的残余风险水平然后用行驶里程和事件计数做统计推断判断当前系统的未知场景风险是否低于该水平。这里的统计学陷阱不少低频事件的置信区间很宽里程不够时结论不可靠不同 ODD 的风险不能简单合并统计。所以未知场景评估往往要配合运行阶段的持续监控把“发布时估不准”的部分交给“运行中持续看”。4.4 SOTIF 成果评估与发布推荐第 12 章要求评估 SOTIF 成果并给出发布推荐。这一步不是重新做一遍分析而是检查前面的论证链是否完整危害识别全不全、触发条件覆盖够不够、验证确认的证据是否支撑接受准则、残余风险是否在可接受水平。标准附录里给了用 GSN 构建 SOTIF 论证的示例GSN 的价值在于把“结论”和“支撑证据”显式连起来任何一个证据缺失或失效论证图上都能看出来。发布推荐的实质是一个判断现有证据是否足以论证该功能在定义的 ODD 内 SOTIF 达标。这个判断要写清楚前提条件比如“仅在白天、干燥路面、高速公路场景下发布”因为一旦超出前提论证链就断了。5. 避坑与排查SOTIF 落地时最容易翻车的几件事5.1 把 SOTIF 当成功能安全的附录现象团队把 SOTIF 分析塞进 HARA 的表格里用失效模式去套功能不足结果识别出的全是硬件故障感知局限和算法鲁棒性问题一条没进清单。原因功能安全的分析起点是“功能失效”SOTIF 的起点是“功能正常但不够好”两者的因果模型不同硬套会系统性漏掉性能局限类风险。解决单独建 SOTIF 分析工作流危害识别从预期行为和场景因素出发STPA 和场景分析法单独跑一遍最后再和功能安全的 HARA 结果做交叉比对而不是合并。5.2 触发条件清单写完就锁死现象项目初期列了一批触发条件之后设计改了三轮清单没动验证阶段发现测试用例覆盖的场景和当前系统对不上。原因触发条件和功能不足是绑定的功能修改后旧的触发条件可能失效、新的触发条件会出现清单不更新等于分析基线漂移。解决把触发条件清单纳入配置管理每次功能修改强制触发一次清单评审验证用例和触发条件做双向追溯追溯断链就报警。5.3 双层接受准则只用了第一层现象评估时逐事件判断危害行为是否可接受全部通过就认为 SOTIF 达标没做按里程的残余风险统计。原因单次行为合格不代表总体风险合理低频高后果的行为在逐事件筛里可能被放过。解决两层都要跑第一层筛出不可接受的行为第二层用行驶里程或时间做统计确认残余风险低于接受准则两层结论不一致时以更严格的那层为准并回头检查准则定义是否合理。5.4 仿真通过率直接当验证证据现象仿真里场景通过率 99%实车测试却频繁出现接管团队对仿真结论产生怀疑。原因仿真模型的感知噪声、执行延迟、交通参与者行为模型和真实世界有差距仿真通过率高只说明在模型假设下没问题。解决先做仿真模型的置信度评估用实车数据校准关键参数仿真结论只用于场景筛选和回归关键场景必须用场地或道路测试确认建立仿真与实车的偏差监控偏差超阈值时暂停采信仿真结果。5.5 未知场景评估被当成“没法做所以不做”现象项目排期紧未知场景评估被标记为“不适用”直接跳到发布推荐。原因未知场景没法枚举团队误以为无法评估。解决未知场景评估本质是统计推断加运行监控发布前用现有里程数据给出残余风险的初步估计并写明置信度发布后靠现场监控和影子模式持续收集设定触发复评的事件阈值把“估不准”显式写进发布前提而不是假装它不存在。6. 设计取舍SOTIF 的边界在哪以及怎么验证你真的做到了SOTIF 最容易被误解的一点是把它当成一张可以“通过”的考试。实际上标准从头到尾没给达标线它给的是一套论证框架你得自己定义接受准则自己收集证据自己论证残余风险可接受。这个设计取舍很清醒——不同功能、不同 ODD、不同技术路线的可接受风险水平本来就不一样标准如果硬给一个数反而会诱导团队去凑数而不是去真正分析。这也带来一个副作用SOTIF 的论证质量高度依赖团队的自律。同样一份 GSN 论证图认真做的团队会把每个证据节点连到具体的测试报告和数据走过场的团队会把“已分析”三个字当证据。所以验证“是否真的做到了 SOTIF”不能只看文档齐不齐要看三件事触发条件清单能不能追溯到具体的场景数据和测试用例双层接受准则的两层结论是否都有量化支撑功能修改后闭环是否真的转起来了需求、场景、用例三者是否同步更新。另一个取舍在已知和未知的边界上。标准把大量篇幅给了已知场景的验证确认未知场景只给了框架这不是偷懒而是承认工程现实未知场景只能靠运行阶段持续发现发布时的评估注定是不完整的。所以 SOTIF 的发布推荐本质上是一个带前提的判断前提写得越清楚运行阶段的问题就越容易被归因和处理。反过来如果发布文档里只写“SOTIF 达标”不写前提运行阶段出了计划外事件团队连从哪查起都不知道这才是真正的黑匣子。还有一个常被忽略的取舍是标准之间的分工。SOTIF 明确不覆盖信息安全威胁、不覆盖系统技术直接导致的危害比如激光对眼睛的伤害、不覆盖故意滥用这些分别归到其他标准。做安全论证时如果把这些混进 SOTIF 范围论证会变得又大又虚如果漏掉它们不交代论证又有缺口。正确的做法是在 SOTIF 论证的边界声明里写清楚哪些风险由哪份标准承接形成整车安全论证的拼图而不是让 SOTIF 单打独斗。我自己的习惯是每次拿到一份 SOTIF 相关的设计或评估材料先不看结论先翻它的触发条件清单和接受准则定义再看功能修改的闭环记录。这三样能对上后面的证据才值得细看对不上结论再漂亮也要打问号。这套习惯是被几次“文档齐全但一追问就断链”的评审教出来的从那以后我每次做 SOTIF 评审都强制走一遍这条追溯链省下来的返工时间远比多花的评审时间多。希望帮到你。本文还有配套的精品资源点击获取