最近自动驾驶和数据闭环结合在一起，原因是自动驾驶工程已经被认可是一个解决数据分布“长尾问题”的任务，时而出现的corner case（极端情况）是是对数据驱动的算法模型进行升级的来源之一，如图所示。

构成这个自动驾驶数据闭环的核心技术和模块都有哪些呢？首先是这个自动驾驶的算法和模块是数据驱动的，其次源源不断的数据需要有合理有效的方法去利用。

如图是Tesla众所周知的Autopilot数据引擎框架：确认模型误差、数据标注和清洗、模型训练和重新部署。

这是谷歌waymo报告提到的数据闭环平台：其中有数据挖掘、主动学习、自动标注、自动化模型调试优化、测试校验和部署发布。

如图是英伟达公司在自动驾驶开发建立的机器学习平台MAGLEV，也是基于闭环的模型迭代：其中有smart的数据选择、数据标注、模型搜索、训练、评估、调试和部署。

下面对数据闭环各个组成部分进一步讨论：

  1. 自动驾驶的数据驱动模型；
  2. 云计算平台的基建和大数据处理技术；
  3. 训练数据标注工具；
  4. 大型模型训练平台；
  5. 模型测试和检验；
  6. 相关的机器学习技术。

1 自动驾驶的数据驱动模型

应该说，自动驾驶的算法模块，基本都是数据驱动的训练模型要优于基于规则或者优化的，尤其是感知和预测。

以下图（综述论文 “A Survey of Autonomous Driving: Common Practices and Emerging Technologies”）为例，现在自动驾驶的开发基本是模块化的（a），只有个别是采用端到端模式（b）。

端到端模式可以说绝对是数据驱动的（如图为例），因为传统的优化和规则方法无法处理如此复杂的系统设计和公式化。

“E2E Learning of Driving Models with Surround-View Cameras and Route Planners”

模块化的方法也是可以采用数据驱动方式，可以分成以下模块：

  • 感知：图像/激光雷达/毫米波雷达
  • 地图+定位
  • 预测（感知-预测）
  • 规划决策（预测-规划）
  • 控制（规划-控制）
  • 传感器预处理
  • 模拟仿真

下面以此分别讨论：

  • 1）感知：2-D/3-D 目标检测和分割基本是采用深度学习模型，无论激光雷达、摄像头或者传感器融合的形式；跟踪基本是tracking-by-detection方式，不过把跟踪和检测集成在一起做深度学习模型也是大家讨论的热点之一。

“Keep your Eyes on the Lane: Real-time Attention-guided Lane Detection”

“M3DSSD: Monocular 3D Single Stage Object Detector”

“PointPillars: Fast Encoders for Object Detection from Point Clouds”

“Joint 3D Proposal Generation and Object Detection from View Aggregation”

”Seeing Through Fog: Deep Multimodal Sensor Fusion in Unseen Adverse Weather“

“Fast and Furious: R-T E2E 3D Detection, Tracking & Motion Forecasting with a Single Cnn”

  • 2）地图定位：车辆定位中基于语义地图的方法，在语义目标提取也是采用深度学习模型，甚至语义地图的制作也是如此，目前感兴趣的地图更新（或者在线地图）多半需要检测语义目标。定位的后端也可以是数据驱动的解决，包括全局定位和相对定位，最近SLAM和深度学习的结合工作也如火如荼进行。

“LCDNet: Deep Loop Closure Detection andPoint Cloud Registration for LiDAR SLAM”

“DeepSFM: Structure From Motion Via DeepBundle Adjustment”

“HDMapNet: An Online HD Map Construction and Evaluation Framework”

  • 3）预测：障碍物的轨迹预测现在已经是自动驾驶发展至今的重点之一，现在重要性可以说是高于感知。如何建模智体行为、如何建模智体之间的交互和轨迹预测的动作多模态性，自然最佳方式是采用数据来训练。另外，感知-预测结合解决也是需要大量数据训练去得到合理的模型。

“Learning Lane Graph Representations for Motion Forecasting”

“PnPNet: End-to-End Perception and Prediction with Tracking in the Loop”

“Deep Multi-Task Learning for Joint Localization, Perception, and Prediction”

“TNT: Target-driven Trajectory Prediction”

  • 4）规划：规划问题可以是传统的规则方法，也可以是强化学习或者模仿学习，其中强化学习也需要数据学习惩罚/奖励和策略。目前人们关心规划的地域化和个性化问题，这个比起感知的类似问题解决起来更加困难，比如激进还是保守地进行换道超车和并道汇入。最近有讨论合并预测和规划的解决方法，甚至包括地图定位一起建模，这个没有数据的“喂养”是很难成立的。

“DSDNet: Deep Structured self-Driving Network”

“End-to-end Interpretable Neural Motion Planner”

“MP3: A Unified Model to Map, Perceive,Predict and Plan”

“Probabilistic Anchor Trajectory Hypotheses For Behavior Prediction”

“VectorNet: Encoding HD Maps and Agent Dynamics From Vectorized Representation”

“Deep Imitation Learning for AV in Generic Urban Scenarios with Enhanced Safety”

“Perceive, Predict, and Plan: Safe Motion Planning Through Interpretable Semantic Rep”

  • 5）控制：应该说，控制的传统方法相对成熟，不过并不是说数据驱动就没有价值，实际上规划和控制的确集成在一起建模也是大家感兴趣的领域，前面提到的强化学习和模仿学习同样是不错的解决手段。

“A Fast Integrated Planning and Control Framework for AV via Imitation Learning”

“Deep Imitative Models For Flexible Inference, Planning, And Control”

  • 6）传感器预处理：在进入感知模块之前，传感器的数据处理，比如污染检测、修补、去噪和增强等，传统的方法也会被数据驱动的机器学习方法取代。

“ZeroScatter: Domain Transfer for Long Distance Imaging and Visionthrough Scattering Media”

  • 7）模拟仿真：模拟仿真需要对车辆/行人、传感器、交通环境和道路环境建模，有时候无法直接获得逼真的合成模型，特别是实际发生的交通事件，有时候不得不采用真实传感器数据来建模合成。下图是GAN-based的雨夜图像合成方法。

“ForkGAN: Seeing into the Rainy Night”

2 云计算平台的基建和大数据处理技术

数据闭环需要一个云计算/边缘计算平台和大数据的处理技术，这个不可能在单车或单机实现的。大数据云计算发展多年，在资源管理调度、数据批处理/流处理、工作流管理、分布式计算、系统状态监控和数据库存储等方面提供了数据闭环的基础设施支持，比如亚马逊AWS、微软Azure和谷歌云等。

Amazon Elastic Compute Cloud（EC2）是亚马逊云服务AWS的一部分，而Amazon Elastic MapReduce（EMR） 是其大数据云平台，可使用多种开放源代码工具处理大量数据，例如数据流处理Apache Spark、数据仓库Apache Hive和Apache HBase、数据流处理Apache Flink、数据湖Apache Hudi和大数据分布式SQL查询引擎Presto。

下图是亚马逊云AWS提供的自动驾驶数据处理服务平台例子：其中标明1-10个任务环节

  1. 使用 AWS Outposts （运行本地 AWS 基础设施和服务）从车队中提取数据以进行本地数据处理。
  2. 使用 AWS IoT Core （将 IoT 设备连接到 AWS 云，而无需配置或管理服务器）和 Amazon Kinesis Data Firehose （将流数据加载到数据湖、数据存储和分析服务中）实时提取车辆T-box数据，该服务可以捕获和转换流数据并将其传输给 Amazon S3（AWS全球数据存储服务）、Amazon Redshift（用标准 SQL 在数据仓库、运营数据库和数据湖中查询和合并 EB 级结构化和半结构化数据）、Amazon Elasticsearch Service（部署、保护和运行 Elasticsearch，是一种在 Apache Lucene 上构建的开源 RESTful 分布式搜索和分析引擎）、通用 HTTP 终端节点和服务提供商（如 Datadog、New Relic、MongoDB 和 Splunk），这里Amazon Kinesis 提供的功能Data Analytics， 可通过 SQL 或 Apache Flink （开源的统一流处理和批处理框架，其核心是分布流处理数据引擎）的实时处理数据流。
  3. 删除和转换低质量数据。
  4. 使用 Apache Airflow （开源工作流管理工具）安排提取、转换和加载 (ETL) 作业。
  5. 基于 GPS 位置和时间戳，附加天气条件来丰富数据。
  6. 使用 ASAM OpenSCENARIO （一种驾驶和交通模拟器的动态内容文件格式）提取元数据，并存储在Amazon DynamoDB （NoSQL 数据库服务）和 Amazon Elasticsearch Service中。
  7. 在 Amazon Neptune （图形数据库服务，用于构建查询以有效地导航高度互连数据集）存储数据序列，并且使用 AWS Glue Data Catalog（管理ETL服务的AWS Glue提供数据目录功能）对数据建立目录。
  8. 处理驾驶数据并深度验证信号。
  9. 使用 Amazon SageMaker Ground Truth （构建训练数据集的标记工具用于机器学习，包括 3D 点云、视频、图像和文本）执行自动数据标记，而Amazon SageMaker 整合ML功能集，提供基于 Web 的统一可视化界面，帮助数据科学家和开发人员快速准备、构建、训练和部署高质量的机器学习 (ML) 模型。
  10. AWS AppSync 通过处理与 AWS DynamoDB、AWS Lambda（事件驱动、自动管理代码运行资源的计算服务平台） 等数据源之间连接任务来简化数据查询/操作GraphQL API 的开发，在此使用是为特定场景提供搜索功能。

下图是AWS给出的一个自动驾驶数据流水线框架：数据收集、注入和存储、模型训练和部署；其中Snowball是AWS的边缘计算系列之一，负责车辆和AWS S3之间的数据传输； 其他还有两个，是AWS Snowcone和 AWS Snowmobile。

可以看到，AWS使用了数据存储S3、数据传输Snowball、数据库DynamoDB、数据流处理Flink和Spark、搜索引擎Elasticsearch、工作流管理Apache Airflow和机器学习开发平台SageMaker等。

其他开源的使用，比如流处理的实时数据馈送平台Apache Kafka、资源管理&调度Apache Mesos和分布NoSQL数据库Apache Cassandra。

如图是国内自动驾驶公司Momenta基于亚马逊AWS建立的系统架构实例图：

其中AWS IoT Greengrass 提供边缘计算及机器学习推理功能，可以实时处理车辆中的本地规则和事件，同时最大限度地降低向云传输数据的成本。

其中P3实例和C5实例是Amazon EC2提供的。Amazon CloudFront是AWS的CDN，Amazon Glacier是在线文件存储服务，而Amazon FSx for Lustre 是可扩展的高性能文件存储系统。

除此之外，亚马逊指出的，Momenta采用的AWS服务还包括：监控可观测性服务Amazon CloudWatch、关系数据库Amazon Relational Database Service (Amazon RDS)、实时流数据处理和分析服务Amazon Kinesis（包括Video Streams、Data Streams、Data Firehose和Data Analytics）和消息队列服务Amazon Simple Queue Service (Amazon SQS)等。

最近Momenta还采用Amazon Elastic Kubernetes Service (EKS) 运行容器Kubernetes。此外亚马逊也推荐了Kubernetes服务，AWS Fargate。

Apache Kafka

Apache Spark

Apache Flink

Apache HBase

Apache Cassandra

Presto

Apache Hudi

Apache Airflow

Apache Mesos

Kubernetes

3 训练数据标注工具

其实AWS的机器学习平台本身也提供了数据标注工具Amazon SageMaker Ground Truth。

如图是微软开源标注工具VOTT（Video Object Tagging Tool）：

microsoft/VoTT​github.com/Microsoft/VoTT/正在上传…重新上传取消

标注工具可以是全自动、半自动和手工等3类。

比如人工标注工具：摄像头图像LabelMe和激光雷达点云PCAT

LabelMe. The Open annotation tool​labelme.csail.mit.edu/Release3.0/正在上传…重新上传取消

halostorm/PCAT_open_source​github.com/halostorm/PCAT_open_source正在上传…重新上传取消

还有半自动标注工具：摄像头CVAT、VATIC，激光雷达3D BAT、SAnE，图像点云融合Latte

openvinotoolkit/cvat​github.com/openvinotoolkit/cvat正在上传…重新上传取消

cvondrick/vatic​github.com/cvondrick/vatic正在上传…重新上传取消

walzimmer/3d-bat​github.com/walzimmer/3d-bat正在上传…重新上传取消

hasanari/sane​github.com/hasanari/sane正在上传…重新上传取消

bernwang/latte​github.com/bernwang/latte正在上传…重新上传取消

自动标注工具：基本没有开源（商用也没有吧）的工具可用。

这里有一些自动标注方面的论文：

  • “Beat the MTurkers: Automatic Image Labeling from Weak 3D Supervision“

  • “Auto-Annotation of 3D Objects via ImageNet“

“Offboard 3D Object Detection from Point Cloud Sequences“

这里是Nvidia在会议报告中给出的端到端标注流水线：它需要人工介入

在这里顺便提一下“数据可视化”的问题，各种传感器数据除了标注，还需要一个重放、观察和调试的平台。如图是Uber提供的开源可视化工具 Autonomous Visualization System (AVS)：

https://avs.auto/#/​avs.auto/#/正在上传…重新上传取消

其中”XVIZ“是提出的自动驾驶数据实时传输和可视化协议：

另外，“streetscape.gl“是一个可视化工具包，在XVIZ 协议编码自动驾驶和机器人数据。 它提供了一组可组合的 React 组件，对 XVIZ 数据进行可视化和交互。

4 大型模型训练平台

模型训练平台，主要是机器学习（深度学习）而言，前面亚马逊AWS提供了自己的ML平台SageMaker。我们知道最早有开源的软件Caffe，目前最流行的是Tensorflow和Pytorch（Caffe2并入）。

Tensorflow

Pytorch

在云平台部署深度学习模型训练，一般采用分布式。按照并行方式，分布式训练一般分为数据并行和模型并行两种。当然，也可采用数据并行和模型并行的混合。

模型并行：不同GPU负责网络模型的不同部分。例如，不同网络层被分配到不同的GPU，或者同一层不同参数被分配到不同GPU。

数据并行：不同GPU有模型的多个副本，每个GPU分配不同的数据，将所有GPU计算结果按照某种方式合并。

模型并行不常用，而数据并行涉及各个GPU之间如何同步模型参数，分为同步更新和异步更新。同步更新等所有GPU的梯度计算完成，再计算新权值，同步新值后，再进行下一轮计算。异步更新是每个GPU梯度计算完无需等待，立即更新权值，然后同步新值进行下一轮计算。

分布式训练系统包括两种架构：Parameter Server Architecture（PS，参数服务器）和Ring -AllReduce Architecture（环-全归约）。

如下图是PS结构图：

这个图是Ring AllReduce的架构图：

Pytorch现在和多个云平台建立合作关系，可以安装使用。比如AWS，在AWS Deep Learning AMIs、AWS Deep Learning Containers和Amazon SageMaker，都可以训练Pytorch模型，最后采用TorchServe进行部署。

Pytorch提供两种方法在多GPU平台切分模型和数据：

  • DataParallel
  • distributedataparallel

DataParallel更易于使用。不过，通信是瓶颈，GPU利用率通常很低，而且不支持分布式。DistributedDataParallel支持模型并行和多进程，单机/多机都可以，是分布训练。

PyTorch 自身提供几种加速分布数据并行的训练优化技术，如 bucketing gradients、overlapping computation with communication 以及 skipping gradient synchronization 等。

Tensorflow在模型设计和训练使用也方便，可以使用高阶 Keras API；对于大型机器学习训练任务，使用 Distribution Strategy API 在不同的硬件配置上进行分布式训练，而无需更改模型定义。

其中Estimator API 用于编写分布式训练代码，允许自定义模型结构、损失函数、优化方法以及如何进行训练、评估和导出等内容，同时屏蔽与底层硬件设备、分布式网络数据传输等相关的细节。

tf.distribute.MirroredStrategy支持在一台机器的多个 GPU 上进行同步分布式训练。该策略会为每个 GPU 设备创建一个副本。模型中的每个变量都会在所有副本之间进行镜像。这些变量将共同形成一个名为MirroredVariable的单个概念变量。这些变量会通过应用相同的更新彼此保持同步。

tf.distribute.experimental.MultiWorkerMirroredStrategy与MirroredStrategy非常相似。它实现了跨多个工作进程的同步分布式训练，而每个工作进程可能有多个 GPU。与MirroredStrategy类似，它也会跨所有工作进程在每个设备的模型中创建所有变量的副本。

tf.distribute.experimental.ParameterServerStrategy支持在多台机器上进行参数服务器PS训练。在此设置中，有些机器会被指定为工作进程，有些会被指定为参数服务器。模型的每个变量都会被放在参数服务器上。计算会被复制到所有工作进程的所有 GPU 中。(注：该策略仅适用于 Estimator API。)

5 模型测试和检验

模型的测试和检验可以分成多种方式：

