SOTIF在GB 44721里到底怎么做？ · 22条措施串成一条闭环

文档库

📱 微信图文剪藏

原文链接：https://mp.weixin.qq.com/s/wYlX__9yMDm57K-Jt_DJ7Q

自动驾驶安全手记2026年8月31日

SOTIF在GB 44721里到底怎么做？ · 22条措施串成一条闭环

不是多做一点场景测试，而是把功能不足、触发条件、运行控制、现场监测和产品改进连成一条持续收敛风险的工程闭环。

SOTIF

从D.2.4.3.1到D.2.4.3.22，看清GB 44721的SOTIF工程闭环

GB 44721SOTIF

EDITOR’S NOTE

先别急着数场景很多人第一次看GB 44721里的“预期功能安全”，很容易把它理解成：多做一些场景测试。比如雨天、逆光、施工区、行人横穿、异形障碍物、cut-in……这些当然重要。但如果仔细读GB 44721报批稿附录D，会发现标准对SOTIF的理解远不止“场景测试”。

在D.2.4.3“预期功能安全措施”下面，标准连续给出了D.2.4.3.1～D.2.4.3.22共22个条款单元。它们并不是22个互不相关的要求。

把这些要求重新排列以后，会发现GB 44721实际上画出了一条相当完整的SOTIF风险闭环：功能不足→触发条件→风险探测→ODC控制→安全响应→误用防护→碰撞避免→运行监测→现场风险→产品改进→再监测。

这可能才是D.2.4.3最值得研究的地方。 它不是一份静态的SOTIF报告，而是一套持续发现、控制和验证风险的机制。

SOTIF CLOSED LOOP

功能不足触发条件风险探测ODC控制安全响应现场监测产品改进再监测

PART

GB 44721先回答了一个最基本的问题：SOTIF到底在管什么？

从功能不足出发，而不是从测试场景出发

D.2.4.3.1其实是一条总纲。

车辆制造商需要提交预期功能安全措施说明，并把三件事情讲清楚：ADS存在哪些功能不足；这些功能不足在什么触发条件下会暴露；它们可能造成什么整车危害，以及准备采取什么安全措施。

BASIC LOGIC

功能不足触发条件整车危害安全措施

这几句话看起来很普通，但已经把整个SOTIF Safety Concept的主干搭出来了。

这也是理解后面21项要求的钥匙。

所以做GB 44721的SOTIF，第一步并不是：“我要准备多少个测试场景？”

而应该先问：“我的ADS有什么地方可能在没有故障的情况下仍然表现得不够好？”

例如感知能力边界、目标分类局限、预测错误、规划策略局限、ODC判断不足、人机交互不合理……然后再继续追问：什么情况下这些不足会真正变危险？这时才进入所谓的“触发条件”。

PART

第一段闭环：先把危险“看见”

风险探测与ODC在线控制

D.2.4.3.2和D.2.4.3.3实际上解决的是整个SOTIF最核心的问题之一：系统怎么知道风险正在出现？

D.2.4.3.2要求，在自动驾驶功能运行过程中，对可能影响安全运行、进而引发危害的预期功能安全问题进行探测。

发现问题以后不能什么都不做。还需要告知用户，并及时执行后援响应。

RUN-TIME LOOP

功能不足出现风险被探测用户得到提示ADS采取后援响应

但GB 44721接着把问题推进了一步。很多SOTIF风险，其实都和ODC有关。

所以D.2.4.3.3专门要求建立与ODC相关的安全概念。

这里面的逻辑很值得展开。ADS不仅需要知道“当前是不是ODC？”，还要知道“哪些触发条件可能出现？”“这些触发条件和ODD之间是什么关系？”“什么时候禁止功能开启？”“什么时候应该提前请求后援用户响应？”

甚至还要求考虑突然不符合ODC怎么办，以及怎样避免ADS频繁激活、退出。这就不是一张ODD定义表能解决的问题了。

