**导读：**本次分享将从以下几个方面介绍——

• Pony.ai 基础架构做什么
• 车载系统
• 仿真平台
• 数据基础架构
• 其他基础架构

–

01 Pony.ai 基础架构

互联网公司在系统基础架构在业务扩展时通常会遇到一些通用的技术挑战，比如存储系统、计算平台还有 Web 服务治理。除了上述提到的互联网公司会遇到的一些技术挑战之外，会有很多自动驾驶技术本身相关的技术挑战，比如大家都可以想到的车载系统、仿真平台。此外，对于 Pony.ai 来说，如果运营一个大规模的自动驾驶车队，需要有一套完善的车队运营基础。自动驾驶需要和人进行交互，因此需要一个人机交互的接口。

Pony.ai 的目标是建立一个比较大规模的自动驾驶车队，车队规模在未来会成百上千计，而目前公司正处于自动驾驶车队数量快速扩张的阶段，虽然对其他技术挑战也存在，但是对基础架构的挑战更是巨大的，它要求整个自动驾驶的基础架构要有足够的可扩展性。随着车辆数量的增加，运营区域会增加、数据量会增加、工程师数量增加，系统各个模块数量会增加、内部代码量也会增加。这些都会给基础架构带来非常多的技术问题。接下来会详细介绍在我们在基础架构演进过程中遇到的挑战。

–

02 车载系统

首先介绍的是自动驾驶车载系统。

那么什么是车载系统呢？一般来说自动驾驶系统上有很多传感器代替人类收集信息，车载系统需要处理这些数据信息，最终转化为对车辆的控制决策，如踩刹车、转多少方向盘，做出决策后传递给车辆。

上图是一个自动驾驶系统示意图，每一个方块对应系统中的一个模块。

首先，车载系统通过一些传感器去感知真实世界，有激光雷达、摄像头等驱动收集真实世界中的信息，这些信息会传递给 Perception 模块，这个模块会实时感知车辆行驶中周围的环境，比如车辆周围有哪些车辆以什么样的状态在行驶；车辆周围有哪些行人等。

当 Perception 模块收集到这些信息后将其传递给 Prediction 模块，我们不能只依据当前车辆周围环境信息做决策，需要对车辆周围的任何物体或者人、障碍物接下来的行为预计，如前面路口的车是转弯还是直行对接下来车辆的决策很重要。

当 Prediction 模块生成这些信息后会传递给 Planner 模块，这个模块会规划接下来车辆一段时间的行驶轨迹、做出什么样的决策。比如前面有行人需要踩刹车等待行人先过去，前面车行驶比较慢可能需要变道超车。

当 Planner 模块规划好轨迹后传递给 control 模块，计算出车辆需要进行操作的指标参数，如打多少方向盘，踩多少刹车等，最后传递给自动驾驶车辆。在模块运行中，可能还需要其他一些模块，需要高精度地图、实时定位，还需要 router 模块，当指定起点终点时，需要计算出一条合理的路线。

车载系统需要去调度各个模块的运行，模块间的消息通信（一个模块的输入可能是另一个模块的输出），还有车辆上有不同的计算资源，不同的模块可能也需要不同的计算资源，一些感知的算法可能需要很大的 GPU，有些模块可能是 CPU 计算多一些，因此需要系统合理分配不同模块需要的计算资源。日志记录也是车载系统需要提供的非常重要的功能功能，在自动驾驶的过程中，系统需要记录车辆运行过程。这样如果出现一些非预计的情况可以通过日志信息进行 debug，来帮助系统持续演进。此外，自动驾驶安全要求很高，因此系统需要有非常完善的监控和报警系统，当系统出现一点点问题都需要及时报警，使得安全员可以进行正确的反应来避免潜在的危险。

对于车载系统有很多要求，在某些方面可能实现比较困难。

首先是可靠性，代码逻辑设计错误会出现各种问题在车载系统可能引起严重后果，因此对这方面的可靠性要求很高。特别是 Pony.ai 正在扩展车队的规模，不稳定的系统可能严重影响车队运营效率。可靠性也体现在系统监控和异常报警的可靠性要求也很高。

第二个系统设计的要求就是高性能，各模块间消息通信的数据量很大。在我们最新一代车载系统中有6个1080P摄像头，当以每秒10-20帧的帧率获取数据，每秒会产生的数据量是非常大的。要使这么大的数据量高效在各个模块之间传输，对于设计上的挑战还是很大的。吞吐量之外，模块通信延迟也要求很低，想象一下如果识别到车辆前方的行人之后需要1秒才能作出反应，就可能会造成严重的后果了。最后一点是系统需要保持高效的灵活性，需要系统灵活的支持各种不同的模块计算资源的接入，还有不同类型模块的接入。

针对这些系统设计上的需求公司早期决定放弃有名的开源 ROS，自主研发 PonyBrain。做出决策的原因有：首先 ROS 作为开源系统，代码质量可能不受公司控制，不能很好地保证代码质量。另外一点是 ROS 作为一个通用的机器人操作系统，可能不太贴合一些特殊的自动驾驶需求。基于上面这些因素，我们选择自研 PonyBrain 系统。

对于之前提到的系统设计上的挑战，我们也都在工程实践上有一套针对性的措施。首先可靠性挑战，只有高质量的代码才有可能让系统足够可靠。为了提高代码质量，必须执行非常严的 Code review 和 Unit test 的机制来保证代码质量，确保不会有意外状况出现。同时，还会使用一些工具来及时发现问题，如静态分析和 ASAN，还有监测内存泄露的工具。在系统运行时也会有多重系统可靠性检查，在系统启动前会校验系统启动环境，系统运行时也会有实时监控检查，监控系统运行是否符合预期；系统运行后也会将收集到的所有数据都会执行数据分析，监测系统运行是否存在潜在问题。

