滴滴自动驾驶 | 基础架构如何以终为始，稳定先行？

1. 

关于自动驾驶基础架构

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

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

2. 

技术的主要矛盾

不同Camera表现对比图

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

▍3. 硬件性能与车规级安全的矛盾

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

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

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

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

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

3. 

自动驾驶的长远目标

V2X与远程协助

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

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

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

• 自下而上，安全为重

• 自上而下，功能为先

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

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

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

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

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

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

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

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

4. 

自动驾驶的发展节奏

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

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

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

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

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

▍1. 硬件架构的演进思路

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

1.1 传感器部分

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

• Lidar:

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

• Camera：

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

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

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 类似的方向上演进。

▍2. 软件架构的演进思路

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

• ROS

• Apollo Cyber RT

• Iceoryx

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

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

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

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

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

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

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

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

6. 

结语

扫码了解更多

?

联系我们 | DiDiTech@didiglobal.com

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34798 人正在系统学习中