滴滴技术解读：自动驾驶基础架构如何以终为始，稳定先行？

导读：

本文由滴滴技术授权发布，作者为Ferry Wang。

滴滴开始做自动驾驶可以追溯到2016年。4年来，整个行业经历过大众的狂欢与围观，也经历过资本的追捧与冷静。由于今天的技术还处于比较早期，自动驾驶作为“还没有被真正做成“的事情，外界对技术长期主义的不解与质疑也客观存在。本文将从自动驾驶基础架构面临的挑战出发，客观聊聊在技术演进过程中，这个方向上的一些矛盾权衡以及背后思考。

1

关于自动驾驶基础架构

基础架构在互联网行业中，是一个相对比较成熟的领域。然而在自动驾驶领域，却是一个新鲜的话题。基础架构的工作包括硬件、onboard（车载系统）、云端三大板块。在我们认为，自动驾驶领域中 “基础架构” 的核心价值，是为自动驾驶提供恰到好处的、全方位的技术保障。在自动驾驶系统中，如果说感知是眼睛，规划是大脑，那么基础架构就是神经系统，将自动驾驶软件系统与车辆紧密的联系在一起。

自动驾驶中的基础架构相关工作

然而在近几年的探索中，我们发现随着自动驾驶技术的演进，种种基于安全、效率、体验等方面的考虑也更加苛刻。基础架构的工作不仅仅是为软件算法提供支持，还需要在硬件、效率、功能安全等多个方面进行权衡。而基础架构工作本身，则是在三个主要技术矛盾之间进行权衡。

2

技术的主要矛盾

2.1 快速迭代与功能安全的矛盾

传统的互联网企业，其核心技术竞争力在于快速迭代。通过缩短迭代的周期，来加速功能的升级，进而在市场上获取先发制人的竞争力。而传统的汽车行业，则往往需要四至八年作为一个迭代周期，以尽可能地确保功能安全。可见，“快速迭代” 和 “功能安全” 从时间的维度上看本身就是矛盾的。

在自动驾驶领域，这个矛盾则更加突出。多数自动驾驶行业的从业者，可能都思考过这样一个问题：在操作系统的选择方面，是选择更加熟悉、资源更加丰富的 Linux 系统，还是选择实时性更有保障、更加安全可靠的 RTOS 系统？如果选择前者，意味着可以更快地进行功能迭代，让自动驾驶软件算法快速适应复杂的交通场景，但很难保证极端情况下的功能安全；如果选择后者，则意味着需要遵守更加严格的研发流程，需要做更多的系统性工作，而这本身就意味着时间。

2.2 更多、更好的传感器与算力平台的矛盾

坊间曾盛传着一句话，在无限 ODD（设计行驶区域） 的场景下，感知对于传感器的需求也是无限的。由近及远的探测范围、360° 的探测视角、多种类型传感器的互补和冗余，对于应对各种极端场景而言都是必不可少的。近几年传感器领域的发展也遵循着这个趋势，Lidar 的点云密度越来越大，Camera 的像素越来越高，自动驾驶厂商所使用的传感器数量也越来越多。行业领头羊 Waymo 在第五代车上所使用的传感器数量更是多达 40 多个。

不同Camera表现对比图

然而，传感器方面提升的同时，也往往意味着对计算平台的算力要求有着大幅提升，需要更强的算力来处理更多的数据。而更多的算力则通常意味着更大的功耗和散热需求。也许在云端计算中，我们可以假设算力、功耗和散热等问题都是不存在的。然而在乘用车的狭小空间内，这个假设显然不成立。

2.3 硬件性能与车规级安全的矛盾

基于 x86 平台的小型服务器在搭上互联网的顺风车经过多年快速发展后，其计算能力是非常好的。然而问题在于，汽车本身并不是经过精心设计的 IDC（互联网数据中心），对多个方面都有很强的约束，包括供电、散热、体积、温度范围、电磁稳定、接口稳定、通信稳定等等多个方面。甚至在传统汽车行业对这些条件都有明确的行业标准。这就意味着将传统基于 x86 架构的工控机直接搬到车内是有很多问题的。