另外，还会有持续的集成与发布平台来保证每一册代码改动后的系统可靠性，会提供一个稳定的 Release 版本发布给车队测试。

对于高性能方面，只能依据车载系统的实际需求做一些合理的架构设计上的取舍。在设计时更可能多的考虑些消息通信中需要支持的一些场景，避免大数据的拷贝时影响性能的逻辑。我们也会预计不同模块资源需求合理的分配计算资源，保证不同模块高效运行。还有是对系统定期进行 Profile 分析，通过数据矩阵的方式分析系统瓶颈，去优化性能。

对于系统灵活性方面，一开始就需要定义好通用的模块接口的通用的消息通信接口去支持不同类型的模块和不同的消息通信。

–

03 仿真平台

仿真平台在日常开发起到非常重要的作用。其重要性不言而喻。首先仿真平台相对于路测低开销，不需要路测和人力的介入来评价系统性能变化；第二个就是低风险，不会对实际中的任何车辆产生影响；第三点提供了基于数据驱动的快速迭代算法的可能性，新算法直接可以在仿真平台上评估。

仿真平台有两个主要的使用场景。第一，它需要支持真实路测收集的场景，在路测中可能出现某一个场景处理不好，需要能够对异常进行追溯和修复，需要在仿真平台进行复现来检验算法。第二，仿真平台需要支持人工或者随机生成的场景，来帮助我们去测试一些不太成熟的算法或者是很难路测到的一些场景，如前面几辆车行驶较慢，车辆在变道的时候左边有一辆运行比较快的大车，这时需要车辆做出正确的决策，这样可以保证所有的算法和 feature 都可以在仿真平台上做足够多的测试。

下面来谈谈仿真平台的挑战与实践。首先是如何保证仿真结果的足够可靠。服务器的环境不可能和车辆的环境足够一致，机器配置和服务器配置可能存在区别，如何在仿真平台上模拟车载计算平台的环境并不容易。在仿真平台里不像真是场景有控制反馈的机制，因此需要对真实车辆的动力学模型进行仿真建模来支持仿真平台。第二个就是仿真数据的选择和管理。我们需要对路测数据进行管理，提取一些类型收集这些路测数据，仿真流水线可依据不同需求运行不同的 feature 和 case。第三点就是仿真的系统性能很重要，快速的得到仿真的结果可以帮助工程师更快的验证新的算法。因此需要一个分布式高性能的仿真平台，能够快速的将仿真结果反馈出来供工程师去决策。

–

04 数据基础架构

数据是自动驾驶技术的核心驱动力，在做仿真、模型验证，解决路测不好的 case 时，都需要靠数据支持，因此我们需要解决数据的存储和访问、数据处理机制、数据同步机制等问题。对于数据基础架构而言，面临的核心挑战是数据量很大，数据量是 PB 级。还有就是数据属性不同于互联网数据，有大量客户端产生的数据（互联网是用户累计数据量大，单个用户数据量不大），有大量传感器数据，有大量模块运行日志数据。

数据存储的挑战。首先会依据特定的数据使用场景设计一些合理的存储格式，例如需要便于车载系统记录，需要进行大规模数据分析。有些数据有部分访问和随机访问的需求，一个8个小时运行数据，我们可能关心的只是运行过程异常的时间段，这个时候就需要系统能够方便获取我们感兴趣的数据。最重要的一点是要便于文件系统存储。当确定了存储格式还需要选择合适的存储系统，如冷热数据不同选择方案，存储系统高可用，容易水平扩展，控制成本。

数据处理可以帮助收集性能指标，有 MPI、模块运行效率、乘客舒适度体验等，还有就是路测有趣场景的挖掘，如接管、急刹、感知算法识别、不合理的变道策略等用于模型训练和仿真。在数据处理我们要着重减少从数据采集到数据处理完成的延迟，这直接影响了路测的问题得到解决的效率；另外就是依据不同类型数据处理的任务选择合适的处理系统，如有些数据处理任务是 CPU 密集型，有些是 IO 密集型，要区分不同需求用不同的机制去完成；与车载系统一样，数据处理系统同样需要有通用的任务定义以支持灵活的添加新任务。

特别说一说数据同步，Pony.ai 有三个办公室和多个测车地点，但这并不意味着需要多个系统，整个公司在用同一整套的解决方案去部署在多个不同的测车地点，这样我们的系统是有足够的泛化能力的。那么数据需要在测车地点和研发办公室之间按需同步服务，这个服务又受到带宽等网络条件的限制，设计起来还是非常有挑战的。

–

05 其他基础架构服务

建立一个自动驾驶车队，车队运营会有很多业务需求，车辆增长快，运营人员增长也快。如何高效运营这个车队对配套服务的要求很高，需要进行车辆状态管理、路测任务管理，还有车队运营实时监控，帮助车辆运营状态实时观测车辆状态。

对于车队运营基础平台的挑战在 Web service 的产品开发和产品的迭代速度很快、业务逻辑复杂。相关的基础架构需要去面对快速变化的复杂需求以及大量 Web service 的部署与管理。为了支持各种各样的计算和服务需要大规模的服务调度平台充分利用服务器集群支持多种应用，因此会在 Kubernetes 平台上做一些开发。

随着规模扩大可能会有一些可视化需求，需要维护一个通用的可视化工具，便于工程师方便查询算法运行和场景运行，因此需要高性能，需要注重 3D 实时渲染性能，系统是跨平台，支持桌面/移动/Web 等多平台，还有人机交互接口，方便乘客使用的用户界面。

注：欢迎转载，转载请留言或私信。