划重点：
1.车企自研自动驾驶系统成为趋势。
2.基于MBD的开发流程已经不能满足自动驾驶系统开发需求，需引入数据驱动的端到端的开发流程。
3.开发工具链的效率决定了整个系统开发的效率，工具链需要和pipeline数据流结合，当前工具链普遍存在割裂和“数据孤岛”现象。
4.数据处理是数据驱动的基石：智能化数据采集势在必行，数据标注的外包化和对高质低价的追求也趋于明显。
5.自动驾驶仿真是开发的加速器：要求仿真软件既要懂仿真，也要懂汽车；场景库被车企视为核心竞争力；仿真评价面临多样化和定制化的趋势；OpenX 得到了业内的普遍认可，仿真软件也逐渐标准化。
6.高精地图是工具链不可或缺的一环，合规性、复杂场景精度和动态更新仍是行业痛点。
7.自动驾驶上云是大趋势。
8.自动驾驶开发工具链的发展趋势是：高效（端到端）、开放和灵活合作。
汽车行业“智能化”发展趋势下，各种L2级别的辅助驾驶功能成为吸引消费者的重要配置，另一方面，在“软件定义汽车”的新时代，自动驾驶更是成为了影响车企未来发展的重要战略。
如此大背景下，车企需要回答一个问题，是否要自研自动驾驶系统？
我们先来盘点下几家车企在自动驾驶领域的布局：
车企的自动驾驶布局盘点
可以看出来，车企自研自动驾驶系统成为一大趋势，很多车企也发现自动驾驶的核心是在“软硬件解耦”背景下，充分发挥出数据的价值，甚至有些车企，因为重视自动驾驶业务，也为了方便业务的后续发展，纷纷成立独立子公司，专注于智能驾驶的开发。如一汽集团成立了人工智能子公司一汽(南京)科技开发有限公司；长城汽车成立了毫末智行；上汽集团筹建了软件中心上汽零束等。
不过，要自研自动驾驶系统，也并非易事，因为自动驾驶系统的开发流程和工具链特别复杂。
传统的汽车软件开发使用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，“工具链不是我们的竞争力，需求定义、系统集成和功能测试才是我们的竞争力”，某车企智能驾驶负责人告诉《九章智驾》。
不同车企虽然开发阶段不同，但也有相似之处，那就是都有工具链“割裂”的痛点。接下来，我们就分别从数据处理、仿真这两个环节入手，详细梳理下工具链的现状和痛点。
数据驱动，最核心的就是数据。传统基于模型的开发流程，更多是基于开发者的过往经验对模型优化，而数据驱动，则是要基于海量的数据来优化模型。对于车企而言，要建立数据驱动的开发流程，必须要学会怎么处理庞大的数据。
数据处理，是整个开发链路的第一环节，也是最繁杂的环节，包括了数据采集、数据预处理、数据挖掘和数据标注等环节，其数据量的多少和数据质量的高低直接决定了整个模型的水平。
下图为特斯拉自动驾驶数据处理的链路。
Tesla Autopilot数据处理流程（引用自黄浴的知乎文章）
数据相关的工具链，包括了数据采集、数据上传、数据清洗、数据标注等环节。
先说数据采集。行业里有一些开源的数据集，可以用做基础算法训练，目前最常用的数据集有KITTI、nuScenes等，不过这些数据还是多半来自海外的公开测试集，中国本土特色的数据集，还是比较少的。
自动驾驶开源数据集汇总，引用知乎文章《自动驾驶开源数据集汇总》
在这种情况下，要训练匹配特定场景的算法，就需要收集该场景的数据。只有足够多且高质量的数据采集到了，才有了后续的流程，而这第一个环节，目前工具链的效率并不太好。
某头部造车新势力员工告诉《九章智驾》，该公司自动驾驶数据采集触发、数据上传的策略还不能满足后续问题分析的要求。比如，用户撞了车之后，回传的数据不能用——要么数据量不全，要么采集频率不对，开发人员在排查问题时效率很低。
一般来说，不同的Corner Case，后续分析所需要的数据格式不一样、前后所需要的时间段也不一样。这个很容易理解，不同原因导致的接管，是感知还是决策模块的问题，还是高精地图的错误，所需要的数据当然是不一样的。甚至针对某些特殊的Corner Case，还会有一些定制化的数据采集需求，让测试人员带着采集任务去路测。
而正是因为采集需求复杂，链路打通又难，现实中有些工程师遇到问题，便会选择自己去采集数据。为了避免上述这些问题，有些L4 Robotaxi公司选择用最原始的“硬盘拷贝”方式，全量数据回传，然后再进行数据挖掘。
这样做，当测试车辆数量少时，是没有问题的，一旦后续车辆多到一定程度后，自动驾驶采集的数据量即将进入PB时代，如此“海量”的数据，真正找到有价值的、占比较少的Corner Case，真正的“大海捞针”。
而要采集对自动驾驶真正有用的片段数据，就需要更加智能化的数据采集策略。
何谓智能化数据采集策略？就是针对特定场景进行数据采集。
华为内部人员在和《九章智驾》交流时，提到“华为八爪鱼”便有对场景进行智能化打标签的功能：“比如发生人工接管，或者遇到隧道、环岛、无保护左转等，以及快递三轮车之类云端需要主动搜集积累数据进行学习的场景。开发人员可以上传需要车辆获取的图片，通过云端下发指令，车端会采取类似‘以图搜图’的方式，遇到类似的场景就会自动截取下来。这样，只需要把这些打过标签的‘有价值’数据筛选出来上传到云端即可，可避免整段数据上传，能提升Corner Case挖掘的效率。”
找到有价值的数据之后，就需要进行数据清洗和数据标注。
在以深度学习为主的感知模型中，主流的深度学习训练方法还是监督学习，用这种方法训练，需要向模型“喂养”海量有“真值（Ground Truth）”的数据。
那这些“真值”数据从哪来？人工标注出来的。所以行业里经常开玩笑说，人工智能，就是“有多少人工，就有多少智能”，也因为海量数据标注的需求，还诞生了一个新职业——“人工智能训练师”。
虽然职业名字听起来很好听，但其实，数据标注本质上是一个劳动密集型的产业。为了能够获得足够廉价的劳动力，企业在新疆、河南、山西的某些地区集聚，形成了数据标注的产业集群。
作为客户（标注需求方），他们关心的是标注质量够不够好，标注价格够不够便宜，换句话说，就是“既要马儿跑得快，还要马儿不吃草”。
首先，模型训练对标注数据的质量要求很高，数据质量直接决定了训练出来的模型精度高低，质量不高，很容易“Rubbish In，Rubbish Out”。而标注质量和标注成本密切相关，经济不发达地区的廉价劳动力的标注质量，能否满足开发者们的需求，是一个很大的疑问。
其次，需要标注的数据量巨大，比如一个新的视觉算法通常需要上万张到数十万张不等的标注图片做训练，定期优化也有上千张图片的需求，单张图片标注价格差一点，放在几十万张的体量下就是个很大的数字，因此，需求方对价格很敏感。
高质量的标注要求，必然会导致人力成本上升，而低价格则会影响标注质量，高质量和低价格似乎成了一个难以调和的矛盾。
对车企而言，养几十号人去做数据标注会显得人力成本过于沉重。他们一般更倾向于选择外包给专业的数据标注平台或者数据标注团队去做，比较有名的数据标注平台有百度众测、京东众智、龙猫数据、数据堂等。
不过外包也分为两类：第一类是人力外包，即自己提供标注平台和标注工具，外包公司只需提供人力即可；第二类是服务外包，即自己不提供标注平台和标注工具，直接将待标注数据提供给外包公司，外包公司提供标注好的数据。
部分车企对标注效率要求很高，会选择自己开发标注平台和标注工具，这样他们就会选择人力外包；而对于另一些车企而言，自己开发标注平台显然性价比不高——一方面需要投入那么多资源去开发标注平台，另一方面，自己开发的标注平台和外面的对比价格上又没有优势，不划算。
因为市场需求的爆发，数据标注行业涌现了很多初创公司，data.forge就是其中一家，其创始人兼CEO杨洋向《九章智驾》介绍道：客户最关心的是质量/价格比，为了提升质量/价格比，他们采取了很多措施，比如自动化辅助标注，还有优化标注工具的便利性，这也形成了公司的核心竞争力。
华为内部人员向《九章智驾》介绍时，提到“华为八爪鱼”也提供数据标注服务：“首先，‘华为八爪鱼’花了很多时间打磨自己的预标注算法，目前华为的预标注算法精度已经达到领先水平，在nuScenes、COCO、KITTI等多个自动驾驶国际公开数据集测试挑战中获得第一，预标注算法可以大幅减少每框数据标注所需的时间。
“其次，为优化标注平台的操作，我们会结合具体的业务操作去优化人机交互方式，提升工作人员的操作效率。
“再次，我们有成熟的管理体系来保证标注质量，标注人员标注完成后，经过标注人员的自检、质检员的抽检和标注经理的抽检三重质检流程后，才会交付给客户。与其他标注团队大部分标注人员分布在新疆、河南、山西等地不同，华为的人工标注团队在深圳，就在华为的办公室。之所以这么做，是为了方便沟通和管理，也能更好地保证标注质量。
“最后，为了解决本土开源数据集不足的问题，‘华为八爪鱼’除了能够给客户提供增量的数据标注服务外，还可为客户提供2000万个已标注的对象，而且这个数据集是持续迭代、持续扩充的，客户可以利用这些数据进行训练，快速地搭建起模型。”
作为自动驾驶工具链中非常核心的一环，仿真系统主要由场景库、仿真平台和评测体系三部分组成，仿真系统的效率高低直接影响到了整个开发链路的效率，所以一直是客户的痛点，也是众多玩家瞄准的市场。
也正是因为看到了仿真系统的重要性和不成熟的现状，深感“广阔天地，大有可为”，众多玩家纷纷进入了这个赛道。根据公司类型，这些玩家大致可以分为传统仿真软件公司、初创仿真软件公司和科技巨头仿真软件三类，下面就分类盘点一下。
传统仿真软件以西门子公司的PreScan、德国VIRES公司的VTD、德国IPG公司的CarMaker和美国MSC的CarSim等为代表。他们或凭借某部分领域深厚积累，或因某些功能做的出色，而被广大车企广泛使用：CarMaker和CarSim在车辆动力学领域积累最深、实力最强；VTD以其场景高渲染能力和最先支持OpenX而知名；PreScan以操作方便、上手容易吸引了众多用户。
凭借已有的客户资源加上过去的积累的优势，他们成为了自动驾驶仿真软件领域的重要玩家。
看到了仿真软件巨大的市场空间，不少初创公司新玩家也纷纷进入，希望分一杯羹。比如国内的初创公司51WORLD（原51VR）推出了51Sim-One自动驾驶仿真测试平台；以色列初创公司Cognata，为智能驾驶产品各个阶段提供不同的仿真解决方案，为了满足不同客户的需求，甚至推出了本地版、云版和硬件版本三个版本。
初创公司对市场更敏感，没有历史包袱，其为车企提供的仿真平台，开始有意识打通仿真的各个环节，成为一股不可忽视的力量。
英伟达于2018 年 推出Drive Constellation 仿真系统。该仿真系统由两台不同的服务器打造，第一台服务器运行英伟达 DRIVE Sim 软件来进行传感器仿真，如相机、激光雷达和毫米波雷达，第二台服务器搭载了英伟达 DRIVE Pegasus 人工智能车载计算平台，用来处理仿真的传感器数据。
Drive Sim基于Omniverse平台，据英伟达官方的说法，它可以达到“照片级逼真且物理精确”的传感器仿真。在场景方面，Drive Constellation 可以生成数据流，创建各种测试环境，模拟各种天气条件，以及不同的路面和地形，还可以模拟白天不同时间的眩目强光以及晚上有限的视野。
在自动驾驶开发工具链领域，华为推出了自动驾驶云服务，也称为“华为八爪鱼”（HUAWEI Octopus），从数据采集、难例挖掘、数据标注、算法训练、仿真平台等方面提供了完整的解决方案，并提供了大量的数据集和场景库供客户使用，帮助车企构建数据驱动闭环的自动驾驶开发平台。
另外，基于华为强大的云业务，“华为八爪鱼”集成了云端训练和云端并行仿真，有丰富的仿真场景，高并发实例处理能力，提供超过20万个仿真场景实例；系统每日虚拟测试里程可超过1000万公里，支持3000个实例并发测试。
百度Apollo为开发者提供基于云端的决策系统仿真服务，搭建在百度云和微软Azure上的云仿真平台，轻松打造日行百万公里的虚拟运行能力。在场景库方面，百度Apollo平台提供的场景库涵盖了法规标准场景、危险工况场景和能力评估场景，共计200种左右。
Apollo还与Unity合作，开发基于 Unity 引擎的虚拟仿真环境，提出了端到端的自动驾驶仿真系统——增 强 现 实 的 自 动 驾 驶 仿 真 系 统 AADS，通过模拟交通流来增强现实世界图像，进而创建逼真的仿真场景。
百度开放了自动驾驶数据集ApolloScape，目前已经开放了14.7万帧的像素级语义标注图像，包括感知分类和路网数据等数十万帧逐像素语义分割标注的高分辨率图像数据，以及与其对应的逐像素语义标注。”
腾讯于2018年发布仿真平台 TAD Sim，这是一个结合专业的游戏引擎、工业级车辆动力学模型、虚实一体交通流等技术打造的虚实结合、线上线下一体的自动驾驶仿真平台，可以实现场景的几何还原、逻辑还原及物理还原。
TAD Sim 还支持云端运行，包括场景型云仿真和虚拟城市型云仿真两种模式。城市型云仿真既可以实现加速仿真，也可以实现高并发仿真，满足真实世界中各种场景和驾驶的可能性，加速企业自动驾驶测试进程。场景库中有超过 1000 种场景类型，具备每日1000 万公里以上的测试能力。这些科技巨头做仿真平台，更多的基于其已有的渲染能力、云计算等优势去构建自动驾驶仿真流程，他们更重视云端并行仿真，对场景库也更为重视，也更加有意识地打通上下游各个环节，将自动驾驶系统的测试验证向前推进了一步。
作为自动驾驶开发链路中的一环，仿真需要和其他环节有机地结合在一起。
传统仿真软件，虽然在某些领域很专业，但和上下游链路打通时就很麻烦。
比如，对路测中发现的问题，开发者们当然希望将该场景纳入仿真场景库，后续可以做回归测试，而很多传统软件是不支持这一功能的，只能自己手动去建场景库，手动建场景库的效率很低，一天也建不了几个。
比如，有些传统仿真软件只能在WINDOWS环境运行，而现在自动驾驶开发的环境都是在Ubuntu环境下。
再比如，传统仿真软件的云端并行仿真功能兼容性不好，有些是最近版本才开始兼容云端仿真。据某业内专家透露，因为传统仿真软件是卖License的，几台电脑装这个软件就卖几个License。
随着云端并行仿真发挥越来越大的作用，按照服务收费的SaaS模式对客户显然更加友好，也是后续的发展趋势，传统仿真软件卖License的模式也需要随之调整。
云端并行仿真无疑能大大提升自动驾驶开发效率，华为、百度、腾讯等巨头的仿真平台可以无缝衔接他们的云平台，初创公司51WORLD 的产品也支持并行仿真并支持部署在私有云和公有云上。
而生态型巨头们除了提供仿真软件外，还把仿真平台和其他工具链打通，融入到他们的全栈解决方案中。比如“华为八爪鱼”提供了云端一站式的仿真评测工具链，实现自动驾驶领域的DevOps，从代码仓库接入、版本管理，到仿真、评测，可以实现自动化闭环。这样，车企使用起来，上手更容易，适配成本也更低。
不过这些巨头们也面临一个不小的挑战，那就是由于对车辆动力学模型、汽车核心零部件等硬件方面缺乏足够的积累，这些公司需要通过自研或合作补齐相关的能力。如百度选择自研车辆动力学模型，Apollo 5.0新增了车辆动力学模型；“华为八爪鱼”的仿真系统，则和VTD战略合作，并嵌入了CarMaker的车辆动力学模型。据了解，华为与赛目科技也开始建立合作关系，将在自动驾驶预期功能安全（SOTIF）领域发力。
在数据驱动的开发链路中，数据驱动相当于“题海战术”，考官能做的就是出更多更难的题。在系统开发链路中，场景库便相当于考官出的考题，来评价软件好坏的标准，因此，场景库的数量和质量，直接决定了系统水平的高低。
场景库一般有几种来源：采购自第三方的场景库，市面上能买到的第三方场景库多以标准法规和专家的经验数据为主；针对场景去正向搭建场景库，比如要做泊车功能，就针对泊车设计场景，比较费人力；针对路测中发现的接管事件或者Corner Case，反向生成场景库，相当于考生根据之前错题整理成了自己的“错题本”。
除了这些场景库外，车企还持续不断地通过路测中遇到的Corner case来“扩建”自己的场景库。针对这一需求，有些仿真软件，如“华为八爪鱼”，则提供了“一键将真实路测场景转化为仿真场景”的功能，并且可以在此基础上进行编辑泛化。比如，改变天气环境、周边环境、镜像等手段去泛化出更多的场景，并且华为还提供了虚实混合仿真能力。
所谓虚实混合仿真，就是在云端构建测试场景，再将其加载到车端运行，这样车辆可以在空旷的道路上或封闭场地内，模拟出各种虚拟场景，尤其是行人横穿、非机动车CUT-IN等危险场景，这样就可以测试自动驾驶算法和实车的车辆动力学性能，从而提升测试效率。
仿真评价可能是整个仿真体系中最容易被忽略的部分。
仿真评价主要包括两方面，一方面指当前测试是否可以判定为通过，另一方面指当前测试对应的同场景实车测试的一致性、重复性如何。
如何评价系统能否顺利通过一个场景库的考试呢？考题也出了，考生也做完了，那如何进行“阅卷”，给自动驾驶软件系统打KPI呢？
如果你是考官，你能想到的评价标准有哪些?目标点是否到达？是否安全行驶（没有发生碰撞）？有没有闯红灯？是否急加速急减速？等等。
评价标准随便一想就可以有很多，更让人头痛的是，不同场景对算法考察的侧重点不同，很可能评价标准也是不一样的。场景库千奇百怪，评价标准自然也千差万别。
但总体来说，可以将评价标准分为五大方面：标准匹配性（是否满足标准法规）、驾驶安全性（是否足够安全）、驾驶高效性（是否能够足够高效的到达目的地、燃油经济性）、驾驶舒适性（是否足够舒适）和驾驶智能性（是否足够智能）。
据业内专家透露，每个在场景库在搭建的时候都要“量身订做”通过与否的评价标准。这个时候就需要仿真软件提供多样化的仿真评价标准了，如果不提供的话，相当于在某些方面无法考核到。
因此，各个仿真软件也给客户提前预定义了场景库的评测标准，如“华为八爪鱼”从安全性、舒适性、可靠性、人机交互体验、可用性、合规性、能耗性和通行效率等维度，共开放了200项评价指标。据华为内部人员透露，为让仿真评价更灵活，后续还将支持由客户自己定制开发仿真评价标准。
上文说的仿真平台和上下游工具链打通，都是纵向打通，业内还有一个比较大的痛点，是横向打通时，不同仿真软件之间格式不能兼容。
同一家车企往往会同时使用几种仿真软件，比如可能既用Prescan，又用VTD，每个仿真软件上都会积累一系列场景案例，但是不同的仿真软件制作的场景案例库，格式是相互不能兼容、文件不能通用的。
这其实是因为整个行业的标准化程度不够。
为了解决这个问题，ASAM 发布的仿真领域标准 OpenX 得到了众多车企、供应商和科研机构的认可，目前大多数仿真软件也都开始支持OpenX标准。ASAM正在制定更多的标准。
ASAM仿真格式标准（引用自2020中国自动驾驶仿真蓝皮书）
当下仍有部分仿真软件目前不支持OpenX格式。据业内人士透露：“某些仿真软件公司想把所有的环节掌握在自己手里，让自己具有不可替代性，让客户绑定在自己身上，想换也换不了。这也是以前一些做仿真测试的巨头的惯用的手段。但车企肯定是不能接受的，他们非常不想被绑架，希望做到标准化，减少迁移成本。”毕竟不支持OpenX的还是少数，从整体来看，标准化是大势所趋。相信随着标准化的推进，不久后不同软件之间的文件兼容将不再是问题。
大家都知道，现在很多L2+自动驾驶功能，都会使用高精地图，尤其是对于L4自动驾驶，高精地图将成为重要的基础设施。而对于自动驾驶仿真来说，高精地图也是不可或缺的重要环节。很多仿真场景的构建，比如上文提到的路测场景转化为仿真场景，以及虚实混合仿真都离不开高精地图的支持。
不过高精地图也有很多痛点，首先要解决的是合规性问题。
目前国内只有20多家企业有甲级测绘资质，华为、阿里、腾讯、百度、小米、滴滴都拥有该资质，车企中，上汽中海庭、吉利亿咖通，以及近期收购智途科技的小鹏汽车，也都拥有甲级测绘资质。
四维图新执行总裁白新平曾经对媒体表示：“高精地图必须是有资质的企业参与，资质关系到合规和安全，前期国家在这个领域监管不是太严格，以后会越来越严”。
在这样的背景下，车企的量产方案为了解决合规问题，就会纷纷选择有资质的地图服务商合作。地图服务商需要构建高性能、高可靠、符合安全合规要求的基础设施，能有效支撑海量地图数据的安全存储，还应具备强大的算力资源以及智能算法，对路测数据进行数据脱敏与合规应用的处理，同时系统还要有效支撑第三方合作伙伴开展智能驾驶开发以及地图数据应用服务。
目前头部地图服务商已经覆盖了全国主要的高速公路和快速路，但地图质量仍不容乐观，仍会有漏标和错标的情况。
业内人士告诉九章智驾，某头部地图服务商对高速路段的高精地图覆盖并不完整，尤其是对于进出高速的匝道以及收费站和服务区，会存在偏差或者覆盖不到的情况。
而在和某车企的高精地图负责人沟通时，该负责人告诉九章智驾，他们做L4 Robotaxi测试时，主要场景就是在城市道路，而这部分可以覆盖的地图服务商较少，而且质量和更新频率都不高，他们不得不自己采集和制作高精地图。
因此高精地图不仅要加强高快速路的覆盖，也要重点解决城市通勤场景的覆盖问题，提升复杂路况的精度。这样才能提升高精地图对自动驾驶的支撑作用，同时有效支持城市复杂场景的自动驾驶仿真和测试。
高精地图还需要解决动态更新的问题，否则，数据一旦失去时效性，非但无法有效支撑智能驾驶，还可能带来安全隐患。
目前多位业内人士分析认为，地图众包更新模式，因为从更新及时率和采集成本角度上更具优势，将会成为未来主流技术模式，针对该技术路线，国内相关地图服务商也在不断探索，并开展了相关技术测试。地图众包更新，除了技术上面临不少挑战，例如数据来源多样化，质量参差不齐、采集要素标准未统一、云-端-车链路互通等问题，更面临着国家法律法规方面的制约，这其中涉及敏感地理信息过滤、地图数据加密、个人隐私泄露等风险，需要国家相关部门做进一步的统筹规划。
事实上，解决高精地图的动态更新是一个系统工程，需要多方资源、数据的汇聚和融合，以及云边端的协同，未来将通过地图服务商、智能网联汽车、各类交通参与者、道路基础设施、边缘计算与云端协同，以及交通大数据、路政建设维护数据、道路运营企业等多方合作，实现高精地图动态更新，提升高精地图数据的鲜活度。
在笔者看来，高精地图的制作和更新是一个浩大的工程，如果能形成统一的高精地图要素标准，多方资源统筹协作，减少重复性工作，共同绘制全国一张图，从而大大降低行业成本、提升行业效率和数据可靠性，减少数据安全风险，将是一大幸事。
数据驱动的系统开发中，无论是海量数据的存储、模型的训练还有并行仿真测试，都需要用到大量的IT资源。
业内人士告诉《九章智驾》，自动驾驶系统开发时，会突然遇到一些突发性的算力需求，如模型训练，本地的算力无法满足需求，而走流程采购新的服务器，审批流程可能动辄几个月，很影响开发进度。而据了解，为了应对该需求，某车企智能驾驶开发的子公司，在规划新办公楼时，把整整一层办公楼规划为机房。
不管是存储还是训练，应对这种突发的需求，其实有个非常好的办法，就是——上云。
上云好处有很多，比如云端的开发环境兼容性好，快速弹性扩容能提升开发效率，在成本和数据安全性上也有好处。
相比自建机房，上云的好处
在新冠疫情特殊背景下，数字化转型成了企业生存之道。为应对疫情，企业要实现业务实时在线，将服务场景从线下搬到线上，就要数字化转型，通过云会议、云采购、云销售、云签约等，将员工、客户、服务和流程的全面在线化。
数字化发展程度越高，对企业发展越有利，IDC调研数据发现，数字化指数高的企业，生存能力甚至超过平均水平5倍多。
业内普遍认为，要实现数字化转型，上云是必经之路，甚至是第一步，“数字化必然要先上云”。
上云，更是建立自动驾驶数据闭环开发链路的必要选项。以“华为八爪鱼”对Corner Case的优化链路为例，在车端发生人工接管后，“华为八爪鱼”自动触发并在线反馈至云端，云端进行跟踪回放并诊断确定原因，如果确认是自车责任（自身系统问题），那么数据采集服务会将接管前后的有效数据上传至云端，并进入数据处理流程。
如果是感知环节需要优化，则进行数据采集、清洗、标注，处理完后在云端进行感知模块的训练；如果需要优化规划控制模块，则将该问题场景一键转化为仿真场景库。优化后的算法系统要并行仿真测试和回归测试，若仿真评测也通过，则云端启动OTA推送服务，对车端系统进行升级，如此一个完整的闭环便完成了。
“华为八爪鱼”数据闭环链路
上云，更是自动驾驶从开发测试阶段到商业化的必经之路。
目前，大多数车企还是以开发测试为主，测试车辆数量几台、几十台不等，但是随着测试车辆越来越多，到后续量产后的成千上万台，每天产生的数据量也将由百/千TB的量级提升到10PB级，训练和并行仿真所需要的GPU算力也会从几十个扩展到到上千个，届时上云的需求会变得越来越迫切。
了解完上云的好处，我们再来看下稍微了解下云计算的分类。云一般分为三类：公有云、私有云和混合云。
公有云是非用户所有的基础架构构建的，可以分配给多个租户使用的云，平时最常说的上云，就是指的是公有云，常见的公有云服务商有亚马逊AWS、阿里云、华为云和腾讯云等。
私有云一般是指为单个客户创建的，访问权限归该客户专有，客户可以选择在自己的机房搭建（私有化部署），也可以选择在云服务商的机房内进行托管服务（托管私有云）。
混合云一般可以被看做是私有云和公有云的二者结合体，或者采用不同服务商的公有云。
一般认为，公共云可以快速扩容，更适合需求量大或存在波动的工作负载，而私有云要扩容，则要购买或租借新的硬件和资源，要复杂的多。在自动驾驶开发过程中，一方面随着车辆数的增多，存储的需求量会指数级上升，另一方面开发中也经常会有突发的大算力需求（云端训练或并行仿真等），面对这样的需求，公有云会更合适一些。
从云计算的发展趋势来看，公有云市场占比逐年提升，私有云占比逐年下降。艾媒咨询数据显示，2020年中国云计算市场，公有云规模在2019年超过了私有云，成为了第一的主要市场。
在和《九章智驾》沟通时，车企人员在认可公有云的好处的同时，也提出了担心——数据安全，“我的数据放在公有云上，会不会被别人盗用？”一位车企人员这样说。
正是因为有这样的担忧，很多车企会选择自建服务器，或者选择私有云；部分车企会选择混合云，即企业只将一部分不涉及到数据安全和数据隐私的服务运行在公有云上，而将其他服务运行在私有云里。
一些头部车企和造车新势力，虽然选择公有云，但在选择公有云服务商时选择和自己存在股权关系的服务商，“毕竟是自己人，不用担心数据安全”，他们这样解释。
信任的基础是相互之间的了解、熟悉。很多时候，不信任，就是因为不了解，比如上云。
对于上云的企业而言，其云上数据被妥善地保护，是其最重要也是最基础的安全需求，这也是云服务商赢得客户信任的“生命线”。
根据《阿里巴巴经济体云原生实践》内的介绍，客户对数据安全的要求，可以用信息安全基本三要素"CIA"来概括，即机密性（Confidentiality）、完整性（Integrity）和可用性（Availability）。
机密性专指受保护数据只可以被合法的（或预期的）用户可访问，其主要实现手段包括数据的访问控制、数据防泄露、数据加密和密钥管理等手段；
完整性是保证只有合法的（或预期的）用户才能修改数据，主要通过访问控制来实现，同时在数据的传输和存储中可以通过校验算法来保证用户数据的完整性；
数据的可用性主要体现在云上环境整体的安全能力、容灾能力、可靠度，以及云上各个相关系统（存储系统、网络通路、身份验证机制和权限校验机制等等）的正常工作保障。
在这三方面中，保障机密性（Confidentiality）的最主要的技术手段就是数据加密，而且是全链路的数据加密能力。
“全链路加密”指的是端到端的数据加密保护能力，也是数据全生命周期的加密，主要指的是从云下到云上和云上单元之间的传输过程、到数据在应用运行时的计算过程（处理/交换），和到数据最终被持久化落盘的存储过程中的加密能力。
整体来说，数据加密操作流程是明文数据经由国际国内公认的安全算法计算得出数据密文。在加密操作中，被安全保护和管理的密钥是加密保护的充分而必要的条件。换言之，控制了密钥，也就控制了整体加密操作的主动权。由于用户自带主密钥为用户资源，而任何调用需通过用户授权，用户对于加密后数据的使用有了完全自主的控制权和主动权。同时，任何对于用户资源的调用都会在日志审计中完整的显示出来，因此加密后数据的云上使用透明性也有了更好的保障。
数据安全的生命周期，摘自阿里巴巴经济体云原生实践
诸多业内人士在和《九章智驾》交流的时候，也提到了一点：谁能保证云服务商内部员工或者运维人员不会利用自己的权限去偷偷的使用我的数据？
这其实涉及到合规，需要通过内部流程来保证，而该内部流程往往通过权威第三方的合规认证来确认。其中目前国际上最权威、最被广泛接受和应用的信息安全体系认证是ISO27001，在各大云服务商的官网上也都能查到各自通过的合规认证。
外部的合规认证还要落实到内部的执行，以华为为例，其内部从开发到管理的安全红线都有一系列规定，一旦有人违反，处置很严格，动辄降职、处分、警告，甚至开除等。在聊到合规问题时，该华为内部人士还开玩笑说，美国在开始制裁华为之后，一直倾全力在全球范围找华为“不合规”的“实锤”证据，结果两年多了也没找到，这也从侧面证明了华为在合规性方面做得有多严格，前段时间华为智能车云服务还通过了ASPICE L2第三方认证和大众集团APSICE(KGAS) PN（潜在供应商）审核，这也说明华为智能车云服务的研发质量和开发流程已经被国际主流汽车厂商所认可。
也许，从商业逻辑上来理解会更容易一些。对云服务商来说，客户的数据安全就是命根子，客户把命交给你，一旦出现问题，这份信任就不复存在了，也就失去了商业上的立足点了。而且从云计算本身的架构来说，云上的数据也会更安全：一方面云服务商会做异地容灾的数据备份（防止火灾等自然灾害导致数据丢失），另一方面安全保护等级上也更高（更多的安全人才，采取更多的安全措施）。
虽然对车企来说，上云是大势所趋，但也不会一蹴而就，车企对公有云的理解和接受，需要一个过程。
某公有云市场推广人员告诉《九章智驾》，相对来说，互联网背景的自动驾驶公司和外资车企更愿意上云，传统车企，尤其是国企，在数据方面的担心会更多一些。
从云计算的行业发展趋势上看，不同行业对云的认识程度不同，云计算的渗透率也不同，根据Frost & Sullivan数据显示，当前中国云计算的主要用户集中在对云接触比较早的互联网、金融、政府等领域，其中，互联网相关行业占比约三分之一，政务云目前占比约为29%，交通物流、制造等传统行业云计算应用水平正在快速提高。相信接下来，随着车企对云计算的认识加深和数字化转型的进程加快，对上云的接受度也会越来越高。在不久的将来，上不上云，或许也不再是一个问题。
当前车企在开发自动驾驶系统中，最大的痛点是，工具链的相互分割和数据孤岛。
传统工具链公司和初创公司往往聚焦于工具链的某一个环节，比如做仿真的就做仿真，做标注的就做标注，而车企在使用时，每一部分是作为整个开发工具链中的一环来串联使用的，如果只聚焦于中间的某个环节，难免就会与其他环节“错位”。
并且，当前工具链缺少行业规范，每一家的差别很大，客户不得不花大量的时间去适配，所以车企希望能由一家供应商将工具链的多个环节打通，减少自己的适配成本。也正是看到这个机会，科技巨头们纷纷携“工具链生态”入局，提供了全栈的工具链。
芯片巨头英伟达已围绕车端、桌面端、云端构建了GPU硬件统一架构和CUDA软件架构，开发者可以用很简单的指令调用复杂的深度学习模型。《九章智驾》在和业内专家交流中得知，他们选择英伟达很重要的原因在于，英伟达拥有稳定的工具链和丰富的软件生态。成熟工具链的好处在于，如果出了问题，可以快速定位到问题出在哪。
2017年，英伟达发布了自动驾驶平台NVIDIA DRIVE ，该平台上还搭配了自研的软件架构Drive AV 和 Drive IX。NVIDIA DRIVE 平台的车载智能驾驶控制器。目前上市的有 Xavier 系列，最新 Orin 计划2022年量产上车，并能达到 ISO 26262 ASIL-D 的功能安全标准。
在仿真领域，英伟达于2018 年 推出Drive Constellation 仿真系统和Drive Sim。2019年，英伟达还展示了其高精定位方案 DRIVE Localization，此外，英伟达还在规划高精地图众包方案NVIDIA MapWorks 。目前，英伟达已经和奔驰、奥迪、丰田、沃尔沃、博世、大陆等公司建立了自动驾驶研发合作。
华为坚持“不造车，聚焦ICT技术，帮助车企造好车”的战略，在芯片、云、软硬件、工具链和高精地图等多方面发力，打“组合拳”，形成开放的生态。
华为智能驾驶计算平台MDC集成了华为自研的CPU、AI芯片和其他控制芯片，并通过底层的软硬件一体化调优，使整体性能方面达到业界领先水平。此外，华为MDC也有完整的测试平台和工具链，为MDC的开发提供了全栈解决方案。MDC平台硬件上运行着智能驾驶操作系统AOS/VOS和MDC Core。也就是说，MDC拥有车规级的软硬件，方便车企的量产车型选用。
MDC整体架构图-来自华为MDC白皮书
在自动驾驶开发工具链领域，华为推出了自动驾驶云服务。此外，华为还推出了车联网云服务（智能驾驶、智能座舱数据采集与存储）和三电云服务（三电系统的云端管控）和高精地图云服务。除了这些，华为还“软硬兼施”，布局了自动驾驶传感器。
2017年，百度发布了无人驾驶开放平台阿波罗，向汽车行业及自动驾驶领域的合作伙伴提供一个开放、完整、安全的软体平台，阿波罗平台是一套完整的软硬件和服务系统，包括车辆平台、硬体平台、软体平台、云端数据服务等四大部分，可以帮合作伙伴结合车辆和硬体系统，快速搭建一套属于自己的自动驾驶系统。
后续阿波罗持续升级，分别开放了限定区域视觉高速自动驾驶、自主泊车（Valet Parking）、无人作业小车（MicroCar）、自动接驳巴士（MiniBus）、复杂城市道路的自动驾驶等方案，并开始自建Robotaxi车队，以“萝卜快跑”品牌在各地进行测试运营。
值得一提的是，Apollo发布了中间件Cyber RT，提升了自动驾驶系统的安全性。
Apollo生态开发者提供基于云端的系统仿真服务和增强现实的自动驾驶仿真系统 AADS。
2021年初，百度和吉利合资成立集度汽车，宣布下场造车，李彦宏公开表示“成立集度汽车的目的，就是把百度的自动驾驶技术、智能座舱技术推广到市场”。
腾讯也在布局自动驾驶云生态的开发平台。腾讯不造车，也不造传感器，仅提供软件和服务。
在车端，腾讯提供包含了感知、定位、规划、决策、控制的的解决方案；在云端，基于云端存储及算力支撑，腾讯构建了数据采集管理、样本标注、算法训练评测、诊断调试、云端仿真（仿真平台TAD Sim）、实车反馈闭环全流程云服务，提供支撑自动驾驶研发的全链路云服务和开发平台。
腾讯自动驾驶业务布局和定位（引用自腾讯苏奎峰的线上公开分享）
全栈工具链对于效率的提升是很明显的，尤其是可以快速搭建Pipeline。“华为八爪鱼”内部人员介绍道：如果采用各家公司离散的工具链方案，光调试链路，可能要花几个月的时间，而“华为八爪鱼”，已经针对整个链路做好了集成和适配，减少了重复工作，此外华为还提供给客户一套参考算法，客户可以在此基础上调试优化，大大降低了上手的难度，最快只需要几天就可以跑通整个完整链路，效率很高。
很多车企之所以会选择自研工具链，一方面是出于效率考虑，另一方面还出于“安全”的考虑，车企还想延续自己过去在生态中的掌控地位，而本能地不喜欢潜在的被“卡脖子”的风险，所以往往喜欢和工具链上的小公司合作。
在开放性上，不同的科技巨头策略也不尽相同，据某车厂自动驾驶开发人员透露，某企业自动驾驶开发平台的生态是不解耦的，“如果要选用，就必须‘全盘接受’，不接受单模块使用”，籍此来深度绑定客户；而华为选择了另一条路——各模块解耦。
据华为内部人员介绍，“华为八爪鱼”的工具链分为数据、训练、仿真、监管四部分，这四部分完全开放解耦、不绑定，客户随时可以替换。
对车企来说，如果已有的技术储备不能支持量产方案，要量产就只能外购，这似乎和自研的策略产生了冲突。
在和《九章智驾》交流时，车企开发人员给出的答案出奇的一致：一方面，量产车装的是外采的ADAS解决方案，由于是黑盒采购，供应商并不开放任何数据，但是为了整车的竞争力和销量，车企只能容忍下这“眼前的苟且”；另一方面，车企们同时投入大量人力物力在自研L2+方案上，“一旦自研方案成熟，就会逐步替换上车”，于是自研成了“诗和远方”。
考虑到车企客户的这些诉求，“华为八爪鱼”提供给客户多种合作方案，华为内部人员介绍道：“第一种方案，华为负责开发并提供完整量产解决方案；第二种方案，华为负责开发，客户可自由配置部分参数；第三种方案，华为提供自动驾驶开发工具链，客户自研，华为提供全套售后开发咨询服务。”
本文从自动驾驶开发工具链的角度分析了行业现状和发展趋势。
当前自动驾驶开发工具链行业发展仍不成熟，非标准化和信息孤岛现象比较严重，头部的自动驾驶团队为了开发效率，不得不各自“造轮子”。
不过，随着众多工具链新玩家的进入，整体行业在朝着成熟发展，后续工具链会逐渐开放、标准、规范。尤其是像华为、英伟达等巨头携生态入局，打通了整个开发链路，给行业带来了范例，促进了行业发展，用华为内部人员的话说，这么做是在“拉着中国的自动驾驶产业，不停地往前跑”。
自动驾驶上云是大趋势，随着高等级自动驾驶，正逐渐从技术研究阶段向规模商用阶段演进，除了对存储、算力等资源的要求，还对基础设施服务的高可靠性、安全性以及可拓展性提出了严苛的要求。
传统的数据中心建设模式将为自动驾驶开发企业带来巨大的建设成本和运营维护压力。而公有云通过对多元算力的支持，可满足自动驾驶开发过程中，模型训练和并行仿真对海量基础设施资源极致算力、安全可靠和弹性灵活的业务需求，进而实现自动驾驶算法的敏捷开发与迭代。因此，尽管当前多数企业对公有云的方式还心存疑虑，不过相信随着整个自动驾驶行业的快速发展，以及对公有云认识的持续加深，这种服务模式将会得到进一步推广。
转至：九章智驾
关注微信