然而，即使经过多年的发展，满足这些条件的计算平台在算力方面却往往不尽如人意。比如广泛使用的 Nvidia Xavier 平台，算力仅仅只有 30 TOPs。通过这样的算力来实现全功能的 L4 级自动驾驶，几乎是一件不可能的事情。

同样的，其他很多硬件比如交换机、传感器皆是如此。在当前这个阶段，工业级或者车规级产品的性能往往会更弱，这是硬件发展的客观规律决定的。因此我们需要考虑的不仅仅是推动相关硬件行业的发展，还需要考虑软硬件的协同演进，不能让硬件成为软件算法的天花板。

上述这三个矛盾，是当前阶段我们在设计基础架构时所面临的三个核心问题。当然，从自动驾驶的终极目标来看，功能安全、高算力平台、稳定可靠的硬件都是不可或缺的。现阶段我们探索更多的是，在资源有限的前提之下，如何用一种适当的节奏来逐步达成这个目标。

这样就引申出另一个问题，自动驾驶的长远目标是什么？

3

自动驾驶的长远目标

自动驾驶的长期目标是用更安全稳定的无人驾驶，将人类驾驶员从重复，低效或危险（比如疲劳，醉酒，或极端天气等）的驾驶行为中解放出来，提升社会的运转效率，降低交通运输风险。

运载的本质在于安全，没有安全保障的无人驾驶，是对生命的漠视。那么如何定义安全？这是自动驾驶领域内经久不衰的话题。

百年汽车行业，不仅仅是百年的技术演进，更是持续百年的对汽车安全的探索。也正是如此，逐渐演变出 iso26262 等等非常全面的行业标准，对硬件、软件、研发流程都有非常细致的要求。这本质上是一种主动证明安全的方式，凡是按照车规级和功能安全研发的产品，至少可以保证是在一定的安全水准之上的。

而非汽车行业出身的玩家中，则逐渐形成另一种对于安全的定义。除了对每一个环节做到车规级的功能安全这种思路之外， 也可以通过更好的冗余系统设计来提升整体安全性。比如当单车智能不足的时候，通过外部信息的帮助，比如 V2X、远程接管等技术手段，来更快的实现安全前提下的无人驾驶。

这种方式，本质上可以认为是对功能安全的定义的演进。被动层面上，可以通过 MPI （每两次人工干预之间行驶的平均里程数）达到一个足够大的数值，来证明整体系统的安全可靠。主动层面上，可以通过增加冗余系统和降级系统，在各种故障场景下对于安全进行保障。除此之外，在软件算法层面，也可以通过穷举交通参与者的任何可能状态和行为，通过概率空间的方法，来证明软件算法对各种异常场景的适应性。

V2X与远程协助

滴滴自动驾驶自主研发的车路协同解决方案

路端V2X设备帮助车辆接收路况信息 消除视觉盲区

虽然自动驾驶与汽车紧密相关，但毕竟自动驾驶是一个相对新兴的行业，汽车行业对功能安全的定义和标准并不一定完全适用于自动驾驶领域。我们也许可以找到一个新的对于功能安全的定义和标准，来证明自动驾驶系统的安全可靠。

也正是因为这些原因，自动驾驶领域的玩家们，逐渐演变出两种不同的流派：

• 自下而上，安全为重

• 自上而下，功能为先

这里的 “上” 与 “下”，可以有三层含义：

• 在 SAE International 所制定的 “L2 L3 L4” 自动驾驶等级中，选择相对复杂的 L4 为起点，还是选择相对简单一些的 L2 为起点。

• 在系统演进的过程中，优先选择功能的实现，还是优先选择系统的安全。

