自动驾驶仿真及其工具链（6万字扫盲）

1.1.3 车辆动力学仿真

在自动驾驶仿真过程中，需要借助车辆的动力学模型，来对 决策、控制算法进行客观的评估 。基于现实的物理模型，动力学模型给汽车定义了其 操控的边界 。举个小例子，对于0-100km/h加速分别为5秒和15秒的两辆车，在加速、刹车的决策上一定是存在差异的；一辆保时捷跑车和一辆重型卡车，转弯时允许的最高速度也一定是不同的。

举个例子： 某SUV自动驾驶车辆需要在110km/h的车速下紧急转弯避险，决策系统决定向左猛打方向，但由于动力学建模不准，自动驾驶系统完全不知道在此车速下会发生严重的转向不足，因而不能成功避险，并且由于车辆重心较高发生了侧翻。而同样的情况下，一辆保时捷Panamera就轻松愉快地完成了此次避险动作。

结论就是：就算是自动驾驶系统，也得知道车子允许操控的极限在哪里。

由于零件数量众多，车辆的动力学模型是极其复杂的，主要包含车体、悬架系统、转向系统、制动系统、动力系统、传动系统、硬件IO等多个真实部件的车辆模型。将这些被控对象模型参数化后，即可将真实的线控油门、线控转向、线控刹车系统集成到仿真平台中进行测试。

客观上讲，完整的车辆的动力学建模较为困难，十分依赖于过往的经验积累。因此行业顶尖仍然是传统的仿真软件供应商、以及整车厂。专业的车辆动力学仿真软件，有 CarSim、CarMaker、VI-Grade、VeDYNA 和 PanoSim （中国）等。根据笔者调研，目前来看，如 长于动力学仿真的软件不会被轻易替代。 但同时，该领域的理论体系已很成熟，基本没有太多新的方法论出现，因此在自动驾驶仿真领域并不算热点。

值得注意的是，以往的汽车动力学模型是基于燃油车而构建，而未来的自动驾驶车辆基本是电动车，其动力学特性与燃油车有很大区别，例如内燃机和电动机的输出转速-扭矩曲线有很大差别，电池的重量、重量分布也会对整车的动力学特性产生很大影响。

1.1.4 传感器仿真

传感器仿真即在虚拟环境中对自动驾驶车辆的传感系统进行重建，主要对象有摄像头（Pinhole，Fisheye），Radar，LiDAR，GPS，IMU、超声雷达等。现实中的传感器并不完美，因此仿真系统中也要对传感器的误差项进行建模。例如对Camera而言，还需要对其噪声、畸变、色差、像差等误差项进行建模。最后，虚拟的传感器需要提供丰富的选项配置以及支持多种输出方式，例如 Raw Data，Ground truth。

值得一提的是，Ground truth模式下， 虚拟传感器输出的场景带有100%正确的标签，即 带有100%正确语义的图像/ 点云，相比于现实中采集的数据需要经过耗时且昂贵的人工标注， 此种虚拟采集的数据成本极其低廉，对感知系统中的检测、分割、跟踪算法，以及决策系统的算法模型训练也有着很大的推动作用。

1.1.5 通信环境 / 仿真接口

最后就是仿真软件和被测对象之间的 通信环境， 也就是所谓的仿真接口，其基础是利用计算机网络的完成信息传输。

一般情况下，可以通过 通信中间件 处理仿真数据，并将其转化为被测对象所需的数据格式进行传输。最常用的有 基于ROS/ROS2 、Cyber RT（百度研发）的中间件等，其关键在于如何降低仿真消息的延迟和丢失，以提升系统实时性。

1.2 仿真软件的发展：从基于模型设计到数据驱动——以场景为核心

总结下来，当前自动驾驶仿真平台的主要组成为：静态、动态场景的搭建、车载传感器的仿真、车辆动力学的仿真、以及自动驾驶算法的接口；此外，还会利用云技术进行规模化部署仿真。而此种仿真体系的结构并非一蹴而就的，其经历了一个发展历程。

1.2.1 V-Shape开发流程

现阶段汽车软件开发主要采用V-Shape开发流程，分为 设计开发流程 （左）以及 测试验证流程 （右），包括低级别的L1、L2的ADAS功能开发流程也是如此，其具体过程如下：

在V-Shape开发流程中一个重要的概念是X在环（X in the loop），即在不同阶段采用不同的测试方法，包括：模型在环仿真（Modole in Loop-MIL）— 软件在环仿真（SIL）— 硬件在环仿真（HIL）—. 整车在环仿真（VIL）等测试方法，其具体区别如下：

可见测试过程从“虚拟”一点点过渡到“真实”。 此种开发模式的优点是流程严格有序，每个开发阶段都对应的测试阶段，环环相扣，这样能在提升开发效率的基础上有效保证软件的质量，对于开发质量和安全性有着极为严苛要求的汽车工业而言十分重要。

1.2.2 弱场景，重动力学，基于模型MBD，围绕Simulink为中心的仿真

早期的仿真主要是以动力学仿真为主，用来对整车的动力、稳定性、制动性等 基础车控进 行建模仿真，例如前面提到的Carsim为代表的软件即是如此。 而随着一些相对简单的辅助驾驶（ADAS）功能的开发，场景开始被引入。

于是，能够提供简单的道路环境，可以对交通车辆、行人等动态要素进行编辑，以及布局简单传感器模型的ADAS开发仿真软件开始出现，例如Prescan。同时，以往的那些纯粹的动力学软件也朝着这个方向进化。

此时，对于V-Shape左侧的 设计开发流程， 其方式主要是以 基于模型的设计MBD（Model Based Design）为主（ISO26262也要求车规级软件需要基于MBD开发） 。大多数公司是基于Matlab Simulink提供的工具箱来搭建快速模型，然后导入用Prescan等软件创建的较为简单的场景、CarSim等软件创建的动力学模型，然后对模型进行仿真验证。然后利用Simulink即可自动生成工业级的C代码，并烧写到控制器上，应用dSPACE、SpeedGaot、NI等公司提供的 快速原型硬件 进行下一步的HIL、VIL测试验证流程。

运用此开发流程，从算法构想、到快速原型、再到SIL、HIL的仿真测试，最后到工业部署一整套的开发流程得以快速实现，围绕Simulink的工具链的功能安全和测试验证流程严格且成熟，保证了车企规模化的稳定量产。比如：

1. 当前大多 ABS防抱死 、 ACC自适应巡航 等代码都是由Simulink开发后转成嵌入式平台的C代码；
2. 现行L2级别的ADAS功能，基本仍然是依靠Simulink来写控制逻辑和算法，也包括很多新势力整车厂；

但该套开发方案的局限性也比较大： 软件仅仅运行在单机上，由于Simulink的固有的“建模”属性，使得其十分偏向于底层运动控制算法以及车辆动力学层面（即操控性）的验证。因此，一些L1、L2级别的ADAS功能在使用这套 “弱场景、MBD、X in Loop、以Simulink为中心 ”的开发方案尚可满足需求。

但是，L3+级别的自动驾驶功能极为复杂，代码量提升了好几个数量级。 MBD的方法论、以及Simulink提供的结构化工具箱和块组建模，在应对重场景+深度学习算法时候，就显得力不从心。

尽管Mathworks也在此方面做出了一些努力：比如，在场景方面，Simulink收购地图编辑软件Roadrunner、发布Unreal联合仿真功能（自动驾驶工具箱Automated Driving Toolbox的Simulation 3D Scene Configuration模块），大幅提升了场景搭建的能力；另外，深度学习工具包也在最近的版本中持续迭代。但是，对于L3+依仗的AI技术，已经形成了一套主流的开发框架和生态，Simulink与其兼容性并不高。

综上，当前的自动驾驶工程师往往是选择直接编程搭建仿真系统，而不是像以往一样用Simulink建模，自动生成代码。 当然，以上也不意味着传统的方法完全过时。V shape的开发流程在实际生产中仍然具有重要意义，对于OEM而言， 能够提供从MIL到VIL整套自动驾驶仿真解决方案，才有可能转化为真正的生产力。

1.2.3 偏向数据驱动，以场景为核心的仿真

随着以Waymo为代表的L4+厂商出现，仿真技术迎来了突破。此类厂商运用仿真技术搭建逼近于真实的虚拟自动驾驶测试环境，来对自动驾驶算法进行测试。 尤其是基于AI的感知、决策算法。 这个时候仿真场景的重要性第一次被业界所重视。

2015年前后，出现了一批基于 游戏引擎 （主要是Unreal，Unity）开发的自动驾驶仿真平台，其最明显的特征就是 场景比以往丰富的多，也真实的多 （甚至有研究者基于GTA5 + 视觉的方案来研究自动驾驶算法，链接： GitHub - deepdrive 、 GitHub - DeepGTAV ）。 而传统的仿真工具链也在朝着这个方向进化 ，比如2020年4月，Mathworks收购了vectorzero及其开发的地图编辑软件RoadRunner，升级了构建大规模静态场景的能力（下文会着重介绍该软件）；Simulink也开放了与Unreal引擎联合仿真接口，提升了传统工具链在场景搭建方面的实力。

当前自动驾驶仿真工具的种类较多，联系十分复杂，本文后面会尽量梳理。不过 当前自动驾驶仿真平台基本的技术方向基本一致：

1. 基于游戏引擎开发，以实现对静态场景的高保真渲染和物理模拟；
2. 有静态场景编辑功能，支持基于高精地图的静态场景搭建；
3. 有动态场景编辑功能，也有交通流仿真功能；
4. 传感器的仿真一般不算太复杂，一般仿真平台都会自带，关键是要基于物理模型；
5. 汽车动力学模型则一般由外部的专业仿真软件导入；
6. 逐渐转向云端仿真，可以通过添加硬件方式提高测试里程，典型案例如Waymo；

1.3 自动驾驶仿真行业参与者

• 根据1.2节 所叙行业发展历程，当前整个行业的参与者分为下面几类：

每一类参与者的技术优势以及侧重的方向都会有所不同。一般而言，传统仿真企业在车辆动力学、交通流仿真方面占有优势，“工业软件”所侧重的严谨、实用、稳定的风格会更浓烈。而初创公司和大型客机公司则在场景搭建、以及对L4+自动驾驶系统的支持都有较大优势，“工业软件”的风格则较为淡薄。

当然也会有资金雄厚的传统企业、车企收购初创的科技公司，例如达索持股SCANeR，Mathwork收购RoadRunner，丰田支持Carla的研发等。从产业结构上看，自动驾驶仿真基本以美国、中国、以及德国为主。这里面商业化软件的完成度会更好，对于SIL、HIL等生产力支持也会更完善，但开发者的灵活性显然会受到不小的限制，而开源软件则会与商业软件具有相反的特性。

软件的具体介绍请见chapter 8。

• OEM、Tier1采用的仿真软件（2022年）

*此表需要逐渐根据积累调查补全， 加粗字体表示已证实的、在产品开发中发挥作用的软件，而并非如“签订合作协议”等套话。

参考资料：

1. 2019中国自动驾驶仿真蓝皮书（ 推荐阅读 ，51World主导编写-对51Sim着笔墨较多）；
2. 2020中国自动驾驶仿真蓝皮书（ 推荐阅读 ，腾讯主导编写-对自家平台介绍多）；
3. 两万字详解自动驾驶开发工具链的现状与趋势-面包板社区 (eet-china.com)
4. 一文读懂自动驾驶仿真测试技术现状 - 知乎 (zhihu.com)
5. 场景仿真加速智能网联开发测试进程_哔哩哔哩_bilibili （VTD综述类视频，推荐观看）
6. 自动驾驶系统之软件仿真测试 - 知乎 (zhihu.com)
7. 自动驾驶仿真工具需求 - 知乎 (zhihu.com)
8. 如何学习自动驾驶仿真？ - 威士忌燕麦拿铁的回答 - 知乎
9. Unity自动驾驶仿真 - 知乎 (zhihu.com)
10. Prescan、Carsim、Simulink联合仿真 - 知乎 (zhihu.com)
11. 虚拟仿真测试介绍（7）：MIL、SIL、PIL和HIL是个啥 - 知乎 (zhihu.com)

2. 车辆本体1: 动力学仿真（2022.05.18）

动力学是对车辆本体仿真的核心之一。尽管如前面所说，车辆动力学的理论和模型已经相对成熟，但并不意味着其不重要。相反，在自动驾驶仿真中， 想要真正实现量产落地，动力学模型必须足够精准。 简单的动力学模型意味着仿真车辆的工作状态与实际出入会比较大，对于实际车辆没有指导意义。

对于仿真平台，一些仿真平台会自行开发动力学模型。不过，当前构建车辆动力学模型直接且高效的方案是与专业的动力学软件进行联合仿真，业界大部分是与Carsim进行联合仿真。此方面Simulink、VTD、Prescan、TAD Sim等商业软件与Carsim的接口做的比较完善。PanoSim、VI-Simworld此类动力学仿真基础十分扎实的商业化仿真软件自然也不成问题。

