两万字详解自动驾驶开发工具链的现状与趋势

两万字详解自动驾驶开发工具链的现状与趋势

划重点：

1. 车企自研自动驾驶系统成为趋势。

2. 基于MBD的开发流程已经不能满足自动驾驶系统开发需求，需引入数据驱动的端到端的开发流程。

3. 开发工具链的效率决定了整个系统开发的效率，工具链需要和pipeline数据流结合，当前工具链普遍存在割裂和“数据孤岛”现象。

4. 数据处理是数据驱动的基石：智能化数据采集势在必行，数据标注的外包化和对高质低价的追求也趋于明显。

5. 自动驾驶仿真是开发的加速器：要求仿真软件既要懂仿真，也要懂汽车；场景库被车企视为核心竞争力；仿真评价面临多样化和定制化的趋势；OpenX 得到了业内的普遍认可，仿真软件也逐渐标准化。

6. 高精地图是工具链不可或缺的一环，合规性、复杂场景精度和动态更新仍是行业痛点。

7. 自动驾驶上云是大趋势。

8. 自动驾驶开发工具链的发展趋势是：高效（端到端）、开放和灵活合作。

汽车行业“智能化”发展趋势下，各种L2级别的辅助驾驶功能成为吸引消费者的重要配置，另一方面，在“软件定义汽车”的新时代，自动驾驶更是成为了影响车企未来发展的重要战略。

如此大背景下，车企需要回答一个问题，是否要自研自动驾驶系统？

我们先来盘点下几家车企在自动驾驶领域的布局：

车企的自动驾驶布局盘点

可以看出来，车企自研自动驾驶系统成为一大趋势，很多车企也发现自动驾驶的核心是在“软硬件解耦”背景下，充分发挥出数据的价值，甚至有些车企，因为重视自动驾驶业务，也为了方便业务的后续发展，纷纷成立独立子公司，专注于智能驾驶的开发。如一汽集团成立了人工智能子公司一汽(南京)科技开发有限公司；长城汽车成立了毫末智行；上汽集团筹建了软件中心上汽零束等。

01  自动驾驶开发流程——从基于模型设计到数据驱动

不过，要自研自动驾驶系统，也并非易事，因为自动驾驶系统的开发流程和工具链特别复杂。

传统的汽车软件开发使用V 模型，包括很多ADAS功能，也都是使用这种流程去开发。具体可以参照下图，左侧是设计开发流程，右侧是测试验证流程。

V模型开发流程

左侧的设计开发流程，现阶段以基于模型设计MBD（Model Based Design）的开发流程为主，其中的多数元素（模型）是基于MathWorks公司的产品（MATLAB和Simulink）提供的标准工具箱、块组，在图形化界面上搭建模型，并自动生成代码。整体需要工程师自己编写的代码量不多，开发速度快，开发成本也较低。

右侧是测试验证流程，即X在环（X in the loop），在不同阶段采用不同的测试方法，包括MIL/SIL/PIL/HIL/DIL/VIL等测试方法。

传统的汽车软件控制逻辑，包括L2的一些相对简单的ADAS功能，使用MBD+X在环的开发流程还可以满足需求，但是随着自动驾驶算法功能越来越复杂，以前基于MBD的开发流程已经显得有点力不从心了。

首先，更加复杂的自动驾驶功能，其软件的代码量和功能的复杂程度也提升了几个数量级。结构化的工具箱和块组建模，在开发简单的功能算法时还可以胜任，但在面对复杂的深度学习算法时，MBD在灵活度方面，就显得有些捉襟见肘了。

其次，人工智能行业发展这么多年，无论是架构还是工具链、各种各样开源的函数库，都已经形成强大的生态，对于如今的自动驾驶从业者而言，直接用编程来实现，反而比在Mathworks里建模效率更高得多。

同时，传统汽车软件量产之后就不再发生变化，这对于自动驾驶软件是不现实的。一方面，自动驾驶开发周期长，在整车开发周期内开发、测试的时间远不够；另一方面，OTA让软件持续升级有了可能，这样软件的生命周期也得到了延续，而以深度学习模型为代表的自动驾驶算法，就需要持续不断地收集长尾的“corner case”数据，作为“燃料”持续迭代算法系统。

有句话说得好，如果要上太空，就不能搭梯子，必须要造飞船。为了更有效率地开发自动驾驶系统，业内专家们找到了适用于基于深度学习的自动驾驶开发流程——也就是数据驱动的端到端的开发流程。

对于这种软件开发流程的转变，有前瞻意识的车企和Tier 1也早已意识到。