• 在核心决策流程中，是以核心软件算法为主，由软件定义车辆；还是以车辆硬件为主，由硬件来约束软件。

可以看到，这与我们所遇到的基础架构设计中的主要矛盾是相互对应的。

汽车行业出身的玩家，多采用第一种方式。严格遵循安全为重的原则，在满足车规级安全等级要求的前提下，选择更加稳定可靠的硬件、系统和中间件，然后逐步进行功能实现。从这个角度讲，汽车行业出身的玩家优先选择 L2、L3 或者 ADAS 作为自动驾驶的起点，并不完全是因为更认可 L2、L3 的商业价值，更是因为在这个前提之下，比较难实现安全可靠的 L4 级自动驾驶。

非汽车行业出身的玩家，则多采用第二种方式。采用自上而下、功能为先的研发方式，在有安全驾驶员的前提下，优先实现自动驾驶系统的核心功能，再逐步通过系统冗余设计，以及 V2X、远程接管等外部辅助手段，逐渐实现安全可靠的无人驾驶。

滴滴自动驾驶从技术复杂性几何级跃迁的 L4 级自动驾驶切入，锁定 Robotaxi 的商业运营为长远目标，并在“终点“的指引下，不断探索新的技术方案，同时兼顾软件功能与安全，不断积累能力，以一种适当的节奏，来逐步达成这个目标。

4

自动驾驶的发展节奏

在我认为，如果以 MPI 为参考系的话，整体上而言自动驾驶可以划分为四个阶段：

10 -> 100 -> 1000 -> driverless（无人驾驶）

4.1 第一阶段：MPI < 10

这个阶段，可以定义为自动驾驶的原型探索阶段。如果按照每辆车每天可以测试 200km 里程的话，意味着每辆车每天可以产生 20 多个接管问题，少数的测试车辆即可满足常见问题的稳定复现。因此，从这个角度看，在这个阶段以无人驾驶为目标是非常困难的。相对的，把安全驾驶员看作系统整体的一部分，更充分的利用人的存在来获取更多的信息、数据并保证安全底线，反而显得更有价值。在这个思路之下：

在Infra 方面，其核心价值在于提供一个强有力的可快速迭代的系统架构和硬件平台，赋能软件算法的快速迭代，完成系统原型的搭建。在这个阶段过于追求硬件、系统的稳定性和可靠性，不仅意义不大，还可能会对核心算法的探索造成阻碍。

在Simulation 方面，由于日常路测会直接产生大量接管问题，对这些真实问题的高效分析和迭代是更重要的。因此对于仿真平台而言，其核心价值并不在于构建更多的虚拟场景，而在于对软件的回归测试和功能层面的白盒测试，而其他测试则交给封闭场地的结构化测试和开放道路的黑盒测试则相对更为高效。

在Autonomy 算法方面，对于如何实现自动驾驶的技术路径应该还不足够清晰和明确，需要大量的原型验证和方法探索，并在这个过程中逐步形成相对明确的技术路线和方向，搭建一个完整软件技术体系，形成数据驱动的研发流程。相对而言，一些频次较低的问题和场景，以及一些比较极端安全问题，则可以优先级低一些，由安全员来进行保障。

4.2 第二阶段：MPI <100 

这个阶段，可以定义为自动驾驶的成长阶段。这个阶段，应该是方法论逐步成型并持续需求突破的一个过程。

在 Infra 方面，需要对多样化的系统架构和硬件平台进行探索，给核心算法提供更好的传感器和算力的支撑，帮助算法团队进行持续深入的探索和更多方法的尝试，赋能更多、硬件和安全的可能性。与此同时，由适当的力的约束，需要在系统层面逐步提供一些约束和优化，与算法团队共同提升计算效能，从而在有限的资源下提供更多的可能性。