ODD告诉系统“理论上哪里可以开”，ODC监测告诉系统“此时此刻到底还能不能继续开”。 SOTIF进一步追问：如果环境正在逼近能力边界，怎么办？

这也是为什么ODC会成为GB 44721整个安全体系中如此重要的概念。

PART

第二段闭环：发现风险以后，怎么安全退出？

RTI、转换可控性、MRM与MRC

知道有危险还不够。最困难的问题其实是：怎么从危险状态退出来。

D.2.4.3.4～D.2.4.3.6基本都在解决这个问题。

标准要求终止自动驾驶功能时，要判断运行中的预期功能安全风险、不满足安全相关ODC条件的情况，以及用户关闭、接管是否合理。

随后还要处理ADS与其他驾驶自动化系统之间的转换。这里会涉及：谁的控制优先级更高？另外一个驾驶自动化系统什么时候应该被抑制？系统切换过程中会不会产生新的风险？

再往后就是非常关键的：可控性。特别是L3。

系统不能简单地说：“前面有问题，请接管。”然后立刻撒手不管。

GB 44721甚至在这里给出了一个非常工程化的要求：对于3级自动驾驶功能主动发起介入请求的情况，从首次报警开始，如果后援用户没有接管，介入请求持续时间一般不少于10 s；计时结束仍未接管，或者风险升级，则系统立即执行MRM。

SAFE EXIT

发现风险判断能否继续运行发起退出或接管保证转换过程可控接管失败MRMMRC

SOTIF因此第一次和RTI、MRM、MRC真正连起来了。

这也是一个非常重要的认识：SOTIF并不只发生在“感知算法”里。

一项感知局限最终可能落到：感知→决策→HMI→接管→制动或转向→MRM。它实际上是整车级安全问题。

PART

第三段闭环：风险不只来自算法，还来自“人”和“车”

乘员、误用、外部人员与车辆状态

接下来D.2.4.3.7～D.2.4.3.12很有意思。因为标准突然不再只谈算法。它开始谈：乘客、用户、外部人员、车辆工作状态。

对于不允许行驶中退出至人工驾驶的自动驾驶功能，如果乘客未系安全带、没有正确就座等，需要识别风险，并采取告警、MRM等措施。

如果车内用户可能错误操作驾驶操纵件，也要考虑防止或者减轻这种误用。

标准甚至给出了非常具体的思路：通过机械或电子方式隐藏、隔离操纵件；或者通过提高作用力、施加反向力等方式抵抗不安全操作。

再往外扩展，还有：未经授权人员试图进入车辆；车辆运行期间被放置异物或者遭到人为破坏。

再往车辆本身扩展：轮胎状态不佳；异常外部负载；不可探测的车辆改装；轮胎磨损；外部拖挂。

这些内容放在一起以后，就能看到GB 44721对“触发条件”的理解其实非常宽。

触发SOTIF风险的，并不一定只是逆光、雨雪、遮挡。它还可能来自用户行为、乘客状态、车辆状态、外部人员甚至车辆使用方式。

仅仅建立一个“天气×道路×交通参与者”的场景库，很可能是不够的。 触发条件的来源远比典型环境场景更广。

PART

第四段闭环：从“避免碰撞”一直管到“碰撞后的损害”

预防、检测、严重度判断与缓解

D.2.4.3.13～D.2.4.3.16形成了另外一条非常漂亮的逻辑链。

首先是：尽量不要撞。ADS需要监测道路和路面情况，例如施工、障碍物、低附着路面；监测ORU并预测行为；合理处理未知目标；合理应对ORU的非预期行为；处理不可见区域；保持安全速度和距离；必要时采取应急响应。

但标准并没有停在“AEB成功就完了”。下一步是：我到底撞没撞？

D.2.4.3.14要求有策略判断车辆是否与安全相关目标发生碰撞。

