本文整理自 2022 年 12 月的智算峰会 · 自动驾驶分论坛上的同名主题分享。

百度的云仿真平台目前已经覆盖自动驾驶的整个研发环节，为包括感知、决策、规划、控制在内的诸多环节提供集成测试验证服务。

目前已覆盖 98% 的道路场景，实现日行百万公里的仿真里程，运营版本发布周期缩短至一周，模型成功上车率达到 99.8%。

在今天的演讲中，我会着重介绍一下百度的云仿真系统，分享百度在整个智能驾驶测试过程中的一些实践经验。

1. 百度全系自动驾驶工具链解决方案总览

首先，我从整体上向大家介绍一下百度全系自动驾驶工具链解决方案包含哪些内容。

百度从 2013 年开始就进入到了自动驾驶领域。经过 9 年的不断积累，逐步形成了“数据、研发、测试、运营、监管”五大中台。并且我们结合百度智能云团队在算法、算力上的支持、百度 3000 多万公里的真实路测数据、以及我们基于这些路测数据进行的场景侧挖掘，为整个工具链提供了宝贵的算力、算法以及数据支撑。

在这样一个强大的工具底座之上，我们打造了两大核心引擎：汽车制造引擎和 AI 创新引擎。前者帮助我们造聪明的车，后者帮助我们造优秀的车。

目前整套自动驾驶工具链除了服务百度内部的研发迭代，为我们打造出了 ANP、AVP 以及 5G 云代驾这种标杆类产品之外，还帮助我们的生态合作伙伴进行了智能出租、智能矿卡、智能货运、智能园区物流、智能公交等多场景下的产品技术赋能。

整个自动驾驶行业希望达成的目标，就是高阶自动驾驶能够变得触手可及、安全好用。这样一个目标的实现，离不开一套先进的工程化实践平台。百度的自动驾驶工具链实际上就是这样一套为研发、测试打通研发链路的工具平台。

作为工具平台，在底层我们依赖百度百舸平台，在 AI 计算、AI 存储、AI 加速、AI 容器上提供强大的支持。这部分在我们前面的分享中的也进行了比较详细的介绍（相关内容可参考：百度百舸 · AI 异构计算平台，加速自动驾驶模型迭代）。

在百度百舸之上，我们构建了一套完整的数据管理平台，为自动驾驶业务提供了覆盖数据采集、数据标注、数据处理、数据应用、数据管理的系统支持。

我们目前能够承载 EB 级数据的高效管理应用，并且和标注平台进行了打通，提供了数据送标、标注回灌，数据集同步以及问题事件挖掘等相关能力，实现了从原始数据采集到标注生成高质量数据集，再到将数据集提供给研发进行训练的完整数据闭环（相关内容可参考：打造合规数据闭环，加速自动驾驶技术研发）。

在完成单模块训练迭代之后，我们需要对整个感知、规划、控制的相关算法进行集成测试，在海量的场景中进行完整的模型验证，这就涉及到仿真测试环节。

2. 道路测试 vs 仿真测试

    2.1 从路测到仿真

其实在将道路测试还是仿真测试作为算法主要验证方式的问题上，百度也走过一些弯路。在 2018 年之前，百度的测试是以路测为主，仿真为辅的。当然这里面也有很多现实因素，包括早期国内自动驾驶的仿真经验不足、场景数据极为匮乏等。那个时候，每当我们训练出一版新模型后，都会先部署在测试车上，然后让司机开着测试车到测试区域进行路测，以验证我们的模型效果。从效果上来说，对算法能力的评价主要也依赖司机的主观体验，相关的量化指标主要是看每公里司机接管次数。

不难看出，针对路测时发现的问题，我们都采用 case by case 的解决方式，出现一个问题就解决一个问题。但这样会导致十分严重的后果，因为我们并不知道解决了某个问题之后，是否覆盖了所有的同类问题，是否在回归后产生其他的问题。

举个例子，我们早些年在路测时发现，在北京园区有个无保护左转的场景始终通过不了。回到实验室之后，我们对算法进行了更新迭代，在北京园区的测试场景下，确实可以正常通过。但是同样的模型，在广州园区，类似的无保护左转的场景却又再次出现。后来究其原因，仅仅是北京和广州这两个路口的路宽有差距。

此外，路测的方式除了劳神费力外，更新迭代也比较慢，一般一个月左右才能测出一个运营版本，而且版本的上车成功率也非常低，大概只有 40% 的成功率。

到了 2018 年之后，百度就改变了传统的测试方式。我们开始以仿真为主，路测为辅。虚拟仿真的评价指标也不再仅仅是局限于每百万公里司机接管次数，而是采用了涵盖安全体感、智能化以及个性化在内的多维度综合评价指标。