在 Simulation 方面，需要提供更高效和低成本的测试手段，通过更好的仿真度和虚拟仿真，将部分需要依赖于实体车的场景测试和部分结构化测试转移至仿真平台，实现 Simulation In the Loop，提升研发测试的效率。从需求的角度讲，如果将仿真分为 “感知仿真” 和 “规划仿真” 的话，则对于 “规划仿真” 的仿真度的提升相对而言性价比更高。

在 Autonomy 算法论、技术路径方面，需要更多的传感器和方法论方面的探索。一方面可以尝试更好的传感器和硬件所带来的直接收益，另一方面，则需要在方法论方面有一些突破，能够更全面的来应对更复杂的道路场景。于此同时，由于计算平台算力的约束，也需要在计算效能方面有更多的尝试，在算力有限的情况下尝试更多的可能性。

4.3第三阶段：MPI < 1000

这个阶段，可以定义为自动驾驶的蜕变阶段。这个阶段会有两个特征：

• 自动驾驶的 issue 逐渐进入长尾阶段，issue 的发现和处理效率将会成为核心瓶颈

• 系统稳定性和可靠性将会逐步成为 MPI 的主要组成部分

所以，对于自动驾驶系统而言，需要向功能安全做出更多的尝试和探索，追求系统的稳定性和可靠性。

在 Infra 方面，需要全面向安全可靠的系统架构进行探索。

• 硬件方面，需要向车规级传感器、高能耗比计算平台和连接方式靠拢，探索高能耗比专用芯片的可能性；

• 中间件方面，对上要对算法模块提供更加深入的约束和顶层设计，来实现更好的系统稳定性和可靠性；对下要兼容不同架构的硬件平台和操作系统，提供对车规级硬件的适配能力；对内要实现可靠的故障探测机制和监控系统，作为承上启下的核心环节；对外要提供远程监控、远程协助甚至远程接管的能力，提供全方位的安全保障。

• 系统方面，需要进行充分的系统性冗余设计，通过倒金字塔式的收敛方法探索不同层级的 failover 能力，实现整体系统的安全可靠。

在 Simulation 方面，需要提升发现问题的效率，减少对真实路测的依赖。可以尝试一些诸如对交通参与者的行为进行穷举的方法，从所有可能性中找出 In Scope 的范围和边界，来验证自动驾驶算法对于所有可能性的应对能力。

在 Autonomy 算法方面，需要在算法本身相对成熟的前提下，通过软硬件结合的方式进行系统性的优化，提升算法的运行效率、稳定性和可靠性。

综上所述，以 MPI 为参考系来划分多个阶段的核心价值，在于通过这种方式来制定一个更加清晰的 Roadmap，明确每个阶段的核心目标。从而在总体资源有限的前提之下，步步为营地朝着自动驾驶的终极目标演进。同样，这对基础架构的演进节奏和目标设定是有很好的参考意义的。

5

基础架构该如何演进

作为自动驾驶整个系统的基础设施，基础架构相关的工作需要比软件算法模块更早一步。这也是所谓的 Infra 先行。

从当前行业所处的阶段并结合国内道路的实际情况来看，在自动驾驶这条长跑赛道上，多数玩家仍然处于相对早期的阶段。我们需要清晰的认识到，实现普遍意义上的无人驾驶还需要较长的时间。因此，我们可以假设无人驾驶的落地更可能是一种由点及面的过程，那么特定区域、有限 ODD（设计运行区域）之内的无人驾驶商业化落地，将会是这个行业未来重要的里程碑，正如 Waymo 在凤凰城做的那样。

在这个目标之下，以 MPI 为参考系，基础架构的演进需要将重点放在两个方面：

• 硬件架构升级：从通用的硬件体系逐步向高性能的、稳定可靠的专用硬件体系演进。

• 软件架构升级：从赋能算法逐步向自上而下的整体软件架构设计演进，实现更加安全的、全面的基础软件体系。

5.1 硬件架构的演进思路

自动驾驶的硬件部分，通常包括传感器和计算平台两个部分。