一是仿真测试检验。建立仿真测试环境，比如开源的一些软件平台：

  • Carla

https://github.com/carla-simulator/carla​github.com/carla-simulator/carla

  • AirSim

https://microsoft.github.io/AirSim/​microsoft.github.io/AirSim/

  • LGSVL

SVL Simulator by LG - Autonomous and Robotics real-time sensor Simulation, LiDAR, Camera simulation for ROS1, ROS2, Autoware, Baidu Apollo. Perception, Planning, Localization, SIL and HIL Simulation, Open Source and Free.​www.svlsimulator.com/

还有一些成熟的商用软件，也可以构建仿真测试环境：Prescan和VTD。存在一些仿真子模块，比如开源的交通流仿真方面SUMO，商用的动力学仿真方面CarSim、Trucksim和Carmaker等。测试方式包括模型在环（MIL）、软件在环（SIL）、硬件在环（HIL）和整车在环（VIL）等。传感器的仿真，特别是摄像头的图像生成，除了图形学的渲染方式，还有基于机器学习的方式。

这里列出Uber ATG发表的一系列仿真建模论文：

  • “LiDARsim: Realistic LiDAR Simulation by Leveraging the Real World“

  • ”S3: Neural Shape, Skeleton, and Skinning Fields for 3D Human Modeling“

  • ”SceneGen: Learning to Generate Realistic Traffic Scenes“

  • ”TrafficSim: Learning to Simulate Realistic Multi-Agent Behaviors“

  • ”GeoSim: Realistic Video Simulation via Geometry-Aware Composition for Self-Driving“

  • “AdvSim: Generating Safety-Critical Scenarios for Self-Driving Vehicles“

另外谷歌Waymo最近推出的传感器仿真工作：

  • ”SurfelGAN: Synthesizing Realistic Sensor Data for Autonomous Driving“

二是封闭场地的实车测试检验。各大车企都有自己的测试基地，现在自动驾驶方面也可使用。其开销远大于仿真系统。

谷歌waymo测试场

三是开放场地的测试检验。现在好多L4级别的自动驾驶，比如无人出租车/无人卡车/无人送货，都在做这种政府批准的实际驾驶实验区测试。这种测试，必要时候安全员的接管或者遥控接管，都是需要花费大量投入的。

GM的自动驾驶公司Cruise在旧金山测试

最后是用户的测试检验。这个是特斯拉特有的影子模式，以及FSD beta版本测试的志愿者模式。

特斯拉的“Operation Vacation”模式

如图是英伟达报告描述的车队级别的模型部署闭环：

6 相关的机器学习技术

最后，谈一下数据闭环所采用的机器学习技术，其实就是选择什么训练数据和如何迭代更新模型的策略。主要有以下几点：

  • 主动学习
  • OOD检测和Corner Case检测
  • 数据增强/对抗学习
  • 迁移学习/域自适应
  • 自动机器学习（AutoML ）/元学习（学习如何学习）
  • 半监督学习
  • 自监督学习
  • 少样本/ 零样本学习
  • 持续学习/开放世界

下面分别讨论：

1）主动学习

主动学习（active learning）的目标是找到有效的方法从无标记数据池中选择要标记的数据，最大限度地提高准确性。主动学习通常是一个迭代过程，在每次迭代中学习模型，使用一些启发式方法从未标记数据池中选择一组数据进行标记。因此，有必要在每次迭代中为了大子集查询所需标签，这样即使对大小适中的子集，也会产生相关样本。

如图是一个主动学习闭环示意图：在无标注数据中查询、标注所选择数据、添加标注数据到训练集和模型训练。

一些方法把标注和无标注数据放在一起，故此采用监督学习和半监督学习进行训练。

贝叶斯主动学习方法通常使用非参数模型（如高斯过程）来估计每个查询的预期进步或一组查询后的预期错误。

基于不确定性主动学习方法尝试使用启发式方法，比如最高熵，和决策边界的几何距离等来寻找困难例子（hard examples）。

如图是英伟达基于主动学习的挖掘数据方法：

还有其他的主动学习实例方法：

  • “Deep Active Learning for Efficient Training of a LiDAR 3D Object Detector“

  • “Consistency-based Active Learning for Object Detection“

2）OOD检测和Corner Case检测

机器学习模型往往会在out-of-distribution（OOD) 数据上失败。 检测OOD是确定不确定性（Uncertainty）的手段，既可以安全报警，也可以发现有价值的数据样本。

不确定性有两种来源：任意（aleatoric）不确定性和认知（epistemic）不确定性。

导致预测不确定性的数据不可减（Irreducible）不确定性，是一种任意不确定性（也称为数据不确定性）。任意不确定性有两种类型：同方差（homo-scedastic）和异方差（hetero-scedastic）。

另一类不确定性是由于知识和数据不适当造成的认知不确定性（也称为知识/模型不确定性）。

最常用的不确定性估计方法是贝叶斯近似（Bayesian approximation）法和集成学习（ensemble learning）法。

一类 OOD 识别方法基于贝叶斯神经网络推理，包括基于 dropout 的变分推理（variational inference）、马尔可夫链蒙特卡罗 (MCMC) 和蒙特卡罗 dropout等。

另一类OOD识别方法包括 (1) 辅助损失或NN 架构修改等训练方法，以及 (2) 事后统计（post hoc statistics）方法。

数据样本中有偏离正常的意外情况，即所谓的corner case。可靠地检测此类corner case，在开发过程中，在线和离线应用都是必要的。

在线应用可以用作安全监控和警告系统，在corner case情况发生时进行识别。离线应用将corner case检测器应用于大量收集的数据，选择合适的训练和相关测试数据。

最近的一些实例工作有：

  • “Towards Corner Case Detection for Autonomous Driving“

  • “Out-of-Distribution Detection for Automotive Perception“

  • “Corner Cases for Visual Perception in Automated Driving: Some Guidance on Detection Approaches“

3）数据增强/对抗学习

过拟合（Overfitting）是指当机器学习模型学习高方差的函数完美地对训练数据建模时出现的现象。数据增强（Data Augmentation）增强训练数据集的大小和质量，克服过拟合，从而构建更好的机器学习模型。

图像数据增强算法包括几何变换、色彩空间增强、内核过滤器、混合图像、随机擦除、特征空间增强、对抗训练（adversarial training）、生成对抗网络（generative adversarial networks，GAN）、神经风格迁移（neural style transfer）和元学习（meta-learning）。

激光雷达点云数据的增强方法还有特别的一些：全局变换（旋转、平移、尺度化）、局部变换（旋转、平移、尺度化）和3-D滤波。

对抗性训练可以成为寻找增强方向的有效方法。通过限制对抗网络（adversarial network）可用的增强和畸变变换集，通过学习得到导致错误的增强方式。这些增强对于加强机器学习模型中的弱点很有价值。

值得一提的是，CycleGAN 引入了一个额外的 Cycle-Consistency 损失函数，稳定 GAN 训练，应用于图像到图像转换（image-to-image translation）。实际上CycleGAN 学习从一个图像域转换到另一个域。

机器学习模型错误背后的一个常见原因是一种称为数据集偏差或域漂移（dataset bias / domain shift）的现象。 域适应方法试图减轻域漂移的有害作用。对抗训练方法引入到域适应，比如对抗鉴别域适应方法(Adversarial Discriminative Domain Adaptation，ADDA)。

最近出现的一些新实例方法：

  • “AutoAugment: Learning Augmentation Strategies from Data“

  • “Classmix: Segmentation-based Data Augmentation For Semi-supervised Learning“

  • “Data Augmentation for Object Detection via Differentiable Neural Rendering“

  • “LiDAR-Aug: A General Rendering-based Augmentation Framework for 3D Object Detection“

  • “Adaptive Object Detection with Dual Multi-Label Prediction“

  • “Taking A Closer Look at Domain Shift: Category-level Adversaries for Semantics Consistent Domain Adaptation“

4）迁移学习/域适应

迁移学习(transfer learning，TL)不需要训练数据和测试数据是独立同分布(independent and identically distributed，i.i.d)，目标域的模型不需要从头开始训练，可以减少目标域训练数据和时间的需求。

深度学习的迁移技术基本分为两种类型，即非对抗性的（传统）和对抗性的。

域适应 (domain adaptation，DA) 是TL的一种特殊情况，利用一个或多个相关源域（source domains）的标记数据在目标域（target domain）执行新任务。

DA方法分为两类：基于实例的和基于特征的。

最近出现的一些新实例方法：

  • “Multi-Target Domain Adaptation via Unsupervised Domain Classification for Weather Invariant Object Detection“

  • “Uncertainty-Aware Consistency Regularization for Cross-Domain Semantic Segmentation“

  • “SF-UDA3D: Source-Free Unsupervised Domain Adaptation for LiDAR-Based 3D Object Detection“

  • “LiDARNet: A Boundary-Aware Domain Adaptation Model for Point Cloud Semantic Segmentation“

5）自动机器学习（AutoML）/元学习（学习如何学习）

一个机器学习建模的工程还有几个方面需要人工干预和可解释性，即机器学习落地流水线的两个主要组件：预-建模和后-建模（如图）。

预-建模影响算法选择和超参数优化过程的结果。 预-建模步骤包括多个步骤，包括数据理解、数据准备和数据验证。

后-建模模块涵盖了其他重要方面，包括机器学习模型的管理和部署。

为了降低这些繁重的开发成本，出现了自动化整个机器学习流水线的新概念，即开发自动机器学习（automated machine learning，AutoML) 方法。AutoML 旨在减少对数据科学家的需求，并使领域专家能够自动构建机器学习应用程序，而无需太多统计和机器学习知识。

值得特别一提的是谷歌方法“神经架构搜索”（Neural Architecture Search，NAS），其目标是通过在预定义搜索空间中选择和组合不同的基本组件来生成稳健且性能良好的神经网络架构。

NAS的分布式训练实现

NAS的总结从两个角度了解：模型结构类型和采用超参数优化（hyperparameter optimization，HPO）的模型结构设计。最广泛使用的 HPO 方法利用强化学习 (RL)、基于进化的算法 (EA)、梯度下降 (GD) 和贝叶斯优化 (BO)方法。

如图是AutoML在机器学习平台的应用实例：

注：在谷歌云、微软云Azure和亚马逊云AWS都支持AutoML。

深度学习（DL）专注于样本内预测，元学习（meta learning）关注样本外预测的模型适应问题。元学习作为附加在原始 DL 模型的泛化部分。

元学习寻求模型适应与训练任务大不相同的未见过的任务（unseen tasks）。元强化学习 (meta-RL) 考虑代理与不断变化的环境之间的交互过程。元模仿学习 (Meta-IL) 将过去类似的经验应用于只有稀疏奖励的新任务。

元学习与 AutoML 密切相关，二者有相同的研究目标，即学习工具和学习问题。现有的元学习技术根据在 AutoML 的应用可分为三类：

  • 1）用于配置评估（对于评估者）；
  • 2）用于配置生成（用于优化器）；
  • 3) 用于动态配置的自适应。

元学习促进配置生成，例如，针对特定学习问题的配置、生成或选择配置策略或细化搜索空间。元学习检测概念漂移（concept drift）并动态调整学习工具实现自动化机器学习（AutoML）过程。

6）半监督学习

半监督学习（semi-supervised learning）是利用未标记数据生成具有可训练模型参数的预测函数，目标是比用标记数据获得的预测函数更准确。由于混合监督和无监督方法，半监督学习的损失函数可以具有多种形状。 一种常见的方法是添加一个监督学习的损失项和一个无监督学习的损失项。

已经有一些经典的半监督学习方法：

  • “Pseudo-label: The simple and efficient semi-supervised learning method for deep neural networks”
  • “Mean teachers are better role models: Weight-averaged consistency targets improve semi-supervised deep learning results“
  • “Self-training with Noisy Student improves ImageNet classification“

最近出现一些新实例方法：

  • “Unbiased Teacher for Semi-Supervised Object Detection“

  • “Pseudoseg: Designing Pseudo Labels For Semantic Segmentation“

  • “Semantic Segmentation of 3D LiDAR Data in Dynamic Scene Using Semi-supervised Learning“

  • “ST3D: Self-training for Unsupervised Domain Adaptation on 3D Object Detection“

  • “3DIoUMatch: Leveraging IoU Prediction for Semi-Supervised 3D Object Detection“

7）自监督学习

自监督学习（self supervised learning）算是无监督学习的一个分支，其目的是恢复，而不是发现。自监督学习基本分为：生成（generative）类, 对比（contrastive）类和生成-对比（generative-contrastive）混合类，即对抗（adversarial）类。

自监督使用借口任务（pretext task）来学习未标记数据的表示。借口任务是无监督的，但学习的表示通常不能直接给下游任务（downstream task），必须进行微调。因此，自监督学习可以被解释为一种无监督、半监督或自定义策略。下游任务的性能用于评估学习特征的质量。

一些著名的自监督学习方法有：

  • “SimCLR-A Simple framework for contrastive learning of visual representations“
  • “Momentum Contrast for Unsupervised Visual Representation Learning“
  • “Bootstrap Your Own Latent: A New Approach to Self-Supervised Learning“
  • “Deep Clustering for Unsupervised Learning of Visual Features“
  • “Unsupervised Learning of Visual Features by Contrasting Cluster Assignments“

注意最近的一些新方法：

  • “DetCo: Unsupervised Contrastive Learning for Object Detection“

  • “PointContrast: Unsupervised Pre-training for 3D Point Cloud Understanding“

  • “MonoRUn: Monocular 3D Object Detection by Reconstruction and Uncertainty Propagation“

  • “Weakly Supervised Semantic Point Cloud Segmentation: Towards 10x Fewer Labels“

8）少样本/零样本学习

零样本学习（Zero-shot learning，ZSL）旨在识别在训练期间可能未见过实例的目标。虽然大多数ZSL方法都使用判别性损失（discriminative losses）进行学习，但少数生成模型（generative models）将每个类别表示为概率分布。

对于未见类（unseen classes），ZSL除了无法访问其视觉或辅助信息的inductive设置之外，transductive方法无需访问标签信息，直接用已见类（seen classes）和未见类一起的视觉或语义信息。

ZSL属于迁移学习（TL），源特征空间为训练实例，目标特征空间为测试实例，二者特征空间一样。 但对于已见类和未见类，标签空间是不同的。

为了从有限的监督信息中学习，一个新的机器学习方向称为少样本学习 (Few-Shot Learning ，FSL)。基于如何使用先验知识，FSL可分为三个类：1）用数据先验知识来增强监督经验，2）通过模型先验知识约束假设空间，和3）用算法先验知识改变假设空间中最佳参数的搜索方式。

FSL 可以是监督学习、半监督学习和强化学习（RL），取决于除了有限的监督信息之外还有哪些数据可用。许多 FSL 方法是元学习（meta learning）方法，以此作为先验知识。

最近的一些实例方法：

  • “Don’t Even Look Once: Synthesizing Features for Zero-Shot Detection“

  • “Zero-Shot Semantic Segmentation“

  • “Zero-Shot Learning on 3D Point Cloud Objects and Beyond“

  • “Few-Shot Object Detection and Viewpoint Estimation for Objects in the Wild“

  • “Self-Supervised Few-Shot Learning on Point Clouds“

  • “Few-shot 3D Point Cloud Semantic Segmentation“

9）持续学习/开放世界

持续学习（ continual learning）可以不断积累不同任务得到的知识，而无需从头开始重新训练。其困难是如何克服灾难遗忘（catastrophic forgetting）。

如图是持续学习的方法分类：经验重放（ER）、正则化和参数孤立三个方向。

开放集识别（Open set recognition，OSR），是在训练时存在不完整的世界知识，在测试中可以将未知类提交给算法，要求分类器不仅要准确地对所见类进行分类，还要有效处理未见类。开放世界学习（Open world learning）可以看作是持续学习的一个子任务。

以下给出最近的一些实例方法：

  • “Lifelong Object Detection“

  • “Incremental Few-Shot Object Detection“

  • “Towards Open World Object Detection“

  • "OpenGAN: Open-Set Recognition via Open Data Generation"

  • “Large-Scale Long-Tailed Recognition in an Open World“

数据闭环的关键是数据，同时采用数据驱动的训练模型是基础。决定了整个自动驾驶迭代升级系统的走向是：

  • 数据的模式（摄像头/激光雷达/雷达，无/导航/高清地图，姿态定位精度，时间同步标记）；
  • 数据驱动模型（模块/端到端）；
  • 模型的架构（AutoML）；
  • 模型训练的策略（数据选择）。

工程化

前言

这篇文章的重点不在于具体的软件架构，而在于软件架构的工程化落地。因为再好的架构，也需要变成真正可以稳定运行的产品才能体现其价值。而自动驾驶相关的软件系统关联了非常多的技术领域，每个技术领域有专门的知识体系，需要专门的人才，需要解决特定的问题。而完整的自动驾驶系统是需要所有相关的技术一起协同工作的，任何一个领域在技术或工程上的短板，都将影响整个系统的可用性、可靠性、安全性。