而根据调研：Carla、Airsim、LGSVL此类开源平台的动力学仿真则十分简陋甚至于差劲，几乎无法模拟汽车的正常形态的运动行为，只有Carla的尚且算作正常。不过，这些平台也都可以通过Unreal Pluign也可以接入Carsim。目前，笔者找到的Carla与Carsim联合仿真案例： Carla和Carsim的联合仿真打通了 - 知乎 (zhihu.com)

2.1 多体动力学仿真——ADAMS

回到车辆动力学仿真本身，其本质上仍然属于 传统的构建数学/ 力学模型 。那么如何针对一辆汽车进行动力学建模，直观的想法是传统的基于 多体动力学的方式：

ADAMS是MSC software旗下的老牌多体动力学建模和仿真工具（学机械的人应该不陌生）。导入3D机械结构文件，定义好装配约束，配置好材料特性，再给定运动输入，即可对某种机械结构进行运动学、动力学的仿真。这种正向的开发流程建立的动力学模型精度极高，理论上是可以按照上述方法来进行整车的动力学仿真的。（笔者想起了大学时候做过的ADAMS雷达天线仿真大作业）

但是大多数时候，一辆汽车包含的零件以万计，细粒度的整车模型需要包含所有零件的尺寸、材料参数，这种复杂度极高的模型基本不具备仿真的可行性。因此，在汽车动力学仿真中，ADAMS一般用来对一些结构较复杂，不易得出特性的机械总成级别的结构进行动力学分析，以及悬架、轮胎等性能优化。那么，整车级别的动力学仿真该如何做？

ADAMS给出的解决方案是对模型进行大幅精简（但具体方式未知），在其推出的ADAMS Real Time版本中，对整车模型进行精简后仍然能够保持200个自由度，相比后面要介绍的基于总成特性的模型更为精准。其目前只能与同属MSC Software的VTD进行联合仿真，对其他自动驾驶仿真平台的支持一般。

2.2 基于总成特性的仿真——CarSim - 1996

而另一种更为简化、业界更为通用的整车动力学构建方式是， 使用粗粒度的总成的特性 ，基于递推动力学求解。如此需要的参数更少，计算速度更快，自由度也更少一些。 而其所利用的总成特性则由多体动力学、或者实验数据得出。 可以粗略理解为：ADAMS的输出可以作为Carsim这类软件的输入，例如，由某一总成下零件的装配关系，根据多体动力学可以得到该总成的动力学特性。而Carsim可以通过底盘的动力学特性，模拟车辆在道路上运行的情况。

从上述建模的逻辑也可以看出，车辆动力学建模非常依赖于在常年的工程实践中积累的仿真、实验数据。即便是一个传统的方向，其行业壁垒仍然比较高。

代表性软件CarSim：由美国Mechanical Simulation 公司开发，其内置了相当数量的车辆数学模型，Carsim本质上就是一个 模型库 + 参数库 + 求解器 + 后处理工具 + 用户界面。也就是说，其自带的模型都有一些“比较靠谱”的参数， 用户可以“傻瓜式”地根据要仿真的车型，选择一个合适的模型，然后 调整模型参数 ，即可快速的构建自己的动力学模型，省去了繁杂的建模过程。

因为CarSim做的是整车仿真，为了提升仿真的速度，因此其模型都比较简单，通常就是简单的公式或者 基于特性（二维、三维查找表）的模型 ，可更改的参数也比较少，但从整车层面来看，其精度也是可以接受的。

目前，CarSim里面并没有电动汽车的模型，不过可以通过手动魔改油车模型来实现：重新设置重量、以及转矩曲线来实现电动车的动力学建模。笔者尝试了Carsim的一些设置，的确比较简单、容易上手。

CarSim也提供了ADAS相关的功能，比如简单的静态场景构建，以及控制算法的仿真。但 更为普遍的做法还是通过接口将模型导出至其他平台进行联合仿真。 由于Carsim的普及度非常高，因此它应该是当前对自动驾驶仿真平台支持度最好的动力学软件，大部分的仿真平台都为其预留了联合仿真接口，还可以通过Carsim自带的Unreal Plugin接入。

2.3 CarMaker、PanoSim、VI-Grade、dSPACE-ASM、AVL-Cruise、veDYNA、ANSYS Motion

上述几款软件也都是十分擅长动力学仿真的软件，很明显他们都是属于前面所述的“传统仿真厂商”。不过这些软件的特性其实并不一样，CarMaker、PanoSim、VI-Grade、ANSYS已经向着综合的自动驾驶仿真平台发展：

1. 在整车动力学基础上加强场景搭建、传感器模拟能力；
2. 支持导入标准格式的地图文件（rFpro导入Carmaker，OpenDrive导入VI-Grade），也会基于游戏引擎来渲染场景（PanoSim基于Unreal，VI-Grade基于Unity），以增强场景的真实性。

在后面的章节还会提到这些仿真平台。 dSPACE则更多是作为其快速模型研发链条的一环，与其他工具一同打包售卖；AVL-Cruise、veDYNA则维持了传统的“动力学仿真软件”的定位。

当然，他们的一个共同特点是：基本都支持将模型导入Simulink，与之进行联合仿真，也即前面提到的传统汽车软件开发的模式，带有工业软件的本色。

2.4 L2/L3级ADAS功能测试仿真：Matlab/Simulink - 1984

前文提到了，车辆动力学仿真本质上就是数学/力学建模，那么Simulink作为万能的建模工具自然也可以胜任。近几年，Matlab提供的车辆动力学工具箱不断丰富和完善，同样具备动力系统、轮系、转向、悬挂、车身等系统的仿真能力。在缺少专业动力学仿真软件下，Simulink可以作为很好的替代品。

REF：

1. 卿颜 - 知乎 (zhihu.com) （仿真从业者，前dSPACE员工，现SpeedGoat员工）

dSPACE：

1. 主页 - dSPACE
2. 无人车系统仿真相关软件介绍-dSPACE - 知乎 (zhihu.com)

Mathworks Simulink：

1. Vehicle Dynamics Blockset 소개 (matlabexpo.com)
2. 如何用simulink建立整车动力学模型？ - 知乎 (zhihu.com)
3. CarSim： Mechanical Simulation (carsim.com)
4. CarMaker： CarMaker | IPG Automotive (ipg-automotive.com)

3. 车辆本体2: 传感器的仿真（2022.06.07）

3.1 传感器仿真概述

车辆本体仿真的另一个核心是传感器，既然是仿“真”，我们可以参考真实传感器原理如下：

1. Radar： BUAA火车侠：自动驾驶传感器（二）：毫米波雷达Radar原理
2. LiDAR： BUAA火车侠：自动驾驶传感器（三）：激光雷达Lidar底层原理
3. Camera： BUAA火车侠：自动驾驶传感器（四）：数码相机Digital Camera原理
4. GNSS-RTK： BUAA火车侠：自动驾驶传感器（五）：卫星导航GPS-RTK原理
5. IMU： BUAA火车侠：自动驾驶传感器（六）：惯性导航IMU原理

对硬件原理不熟悉的话，可能对后面的内容理解不透彻。

一般而言，传感器的仿真主要是用来对自动驾驶的 感知系统进行测试评价， 包括各种噪声、以及不同的环境对感知系统的影响，当然也可以用于对自动驾驶系统整体的闭环测试与评价。

3.1.1 核心1：基于物理的场景 （PBR）

总体而言，传感器的仿真是一个难度很高的方向。 且多数时候，主要障碍并非传感器的仿真模型 ， 而是在于场景渲染的真实性上。

举个例子，人眼对于这个世界的感知是非常“主观”的，即我们所能看到的一切，都是环境中的可见光经过物体复杂的反射、散射过程后，在视神经上的作用。不同的动物，比如鸟类和人类的对于同一场景在大脑中生成的图像是不一样的。

所谓的的渲染，其实就是在计算机中对真实世界的光学规律进行模拟，这样计算机输出的光线在人眼的成像就更加趋近真实。进一步地，如果场景渲染仅使用物体的RGB颜色信息，对其反射、折射特性等诸多影响外观的特性不做定义，那么即使Camera的模型再精准，输出的图像仍然不能像真实的照片那样。

再比如，在现实中激光打到不同材质、不同表面形态的物体上，其反射率也是不同的，如果不能对场景中所有物体的反射率、以及不同表面对反射率的影响做出详细定义，显然LiDAR的仿真也是不够真实的。

因此，传感器仿真的第一个核心就是基于物理模型的场景渲染（PBR），这又是一个十分庞大的学科。因为笔者对其知之甚少，只提两个比较重要的点： 微表面模型，以及光线追踪 。

• 微表面模型Microfacet Model

微表面模型将自然界中的粗糙的物体宏观表面(macrosurface)视作由一个个微表面(microfacets)组成。这些微表面是完美的平面，它们的朝向各不相同。这些微表面的法线越杂乱无章（方差越大），宏观表面就越粗糙；反之则越光滑。

详细一些的定义见Ref，反正我看不下去，也看不懂。

• 光栅化Rasterizartion 与 光线追踪Ray Tracing

在虚拟成像中有两种方式：光栅化与光线追踪

光栅化是将可视区域内3D场景通过矩阵场景投影到2D表面，然后通过数学方式计算2D表面的光照以及阴影。并非按照实际的光线传播原理来进行计算，因此渲染不够精确。

而光线追踪则是根据光线传播路径来确定每一个pixel的颜色信息。我们可以把屏幕想象成人的眼镜。当计算每一个pixel的颜色时候，会从该像素沿着视线方向发射射线，当射线与3D场景中的物体相交时候，会继续朝着光源投射光线，如果中途被遮挡，则产生阴影，如果没有被遮挡，则根据光源的颜色、材质、光源距离等因素来计算该像素的颜色。Ray Tracing对成像过程的模拟更加真实，但显然 计算量也更大 。不过随着Nvidia的显卡支持实时光追，这不再是什么难点。

上面涉及的是物理学中的光学部分，这对于构建“让人看起来真实”的虚拟世界很重要。但要做的事情还不止于此，比如对力学的模拟：道路的摩擦力、弹性模量、以及雨雪对道路摩擦力的影响，这对车辆动力学的模拟都是相当重要的。

这也是Unreal/Unity这类游戏引擎的根本优势——其底层物理模型更加真实，包括图形渲染在内的物理规律模拟更为真实。这也就是越来越多的仿真平台基于游戏引擎开发、或者使用游戏引擎进行场景渲染的原因。

• 神经渲染自动建模

除了主流的游戏引擎渲染外，Nvidia、Waymo等厂家采用了神经渲染的方式， 直接绕开了物理的建模， 利用神经网络（Surfel GAN，Block Nerf等）将实际采集的Camera和LiDAR数据转变为三维场景，进而可以得到更为逼真的渲染效果。这在目前是非常热点的研究方向。

3.1.2 核心2：基于物理的传感器模型

有了基于物理模型的场景，同样地， 传感器仿真也要基于物理模型 ，例如LiDAR的仿真要还原激光发射-相交-反射的 Ray Casting 过程，Radar仿真则要模拟MIMO的FMCW连续调频波的发射-反射的物理过程。

传感器的基于的物理原理是不同的，因此环境给传感器带来的噪声和扰动项也是不同的，这都为传感器的仿真带来了不小的难度。因此， 建立堪用的传感器模型门槛并不高，但要建立贴近真实的模型则难度陡然上升 ，很可能费时费力却只换来一点点提升。

在仿真平台中，对仿真传感器的基本需求有（流水账+废话，不用看）：

Ref：

1. 【RTX光线追踪-1】专业图形显卡支持的「光线追踪」是什么原理？_哔哩哔哩_bilibili
2. PBR学习笔记（二） BRDF和微表面模型_哔哩哔哩_bilibili
3. Sensors | Free Full-Text | Automotive Lidar Modelling Approach Based on Material Properties and Lidar Capabilities (mdpi.com)

3.2 传感器仿真方法

3.2.1 Camera仿真

Camera的仿真的基础是虚拟场景的渲染，这个前面已经讲过。而后面的则是对相机自身成像系统的模拟：镜头的投影过程模拟、CMOS/CCD传感器模拟、DSP模拟。

• 镜头投影仿真

镜头的仿真参照了现实中的成像方式：通过相机外参 (R,t) ，将世界坐标 C_{world} 下的点 P(X,Y,Z) 先投影到相机坐标 C_{camera} ，再投影至归一化平面，最终投影到像素平面。之后，还需要对镜头存在的 光学特性 以及 误差项 进行仿真，比如 焦距、径向畸变、切向畸变、炫光、泛光、晕影等。

当然具体地可以有小孔相机和鱼眼相机的类型，这仅仅是 相机个数 以及 投影模型公式 的不同，不算什么难点。

• 传感器 + DSP仿真

主要是对成像的传感器以及数据转换过程进行仿真，比如： 光圈、快门、ISO、像素 的调节（拍照流程）， Gamma校正、白平衡、景深、HDR调整、色彩空间 等等（DSP的调节）。以上概念不熟悉的话读起来会十分枯燥乏味，仍然建议学习Digital Camera的原理。