5.1.1 传感器部分

从行业的发展趋势来看，除了极少数玩家，如 Waymo，投入大量资源用于传感器的自研以外，已经逐步形成一个相对完整的供应商体系，在保持性能提升的同时，逐步朝着车规级的目标演进。这里对我们影响较大的主要有两种类型的传感器：

• Lidar:

  追求更高的点云密度和更远的探测距离，并逐步车规化。通信方面，由传统的 Ethernet，逐步向车载以太网演进，并在硬件上逐渐实现车规级。

• Camera：

  追求更高的分辨率和更大的动态范围，适配不同光线的场景。通信方面，由工业级的 USB、Ethernet 接口逐步向高带宽的串行数据接口（比如 GMSL based LVDS 协议）演进，以获取更大的通信带宽、更低的传输延时和更好的接插件可靠性。不过由此引入的问题是，车规级 Camera 通常由于体积的约束，多数需要 ISP 外置，这意味着我们可能要涉及更多与 ISP 相关的工作。

由此可见，在传感器方面，能施展的空间并不大。我们可能更需要关注的是，如何能够结合感知模块的需求与平台算力的约束，更加充分的利用这些传感器的特性，为自动驾驶的眼睛提供更多的信息。

5.1.2 计算平台部分

这是相关问题的核心所在，也是基础架构团队需要解决的核心矛盾。多数互联网出身的自动驾驶团队，都是从一台工控机开始的，使用基于 Intel CPU + Nvidia GPU 的解决方案作为计算平台。然而作为运行在车上的计算平台，在硬件本身方面，我们至少需要考虑：

• 供电

  车辆平台尤其是电动汽车多提供 12V 的直流供电方式。相对于传统的 220V 交流供电而言，如果可以适配这种供电方式，不仅可以增加效能，也能避免一些安全隐患。除此之外，车辆供电所能支持的最大功率也是一个很重要的问题。

• 散热

  汽车上可以使用的散热方式主要有风冷和液冷两种。风冷虽然成本比较低，结构简单，不过缺点在于散热效率较低，噪音也比较大。与此同时，多数纯电动汽车或者混动汽车，都会有原生的电池液冷回路。因此，相对而言，液冷方案更加适用于车载环境。

• 接口

  Ethernet 是阶段非常常用的一种大量数据的传输方式。然而传统 Ethernet 多采用 RJ45 的接口形式，在长期运行的过程中会对网络的稳定性产生一定影响。除此之外，也需要足够多的接口能够接入所需的传感器。除此之外，CAN/串口等等也是比较常用的接口类型。

从当前的行业现状来看，如果希望达到这些目标，可以有两种途径：

一、采购相对成熟的解决方案。

比如 Nvidia 的 Xavier 以及基于 Xavier 的 Pegasus 平台。Nvidia 依靠在 Deep Learning 领域内的深厚积累，已经在自动驾驶领域深耕多年，并有望成为一个新的 Tier 1 势力。

Xavier 或者 Pegasus 的优势主要有：

• 是一个完整的系统，并且是按照车规级的标准设计的；

• 已经适配了很多传感器，尤其是提供了 ISP 适配了很多 Camera；

• 有着相对清晰的 Roadmap，方便后续的迭代升级。

然而核心问题在于 SoC 中的 CPU 部分性能太弱。这颗基于 Arm 架构的 CPU，主频为 1.8GHz，8 个核心，难以满足核心算法的性能需求。也许这也是 Nvidia 选择收购 Arm 的原因之一，在未来可以逐步补全 CPU 方面的短板。

二、采用自己主导设计，定制化的解决方案。

以 x86 平台为原型，直接集成 Intel Xeon 的 CPU 与 Nvidia 最新架构的 GPU，以期达到最强算力。不过这个方案的缺点在于，除了需要对接口、散热、电源进行定制以外，还需要一些与传感器集成相关的工作，以及未来需要克服更多的困难来往车规级和功能安全演进。