同时在研发组织上，也需要让不同领域的技术团队能够独立的开发、独立测试验证，最后还能集成在一起。那么如何拆得开、拆得好，还能整合起来，就是工程落地过程中至关重要的顶层设计问题。

第1章叙述闭环的抽象概念以及研发闭环的界定。阐述如何依据最小变量原理来拆解研发闭环，使得复杂系统的研发及集成过程可控。

第2章叙述产品概念上的闭环思路。自动驾驶作为跨多个技术领域的复杂产品，很难一步到位解决所有问题。本章从产品角度出发，提出纵横交叉的产品演进路线，使得自动驾驶系统工程化道路上的每一步的难度降低，也让整个系统能在早期就开始逐步集成，提高整体工程化成功的可能性。

第3章是本文的重点。目的是阐述数据驱动闭环的基本原理以及方法论。

这一章中，我们先给出数据概念模型及其分析，重点阐明语义层级的概念。然后我假设一个AEB 的技术方案，作为我们讨论的功能范围的锚定点。基于概念模型，分析这个技术方案涉及算法的语义层级分解。

我们再给出智能驾驶系统集成的一般原理，分别阐述“算法串接、执行平台、数据规模”三个集成纬度的各自概念和相互组合关系。并将这个一般原理应用到 AEB 方案的系统集成上，给出一个参考的 AEB 功能的系统集成路径。这个集成路径上涉及了大量的工具链，我们重点分析了其中的仿真测试工具链，并对不同的仿真和测试的手段做了对比，分析其各自的用途和侧重点。至此，用于数据驱动闭环的技术基本设施叙述完毕。在此基础上，我们论述了如何基于这些技术设施，利用大量数据从算法开发和测试验证两个方面驱动AEB产品完成工程化落地。虽然 AEB 功能实际对量产开发并不需要把所有上述过方法论严格实施。但是这个方法论是迈向更高阶功能的基础。我们以 Level 2.5 和 Level 4 为例阐明该方法论的进一步应用。

最后，我们分析了什么是自动驾驶的核心技术：“算法能力”和“工程化能力”缺一不可。目前自动驾驶技术在实际应用中在这两方面都遇到了很大程度的困难，于是采取了很多手段规避这些困难，从而衍生出各种弱化版本的自动驾驶场景。本章对这些场景在算法能力和工程化难度两个纬度做了分析和比较。一方面可以了解产业图景背后的技术原因，一方面也可以直观的理解建立工程化能力的难度及重要性。

本文为个人产品与研发经验的总结，不代表任何企业或组织的观点，仅仅分享出来供行业同仁参考。受个人水平与视野限制，文中难免有疏漏谬误之处，欢迎业内同仁指正，共同探讨。

本文的读者

本文的目标读者为从事自动驾驶系统研发的相关人员，包括产品经理、系统工程师、架构师 、算法工程师、软件工程师、数据工程师、测试经理、项目经理等角色。本文的重点不在自动驾驶的算法，而在于如何实现工程化落地。对于自动驾驶领域的投资人，本文也有参考意义，方便投资人理解和评估自动驾驶企业的落地能力。

为了让更多人能理解工程化的方法论，本文尽量避免采用过于专业的术语，用到的术语也会在首次出现时定义它在本文中的含义，以避免歧义而影响理解。本文也不会叙述具体算法的细节原理和实现方式，因此对于行业内的大部分人，投入一定的专注力，应该都可以理解本文的主旨。

版权声明

本文作者为萧猛。本文的电子版本允许任何不以盈利为目的的使用、复制和再分发。要求在分发过程中保留此版权声明的全文。否则视为对本文著作权的侵犯，将会承担相应的法律责任。以盈利为目的的使用请与本人联系。

感谢

本文写作过程中曾与很多业内人士进行沟通交流。感谢东风技术中心数字化部林斯团总工，多次讨论中给了我很多启发与帮助；感谢真点科技 CTO 袁宏先生在 NRTK 定位算法方面的解惑以及关于自动驾驶路权方面的指导。也感谢许多领导和同事在本文写作过程中给予的帮助和支持。

数据驱动的闭环

随着高阶自动驾驶逐步进入现实，数据闭环的概念越来越受到重视，很多自动驾驶研发公司和 OEM 都想建立自己的数据闭环体系。但是究竟要达到一个什么样的状态才叫数据闭环，数据闭环如何设计、如何实施又往往很难有一个明确的说法。

这里有一个关键点概念很容易被人忽视，“产品规划的闭环、研发和测试的闭环才是自动驾驶研发工程化的内在需求，而数据是驱动这个闭环运转的技术要素”。

前面两章讨论了研发测试的闭环与产品规划的闭环，核心思想是尽量从小的闭环开始，逐步叠加到完整的系统闭环，以从简单的到复杂逐步递进的方式构建大型系统，这是工程化的方式。这是从产品和研发的视角看待闭环系统。然而不管是大的闭环还是小的闭环，都是需要通过数据对其进行驱动，小闭环叠加成大闭环的过程，也是多样化的数据逐步进入系统并协同驱动大系统工作的过程，所以本章从数据的视角来讨论闭环系统。数据闭环的正确说法应该是数据驱动的闭环。

直接讨论整体的数据闭环很难说清楚，我们依然从小闭环开始讨论如何进行数据驱动。不同类型的闭环，由于其闭环标的不同，其中流转的数据也有非常大的不同。

要分析清楚一个数据驱动的闭环，需要搞清楚以下问题：

  • 数据闭环语境下的数据到底是什么（数据的概念）
  • 在闭环中需要什么数据，数据的作用是什么
  • 数据如何生产
  • 数据在使用前如何被加工
  • 感知类数据，如何获取真值（Grand Truth）
  • 数据如何在闭环中流转，需要哪些工具来支持数据的流转

这一章先分析基础的“数据概念模型”，然后再通过几个典型的案例来分析其数据如何驱动闭环的执行。

3.1.数据概念模型

既然讨论数据驱动的闭环，那我们先把“数据”的概念搞清楚。本文说讲的“数据”是指与自动驾驶系统的研发与运行相关的信息元素，图 12展示了数据的抽象概念模型。理解了这个概念模型，就能更容易理解数据是如何被生产、加工和使用的。

此图的符号语义是基于 UML 类图，基本的符号语义请参照我在《中间件与 SOA》3.1.1节中的简单描述。图中淡蓝色框内的是数据概念模型，外围是具体的数据类别和关联的工具平台。

我们可以从很多方面去描述一个数据的属性，对于自动驾驶系统中的数据，我们可以关注分类、语义层级、生产方式、使用方式（图中从“数据”引出去的四个概念）。从另一个角度看，这几个关注点描述了数据“是什么，从哪来，到哪去”三个问题。

关于分类，数据可以有很多种不同的分类方式，比如按照跟自车的关系，分为自车数据或环境数据；按数据的物理采样方式分为图像数据、雷达信号等等，采用什么分类方式并没有固定的标准，是根据实际对数据利用的上下文来选择。

图 12 数据的概念模型

图中淡蓝色框内的是数据概念模型，外围左侧列举了一些具体的数据形式，其它红色是关联的工具平台。左侧具体的数据形式只画出了语义层级，但是每种数据都会有概念模型中语义提升、生产方式、使用方式等概念的具体体现。图中限于布局不容易表示，后文中都会详细说明。

这里我们先重点说明“语义层级”概念，它对于自动驾驶系统的数据是非常核心的属性，很多数据处理动作实际上就是在提升数据的语义层级。

语义层级

“语义”是我们从某个信息媒介中所提取的高阶信息含义。比如一张报纸，其物理层面是纸张上分布着油墨，人读报纸，能从油墨的分布中其中的的含义，这就是语义提取。NLP（自然语言理解）可以认为是计算机自动从文字中提取语义。

语义是有层级的，语义层级并没有标准化的定义，本文根据实践经验给出自己的定义。

“零级语义”就是没有语义的原始物理信号。如摄像头的原始像素点集合，激光雷达的点云，雷达收到的电磁信号经过采样之后的原始数据。

“一级语义”级是根据原始物理信号计算出来的属性特征，有明确的“是什么、有多少、可以/不可以”等含义。比如带计量单位或物理量纲的速度、距离、位置等；车辆、行人、车道线等目标分类；交通标志的限行、限速、禁止掉头，可行驶区域分割等。

“二级语义”是在一级语义上的进一步加工，有一下几种可能情况

  • 两个2级语义的组合，如车在某个车道，两个传感器的后融合。
  • 时空两个维度同时具备，如历史轨迹，目标跟踪。

“三级语义”对目标意图的识别与判断，如当前行为意图，行为预测，轨迹预测

“四级语义”多个交通参与者在特定道路环境下一段时间内的行为

举例来说，摄像头输出的一帧图像，如下图：

图 13 非法掉头的示例场景

图像本身实质上是 YUV 或 RGB 格式保存的一段二进制数据，记录里每一个像素点的光学采样值。这是没有任何语义信息的，是零级语义。

通过人眼识别或者 AI 算法识别，我们从这一帧图像中提取出一辆乘用车、车道双黄线、还有“禁止掉头”的交通标志，这是几个独立的一级语义，互相之间没有关联起来。

根据车辆和车道线的相对位置，我们可以车辆压线，这是两个一级语义的组合。可以认为是二级语义。继续叠加双黄线的交通规则信息，可以认为车辆已经非法压线了；再叠加禁止掉头的语义，可以认为这是非法掉头。

假如对向车道有一辆车正在向图上的白车行驶过来，我们能测出其速度。那我们还能作出预测，这两辆车可能会相撞。这已经不是多个独立的一级语义叠加了，而是多个目标可能的关联分析，这可以认为是三级语义了。

图 12中并没有画三级之上的高层语义，本文也不打算去定义更高层的语义，第三级语义的定义也值得商榷。因为语义分层的目的体现在工程上是给不同算法的能力划定边界，分层的方式也确定的各层算法独立进行闭环测试的闭环分解方法。比如，我可以单独为某个零级提升到一级语义的算法设计测试闭环，同时还可以直接提供一级的真值给另一个算法，它负责提取出二级语义。所以你完全可以根据你的算法集和的规划去定义自己的语义分级规则。语义分层是为了可以进行工程化的闭环测试。

语义提升

前面例子中从低级语义逐步提取到高级语义的过程就是语义提升。（图 12中零级语义和一级语义中有一根线连接到“语义提升”，这在UML语义中表示关联类，就是说“语义提升”是跟两个高低语义层级相关）。人眼在看图 13 时这个语义提升的过程是瞬间完成，人也不会意识到会有这个逐级提升的过程。但是在计算机来执行语义提升的时候，确实不同的类型的数据，不同层级的提升方法都有很大的差别。

图 12中画出来三种语义提升的方式，人工智能(AI) ，人工标注，数字信号处理，还可以有更多的语义提升方式。这三个是比较具有典型性，数字信号处理主要是在对雷达原始数据的处理上，已经发展了很多年，图像和激光雷达点云采用深度学习等人工智能技术成为了主流。“人工标注”实际上就是一种语义提升的方式，它一样可以用在不同的语义层级之间。

“语义提升”对于低级语义来说是数据的使用方式，对于高级语义来说，是数据的生产方式。最直接的数据生产方式就是“数据采集”，直接采集原始数据。

真值系统

目前感知层面的深度学习主要是以监督学习为主，监督学习就需要数据的真值来进行训练。不同类型的数据，不同类型的算法训练，其真值形式也有很大差别。产生真值的系统称为“真值系统”。我们在设计生产用于 AI 训练数据的同时，也必须设计获取其真值系统。

真值系统至少有三种：1.人工标注2.用更高精度的测量工具的结果作为低精度工具的真值3.仿真软件直接输出真值

第1种就是靠人力去标注，比如百度就建设有上万人的标注基地，为很多自动驾驶公司提供标注服务。第2种，比如我们可以用激光雷达算法输出的结果作为视觉算法的真值，前提是激光雷达算法的精度足够。仿真软件的真值是可以直接输出的，这在我们设计测试闭环的时候非常有用，可以让我们在算法成熟之前就建立起算法或其它软件模块的测试闭环。

为数据生产服务的工具平台

各级语义数据的生产，算法的开发，离不开一系列的工具平台的支持。清楚了数据的抽象概念模型，也就能更清楚的理解工具平台的作用。相关的工具平台如图 12所示：

数据采集系统要支持各种传感器数据车身数据的实施采集，支持每天10T 级别的数据采集量，还要保证各种数据的时钟同步。

数据标注需要标注工具与平台，提供各种类型的数据标注功能、支持标注质检，支持成千上万人分布式工作、对任务和人员进行调度管理。

要为各种不同类型的数据，提供符合算法要求的真值系统。

AI 训练平台要能支持成百上千的计算卡进行分布式训练。

测试仿真平台要能利用各种语义层级的数据形成多样化的测试闭环。

需要一个统一的数据管理平台对数据从导入、存储、清洗、加工、筛选、利用进行全生命周期的管理。

这些相关的工具平台也会在后文的合适章节单独进行论述。

3.2.假设的系统方案

AEB （Autonomous Emergency Braking）是典型的 L1功能，就是自动紧急制动，避免撞上前方的车辆、行人或其他障碍物，或者至少降低速度后，减少撞击之后的伤害。当然这只是非常简单的描述，详细的功能描述可以写出500页出来，这里不多说。

我们假设一个能支持 AEB 功能的系统方案，包含简明的软硬件架构，这个方案有最足够的传感器和足够的计算能力，不过我们只关注 AEB 一个功能。但尽可能穷举出所有可以细分的工程环节，包含各独立子产品开发、分步集成、仿真测试、量产后根据回传数据持续迭代等。

这个系统方案不会出现在任何企业的实际产品中，因为方案的硬件配置只实现一个 AEB 功能从成本来说太不划算，过于细分的工程环节只用于开发一个功能太过奢侈。

这个案例的意义在于可以提供一个方法论模板，让我们先不陷入复杂的自动驾驶功能里，而是从开发单一功能的视角分析工程化过程，让功能尽量简单，以凸显工程化的脉络。在后续叠加更多的自驾功能时，其实就是在这个模板的各个环节横向增加内容，而工程化的原理还是一样的。

我们假设的AEB 功能的系统方案，关键硬件组成：

序号 名称 规格 备注
1 前向毫米波雷达 输出目标数据（一级语义）
2 前置摄像头 800万像素，HFOV:120°，VFOV: 54.2° 输出原始视频帧（零级语义）
3 ECU SoC 主芯片 内置多核心 CPU, ISP单元，AI 单元，编解码单元，GPU 可以运行Linux/QNX 系统，可以进行深度学习计算
4 ECU MCU 主芯片 符合 ASIL-D 标准的高性能多核 MCU，有浮点加速单元 可以运行 RTOS 系统或 CP AUTOSAR
5 ECU 视频接口 1到多个 GMSL2 接口支 持800万像素30帧输入
6 ECU 以太网接口 1到多个外部千兆以太网接口
7 ECU 其它接口 电源、UART, CanFD,等
旁注：方案中雷达使用 Smart Senor ,直接输出检测到的目标列表。此案例先关注在视觉算法上。实际产品可以直接把雷达信号处理运行在ECU中的 MCU 上，MCU 要负责对雷达回波的物理信号进行采样。但这样在对ECU进行 HiL 测试时要模拟雷达回波，难度很大。此案例雷达用Smart Sensor 以简化后面的说明。

然后我们还有专业采集车，专业采集车上安装一个64线的激光雷达，输出点云(零级语义)。

3.3.各层级数据语义的独立研发闭环

图 14 算法的语义层级划分，这张图中把 AEB 功能可能涉及到的各种算法按照语义层级进行划分。这是一个工程化视角，并不是一个算法实现原理的视角。这里所谓工程化视角，是指可以比较方便的把每个算法单独开发，单独测试。

比如雷达目标和摄像头目标都是一级语义数据，我们需要这两个一级语义数据做的融合算法。可以直接在仿真软件上做传感器模拟，基于仿真软件输出的一级语义进行开发。这样我们可以在雷达算法和摄像头算法都不具备的情况下，先进行融合算法的开发。

好的仿真软件，可以提供各级语义的模拟数据，可以在模拟数据上加噪音，同时还能直接提供真值。这些可以满足各层算法的前期开发需要。

所以各种算法的独立开发再逐步集成的过程，是沿着语义层级的边界进行的。下面我们梳理一下图 14中各层级的算法。每个算法我们会关注其要达到的目的、语义层级、以及数据来源、和真值数据产生的方式。这篇文章不会关注具体算法的实现原理。

图 14 算法的语义层级划分

3.3.1.“0级语义处理”独立开发闭环

ISP 算法独立开发闭环

最典型的0级语义处理是 ISP（图像信号处理）算法。摄像头传感器输出的图像质量会受到环境的明暗程度、相机的对焦、曝光时长等很多方面的影响。视觉算法的效果重度依赖摄像头获取的图像质量。尤其现在自动驾驶系统安装量越来越多的摄像头，ISP算法的重要性就很突出了。