总之，Camera仿真的核心在于虚拟场景的渲染， 后面的镜头投影的仿真、信号处理的仿真、以及误差项仿真都不算太困难。

• 输出项

相机的仿真输出应当包含RGB图、以及各种深度图、语义分割（Ground truth）、实例分割、光流等结果，从而可以对感知算法进行评价，或者作为感知模型的训练材料。

3.2.2 LiDAR仿真

激光雷达的模拟有几个重点，分别是： 基于RayCasting的反射模拟，不同材质反射率的模拟，多种激光雷达原理的模拟。

• 基于Ray Casting的反射原理

LiDAR仿真的思路是还原真实LiDAR扫描的方式，模拟以下过程： 激光束发射—与场景中物体相交—根据相交物体的物理材质属性计算反射强度与噪声—接收反射信号—处理反射信号。

以禾赛Pandar128线LiDAR为例，其角分辨率为0.1°，频率为10Hz，这也意味着每秒钟会发射约 461万 条激光射线。对于探测范围内的每一个有效点，需要执行一次较为复杂的求交算法，对于算力的开销比较大。不过这算不上什么问题，实际过程中一般会利用GPU来负担LiDAR的仿真的算力开销。几乎所有的仿真平台都是支持基于RayCasting的激光雷达仿真的。

不过，仿真的LiDAR与真实的LiDAR存在一个很重要的不同，真实的LiDAR采集过程中，汽车处在不停的运动前进过程，因此单帧点云的时间戳是不一样的。但仿真的LiDAR工作时，会默认汽车停止在当前位置，直至LiDAR采集完当前帧，因此其单帧点云时间戳是一样的。

• 反射率的模拟

激光雷达仿真的一个难点在于对其 接收信号强度的模拟 。现实中，影响LiDAR的信号强度主要有以下因素：

1. 目标物体的物理材质对激光波段（905nm or 1550nm）的 反射率；
2. 目标物体与激光源的距离；
3. 激光反射的角度；
4. etc；

因此，在仿真前， 需要对场景中所有物体的物理材质的激光反射率进行定义 ，反射率的calibration过程可以参照现实场景中激光雷达数据进行。然后，根据已有的光学模型，最终可以得到 激光的反射强度为 ：

P_R=\frac{P_E D_R^2 \rho \cos \alpha} {4R^2}\eta_{sys}\ \eta_{atm} ，具体解释为：

回波功率=\frac{发射功率* 接收机孔径^2 *物体表面反射率 *cos 入射角} {4*距离^2}*系统传输率*大气传输率

最终，将反射功率归一化即可。

• 不同类型激光雷达的模拟

激光雷达仿真的另一个麻烦点在于 激光雷达原理的多样性。 目前车用的激光雷达有：360度旋转的机械式激光雷达，已经量产的转镜式激光雷达，即将量产的MEMS激光雷达，以及后续可能量产的OPA光学相控阵激光雷达，FLASH激光雷达。

其扫描原理、激光测距原理都有所不同，造成其工作特性以及误差模拟也会不同，这会给工程师带来很多额外的工作。举个例子：MEMS振镜受外界温度、振动环境影响会导致谐振频率的变化，从而导致线束紊乱、成像歪曲，然而这些对于转镜式以及机械式激光雷达都不是什么问题。（欲理解这几种雷达的根本不同，可见上述参考文档，在本文不做展开）

• 输出项与参数

至于激光雷达仿真应当支持的参数：如安装位置与角度、工作频率、探测距离、线数以及分布、视场角设置、噪声模拟、在不同光照和天气下的输出；当然也需要具备输出语义分割点云、3D bounding box等功能。这些从原理上并不难实现。

3.2.3 Radar仿真

• 毫米波Radar行业的尴尬

目前，毫米波雷达行业面临着一个尴尬的境地。在实际工况下，受限于原理， 毫米波雷达所能获取的环境信息是非常少的，但其原理以及信号处理算法却基本是最为困难的 ，完全不像LiDAR的TOF测距那样简单直观。

因此，Radar在自动驾驶传感器的地位是远弱于Camera和LiDAR的，Tesla甚至放弃了Radar的使用。Radar产研带来的经济效益也是远不如激光雷达，直言之—— 研发Radar是一件费力不讨好的事情 ，因此Radar在资本市场的热度一直不高。同时在中国，雷达领域的人才数量不多，且大多集中于军工领域，以上种种致使激光雷达的生产制造以及算法仿真进展都不是那么快。

• 毫米波Radar仿真

Radar仿真时，根据配置的FOV和分辨率，向不同方向发射虚拟的FMCW连续调频波，并接收目标的反射信号，经过解算后即可得到 水平方位角、距离以及多普勒等 信息。当然，还有新型的4D毫米波雷达可以实现水平、垂直两个方向上的方位角测量，可以形成较为稀疏的点云。

雷达回波功率可以使用微表面模型结合目标的距离、物理材质等计算。毫米波雷达仿真一般需要支持更改毫米波雷达安装位置、角度、探测距离、FOV和距离分辨率、噪声参数等。对于某些兼有长距和中距探测功能的毫米波雷达，仿真时则需要同时支持两者的参数设置。

3.2.4 IMU、GNSS、V2X

无力调研，略

3.3 传感器仿真厂商

前面提到，传感器仿真的上限很高，但下限也比较低，囫囵做个模型出来是十分简单的事情。因此，基本上所有的仿真平台都会提供传感器模型。据说业界做的比较好的有VTD、RightHook(创业公司，已经并入VI-Grade)、Metamoto等，SImulink的自动驾驶工具箱的传感器模型也不错。

Ref：

1. Background: Physics and Math of Shading by Naty Hoffman；
2. 基于物理的 BSDF：Microfacet Model（微表面模型） - 知乎 (zhihu.com) ；
3. CARLA模拟器中有激光雷达和毫米波雷达的模型吗？ - 知乎 (zhihu.com) ；
4. [Unity 教程]-Unity实时光线追踪技术介绍_哔哩哔哩_bilibili
5. Background: Physics and Math of Shading by Naty Hoffman
6. 图形渲染基础：微表面材质模型 - 知乎 (zhihu.com)
7. 基于物理的 BSDF：Microfacet Model（微表面模型） - 知乎 (zhihu.com)
8. 游戏引擎PBR的前世今生--使用微表面模型进行渲染 - 知乎 (zhihu.com)
9. Ray tracing (graphics) - Wikipedia
10. 基于Unreal游戏引擎的lidar传感器仿真及3D场景重建（混合点云）_JhonLocke的博客-CSDN博客
11. 走进自动驾驶传感器（一）——激光雷达 - 知乎 (zhihu.com)

4. 场景仿真1: 静态场景建模（2022.05.24）

4.1 静态场景的建模方法

前面讲过，主流的静态场景搭建基于游戏引擎，这使得自动驾驶仿真的场景更加真实，包括了 更加真实的图形渲染 ，以及 更加真实的物理规律 两个方面。但Unreal、Unity本身并非具体的场景建模工具，而是可以理解为一个 “装配”工具 。因此详细的模型素材仍然需要借助其他软件完成，典型如的Autodesk公司的3DS Max、Maya等等。

用细粒度的3D建模软件来构建大型场景显然是低效的，因此也会有一些专业的粗粒度的建模软件用搭积木的方式来构建。举个例子，一般的场景大概包含了 道路、地形、以及建筑物 的构建，那么就可以用对应的软件/插件来解决。比如下面是围绕 Unity 引擎的一些较为典型的建模软件。

链接： RoadArchitect 、 VTP 、 EasyRoads3D 、 Unity Terrain Toolkit 、 World Composer 、 ArcGIS CityEngine 、 UDST/vizicities

但总归而言，这种场景中所有的模型都是需要人手动来参与搭建的，使用工具、插件也总得去输入不少参数，其效率始终不是很高。并且，尽管基于Unreal/Unity引擎构建的场景在这几年看起来越来越逼真，但仍然与真实的图像有所差别。

因此，业界的另一种方法则是根据实采的点云与图像数据，采用神经渲染的方法自动化的生成3D虚拟场景。这种方式最显著的两个优点是：大幅度提升了场景搭建的效率，大幅提升了场景渲染的真实性。并且，生成的具体模型还可以作为资源库，用于构建新的场景或者更改已有场景。（我在此领域的知识了解太少，需要进一步学习补充）

4.1.1 基于高精地图的场景生成

针对于“ 面向自动驾驶的3D场景构建 ”，业界常用的方式是基于高精地图来生成场景。高精地图的生成方法可以参考： BUAA火车侠：高精地图（一）：自动驾驶HDmap流水账科普

而基于高精地图的场景生成即是将高精地图的结构化的矢量图形再次进行3D渲染。其方法是将高精地图的每一种矢量图形建立一 一对应的标准模型素材库，然后根据矢量图形的语义调用素材库中不同的资源进行重新渲染，即可完成 对道路场景 的建立。

显然，相较于人工去对道路进行建模，这种方式更加高效、低成本，且构建的道路也是对应实际场景的。之后，再对道路两边添加建筑，植被、地形等要素，即可构成面向自动驾驶仿真的静态三维场景。

目前，一些综合仿真平台/软件都自带了支持高精地图的道路/场景编辑器，可以证实的做的比较好的有VTD、SCANeR studio、Prescan等（也仅仅是相对地）；还有的场景编辑能力比较孱弱，比如Carla，需要借助第三方的场景编辑软件RoadRunner。当然RoadRunner作为一个单纯的场景编辑软件对这些仿真平台几乎一视同仁，其能够导出适配多种仿真平台的格式，这在后面会专门提到。

最后，基于高精地图生成静态场景也需要这些仿真软件支持 统一的高精地图标准与场景标准 ，当前的主流标准一般是OpenDrive（ .xodr后缀），这部分也会在后面的章节具体讨论。

4.1.2 Waymo - 基于神经渲染的场景生成

作为公认的自动驾驶技术最强的公司，Waymo在2020年就开始使用神经渲染的方式来自动生成场景。2020年CVPR大会上，Waymo做了题为《Machine Learning for Autonomous Driving at Scale》的报告。

在该方案中，Waymo采用Surfel GAN（Surface element Generative Adversarial Networks ）， 可使用车辆实际采集到的LiDAR和Camera数据，生成逼真三维场景，进而在各角度得到逼真的相机图像 ——其可以视为真实世界-虚拟世界之间的Domain adaptation/ transfer。所谓Surfel表面元素，一个对象由一组密集的点或者带有光照信息的面元来表示。

其主要步骤是：

1. 扫描环境，重建一个由有纹理的表面元素（Surface element）构成的场景；
2. 然后用相机轨迹对表面元素进行渲染，同时进行语义分割和实例分割。接着通过GAN生成逼真的相机图像。

更加详细的信息可以阅读论文，论文链接见下方，本文就不做过多解读（主要我也不懂）。

还有近期的 Block-Nerf 的工作， 论文和Demo见Ref 。这种方式的静态场景构建显然是更加高效，省去了太多的地图编辑任务，并且模型面元来自真实图像，其渲染真实性更高。

参考资料：

官网 & 介绍：

1. 官网： Home – Waymo
2. 论文： [2005.03844] SurfelGAN: Synthesizing Realistic Sensor Data for Autonomous Driving (arxiv.org)
3. [2202.05263] Block-NeRF: Scalable Large Scene Neural View Synthesis (arxiv.org)
4. Demo： Block-NeRF - YouTube

教程 & 案例：

1. 黄浴： WayMo在CVPR 2020自动驾驶研讨会的报告 - 知乎 (zhihu.com)
2. 数据不够，Waymo用GAN来凑：生成逼真相机图像，在仿真环境中训练无人车模型 - 知乎 (zhihu.com)

4.2 软件：RoadRunner——自动驾驶仿真设计三维场景

对于场景建模软件，某种程度上，其开放权限与建模效率很难两者得兼。例如使用Prescan建立场景时候，只需根据需求拖动素材并更改参数即可，但其对特殊形状的路段的支持就比较差。VTD的场景编辑功能比较灵活，但建模的工作量就比较大。 而在这方面Mathwork旗下的RoadRunner基本能够做到两者兼顾。

前面提到，Mathworks收购RoadRunner，旨在提升其开发链条上的场景构建能力。其具备特点有：

1. 创建三维场景的功能十分丰富，可导入OpenDrive格式地图（常规操作）；可以导入LAS、LAZ、和PCD；
2. 借助Asset Library素材库，可以使用多种三维模型快速填充三维场景；
3. 借助Scene Builder，可将OpenDRIVE®地图自动转化为3D场景，十分高效；这也是RoadRunner最attractive的点；在Ref里面的介绍视频里有体现；
4. 可导出 OpenDRIVE® 格式的道路网络，三维场景输出的格式极为全面：包含 FBX® 、glTF™、OpenFlight、OpenSceneGraph、OBJ 和 USD 等格式；导出场景可适配几乎所有的自动驾驶仿真器和游戏引擎。
5. 对GIS的支持较好，GIS数据可作为参考或提供地形数据；