这两种方案，本质上也是车规级方案与性能向方案的抉择。现实就是这样，工业级（航空级、车规级）产品相对而言虽然更加稳定可靠，但性能往往要比普通的消费级产品差一些。

我们再回到 MPI 这个参照系上。在前两个阶段中，如果选用诸如 Nvidia Pegasus 这样的方案，虽然在可靠性和传感器接入方面有一定的优势，但性能方面的问题将会在一定程度上制约上层软件算法的迭代和更多方法的尝试。由此来看，在这两个方案之间选择更加安全可靠但是性能相对较低的计算平台，并不是一个很好的选择。

不过我们需要看到，在当前状态下，Nvidia 在自动驾驶及相关领域的投入是远比 Intel 等其他厂商要大的，也取得了一定的成绩。如果可以做到补齐 CPU 方面的短板，或者在软件方面减少对于 CPU 的依赖，那么未来大概率还是会朝着 Nvidia Pegasus 类似的方向上演进。

5.2 软件架构的演进思路

自动驾驶的软件架构，通常包括操作系统、中间件、监控系统等等多个部分。中间件则是软件架构中最核心的部分，介于车辆硬件、计算平台与上层软件算法之间，起到承上启下的作用。在中间件部分，我们可能耳熟能详的有：

• ROS

• Apollo Cyber RT

• Iceoryx

这三者之间的区别就不在这里详细阐述了。不过从某种程度上来看，这三者也分别代表了三种不同的设计理念：

• ROS：设计成为一个相对通用的分布式机器人控制平台。

• Apollo Cyber RT：设计为一个高性能的、全功能的自动驾驶专用平台。

• Iceoryx：设计为一个高性能的、跨平框架功能安全的自动驾驶通信框  。

这三种设计理念，也是与上文所述的三个阶段隐隐有所呼应的。

多数自动驾驶领域的玩家，都是从 ROS/Ubuntu 开始，主要原因在于其成熟、完整，技术人员可以更多的 focus 在自动驾驶的核心算法上。然后随着项目的进展，逐渐沿着 Apollo Cyber RT 类似的理念进行演进，针对自动驾驶的具体场景进行技术优化，逐步形成更加完整、高效的软件架构。最终朝着功能安全的方向发展，逐步实现量产化。

这里面的核心问题，在于 “灵活” 与 “可控” 的权衡。正如要盖一栋大楼，可以选择建造只有主体框架结构的商业建筑，由用户自行设计内部空间；也可以选择建造具备户型设计的住宅建筑，用户只能在相应功能区域之内做设计。目的不同，设计理念自然不同。

因此，中间件的设计，不能一味的追求功能，而应该结合当前软件与硬件的发展阶段，考虑所需解决的核心问题与阶段性项目目标，来进行整体的设计和规划。一个好的中间件设计，需要考虑整体软件架构中的“灵活”与“可控”，需要考虑不同硬件架构和操作系统的适配，需要权衡功能安全与软件效率，需要能够赋能整个项目的研发与迭代。

6

结语

自动驾驶是一个非常复杂的系统，包含感知、预测、规划、控制、地图、仿真、车辆、基础架构等等多个技术方向。这些方向之间并不仅仅只是“木桶理论”中的长短的关系，而更是一种相互依存、相互制约、协同发展的关系。正如两人三足游戏中，个体的激进只会造成摔跤，整体的步伐一致、节奏相符才可以走的更快。因此，如何理解自动驾驶的发展节奏，如何在各个方向上实现步伐一致并与整体节奏相符，是每个方向都需要考虑的问题，更是基础架构方向演进的基础。

自动驾驶是一个颠覆性的创新技术，不可否认仍然有很多未解的技术难题需要去攻克。但是值得庆幸地是，整个行业都在坚定地全力推进，相信技术驱动改变世界的那一天并不遥远。

END