ISP 算法一般由专用芯片来执行（或者 ISP 硬件模块集成在某个SoC）中，算法根据情况还会对镜头或 Sensor进行反馈控制。常见的 ISP算法至少包含“格式转换、3A(自动白平衡，自动对焦，自动曝光）、噪点消除、宽动态(WDR)、白平衡调整、颜色校正、锐度调整”等。

旁注：有三类厂商非常看中 ISP 算法能力。一类是摄像头厂商，为了便于销售往往把 ISP 芯片集成在摄像头内部，调试好图像效果后整体出售，这样客户也方便。另一类是视觉算法开发厂商，因为算法严重依赖 ISP 效果，所以他们会非常看中 ISP 的效果，要么与摄像头厂商深度合作，要么自己参与研发。第三类是用于自动驾驶的SoC 芯片厂商。因为自动驾驶系统需要很多摄像头，如果把摄像头中的 ISP 芯片放在 SoC 内部，可以大大降低摄像头的成本。SoC 芯片厂商为了让芯片有竞争力，也会开发 ISP算法。具体项目中，ISP 的能力具体由谁来提供是一个重要的待决策事项。
执行环境 实验室暗房 各种真实光照环境
数据来源 在实验室中设计光照环境 到各地实地环境调试验证，覆盖各种道路、隧道、天气环境
真值方案 客观真值看参数，主观真值人判断
工具链 暗房设备，truing 工具 truing 工具，实车环境
被替代方式 上层算法至少有两种方式使用替代手段跳过 ISP 算法的开发：1. 直接从仿真软件获取渲染的图像。需要在仿真软件上设置模拟的传感器，“安装”在实际传感器同样的位置，一样要标定内外参数2. 先使用一个内置ISP能力的摄像头，在其能支持的场景中使用。

摄像头的畸变矫正算法、传感器的前融合算法也都属于0级语义的处理，理论上都可以采取类似的处理方式，但是具体算法还是有各自的差别。

3.3.2.“0->1语义提升”独立开发闭环

激光雷达算法独立开发闭环

激光雷达可以生成3D点云，线数越多，点云越稠密。相对摄像头和毫米波雷达，更能精确的测量物体在3D空间中的位置和形状。所以基于点云可以做一系列的感知算法，包括目标检测、分类、跟踪、语义分割、SLAM 定位等等。

本 AEB案例的系统方案主要使用视觉方案，不使用激光雷达，但是一个良好的激光雷达算法可以协助进行视觉数据的自动化标注，也就是将激光雷达算法的输出作视觉算法训练使用的真值。所以本例的专业采集车配备激光雷达。

数据方案 仿真数据方案 真实数据方案
零级语义数据来源 在仿真软件中添加激光雷达传感器模拟，获取点云数据 专业采集车获取点云数据
真值方案 仿真软件直接输出真值 人工标注真值
工具链 仿真软件、训练设施 专业采集车、激光雷达、采录设备、训练设施
一级语义的替代方式 仿真环境，可以从仿真软件获取所需环境数据的真值用于上层规划控制的开发 实车环境，可以采购带有成熟算法的激光雷达设备，相当买了个 Smart Sensor
旁注：关于仿真软件的传感器模拟。交通场景仿真软件是可以知道整个场景的真值信息的，包括场景中的建筑物、道路、各种车辆、行人等交通参与者，其位置、速度、行为都是仿真软件都是知道其绝对真值的。我们看到的逼真的3D视觉效果就是根据真值渲染出来的。相当于仿真软件具备了完全的上帝视角。我们要模拟一个真实车辆上的摄像头，就需要在仿真软件的自车对应位置设置一个同样参数的摄像头。参数包括安装的位置、摄像头的像素、FOV，畸变效果等等。仿真软件还要在其全知全能的上帝视角中，过滤出该摄像头“应该”能看到的局部场景信息并输出。输出可以有0级语义或1级语义。对应摄像头，0级语义就是符合摄像头参数允许范围内“看”到的局部图像。仿真软件要根据真值渲染出这个局部图像输出。输出1级语义就是从全场景真值中过滤出这个局部的真值。其他传感器的模拟也是类似原理。只是不同传感器的0级语义模拟时，要根据局部真值转换成该传感器对应的信息形式。所以仿真软件中一个模拟的传感器本质上是整个场景信息的一个过滤器。

视觉算法独立开发闭环

对本例的 AEB 功能来说，视觉算法主要做的工作是目标识别与分类、目标跟踪、视觉测速、车道线识别等等。下表列出了四种不同的数据来源方式来完成视觉算法开发。

数据方案 仿真数据方案 小批量摄像头路采 大批量摄像头+LiDAR 路采 量产车数据回传
零级语义数据来源 在仿真软件中添加摄像头传感器模拟，获取视觉渲染图像 实车安装摄像头，小批量采集数据 带激光雷达专业采集车实车大批量采集数据(含点云与图像) 量产车辆根据预设的触发条件记录数据，通过LTE 网络回传
真值方案 仿真软件直接输出真值 人工标注 人工标注+激光雷达算法自动标注 人工标注
工具链 仿真软件、训练设施 专业采集车，ISP Ready 摄像头，标注工具及管理平台、采录设备、训练设施 专业采集车、ISP Ready 摄像头、激光雷达算法、标注工具及管理平台(支持自动标注)、采录设备、训练设施 新增：量产车的数据回传机制，触发规则的 OTA 机制，合规自动驾驶云设施
一级语义的替代方式 仿真环境，可以从仿真软件获取所需环境数据的真值用于上层规划控制的开发 使用能直接输出目标的摄像头算法套件(Smart Sensor) 。如Mobile Eye 摄像头 实车环境，可以采购带有成熟算法的激光雷达设备，相当买了个 Smart Sensor

这四个方案都可以支持视觉算法独立的进行开发和训练。但从左到右，是从原型系统到真正量产可用的过程。数据量越来越大，需要的资源也越来越多，成本也越来越高。体现了一个单体算法开发从起步到真正实用的过程。

旁注：关于联合标注。数据采集的时候如果同时采集激光雷达数据和视觉数据，只要两个传感器数据的时间戳能够做好同步，并标定好相机和雷达之间的位置关系参数，那么标注激光雷达数据的同时是可以连带视觉图像数据一起标注的，称为联合标注。如图 15所示是联合标注工具。我们可以看到在激光雷达点云上标注的车辆，同时在左后相机上也被标注出来。因为点云是3D 空间，所以可以在三视图上对标注框做更精细的调节，转换到视觉图像上，就是一个贴合非常好3D Bounding Box。这样我们为激光雷达数据标注真值数据时，可以同步标注图像数据的真值。

图 15 激光雷达与视觉的联合标注

3.3.3.“1-2级的语义提升”独立开发闭环

此AEB案例中，1级到2级到语义提升算法可以包括：

后融合算法：根据毫米波雷达输出的目标和视觉算法输出的目标。

目标跟踪算法：在连续多帧数据中跟踪单个或多个目标

基于车道线的车体定位：判断车辆与车道的关系

主要目标选择算法：从多个目标中筛选当前最重要的关键目标

这些算法的数据方案基本类似，如下表：

数据方案 仿真数据方案 实车数据方案
一级语义数据来源 仿真软件中建立传感器模拟，取得各传感器输出的一级语义真值数据用于计算 基于雷达和摄像头的 Smart Sensor 获取一级语义。在一级语义基础上做语义提升的算法开发
真值方案 仿真软件直接输出真值，或在仿真场景设置时指定真值 人工标注真值，或者利用激光雷达算法输出作为真值
工具链 仿真软件、训练设施 专业采集车、激光雷达、采录设备、训练设施、数据回放机制（各种台架）
二级语义的替代方式 仿真环境，可以从仿真软件获取所需环境数据的二级语义真值用于上层规划控制的开发 实车数据的二级语义是一个基础的开发切入点，一般不再为它设计替代方案

3.3.4.“2->3 级语义提升”独立开发闭环

轨迹预测与行为预测的独立开发闭环

AEB 功能对于选定的主要目标，要判断其危险性，需要做“轨迹预测”和“行为预测”。我们认为这是2级到3级到语义提升。

旁注：“轨迹预测”和“行为预测”在 AEB 中并不是必须的，目前实际量产的 AEB 功能，多数并没有做，或者并没有明确的有这两个模块。一般在 AEB 功能的“危险程度评估”阶段，会对主要目标的速度和方向做一些判断，并不会去做较长时间（比如5秒以上）的轨迹预测。因为 AEB 功能如果需要被触发，从触发到执行的时间非常短，从预警(声音)到舒适性制动再到紧急制动的过程一般会在0.5-3秒内完成。从保守的安全性考虑，决策时不考虑目标未来的轨迹和行为，会减少漏报的可能性。如果能在足够的数据支持下增加“轨迹预测”和“行为预测”理论上可以减少误报率(幽灵刹车)。所以这两个算法的开发应该作为 AEB 功能持续改进时的切入点，而不是一开始的重点。Level 4 以上高阶自动驾驶中“轨迹预测”和“行为预测”的重要性就非常大了。
数据方案 仿真数据方案 实车数据方案
二级语义数据来源 仿真软件中设计场景，场景中的目标 基于激光雷达和摄像头的 Smart Sensor 内置了算法，可以直接输出二级语义数据
真值方案 仿真软件中设计场景时，可以指定目标的轨迹，需要仿真软件支持目标轨迹数据的获取 从未来轨迹和行为中提取真值
工具链 仿真软件、训练设施 专业采集车、激光雷达、采录设备、训练设施、数据回放机制（各种台架）
三级语义的替代方式 一般不做替代方案。如果需要，可以要求仿真软件直接能提供环境目标的未来轨迹。 无

3.3.5.“2和3级语义利用”的独立开发闭环

对于本例的 AEB 功能来说，“2和3级感知语义的利用”就是基于它们执行车辆的控制的行为“舒适性制动”和“紧急制动”。

执行环境 全仿真环境 车辆在环仿真(ViL) 实车环境
二、三级语义数据来源 仿真软件输出环境真值 仿真软件输出环境真值 基于激光雷达和摄像头的 Smart Sensor 内置了算法，可以直接输出二级、三级语义数据
车辆执行机制 仿真软件提供车辆模拟 真实车辆 真实车辆
工具链 仿真软件、快速原型设备 仿真软件、快速原型设备，车辆 快速原型设备，车辆、Smart Sensor

这正好是“图 4 车辆控制算法开发闭环演进”说阐述的内容。

3.3.6.独立闭环与执行环境

图 16 算法开发的独立闭环与执行环境

通过上面的分析，我们可以发现一个特点，各层以及层级之间语义提升的算法可以独立开发，但是可以在不同的执行环境中开发，从便捷的仿真环境，逐步到更贴近真实场景的实车环境。

仿真环境数据和真值获取方便，便于建立初始研发闭环。实车环境跟真实量产的执行环境最为接近。

如图 16所示，几个不同语义层级的算法都可以独立进行开发（对低级语义的数据需求使用替代性方案），同时还可以在不同的执行环境中运行，包括纯软仿真环境、HiL台架、 ViL 仿真、实车环境等等。如前文所述，每种环境的数据来源、真值方案各有不同。完成从原型开发逐步向量产质量的过渡。

各种环境都需要一定的 IT 底座进行支持，越接近量产，数据规模越大，IT 底座的资源也越多。同时需要一系列的工具链支持，包括仿真软件、台架系统、采集系统等等。

3.4.智能驾驶系统集成的一般原理

各算法模块能够独立进行开发和测试了，那么下一步就是如何进行集成。

3.4.1.集成的三个维度

可以从三个纬度去考虑集成过程，为了能小粒度的准确的表述集成的演进路线，我再把每个纬度分层三段，如图 17：

1.算法串接（单体算法 局部闭环 全程闭环）

2.执行平台（原型平台、工程平台、量产平台）

3.数据规模（少量数据、大量数据、海量数据）

图 17 三个纬度看待系统的集成

本文会出现“执行平台”和“执行环境”两个概念，这里做一下定义。“执行平台”是自动驾驶算法和软件的运行平台，包括硬件平台(MCU + SoC)、操作系统、中间件等。“执行环境”是执行平台及其所运行的外在环境，外在环境包括传感器、车辆以及交通场景。外在环境主要有实车道路环境与仿真环境两类，也有实车+仿真道路的模式(ViL)。

3.4.2.算法串接

“算法串接”很容易理解，图 14中列出的多个算法可以连接在一起。比如，我们在仿真环境开发毫米波雷达与视觉的融合算法，两个一级语义的数据都可以由仿真软件给出，那么这个研发闭环就是“融合算法在仿真环境下的单体闭环”，实现的是1->2级语义的提升。

如果把视觉算法加入这个闭环，也就是让仿真软件输出渲染图片，用训练好的深度学习模型进行推理，计算得到车道信息和目标列表，再跟雷达目标进行融合，这样就把0->1, 1->2 两级语义提升连接在了一起。但还没有完成全部 AEB 的流程，所以只是“局部闭环”。

局部闭环是一个逐步叠加的过程，一个个算法模块或功能单元逐步被纳入到执行平台中，直到把图 14中的所有算法连接在一起，形成仿真环境下的从感知到控制执行的全流程，称为“全程闭环”。

3.4.3.执行平台

如果系统都集成是在仿真环境下执行的。整个过程完全没有使用任何将来会安装在车上的元器件。那么这执行平台只是一个“原型平台”。对应与图 16中的“全仿真执行环境”平面层。

“原型平台”不光可以基于仿真建立，在实车环境也可以。我们可以用两个 Smart Sensor（内置算法直接输出目标信息摄像头和雷达器件）提供一级语义来开发融合算法，这是单体闭环。如果去掉视觉 Smart Sensor,换上我们自己选用或开发的“摄像头+ISP+视觉算法”提供视觉目标，这就到了局部闭环。我们再加上控制算法，使用快速原型设备控制真实车辆，就可以形成全程闭环。（参见1.2.3中的闭环 B）如果视觉算法运行在 x86 工控机上，那这个执行平台也没有任何用于量产的元器件。

我们接着对上面的执行平台进行改造。我们去掉快速原型设备，如果我们自己的设备(ECU/域控制器/计算平台/智能大脑等等目前流行的各种叫法) 还未就绪，那么可以使用 已选定的MCU 的开发板运行实时域程序，用选定的 AI 芯片的开发板运行视觉算法（参见1.2.3中的闭环 D），这时候，整个执平台中就有了我们用于量产的元器件，我们认为它是一个初步的“工程平台”。

工程平台也是一个逐步累积的过程，比如我们用自己的计算平台设备的样件替换掉了前面两个开发板，这就往前跟进一步了。最终我们的执行平台就是正式量产的计算平台设备，成为“量产平台”。

各执行平台都可以基于仿真来运行（参见1.2.3中的闭环 C），量产平台一样可以基于仿真来运行，一般意义上的HiL 测试就是这种模式。ViL 测试既可以基于原型平台，也可以基于量产平台。

3.4.4. 数据规模

说到数据闭环，数据规模是大家最关心的事情。因为无论是采集、存储、脱敏，还是数据的清洗、筛选、标注、训练，一旦上了规模，都是大把大把真金白银的投入。假如我们准备了100量专业采集车，配备全套传感器，全国采集了上千万公里的数据(这投入已经是10亿人民币量级了)，然后发现某个数据没有时间戳~~~~ 芭比Q 了

这里我把数据规模分为“少量数据、大量数据、海量数据”，这里不必纠结于字眼，多少本来就是相对的概念。名称只是一个代号，重要的是数据规模划分的逻辑。

少量数据

图 17中把“算法串接、执行平台”的各自三段画在“少量数据”的平面上，也是为了表示“少量数据”的重要性。这个重要性就是“基于少量数据快速建立起‘单体算法、局部闭环、全程闭环’分别在‘原型环境和工程环境’的执行能力”。

我们可以通过仿真软件，提取数据建立基于仿真的算法串接闭环，包括算法串接的三个阶段。我们也可以用简化版本的采集车，先采集少量数据做算法验证，采集车也需要迭代到一个完整版本。即便有完整版本的采集车，也可以只是先采集少量初始数据，到底是多少，看你项目需要达到的目的，几万公里不多，几千公里不少。

但这些数据的目的是为了“建立原型环境和工程环境的执行能力”，这些能力体现在至少以下方面：

  • 算法串接的各种局部组合到全程闭环都能在原型环境和工程环境运行起来（只关注能否运行，不关注准确性）
  • 工程环境的各种形态可运行能力经过了实际数据的检验
  • 工程环境的各种形态能对不同的算法串接组合做自动化测试
  • 工程环境执行中产生的日志数据可以进行回放，便于分析问题
  • 为采集到的数据建立了标准的处理流程，基于各种数据处理工具（数据脱敏、清洗、筛选、标注、训练），建立了数据生产并推动算法提升的能力
  • 建立了可弹性扩展的 IT 基础设施，弹性体现在算力、存储等方面，也就是 IT 基础架构具备，可以随时扩容

简单来说，就是“用少量数据建数据处理能力，为大量数据驱动做准备”。

大量数据

数据处理能力建立并得到验证，就可以投入大量资金去提升数据规模。这个时候只要资金够，就可以投入几百台采集车，获取上亿里程的数据。用数据去驱动各种算法快速成熟可用。所以少量数据的时候关注点是算法可执行，大量数据阶段关注的是算法的正确性和执行性能。这个阶段完成，整个系统具备了量产装车的可行性。

海量数据

但是就算有几百台采集车，司机驾驶行为的多样性依然不够；上亿里程，也不能覆盖所有的长尾场景。这时候就需要通过量产车辆在合适的时机触发数据采集，回传数据到数据处理平台。

假设有10万量产车具备数据回传到能力，只要设置了合适的采集触发规则，我们就可以针对特定的兴趣点（感兴趣的环境、自车行为、交通场景等）获取海量数据。这个海量不仅仅体现在数据容量上，更体现在数据多样性上，10万不同的司机，遍布在几乎所有可能的道路环境，发生任何事情都不奇怪。

一般来说，我们会把通过大量数据验证的软硬件系统部署到量产车上，但是以“影子模式”运行。也就是全部的传感器都开启、所有涉及的的计算都正常执行，但是到控制车辆的最后一步放弃执行，改为触发数据回传。

这样通过海量数据挖掘出长尾场景，这些场景的数据经过加工后，可以在合适的工程环境中回放，分析、复现问题并验证修复的结果。改进后的软件 OTA 到量产车辆，再重复这样的循环。经过一段时间的迭代，长尾场景的数量收敛到一定程度，相同触发条件下的数据回传量也会减少，那么在合适的时机，就可以在量产车上关闭影子模式，真正启用功能的执行。

综上所述，数据规模三个阶段的作用，总结来说就是以下三点：

1.用少量数据尽快建立起“单体算法、局部闭环、全程闭环”分别在“原型环境和工程环境”的执行能力，并能进行自动化回归测试。

2.基于专业采集获取的大量数据，驱动上述执行能力组合，快速迭代，达到量产装车的基本要求，保证影子模式能够执行

3.利用量产环境回传海量数据，并进行分析处理，提取长尾场景，补充训练、测试并改进系统，最终实现在量产车上启用功能。

3.5.AEB 功能的系统集成路径

上一节是一般意义的系统集成原理。现在我们回到我们的样例AEB 功能开发，看如何进行整体的系统集成。我们先基于少量数据，在“算法串接”和“执行平台”两个维度上进行集成。

图 18显示了整个集成的过程。为了能在一页图上能放得下，我们还省略了一些更细节的步骤，不过图上显示的部分已经足够说明整体的集成思路了。

因为整幅图比较复杂，自定义了一套符号体系来表达，说明如下：

图上的实体符号有三类，“算法闭环”、“执行平台”和“工具集”。算法闭环的三个几段用三种颜色做了区分。每个算法闭环下有其依托的执行平台。整幅图从上到下分了三个区域以区分“原型环境、工程环境、量产环境”。工具集分为“仿真工具集”和“实车工具集”，以不同颜色区分，布局在图上两侧。

图18 理想化的 AEB 集成（虽然图很复杂，但仍只是实际集成过程的简化表示）

图上的连接线三类，一类表示算法闭环的串接关系，一类表示执行环境如何使用工具集，一类表示工具集之间的关系。连线附近有关于其意义的文字说明。可以参见图例来识别符号含义。为了便于后文说明，算法闭环和工具集上有数字角标，用于在后文陈述中对其引用。

整张图主要有三条线索，“算法串接”和“执行平台演进”两条线索本身就是我们前面说的集成过的两个维度。另一条线索是 “工具集的变化”主要体现了集成过程中不同阶段的测试环境和测试方法。这三条线索是交叉行进的，虽然图上的布局尽量体现了从上到下从原型开发到量产的过程，但依然在中间会出现很多交叉的过程，这也是感觉复杂的原因。我们理解集成过程时，也要顺着这三条线索去分析。我们从上到下，依次来说明（后续内容建议阅读时打开另一个页面，显式图 18，随时对照）。

原型开发阶段

原型阶段的 A1 （视觉算法） A2（后融合、目标跟踪、主目标选择）和 A3（控制算法）三者之间是可以完全独立进行开发的。A1使用的是0级语义数据，A2使用的是1级语义数据，A3使用的是1级和2级语义数据。A1和 A2都可以在 T1、T2这两个工具集下进行闭环测试，T1、T2分别提供了仿真和实车的测试环境，提供算法需要的0级语义或1级语义。A1、A2、A3是典型的以语义分层为边界做的划分，使得各层算法可以独立、并行的进行开发和测试。

A1和A2串接起来成为 A4，直接实现从0级语义到2级语义的提升。A3、A4串接起来形成 A5。A5就已经是从感知到控制的全程闭环了。

A1~A5的执行平台虽然都算原型平台，但是也是有差别的。A1，A2，A4可以直接在 PC 上进行开发，开发环境的建立成本会低很多。A3和 A5涉及到对车辆的控制，一般都需要 MBD (Model Based Development) 工具链和快速原型设备支持（参见1.2.3）。

A1~A5都可以在仿真测试环境或实车测试环境运行。同样的功能和执行平台能在两个不同的测试环境，一方面可以利用仿真降低研发成本提高效率，一方面方便建立自动化测试体系。

大多数自动驾驶系统的开发都是从原型阶段开始的，原型阶段的最终形态一般就是在在改装好的车辆后备箱安装一大堆设备，以x86工控机作为计算平台，驱动车辆演示一些自动驾驶功能。多数公司前期融资时就是这样的状态，但实际上这仅仅只是一个漂亮的 Demo，距离工程化的量产，还差的非常非常远。

工程化阶段

工程化阶段的核心目标，直观来说，就是把原型阶段车辆后备箱里的那一大堆设备都扔掉。这要求硬件上要用能耗比高的计算平台替换掉工控机，要求具有高 AI 运算能力、高实时性，还要能满足车载设备抗振、耐高低温、电磁兼容等要求。软件上从操作系统到中间件到自动驾驶软件架构，也有非常多的技术难点需要克服。同时，软硬件还要能满足汽车功能安全要求。所以工程化落地能否合理有序的推进，同时辅以一系列测试手段保证产品的质量，是自动驾驶技术能否落地的关键环节之一。

图 18演示的工程化阶段的步骤仍然被高度简化了，但可以用来阐述一般性原理。具体到实际项目要做专门的工程化路径设计。

A5到 A6的工程化动作是把快速原型设备替换为量产的 MCU 平台来执行实时域的计算。相当于1.2.3节中的 闭环 B 演进到闭环 D。A5和 A6的仿真测试环境和实车测试环境是一样的。这也是符合最少变量原理，每次演进步骤尽可能做最小的改变。

A4到 A7的工程化步骤是讲 PC 平台替换为车载计算平台，这其实是一个很大的工程化动作。内部还可以进一步拆分层更小的步骤，比如 A1，A2包含的4个算法可以单独向 A7的执行环境移植，图上没有做这更细粒度的拆分。

A4和 A7都不是全程闭环，因为没有对接车辆控制算法。A7的测试环境可以有很多种，技术人员从芯片的开发板开始，逐步迭代自己的硬件平台和基础软件，最终形成相对完整的计算平台。密集开发阶段，可能每个开发人员桌面都会有一个样件，专注调试自己负责对模块。

图 18画的 A7与T4形成的测试环境是比较接近开环测试（不包含车辆控制）能达到的最大测试跨度。T4是PiL（处理器在环）测试台架，主要测试软件和算法在目标嵌入式平台上的行为。PiL 比 HiL 简单，可以包含仿真软件，也可以不包含仿真软件，这样成本很低，就可以在 PiL 台架上同时支持多路目标设备，方便进行并行执行多个用例的自动化测试。

A6和A7 集成在一起就成为A8，A8在目标计算平台上运行完整的感知到控制的闭环。A8可以在 HiL 台架（T5）上进行测试，也可以将 HiL 台架小型化后再车上进行ViL 测试（T6），也可以直接实车测试（T7）。ViL 和实车测试录制的日志数据，应该可以在 HiL 和 PiL 台架上进行回放，用于分析和定位问题。

量产阶段

A8进一步工程化到量产装车的正式产品 A9。A9与A8相比，增加的比较重要的特性在几方面：

1.A9要支持一定的 OTA 能力，方便更新软件

2.A9要与车辆环境深度集成并进行严格测试，比如电源管理、网络管理等。而 A8只需要关心自动驾驶相关的功能、

3.A9需要能支持影子模式与数据回传。

A10的产品形态并不是安装在车上，但是也把它放在了量产阶段，因为这就是它这种运行模式的最终形态。A10直接从A4进化而来，执行平台从PC换成了云平台。A10所依赖的执行环境 T9为轻量化的云仿真平台。它不需要做0级语义的支持，这意味着不会做视觉的渲染输出，会大大降低单个仿真实例对计算资源的需求。一般来说，T9的渲染只需将1级及以上语义信息以线框图的形式呈现出来。比如我们经常能看到 Apollo 开发平台仿真的渲染画面。

图 19 场景渲染的线框图形式（图片来源于Apollo 官网）

T9的重要作用在于对场景的复现与测试，也就是在三级及以上语义基础上，验证对车辆行为的规划与控制。比如我们再 A9回传到数据中发现了一个“鬼探头”的场景，就可以在 T9仿真环境中设计复现这个场景，并将它加入到每日例行的回归测试中。

T9的另一个重要作用是并行仿真，后文详述。

3.6. 仿真及测试工具链分析

可以看到，图 18中包含了很多仿真和测试的工具链，这些工具链的存在对完成整个系统的工程化有非常重要的作用，以下简要列出来仿真及测试工具链在“工程化、高效率、一致性、可测性、精确性、可靠性”等方面的作用：

1.实现工程化的分阶段测试。研发不同阶段提供的测试环境 T1~T9 ，也为出现问题时提供回溯分析的平台。

2.提高效率，节省研发资源。能在仿真上做的开发和测试就尽量在仿真上先做，至少先把算法或功能的流程通路先跑通，省得在实车测试出现这方面问题，就能节省实车测试时间。

3.验证不同环境下的一致性。对于能同时在仿真环境和实车环境执行的研发阶段，如 A1~A6，A8 ，保证执行平台一致，仅需关注测试环境的不同。就可以在仿真环境中提早发现问题。也可以把实车环境的问题在仿真环境进行复现。

4.通过仿真系统模拟部分必须的数据，使得局部或全程系统达到可测性，尤其某些危险场景实车测试很难进行，就只能进行仿真测试。

5.软件系统的可靠性是需要持续不断的回归测试来支持的。理论上只要有代码（或AI模型)的更新，都应该执行回归测试。每次变更之后都要将之前的测试用例都重新测试一遍。必须要建立自动化测试机制才能高效率高频次的执行测试动作。大多数自动化测试只能在仿真环境进行。仿真是解决自动化测试的关键武器。