REF：

1. 自动驾驶系统之软件仿真测试 - 知乎 (zhihu.com)
2. Unity自动驾驶仿真 - 知乎 (zhihu.com)
3. Ray Tracing渲染： [Unity 教程]-Unity实时光线追踪技术介绍_哔哩哔哩_bilibili

RoadRunner场景搭建：

1. 手把手教你使用 RoadRunner 为自动驾驶模拟设计 3D 场景_哔哩哔哩_bilibili （推荐观看，这个视频对RoadRunner的介绍极为全面，看完后基本不需要再看其他的介绍了）
2. MATLAB收购的RoadRunner是什么？自动驾驶场景软件市场又添波澜 - 知乎 （推荐阅读）
3. MathWorks中国工程师最全问答 | 自动驾驶场景编辑器——RoadRunner - 知乎 (zhihu.com)
4. MATLAB新杀器 RoadRunner实战篇 | 基于MATLAB、RoadRunner、虚幻引擎和Speedgoat的驾驶员在环系统 - 知乎 (zhihu.com)
5. How to make a new map with RoadRunner - CARLA Simulator

VTD的场景搭建：

1. VTD（Virtual Test Drive）基础培训-QuickStart_哔哩哔哩_bilibili
2. VTD场景搭建从听说到入门（零） - 知乎 (zhihu.com)
3. VTD场景搭建从听说到入门（二）- 静态场景 - 知乎 (zhihu.com)
4. VTD场景搭建从听说到入门（三）- 动态场景 - 知乎 (zhihu.com)

Prescan场景搭建：

1. 【Simcenter Prescan 快速入门系列】 第1期：Prescan架构及基础场景建模_哔哩哔哩_bilibili
2. 小编最近安装使用了PreScan2021,参考文档，总结了一下2021的变化 (360doc.com)

LGSVL 2021版本场景编辑：

1. Using VSE - SVL Simulator
2. LGSVL官方文档理解（三）：最新发布版的新特性 - 知乎 (zhihu.com)

SCANeR场景搭建：

1. 上海益罗的个人空间_哔哩哔哩_bilibili （SCANeR代理商）

5. 场景仿真2: 动态场景搭建（2022.05.26）

5.1 需求与难点

当前，自动驾驶最容易落地的场景有两种：一种是低速的清扫、物流机器人，缓慢的移动速度 + 保守的算法，总不至于捅出什么篓子；其二是封闭的工厂、园区、港口等场景，没有 复杂、随机的 动态环境、沿着既定的线路运行，使得环境的熵值被有效控制。

然而，消费级的自动驾驶车辆最终是要跑在 复杂且随机 交通环境之下的，车辆必须要处理很多与其他车辆、行人之间的交互任务。因此需要构建动态的场景以测试、迭代自动驾驶算法。事实上， 业界经常提到的非常宝贵的自动驾驶Corner Cases大多都是一些较为极端、特殊的动态场景。

前面已经给出，动态场景主要是 交通参与者的仿真 （机动 车、非机动车、行人的行为、交通管控），其次是 环境气候的仿真 。那我们的需求有：

1. 动态场景中各交通参与者的行为要趋近真实、合理；
2. 环境仿真要基于物理模型；
3. 动态场景库的设计具有代表性，能够以少量场景覆盖所有现实中存在的交通状况（场景库的建设在后面会介绍）；

• 动态场景建模难点

从直观感受上，对单个元素的动态行为建模需要描述 “谁在哪里做了什么事情，持续了多长时间” ，这要比静态环境建模难了许多，参数化的描述也十分晦涩难懂。这使得动态场景的标准化较为艰难，比如， 后面提到的动态场景标准OpenScenario的建设即比静态的OpenDrive复杂困难了许多。

其次是仿真的真实性不足。比如，仿真的车辆基本上是难有准确的动力学行为的。并且现实中一个实体的行为，是会对周围的其他对象产生影响的，而当前多车、车-人之间的互动真实性有待提升。

第三点，当前动态场景对现实世界的统计学意义未被明确提出，而建设有效的、覆盖大部分现实情况的动态场景库，是需要这种仿真-现实之间的映射关系来进行优化的。

5.2 细粒度：Scenario的编辑

我们将“动态场景”缩放到最细的粒度——每个个体的行为，即“谁在哪里做了什么事情，持续多久”。我们以下图举个例子：

• 黄色重卡从A到B，走左侧车道，在a路口左转，全程行驶速度50km/s，到达B点后停车；
• 蓝色轿车从A到C，走中间车道，在a路口直行，全程行驶速度60km，到达C点后继续以当前速度行驶；
• 左侧红色轿车从D到E，走中间车道，在a路口碰到红灯，等待50s后通过，停车、启动加减速曲线定义、稳定车速40km/s，到达E点后停车。
• 右侧红色轿车.......

我们会发现，单一个体十分简单的行为，用自然语言进行精细化的描述却是一个十分繁琐的过程，即便我们尝试用结构化的标记语言对其进行抽象，仍然无法做到十分简洁，例如：

Vehicle type：Van; //车辆定义
Vehicle ID：12345;
City：Beijing； //场景发生地点
District：Chaoyang；
Lane：left； //行为：车道
Lane change：None;
Intersection1：a； //转弯行为1
Turn1：left；
Intersection2：b； //转弯行为2
Turn1：None；
Speed：50; //速度定义
Start：Point_A; //起始位置
Start Status：Moving； //起始状态
Dest：Point_B; //终点位置
End status：Brake； //重点状态
...

当然，此种想法仍然是描述一个Scenario的最佳方式，只需要对一些关键特征做出定义，即可实现对个体行为的最细粒度的编辑。后面讲到的OpenScenario标准即可理解为定义了一套比较好的参数化描述场景的标准。这种细粒度的场景编辑，可以最精确的构建想要的场景，最为现实的意义就是1：1的还原现实世界中自动驾驶车辆遇到的Corner Case，进而对算法进行训练和测试。

当前，业界主流的对动态场景描述的标准是OpenScenario 1.0版本（读者可以先看对应的章节介绍，为了保持文章整体结构，本章不做展开），主流的场景编辑软件基本都是基于该标准实现场景的编辑。

5.2.1 RoadRunner Scenario - 2022- 动态场景编辑

当前（2022年），能够基于OpenScenario的实现场景编辑的软件不算多，毕竟OSC 1.0标准发布于2020年，2.0版还处于建设与完善过程中，但业界对于OSC的潜力的共识很强。

最典型的软件是2022年Mathwork发布的RoadRunner Scenario：

1. RoadRunner Scenario 是一个交互式的动态场景编辑器，其功能为： 设计用于自动驾驶仿真测试的动态场景。
2. 其操作流程较为简单：放置车辆和路径，定义逻辑，并将场景参数化。然后即可在编辑器中模拟、回放该场景。车辆可以从内置车辆对象中选择，也可以用Simulink或者Carla定义。
3. RoadRunner Scenario设计的场景可以连接到其他仿真器上进行联合仿真（目前未知有那些平台，不过Mathwork外部接口一贯做的比较好）。也可以将动态场景导出为OpenScenario 1.0格式，然后就可以用于任何支持OpenScenario的仿真平台或者场景编辑器，如后面会提到的esmini。
4. RoadRunner API允许更改场景参数，为自动测试创建许多变体。可以使用该API自动化工作流，例如在不同场景中放置场景、模拟场景和导出。

官网 & 介绍：

RoadRunner Scenario 产品信息 - MATLAB & Simulink (mathworks.cn)

5.2.2 Python Scenariogeneration、Esmini、OpenScenario Editor

下面介绍的是三个开源的动态场景项目：

• 首先是Python Scenariogeneration：

这是一个是用于生成 OpenSCENARIO（.xosc） 和 OpenDRIVE（.xodr） XML文件的库。此组合包（包括以前的pyoscx，pyodrx）可用于联合生成OpenDrive格式的静态场景，以及在此基础上的OpenScenario动态场景文件。

这个库由Scenario_generator模块和两个子包xosc、xodr组成，xodr目前覆盖了 OpenDrive 1.5.0，xosc目前覆盖了OpenScenario V1.0.0和V1.1.0的大部分内容。当前Scenariogeneration支持参数化的自动生成、以及利用esmini进行可视化。

• 然后是Esmini：

Esmini的全称是Environment Simulator Minimalistic，是一个小且精致的 OpenScenario的解析器以及可视化工具， 是一个很好的OpenScenario的教学工具。项目本身也有较好的易集成性以及可移植性。其组成有（摘抄）：

1. RoadManager（esminiRMLib） ：提供以OpenDRIVE格式描述的道路网络接口库。
2. ScenarioEngine（esminiLib） ：提供viewer和与以OpenSCENARIO格式描述的交通场景交互的主库。该库包括RoadManager。

esmini还提供了 一些可以原样使用或为定制解决方案提供灵感的应用模块：

1. esmini ：一个静态链接到esmini模块的场景播放器程序。
2. esmini-dyn ：一个使用esminiLib播放OpenSCENARIO文件的mini示例。
3. odrplot ：能用于从OpenDRIVE产生数据文件，并使用Python绘制路网。
4. odrviewer ：使用虚拟交通可视化OpenDRIVE道路网络。
5. replayer ：重播以前执行过的场景。
6. osiecever ：一个通过UDP从esmini接收OSI消息的简单应用程序。请注意：从版本1.5开始，esmini仅支持OpenSCENARIO v1.0。 所有demo场景均已从0.9.1更新到1.0。ASAM提供了一种转换方案 。可以与自动迁移XML文件的工具一起使用

• 最后是OpenScenario Editor：

OpenScenario Editor是基于Esmini的项目的一个开源的场景编辑器，比RoadRunner Scenario简陋了很多。

官网 & 介绍：

1. Py_Scenariogeneration： GitHub - pyoscx/scenariogeneration: Python library to generate linked OpenDRIVE and OpenSCENARIO files
2. Welcome to scenariogeneration (pyoscx.github.io)
3. Esmini： https:// github.com/esmini/esmin i
4. esmini team - YouTube
5. OpenScenario Editor： GitHub - ebadi/OpenScenarioEditor: ASAM Open Scenario Editor
6. Esmini介绍： esmini | A basic OPENSCENARIO player (qq.com)

教程 & 案例：

1. 在Carla里做一个Robotaxi （三） - 知乎 (zhihu.com) （用的Scenario generation）

5.2.3 其他软件：

细粒度的动态场景编辑总体而言不算什么困难的事情，当前 51Sim-One 、 VTD 、 Cognata 、 AAI 、 Carmaker 、 dSPACE 这些仿真软件，都是可以实现基于OpenScenario的场景编辑的。如下方即为51world的案例以及英国布里斯托大学的Demo。

案例：

1. 51World： 51Sim-One场景标准OpenSCENARIO的应用实践_哔哩哔哩_bilibili
2. Bristol大学： Online openScenario GUI editor - YouTube

5.3 粗粒度：交通流仿真

上述对个体行为的细粒度建模可针对于一些精细化的刁钻的场景建模。但对于大型的场景，如果要编辑每一辆车、每一个行人的行为，则完全是不现实的，多个对象之间的行为也非常容易产生干涉。这个时候就需要使用其他的方法：

1. 基于真实的交通流的数据：

即通过传感器采集真实世界的交通信息，经过基于AI的识别、跟踪算法处理之后置入仿真场景之中。其次，还可以在真实数据的基础上进行一定程度上的泛化，对真实场景的所有变量进行一定程度上的合理变形，例如在十字路口中，将机动车、非机动车、行人的到达时间、停留时间、移动速度等数值在合理的范围内变动。Waymo的仿真平台Carcraft即借鉴了该技术方案。

真实的交通流数据还可以用于训练AI模型，然后再由AI模型自动生成拟真的车辆、行人交通流，这也是近年来随着AI技术兴起的一个热点方向。

不过从实践上，将真实的交通数据转化为机动车的交通流并不是理想化的。从我方所作赤峰项目来看，视频流-车牌提取-路由文件的转化过程会带来一定的失真。同时，想要大规模获取真实交通数据的成本也是比较高的，路侧采集设备的覆盖总是不够理想。

2. 基于微观交通仿真系统：

然后就是 交通工程领域 的 交通流仿真 ，这是当前主流的方案。该学科研究始于上世纪50年代，主要研究每个车辆的行为交互，宏观层面上关注区域内的车流平均速度、路口平均等待时间等统计指标。微观交通流仿真一直都是 交通系统的规划、优化、以及评价的主流方式。 不过在自动驾驶领域， 其主要的价值是提供随机、复杂的动态环境。

交通流系统模型通常分为三类，具体取决于它们在哪个级别上运行：

• 微型模型： 分别代表每辆车，并尝试复现驾驶员行为。
• 宏观模型： 从交通密度（每公里车辆）和交通流量（车辆每分钟）的角度描述车辆的整体移动。它们通常类似于流体的流动。
• 中观模型： 是结合微观和宏观模型特点的混合模型，将流量建模为车辆的"包"。

