智能汽车的未来之战:破解端到端自动驾驶的功能安全困局

自动驾驶的玩法变了，但问题也变了

2019年之前，自动驾驶行业的开发范式很清晰：感知→预测→规划→控制，每个模块独立开发、独立测试。出了问题，定位到某个模块，打补丁、调规则。

这套方法论来自一个关键前提——模块之间有"硬编码接口"，每个模块的输入输出是可枚举的、确定的。

也正因如此，ISO 26262功能安全标准才能生效：每个模块的失效模式可以被穷举，可以做FMEA，安全边界用规则画出来。

然后Transformer来了，Foundation Model来了，整个前提被动摇了。

01｜当自动驾驶开始用"常识"开车，功能安全第一次失去了锚点

AI正在渗透进感知、规划等子模块，模块性能提升了，但安全性和可解释性的问题随之浮出水面——而当架构走向完全端到端时，这个矛盾只会更激烈，因为模块化的验证层和可解释层都不存在了。

端到端架构背后的技术推力，是Foundation Model（基础模型）在自动驾驶领域的迁移。基础模型在语言和视觉领域展现出了"惊人的性能"（tremendous performance），同时也为场景工程（Scenario Engineering）带来了新机遇——但也带来了新的挑战：

问题一：开放世界——长尾分布永远填不完

真实世界的驾驶场景，从高频常规场景到极端Corner Case，再到完全前所未有的场景，构成了一个开放的长尾分布。

日常通勤场景可以被数据覆盖，但那些"日常生活中人类能处理、但自动驾驶会卡住"的情况——施工路段的水泥隔离墩、急救车需要让道但系统无法识别、复杂路况中突然出现的行人——这些构成了一个永远无法被穷举覆盖的分布。

这些问题，靠"扩大数据集"解决不了——因为它们本质上不是"数量不够"，而是"种类不可枚举"。

问题二：端到端更脆弱——对分布偏移更敏感

模块化架构里，每个模块独立处理输入，如果某个感知场景超出模型范围，只有感知模块出错，出错范围是局部的。

端到端架构里，感知和规划是一个联合模型——输入偏移会导致整个决策链一起偏移，而且是非线性的偏移：模型不会说"我不确定"，而是会给出一个基于训练分布的"自信输出"，这个输出可能在常规场景下完全正确，在偏移场景下完全错误，却没有内部机制能检测到这个错误。

问题三：ISO 26262 / SOTIF 标准框架失锚

这是最根本的问题。

功能安全标准ISO 26262建立在"穷举失效模式"的方法论上。规则系统的失效路径是可枚举的，可以逐条做FMEA，逐条设计安全机制。

端到端模型是连续函数，失效不是"这条规则错了"，而是："这个高维输入落在了训练分布之外的区域，输出产生了系统性偏移"。

问题四：模块化边界的"循环依赖"问题

随着端到端系统引入注意力机制和双向信息流，模块之间的依赖关系变得循环了。

当感知依赖规划、规划依赖预测、预测又依赖感知时，独立模块的安全验证就失效了——因为一个模块的输出已经不再独立于另一个模块的状态。

这也意味着：即使保留两段式架构的形式，端到端的数据驱动特性也会瓦解模块化安全验证的基础。

02｜SO-M-E2E：德国学者提出的"保守解法"

面对上述困局，FAU和乌尔姆大学的研究者提出了SO-M-E2E架构（Service-Oriented Modular End-to-End）。

核心设计：

• SO（面向服务）：保留模块化架构的可测试性，通过硬编码接口独立保障每个服务

• M（模块化）：感知、预测、规划等功能独立但协同，不是彻底的黑箱

• E2E（端到端）：各模块之间用注意力机制动态编排，信息流向由数据驱动而非硬编码规则

关键创新：Attention-based Orchestrator（注意力编排器）

用注意力机制动态决定信息流向哪些模块。遇到未知场景时，系统可以自适应组合已知能力，而不是直接崩溃。

但SO-M-E2E的局限也很明显：

论文本身也承认了这一点——模块化架构天然地给"性能上限"设置了天花板：每个模块的输出经过下一个模块的处理，是逐步精化的过程（refinement），模块边界既是安全的护栏，也是性能的瓶颈。

简单说：SO-M-E2E提升了安全下限，但锁死了性能上限。

03｜行业还是选择了端到端——因为性能差距太明显了

尽管功能安全挑战重重，行业主流还是坚定地走向了端到端/VLA路线。

原因很直接：性能差距是量级上的，不是细节上的。

Tesla FSD v12用端到端模型替代了超过30万行C++规则代码，在常规场景下的通行效率和舒适度远超模块化方案。

行业已经用脚投票：端到端是性能最优解，这一点没有争议。

真正的分歧在于：如何在端到端的高性能下，保证功能安全？

04｜答案：Guardian Angel——给AI装一个"安全兜底"

功能安全研究者想出了一个很优雅的思路：不要消灭端到端，而是给端到端加一个永远在线的安全守护层。

这就是Guardian Angel（守护天使）架构，也被称为Parallel Planning / Fail-Safe Hybrid Architecture。

核心逻辑：

• 通道一（Primary / E2E）：端到端模型主力输出，追求通行效率和舒适度

• 通道二（Guardian / Safety）：规则/模块化通道实时运行，输出安全约束边界

• 仲裁器（Arbiter）：安全层永远有否决权

这解决了一个根本矛盾：

端到端负责"把车开好"，安全规则负责"保证不开出安全边界"——两者各司其职，安全层不需要理解端到端在做什么，只需要判断"这个输出有没有超出安全边界"。

于是功能安全验证重新变成可能：

• 安全层是规则系统，可以形式化验证，符合ISO 26262框架

• 端到端负责性能上限，不需要直接对功能安全负责

• 两者解耦，各自迭代，互不阻塞

05｜元戎启行的 Guardian Angel 实践

元戎启行采用了双保险，一个是Safety E2E，外加一个基于规则的通道。

Safety E2E Model输出的不是分类决策，而是完整的3D轨迹——包含未来每一时刻的位置、速度、加速度。

工程难点：

1. 仲裁器延迟：两个通道输出时间戳必须精确对齐

2. 安全层误触发：频繁否决导致系统性能退化

3. 极端场景定义：什么算"端到端无法处理"，需要大量实车数据标定

写在最后

端到端给了自动驾驶性能，Guardian Angel给了它功能安全的可能性。

这两件事，并不矛盾。

行业真正在摸索的，是如何在保证功能安全的前提下，把端到端的性能上限全部释放出来——

Guardian Angel 的工程落地，是大规模商业化的最后一把钥匙。

参考文献：Ullrich, L. et al. "Toward Fully Autonomous Driving: AI, Challenges, Opportunities, and Needs," IEEE Access, 2026 (arXiv:2601.22927)；元戎启行AEB量产方案工程实践