6.不同算法都必然有精确性的要求，这需要测试机制能够对算法的精确性提供测试和度量的方式。

分析和设计测试环境时，可以从以上几方面进行考虑。图 18中T1到T9的测试环境都会体现上面几个特性的组合。但T1~T9也不能完全涵盖全部可能的测试环境，需要根据产品和项目的需求设计合适的测试环境。

同时从T1到T9各自的用途和侧重点有不同，产生的数据和对数据的利用方式也有不同。我们也可以从数据的语义层级出发对测试环境进行分析。

下面我们对几个重点的仿真和测试环境从“工程化、高效率、一致性、可测性、精确性、可靠性”以及与数据的关系方面进行一些分析。

3.6.1. 纯软件仿真

图 18中T1和 T3是纯软件仿真。A1+T1 使用的是0级语义的图像数据，A2+T1 使用的是1级语义，不需要图像数据。这两个组合首先解决的首要问题是提高效率。尤其在开发前期，车辆环境还不具备的时候就可以进行开发。一台车辆从采购到改装至少两个月，还要找专业的有工程车测试资质的测试员来开，多个团队等着排队用车，会消耗很多时间在等待上。

要让 T1具备对 A1和 A2 的可测性，要求 T1的仿真软件具备“传感器模拟”能力和良好的“真值输出接口”。

传感器模拟

我们先区分两个仿真中的两个概念“地图”和“场景”。“地图”代表一个交通环境中的静态部分，包括道路结构(含桥梁隧道)、交通标志、静态障碍物等等。“场景”表示“地图”加上一段时间内交通参与者的行为，交通参与者包含自车（EGO Car）、其它车辆、行人信号灯状态变换等等。简单说，“地图”是静态的，“场景”是动态的。这两个词的意思或许在其它地方与这个定义有差别，但在本文，就是表示这个意思。

那么当一个仿真软件加载并运行一个场景时，它是有一个上帝视角，知道场景中所有事物（包括地图中的静态物体和场景中的所有参与者）的状态的。传感器模拟实质上是给这个全知全能的上帝视角增加一个过滤器。比如一个前置摄像头，给定了横向和纵向的视场角后，它就过滤掉这个视场角之外的环境信息，只把视场角内的环境数据输出出来。这就是传感器模在环境语义上的本质含义。

对于类似于 A1和 A2的开发需求，要看重仿真软件的传感器模拟能力。包括能够支持的传感器类型，每种传感器能够模拟的物理参数范围，执行性能上要能同时设置大量传感器而没有明显的延迟等等。

上帝视角的场景信息至少是一级语义，所以传感器模拟输出一级语义是非常自然的，反而输出0级语义（图像或点云或雷达信号），反而要经过额外的数据处理或渲染。

关于仿真软件的渲染效果

人们很容易关注仿真软件的3D 实时渲染效果，毕竟这是很容易被直接看到的，高逼真度类似游戏的场景渲染，确实很震撼。但从语义层级来讲，这是零级语义，仅仅在需要使用图像数据的闭环测试中需要，比如 HiL 测试。

对于直接利用一级及以上语义进行开发的闭环（如 A2和 A3），是不会利用渲染图景，对渲染效果自然也就没有要求，反而往往会更关注仿真软件的传感器模拟能力，真值的结构定义、输出API形式。要对车辆进行控制的研发闭环，会关注仿真软件中自车的动力学模拟能力是否足够逼真。

支持三级语义（涉及自车之外的其他交通参与者的研发闭环），更希望仿真软件能够提供除自车之外，对其它交通参与者行为的控制能力，包括AI 控制或提供编程控制的接口。

一级及以上语义的研发闭环，对渲染的要求只要能让人看清语义含义就行，可以简单到只需要使用线框图显示就足够了，这样不需要高性能的渲染设备，还可以直接在浏览器中高性能的展现，也方便在渲染画面中附注各种方便开发人员进行分析的信息。

高逼真度的3D 实时渲染效果需要高性能显卡支持，研发人员在桌面端或许有需求。当不适合用于成百上千场景的并行仿真，并行仿真中本来也没人去看渲染的结果，并行仿真只需要记录日志数据，如果有需要（比如分析仿真中发现到的错误），只要能将日志数据以线框图的形式回放分析就可以了。

真值的定义和输出接口

仿真软件自身拥有的上帝视角，有场景中所有事物的真值数据。但是这个真值的数据结构如何定义，真值数据如何输出并不是一个容易的设计。

真值数据结构体现了描述复杂的交通环境的能力，我们也把这个交通环境的数据表达形式成为“环境模型”。开放仿真接口（Open Simulation Interface）定义了一套环境模型表达的数据结构，使用 proto buffer 的格式定义，可以从 GitHub上获取 。

图 20 是分析 OSI 定义中所有文件的依赖关系而绘制出来的依赖图，A --->B表示 A 依赖于 B。可以看到，所有代表传感器检测到的环境信息的数据文件是依赖于代表真值的数据文件的。这也从侧面说明了，仿真软件输出的模拟传感器检测到的环境数据，是根据真值推算出来的（把传感器当过滤器，输出部分环境真值数据，根据必要还可以加噪声）。

图 20 开放仿真文件依赖分析 (A --->B ,代表 A 依赖于 B)
代表上帝视角的真值数据本身也非常复杂，毕竟要描述“整个世界”.

图 21 开放仿真接口的真值定义

图 21 是开放仿真接口的真值定义（根据 OSI 定义文件逆向生成，高清图请单独索取），包括车道、车道边界、静态物体、动态物体、交通标志、地面标志等等。

OSI 的定义出来的比较晚，大多数仿真软件还没有支持，所以各仿真软件都有各自的真值和模拟传感器输出的数据格式。所以为 A1和A2类似的开发阶段，需要考场仿真软件真值的表达能力。还有真值和模拟传感器的数据的方式也会影响开发的难易程度，值得关注。

动力学仿真

图 18中A3、A5（原型阶段的全程闭环）和 A6（工程化阶段的第一个全程闭环）都使用了T3作为仿真环境。T3主要是在 T1的基础上增加了车辆动力学模拟。一般自动驾驶仿真软件都会提供一定的车辆动力学模拟能力，预置一些典型车型的动力学基本参数。用户也可以根据已知的参数来在仿真系统上创建新的动力学参数车型。