同时，我们针对仿真测试过程中遇到的问题，也摒弃了 case by case 的解决方式，转而采用场景库进行问题的批量解决。比如说我发现一个问题，我不再单独解决这一个问题，而是通过该问题类别下的场景集进行统一的测试验证。此外，云仿真还有一个极为先天的优势，就是可以支持线上高并发的集成测试。可以分享这样一个数字，目前在百度内测环境里面，我们已经能够做到日行百万公里的里程测试。这也帮助我们运营版本的发布周期从原来的一个月缩短到了一周，成功上车率也达到了 99.8%。

    2.2 百度的云仿真平台架构

下面给大家展示一下百度的云仿真平台的架构。该架构与传统单机版仿真软件架构最大的区别在于，云仿真是 B/S 架构的产品。从整体来看，我们底层依赖于智能云团队提供的先进算力支撑。在仿真的核心能力上，我们包含了三个核心要素，分别是仿真执行引擎、不断完善的场景库以及我们的精细化度量工具。

仿真平台参与到整个研发测试流程后，我们就会为包括感知、决策、规划、控制在内的诸多环节进行集成测试验证，并将过程中发现的问题暴露出来，供我们的研发环节进行迭代修复，助力完成高效的闭环链路。

    2.3 仿真面临的四个问题

实际上从路测到仿真的过程，行业内依然有不少担忧，因为测试方式完全变了，出现了几个无法回避的问题就摆在所有人的面前。

• 首先是场景真不真的问题。从实际路测转向虚拟仿真的过程中，仿真的场景是否能够足够、真实地反映物理世界的客观规律。这是我们遇到的首要问题。

• 其次是场景全不全的问题。换句话说，我们在云上进行仿真测试的场景，是否能覆盖自动驾驶业务在真实的物理世界中可能会遇到的场景。

• 第三是迭代速度快不快的问题。我们知道，高阶自动驾驶对测试里程的要求非常高，动辄需要上亿里程的支持，那仿真测试的效率是否能够应对高阶自动驾驶所需的迭代里程要求就成了一个关键的问题。

• 最后是仿真评价准不准的问题。在真实的物理世界之中，我们可以通过司机的直接体验来判断模型的好坏。到了仿真测试环境里面，我们的研发既看不到和感受不到车，那么该如何去评价这套算法的实际能力呢？这也是仿真过程中亟待解决的问题。

那么针对这些痛点问题，百度的云仿真平台都一一进行了解决。

• 首先，在场景的真实度上，我们按照合规的标准集成了高精地图，1 比 1 刻画了物理世界的道路拓扑。针对动态的交通参与元素，我们基于来自于真实路采数据的场景进行挖掘，同时对动态元素的交互进行精准刻画，从而解决场景真不真的问题。

• 其次，在场景生成模式上，我们将手动场景编辑模式和基于真实路采数据的场景挖掘相结合，目前已经覆盖了 98% 的场景（包括城市、高速、停车场、封闭园区等）来满足虚拟仿真过程中对场景丰富度的要求，从而解决场景全不全的问题。

• 第三，云仿真相比于传统仿真最大的优势，就是可以依赖百度智能云的技术支撑和算力优势，实现数十万任务的并发运行，做到日行百万公里的仿真里程。这是在真实道路测试中永远无法达到的一个指标，从而解决了迭代速度快不快的问题。

• 最后，在评价体系维度，我们基于数年来的经验积累，积累了六大类 200 多项评价指标，来对每次的仿真结果进行综合评定。除了安全、交规之外，我们还将舒适性、智能性等难以通过规则直接评定的因素加入到我们的评判标准中，解决了仿真评价准不准的问题。

正是因为有这些能力的集成，才使得云仿真在高阶自动驾驶中得到广泛的应用。

3. 云仿真三个核心单元详解

刚才我们提到，云仿真中有三个核心的单元：执行引擎、场景库以及度量体系。接下来我就围绕这三个方面给大家进行分享。

    3.1 执行引擎

我们知道，传统的 L3 以下的仿真测试，驾驶任务的主要控制者依旧是人。因此这个阶段的自动驾驶算法仍是以感知和控制为主，属于重感知、轻决策的方案。对于这类算法的测试验证所使用的场景集也主要是以手动编辑为主，不用过多的去考虑交通流的完整性或者复杂的交互博弈。

但是到了 L3 及 L3 以上，也就是我们常说的高阶自动驾驶。此时，车辆成为驾驶任务的主要载体，整个算法的复杂性也就上升了好几个数量级。在仿真测试过程中，我们所关注的不再仅仅是感知、决策等单一的维度，还需要去关注场景的完整度和真实度，以便验证车辆在真实路网复杂交通流下的应对能力。

所以在百度云仿真平台的执行引擎设计过程中，我们设计了四种不同的产品单元：从基础的 WorldSim 到无限里程下的 SimCity，以满足算法开发在不同阶段对测试的不同要求。