一般而言，自动驾驶场景都是使用相对精细的 微观交通流模型。 现有的综合自动驾驶仿真平台一般也配备了交通流仿真功能，比如比如VTD的I-Traffic模块，Prescan的Intelligent Traffic Module，Carla基于PhysXVehicle的交通流生成等等。但与前文提到的动力学仿真模块相似，综合仿真平台在目前（2022）还很难超越专业的交通流仿真工具。因此，最好的方法仍然是取长补短，通过仿真接口接入专业的交通流仿真软件。例如Carla与 SUMO、PTV-Vissim 都可以进行联合仿真。

5.3.1 SUMO（Simulation of Urban MObility）

SUMO 是由德国国家宇航中心开发的开源软件，支持微观交通流仿真，也可以用于车间通讯的仿真。SUMO附带了一个 路网编辑器 ，同时也可以转换来自Vissim，OSM，OpenDrive的路网数据。对于 路由数据 ，可以通过编辑路由文件的方式指定每辆车辆的路由，或者使用参数来随机生成路由。SUMO还提供了C++、Matlab算法的接口，如前面所言，可以进行交通系统的优化以及评价。

例如某个智慧交通项目中，工程师基于CF市的道路工程图纸，利用SUMO路网编辑器构建了路网，然后根据实采道路过车数据编辑路由文件，复现了车流数据。然后基于强化学习算法，对每个路口的交通信号灯配时方案进行自适应调整，提升了交通效率。这是SUMO仿真器相当典型的应用。

当然，在自动驾驶仿真中，SUMO仅是提供交通流的，比如2020年开始，CARLA开始支持和SUMO联合仿真，后面也会提到基于此衍生出的仿真平台OpenCDA。

官网 & 介绍：

1. Eclipse SUMO - Simulation of Urban MObility
2. Documentation - SUMO Documentation (dlr.de)

教程：

1. SUMO软件基本教学_哔哩哔哩_bilibili

5.3.2 PTV Vissim - 1979

Vissim是由德国PTV公司开发的交通流仿真软件。PTV公司位于卡尔斯鲁厄，2017年后由保时捷全资控股。Vissim可以在仿真场景中模拟包括 机动车、卡车、轨道交通以及行人 的交互行为，包括微观个体的跟驰行为和变道行为，以及群体的合作和冲突。其具体的功能应用和SUMO比较类似，具体的介绍可见下方的参考链接，十分详尽。

Vissim的软件支持很好，可支持的联合仿真有：Carmaker、Prescan、VTD、Carla、Carsim、dSPACE ASM、Simulink、Unity、Unreal、rFpro等等。

对比SUMO与Vissim：作为一款开源软件，SUMO支持跨平台的开发，但其模型相对不够完善，比如缺少非机动车的专用模型，因此可信度存疑。而Vissim仅支持Win平台，作为商用软件，模型较完备，可信度也较高；支持一定程度的二次开发，但费用较高（大约10W RMB）。

市面上还有其他交通流仿真软件，如同济开发的微观交通流仿真TESS NG等，但那些市占率基本无法与上面两款相提并论，也就不多介绍。

官网 & 介绍：

1. PTV Group - PTV Vissim - ptvgroup.com
2. Vissim在自动驾驶仿真工具链中的作用_哔哩哔哩_bilibili （推荐观看）
3. 面对进入自动驾驶仿真的IT巨头，PTV VISSIM的优势何在？-电子工程世界 (eeworld.com.cn)

教程 & 案例：

1. Vissim扫地僧的个人空间_哔哩哔哩_bilibili （Vissim中国官方账号）

Ref：

1. 交通工程跨界思考：何为无人驾驶仿真中的交通流仿真以及可用平台有哪些？ - 知乎 (zhihu.com)
2. Co-simulation with SUMO and PTV-Vissim - 知乎 (zhihu.com)

交通流仿真

1. 《Fundamentals of Traffic Simulation》
2. 《Verkehrsdynamik und -simulation: Daten, Modelle und Anwendungen der Verkehrsflussdynamik》
3. 《 Traffic Flow Dynamics 》

5.4 环境气候的控制

天气系统是游戏引擎的强项，当前在游戏引擎中可以实现较为复杂、且拟真程度极高的天气模拟。天气系统的仿真有两种方式：一种是基于 材质纹理 （类似于给表面贴图），另一种则是 基于物理模型 的仿真（例如Unreal Engine最强的动态天气系统插件Ultra Dynamic Sky）。前者的渲染不够真实，但资源占用少，后者更加真实但资源占用极大。

两者的区别，举个例子：当模拟下雨天的时候，地上有一个小水坑，那么基于物理模型仿真中，小水坑的水就会越积越多，同时积水对于地面的摩擦系数也会产生影响。而基于贴图的模拟则仅仅是贴上了“表面有水”的效果动化，仿真世界的物理参数并未发生变化，其真实性无法与物理模型相比。

基本所有的自动驾驶仿真平台都有对天气的控制，或简单或复杂。例如，Carla可以通过Python脚本来更改天气参数，大概包含了：

• 太阳位置(仰角，方位角)控制；
• 阳光的色温、强度、大气散射；
• 云、雨、风、雾等场景（当前还没有雪）；

其气候系统不是基于物理模型的，因此相对而言也比较粗糙。

Ref：

1. 自动驾驶模拟软件Carla上手-操纵天气，手动驾驶模式_哔哩哔哩_bilibili
2. 《技术启发艺术》虚幻4（UE4)资产：Ultra Dynamic Sky（UDS）光照系统以及（UDW）天气系统简述 2021 07 01_哔哩哔哩_bilibili

5.5 综合场景搭建厂商

综合 静态 和 动态 场景搭建的需求，一款理想的场景搭建工具需要具备的特性要有：

5.4.1 rFpro - 2007 - 第一个关注路面的厂商

rFpro在场景搭建领域的方案比较有趣，尤其是 注重“路面的特征” 。但网上对该软件的描述大多数都是抄来抄去，并没有很好的阐述其特点。

rFpro 是一家英国公司， 成立于2008年，开始是一个为赛车项目进行赛道重建以及DIL-驾驶员在环的模拟软件，主要为车队提供服务，并可对赛车手进行训练。这就决定了，其场景必然十分真实精确，物理模型真实细致，仿真实时性较高。

1. rFpro是选择基于真实世界，自己搭建场景，利用高精度的干涉激光雷达扫描路面，可以1mm内的精度构建出 高精度路面数字模型。 然后，使用普通ToF激光雷达扫描路侧街道，构建场景。rFpro使用该方法创建了许多赛道以及测试场景的高精度虚拟场景，包括F1，NASCAR, IndyCar， 东京C1高速 - YouTube 。 即rFpro直接出售建好的场景，而并非场景编辑软件。
2. 这种建图的方式最大特点在于对路面微观特性的关注，可以较好的还原路面的粗糙度、凹凸、摩擦系数等细节， 因此可为汽车的动力学仿真提供十分真实的虚拟场景，这与后面要提到的OpenCRG标准异曲同工。
3. 商业化团队构建出的虚拟环境，必然在完成度、精细度方面更有保障，在当前场景编辑工具不够完善、环境构建流程非常繁琐的当下不失为一种好的解决方法。但另一方面，目前没有证据表明其场景支持Open X标准，在标准化方面仍然不足。
4. 动态场景方面，rFpro 可以接入 SUMO 或者 Vissim，用它们生成连续的交通流来填充整个场景；并且，其天气场景都是基于物理模型的，精确度也非常高。
5. rFpro可以与Carmaker 联合仿真，为Carmaker提供更真实的传感器和测试场景。
6. rFpro也支持导入第三方地图模型，包括如IPG ROAD5（Carmaker的格式），.max，.fbx，OpenFlight，Open Scene Graph，.obj等，但可以想到外部模型的精度应该是无法与rFpro自建地图相比。

总之，rFpro最大的特点就是第一个将“精细化的道路微观特性”作为重点的公司，尽管这原本是赛车领域的需求，在自动驾驶领域属于无心插柳。理论上，rFpro拥有的道路模型很好的满足了： 静态场景 + 高精度路面 + 动态交通流 + 基于物理模型的天气场景。 将这四者结合起来并不容易，直到2022年的今天，能完成的厂家也不多。

官网 & 介绍：

1. Driving Simulation for autonomous driving, ADAS, vehicle dynamics and motorsport (rfpro.com)
2. rFpro - Wikipedia

教程 & 案例：

1. rFpro Tokyo Digital Twin - YouTube （rFpro重建东京C1高速）

5.4.3 Parallel Domain - 2017

Parallel Domain 是一家位于加州的初创公司。其主要业务方向是“利用AI自动生成高质量的虚拟环境，用于自动驾驶的仿真测试”。

结论： 目前没什么实质进展，官网的几个Demo，看起来Carla基本都能做到，场景建立给的自由度也不高，知道有这么个公司就行。

官网 & 介绍

1. Parallel Domain | The New Data Pipeline for Computer Vision
2. 仿真初创公司 - Parrallel Domain（2017创立） - 知乎 (zhihu.com)
3. 提供的一个公开数据集： Bicycle Detection - Parallel Domain 、
4. GitHub - parallel-domain/pd-sdk

5.4.4 Cognata - 2016

以色列创业公司，主要业务集中在 场景生成 以及 传感器仿真（支持超声雷达、热成像仪） 。提供通用型的场景库，也可以使用使用Cognata Studio UI + ASAM OpenSCENARIO® 脚本（动态）创建自定义场景。

• 仿真接口：Simulink、ROS
• 联合仿真：SUMO交通流
• CI/CD：Jenkins、Bamboo
• 支持标准：OpenDRIVE，OpenSCENARIO

分析： 除了支持用OSC自定义动态厂商，其他看来没什么新鲜的，知道名字就行了。

官网 & 介绍：

1. Cognata 科纳特 - 自动驾驶和ADAS仿真测试软件 机器人仿真软件
2. Cognata Ltd. - YouTube （YT官方账号）
3. SUMO联合仿真Demo： Cognata Traffic model - Sumo 3rd party Integration - YouTube

官网提供了一些公开的数据集（虚拟数据），可邮件申请。

本章Ref：

1. 白皮书系列；
2. 交通工程跨界思考：何为无人驾驶仿真中的交通流仿真以及可用平台有哪些？ - 知乎 (zhihu.com) （交通流领域概况，推荐阅读）
3. UE4-Vehicle车辆载具探索-运动 - 知乎 (zhihu.com)
4. 微观交通流仿真Python实现 - 知乎 (zhihu.com)

6. 仿真通信仿真接口与分布式计算

（这部分不太懂，待学习，写的也比较糟，谨慎阅读）

1-5节阐述了自动驾驶仿真包含的核心模块：动力学、传感器、静态、动态的场景。而搭建一个完善的自动驾驶仿真系统，还缺少几个重要拼图： 通信环境 和 分布式计算 。因为笔者也不懂，因此只做简要介绍。

6.1 通信环境

前面提到，按照自动驾驶算法的开发流程，完整的开发需要经历MIL、SIL、HIL、VIL、DIL。一般情况仿真软件的支持会止于HIL。对于仿真软件，需要提供与被测对象之间的 信息传输环境， 即所谓的 “仿真接口” 。

目前可以通过通信中间件传输仿真数据，并将其转化为被测对象所需的数据格式进行传输。中间件类型有很多，常用有ROS、ROS2、AutoSAR、CyberRT等，其关键在于如何保证实时性，减少仿真消息的延迟以及丢失的可能性。（例如Apollo 3.0之前采用ROS，但其非实时性造成较大影响，后来百度基于ROS和DDS开发了CyberRT）

在自动驾驶开发过程中，如果是单独实现或测试一个算法，那么直接拿写好的算法在仿真软件上测试就可以了，但是如果是需要测试已经开发好的软件，比如apollo和autoware系统，则需要实现 仿真软件和自动驾驶系统的对接 。一个简单的想法就是通过桥接器实现，目前carla和lgsvl都实现了通过桥接器和自动驾驶系统的对接（例如Apollo与lgsvl的桥接）

6.1.1 仿真接口

“仿真”作为自动驾驶开发链路中的一环，其需要和其他环节紧密结合在一起。但很多软件在上下游链路打通时则非常麻烦。比如：

1. 一些仿真软件只能支持WIN，而现在自动驾驶开发的环境都是在Ubuntu环境下；
2. 一些传统仿真软件的云端并行仿真兼容性不好，有些是最近版本才开始兼容云端仿真。
3. 目前仿真企业的商业模式是几台电脑装软件就收几套License费用，显然这种模式对用户十分不友好。随着云端并行仿真的兴起，按照服务收费的SaaS+PAAS模式对客户显然更加友好。

对于一些科技巨头，除了研发仿真软件外，还更加注重仿真平台与其他工具链的集成与打通，形成一套全栈式的解决方案。比如华为的Octopus的仿真模块是与VTD合作开发，嵌入了Carmaker的动力学。在此基础上提供了云端一站式的仿真评测工具链，从代码仓库接入、版本管理，到仿真、评测，可以实现开发链条的闭环。这样，车企使用起来，上手更容易，适配成本也更低。