然后继续：这次碰撞严重吗？D.2.4.3.15又要求判断碰撞是否可能造成重大损害，可以结合目标对象、碰撞位置、相对速度、自车速度，以及历史事故或风险事件数据。

最后，如果碰撞已经不可避免：尽可能减轻后果。D.2.4.3.16要求通过调整车速降低相对碰撞速度，并使车辆达到静止状态。

DEFENCE IN DEPTH

危险目标识别风险预测碰撞避免碰撞检测严重度判断碰撞缓解安全停车

这是一个非常典型的“纵深防御”思路。系统不是只有一道防线。前一道失败以后，下一道继续降低风险。

PART

真正让我觉得这22条很有意思的，是最后6条

从开发阶段延伸到车辆运行阶段

如果标准写到D.2.4.3.16就结束，其实仍然很像传统的Safety Concept。

但D.2.4.3.17～D.2.4.3.22把整个事情彻底改变了。因为GB 44721开始讨论：车卖出去以后怎么办？

SOTIF不能随着SOP结束

D.2.4.3.17要求车辆制造商说明ADS运行阶段的安全保障措施。也就是说：SOTIF不能随着SOP结束。

量产以后仍然要持续监测功能不足产生的风险，并确保运行阶段继续符合残余风险接受准则。

接下来D.2.4.3.18甚至直接规定了应该监测哪些异常。

系统没有输入

监测输入缺失以及由此带来的预期功能安全风险。

错误输入

识别输入质量或输入内容异常。

感知系统老化

关注传感器或感知能力随时间变化带来的风险。

突然离开ODD

监测运行条件快速变化导致的能力边界越界。

人员错误操作或未正确接管

把人的行为异常纳入现场风险监测。

系统没有输出或错误输出

直接关注ADS输出层面的功能不足。

功能不足导致MRM

把MRM本身作为现场风险信号之一。

潜在风险事件

即便没有碰撞，也要监测高风险事件。

ADS直接或间接参与的碰撞

碰撞事件是最重要的现场证据之一。

这些全部可以成为Field Monitoring的触发信号。

PART

从这里开始，SOTIF真正变成了一个“活系统”

风险评估、现场管理与产品改进

监测到事件以后怎么办？D.2.4.3.19要求建立风险评估机制。

也就是说，每次出现安全相关事件以后，需要回答：还能继续运行吗？还是这个风险已经需要处理了？

随后D.2.4.3.20进一步要求建立现场风险管理流程：事件或事故上报→问题调查→风险评估→对策管理→实施措施→效果反馈。

注意这里已经几乎不是一个“开发流程”了。它实际上是一个产品运行风险管理体系。

然后是D.2.4.3.21。如果风险已经不可接受，可以：限制功能使用范围；功能降级；功能停用；修改系统设计；更新ODD；OTA升级；告知用户新的使用风险；修改操作限制和操作指导。

这意味着一个非常重要的事情：ODD并不是产品开发完成那一天就永久冻结的。

如果真实世界数据证明某个运行区域风险不可接受，完全可能出现：扩大限制条件，而不是扩大ODD。

发现未知风险以后，第一动作未必是“把算法做得更强”。 有时候最合理的安全措施反而是：先让系统少开一点。

PART

最后一条，才真正把闭环关上

措施有效性确认与持续迭代

D.2.4.3.22只有一句核心思想：安全措施实施后，要继续监测和评估它是否有效；如果风险仍然不合理，就继续调整。

这句话看起来很简单。但它实际上让前面的21条全部重新循环起来。

FULL LIFE-CYCLE LOOP

识别功能不足识别触发条件分析整车危害设计安全措施ODC和运行风险监测后援响应或MRM或碰撞缓解车辆投入实际运行监测异常事件现场风险评估限制功能或OTA或ODD更新或设计改进评估措施是否有效仍有风险则重新进入下一轮

所以我认为，理解GB 44721的SOTIF，最重要的一张图其实应该是：Triggering Condition→Functional Insufficiency→Hazard或Risk→Safety Measure→Verification→Field Monitoring→Risk Assessment→Improvement→再验证、再监测。

