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

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

1. 

关于自动驾驶基础架构

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

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

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

2. 

技术的主要矛盾

▍1. 快速迭代与功能安全的矛盾

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

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

▍2. 更多、更好的传感器与算力平台的矛盾

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

不同Camera表现对比图

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

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

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

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

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

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

这样就引申出另一个问题，自动驾