通信协议：

这是个完全开源的自动驾驶仿真软件，后端是UE4，客户端用Python和C++都可以写，官方的Python文档写得很好很好，而且数据接口是RPC式的，比起一些基于自定义协议的（比如VTD的RDB，腾讯TADSim的基于Protobuf自定义协议等）要方便很多，不用自己写解析协议的代码，一些关于同步、频率的问题可以暂时往后放放，先实现功能，看到反馈。

链接： https://www. zhihu.com/question/4692 63088/answer/2223537795

Ref：

1. 两万字详解自动驾驶开发工具链的现状与趋势-面包板社区 (eet-china.com) （推荐阅读）
2. 云仿真场景库 - CSDN

6.1.2 案例与Matlab 的联合仿真（基于ROS2 Bridge）

1. Matlab与Carla或Lgsvl联合仿真之matlab配置 - 知乎 (zhihu.com)

6.2 云仿真与并行加速

不懂，待学习

云端并行仿真无疑能大大提升自动驾驶开发效率，科技背景的企业如华为、腾讯的仿真平台可以无缝衔接其云平台。当然其他仿真公司的产品也开始逐渐支持并行仿真，以及支持部署在私有云和公有云上，例如VTD的方案。

Ref：

万字长文 | 谈谈自动驾驶仿真 - 知乎 (zhihu.com)

7. 自动驾驶仿真平台/软件（2022.06.01）

该章节读者没必要浪费精力浏览，直接看自己感兴趣的平台即可。互联网上类似文章基本基本上是抄来抄去，且废话连篇。想要真正将一款软件平台的特性阐述完整需要很大的篇幅，并且结合众多图例和视频Demo，受限于篇幅和精力，本文不会这么做。

我会沿着本文的逻辑，重点介绍一下其动力学、静态场景、动态场景、仿真运行的一些方案以及软件的核心特色。详细介绍的文档、视频演示放在对应的ref栏里，想要详细了解的可以查阅。

另外，由于专业领域算比较小众，商业化软件大部分都是没有破解版本的。除了Carsim、Prescan、Matlab、Vissim这些用户基数大一些的软件会有盗版存在。

• 细分领域仿真软件 2022.06

综合自动驾驶仿真软件/平台 - 2022.06

*热门的比较有特色的仿真软件用*标出 ， 相对冷门软件用后续不做介绍，感兴趣读者可自行调研。

7.1 传统仿真厂商

这些传统的仿真厂商开发的仿真软件，一些是由动力学软件进化而来，比如Carmaker、PanoSim，另一些则是做ADAS仿真起家，比如Prescan、VTD。其特点有：

1. 一般支持与Carsim 的联合仿真、也能较好的支持Simulink仿真；
2. 支持从MIL到HIL的在环仿真；
3. 仍然是较为可靠的OEM、Tier1的生产力工具 ，基本靠卖给企业、研究团队License赚钱；

一个趋势是， 此类传统仿真供应商，在最近的版本中，也基本都开始使用游戏引擎来对增强场景的渲染，具体可见本章开头的那张表，在后面的叙述中就不再重复提及 。可见游戏引擎作为3D技术的集大成者，基本在自动驾驶仿真业界达成共识。例如下图中Prescan最新版本即采用Unreal引擎取得了还不错的场景仿真效果。

7.1.1 Vires - VTD（Vitual Test Drive）

在自动驾驶仿真软件中，VTD是一套绕不开的软件。这是因为其开发者 德国VIRES公司（2017被MSC收购）是ASAM-OpenDrive，OpenCRG以及OpenScenario标准的主要贡献者和维护者 ，VTD的功能和存储也依托于这些开放格式。VIRES公司很大程度上推动了静态、动态场景的标准化进程，其中也包括高精地图的标准化。

其功能模块基本也就是上面提到的那些：

1. 路网搭建： VTD提供了图形化路网编辑器 Road Network Editor (ROD) ，可以构建较为复杂的静态道路环境的同时，还可以导入、导出OpenDrive高精地图。不过，VTD应该不支持自定义的场景元素库。
2. 动态场景配置： VTD提供了图形化的交互式场景编辑器 Scenario Editor ， 在地图上可添加自定义行为控制的 交通体 ，或者是连续运行的 交通流， 还可以接入SUMO、VISSIM的交通流（常规操作）。
3. 场景渲染： VTD并未基础游戏引擎做渲染，从Demo可以看出， 其场景渲染效果比较糟糕。
4. 动力学仿真： VTD可以接入Carsim、Carmaker、以及MSC自家的ADAMS RT。
5. 仿真运行： 支持SIL、HIL，支持与Apollo的联动、算此类仿真企业的传统艺能。

较多德系汽车厂商和Tier1，比如Bosch都采购了该软件。后面其他软件的特性基本和VTD大差不差，因此简要叙述。

官网：

1. Virtual Test Drive (VTD) – Complete Tool-Chain for Driving Simulation (mscsoftware.com)

教程&介绍：

1. Virtual Test Drive——驾驶仿真应用的完整工具链_哔哩哔哩_bilibili （能看出场景渲染很差）
2. VTD（Virtual Test Drive）基础培训-QuickStart_哔哩哔哩_bilibili
3. VTD-敢卖100w+人民币的自动驾驶仿真器 - 知乎 (zhihu.com)
4. VTD和CarMaker/Carsim车辆动力学的联合仿真方案 - 知乎 (zhihu.com)

7.1.2 IPG - Carmaker

1. Carmaker是以 动力学仿真 起家的仿真平台，自家的动力学比较优秀；
2. IPG Road静态场景： 可以配置GUI模拟多种道路场景（支持HERE地图导入，OpenDrive导出），可以对道路的几何形状以及不平度、粗糙度进行定义（支持OpenCRG）；
3. IPG Traffic动态场景： 没什么新鲜的，支持OSC 1.0；
4. IPG Driver： 自适应的驾驶员模型；
5. 可以导入rFpro的场景，前面也提过；
6. 支持Docker，支持云计算；
7. 支持AUTOSAR、FMI标准接口；

官网 & 介绍：

1. CarMaker | IPG Automotive (ipg-automotive.com)
2. CarMaker 10.0 Release By IPG Automotive | UNIGINE: real-time 3D engine

7.1.3 Siemens - Prescan - 2013

1. Tass International 研发，2017 年 8 月被西门子收购，在中国市场化做的不错；
2. 地图编辑器： 还不错，包含动态+静态，该有的元素都有。也支持导入OpenDrive，不过应该不能像RoadRunner一样根据OpenDrive自动生成道路，也不支持导出。
3. 传感器仿真： 还挺全，有V2X和超声。
4. 动力学模型： 没有动力学模型，因此支持与第三方动力学软件联合仿真，如CarSim、dSPACE ASM、 VI-Grade、AmeSIM等；
5. 对于传统的“基于MBD，围绕Simulink的设计流程、MIL到HIL的仿真测试”的支持都不错。
6. 支持基于云端布置大规模仿真；
7. 老版本的盗版非常多，人们用的比较多；

官网：

Simcenter Prescan 2020.4 -Create more realistic images | Simcenter (siemens.com)

视频教程：

【Simcenter Prescan 快速入门系列】 第1期：Prescan架构及基础场景建模_哔哩哔哩_bilibili

7.1.4 PanoSim - 2014

1. 国产软件 ，创始人邓伟文原为吉林大学千人教授，现为北航交通学院院长；
2. 动力学： PanoSim也是从动力学模型起家；
3. 静态场景： 有地图编辑器，支持导入OpenDrive生成数据，自动生成场景；
4. 场景渲染： 也是基于游戏引擎，但相对粗糙；
5. 对MBD、Simulink、X in Loop那一套支持比较好，这几年建设自动驾驶仿真平台，该有的模块也都有；

官网 & 介绍：

1. PanoSim—面向汽车自动驾驶技术与产品研发的一体化仿真与测试平台
2. PanoSim的个人空间_哔哩哔哩_bilibili （B站官方账号）

教程&案例：

基于PanoSim5.0虚拟仿真平台的自主代客泊车AVP系统开发教程_counteryida的博客-CSDN博客_panosim下载

7.1.5 VI-Grade + RightHook - 2005

1. VI-Grade动力学： 创业初期核心团队是ADAMS出身，因此是车辆动力学起家；
2. 做下图所示的汽车驾驶模拟器，驾驶员在环仿真比较强，经常举办、赞助大学生虚拟方程式大赛；
3. VI-WorldSim交通流仿真： 2020年推出，需要搭配RoadRunner创建静态环境使用；
4. RightHook传感器： 2021年与硅谷创业公司RightHook合并，传感器仿真能力大幅增强；
5. 仿真还是Simulink那一套支持的比较好；

官网 & 介绍：

1. Driving Simulator | VI-grade
2. VI-grade中国的个人空间_哔哩哔哩_bilibili (B站官方号)
3. VI-WorldSim交通流仿真软件线上系列教程_哔哩哔哩_bilibili （VI-WorldSim）
4. 虚幻引擎：为无人驾驶汽车开发和训练提供优质的用户体验 - 知乎 (zhihu.com)

7.1.6 SCANeR - 2017

1. SCANer是OKTAL与雷诺、达索成立的合资公司AVSimulation研发，并且 与ANSYS合作 ，作为ANSYS的自动驾驶仿真平台核心；尽管成立年限不长，但其技术、商业模式、合作方仍然比较老套，因此将其算作传统仿真厂商；这家公司也做上面VI-Grade做的那种模拟驾驶舱；
2. TERRAIN： SCANeR自带了一个静态场景编辑器，界面类似于RoadRunner，可以比较灵活的编辑道路、编辑地形，并添加树木、建筑，形成完整的静态场景。生成场景文件为OpenSceneGraph格式，可用Unreal Engine渲染；
3. 支持OpenCRG对道路表面的定义；

1. SCENARIO： 定义动态场景；
2. VEHICLE： 包含车辆动力学定义以及基于物理模型的传感器等；
3. SIMULATION：
1. 支持MIL到HIL的仿真；
2. 支持和Simulink联合仿真，传统艺能；
3. 提供API控制；
4. ANALYSIS： 仿真分析；

官网 & 介绍：

SCANeR studio - AVSimulation

教程 & 案例 ：

1. 上海益罗的个人空间_哔哩哔哩_bilibili （B站官方账号）
2. SCANeR Studio教程目录索引 - 哔哩哔哩 (bilibili.com)
3. 自动驾驶仿真软件：SCANeR使用介绍 - 知乎 (zhihu.com) （详细、推荐阅读）
4. 学习笔记|自动驾驶仿真工具-SCANeR studio_智驾仿真李慢慢的博客-CSDN博客_scaner
5. 虚幻引擎官宣：将为多用途汽车模拟环境注入新力量 _ 游民星空 GamerSky.com

7.1.7 Matlab Simulink + RoadRunner + RoadRunner Scenario

1. Simulink在传统的整车软件开发中发挥了重要作用，甚至是主要的生产工具；当前Mathworks的自动驾驶开发仿真工具链也一直在不断进化；
2. 动力学： Automated Driving Toolbox - Vehicle Dynamics Block Set；
3. 静态场景： RoadRunner，前面介绍过，目前业界最好的静态场景编辑器；
4. 动态场景： RoadRunner Scenario，前面也介绍过，目前最好的动态场景编辑器；
5. 场景渲染+传感器： 基于Simulink Unreal Plugin，还可以；
6. 仿真： Simulink；

官网 & 介绍：

MathWorks - MATLAB 和 Simulink的制造者 - MATLAB & Simulink

7.2 开源平台

前面的商用仿真软件的优点在于其完成度和严谨性都比较有保障，作为OEM稳定的生产力使用。但是对于研究者而言，往往需要对软件进行深层改动，以满足特定需求以及研究目标，对实际生产中的很多问题并不看重。

因此，这个时候Carla、LGSVL、AirSim等开源模拟器是更好的选择，这些模拟器通常作为研究平台创建，以支持强化学习或机器学习的合成数据生成，通常需要不小的额外的努力来集成用户的自动驾驶系统和通讯模块。

7.2.1 Carla

1. 开发者： 巴塞罗那自治大学 + Intel + Toyota北美，Server/Client架构；
2. 交互控制： 目前通过Python API操作，无GUI；
3. 动力学： Carsim接口；
4. 静态场景：

• 自建：RoadRunner导出OpenDrive与Fbx；
• 开源：提供几个开源的测试训练场景；

1. 动态场景： 可导入RoadRunner Scenario场景编辑、与SUMO、VISSIM联合仿真；
2. 场景渲染： 算做的比较好的，但不是PBR；暂时没有RayTracing；
3. 传感器仿真： Lidar用CPU跑的，暂时还没有用GPU跑Lidar仿真；
4. 仿真测试： 支持ROS、ROS-Bridge，包含自动驾驶系统的3种方法:
1. 经典的感知、定位、决策、控制模块化方法；
2. End to End强化学习方法；
3. End to End模仿学习方法；
5. 拓展： OpenCDA = Carla + SUMO；