T3首先解决的需求也是提高效率和可测性。让车辆未就绪时能支持控制算法的开发。T3跟 T5（HiL 台架测试环境）是有很大差别的。T3主要靠软件解决问题，尽量不涉及昂贵的硬件。T3对准确性的要求低，但同时也要求成本低。软件仿真的优势就是可以同时开启很多实例，让不同组别的人可以同时工作。甚至每个开发人员都可以在桌面启动一个仿真测试的开发闭环。测试组也可以同时进行测试闭环的开发，自动化测试的搭建。所以要求单授权的采购成本低才能采购较多的授权。

而T5 HiL 台架测试会追求高精度，不仅仅动力学模型参数准确、实际执行效果也跟要适配的车辆高度一致，动力学模型也要放在高性能的实时机上执行，支撑的软件也会非常昂贵。这样的系统一般来说不可能会采购很多实例。

纯软件仿真工具的选择原则

纯仿真软件（T1和 T3）的重点在提高效率和提供可测性，并尽可能降低成本以采购尽量多的授权。同时在准确性上的要求应有所让步。

0级语义的精确性不是 T1的目标。满足 T1要求的仿真系统，需要有较好的渲染效果，但是不用追逐过于逼真的渲染效果，因为再逼真的效果，也是计算机生成的，跟物理摄像头拍摄还是有很大出入，尤其在人眼看不到的细节上，人眼看不到的内容，也许对算法上敏感的。而为获取逼真渲染效果的投入与其产出并不成正比。

动力学模型的准确性也不是 T3的核心目标，T3需要的是低成本下的动力学模型支持。只要测试闭环能建立起来，实际对动力学效果到 T2（实车上）进行测试。

所以在选择仿真软件时，尤其要注意以下几点：

  • 警惕对渲染效果的过度宣传，确认你是否需要并值得为其付费
  • 这个阶段不要过度追求高精度的动力学模型
  • 根据自己需要的语义层级、传感器类型谨慎选择仿真软件的功能模块

总之就是要在满足核心目标（提高效率和实现可测性）的前提下，尽可能降低成本而采购足够多的授权。一个所有功能齐备、渲染精美、动力学模型高精度的仿真软件，单个授权上百万了，抵得上一辆豪车了，如果不能买多个授权，开发团队和测试团队不能同时使用，也就谈不上效率了，还不如多配几台车算了。

同时为了能基于不同层级的语义做各层算法的并行开发，要特别关注仿真软件对不同层级语义的定义能力、真值的定义能力、数据格式规范、以及 API是否便利。

3.6.2.处理器在环仿真

1.3节已经提到 PiL（处理器在环），也就是图 18中的 T4。

图 22 各 AI芯片平台

PiL 测试首要解决的问题是一致性。原型阶段的所有软件都没有在我们的最终目标硬件上运行。更直接到说法，原型阶段大多数都是在 x86平台上开发，在车上也是用 x86工控机，工控机上安装Nvidia的显卡来运行深度学习算法。但是在量产阶段，我们需要所有软件运行在车载专用计算平台，CPU 以 Arm 为主，AI 模块各芯片有自己的专用设计。

图 22列出来目前比较知名的一些 AI 芯片平台。可以看到，虽然大家在训练阶段都使用Nvidia的 GPU 或计算卡，但是在推理阶段， 训练得到的AI模型在向不同的嵌入式平台移植时都需要做一下模型的转换、嵌入式的优化工作。需要保证移植和优化完成后，算法的执行结果仍然和最初训练出来的一样。

除了感知类的 AI 算法外，控制算法原型阶段在快速原型设备上运行，工程阶段要在高实时 MCU 上运行，也需要保证一致性。嵌入式系统的基础软件环境与工控机也不同，也需要验证软件在运行环境变更后，其行为是否一致。

日常开发可以用计算平台样件，为了方便做自动化测试，一般通过 PiL 台架来执行。PiL 台架上包括电源、电压范围、软件的更新都可以通过程序进行控制。方便自动化测试用例的部署和执行。以太网、Can总线、LVDS 线束等也可以设计层可以通过程序控制其中断与连接，这样可以模拟故障的注入。

PiL 台架可以支持视频注入到嵌入式平台的摄像头数据捕获接口（一般是 LVDS 接口），这样可以把嵌入式平台的视频捕获模块也纳入到测试回路中，这是 T1、T3 仿真测试环境无法实现的，T1、T3的渲染数据只能通过以太网发送，是测试不到视频捕获模块的。如果 PiL 台架不包含仿真软件，还可以直接回放视频文件作为视频源，这样也可以将实车路采的视频数据在 PiL 台架上进行回放。

3.6.3.硬件在环仿真

具体的硬件在环测试的原理和设计很多文章有论述，这里不做详细说明，只对其与其他测试手段的区别进行说明。

在 PiL基本上解决了一致性的前提下，HiL 主要目标是可靠性和可测性，同时兼具精确性。能够达到这几点，是由设计HiL 测试的几个基本原则决定的：

1.待测设备的所有外部接口数据交换方式要尽可能跟实车一样

2.完成从感知到控制执行的全程闭环

3.测试场景通过仿真来实现

4.全系统能够程序控制自动化

对于第1点，我们想达到的效果是让待测设备貌似不知道自己当前是在车上还是在测试台架上。因为所以的外部接口的数据交换都是跟车上一样。比如在摄像头数据输入上，也需要通过视频注入的方式，让视频捕捉设备以跟车上同样的方式获取图像数据（0级语义模拟）。也可能某些传感器的0级语义模拟非常困难，很难做到很精确，或者成本太高（比如雷达回波），那么部分传感器数据使用1级语义。但总的来说，是倾向于全部使用原始的0级语义数据。

这样就将待测设备的全部软硬件都纳入到了测试闭环中，相对于其它跳过某些环节的测试手段而言，这是最完整的测试闭环（上文第2点），这是能验证系统可靠性的一个基本前提。同时与自动化测试相配合，可以在测试频次、测试时间上提高数量级，对可靠性验证有很大帮助。

虽然是全程闭环，但是交通场景是仿真的，这也就意味着一些危险的场景能够以较低的成本被进行测试，达到较好的可测性。

因为感知到0级语义（图像、点云等）是仿真出来的，经过训练的感知算法对这些数据会有非常好的效果。这可以推导出两个结论：

1.HiL 测试中感知算法对仿真场景非常准确，能给后续的决策规划提供较好的依据

2.HIL 测试实际上测试不了实际感知算法的精确性（但能助力形成全程闭环过程）

在这两个前提下，如果我们提高车辆动力学模型的精确性，就能非常好的测试控制算法的精确性。因此 HiL 测试的仿真软件要求能够具有非常精确的设置和调整动力学模型的能力，同时使用高性能的实时机（硬件和操作系统都是以高实时为目标进行设计）来执行动力学模型，保证其执行机制跟实车环境高度一致。这也是 HiL 测试系统价格昂贵的重要原因之一。

这与4.5.1中对动力学模型的要求是不一样的。4.5.1的纯软件仿真是以效率为主，要求低成本获取足够多的软件授权提高前期的开发效率，可以牺牲部分动力学模型的精确性。本节的 HiL 测试确是要以控制算法的精确性为主要目标之一，以高成本实现一个测试台架。

ViL 测试（图 18的 T6）可以看成是 HiL测试的小型化，整套测试环境（仿真软件、传感器注入能力）都被安装到车上。去掉 HiL 测试中运行动力学模型的实时机，替换为真实的汽车执行机制。这样就在 HiL 基础上，对控制执行的测试直接使用真实的实车设备，进一步提高了测试的精确性。因为依旧使用仿真场景，所以仍然具有跟 HiL一样的可测性，但是一定程度上牺牲了自动化测试能力。

3.6.4.影子模式与云化并行仿真

前面我们用软仿真快速构建初步的研发闭环，在利用 PiL 测试环境逐步从原型阶段向工程化阶段转换。HiL 测试实现了工程化阶段最完整的仿真闭环，ViL测试得到更精确车辆控制效果。我们也可以通过实车（T7）来复现某个单个场景（使用假人、模型车等道具）。到这一步，对单个场景的工程化能力建设到了极致。我们可以在这一系列工程化阶段中把算法、软件迭代得越来越好，但还有一个关键点问题：场景覆盖度不够。

这体现在两方面：

1.如何发现大量的长尾场景

2.如何对大量场景进行回归测试

第1点难在“如何发现未知的问题”，第2点是“如何提高测试效率”的问题。T1~T8都是针对少量场景的测试，是无法应对段时间内执行成千上万测试场景的需求的。

为了解决这两个问题，衍生出对应的解决方案，分别是影子模式和并行仿真。

量产车的影子模式

图 18的 T8是量产车，如果把刚刚开发完成对 AEB 功能部署到量产车，会出现两类大问题，漏报和误报。

漏报就是应该紧急刹车的时候没有刹车，会影响行车安全，造成重大的人身伤亡事故。但是如果为了减少漏报，将相关触发条件的阈值放得较为宽松，就会出现大量的误报，就是俗称的“幽灵刹车”，严重影响驾驶体验。

影子模式就是用来解决这个问题。其基本原理很简单，当我们的 AEB 功能实际装车后，会让所有相关的传感器、算法逻辑、AEB 功能的触发都正常运行。但是在功能触发后，应该实际执行紧急刹车动作的时候，停止执行。同时把触发时间点前后一段时间的传感器数据、自车的状态数据、驾驶员的驾驶行为数据等信息，加密脱敏后回传到云端进行分析。这里有几个关键点：

1.触发数据记录规则的设定与更新

2.数据记录与回传能力

3.软件 OTA 能力

设定数据触发的规则是为了找到尽可能多的漏报和误报的场景。所有影子模式下功能被触发的场景，一般都应该记录下来。这里会有大量的误报场景。甚至可以在初期将相关阈值调低一些，以获取较多的触发场景进行分析。然后调整规则，让误报逐步减少。但减少误报可能会增加漏报。

漏报的触发规则可以是检测到车辆撞击、驾驶员紧急刹车，所以漏报后的数据回传是一个亡羊补牢的过程，每一个漏报可能是一个悲伤的故事。

触发规则的设计是为了找到对算法改进有用的数据。所以往往会针对算法的能力弱点进行设计。比如根据不同传感器获取了不一致的结果时，一定有一个是有问题的，这可以是一个触发规则。或者算法对隧道的效果较差，也设定进入隧道前开始触发数据记录（根据定位数据触发）。也就是说触发规则的定义应该可以非常灵活。

在车载终端执行触发规则时，可以选用合适的规则引擎工具，具体规则可以由算法专家根据需要编写，再下发到车端。

数据记录和回传到能力也是影子模式的关键。量产车与专业采集车不一样，受限于存储与计算资源，并不能记录太长时间的数据。一般来讲软件设计时会在内存中时刻更新一个时间窗口内的数据，包括传感器数据（0级语义的原始数据和各级语义提升后的数据），规划决策的关键数据、软件运行中的关键日志信息、车辆总线数据等。数据记录被触发时，才会把内存中的数据写入持久化存储。如果遇到严重事故，数据落盘可能会失败。这些数据来源与不同的模块，如何统一记录需要做好设计。数据回传通道一般会利用智能座舱域的对外网络通讯能力。所以数据记录和回传能力是要在车辆开发阶段就进行专门设计的。

根据回传数据修正的算法和软件需要能更新到车辆上，所以车辆必须要有 OTA 能力，至少对相关的自动驾驶软件部分具有 OTA 能力。

另外数据记录触发规则的 OTA 和整个自动驾驶软件的 OTA 是两回事。前者简单很多，是为了更好的采集数据而调整采集规则，应该与软件的 OTA 分开处理。

从影子模式和正常功能启用模式并不是非此即彼的，可以有中间状态。比如某些非常确定的场景可以实际执行控车动作，而其他场景保持影子模式执行。逐步迭代更新到完全功能启用模式。

这里说句题外话，量产车从影子模式切换到完全功能启用的过程时间是不一定的，可能几个月，也可能一两年。但是这个切换的过程大多数情况下用户是不太清楚的。所以从负责任的角度看，车辆销售时应该避免夸大自动驾驶功能，尤其像 AEB 这种与人身安全密切相关的功能，避免给用户过高的预期，而降低了驾驶的警惕性，尤其是在车型量产前期。但为了新车型销售，往往会把自动驾驶功能作为宣传卖点，这里就有利益冲突。总之，在现阶段，用户驾驶时不要过度依赖自动驾驶功能，还是要专注驾驶、警惕危险，保证自身的安全。

基于云的并行仿真

基于云的并行仿真解决的是对大量场景高效率的全覆盖测试的问题。要准确理解这句话，我们只需回答以下几个问题：

1.大量场景从哪来，是个什么量级

2.为什么其他仿真形式不能满足大量场景的测试要求

3.基于云的并行仿真测试重点是什么，哪些能力不在它的测试覆盖范围内。

如前文所述，本文对场景的定义是“在特定的静态道路交通环境下（地图），多个交通参与者在一段时间内的行为及相互影响”。

设想如下场景。

场景:1：“一辆车顺畅的通过一个空无一人的路口”。

场景2：“一辆车通过路口时，前方车辆遇到红灯停下，本车也停下。绿灯后跟随前车通过路口”。这至少有两个交通参与者，红绿灯的状态变化也是场景的一部分。

场景3“车辆行进时突然有侧方来车，避让不及相撞”。

这些交通参与者的行为可以有无穷无尽的组合，还可以发生在不同的地图上。原型阶段和工程化阶段开发时我们只需针对少量典型场景进行开发和测试，重点是验证感知的准确性，控制执行的准确性。但在工程阶段后期和量产阶段，我们需要找到足够多的有可能会使得功能失效的场景。影子模式就是用来发现这些场景的重要手段。

如果把上述场景称为“基准场景”，根据关注的自动驾驶功能的复杂度，我们可以设计出成百上千，乃至更多的基准场景，当然我们需要尽量选择对现实交通有代表意义到场景。每个基准场景可以有多个参数。必如上面的场景3，我们至少可以设计几个参数，自车的初始速度，初始时刻位置，感知系统发现另一辆车的时间，另一辆车也可以有初始位置，和初始速度，这就是5个参数。交通参与者越多，参数也会越多。假设每个参数有5个可选值，那就是25个参数组合就是一个可被测试的场景，这里称为“特化场景”。如果有1000个基准场景，每个有25个特化场景，这就有2.5万个特化场景。这个数字就非常大了。

HiL测试能否对这些特化场景进行测试？答案是肯定的，而且可以做到非常精确。假设我们有一个完全自动化的HiL测试台架，5分钟完成一个特化场景的测试，一刻不停的进行测试，要完成2.5万特化场景的测试要将近三个月。就算有足够的预算可以多添置几个HiL台架，也是无法应对指数增长的特化场景数量的。所以不能指望HiL完成海量场景的测试。

要短时间内完成海量场景的测试，一方面要大大提高并行能力，一方面要降低单个场景测试的资源需求。首先降低资源需求的方式是仿真过程中不对零级语义数据做模拟，也就是不做视觉渲染，不做点云生成等，直接使用一级（含）之上的语义。其次是简化车辆动力学模拟。HiL测试是包含了基于真实车辆动力学模型的控制算法的。我们给线控系统下指令希望车辆加速度降低到多少，这是由运行在实时机上的动力学模型根据真实的车辆发动机参数模拟执行最后达到的。但在云仿真中，我们要求车辆加速度到某个数值，它就自然到了，怎么到的不用关心，上帝之手帮你搞定，这就是一个非常简化的动力学模型。

这样单个场景的仿真需要的资源大大降低，也就有了大量低成本复制测试闭环，达到并发测试的目的。但也意味着我们不会测试感知算法，不会测试控制算法，实际上测试的是各种规划和决策算法。

轻量化后的测试闭环非常适合部署在云平台上，不测试时不需要占用太多计算资源。需要测试时临时开启大量资源并行执行，测试完成后释放资源。

3.6.5.各种测试方式的对比

图18的 T1~T9是各种不同的测试环境，我们不能指望一种测试环境可以达到所有的测试目的，而是要在不同的研发阶段，在测试条件和成本等诸多因素的约束下，使用恰当的测试方式达到特定的目的。

下表总结了各种测试环境的关注重点。

测试方式 软仿真(T1) 软仿真(T2) PiL(T4) HiL仿真(T5) ViL仿真(T6) 云仿真(T9) 影子模式(T8)
工程化目标 为早期原型开发提供数据与真值 为原型开发提供全程闭环机制 为软件系统提供基于目标硬件到测试平台 提供基于目标硬件设备的全程闭环 在 HiL 基础上提供真实的车辆动力学 高效并行测试海量场景 挖掘长尾场景
并行高效率 ✭ ✭ ✭ ✭✭✭ ✭✭✭
一致性 ✭✭ ✭✭ ✭
可测性 ✭ ✭ ✭✭ ✭✭ ✭
动力学精确性 ✭ ✭✭ ✭✭✭
可靠性 ✭ ✭ ✭ ✭
渲染逼真度 ✭ ✭ ✭✭✭ ✭✭✭ ✰(线框)
场景数量 ✭ ✭ ✭ ✭✭✭ ✭✭✭

我们可以看到，软仿真阶段重点是让研发和测试团队能够尽快的建立基本的开发和测试闭环，对硬件设备的依赖尽可能少。T2因为是全程闭环，所以比 T1增加了对渲染和动力学模型的要求，但是对精确度要求不高。

PiL 测试重点解决一致性，可以通过在测试台台上部署多个设备，提供自动化测试的并行度。然后HiL 和 ViL继续增加精确性上的测试能力，但是因为较高的设备成本，一般只有少量的整套测试设备，测试成本较高。

到这一步已经可以完成对单个场景的高精度测试。然后通过云仿真建立大量场景并发测试的能力，通过影子模式采集数据挖掘基准场景，基准场景参数化后生成的海量场景通过云仿真进行高效率并发测试。测试中发现的重点场景可以再进行 HiL或 ViL 的高精度测试。

这样多种测试环境的组合使用，就构建了全方位的工程化测试能力。如果所有测试环境都完成了自动化测试能力的构建，并在各个测试阶段进行回归测试，就能很好的保证算法和软件的质量，这也是提高工程化能力的重要手段。

3.7.数据如何驱动

3.4.4阐述数据规模时提到，少量数据的作用是“快建立起‘单体算法、局部闭环、全程闭环’分别在‘原型环境和工程环境’的执行能力”。对应到图18，也就是原型阶段和工程阶段A1~A8、T1~T7的内容。这部分执行能力建立起来后，工程阶段的数据驱动才具备了前提条件。

工程阶段的数据驱动体现在两个方面：

1.采集的数据经过处理后（清洗、筛选、标注、检索）用于算法的开发，先在原型系统中进行验证，工程化环境具备后，也可以在工程化环境中进行验证。

2.具备了逐级递进的工程化仿真及测试环境后，可以利用第N级仿真环境作为第N+1测试环境的日志数据回放平台。回溯分析N+1级测试的问题，并在第 N 级仿真环境中建立可以进行自动化回归测试的测试用例。

下面分别说明。

获取对算法改进有效的数据

第1条很容易理解，尤其对于感知算法，目前普遍使用监督学习方式，根据采集的数据和真值进行训练，数据越多越好。需要针对不同的传感器、不同的算法类型选择合适的数据和获取真值的方式。这里的难点是对如何对数据进行管理，其核心就是通过一系列技术手段找到对算法改进有效的数据。

对于监督学习而言，典型问题领域使用哪种神经网络结构已经被业界研究的差不多了。在算法设计上的革命性改进很多年才有一两次。多数算法都是根据已有的论文实现，算法效果的优劣实际上比拼的是数据。

无论是哪种算法前期数据的有效性是最明显的。当算法效果提升到一定程度之后，就需要找到对算法改进有效的数据。因为只有这些数据才是具有“驱动性”的数据。

而要找到这些数据，一靠数据规模，足够多的数据找到有用的数据几率就会越大；二要依靠数据挖掘的手段。为了达到更好的挖掘效果，要从数据采集开始，到后续数据处理的各个环节，为后续能更好的进行数据挖掘做准备。这就是数据管理平台的作用。

数据回溯分析

数据驱动的第2层含义就是基于测试数据的回溯分析。图18中我们画了好几条标注为“回放日志”或“场景复现”的连接线。比如 T5 HiL台架的测试、T6 ViL 测试和T7量产车的测试，其测试执行时采集到的日志数据，我们都可以在 T4 PiL台架上进行日志回放执行。

假设我们在T7样车上进行 AEB 功能测试，测试场景是过马路时检测到行人紧急制动。在测试场使用假人和真实车辆进行测试。当某个参数组合（车辆的速度，行人出现的时机）下，10次测试会出现1次测试失败，车辆撞倒了假人，造成一定伤害。

我们可以通过在 PiL 台架或者专用的日志可视化工具中（如：ROS的 rviz 工具，图18中的 T1.5）中回放日志，分析错误所在。感知算法的各个环节、软件代码等都有可能出现错误。无论错误在哪，假如我们发现并修复了错误，那么怎么进行验证。

最直接的办法就是在到测试场上执行同样车测试场景。这里就有两个问题：

1.频繁的在测试场进行实车测试，成本高昂，效率非常低。

2.没法保证每次实车测试的执行环境完全一样。

就算不考虑测试成本的问题，第2条也让确认 Bug已经被修复非常困难。而且Bug的发生率是10次偶发1次。修复后就是测试100次都正确也不能认为 Bug 已经解决，因为可能这100次测试都没有达到 Bug 的触发条件。

这种情况下，至少有两种解决方案。

1.将出现错误的那次测试的实车数据在 PiL 台架上进行回放执行。这个执行与纯观看日志数据的结果不一样，PiL 上的回放执行是可以直接将录制日志中的视频图像数据直接注入的计算平台的视频捕捉接口，各算法和软件尽可能的运行只到错误出现的那个时间点。在这个时间点，验证bug 修复前后同的执行结果。这个数据回放是开环的，如果 bug 修复成功，该时间点后的日志时间就无意义了。

2.另一种方法就是在 HiL 台架上复现出错误的场景。同样的场景使用bug修正前和修正后的不同版本软件进行测试，比较执行结果。这个测试时闭环的。

工程阶段，专业采集车可以运行数百万公里并采集数据。我们可以分析提取大量的片段数据，每个应该触发或者不应该触发某个动作的执行。可以把这些片段数据在 PiL 台架上进行测试，验证与我们的期望是否一致。

到量产阶段，影子模式根据设定的规则回传大量不同场景的日志数据。但是量产车与专业采集车相相比，采集到的日志数据种类和数量都会少很多，一般达不到能在 PiL台架进行回放的条件。跟多的是分析场景，在 HiL/ViL 上进行高精度场景复现，验证代码在这些仿真场景下的行为。或者在轻量化的云仿真平台进行复现、修复、再验证。

3.8.高阶功能的闭环拓展

前文用 AEB 来举例子，只是为了在尽量单一的功能下，突出工程化的方法论。下面我们尝试将这个工程化的分析方法应用到更多的功能开发，以两个例子作为说明。

3.8.1. Level 2.5自动车道变更功能

自动驾驶的功能分级里有一个 Level 2.5 的说法。大意就是 Level3达不到，但功能又明显超过了 Lever 2 的范围，还有称为 Level 2.9 的，含义不言而喻。当然也有人认为 L1~L5这种自动驾驶能力的分级方式本身就不对。

3.8.1.1.L2.5是一个核心技术能力的临界点

不过从工程化的角度看，L2.5 的功能点是一个核心技术能力的临界点，非常关键的临界点。L2.5的典型功能就是“自动变道”，可以分为“人触发自动变道”和“完全自动变道”。为什么说它是核心技术能力的临界点？至少有两个原因：

首先，从算法角度看，从这个功能开始要做路径规划了。之前 L1、L2的功能只需要在某个时机对车辆运动实施横向或纵向的影响就行。但是变道不行，规划到控制的设计方式跟 L2有很大不同，难度也增大很多，倒逼对感知能力的要求也高了很多。

第二，从工程化角度看，自动变道的可能场景更多了（当然，这个对算法的要求高了很多）。L2的ACC、AEB、TJA 等功能， 每个功能基准场景20个左右就能覆盖到绝大多数现实情况了。但是变道的场景就复杂多了，涉及多个车道，道路结构有多种可能，多个车道都可能有车，交通参与者变多，组合形式多样。枚举出200个以上意思的基准场景是完全可以做到的。更多的场景意味着要更多的数据、更严格的测试，这都是工程化的难度。

之所以还有个“人触发变道”功能，说白了就是功能太难做不出来，先做个简单的。人来判断变道的触发时机，这样就排除了大量场景，相应对感知算法到要求也被降低了。整体从算法到工程化的难度都降低了。

3.8.1.2.工程化与数据驱动

我们使用本章的方法论，来看看“完全自动变道”功能进行工程化开发的方法。并与前文 AEB 的工程化方法相对照。

首先我们要分析出来涉及的各种算法，按照语义层级进行分割。按语义层级分割我们可以很方便的分析出哪些算法可以同时一起开发，高层级的算法可以使用仿真软件输出的低级语义。可以分析出算法需要的数据和真值，可以先通过仿真软件获取某些算法的数据集和真值。

图14中的所有算法基本上都会继续使用。为了换道，侧方的摄像头和毫米波雷达（一般是角雷达）是必须的，要观察后方来车，也需要后向的摄像头，以及后雷达。增加的算法至少有：

  • 侧方和后方都需要有对应的视觉算法，完成目标识别、分类、跟踪等
  • 基于前后摄像头、前后雷达、侧方摄像头和角雷达进行360度目标融合
  • 车辆的行为预测和轨迹预测不再是可选的，而是必须的。
  • 要根据其他车辆的当前轨迹和预测轨迹来规划自车的形行驶路径
  • 控制车辆按照规划的路径行驶

原型阶段的扩展

我们对照图18来分析在“完全自动变道”功能下的扩展。

首先对A1进行扩展，原来的 A1主要是前置摄像头的视觉算法（目标检测和分类、目标跟踪、车道线识别、还有基于视觉的测速等等），现在要新增后向摄像头、侧方摄像头的视觉算法，也要涵盖前视视觉算法的内容，但是摄像头安装角度不一样，看到的数据风格还是有差别，需要补充这些角度的数据进行训练。不过T1和 T2环境一样可以为这部分开发进行服务。

A2是基于1级语义开发的算法。新功能下同样可以找出需要基于1级语义开发的算法，比如“选择对变道动作有影响的目标”，“360度目标融合”等等。

A3在 AEB 的例子中是直接使用1级语义的数据完成控制算法的开发。这个控制算法里面其实隐含了好几级算法步骤。先要根据两车的距离和相对速度计算出对本车的速度规划（一段时间内的速度变化），然后算出对应的加速度变化，再转成对刹车和油门踏板的控制执行。因为这几个阶段经常都是同时在一个算法模块里完成，所以常常放在一起称为控制算法。但在“完全自动变道”的案例中，A3应该会被拆解成明确的两个算法步骤“轨迹规划”（也有叫“路径规划”的）和“轨迹执行”，也有可能在具体算法设计时做更精细的拆解。但这两个步骤都同 AEB 例子的 A3一样，利用1级语义进行开发和测试，可以在 T2和 T3环境进行测试验证。

A4代表的是几个算法的局部串接，相对 AEB 案例，“完全自动变道”的案例的单体算法更多，在这一步可以设计更多的串接组合，但串接的基本原理和测试环境仍然是一致的。

A5是原型阶段的最终形态，经过前面的逐级开发和串联，到这一步从感知到控制执行全部闭环（运行时闭环）连接在一起。AEB 案例和完全自动变道案例只是功能复杂度不同，在开发过程中所属阶段和测试环境也是一致的。

两个案例在工程化阶段的分析与上文原型阶段的分析类似，这里不再赘叙。

场景的挖掘

相较于 AEB 案例，完全自动变道功能因为传感器更多，涉及的场景更复杂，相应数据规模也会大很多。传感器配置齐全专业采集车能提供丰富的感知数据用于训练。从这些数据中我们也能挖掘出自动变道的场景。

专业采集车采集数据的过程中，驾驶员也会存在变道的情况。编写相应的检索算法分析采集到的数据（例如：提取40公里以上速度时驾驶员拨转向杆，过段时间又拨正的场景，再进一步分析）。这些数据里至少提供了三个算法的真值：

1.变道的时机

2.变道的轨迹规划

3.变道的控制执行

这些数据可以作为工程化阶段开发的数据来源，人工或自动的方式提取场景信息。因为专业采集是各种传感器数据非常完备，我们甚至可以通过在 PiL 台架上回放数据，来验证我们判断变道时机的算法是否正确。数据回放时可以回放1级语义的数据，也可以回放0级语义的数据来把更多算法纳入到测试执行中。

同理，在配置了足够传感器的量产车辆上，我们可以为“完全自动变道”功能设置影子模式执行。可以在用户拨转向杆时，触发数据记录（包括拨杆前一段时间的数据），到用户拨正时结束。也可以在我们的算法认为应该触发转向时开始记录（这时候用户没有主动执行变道动作），但是不执行变道动作。这两种触发方式，前者可能是我们判断变道的时机过于保守，后者可能是过于激进。这些数据回传后都可以用于我们进行场景分析，调整算法的规则或阈值，发现感知算法的问题点等等。

较多数量的基准场景参数化后产生的庞大的特化场景，就需要轻量的云仿真来进行测试验证。这些设施我们在前面的 AEB 案例中已经就绪。

------

可以看到，虽然“完全自动变道”功能比 AEB 案例复杂很多，但是整个工程化的原理和工具是通用的。只是在横向纬度进行扩充，变得更“胖”了。如果我们在 AEB 开发中就建立好了这一整套工程化设施，就能为新的功能开发带来便利，在架构一致的前提下在量的维度进行扩充。

3.8.2.Level 4的工程化

有了前面 AEB 和完全自动变道两个例子，我们再来看Level 4 自动驾驶的工程化之路也就会比较清晰了。

Level 4 自动驾驶在原型阶段，对应与图18的A1、A2的部分（0->1级语义提升和基于1级语义的算法，1->2级语义提升）依然存在。但是涉及的传感器更多，对应与这个阶段的算法也会更多，这需要算法专家根据具体的传感器配置和整体的算法架构去规划。不过这个步骤对应的测试环境依然可以是图中的 T1、T2。

对应与 A3的部分，与完全自动变道功能一样，也要拆分为“规划”与“执行”两个部分。但是规划部分的复杂度会远远超过自动变道功能中的实现。因为场景的空间范围、时间跨度、交通参与者的类型和数量都有很大的扩充。如何对这个阶段的“规划”与“执行”进行定义、设计和实现，是 Level 4自动驾驶的一个关键技术难点。但是其测试环境依然可以基于T2、T3来进行。(我在另一篇文章《智能驾驶域控制器的软件架构及实现(下)》的4.3节，叙述了一个多级规划与执行的机制，可以参考，有助于理解这一部分的复杂度)。

在工程化阶段的实现机制依然跟前面两个例子一样，但是单体算法和局部闭环的数量会多很多，需要逐个设计其测试方式。测试环境依然是 T4~T7。

但是在量产阶段，Level4自动驾驶跟之前的例子就会有很大不同。

一方面L4的影子模式是不能简单的在量产车上部署的。因为量产的 Level4车辆没有驾驶员，所以算法必须执行所有的控车任务，不能像之前例子一样，只触发数据记录，不具体控车。也就是说出了事故之后的“漏报”数据可以记录并回传，但是没法用影子模式解决“误报”问题。解决的办法就是在量产之前有很长一段时间，使用人类安全员坐在驾驶位上，随时准备“接管”车辆。“接管”动作本身就是一个数据记录的触发器。

另一方面，云端的并行仿真变得极为重要，不可替代。前面 AEB 和自动变道的例子中，云端并行仿真如果没有，基本上也能完成开发，只是测试不充分。但是在 Level4中却是必不可少的。同时功能上不仅仅是简单的复现预设的场景，还要能让场景中除了自车之外的交通参与者也具备一定智能，这样才能主动生成无限的场景组合。才能以低成本的方式通过仿真积累数十亿公里的驾驶里程，发掘更多的长尾场景。

这两个方面都在我们图18的量产阶段中都有定义，但是规模大小又上了一个数量级。我们可以看到 Level 4 自动驾驶的工程化原理依然是与之前示例一样的，但是数据规模比 L2和 L2.5功能的工程化有了数量级上的提升。

正因为这个阶段是 Level4自动驾驶工程化的必经路径，所以当我们看到路上带安全员的Level4的车辆在运行时，并不意味着其 Level4驾驶能力就很好了，也可能只是刚刚开始。这个阶段的开发投入巨大，也需要很长时间点积累，对数据驱动闭环的IT 基础设施和工具链都有很高的要求。

3.9.升维还是降维

自动驾驶领域人们常讨论的一个问题是“升维还是降维？”。也就是说是从Level1、Level2开始逐步升级到 Level4以上的自动驾驶能力；还是反过来，先具备 Level4的技术能力，然后消减功能和硬件配置，以较低成本向下实现功能量产。

这一节我们从工程化的角度对此问题进行分析。

3.9.1.自动驾驶的核心技术

自动驾驶的核心技术是什么，我的总结是两个，算法能力和工程化能力。

算法能力涵盖了各种传感器感知算法、融合算法、定位算法、规划算法以及控制执行算法等。感知算法又与相应的传感器技术密切相关。考核算法能力的基本目标就是能完整原型阶段的完整运行时闭环，也就是图 18中的 A5。这个阶段验证了预期功能在原型系统上的可行性。

工程化能力决定了预期功能是否可以从原型车走向大规模量产。搭建一个自动驾驶原型车和大规模量产的工程难度完全不在一个数量级。原型车我们可以不计成本（毕竟数量少），用高配的硬件设备，对可靠性要求也不高，反正随时出问题可以随时去解决。原型车也不用管AEC-Q100等规范要求，天气冷的地方别去，天热了拉一个空调排风口到后备箱就行。但是量产车辆要控制成本，一辆车的寿命是10多年，对零部件长生命周期的可靠性的要求非常高，否则车辆召回会带来重大的经济损失。在中国销售的车辆，必须能适应南北气候的不同，东北零下30度的气温，大多数原型车都会趴下。

3.9.2.工程化能力的体现

自动驾驶的工程化的能力至少可以现在以下几个方面：

  • 硬件系统的工程化
  • 软件工程化
  • 测试工程化
  • 数据工程化
  • 与车辆工程的集成

如果进行更专业的仔细分析，还能有更多。同时还需要一系列用来满足这些工程化能力的工具链体系。

硬件系统的工程化的体现最典型的就是一系列汽车零部件的质量标准，抗振的标准、电磁兼容性标准、散热的标准等等，我们常说的 AEC-Q100标准是对集成电路的，包含了对芯片的七个大类别共45项各种类型的测试。现在自动驾驶的计算平台已经妥妥地是一台高性能计算机了，板级的精密度已经接近智能手机了，实际对设计和工艺的复杂度比手机还高。这样一个设备要在车上颠簸10年以上，还要保证高可靠性，这在汽车行业也是从来没有过的事情。

相比硬件工程化还有很多硬性标准可以度量，软件的工程化更难度量。软件不比硬件，有时候质量差一些，功能一样能正常运转，只是问题被掩盖的更深。而软件的工程化，从需求管理和跟踪、概要设计和详细设计到编码实现和测试，是需要一系列的文档体系去管控研发过程的。常用的度量软件工程化的手段如 ISO9000标准、CMMI 能力成熟度认证、功能安全过程认证，也是在检查这些文档。

自动驾驶和智能座舱之外车载软件，功能复杂度和整体的代码量其实要低两个数量级，还有可能完全按照规范要求完成全部文档化跟踪。但是自动驾驶相关软件如果严格文档化，导致的研发周期拖长几乎是不可接受的。直接结果就是有人写文档就没人编码了。这也导致了软件的工程化建设更为困难。

所以自动驾驶的软件工程化要在质量和效率之间做平衡。这个平衡不是说牺牲质量换效率，而是说对于这些创新技术的研发，要在研发初期重效率，然后逐步提高对质量的管控能力，而不是一开始就要质量标准卡着软件研发无法寸进。这也是考验每一个自动驾驶软件研发团队进行工程化量产开发的难点。

关于测试的工程化，前文图 18基本上都是讲这方面，不再赘述。

数据工程化较少被提及，算法研究时一般都是基于处理得非常规整的数据进行。但是现实中我们用专业采集车采集的数据规模庞大，充斥着大量无效、重复的数据。要找到对我们算法改进有用的数据并非易事。我们会在后续文章中对此进行讨论、

3.9.3.影响工程化难度的因素

哪些因素会影响自动驾驶工程化的难度呢。

速度快慢

车速一旦慢下来，实时性要求就会被降低，很多软硬件的要求就会被降低了。工程化难度就会下降。比如自动清洁车5-10km 的时速，那对感知算法的帧率要求可以降低到每秒15帧（每帧行进距离不到20厘米）。软件也不用基于高实时的操作系统和中间件，用 ROS就完全可以满足。

载人与否

如果不载人，很多为了功能安全的设计就可以大大简化。行驶也不需要考虑人的舒适性，控制算法开发也可以得到简化。典型的如清洁车、洒水车、无人矿车、无人农用车、无人卡车等。

成本高低

如果量产车能承受较高的成本，自动驾驶系统的工程化难度也能降低。比如一辆无人重卡售价可能到上百万，那么10万元一套的自动驾驶系统就是可以接受的。但是15万左右的乘用车，可能就需要把成本压缩到2万以内甚至更低，还要达到工程化就难了。

应用场景

应用场景应该是对工程化难度影响最大的。前文谈到，从 Level2.5功能开始，场景的复杂度大大增加，到 Level4,会有无数的长尾场景需要被发掘和适配，所以对数据驱动有着非常现实的要求。

我们也可以换一个思路，如果不能挖掘出所有的长尾场景，那就把这些场景消灭掉。所以我们看到封闭园区的 L4低速摆渡车、城市固定路线的大巴车、封闭园区内固定线路的矿车、港口的无人卡车、封闭农场的农用车等等。这些场景通过“封闭园区”、“固定线路”的方式圈定了可能出现的交通场景的范围，以此来降低工程化过程的难度。

3.9.4.升维 vs 降维

核心算法的难度和工程化难度是实现自动驾驶的关键难点。图23将常见的自动驾驶产品（或应用场景）在这两个纬度上进行了一个分布，便于比较。这只是一个粗略的示意图，两个轴也没有精确到比例尺含义，仅仅是相对位置提供一点参考意义。

我们可以看到，Robotaxi是在两个纬度上都是最难的。在原型阶段实现各种算法能力已经很不容易了，要到大规模量产应用还要克服很多工程化的难题。正因为这样，以 Robotaxi 为目标的开发团队，要么做到原型阶段就很难继续，要么在努力工程化的过程中，通过自主研发或整合其它工具，构建了最完善的自动驾驶研发工具链体系。

很多企业为了能尽快具备量产能力，也会选择先专注于工程化难度较低的应用场景。比如无人矿车、封闭园区的无人巴士等。

已经有L4研发能力的企业，希望能把L4研发过程中建立的技术能力用来进行 L2.5~L3级别的开发,实现“降维打击”。

老牌的 Tier1企业，因为具备了比较丰富的 L1/L2的工程化经验，往往会选择以 L2研发能力为出发点向右上方攀登，与降维对应，一般称为“升维”。究竟谁更能成功呢，众说纷纭。

其实从本文重点突出的工程化角度来看，“升维”和“降维”之争很容易就能分辨清楚。

对于具备了 L1/L2工程化量产能力的企业来说，如果在开发过程中并没有建立起本文所说的数据驱动的工程化体系（图18所描述的全套环境和工具链），那么它在走向高阶自动驾驶的过程中将面临两个纬度的挑战，之前工程化能力在新的挑战中有作用但作用有限。典型的，就是之前基于黑盒子芯片加感知算法来实现 L2功能的团队。反之如果在 L2的研发中建立了完善的基于数据驱动的工程化工具链，那么就是需要重点突破算法能力，工程化能力是在“量”上进行扩充，难度相对较小。

对于具备了 L4开发能力的团队，如果仅仅是搭建了几台原型车，能在有限区域中做一些演示。没有完善的工程化能力和工具链，即便做L2/L3 量产开发，也没有明显的优势。反之如果在 L4的开发中，建立了完整的数据驱动的工具链并且采集了大量的数据。那么在转而开发低阶自动驾驶功能时，一方面算法难度会降低，一方面可以从已经采集的数据中挖掘有用的数据，工程化的工具链体系也是现成的，这样才具有“降维打击”的能力。反而是要在成本控制上做更多的努力。

所以不是简单的“升维”和“降维”，要看具体的两方面技术能力的储备。

3.9.5.自动驾驶路权

有些地方开始有无人的有轨电车（上海张江线，成都璧山云巴），这些场景逐渐可以被无人驾驶的大巴来实现。这里面其实隐含了一个路权的问题。从有轨车辆中我们比较容易观察到路权的作用。

高铁作为有轨车辆独占了路权，城市的有轨电车是跟其它车辆共享路权，但是有轨电车有优先权。乘用车的 Level4特别是 Robotaxi 之所以会产生大量的长尾场景，就是因为自动驾驶车辆在和人类驾驶的车辆在平等地共享路权，某些情况下甚至是在争抢路权。虽然有交通规则存在，但是这个规则过于宽泛。比如交通规则只会规定两个车道直接是否可以变道。但是什么情况下变道却是人独立做出判断，每个人的驾驶习惯都可能不同。所以人的行为的太多可能性导致了场景的复杂度。

从路权的角度看，那就把自动驾驶车辆的路权和人类驾驶车辆的路权分开就好了。封闭园区就是自动驾驶车辆独占了路权、固定线路是没有铺设物理轨道的“有轨”，实质是提高了该路线自动驾驶车辆的路权优先级。如果在这些自动驾驶车辆具备路权优势的道路上部署路侧的传感器和 AI 能力，给车辆提供环境信息，一方面能减少车辆的成本，另一方面车跟路就能协同工作。场景的复杂度进一步降低，意味着工程化难度也被降低。

所以，从工程化落地的现实角度看，自动驾驶的发展很大程度上将会是自动驾驶车辆对人类驾驶车辆在路权上的挤出，先有部分道路只允许自动驾驶车辆运行，最后发展到把人类驾驶的车辆彻底赶出去。就像汽车赶走了马车一样。

----

在当前火热的自动驾驶发展过程中，工程化能力确实不如核心算法那么耀眼夺目，但它确实是自动驾驶技术真正走进人们生活的关键难点。负责工程化的大量工程师们可能没有算法科学家、算法专家那样崇高的头衔和漂亮的履历，但他们确实是在一点点的克服各种工程难题，让自动驾驶技术早日走进现实。好比在新冠疫情中，特效药和疫苗代表核心算法，隔离管控、流调等管理手段代表工程化，两者都要做好、互相配合才能得到最完美的结果。

全文结语

本文先论述了自动驾驶的研发闭环和产品闭环，在此基础上继续论述了数据驱动闭环的基本原理以及自动驾驶工程化的方法论。

我们知道，自动驾驶是一个庞大的产业链，从第2章的图11中的各层子产品角度看，每个子产品方向背后就可能有很多不同的公司在开发。同样，图18中的各种工程化工具链也有各种供应商。

有的企业可能擅长原型阶段的算法研究，但是在工程化落地方面缺少资金、数据和经验；有的企业可能对 Level2方面有很好的工程化经验，但是对 Level2.5 及以上的技术缺少算法积累。汽车 OEM 有资金上的优势和理论上最好的数据采集通道（量产车），但是在如何构建整套IT 系统并利用数据上缺少经验；以算法起步的企业有较好的算法研究能力却缺少足够多数据来源。所以产业链上下游的紧密合作才能有利于自动驾驶系统真正的走向工程化落地。

目前自动驾驶行业内都非常强调“自研”或者“全栈自研”。排除掉宣传因素来看，一个企业完成所有的技术栈和工具链是不现实的，或许只有极少数企业能够覆盖到大多数的技术栈。一方面技术积累和团队培养的时间周期会很长，会在竞争中失去先机；另一方面整个行业的人才资源也不足以支持这么多企业去完成“全栈自研”。

所以，从 Tier2,Tier1到 OEM，每个企业都应该找到适合自己的“自研”之路。芯片企业最熟悉自己芯片的 AI 能力，可以开发基础的算法以及算法模型转换到工具链；擅长硬件设计的企业可以使用合适的芯片做出计算平台并集成好操作系统，以硬件 Tier1 的身份向多家 OEM 提供硬件计算平台或域控制器。软件 Tier1开发完整的功能适配不同的硬件平台，同硬件 Tier1 合作向 OEM 完成功能交付。OEM 可以把自主研发的重点放在工程化能力的建设上（图18中的工程化阶段和量产阶段），这部分需要大量的投资以建立数据驱动的能力，而数据通道本来就是 OEM 的固有优势。OEM 另外要重视的是数据如何能够被充分的利用，自己使用的同时开放给算法企业和软件 Tier1使用。而这些也可以通过多方计算、联邦学习之类的技术实现，将会在后续文章中介绍。

预告

根据本文的论述，我们可以看到其中涉及了非常庞大规模的数据，10PB 级别也是刚刚起步；涉及大量人工智能算法的训练；涉及多层次各种目的的仿真测试；需要全面的自动化的 DevOps 系统进行高效率研发和测试。这些都要求有一个坚实的 IT 基础设施来支持

如何打造自动驾驶的数据闭环相关推荐

  1. 深度解析，教你如何打造自动驾驶的数据闭环

    最近自动驾驶和数据闭环结合在一起,原因是自动驾驶工程已经被认可是一个解决数据分布"长尾问题"的任务,时而出现的corner case(极端情况)是对数据驱动的算法模型进行升级的来源 ...

  2. 自动驾驶汽车数据闭环方法分析

    算法与数据双轮驱动才能实现更成熟的自动驾驶技术,也是自动驾驶技术落地的必然选择.随着时间的推移,各家公司在算法方面的差距会逐渐缩小,真正影响自动驾驶技术水平的其实是数据,海量数据会助力自动驾驶技术再上 ...

  3. 华为天才少年一人打造自动驾驶！

    点上方计算机视觉联盟获取更多干货 仅作学术分享,不代表本公众号立场,侵权联系删除 转载于:新智元 AI博士笔记系列推荐 周志华<机器学习>手推笔记正式开源!可打印版本附pdf下载链接 B站 ...

  4. 打车平台Lyft获Magna 2亿美元投资，携手打造自动驾驶汽车

    Root 编译整理 量子位 出品 | 公众号 QbitAI 目前,汽车共享出行的里程数,占所有汽车行驶总里程数的比例还不到1%. "如果要增加到80%,"打车平台Lyft CEO ...

  5. 智能网联汽车 自动驾驶地图数据质量规范

    1 范围 本文件规定了全场景下的自动驾驶地图数据质量检测的基本要求.质量检测内容.质量检测指标.质量检测流程.质量检测方法.质量检测结果的判定与质量报告编写的要求等. 本文件适用于自动驾驶地图产品的质 ...

  6. 百度智能云数据众包，更安全、更优质的数据能力，打造自动驾驶超智“双眼”...

    自动驾驶技术近年来倍受资本和行业市场关注,越来越多的车企.零部件供应商和解决方案供应商投身其中.在资金和政策的双向加持下,行业发展迅猛,几成燎原之势. 而其中最大的技术瓶颈无疑是在感知能力上,除了算法 ...

  7. Imagination推最强多核GPU系列！AI算力达24 TOPS，支持自动驾驶和数据中心

    芯东西(公众号:aichip001)文 | 心缘 芯东西10月13日报道,刚刚,Imagination Technologies宣布推出又一大重磅新品--全新IMG B系列GPU IP. 这是其第一个 ...

  8. 北京正研究“车路协同”模式，将打造自动驾驶测试专用道路

    据透露,第一条自动驾驶测试专用道路将落地亦庄. 今天上午,北京市交通委相关负责人在一档节目中透露,为了推广自动驾驶技术,北京将在未来对道路设置进行改造,实现"车路协同",而第一条自 ...

  9. 福特打造自动驾驶汽车，你的专属安全智能护卫

    福特开启无人驾驶汽车夜间测试项目,自动驾驶汽车成为可能. 人们对科技的需求和创新是永无止境的,无人机之后,人们以相同的概念引入了无人驾驶汽车,开车的人都知道,开车时的注意力需要高度集中,时间长了不仅仅 ...

  10. 自动驾驶系统的学习笔记

    1 自动驾驶系统综述 请参考博文<如何打造自动驾驶的数据闭环?> 2 系统的响应时间 人类驾驶员的响应时间是400~600ms:

最新文章

  1. CentOS 6 安装极点五笔拼音输入法
  2. Linux sar性能分析
  3. 基于数据挖掘的旅游推荐APP（四）：“我的”模块
  4. 【干货】2014年值得仔细研究的十大神级文案
  5. 数据绑定（三）为Binding指定绑定源的几种方法
  6. /bin/sh -c的必要性
  7. Python-读取文件:API介绍
  8. JavaScript回顾与学习——条件语句
  9. 论文浅尝 | 动态词嵌入
  10. fork vfork exit _exit (转)
  11. C#中Windows Media Player控件使用实例|方法
  12. 全链路数据血缘在满帮的实践
  13. 简述ip地址的abc类如何划分_IP 地址分类及 ABCDE 五类是如何划分的
  14. 树莓派添加开机自启动
  15. 探秘 Containerd 容器中的 Shim 进程
  16. JACTF misc wp
  17. 安卓实现浏览器app
  18. BZOJ 2716/CH 4701 天使玩偶
  19. 二维图形旋转公式的推导
  20. 9、Horizon 连接服务器CA证书配置

热门文章

  1. CarMaker入门第二课-创建第一个TestRun
  2. Java编程语言简述
  3. 国庆蓝牙耳机最强选购攻略，2020不容错过的精品蓝牙耳机
  4. matlab画动态简单轨迹,MATLAB中绘制质点轨迹动图并保存成GIF
  5. 暑假作业点评：运动会管理系统设计说明书
  6. 学习CNDS博客写作
  7. DjVu Reader Pro for Mac(djvu阅读器) v2.2.3激活版
  8. 计算机网络安全 第一章绪论
  9. 5 EDA技术实用教程【基本语句2】
  10. QSqlRelationTableModel使用示例