简介：面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者，这份资料提供预期功能安全（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 评审都强制走一遍这条追溯链，省下来的返工时间远比多花的评审时间多。希望帮到你。
本文还有配套的精品资源，点击获取