官网 & 介绍：

1. GitHub - carla-simulator/carla: Open-source simulator for autonomous driving research.
2. CARLA Simulator - YouTube （YT官方账号）
3. An in depth look at CARLA's sensors - YouTube

联合仿真案例：

1. Carla学习——1.Carla和sumo联合仿真 - 知乎 (zhihu.com)
2. Matlab与Carla或Lgsvl联合仿真之matlab配置 - 知乎 (zhihu.com)

OpenCDA：

1. ucla-mobility/OpenCDA: A generalized framework for prototyping full-stack cooperative driving automation applications under CARLA+SUMO. (github.com)
2. 叶小飞 - 知乎 (zhihu.com) （Open CDA作者，其有Carla的文章）
3. OpenCDA：一个开源的多车协同自动驾驶仿真平台 - 知乎 (zhihu.com)

7.2.2 LVSVL——LG Silicon Valley Lab

1. 2022年1月宣布停更， SVL Simulator Sunset Plan ；
2. 交互控制： Python API；
3. 传感器： 都有，包含Velodyne 128, 64, 32线激光雷达，Conti毫米波雷达；
4. 静态场景 ：貌似不能编辑，可以RoadRunner导入；
5. 动态场景： API；
6. 高精地图： 提供高精地图插件；
1. 导入：Apollo5.0、Autoware Vector map、Lanelet2、OpenDrive 1.4；
2. 导出：Apollo 5.0、Lanelet2、OpenDrive 1.4；
7. 仿真： 支持ROS、ROS2（Autoware）和Cyber RT（Apollo）；
8. 支持SIL和HIL；

官网 & 介绍：

1. GitHub - lgsvl/simulator: A ROS/ROS2 Multi-robot Simulator for Autonomous Vehicles
2. Home - SVL Simulator （官方文档）
3. [中文] LGSVL Simulator: A High-fidelity Autonomous Driving Simulator - YouTube （详细的特性介绍，推荐）
4. LGSVL_Simulator的个人空间_哔哩哔哩_bilibili
5. 驾驶模拟器之LGSVL篇：一个高保真的自动驾驶模拟器 - 知乎 (zhihu.com)
6. Lgsvl自动驾驶仿真器介绍（一） - 知乎 (zhihu.com)

教程&案例：

自动驾驶 - 知乎 (zhihu.com)

7.2.3 AirSim

1. 无人机及自动驾驶模拟开源项目， 已永久停更 ；
2. 交互控制： C++、Python、C#、Java API；
3. 动力学： 自带动力学模型，糙；
4. 传感器： 无Radar，有供红外相机与事件相机；
5. 静态场景： 提供开源城市街景，还算丰富；
6. 动态场景： 未知；
7. 延续了微软一贯风格，封装过于严密，自定义地图，NPC，天气都不可行；
8. 仿真测试： 支持ROS、ROS-Bridge，主要用于测试深度学习、 计算机视觉和自主车辆的端到端的强化学习算法；

官网 & 介绍：

GitHub - microsoft/AirSim: Open source simulator for autonomous vehicles built on Unreal Engine / Unity, from Microsoft AI & Research

7.3 国外科技公司 & 创业团队仿真平台

7.3.1 Nvidia Drive Constellation（推荐了解）

Nvidia的架构非常attracive，且富有科技感。但互联网上对其的介绍比较模糊，没有很好体现其方案的优点与特性。

• Nvidia Omniverse平台——内容创作工具间的桥梁

首先要介绍的是Omniverse，其是一个协作式的三维设计平台，以及一个多GPU的实时虚拟仿真平台。Omniverse使用了统一标准的USD文件格式以及MDL材质等开源标准，能够与3DS Max、MAYA、UE、Blender等等一系列设计软件链接。这就使得不同的设计人员能够在各自软件下对同一个项目进行实时编辑，并且在Omniverse上同步渲染。

比如说，A可以在3DS Max上调整一个椅子的位置，B可以在MAYA上给椅子旁边加上草丛，C可以给模型机上纹理和贴图，D可以在UE5里面为这个场景添加物理引擎。

Omniverse如同3D设计界的协作文档那样，极大加速了设计的工作流程。而且将Ray Tracing、AI技术、计算等集成到3D设计的pipeline中。 因此Omniverse也被称为是“元宇宙”的基建工程。

Omniverse：

1. Omniverse Platform for 3D Design Collaboration and Simulation | NVIDIA
2. 连接未来，NVIDIA Omniverse为何成为新一代创作神器？ (baidu.com)
3. Omniverse的View功能怎么用？ - 知乎 (zhihu.com)

• Drive Sim——Powered by Omniverse

Nvidia的Drive Sim是一款基于Omniverse平台开发的、端到端的自动驾驶平台。其主要的作用是进行自动驾驶的 传感器仿真 以及 场景仿真 。传感器仿真是基于物理模型，实时Ray tracing技术也是英伟达的绝活。

而在静态场景搭建方面，英伟达亦采用和Waymo类似方案，用到深度神经网络对实际采集数据进行合成，快速、自动化地生成静态场景（不过，这里具体地技术方案没有查到）。下图的案例中，Nvidia和奔驰合作，在斯图加特采集数据构建了道路的数字孪生。

利用Omniverse，用户是可以构建扩展的传感器模型、动态交通流模型、3D资源等等。

Nvidia Drive Sim：

1. NVIDIA DRIVE Sim | NVIDIA Developer
2. NVIDIA DRIVE Sim Powered By Omiverse | NVIDIA Blog （推荐阅读）
3. NVIDIA DRIVE Sim, Powered By Omniverse - YouTube （推荐观看）
4. 用于DRIVE Sim 的 Omniverse Replicator 加速自动驾驶汽车开发|传感器|drive|sim|神经网络_网易订阅 (163.com)

• Drive Constellation = Drive Sim + AI ECU

最终来到了Nvidia的自动驾驶仿真平台Drive Constellation，其在Drive Sim的基础上又增加了一套车辆的ECU服务器。 平台由两台服务器构成：

那么由上述架构可知，其属于 与自家的ECU硬件耦合 的 实时HIL方案 ，真实性很高；并支持大规模部署。

1. 动力学模型： 主要由dSPACE ASM合作提供，也有Carmaker的模型；
2. 静态场景： 基于Nvidia Omniverse；
1. 如在上面给到的Demo里面，Nvidia团队在斯图加特进行了实际路采，而后利用神经渲染将其转换为静态场景；
2. 也可以由Mathworks RoadRunner建立静态场景导入，可使用Hum3D的资源库；
3. 传感器： 该有的也都有，尤其是支持Luminar的转镜式激光雷达模型；
4. 高精地图： Nvidia目前已收购高精地图厂商DeepMap，未来必然会进行整合；
5. 验证系统： 可接入Foretellix；

官网 & 介绍：

NVIDIA DRIVE Sim | NVIDIA Developer

教程 & 案例：

1. NVIDIA DRIVE Sim - YouTube （推荐观看）
2. NVIDIA DRIVE Constellation 1 - YouTube

7.3.2 Carcraft（信息很少）

Waymo的自动驾驶技术全球最强，并且其自动驾驶技术的强大，很大程度上源于其仿真平台的完善。但Waymo透露的具体技术信息少的可怜，仅有一些宏观的方案。

比如，其拥有的25000余辆“虚拟车队” 每天可以在仿真平台CarCraft上行驶2000万英里，虚拟里程以一年50亿英里的速度迅速上升。Waymo基于现实场景搭建了丰富的虚拟场景库，包含美国奥斯汀、凤凰城、旧金山、山景城等城市的Digital Twin，并且还在加州的非公开道路上构建了众多的Corner Case，这都使得自动驾驶汽车能够取得突破（这一过程也消耗了大量人力物力）。

聊一下Waymo的商业模式： 尽管Waymo的自动驾驶技术实力很强，但其商业化却是最为困难的。Waymo并不像其他自动驾驶厂商如Cruise、PonyAI一样，为整车厂提供L2/ L3级别的量产方案，而是想通过大面积运营Robotaxi来实现L4/ L5的商业落地。其一直采用最为昂贵的激光雷达设备 + 昂贵的算力 + 多传感冗余的硬件方案，使得其单车成本超过20万美元，这是完全没有利润空间可言的。

Waymo目前在前面提到的那几个有Digital twin的城市都开展了Robotaxi的运营，并号称取消了安全员，但和其他Robotaxi如百度、Cruise一样，速度、形势区域等都被加以限制。不同的是Cruise背靠通用已经做了相当多L2/L3级别的量产项目落地，百度Apollo也在中国国内有不少OEM的定点。Waymo在这方面的确非常头铁。

官网 & 介绍：

1. Waymo Driver – Waymo
2. Waymo - YouTube （YT官方账号）
3. Waymo details 'Carcraft' simulation software, 'Castle' testing site for self-driving car training - 9to5Google

7.3.4 AAI - 2017

1. AAI （Automotive Artificial Intelligence），2017年成立于柏林的初创公司；
2. 静态场景： 有道路编辑器和场景编辑器，类似RoadRunner，场景文件格式为fbx；这家公司也做一些数字孪生的场景，比如柏林市的一些道路；
3. 交通流仿真： 基于真实的交通流数据，应用了监督学习以及强化学习技术生成，可以调节车流的密度、车辆混合、以及攻击性水平等（相对比较创新的方法）。可以可以自动抓取生成OpenScenario文件；
4. 仿真支持： 使用实际驾驶数据，训练AI模型生成驾驶员模型。
5. i-Label： 有个简陋的图像标注工具
6. 主要合作方： Conti、Audi、四维图新；

官网 & 介绍：

1. Automotive Artificial Intelligence (AAI) GmbH (automotive-ai.com)
2. Automotive Artificial Intelligence - YouTube （官方YT账号，里面不少展示的Demo）

7.3.5 Metamoto - 2016

1. 美国的创业公司，被以色列的Foretelix收购，Foretelix是OpenScenario2.0的重要起草单位，其推出了场景描述语言M-SDL（Measurable Scenario Description Language）；
2. 评价： 看起来完成度仍然不高，没什么新鲜的；据说传感器仿真做的还不错；

官网 & 介绍：

1. Foretellix - Automated driving systems testing tools for simulations
2. Metamoto, Inc. - YouTube （YT官方账号）

7.4 国内互联网公司平台

国内互联网公司的仿真平台的特点：

1. 巨头们手上的资源极为丰富，因此架构极为宏大，平台几乎涵盖自动驾驶开发的每个角落，“仿真”仅仅是其中的一部分；
2. 新闻和宣传很多，但废话连篇，官网也几乎没有详细的介绍与Demo演示 ，平时基本也只对合作客户开放， 公开的细节信息很少 ；因此下面的介绍也只能是特别宽泛；
3. 基本在各类白皮书、商业报告都会刷存在感，凑个个数。但除此之外捂的非常严实；
4. 这些厂商云技术是强项，这方面的支持会好很多；

7.4.1 腾讯TADSim

1. 腾讯云与智慧产业事业群 - 自动驾驶事业部开发，算是信息披露多，且能商用的；
2. 动力学： 有集成的车辆动力学模型，也可以用Carsim的；
3. 高精地图： 内置了腾讯高精地图，支持全国高速和快速路仿真（腾讯已完成测绘）；
4. 传感器自研，交通流自研，虚实一体交通流，可实现场景的几何还原、逻辑还原及物理还原；
5. 场景编辑自研， 支持OpenX标准， 有一部分数字孪生资产；
6. 该腾讯团队在 OpenScenario、OSI标准制定 时候深度参与；
7. 分布式架构，支持在Windows、Linux和Web环境下部署；支持海量场景的并行计算；
8. 仿真：
1. 支持MIL/SIL/HIL/VIL需求，覆盖V-Shape开发流程，可做生产力工具；
2. 支持ROS、Simulink、LCM等多种接口；

官网 & 介绍

1. TAD Sim和腾讯在OpenX系列标准 制订过程中的相关工作 （C-ASAM的一个介绍，比较细致，推荐）
2. 腾讯TAD Sim仿真平台，助力破解自动驾驶落地困境 - 云+社区 - 腾讯云 (tencent.com)

7.4.1 百度AADS

1. 这就是百度在19年发在《Science：robotics》上的一篇论文的工作。三年过去系统进展如何、是否商用化存疑。
2. AADS (Augmented autonomous driving simulation using data-driven algorithms) 是百度研发的 增强现实的自动驾驶仿真系统。
3. 静态场景： 基于图像渲染的场景图片合成框架； 使用 LiDAR 和相机扫描街景实现自动化3D建模。
4. 交通流仿真： 基于真实数据；

官网 & 介绍：

告别「五毛」仿真环境：百度增强现实自动驾驶仿真系统登上 Science 子刊 - 知乎 (zhihu.com)