博世底盘控制系统中国区总裁陈黎明曾在公开场合提到：“自动驾驶牵涉的场景非常多，不可能再按照传统的方式继续进行，所以必须加入实际道路测试，特别是用数据驱动的验证方式对自动驾驶安全进行验证，就是V模型和数据驱动的闭环进行结合，实现安全验证。”

泛亚技术中心的高级总监陆健翔在近期的世界智能大会上表示：“传统车企要从原本的车端的这种瀑布式的系统集成开发模式向云管端一体化的敏捷式场景集成开发模式转型。”

当然，这并不意味着传统的MBD的方法已经完全过时。V模型的思路仍然是很有指导意义的，比如在自动驾驶系统测试中发挥重要作用的系统仿真，其实就是SIL（软件在换），而MBD开发方法，在汽车底层逻辑算法，如车辆控制算法中仍然会用到。

虽然每一家的数据驱动的软件开发流程在细节上有不同，但是大体思路都是一致的，基本按照如下思路：数据采集->数据存储->数据预处理->数据挖掘->数据标注->模型训练->仿真测试->部署发布。

Waymo的数据闭环平台，引用自黄浴的知乎文章

上述环节中所使用的工具和平台（包括但不限于数据采集、处理、标注工具、模型训练平台、仿真平台、OTA工具和一些其他环节的开发工具），被称作“工具链”。工具链的效率决定了整个系统开发的效率。

虽然可能看上去步骤不多，但其实整个链路非常复杂。

以数据处理为例，单数据类型就多种多样，包括摄像头数据、毫米波雷达数据、激光雷达点云数据，需要先对这些数据进行去噪，也就是所谓的“数据清洗”。以图片为例，数据处理需要先把图片的地理位置信息等擦除，把人脸、车牌等敏感信息去除，再统一格式，这样才算处理完成。

数据处理完成后，下一步便开始数据标注。标注的类型大致可分为2D、3D目标物标注、联合标注、车道线标注和语义分割等，还要涉及到具体标注规范和标注质检流程，整个流程异常繁琐。

而这复杂流程的每一个环节，都需要与之对应的工具和平台的支撑。

和MBD开发流程已经拥有成熟的工具链不同，数据驱动的开发流程，起步晚，工具链效率不高，给车企的自动驾驶开发人员带来了很大的困扰。

数据驱动，源头是数据，面对数据量庞大但高价值数据稀缺的问题，车企并没有太多的经验可供借鉴。

当然，不同的车企，在自动驾驶领域的积累程度不同，在工具链上遇到的问题也不尽相同。

部分车企起步早、投入大，（数据驱动）pipeline已经可以完整跑通，积累也比较多，为了进一步提升效率，他们也做了很多工具链的定制开发。某车企的开发人员告诉《九章智驾》，由于现有不同公司提供的工具链是“分段开发”，只关注自己部分的功能而不关注全局，导致割裂和“数据孤岛”现象严重。为了满足自己的效率需求，他们不得不自己开发工具链或者找生态体系内的企业来提供，甚至连数据标注平台都要自己开发。

对于在该领域积累没有那么多的车企来说，现阶段投入那么多人去开发工具链，就不是多么“划算”了，一方面基础薄弱，技术还没研发到那个地步，另一方面也确实没那么多人。受限于资源投入和技术基础，他们更多地还是希望整合现成的工具链，尽快跑通（数据驱动）Pipeline，“工具链不是我们的竞争力，需求定义、系统集成和功能测试才是我们的竞争力”，某车企智能驾驶负责人告诉《九章智驾》。

不同车企虽然开发阶段不同，但也有相似之处，那就是都有工具链“割裂”的痛点。接下来，我们就分别从数据处理、仿真这两个环节入手，详细梳理下工具链的现状和痛点。

02  数据处理：数据驱动的基石

数据驱动，最核心的就是数据。

传统基于模型的开发流程，更多是基于开发者的过往经验对模型优化，而数据驱动，则是要基于海量的数据来优化模型。对于车企而言，要建立数据驱动的开发流程，必须要学会怎么处理庞大的数据。

数据处理，是整个开发链路的第一环节，也是最繁杂的环节，包括了数据采集、数据预处理、数据挖掘和数据标注等环节，其数据量的多少和数据质量的高低直接决定了整个模型的水平。

下图为特斯拉自动驾驶数据处理的链路。

Tesla Autopilot数据处理流程（引用自黄浴的知乎文章）

数据相关的工具链，包括了数据采集、数据上传、数据清洗、数据标注等环节。

2.1 数据采集：智能化势在必行

先说数据采集。

行业里有一些开源的数据集，可以用做基础算法训练，目前最常用的数据集有KITTI、nuScenes等，不过这些数据还是多半来自海外的公开测试集，中国本土特色的数据集，还是比较少的。