这才是“闭环”。

PART

22条要求，其实可以压缩成6个工程问题

把条款翻译成项目必须回答的问题

D.2.4.3.1～3

我们的功能不足是什么？在什么条件下会暴露？系统怎么发现？

D.2.4.3.4～6

发现风险以后，怎样安全退出、转换和保持可控？

D.2.4.3.7～12

用户、乘客、外部人员和车辆状态带来的风险怎么控制？

D.2.4.3.13～16

怎样避免碰撞？避免不了怎么办？撞了以后怎样减轻损害？

D.2.4.3.17～21

车辆交付以后，怎样持续发现未知功能不足并处理现场风险？

D.2.4.3.22

措施真的有效吗？如果无效，怎样继续迭代？

如果项目能够真正回答完这6个问题，那么22条要求基本就被串起来了。

PART

所以，SOTIF绝对不等于“做一个场景库”

场景只是验证证据的一种载体

这是我读D.2.4.3最大的感受。

很多项目里的SOTIF很容易变成：场景识别→场景库→仿真→测试报告。

但GB 44721展示出来的逻辑明显更大。场景只是其中一个环节。

真正完整的工程链应该至少能够追溯：功能不足→触发条件→危害→安全措施→系统需求→场景→验证结果→现场监测指标→风险事件→改进措施。

场景不是SOTIF的起点，也不是终点。 场景只是把“功能不足和触发条件”转化成可验证证据的一种载体。

PART

对实际项目来说，我反而建议做一张表

建立端到端追溯矩阵

如果让我把D.2.4.3真正落到项目里，我不会先写一份几十页的《SOTIF报告》。

我会先建立一张：SOTIF触发条件—安全措施—验证—运行监测矩阵。

TRACEABILITY MATRIX

功能不足触发条件对应ODC或场景潜在危害风险接受准则安全措施系统需求验证方法验证场景运行监测指标现场事件风险评估改进措施措施有效性确认

这张表一旦建立起来，SOTIF就不再是一堆散落在不同部门里的文件。

感知团队知道自己为什么要解决某个corner case；系统团队知道为什么需要一个安全策略；测试团队知道场景从哪里来；售后和数据团队知道量产以后应该监测什么；Safety Case团队最后也知道证据到底在证明什么。

///

END

结语

不是一份报告，而是一套持续收敛风险的机制

所以，如果有人问：“GB 44721到底要求怎么做SOTIF？”我的答案不会是：“按照22条要求逐条写符合性说明。”而是：把这22条看成一个从设计阶段一直运行到真实世界的风险控制循环。

它从一个很简单的问题开始：“ADS哪里可能做得不够好？”然后一路追问：什么时候会暴露？系统能不能发现？发现以后怎么办？能不能避免碰撞？用户会不会误用？量产以后怎么知道还有没有未知问题？出了问题以后要不要限制功能、修改ODD甚至OTA？做完这些以后——风险真的下降了吗？如果答案仍然是否定的，那么D.2.4.3.22已经告诉你：继续迭代。

不是一份SOTIF报告，而是一套能够持续发现风险、控制风险并证明风险正在收敛的工程闭环。

CLOSING

GB 44721这22条SOTIF要求真正想建立的，不是一份静态文档，而是一个可以从设计走到运行、再从运行反馈回设计的闭环。

SOURCE NOTE

依据报批稿整理本文依据2026年6月GB 44721《智能网联汽车自动驾驶系统安全要求》报批稿及其编制说明整理。D.2.4.3包含1条总纲及D.2.4.3.2～D.2.4.3.22的具体要求。正式实施和合规判断应以最终发布文本为准。

#GB44721#SOTIF#自动驾驶

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见

赞在看收藏THANKS FOR READING

从 SOR 到软硬件规范，一条链路不再返工——汽车控制器需求助手实战