本文主要是介绍自动驾驶系统中的数据闭环：挑战与前景，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
自动驾驶概况
1.1自动驾驶分级
1.2自动驾驶国内发展
1.3自动驾驶架构模型
数据闭环的意义
2.1 搜集corner case的数据
2.2 提高模型的泛化能力
2.3 驱动算法迭代
数据闭环落地的痛点及对策
3.1 数据采集和使用的合规性问题
3.2 数据确权问题
3.3 数据采集会占用系统资源
3.4 数据标注及后续处理的难度大
3.5 数据驱动的软件系统复杂度高
3.6 模型训练难度增加
自动驾驶概况
1.1自动驾驶分级
1.2自动驾驶国内发展
1.3自动驾驶架构模型
数据闭环的意义
2.1 搜集corner case的数据
只要是L2及L2以上的产品，都需要具备持续进化的能力。要让自动驾驶系统持续地进化，就需要不断获得corner case的数据。而随着越来越多的corner case从“未知”转换成“已知”，通过数量有限、形式路线也有限的测试车辆挖掘出新的corner case的难度越来越大。
通过在场景覆盖度更广的量产车上部署数据采集系统，在遇到当前的自动驾驶系统处理地得不够好的情形时，触发数据回传，是一种比较好的获取corner case的方法。
例如，可以在搭载L2辅助驾驶的量产车上部署AEB系统，然后收集驾驶员猛踩刹车、猛踩油门、猛打转向、猛打方向盘等的数据，分析为什么驾驶员在做这些操作的时候AEB系统没有任何响应。针对AEB系统应对地不够好的问题做相应改进，提高AEB系统的能力。
2.2 提高模型的泛化能力
当前，高等级的辅助驾驶正在从高速向城市进军。要解决高速这样相对简单的场景，基本上，仅靠测试车采集的数据来训练模型就够了，而不是一定要回传量产车的数据；然而，城市场景的复杂度大幅提升了，而且不同城市的路况也有很多差异。例如，在广州，随处可见拉着货物的三轮车在道路上疾驰，而在上海就很少会见到这种情形。
因此，很多自动驾驶Tier1以及车企对场景打通的诉求很强烈——即车辆的辅助驾驶系统可妥善应对各主流城市的各种路况。因为车企无法限制用户的行驶范围，假如只针对很小的区域做好辅助驾驶功能，会大大缩小用户群的范围，这显然不是车企希望看到的。
要实现场景打通的目标，模型的泛化能力就需要大幅提高。要大幅提高模型的泛化能力，就要尽可能地把各种各样的场景对应的数据都采集到。而只有基于大规模真实人驾数据的乘用车辅助驾驶才有能力积累到足够规模和足够多样的数据。
2.3 驱动算法迭代
前文提到，基于深度学习的人工智能算法发展已经超过十年。这期间，随着模型的演进以及算力的发展，自动驾驶系统对大数据的消化成为可能。此外，自动驾驶系统要升级，感知、规划等环节都需要在能力上有相应的提升，而采用数据驱动，让算法持续不断地进化，是提升感知、规划等环节能力的一个高效的方式。
城市NOA——即城市内的点对点导航辅助功能是很多主机厂以及自动驾驶Tier1接下来的发力点，要实现点对点的导航辅助驾驶功能，感知系统的语义识别、障碍物识别、可行驶区域的识别都需要具备一定的精度，然而目前这一标准尚未实现。
目前主流的感知系统网络架构是基于BEV+Transformer模型，单纯依靠软件工程师或者算法架构师来优化，模型可以提升的空间不太多，而BEV+Transformer的架构可以容纳大量的数据，进而有望让模型效果得到提升。
在规划层面，数据驱动也可以发挥作用。特斯拉早先使用部分约束下的最优方案作为初值，然后采用递增的方式不断加入新的约束，再求解增加约束后的优化问题，最终得到规划问题的最优。特斯拉工程师针对此方法离线做了很多预生成，并在在线做了并行优化，这样每个候选路径的计算时间仍然长达1～5ms。而根据特斯拉在2022年9月30日的AI day上披露的内容，特斯拉的工程师现在使用了一套数据驱动的决策树生成模型来帮助自动驾驶系统快速生成规划路径。这个数据驱动的决策树生成模型使用特斯拉车队中人类驾驶员驾驶数据和无时间约束下的最优路径作为真值进行训练，能够在100us内生成一个候选规划路径，大大缩短了生成候选规划路径的时间。
综上可见，搭建好数据闭环系统是自动驾驶系统能力提升的一个重要方式。
数据闭环落地的痛点及对策
3.1 数据采集和使用的合规性问题
合规分为测绘合规和隐私合规：测绘合规主要涉及到采集国家地理信息时的合规，隐私合规主要涉及到采集用户隐私相关数据的合规。
测绘合规方面，近几年，国家对数据安全的管理趋严，出台了相关法律法规来对回传数据的范围进行限制。2022 年 “830 新规”之后，车辆在道路上采集的数据都属于测绘数据。企业要使用测绘数据，后续的数据加密、数据合规的环节必不可少。
首先，在道路上采集数据的时候，企业需要具备国家测绘资质，并且要做相应的备案，否则采集过程中会被国安等部门阻止。目前，国内总共有约30家机构具备相关资质，有的企业具备国家电子导航甲级资质，适用范围较广，在国内多个城市都可以采集，而有的企业具备乙级资质，适用范围就会更小，只能在特定的城市采集。
由于测绘资质很难获取，需要有长期的业务积累，并且，要保有测绘资质，企业就需要有相应的测绘业务。因此，主机厂以及自动驾驶Tier1一般会委托带有资质的供应商或单位，例如现在有些云厂商会帮助客户围绕数据的获取、加工、使用来设计一个合规方案。
采集到数据后，还需要在车端脱敏、加密，上云之后（一般来讲是私有云），还需要做一些合规工作，这一部分会由有资质的供应商或者单位来帮忙做测绘的合规。对于部分很敏感的数据，需要由图商来做采集，而且数据需要在脱敏之后存储在图商监管的服务器里。
另外，测绘的数据不得泄漏，尤其是不得将数据挪到国外，非中国国籍的人既不能获取测绘数据，也不能在公司内操作测绘数据。
一般来说，主机厂和自动驾驶Tier1会建立自己的数据中心，出于安全考虑，这些数据中心都比较封闭。主机厂和自动驾驶Tier1需要使用这些数据中心存储的数据来做一些训练、仿真等工作的时候，基于合规要求，需要将相关模型部署到数据中心来使用。
有业内专家表示，“测绘的合规流程太复杂，资质也很难获取，大家希望尽可能减少对高精地图的依赖，这是目前业界流行‘重感知轻地图’方案的一部分原因。但实际上，轻地图不一定就是‘更好’，因为有地图数据效果肯定比没有好。目前这个趋势不一定是最终的形态，也不一定是最好的，只是大家希望能做得更简单一点。”
隐私合规方面，企业在量产车上采集数据，需要用户授权。类似于用微信的时候，企业需要用户在一开始签署授权协议，并告知用户哪些数据会被采集，哪些使用行为会被记录。
3.2 数据确权问题
我们是否可以在车上采集自动驾驶行业需要的摄像头、激光或毫米波形成的数据呢？
“按照中国的《个人信息保护法》相关规定，非法律允许的数据采集受到隐私保护。在德国，原德国联邦信息保护局有这样的规定，如果司机不是受害者，未经对方同意就记录其他司机的脸和车辆，是违反个人信息保护法的。也就是说，即使是车主记录别人信息也可能属于违法。但由于和新能源车伴生的自动驾驶行业很新，法律规定目前尚属空缺，所以我们按照基本法学理念推导，量产车采集的数据应该由车主所有。”
那车主使用自己的车辆采集的数据是否可以授权给其他单位使用呢？
目前并没有相关法律规定与约束。但是在其他行业，比如手机、互联网领域，是广泛允许的。
谁可以拿到车主上传的数据？
从汽车产业链分工看，2种主体可以拿到，第1种是无人车队运营公司，比如百度的无人驾驶出租车，第2种是主机厂。但由于前者规模较小，所以我们重点介绍后者。
由于主机厂离用户最近，所以最容易拿到用户上传的数据。在全球范围看，Tesla是在这方面做地最好的主机厂。
目前，主机厂很少对外开放数据，导致自动驾驶Tier1在帮助主机厂实现了主机厂定制的功能后，很难收集到用户在使用这些功能时的反馈数据，除非Tier1自己有很多测试车。那么，自动驾驶Tier1就难以根据用户反馈的数据对相关功能做后续的优化，数据闭环就难以实现。
3.3 数据采集会占用系统资源
在量产车上采集数据会占用一些系统资源，比如计算、存储等。理论上，可以假设计算资源、网络带宽等都不受限制，但在实际落地过程中，如何保证采集数据不影响量产车上自动驾驶系统的正常运行，例如，如何不影响自动驾驶系统的延迟等，这是一个需要解决的问题。
3.4 数据标注及后续处理的难度大
据估计，从量产车回传数据后，单车每日回传的数据量大概为百兆级。研发阶段，车辆总数可能只有几十辆或者几百辆。但是到了量产阶段，车辆数目的量级可以达到上万、几十万甚至更多。那么，量产阶段，整个车队日产生的数据量就是很大的数字。
急剧增加的数据量给存储空间以及数据处理的速度都带来了挑战。量产之后，数据处理的延迟需要和研发阶段保持在同一个量级。但如果底层的基础设施跟不上，数据处理的延迟就会随着数据量的增长而相应地增加，这样会极大地拖慢研发流程的进度。对于系统迭代来讲，这种效率的降低是不可接受的。
3.5 数据驱动的软件系统复杂度高
传统的V字型开发模式很难适用于数据闭环。而且，目前行业中还没有形成统一的面向高等级自动驾驶的软件开发平台及中间件。
某公司自动驾驶部门的技术专家告诉笔者，“以数据和深度学习模型驱动的自动驾驶功能迭代体系可以称之为软件2.0。在这样的模式下，整个体系，包括团队的构建、研发流程、测试方法、工具链都是围绕数据构建的。
在软件1.0时代，每个人提交了什么代码，预期的效果都是很容易评估的。但是，在软件2.0时代，每个人贡献的部分对整体效果的影响的衡量难度变大了，而且也很难事先预期，因为大家相互交流的不再是清晰可见的代码，而是数据以及根据数据更新的模型。
在数据量很少的时候，例如我们之前做移动互联网应用的AI视觉算法，由于数据量很少，涉及的视觉模型工程师，大家基本上是Windows或Ubuntu的文件夹各自管理，团队成员互相之间直接用各种重新命名的文件夹来回传输，非常低效进行数据交换或合作。
但是涉及到自动驾驶任务时，我们面临的是几十万张图片，而且是几百人共同研发一个系统，每次改动涉及到的的模块可能都是上百乃至上千。如何评测每个模块的代码质量，如何检验各模块之间是否有冲突，这些都是较为复杂的任务。迄今为止，我认为这套系统仍较为糟糕，工程化部分还不够成熟。
到了软件2.0阶段，还需要应对的问题是：如何衡量新增的数据对特定的场景和对全局的影响分别是什么，如何避免基于新增数据重新训练的模型在一些特定任务上效果变好但总体上效果下降。要解决这些问题，我们需要做单元测试，来检验新增部分数据后，对我们希望解决的细分场景有没有帮助以及对全局有没有帮助。
举例来讲，假如针对某个特定的任务，原始的数据集是2000万张图片，然后新增500张图片，解决这个特定任务的能力提升了，但有时候这也同时意味着模型在应对全局任务时得分降低。
此外，针对视觉任务，除了根据指标来判断新增数据对模型的影响，我们还需要实际去看具体的影响是什么，这样才能知道优化是否符合预期。仅仅通过指标来看可能会出现虽然指标提升了但实际效果仍然不符合预期的情况。
3.6 模型训练难度增加
解决了数据采集、存储、标注等问题后，后续的模型训练、功能迭代仍然是挑战。
训练量产车上回传的大量数据，需要有高效的文件传输系统，保证训练时不被I/O“卡脖子”。
同时，还要有充足的算力。提高算力的方式通常是打造多卡并行的集群，那么，如何在训练时保持高效的卡间通信来减少数据传输的延迟从而充分有效地利用每张卡的算力也是需要考虑的问题。
为应对模型训练对算力的需求，有主机厂专门打造了自己的智算中心。然而，打造智算中心的成本很高，对于中小企业来说，这几乎是一件不可能的事情。
尽管当前仍存在诸多痛点，但我们仍然可以预期，假以时日，目前存在的问题会被逐个解决。届时，数据闭环能在量产车上真正落地，在量产车上落地后采集的数据将反哺数据闭环系统，推动自动驾驶系统走向更高阶。
这篇关于自动驾驶系统中的数据闭环：挑战与前景的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
