OE Agent“天工”新版本发布,请前往论坛顶部查看,欢迎试用并反馈~
查看OE-Skills
专栏感知规控自动驾驶功能安全:从 ISO 26262 到 SOTIF 的工程逻辑

自动驾驶功能安全:从 ISO 26262 到 SOTIF 的工程逻辑

巴山夜雨2026-07-04
6
0

讨论自动驾驶安全时,一个容易被忽略的问题是:车辆并不一定要发生硬件故障,才会进入危险状态。摄像头正常、域控正常、制动系统正常,系统仍可能因为感知边界、场景覆盖不足、目标行为预测错误,做出不合适的驾驶决策。

这就是自动驾驶功能安全比传统 ECU 功能安全更复杂的地方。传统功能安全主要处理“系统发生故障后如何避免不可接受风险”;自动驾驶还必须处理“系统按设计运行,但设计能力本身不足”的风险。

一、功能安全到底保护什么?

按照 ISO 26262 的思路,功能安全关注的是道路车辆电气/电子系统发生故障时,如何避免由故障导致的不可接受风险。对自动驾驶系统来说,这一层仍然非常重要,例如制动请求丢失、转向执行异常、传感器供电中断、计算平台死机、通信总线超时等。

但自动驾驶的关键风险并不只来自故障。系统可能没有坏,却没有正确理解场景。例如前方静止异形车辆、施工区域临时锥桶、强逆光下的行人、矿区道路上的扬尘和非结构化边界。这类问题更接近 ISO 21448 所讨论的 SOTIF,也就是预期功能安全。                                                                                                                        

安全问题

典型来源

主要方法

自动驾驶中的例子

功能安全

系统故障

ASIL、诊断、降级、冗余

制动请求丢失、传感器断线

SOTIF

功能不足或误用

场景分析、触发条件、验证闭环

识别正确率不足、长尾场景误判

安全论证

证据不足

Safety Case、场景证据、测试证据

无法证明 ODD 内风险已受控

二、自动驾驶为什么不能只靠 ISO 26262?

ISO 26262 适合处理 E/E 系统失效。例如某个传感器失效、控制器输出异常、执行器不响应,系统可以通过诊断覆盖率、故障注入、冗余架构和安全机制来降低风险。 

自动驾驶的问题是,感知、预测、规划很多时候没有明确的“坏了”。模型给出一个错误结果,可能不是硬件故障,也不是软件崩溃,而是训练数据、场景边界、目标定义或环境条件共同造成的功能不足。这时需要把安全分析从“故障树”扩展到“场景树”。

       两条安全分析链路                硬件/软件故障                  安全机制                  故障后仍可控            复杂真实场景                  功能局限                  系统按设计运行仍有风险      ISO 26262 更擅长处理这一链路      ISO 21448 / SOTIF 更关注这一链路

图2:功能安全和预期功能安全不是替代关系,而是自动驾驶安全工程中的两条互补链路

三、安全架构应该怎么落到车上?

工程上,自动驾驶功能安全不能只停留在文档里。它必须进入系统架构:感知层要输出置信度和失效状态;规划层要识别 ODD 边界;控制层要有安全限幅;执行层要有可验证的降级路径;整车层要有独立的安全监督器。

一个更接近量产的结构,是把 AI/规则规划、模型控制、安全监督和执行器仲裁分开。AI 可以提高驾驶能力,但安全监督器必须能够独立判断是否越界,并在必要时触发减速、靠边、最小风险状态或人工接管。

       自动驾驶安全监督架构          感知 / 预测      规划 / 决策      运动控制                  Safety Supervisor      ODD 边界、风险评分、限速限距、降级策略、接管请求                        制动 / 转向      动力 / VCU                图3:安全监督器不替代自动驾驶算法,而是给算法输出加上可验证的安全边界 

四、真正难的是安全证据,而不是写一份安全文档

自动驾驶功能安全最后要回答的问题是:为什么可以相信这个系统在定义好的 ODD 内风险可控?这个回答不能只靠“测试了很多公里”,也不能只靠“模型指标不错”。它需要一套可以追溯的证据链。

证据链至少包括:危害分析、场景库、触发条件、仿真结果、道路测试、故障注入、模型边界、降级策略、软件版本、标定版本、问题闭环。UL 4600 这类安全论证标准强调的也是类似思路:安全不是单个测试项,而是一套围绕论证和证据构建的工程体系。   

  1. 先定义 ODD:道路类型、速度范围、天气、光照、交通参与者、施工和临时障碍。  

  2. 再识别危险:哪些场景会导致误识别、误预测、过晚制动或不合理避让。

  3. 然后设计安全机制:限速、限距、冗余、最小风险状态、人工接管、降级退出。 

  4. 最后积累证据:仿真、台架、封闭场、开放道路、故障注入、回归测试。 

五、给整车和执行层的启发

 从执行层看,自动驾驶功能安全会改变 VCU、制动控制器、转向控制器的接口定义。未来上层不应该只下发一个目标加速度或目标扭矩,还应该提供置信度、不确定性、风险等级、降级状态和接管状态。

对纯电矿卡、Robotaxi 或高速 NOA 系统来说,执行层还要判断这个请求是否符合车辆边界:附着条件是否足够,制动响应是否来得及,气压或液压是否满足,电机制动力是否受电池和车速限制,转向角速度是否超过舒适和稳定边界。

所以,VCU 不会只是“听上层话”的执行 ECU。更合理的角色是 Vehicle Motion Coordinator:接收上层意图,结合车辆能力和安全约束,做最后的运动仲裁。

前瞻判断 

顺着 ISO 26262、SOTIF、UL 4600 和监管框架的方向看,自动驾驶安全会从“功能有没有实现”转向“证据是否足够”。系统能力越强,越需要把边界、证据和降级讲清楚。

这也意味着,未来自动驾驶量产竞争的一部分,不会发生在感知模型排行榜里,而会发生在安全架构、场景验证、运行时监督和执行层仲裁中。真正能上车的自动驾驶,不只是会开车,还要能证明自己在边界内可控。

参考资料

ISO:ISO 26262 Road vehicles functional safety 

ISO:ISO 21448:2022 Safety of the intended functionality

ANSI / UL:UL 4600 Ed. 3-2023 Evaluation of Autonomous Products

NHTSA:AV STEP automated driving systems framework 

NHTSA:Automated Driving Systems safety guidance

文章转载自公众号:智驾芯视野

感知规控
技术深度解析
评论0
0/600