论文： Sci-Hub | AADS: Augmented autonomous driving simulation using data-driven algorithms. Science Robotics, 4(28), eaaw0863 | 10.1126/scirobotics.aaw0863

7.4.3 华为Octopus

1. 自动驾驶部门与诺亚方舟实验室合作完成；
2. 架构很复杂，细节都没有，内容全靠猜； 以华为的体量，应该做了很多工作，但相关信息少的可怜；
3. 只知道核心仿真模块是基于VTD做的；也用了Carmaker的动力学模型；

官网 & 介绍：

1. HUAWEI Octopus 自动驾驶云服务-华为云 (huaweicloud.com)
2. 揭秘“华为八爪鱼”，自动驾驶云服务加速智能汽车时代到来_自动驾驶云服务_华为云论坛 (huaweicloud.com)
3. 详解华为“八爪鱼”的六大关键特性 - 知乎 (zhihu.com)

7.4.4 阿里巴巴

团队主要在达摩院，信息不多，由于阿里电商平台的性质，对汽车自动驾驶的需求不算高，主要和京东、顺丰类似做一些物流小车。

7.5 国内创业团队仿真平台

7.5.1 沛岱（上海）技术有限公司– Pilot-D GaiA - 2017

2017年脱离于某德国ADAS上海研发部门，成立沛岱；实在没什么新鲜的，粗略判断实力不强，可以进官网看看。

官网 & 介绍：

沛岱（上海）汽车技术有限公司 (pd-automotive.com)

7.5.2 51SimOne - 2015（Attractive）

1. 51SimOne是51World在智能汽车领域推出的仿真产品，本身51World是做数字孪生、智慧城市这类业务起家，因此 在场景构建上的能力十分出众；
2. 动力学： SimOne-Bus、SimOne-Car、SimOne-Truck都是自研的；
3. 静态场景： 有道路编辑器WorldEditor，功能方面和RoadRunner比较像
1. 支持OpenDrive文件的导入、导出、编辑，
2. 支持导入GIS数据还原路网；
3. 支持导入点云数据还原路网；
4. 平台内置了一系列场景库和测试案例库，
4. 动态场景搭建： 支持配置全局交通流，编辑独立的交通智能体（车辆、行人），支持OpenScenario；光照、天气这些属于基本操作；
5. 传感器： 基于物理模型、自研，强项；
1. Camera：包含单目、广角、鱼眼，输出语义分割图、 深度图、 2D/3D包围盒（常规操作）
2. LiDAR：点云原始数据，标注点云数据，Bounding Box（常规操作）；
3. Radar：目标级毫米波Radar检测物数据；
6. 仿真：
1. C++、Py、OSI、ROS接口；
2. 支持MIL到HIL的V-Shape开发；
3. 支持多车协同互动；
7. PAAS 商业模式，可以本地部署，也可以私有云、公有云部署；
8. 51SimOne有一套开源的版本，链接见Ref；
9. 51SimOne也做驾驶模拟器；
10. 案例： 毫末物流车

官网 & 介绍：

1. 官网： 智慧交通_汽车_高速_城轨_机场_解决方案提供商｜51WORLD (51aes.com)
2. 开源版本： 51Sim-One Cloud (51aes.com) （推荐点进去试试）
3. 驾驶模拟器： 国内首个多车互动仿真系统，加速自动驾驶商业化落地_哔哩哔哩_bilibili

7.6 理想的仿真平台与工具链

纵观这些自动驾驶仿真的平台、工具，可以看出自动驾驶仿真实在是一个庞大的议题，其中的一些子模块都可以单独作为一门学科，一个能够实现流程纵向打通的、完整的仿真平台体量必然不会太小。而现存的仿真平台或多或少都嗨存在一些缺点和不足。

那么，比较理想的自动驾驶仿真平台应当具备以下特性：

此时，可以回过头看1.2.3节的内容，随着对各个模块的展开叙述，我们对“仿真平台的趋势和需求”也逐渐细化、清晰。

8. 自动驾驶测试标准——ASAM为例（2022/06/20）

前言：

关于这一节的内容，业界也正处在一个摸索发展的阶段。在测试场景标准方面，德国的ASAM Open X标准基本得到了业界的广泛认可，不出什么意外今后应当会是静态 + 动态场景的主流标准。

关于场景库，各家自动驾驶公司已经积累了一批场景库，而官方背景的中汽研也在主导建立一个大而全的场景库，意欲对后续的自动驾驶车辆功能进行测试认证。（注意：中汽研拥有对汽车标准法规认证的权力，所有主机厂车型上市前都需要通过其主导的各项认证）

下面的文字读起来会有些务虚，听上去空话套话多。但很多时候，也正是因为对标准建设的不重视，导致我国一些行业的长期落后与混乱。Anyway，可以为感兴趣读者提供一些视角。

8.1 概述

从上述的动力学仿真、传感器仿真到场景构建，到仿真接口与云计算，这些上下游仿真工具的打通以及平台的集成化发展，我们可以称之为 “行业的纵向打通” （通过前面的内容也可以看出，这的确是一个较为复杂痛苦的过程）。除此之外，行业内还需要有 “横向打通”， 这包含了：

1. 不同的软件平台间动态、静态场景的统一兼容格式标准；
2. 统一的仿真标准接口；
3. 标准化的场景库，以及标准化的测试用例；

其中最关键的是场景格式的标准化，毕竟场景才是当前自动驾驶仿真的核心以及最宝贵的资源。标准化场景的好处就不再赘述，基本都是些正确的废话。前面提到的RoadRunner是一个非常好的正面案例，在RoadRunner上建立一次静态场景，就可以导出几乎所有的仿真平台可用的格式，而不必重复建模。

当前，比较通用的用于自动驾驶的场景标准是德国自动化及测量系统标准协会ASAM旗下的Open X标准，该标准得到了业内的主机厂、供应商以及众多科研机构的认可。 当前涉及自动驾驶场景的软件都开始主动支持Open X标准 。但其中除了OpenDrive建设趋于完善、推广较为成功之外，其他的如OpenScenario，OpenCRG则刚刚起步，推广应用还有比较长的路要走。同时，国际标准化组织ISO也在逐步构建应用于自动驾驶的场景标准。除此之外，其他标准建设基本乏善可陈。

根据过往的经验，标准的制定是比较容易形成先发优势以及赢家通吃的局面的，行业不发生巨大转变的前提下，笔者更倾向于Open X标准在后期会一统江湖。

8.2 ASAM OpenX标准

注：内容所限，本章不会去深入解读这些文档，我后面计划写一下这些标准的解析

所有标准的说明文档、API都可以在官网下载到，十分详尽；

Open X标准的历史并不长，其从属于2016年德国联邦经济与能源部(BMWi) 启动 PEGASUS项目 （项目于 2019 年 5 月结项）。该项目旨在开发一套 自动驾驶功能测试的流程 ，以促进自动驾驶技术的快速落地。

而前面穿插提到的OpenDrive（XODR）、OpenCRG、OpenScenario（XOSC）三项 驾驶场景标准 即为Pegasus项目的研究成果之一， 而其中OpenDrive即是“道路模型标准”，这也就是为什么OpenDrive被高精地图行业作为标准格式之一的原因。

此三项标准由前面提到的VTD的母公司德国VIRES主导建立，并在2018年交由ASAM进行下一步的标准维护与开发。以此为契机，ASAM于2018年在《场景格式标准》的基础上开创了新一类标准—— 《自动驾驶仿真测试标准》。 2019 年 10 月，由宝马主导开发的Open Simulation Interface(OSI) 标准，正式移交 ASAM 进行维护与开发。再加上正在研发的OpenODD，ASAM 启动的 OpenX 包含标准已达6项。

8.2.1 场景举例

下面用一个简单的动态场景案例来理解OpenX标准中的“ 场景标准部分” ，在一个配备了红绿灯的路口：

• 左边有一辆自动驾驶车辆A，A当前面临黄灯，不知是否能通过路口；
• A后方左侧有一辆车B ，B前方有路障，大概需要并到A所在车道；
• 路口下方是货车C，其正在等红灯结束；
• 此时上方的人行道有一位行人P正在横穿马路；

那么这个场景大概需要以下描述内容：

一个场景主要的要素为，是谁（目标物体），在哪里（与道路或参照物关系），发生了什么（场景的动作描述），持续了多久（场景运行的时间），可见真实的动态交通场景要素极为复杂。

在Open X中，OpenDrive、OpenCRG、OpenScenario三个标准组合起来即可构成对上述静态+动态要素的全面覆盖，如下图所示。

8.2.1 OpenDrive——静态路网（高精地图）

OpenDrive项目于2005年由VIRES和Daimler启动，其定义了一个车道级的静态地图格式，换句话说也就是一种 高精地图 的标准。经过多轮迭代后，OpenDrive相对完善 ，已经广泛地被自动驾驶行业接受和认可。

一些基础概念可以参考：

关于OpenDrive更详细的解读，请参考ASAM官网。 关于OpenCRG标准的解读，我一直想写一篇文章来讲，但知乎的表格支持太差了！

官网 & 介绍：

ASAM OpenDRIVE®

8.2.2 OpenCRG——路面微观情况

OpenCRG全称是 Open Curved Regular Grid， 启动时间为 2019 年 8 月 28 日，2020年9 月，相对完善的OpenCRG 1.2版发布。OpenCRG一开始单纯是为了存储路面高程数据而开发，后来拓展为对 路面微观表面特性 的详细描述，比如路面的 表面起伏、粗糙度、摩擦系数 等。如此即可进行 轮胎模拟 、 振动模拟 和 驾驶模拟。

路面特性与整车动力学仿真高度相关，不同路况下允许的车辆操控极限、以及乘员的舒适度显然是不一样的。比如即便都是铺装路面，高速公路和二级公路允许的过弯速度显然是不一样的。这也就是为何前面提到的rFpro关注路面微观特性是一个开创性的工作。

OpenCRG的文件可以集成在OpenDrive中对道路表面的定义中（即<surface>部分），如此使用更为方便。OpenCRG除了提供详细的说明文档外，还提供了C-API以及Matlab-API，可以对路面数据进行读写、修改、生成、评估、可视化等操作。（如此是正确的标准制定方式，一份完善的标准不应当仅仅是一纸文件，这在后续的Scenario、OSI也有体现）。

• 工业界

目前业界基于OpenCRG已有一些比较有趣的工作。比如，比利时的激光雷达公司XenoTrack推出了专门扫描路面的激光雷达，并且可以直接输出OpenCRG文件，导入到自动驾驶仿真软件如Carmaker、SCANeR中。

Ref：

ASAM官网 ：

1. ASAM OpenCRG®
2. Digital Twin of a road with the help of OpenCRG - YouTube （Demo）
3. 路面形状のOpenCRG/OpenDriveデータ化 - YouTube
4. Jeongseon-gun detailed road 3D model for CarMaker - YouTube
5. Tank following a path defined by an openCRG road - YouTube

XenoTrack路面测量：

1. XenoTrack | Road Profile Lidar | XenomatiX
2. XenoTrack固态激光雷达道路测量结果输出OpenCRG数据以及在IPG Carmaker中的应用_哔哩哔哩_bilibili
3. XenoTrack采集的OpenCRG数字化道路数据导入SCANeR Studio仿真软件_哔哩哔哩_bilibili

8.2.3 OpenScenario——谁在哪儿干什么

在OpenDrive构建的静态路网基础上，OpenScenario是对虚拟动态场景的参数化描述。这包括了：

1. 对象： 车辆（车型、轴距、外观几何等）、行人（男女老幼）、非机动车等；
2. 轨迹： 在OpenDrive路网上的车道级路径规划、速度规划、车辆操作等；
3. 环境： 天气、光照、时间等；

• OSC 1.0-1.X

当前的OSC 1.0版本描述的过程中还涉及非常具体的分层，比如，从故事Story、活动Act、顺序Sequence、动作Maneuver、事件Event，行动Action—— 就如同导演电影一样 。

前面讲到的不少软件VTD、51World、TADSim、Carla都支持了OpenScenario V1.0（下方Ref中有51Sim对OpenScenario的解读以及产品特性）， 腾讯更是深度的参与了OSC后续的1.X 标准的制定 ，不过目前各模拟期间xosc的兼容性都比较差。

• OSC 2.0

而如上OSC 1.X采用XML语言构建的模型是一种“低层次的”、“具体的”规范格式，主要用于仿真工具的解析（PS：关于OSC V1.0的解析，可以参考esmini，CarlaScenarioLoader等开源项目）。

但此种方式已不足以覆盖测试需求，实际工程价值有限。因此，开发中的OSC 2.0计划在更高级抽象级别上来定义场景，并采用前述Foretelix主导研发的M-SDL语言-Measurable Scenario Description Language来对场景进行描述，其表达范例如下方。

当前1.X与2.0分别独立开发，OSC 2.0版本在2022年正式发布，到后面则会合成一个版本。

type storm_type: [rain, ice, snow]
struct storm_data:
 storm: storm_type
 wind_velocity: speed
scenario env.snowstorm:
 storm_data: storm_data with: