▲ 一个自动驾驶仿真软件的运行可视化界面
什么是自动驾驶仿真？个人来下一个不成熟的定义，自动驾驶仿真是借助计算机虚拟技术对实际交通系统进行某种层次的抽象。
仿真的重要性已经不容置疑，自动驾驶想要大规模商业化落地，仿真是绕不过去的。为什么？因为自动驾驶的核心痛点之一就是成本，而仿真测试能把大量自动驾驶开发和测试的成本转化为GPU的物料成本和工程师的知识经验成本，进而大大缓解该痛点。
当前，几乎每家自动驾驶公司或涉及相应业务的公司都在进行仿真相关的工作。但同是仿真，不同公司的水平却参差不齐，不同工程师的仿真工程经验也有很大差异。如何才能搭建一个良性的高效的自动驾驶仿真体系？如何才能成为一名优秀的自动驾驶仿真工程师？这是公众号的未来讨论核心。
搭建自动驾驶仿真体系是一个下限很低，上限很高的事情。下载一个仿真软件，它可以是MATLAB，CarSim，也可以是CARLA、Lgsvl，或者是Prescan、VTD，通过文档学习一下仿真流程，就基本可以开始进行相关工作，这是大多数人对自动驾驶仿真的认识，也是这个细分领域门槛不高的佐证。但需要清楚的是，一个良性的自动驾驶仿真体系是一个标准的系统工程，它包括广义上的场景、系统以及评价三个主要模块，贯穿自动驾驶的开发、测试、落地以及运营等整个流程。有人说，需要让最熟悉自动驾驶系统的人来承担仿真相关工作，这个观点从某种程度上来说是正确的。
接下来就让我们按照这三个主要维度，来谈谈一个良性的自动驾驶仿真体系应该包括什么。
1、仿真场景
场景是仿真体系的开端，它在整个体系扮演着极其重要的角色，但其重要性相比于仿真系统却相对容易被忽略。而且随着仿真系统和评价体系的逐渐完善，越往后期，场景在整个体系中扮演的角色越重要。场景之所以有此地位，本质是因为其是对自动驾驶相关数据的一种价值提炼，是发挥数据价值的必须且高效的途径之一。基于场景的测试方法可以弥补基于里程的测试方法的局限性，在提高系统开发效率、产品落地效率方面都有重要作用。
以光照程度为自变量的场景
场景是公众号后期要讨论的核心内容之一，主要会围绕场景的形式和内容两方面展开。
1.1 场景形式
场景形式指的是场景数据的具体呈现方式。为什么要着重介绍场景的形式？核心在于三个字：标准化。标准化的场景体系的作用包括但不限于以下几点：
目前相对比较通用的场景形式是由德国PEGASUS项目提出的功能场景-逻辑场景-具体场景三层体系。举个例子，功能场景可以描述为，“自车（被测车）在当前车道运行，在自车前方有前车加速运行，自车跟随前车行驶。” 逻辑场景则提炼出关键场景参数，并赋予场景参数特定的取值范围，如以上描述的场景可提取自车车速，前车车速以及加速度，自车与前车距离等参数，每个参数都有一定的取值范围和分布特性，参数之间可能还存在相关性。具体场景则需要选取特定的场景参数值，组成场景参数向量，并通过具体的场景语言表示。以上示例只是为了说明三层场景体系的内涵，具体的表述形式会有更多细节，需要有更多的标准和约束。
三层场景体系
具体场景需要转换为计算机可理解的语言即场景语言才能发挥作用。场景语言是一种可用以描述自动驾驶系统待处理的外部环境的计算机可解析的形式化语言。
场景语言的具体形式不一。针对功能场景、逻辑场景以及具体场景都有相应的场景语言：如针对前两者，有M-SDL等高级场景语言；针对后者有OpenSCENARIO、GeoScenario等。不同仿真软件支持的场景语言也不同：如CARLA和lgsvl等都支持基于Python脚本的场景语言；CARLA、VTD和最新版本的51Sim-One1.2等支持基于XML的场景语言。此外，protobuf、JSON都可以作为承载具体场景语言的格式。
这其中的关键不在于语言本身，而在于能全面且不冗余的覆盖交通元素的体系标准。目前已有一些机构在推相应的标准，比较成功的是由VTD发起的由ASAM（国际）/ CASAM（国内）推动的OpenX系列。公众号在后期会围绕OpenX系列展开较多介绍，因为这是目前看来最有可能推广开来的一个标准。具体也可以关注中汽中心周博林周博的分享。
M-SDL 一种高级场景语言
1.2 场景内容
1.2.1 基于知识、数据的场景来源在确定场景形式后，后期日常工作会围绕场景内容的构建展开。场景内容有两个主要来源：知识和数据。其中，基于知识的方法主要是依赖于具体场景结构，综合借鉴各相关学科的知识，分析自动驾驶系统需要处理的静、动态元素类型，并结合自动驾驶系统的测试需求构建场景。基于数据的分析方法则是从采集的自然驾驶数据中分析提取出有价值的场景。
基于知识、数据的场景构建方法最终都可以生成测试所需要的具体场景，这部分也是公众号后期要展开讨论的核心内容之一。
知识驱动和数据驱动的场景生成方法
1.2.2 具体静、动态场景内容从具体元素的角度看待场景内容，可将元素分为静态元素和动态元素（半动态）两部分。
静态场景元素的分析和提取相对较简单，主要包括道路、基础交通设施（交通标线、交通标志、交通信号灯以及抽象的交通规则等）、天气、光照、其他建筑物基础设施等，难点在于一些连续量（如光照和雨量）的取值范围分析，以及不同静态场景元素之间的约束关系。
动态场景元素的提炼和转化相对较为困难。主要原因如下：
-
除了静态场景元素固有的连续值取值范围和多约束问题外，交通行为是在一个高度复杂的存在多种约束条件的环境下的高交互性行为；
-
交通参与者类型众多，包括重卡、轻卡、乘用车、电动车、行人等，每种交通参与者都有自己特定的动态行为模式；
-
具体的动态行为模式有多种类型：带时间戳的轨迹数据、基于行为分类的数据（如跟车、换道等）、基于Agent的动态行为；
-
在实际提取动态交通数据时，需要考虑采集车自身的影响，即考虑处理交互性；
-
简单动态交通元素的分析以及大规模复杂交通元素的提取和具体形式有较多不同，需要不同的技术手段。
以上都是在提取动态场景内容时需要考虑的问题，也是公众号未来会重点展开的内容。
动态交通流示意
1.2.3 场景提取pipline最后再大致回顾一下场景提取的pipline。基本流程是数据采集、数据提取和数据转化。传统的数据采集工作，包括数据存储、数据标注、数据分类在企业中往往由基础架构部门负责，这部分在理论上和实践上也已经相当成熟了。仿真需要重点关注的是如何高效的从数据中提取有价值的场景，并将其转化为具体的场景格式。
2、仿真系统
仿真系统是整个仿真体系中承上启下的部分。它播放仿真场景，测试研究对象，通过仿真数据接口提供被测对象的运行表现数据。仿真系统是当之无愧的仿真体系核心，前面抛出有个仿真软件就能进行仿真工作的观点，只是为了说明构建仿真体系的下限。但在实际应用工作中，仿真系统的性能也决定着整个仿真体系的上限。
接下来我们来谈谈应该怎么看待仿真系统，围绕着仿真系统又该重点关注什么工作。
2.1 仿真软件 | 被测对象 | 通信环境
首先需要明确的是，仿真系统不止是仿真软件。从狭义上来说，它是仿真软件、通信环境与被测对象的集合；从广义上来说，它又包括云仿真环境等。
其次需要明确的是，仿真系统是具体的工具，是“术”。而在构建仿真系统时，作为仿真工程师在关注“术”之余，也需要关注“道”的部分。不同仿真软件、不同的通信环境、不同的被测对象都有各自的特点，作为仿真工程师需要了解不同仿真模块各自的共有属性，并充分理解并利用不同对象的特异性。关键是做到兼容并包，调节需求和客观仿真资源之间的矛盾。
仿真软件
在了解不同仿真软件的共有属性方面，可以学习基本的pipline。从比较粗的粒度上看，基本的仿真pipline是加载静态地图、构建动态场景、接入被测对象、导出运行数据、结果评价处理。这之后就基本可以上手一个仿真软件，剩余的深入拓展工作也可以围绕整体流程向外展开。
在了解不同仿真软件的差异方面，需要明白市面上各类软件各自的特点，集中精力是正确的，但是封闭眼界并不可取。单就自动驾驶仿真软件而言，Prescan、VTD、Panosim、51simOne、GaiA等商业自动驾驶仿真软件，CARLA、lgsvl、Airsim等开源自动驾驶仿真软件，稍微粗糙一些的DeepDrive、一些基于ROS构建的自动驾驶仿真平台，就都有各自的可取之处。
CARLA Simulator
另外，还有一些专精于特定功能仿真的软件。如在交通流仿真方面有Vissim、SUMO、High-env等；在动力学仿真方面有CarSim、Trucksim、Carmaker等软件；在静态场景仿真方面有一些大规模城市构建仿真软件；在构建复杂交通流场景方面也有一些软件。这些软件都可以纳入到整个自动驾驶仿真体系里来。我们会以后也会重点展开介绍各软件的不同点。
SUMO Simulator
被测对象
根据被测对象的不同，业界常用的仿真工具链包括模型在环（MIL）、软件在环（SIL）、硬件在环（HIL）、整车在环（VIL）。目前SIL在各类公司应用范围最广，但其他各类也都有自己的独特优势和测试必要性；按照自然开发的流程，完整的测试过程也确实需要兼顾这几种平台。站在具体实践角度，每种在环仿真平台有适配于自己的仿真软件和技术栈，其中部分要掌握的技术如下：
-
MIL与SIL相似，最基础的问题是通信环境构建，往上进一步则需要研究仿真效率、实时性、同步性等；
-
-
VIL是大工程，需要投入大量人力物力来搭建专门的实验室，目前一般都应用于驾驶员在环仿真。
各种技术栈也是我们未来要探讨的重点之一，SIL会是主体，其他几种优先级会放的低一些。
通信环境
最后再来说说通信环境，即仿真软件和被测对象之间的信息传输环境。其基础是利用计算机网络的相关知识完成信息传输工作，也即各种JD描述中提到的开发仿真接口。
一般情况下，可以通过通信中间件处理仿真数据，并将其转化为被测对象所需的数据格式进行传输。中间件类型有很多，常用的可能有基于ROS的中间件、基于AutoSAR的中间件等。关键问题是结合具体测试需求选择合适的中间件；以及如何减少仿真消息的延迟和丢失以保证通信效率，这和仿真的可用度密切相关。
