2275
自动驾驶数据闭环的原理和框架早已不是秘密，但是数据闭环在量产车上的落地仍然是一个难题。如何打造一套好的数据闭环系统，尽可能高效、低成本地用数据驱动的方式促进自动驾驶系统能力的提升成了大家关心的问题。
1. 如何提高数据闭环的效率
那么，如何提高数据闭环的效率？笔者在与各位行业专家交流后，按照数据闭环的流程，总结了以下几点。
1.1 优化车端数据采集的逻辑
工程师可以根据模型失效分析以及模型决策边界分析，提前设定要采集的场景并制定采集逻辑，然后，在车端设置trigger层——数据回传触发器，再根据场景算法检测，自动化获取所需要的场景数据集。
在设计车端trigger层的时候，要尽量提高准确率和召回率——既要防止无价值的数据被回传，又要防止有价值的数据被漏掉。
为了提高准确率和召回率，工程师在新开发筛选逻辑时，需要先用之前采集的数据做一些验证。例如，工程师可以查看按照新开发的筛选逻辑，哪些数据会被筛选出来、哪些不会，另外也可以看筛选出来的数据是否符合预期，以及没有被筛选出来的数据中有没有系统需要的部分。假如筛选逻辑的效果符合预期，再将该筛选逻辑部署到车端。
另外，工程师在车端设置trigger层的时候，要考虑到单车的4/5G 带宽以及流量问题，可以将不同的trigger按照重要程度分成不同的组，按照事件的优先程度回传数据，尽量保证多传重要程度高的数据，例如可以优先回传稀缺场景的数据。
1.2 保证车端数据传输链路的通畅
在车端采集数据的时候，车内需要有高效的数据传输链路，来保证数据传输的速度及容量，假如只能通过传统的CAN传输，那么能传输的数据量就会非常有限。此外车端还需要配备4/5G模块，方便数据上传到云端。
目前，市面上量产的很多车型基本具备了批量回传数据的能力，尤其是高端车型。而一些中低端车型，在解决好了网络问题后也可以批量回传数据。
1.3 提高将数据场景化的能力
要从海量数据中提取真正有用的数据，需要把数据场景化。
有自动驾驶公司在关于数据闭环的文稿中提到：“场景是数据需求的基本单位，场景化是数据打通的中枢环节，足够强的场景提取能力，是一家自动驾驶公司的重要技术壁垒。”
何为场景？场景就是构成汽车驾驶环境的独立变量的随机组合，不同的场景组合在一起，就成了场景库。有业内专家将场景库比作考生的“题库”，题库越丰富，考生做过的题越多，在考试中得到高分的概率越高。相应地，场景库越丰富，自动驾驶系统能通过的场景越多，那么它在真实世界中的表现可能就会越好。
一般来说，场景库里的场景可以根据odd——即自动驾驶运行设计域来划分，odd主要包括时空、道路、道路参与者三部分。场景标签主要包括时间、天气、能见度、城市、道路等级、道路状况、交通流等，例如，“一辆车在雨天的傍晚行驶在高速公路上”就可以是一个场景。在此基础上，每一个场景标签还可以进一步细分，例如雨天还可以分为大雨、中雨、小雨等，细分程度取决于实际需求。所以说，场景库基本是无限的。
一个场景标签可以从多段数据中提取，例如很多数据可能都是在下雨天气下采集的；同一段数据也可以出现在多种场景中，此间的对应关系取决于工程师如何定义场景。
也即是说，如何给数据打标签从而映射到场景库里的一个个场景，每个场景的标签要细分到什么程度都是可调的，从某种意义上来讲，这是公司将数据场景化的能力之一。因为一个高质量的场景库离不开科学合理的分类，只有将场景科学合理地分类才能在增加场景库丰富度的同时不过分增加冗余度。
目前，市面上有部分公开的场景库可供从业者使用，这些公开的场景库有相对标准地将数据映射到场景的方式。当然了，自动驾驶公司一般也会根据需求建立自己的场景库或者在公开场景库的基础上添加数据来进一步丰富场景库。
在需要丰富场景库的时候，工程师们可以根据时间、天气、道路状况、交通流等条件来做组合，对于目前的场景库里欠缺的场景，设置相应的采集条件来采集包含这些场景的数据。
具体来讲，假如工程师希望尽可能多地采集早高峰时交通拥堵的数据，那他可以把采集时间设置在上午8点至10点；假如希望尽可能多地采集某个特定地点的数据，那他可以根据地图，把相应地点做好标记，在车辆经过这个地方的时候触发数据采集。后续希望采集其他场景的时候，工程师直接在配置文件里修改采集条件即可。
当然了，这种采集方式，主要适合一些相对简单的场景，或者是说比较容易枚举的场景。
那些更复杂的，不太容易枚举的场景，使用模型来采集可能是更合适的方式。比较常见的使用模型采集的方式就是我们常说的影子模式。
实际上，使用模型来采集数据并不局限于影子模式，也可以是用当前的模型版本和前一模型版本的比较，或者采集条件不基于一些很简单的规则叠加，而是基于更加复杂的神经网络模型，这样收集来的数据可能跟已有的数据有更大的差异性。
某新能源主机厂专家告诉笔者，“长期来看，我认为比较好的采集数据的方式是在云端训练出一个模型，这个模型可以比较好地判断哪些数据对当前的自动驾驶系统是有价值的。然后，我们可以在车端部署这个模型的简化版本，这个简化版的模型负责筛选需要上传到云端的数据。
“假如我们基于规则来筛选，就需要把规则设置成可配置的。因为基于特定的规则来筛选数据时，一个规则用的时间越长，基于这个规则筛选出来的数据的价值就会越低。那么，我们就需要一直更改筛选规则，更改规则是越往后越难的，因为容易枚举的场景会越来越少。
“以后更好的方式大概率不是一直更改规则，而是用模型来判断什么是有价值的数据，然后根据已经积累的数据不断更新模型。”
1.4 灵活更新筛选逻辑
在车端更新数据筛选逻辑时，当前主流的方式是OTA和筛选逻辑配置文件下发相结合。一般来说，筛选逻辑配置文件下发适合较小的筛选逻辑改变，OTA适合较大的筛选逻辑改变，具体采用哪种方式要结合实际情况分析。
魔视智能产品经理苏林飞介绍到：“在国内，按照工信部装备中心[2022]229号文件要求，汽车生产企业OTA需要提前向工信部报备。几乎所有OEM的量产车的OTA流程都很繁琐，首先在OTA前企业的研发部门需要向质量部门汇报发起OTA的缘由，然后提交完整的测试和验证报告给质量部门，质量部门拿到OTA需求输入后，内部开启ECR确定流程，明确变更的合理性，之后下发ECN。上述步骤完成后再开启工信部流程，最后完成OTA。
“因此，汽车OTA频率比较低。涉及到ADAS系统的OTA一般是以季度或者半年度为单位评估更新，极少数主机厂会月度更新。”
针对这一痛点，智协慧同销售副总裁牛国浩称：“我们可以提供一套不需要通过OTA，直接使用传统的车联网通道来更新的数据采集机制，这套机制支持用户把算子化的触发数据采集的逻辑部署在车端。采用这套触发机制的用户可以以天为单位甚至是以小时为单位来更新数据采集逻辑。”
灵活更新数据采集逻辑有什么好处呢？
假如某OEM有10万辆量产车，他们在这些车上都部署了采集急刹车数据的逻辑，那么，只要急刹车逻辑被触发，相关数据都会被回传到云端。不过，实际上，由于OEM来不及更新触发逻辑，尽管采集到的急刹车数据很多，但真正对算法改进有帮助的也许只有前100条，之后的急刹车数据可能都没有新增信息；但如果采集逻辑的更新频率大幅度提升，则数据的有效率会大幅度提升。
1.5 标注自动化，且标注模型不断进化
尽量提高数据闭环整个流程中的自动化比例，降低人工参与度，是提高效率的一个重要方式。尤其是标注环节，自动化可以带来很大的效率提升，同时也可以降低人员管理的难度。
目前，很多自动驾驶公司都在开发自动标注系统。自动标注系统标注好数据后，人基本只需要做质检工作——即检验自动标注系统的工作质量，例如目标物体有没有做好标记、标记的范围是否准确等。在质检阶段，一些自动化的质检算法也可以作为辅助从而减少人的工作量。
有了自动标注系统，对于大部分通用场景来说，标注工作产出成果的主要决定因素从人力资源转到了计算资源和模型精度，计算资源可以很方便地在云端拓展，因此，标注效率可以实现极大的提升。
很多公司采用场景重建的结果来实现自动标注。那么，如何基于场景重建的结果完成标注任务呢？
以 BEV的静态感知标注为例，假设有一辆车，在一个路口右转了一次，另外一辆车在路口直行了一次，还有一辆车反方向直行一次，那么我们把这些信息聚合起来，就可以重建出关于这个路口的基本完整的场景。
有了完整的场景后，当需要标注经过这个路口的车辆的相关数据时，可以拿需要标注的图像信息和重建好的场景信息匹配，从而实现对图像的标注。哪个是真值啊？重建好的场景 ？
类似的，BEV下的高度、光流、三维检测等，都可以通过同样的全息场景重建的方式来提取真值。
除了静态环境的重建，我们还可以进行动态场景重建，或面向动态的感知结果，根据这些结果拼成一个完整的、全息的4D世界信息，来给云端感知模型使用。
魔视智能产品经理苏林飞介绍到：“ 一些比较容易识别的物体——例如车辆、正常行走的行人等，模型可以识别出来，人只需要做一些质检工作，把自动标注系统没有识别出来的物体手工标记好，同时修正系统识别错误的物体。
“引进自动标注系统后，标注的工作量大致可以降低80%。随着自动化标注工具的进步，标注效率有望进一步提升。”
然而，也有数据标注服务供应商表示，在单一企业的特定任务中，假如已经把用于标注的模型训练地很好，那这个模型确实可以帮助我们实现很高比例的预标注——大概80%。但是，在面临新的任务时，原先训练好的模型可能不再适用，我们需要重新依赖人工标注——80%的预标注并不是一个普适性的比例，即使我们将语境限定在自动驾驶的任务中。
在实操中，假如传感器安装的位置改变，可能就会影响数据的识别，预标注的效果会相应降低。假如我们能够做出更通用的预标注模型，在面临不同场景时都能做到较高的预标注程度，而不是每当场景改变时都需要适配，那么标注工作的效率将能大大提高。
1.6 模型训练部分自动化
在模型训练环节，可以借助Auto ML 等工具，设计一套自动化训练引擎，将模型训练的部分工作自动化。
当前主流的公有云平台基本都支持Auto ML。此外，在学术界和产业界人士的共同努力下，现在有一些关于如何在预定义搜索空间中选择和组合不同的基本算子来生成稳健且性能良好的神经网络架构的公开的方法——例如谷歌的“神经架构搜索”（Neural Architecture Search，NAS）。基于这些方法，工程师可以更方便地找到适用于特定任务的神经网络架构。
具体到数据闭环系统里的模型训练，我们可以在训练引擎中维护一个模型集合，这个集合包含了最优的模型，也包含训练过程当中产生的中间模型。因为自动驾驶系统要解决的是一个多目标优化的问题，所以需要保存模型集合而不是单个模型。
保存好模型集合后，可以使用一个推理引擎对这些模型做评测，根据评测结果输出一个候选模型的集合——即多目标优化里的Pareto front。
然后，从模型集合里采样模型的参数和超参数——例如模型的层数、节点划分的最小样本数等，并对整个模型的参数做一些扰动，找到鲁棒性较好的一组参数，然后将这组参数和超参数一起作为初始化传入训练引擎。训练引擎中包含了新采集和标注好的数据，这些新的数据（也可以加上旧数据）可以用于模型的训练。
训练完成之后，将训练过程中产生的模型一起传回整个模型集合。此时，模型集合就是采用新数据训练过后更新的结果。
利用这样的训练引擎，我们就可以将一部分模型训练的工作自动化。
1.7 优化模型训练和部署方式
在感知层面，BEV+Transformer架构已成为业内公认的效果较好的神经网络架构。针对此架构做训练和部署上的优化可以大大提高模型训练效率，节省模型部署需要的算力。
工程师可以借助企业自建的智算中心或者一些公有云，采用大规模多机训练，从而大大提高模型训练的速度。
据悉，业内有团队通过优化训练scheme从而减少epoch、优化网络结构和算子、为Transformer定制混合精度训练等方式，先将感知模型的单机训练时间大幅缩短。然后，团队又充分利用云端算力，将单机训练改为80机并行训练，训练时间再度大幅缩短，最终达到优化前的几百分之一。
此外，我们还可以将基础网络能力的提升和模型的发布解耦，实现训练效率的提升。具体来说，可以让工程师先设计一个骨干模型，这个骨干模型和数据挖掘、自动标注、自动驾驶超算平台等形成一个闭环。在这个环里，只要有持续的数据输入，骨干模型的能力就可以持续地得到优化。需要发布模型的时候，只需在骨干模型的基础上做一些优化，而无需从头开始训练。
在模型部署层面， Transformers层通常是占用时长的大头，工程师可以尝试多种Transformers的变种构建方法，找到一个模型效果好、运行快的版本，从而减少模型推理所需的时间，还可以在尽量不影响模型效果的前提下，对模型的网络骨干做剪枝，降低网络骨干的运行时间。
此外，在计算平台上，通常会有不同的计算单元——包括GPU、DLA、CPU等。这几种计算单元对不同算子的支持度各有不同，工程师可以把神经网络的不同构件放到最适合它运行的地方，然后统一调度三种计算硬件，让三者协同发挥作用，加快模型的推理速度。
1.8 优化工具链
要提高数据闭环的效率，高效方便的工具链必不可少。
根据小马智行工具链负责人介绍：“小马智行自创立伊始就着手打造了一套高效的、方便易用的工具链。借助这套工具链，我们可以高效地用数据驱动模型的更新，同时也能够很客观地量化研发成果，从而高效地完成自动驾驶系统的迭代。”
工具链主要包括了三大平台——车云协同平台、数据平台、仿真平台。
车云协同平台主要连接车端和云端。
在车端，自动驾驶公司可以做一个可视化的界面，这个界面可以作为在车端挖掘数据的辅助。同时，这套平台是车云协同的，云端的新版本模型可以通过OTA的方式更新到车端，车端抓取的数据也可以直接回传到云端平台。
借助车云协同平台，工程师可以在云端很方便地查看车端场景的回放以及一些参考指标——例如安全员接管的频率、急刹的频率等。
此外，假如车辆在行驶过程中面临一些难以应对的情形，例如被一辆车挡住前路，车辆可以把信号发到云端来请求帮助。
数据平台主要用来收集、管理需要用到的数据。
工程师可以借助数据平台在车端采集数据，待数据上传到云端后，再做一些二次挖掘，充分发挥云端的大算力优势，处理一些更复杂的场景挖掘的需求。
把高价值的场景挖掘出来以后，工程师就不用一段一段地再去看原始数据，而是可以基于自己的某个需求，直接通过数据平台去找相应的数据。例如，工程师要找接管数据，他/她只需要在场景库里做一些筛选，就可以找到相应数据。
仿真平台主要会根据实际的路测数据来做仿真，生成仿真场景。
仿真得到的场景可以作为自动驾驶系统测试的辅助，仿真测试可以替代很大一部分的实车测试，极大地节省测试时间，同时也能降低成本。
假如要测试自动驾驶系统无保护左转的能力，工程师可以借助场景库里的无保护左转场景创建一个无保护左转的仿真任务，然后测试自动驾驶系统在这类场景下的表现。
借助仿真平台的评测模块，工程师可以看到仿真任务的具体效果——例如系统在哪些场景下通过了、在哪些场景下未通过。此外，平台还会显示更详细的测试信息。对于系统通过了的场景，工程师可以看到多维度的评测结果，包括安全性、舒适性、效率等；对于未通过的场景，工程师可以看到失败的原因——例如资源不够、版本冲突等。
此外，仿真平台也可以帮助丰富场景库，补充现实环境中较难采到的场景。
仿真平台里仿真场景的真实度和场景生成的速度是影响自动驾驶迭代能力的重要因素之一。很多自动驾驶公司都在研究如何提高仿真场景的真实度以及如何加快场景生成的速度。
据笔者了解，仿真的真实性可以通过提高“光影真实”以及“场景真实”来实现。
具体来说，工程师可以采用技术领先的渲染引擎来提高图片的真实感，从而保证“光影真实”。
在生成仿真场景时，工程师可以先用4D自动标注从真实场景里提取结构化信息——包括动态物体的4D轨迹、静态场景的3D布局等，然后用渲染引擎对结构化信息进行渲染填充，形成仿真图片。这样一来，仿真平台生成的场景就是在模拟真实世界可能发生的场景，保证了“场景真实”。
加快场景生成的速度主要可以通过提高算力来实现，不过这样也意味着成本的提升，因此公司一般会根据自身的需求酌情扩大算力。
除了上述几大平台，还有一些可以帮助提高数据闭环效率的工具。例如，公司可以建立一个服务器的集群，在执行任务的时候，服务器集群可以根据工程师们提交的任务的优先级动态地执行，从而提高计算资源利用率。
还有“用户友好”的UI平台，借助这个UI平台，工程师需要基于数据集跑一些训练或者仿真的任务时，直接在平台上指定一个算法版本，再指定一个数据集，就能一键触发这些任务，大幅提高工作效率。
高效方便的工具链可以赋能数据闭环的整个链路——从数据采集、数据回传、数据处理、数据标注、模型训练到测试验证，让数据在数据闭环系统内高效流转，加快模型迭代速度，同时节省人力、提高效率。
随着企业对数据闭环研发的深入，相应的工具链往往也会随之迭代，很多流程会变得越来越快。
小马智行工具链负责人讲道：“在小马智行，当算法工程师有新的需求时——例如他要采集（使用）无保护左转的数据，基本上一个小时内，他就可以提取出相关的数据。此前，我们已经积累了大量的路测数据，而且可以实时调度正在进行路测的车辆去相应场景帮助工程师采集数据，所以我们的工程师需要相关数据时，获取速度可以非常快。
“依靠我们的工具链，工程师除了可以很快获取数据，完成其他工作也都很快。一般来说，针对特定的场景，工程师从获取数据到模型训练到测试结果，整个过程短则一小时长则一天就能实现。
“我们大部分的步骤都是在云端进行的，也都有非常方便的工具，大家可以通过一个 web界面很方便地操作。”
2. 如何降低数据闭环的成本
提高数据闭环的效率是一方面，如何在保持高效的前提下，降低使用成本也是需要我们思考的问题。
长城沙龙智能化中心负责人杨继峰在一次演讲中提到：“从2020年到2023年，智驾系统的平台硬件成本、数据闭环流量成本加起来，上涨了接近6-10倍。”
虽然大家已经认可数据闭环是通向高阶自动驾驶的“必由之路”，但是假如成本居高不下，那么量产落地就是一件不太现实的事情。
那么，如何降低数据闭环的成本呢？我们先来看数据闭环的成本来自于什么。
根据笔者与业内专家交流得到的信息，数据闭环的成本一方面来自于工具链的开发，维持研发团队需要一定的成本。在工具链之外，很大一部分成本体现在流量费用、计算资源以及存储资源上。
有业内人士预测，数据闭环系统在量产车上落地后，量产车每天回传的数据量大致在百兆量级。虽然自动驾驶公司可以作为大客户向通信运营商要求折扣，但每兆流量成本很难低于普通客户每兆流量成本的1/10。那么，假如车的数量很大，流量成本也将是一个很大的数字。
此外，做仿真、训练模型、存储数据等都会需要服务器资源，笔者在跟行业专家的交流中了解到，有的公司数据存储量会达到上百PB的量级。
服务器使用地越多，相应地数据闭环的效率可能会越高，但同时成本也会越高。据悉有自动驾驶Tier1公司在服务器上每年的投入会达到大几千万的量级。
那么，降低成本就需要在节省流量费用、节省存储资源及计算资源上下功夫。
2.1 优化数据采集、传输和存储方案
要降低数据闭环的成本，首先要尽量从车端回传“有效”的数据，减少“无效”数据的回传。那么，就需要提高车端筛选效率，前文已有关于如何提高车端筛选效率的讨论，在此不再赘述。
在提高车端筛选效率外，还要在合适范围内尽量缩短回传数据的时长。
智协慧同销售副总裁牛国浩告诉笔者：“传统的方案很难做到精准抓取，一般会采相对较宽的视频数据，然后把这些数据全部上传到云端。这样既会浪费流量，又会增加很多数据存储压力，同时还增加了后续的标注、训练等工作量。我们可以把数据采集做得更精细。智协慧同的数据采集系统可以做到以触发数据采集的时间节点为准，把车内前后五秒钟的数据——包括摄像头的、雷达的、总线的数据进行数据去重等操作后打成压缩包然后传到云端。”
此外，要尽量减少数据的存储量，随着时间的增加，部分之前采集的数据的价值会慢慢降低，我们需要筛选出有保存价值的数据，丢掉没有价值的数据。数据的价值的主要可以基于时间和场景两个维度来衡量。
一方面，我们要尽可能保存新采集的数据，将老的数据删掉；另一方面，可以保留目前自动驾驶系统应对得还不够好的场景的数据，删掉已经应对地足够好的场景的数据。
减少数据的存储量还可以通过将数据压缩来实现。在云端，可以用高压缩态的方式来存储数据，同时给每个数据包打好相应的标签，这样一来，用户不需要打开数据包就可以知道这个数据包的关键信息。那么，用户在存储、查找以及使用数据的时候，可以更高效。
智协慧同销售副总裁牛国浩提到：“智协慧同提供的自动驾驶数据采集方案，相较于传统数采方案成本大大降低，成本的降低主要通过在车端对结构化数据实现高压缩、管端高压缩传输、云端超高压缩存储、云端存算分离几个角度来实现。”
具体细节如下表所示。
2.2 用好仿真
目前，通过仿真生成的场景的真实度越来越高，仿真可以用来帮助工程师生成较难采集的corner case数据，也可以作为自动驾驶系统测试的辅助。
另外，当需要更新模型时，工程师可以先用现有的场景库测试模型效果，无需从头开始做实车测试，这样可以大大节省测试验证的成本。
前文关于上述两点有更详细的描述，此处不再赘述。
当然了，前文提到的自动化标注，通过优化神经网络的结构从而提高模型训练的效率等，都是降低数据闭环成本的方式。
特斯拉AI day上，一位主讲人提到，“在数据驱动的人工智能时代，产业界与学术界最大的差异是，学术界人士通常会保持数据不变，在稳定不变的数据集上不断迭代新的算法，以求提高模型性能，然而产业实践的核心在于寻找问题，产业界人士通常会主动获取相应数据，不断地把新获取的数据添加到训练集中，用数据来驱动模型的更新。
“因此，产业界科技巨头可以在数据驱动的人工智能时代反过头引领学术界。数据驱动模式下，模型学到的信息全部来自于数据，而不同的模型仅是在学习速度、效率等方面有差异。因此，数据的数量和质量决定了模型的上限。”
落实到自动驾驶领域，要实现自动驾驶系统能力的提升，我们就需要尽可能多地采集“有价值”的数据。要尽可能多地采集“有价值”的数据，就需要有更多用户愿意使用自动驾驶系统。
目前，国内的自动驾驶公司越来越注重“把场景打通”，让消费者真正能够感受到自动驾驶系统带来的便利。只有用户体验够好，消费者才会认可自动驾驶系统，才会愿意使用自动驾驶系统，自动驾驶公司才能收集到更多的数据，后续的基于数据的系统迭代才有基础。
随着量产车上自动驾驶系统的普及，数据闭环在量产车上的落地，国内的自动驾驶公司能够采集到的数据越来越多，相信在不久的将来，我们可以看到自动驾驶系统能力的显著提升。
附录：工具链需要自研吗？
高效的工具链可以大大提升研发效率，同时也促使业界思考一个问题——工具链要自研还是对外采购？
据笔者了解，部分一线的研发人员希望自研工具链，因为工具链和具体的研发流程息息相关。然而，在高层眼中，尤其是传统主机厂的高层眼中，工具链只是一个工具，没必要自研。而且，业内有些供应商非常愿意对外出售自己的工具链产品。
事实上，在互联网领域，先自研某种“工具链”服务于内部，成熟之后将其出售是一个常态，例如阿里的聊天系统、会议系统等一开始都只是服务于内部员工的，这些系统成熟之后，正好市面上其他公司有相关需求，都成为了对外销售的产品。
目前，数据闭环的整个流程尚未完全成熟，相应地，工具链也要随着团队能力以及业务的变化而变化。基于此，部分一线的研发人员认为，对外购买的工具链会存在不够灵活的问题，很难跟上团队的发展。实际操作中，一些接口可能无法匹配团队目前的需求，而且团队使用的数据格式也可能改变，那么工具链可能都需要有相应改变，外购的工具链很难有较强的适应性。
小马智行工具链负责人告诉笔者：“工具链要发挥好作用，需要和研发流程很好地结合，让工程团队和算法团队能用地快。这些不仅仅涉及到工具链，也涉及到这个公司如何组织团队，如何设计研发的流程，工具链和使用工具链的团队需要一段时间的磨合。在建好工具链之后，还需要有团队一直维护，根据需求的变化一直迭代。”
目前提供工具链产品的主要是供应商，有研发人员认为，供应商和主机厂的视角有差异。具体来说，主机厂希望工具链产品能尽可能地满足自家自动驾驶研发的需求，那么在考量工具链产品的时候，会希望购买的工具链尽可能地和自家的研发流程适配。然而，站在供应商的角度，供应商希望提供的工具链产品比较“标准化”，以便尽可能多地满足更多客户的需求，假如为了满足某一家客户的需求而做一些特定的修改，那么产品会过于“定制化”，不利于推广到其他家。
一个比较折中的方法可能是核心的部分自研，主机厂可以根据云端的架构以及具体的业务划分，选定需要自研的部分。尤其是，涉及到数据管理平台的接口部分，需要自己来把控，尽量做到模块化，这样某一个模块的变化对整体的影响可以尽量降低。
某新能源主机厂的专家告诉笔者：“具体哪些模块要自研，哪些模块可以从供应商采购，其实是一个开放的问题。买的方式也可以灵活，假如供应商愿意卖白盒产品，那么我们需要更改时可以比较方便地修改，我们自己的团队可以对这套工具做持续开发，那么即使整套工具链都采购，也是可以接受的。”
“或者是说，供应商可以把接口部分开放，我们内部的团队做二次开发来定制这些接口，那么大部分的研发需求也可以被满足。所以要不要自研，能不能外购工具链其实是比较开放的问题。”
作者： 张萌宇