第一个介绍的产品单元是 WorldSim，它可以基于纯手工设计 &创建的场景进行仿真执行。我们会在仿真平台内置一套场景编辑器，用户可以通过对车辆、行人、障碍物手动的拖拽，加上参数配置构建一个特定的场景，并基于该自建场景来进行快速的场景泛化。这个阶段的场景构建相对比较简单，由于是人为创建，所以自由度较高，针对性较强。工程师可以非常短平快的去构建出一个特定场景来测试某一个专项算法，十分适合用于 debug 阶段的能力验证。

第二个介绍的产品单元是 LogSim，它可以基于我们现实世界的路采数据进行场景回放，通过对场景的复现来帮助开发者进行回归验证和算法优化。通常的应用场景是安全员上报一个接管任务后，我们在实验室环境中通过 LogSim 来对当时的道路工况或者算法实际的规划轨迹进行回放验证，来评估本次接管是否是一个有效的接管。

但是 LogSim 在进行算法验证的时候常常会有一个问题：由于用于回归的场景是基于真实路采数据，所以周边交通的行为其实主要根据于路采主车当时的行为决策来进行相应调整的。比如说路采的时候，主车直行了，那么对向车道的车也选择直行。如果此时替换了算法，我的车左转了，那么我对向过来的车，理论上应该让行或者说会加速通过，但是 LogSim 仍然会按照原有直行的方式，导致问题产生。

针对该问题，我们在 Log2World 这个产品单元中进行了相关改造，将路测的交通流进行了干预重建。对真实交通参与者的行为学习引用了 SmartAgent 机制，来为障碍车赋予一套智能算法，使得和主车关联的动态障碍物都变成了一个智能体。那么在接下来的仿真测试中，其他障碍车就会根据主车的行为决策来进行对应调整。Log2World 也是我们在高阶云仿真中用的最广泛的一个产品形态，一般用于复杂场景下的 PnC 算法的闭环测试验证。

无论是前面我们讲到的主动设计的 WorldSim 或者是数据驱动的 LogSim 乃至于 Log2World，这些场景基本上都是我们能够想到的或者能够看到的场景。但是我们知道，在真实的物理世界中，往往发生交通事故的场景都是一些不太常见的场景。

这就涉及到我们最后一个产品单元 SimCity，也叫无限里程。其设计理念就是通过大路网随机生成的场景来触及长尾事件，验证算法在这些极为复杂场景下的应对能力。而所谓无限里程，实际上就是让我们的主车在基于高精地图信息构建出来的超过 5,000 公里的高联通测试道路上进行的持续性测试。在这个过程中，还可以在仿真平台中虚拟出数万个动静态障碍物，通过加载的交通流模型生成各类随机的工况，以验证算法的能力上限。

    3.2 场景库能力

仿真的第二大要素就是场景库能力。百度自动驾驶场景库来源于正向的人工主动设计以及基于真实路采数据的数据驱动场景设计。也正是因为双驱动的场景构建方式，目前我们覆盖了 98% 的场景，涵盖高速、城市、停车场、园区、机场等等一系列不同的行驶域。

百度目前有 69 类基础的场景构建能力。这些能力可以理解为构建自动驾驶场景的原子级能力。比如说主车的行为分析、对障碍物的识别、障碍物行为的判定等等。基于 69 类原子能力，我们逐渐积累了千级的语义级场景。比如说主车直行的时候遇到前方障碍物，这就是一个很基础的语义级的场景。基于这些语义级场景的上下衍生，我们又形成了百万级的设计场景以及千万级的挖掘场景。

整套场景设计的方法论其实和目前行业通用的功能场景、逻辑场景以及具体场景三要素是保持高度一致的。我们每天还在源源不断地入库新的场景数据，通过广覆盖的场景来保证我们仿真验证的充分性。

    3.3 度量评测体系

接下来介绍仿真的第三大要素：度量评价体系。百度按照通过型和数值型，将评价指标分成了两大类，六小类以及其下 200 多项具体的度量值。

通过型的指标是必须满足的指标，包括基础、安全和交规。这些指标如果不通过，那算法一定会被打回。但是只是去关注这些通过型的指标其实是远远不够的。在测试验证的过程中，我们经常发现，有些模型虽然也正常到达了终点，没有发生任何的交通事故，也没有违反任何的交通规则。但是在短短一两公里的路程里，自动驾驶模式下的车辆进行了两三次急转弯或者急刹，对乘客来说，这明显不是舒适的搭乘体验，对应的模型也肯定是不符合标准的。

因此，在通过型指标之外，我们还设计了一系列的数值型的指标，包括体感、智能化和个性化。并且针对每一个测试 case，我们都会根据选定的度量指标出具完整的平台报告，来验证我们此次仿真效果的好坏，保证通过的模型能够最大程度具备上路的标准。

以上就是百度整体的自动驾驶工具链以及仿真平台的介绍，感谢大家的聆听。

- - - - - - - - - - END - - - - - - - - - -

请关注微信公众号“百度智能云技术站”

以免错过后续精彩内容