自动驾驶仿真及其工具链（6万字扫盲）
作者：BUAA火车侠成文日期：2022/06/20
背景：去年，团队需要以Carla为基础搭建一个自动驾驶的仿真平台，当时看了不少关于仿真的资料，记录了不少笔记，多达6W多字。不少内容和白皮书上类似，但个人觉得比白皮书更丰富，加入了不少我自己的调查内容，我认为我的表达方式大概也会更易懂一些。
<hr/>1. 前言（2022.05.20）
2022.05.18 这篇文章的本意是写一下自动驾驶仿真常用的软件，以及这些软件搭配使用形成的工具链。但越是深入调查，越是发现此话题比较宏大，学科交叉十分庞杂。因此决定不求速成，而是随着调查缓慢更新，在此过程中不断补全知识体系，通过讲解的方式增强学习效果，这也是笔者非常推崇的Feynman学习法的一次实践。
一些调查中关键的参考文献会特别标注，一些不确定的点也会指明。
自动驾驶仿真涉及学科：
仿真细分领域学科 与 技术领域车辆动力学仿真机械学、力学、车辆工程静态场景搭建1. 基于游戏引擎：计算机图形学
2. 基于神经渲染：深度学习动态场景编辑1. 微观交通流仿真：交通学
2. Senario编辑：计算机开发
3. 环境气候控制：计算机图形学、游戏引擎场景渲染计算机图形学、游戏引擎传感器仿真半导体、模拟信号处理、数字信号处理；各传感器细分学科仿真接口标准化、计算机科学分布式计算计算机科学仿真流程与标准1. 车规软件开发流程：车辆工程
2. 自动驾驶开发流程：车辆工程
3. OpenX标准制定：标准化
1.0 概述
[*]概念
自动驾驶的仿真测试：即以建立车辆模型并将其应用场景进行数字化还原，建立尽可能尽可能接近真实世界的系统模型，如此通过软件仿真即可对自动驾驶系统和算法进行测试。其包含了虚拟的驾驶场景、车辆的动力学系统、感知系统、并预留对接ADAS/自动驾驶系统的通信接口。虚拟仿真对于自动驾驶的意义不需要赘述——无论是业界领先的Waymo还是规模量产的Tesla，仿真技术都在其ADS/ADAS开发中起到至关重要的作用。
[*]仿真在自动驾驶系统开发中的位置
当前，L3+自动驾驶系统的研发主要基于数据驱动，其基本思路都是道路数据采集->数据预处理->数据挖掘->数据标注->模型训练->仿真测试->部署发布。
From Waymo：以数据驱动的自动驾驶开发链条
每一个环节都需要专属的工具或者平台（比如许多公司也都在开发自己的图像/点云标注平台），整套工具链的效率也决定了自动驾驶系统的开发、迭代效率。但在当前，整个工具链条冗长复杂，各平台工具间的割裂也比较严重，能把整个Pipeline跑通已经十分不易，很多车企为了提升整体效率，选择自己开发一部分平台和工具。
1.1 自动驾驶仿真平台架构包含模块
1.1.1 静态场景搭建
还原与真实世界一致的车辆道路静态元素，比如道路、交通标志、护栏、树木、建筑等等。显然，使用三维建模软件创建“素材库”，利用高精地图的矢量化图形对道路要素进行重建，然后再利用专业软件添加建筑、树木、地形等其他静态要素是一个可行的方案。当前，基本所有的自动驾驶仿真软件/ 平台都采用了该种方案，或向该方案靠拢。
也有科技公司如Nvidia、Waymo等采用神经渲染的方式，以极低的成本构建大场景，以真实图片为源头构建的场景比建模的更加真实。
1.1.2 动态场景搭建
除了静态层次，虚拟场景还包括了动态层，这个概念在高精地图也很普及。如下图是一种典型的道路分层结构，其中路网（Layer 1）、交通设施（Layer 2）属于静态层，交通管控（Layer 3）、交通流（Layer 4）、以及环境条件（Layer 5）都属于动态层。分层的具体标准可能存在一定差异，但其主体思想是一致的。
场景 = 静态 + 动态
驾驶模拟场景
动态场景首先包含了动态的交通参与者，如机动车、非机动车、行人、交通信号灯等。直观的想法是利用采集到的真实路况数据复现交通流，但此种方法成本高且速度慢。因此，如何自动化地生成合乎现实逻辑的交通参与者，是自动驾驶仿真中的一个热点课题。
同时，动态场景也包括了天气变化（晴、阴、雨、雪、雾、霾等），时间变化（光照变化）等。所有动态要素需要严格遵循现实世界的物理规律，而在此方面，显然游戏引擎能发挥重要的作用，其在场景渲染、物理引擎等真实场景模拟的能力上，比传统仿真软件强大许多。
科技公司在游戏引擎的应用上走在了前列，这在最新的自动驾驶仿真平台技术上均有所体现，比如Carla、微软AirSim、腾讯TAD Sim都是基于Unreal引擎开发，LGSVL则是基于Unity引擎开发。（目前来看，UE引擎已经和Unity拉开了差距，将Carla升级到UE5之后场景渲染水平极高）
UE5 黑客帝国渲染效果
在自动驾驶仿真领域，场景搭建是最为核心的领域，往往也最为耗时耗力。场景库的测试、复用乃至与交易是一大可见的趋势。这就需要统一标准的化的场景文件。例如德国自动化及测量系统标准协会（ASAM）旗下的OpenDrive高精地图标准，本身就是一种静态场景数据标准，而同为ASAM旗下的OpenScenario则为动态场景标准，这都会进行介绍。
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。
例：Carla传感器配置脚本
值得一提的是，Ground truth模式下，虚拟传感器输出的场景带有100%正确的标签，即带有100%正确语义的图像/ 点云，相比于现实中采集的数据需要经过耗时且昂贵的人工标注，此种虚拟采集的数据成本极其低廉，对感知系统中的检测、分割、跟踪算法，以及决策系统的算法模型训练也有着很大的推动作用。
1.1.5 通信环境 / 仿真接口
最后就是仿真软件和被测对象之间的通信环境，也就是所谓的仿真接口，其基础是利用计算机网络的完成信息传输。
一般情况下，可以通过通信中间件处理仿真数据，并将其转化为被测对象所需的数据格式进行传输。最常用的有基于ROS/ROS2、Cyber RT（百度研发）的中间件等，其关键在于如何降低仿真消息的延迟和丢失，以提升系统实时性。
自动驾驶仿真的通信方式
1.2 仿真软件的发展：从基于模型设计到数据驱动——以场景为核心
总结下来，当前自动驾驶仿真平台的主要组成为：静态、动态场景的搭建、车载传感器的仿真、车辆动力学的仿真、以及自动驾驶算法的接口；此外，还会利用云技术进行规模化部署仿真。而此种仿真体系的结构并非一蹴而就的，其经历了一个发展历程。
1.2.1 V-Shape开发流程
现阶段汽车软件开发主要采用V-Shape开发流程，分为设计开发流程（左）以及测试验证流程（右），包括低级别的L1、L2的ADAS功能开发流程也是如此，其具体过程如下：
典型的V型开发流程
在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的工具链的功能安全和测试验证流程严格且成熟，保证了车企规模化的稳定量产。比如：
[*]当前大多ABS防抱死、ACC自适应巡航等代码都是由Simulink开发后转成嵌入式平台的C代码；
[*]现行L2级别的ADAS功能，基本仍然是依靠Simulink来写控制逻辑和算法，也包括很多新势力整车厂；
传统基于MBD的开发流程
Carsim与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引擎联合仿真接口，提升了传统工具链在场景搭建方面的实力。
当前自动驾驶仿真工具的种类较多，联系十分复杂，本文后面会尽量梳理。不过当前自动驾驶仿真平台基本的技术方向基本一致：
[*]基于游戏引擎开发，以实现对静态场景的高保真渲染和物理模拟；
[*]有静态场景编辑功能，支持基于高精地图的静态场景搭建；
[*]有动态场景编辑功能，也有交通流仿真功能；
[*]传感器的仿真一般不算太复杂，一般仿真平台都会自带，关键是要基于物理模型；
[*]汽车动力学模型则一般由外部的专业仿真软件导入；
[*]逐渐转向云端仿真，可以通过添加硬件方式提高测试里程，典型案例如Waymo；
自动驾驶仿真的一般构成
1.3 自动驾驶仿真行业参与者
[*]根据1.2节 所叙行业发展历程，当前整个行业的参与者分为下面几类：
参与者类型仿真软件说明传统仿真软件企业MSC（Carsim、VIRES-VTD）、西门子TASS-Prescan、达索Oktal-SCANeR、IPG-Carmaker、Mathworks（Simulink、RoadRunner）、PTV-Vissim、rFpro、TSESIS、VI-Grade、Panosim（中国）美、德为主
对外售卖License初创仿真公司51Sim-one（中国，51World）、沛岱（中国）、RightHook、AAI、Cognata、Metamoto、Parallel Domain美、中、以色列为主
对外售卖License大型科技公司LG北美 LGSVL（开源）、微软AirSim（开源）、腾讯TAD-Sim、百度AADS、华为Octopus、NVIDIA Drive Constellation商业软件
一般只对核心客户开放自动驾驶厂商Waymo Carcraft、Cruise（通用汽车）、Pony AI、AutoX仅对内使用，不商用高校&科研机构巴塞罗那自治大学、Intel、Toyota Carla（开源）
德国国家宇航中心 SUMO（开源）一般会开源每一类参与者的技术优势以及侧重的方向都会有所不同。一般而言，传统仿真企业在车辆动力学、交通流仿真方面占有优势，“工业软件”所侧重的严谨、实用、稳定的风格会更浓烈。而初创公司和大型客机公司则在场景搭建、以及对L4+自动驾驶系统的支持都有较大优势，“工业软件”的风格则较为淡薄。
当然也会有资金雄厚的传统企业、车企收购初创的科技公司，例如达索持股SCANeR，Mathwork收购RoadRunner，丰田支持Carla的研发等。从产业结构上看，自动驾驶仿真基本以美国、中国、以及德国为主。这里面商业化软件的完成度会更好，对于SIL、HIL等生产力支持也会更完善，但开发者的灵活性显然会受到不小的限制，而开源软件则会与商业软件具有相反的特性。
软件的具体介绍请见chapter 8。
[*]OEM、Tier1采用的仿真软件（2022年）
国内企业仿真软件国外企业仿真软件上汽TAD-Sim、Matlab、PanoSim、51Simone戴姆勒Carsim、VTD、PanoSim一汽Panosim、Tesis、宝马Carmaker、VI-Grade、VTD、rFpro长安Prescan、Carmaker、PanoSim奥迪VTD、Cognata东风PanoSim大众Carsim、Carmaker、rFpro、VTD蔚来VI-Grade、Carmaker、rFpro、博世VTD、rFpro小鹏未知大陆AAI理想未知丰田Carla、rFpro比亚迪未知电装rFpro吉利Cognata福特Panosim、Carsim、RightHook、rFpro长城PanoSim通用Carsim、VTD、rFpro、PanoSim奇瑞PanoSim沃尔沃VI-Grade（S60车型）、VTD江淮PanoSim雷诺SCANeR、rFpro华为VTD（合作）、rFpro、PanoSimPSASCANeR毫末智行51Simone*此表需要逐渐根据积累调查补全，加粗字体表示已证实的、在产品开发中发挥作用的软件，而并非如“签订合作协议”等套话。
参考资料：
[*]2019中国自动驾驶仿真蓝皮书（推荐阅读，51World主导编写-对51Sim着笔墨较多）；
[*]2020中国自动驾驶仿真蓝皮书（推荐阅读，腾讯主导编写-对自家平台介绍多）；
[*]两万字详解自动驾驶开发工具链的现状与趋势-面包板社区 (eet-china.com)
[*]一文读懂自动驾驶仿真测试技术现状 - 知乎 (zhihu.com)
[*]场景仿真加速智能网联开发测试进程_哔哩哔哩_bilibili（VTD综述类视频，推荐观看）
[*]自动驾驶系统之软件仿真测试 - 知乎 (zhihu.com)
[*]自动驾驶仿真工具需求 - 知乎 (zhihu.com)
[*]如何学习自动驾驶仿真？ - 威士忌燕麦拿铁的回答 - 知乎
[*]Unity自动驾驶仿真 - 知乎 (zhihu.com)
[*]Prescan、Carsim、Simulink联合仿真 - 知乎 (zhihu.com)
[*]虚拟仿真测试介绍（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给出的解决方案是对模型进行大幅精简（但具体方式未知），在其推出的ADAMS Real Time版本中，对整车模型进行精简后仍然能够保持200个自由度，相比后面要介绍的基于总成特性的模型更为精准。其目前只能与同属MSC Software的VTD进行联合仿真，对其他自动驾驶仿真平台的支持一般。
2.2 基于总成特性的仿真——CarSim - 1996
而另一种更为简化、业界更为通用的整车动力学构建方式是，使用粗粒度的总成的特性，基于递推动力学求解。如此需要的参数更少，计算速度更快，自由度也更少一些。而其所利用的总成特性则由多体动力学、或者实验数据得出。可以粗略理解为：ADAMS的输出可以作为Carsim这类软件的输入，例如，由某一总成下零件的装配关系，根据多体动力学可以得到该总成的动力学特性。而Carsim可以通过底盘的动力学特性，模拟车辆在道路上运行的情况。
从上述建模的逻辑也可以看出，车辆动力学建模非常依赖于在常年的工程实践中积累的仿真、实验数据。即便是一个传统的方向，其行业壁垒仍然比较高。
代表性软件CarSim：由美国Mechanical Simulation 公司开发，其内置了相当数量的车辆数学模型，Carsim本质上就是一个模型库 + 参数库 + 求解器 + 后处理工具 + 用户界面。也就是说，其自带的模型都有一些“比较靠谱”的参数，用户可以“傻瓜式”地根据要仿真的车型，选择一个合适的模型，然后调整模型参数，即可快速的构建自己的动力学模型，省去了繁杂的建模过程。
因为CarSim做的是整车仿真，为了提升仿真的速度，因此其模型都比较简单，通常就是简单的公式或者基于特性（二维、三维查找表）的模型，可更改的参数也比较少，但从整车层面来看，其精度也是可以接受的。
目前，CarSim里面并没有电动汽车的模型，不过可以通过手动魔改油车模型来实现：重新设置重量、以及转矩曲线来实现电动车的动力学建模。笔者尝试了Carsim的一些设置，的确比较简单、容易上手。
CarSim的车辆模型界面——车型为C级车，定义了簧上质量、空气动力学、发动机、变速箱、刹车、前后悬挂、轮胎等参数
CarSim也提供了ADAS相关的功能，比如简单的静态场景构建，以及控制算法的仿真。但更为普遍的做法还是通过接口将模型导出至其他平台进行联合仿真。由于Carsim的普及度非常高，因此它应该是当前对自动驾驶仿真平台支持度最好的动力学软件，大部分的仿真平台都为其预留了联合仿真接口，还可以通过Carsim自带的Unreal Plugin接入。
CarSim可实现简单的ADAS仿真
2.3 CarMaker、PanoSim、VI-Grade、dSPACE-ASM、AVL-Cruise、veDYNA、ANSYS Motion
上述几款软件也都是十分擅长动力学仿真的软件，很明显他们都是属于前面所述的“传统仿真厂商”。不过这些软件的特性其实并不一样，CarMaker、PanoSim、VI-Grade、ANSYS已经向着综合的自动驾驶仿真平台发展：
[*]在整车动力学基础上加强场景搭建、传感器模拟能力；
[*]支持导入标准格式的地图文件（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可以作为很好的替代品。
Simulink中的车辆动力学工具箱
REF：
[*]卿颜 - 知乎 (zhihu.com)（仿真从业者，前dSPACE员工，现SpeedGoat员工）
dSPACE：
[*]主页 - dSPACE
[*]无人车系统仿真相关软件介绍-dSPACE - 知乎 (zhihu.com)
Mathworks Simulink：
[*]Vehicle Dynamics Blockset 소개 (matlabexpo.com)
[*]如何用simulink建立整车动力学模型？ - 知乎 (zhihu.com)
[*]CarSim：Mechanical Simulation (carsim.com)
[*]CarMaker：CarMaker | IPG Automotive (ipg-automotive.com)
3. 车辆本体2: 传感器的仿真（2022.06.07）
3.1 传感器仿真概述
车辆本体仿真的另一个核心是传感器，既然是仿“真”，我们可以参考真实传感器原理如下：
[*]Radar：BUAA火车侠：自动驾驶传感器（二）：毫米波雷达Radar原理
[*]LiDAR：BUAA火车侠：自动驾驶传感器（三）：激光雷达Lidar底层原理
[*]Camera：BUAA火车侠：自动驾驶传感器（四）：数码相机Digital Camera原理
[*]GNSS-RTK：BUAA火车侠：自动驾驶传感器（五）：卫星导航GPS-RTK原理
[*]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数据转变为三维场景，进而可以得到更为逼真的渲染效果。这在目前是非常热点的研究方向。
Google展示的城市级神经渲染效果
3.1.2 核心2：基于物理的传感器模型
有了基于物理模型的场景，同样地，传感器仿真也要基于物理模型，例如LiDAR的仿真要还原激光发射-相交-反射的Ray Casting过程，Radar仿真则要模拟MIMO的FMCW连续调频波的发射-反射的物理过程。
传感器的基于的物理原理是不同的，因此环境给传感器带来的噪声和扰动项也是不同的，这都为传感器的仿真带来了不小的难度。因此，建立堪用的传感器模型门槛并不高，但要建立贴近真实的模型则难度陡然上升，很可能费时费力却只换来一点点提升。
在仿真平台中，对仿真传感器的基本需求有（流水账+废话，不用看）：
传感器需求Camera支持外参、内参、物理参数、相机缺陷参数的仿真LiDAR基于Ray Tracing，可以模拟真实的激光发射过程，并根据不同材质的反射强度模型输出带有噪声的点云Radar可以模拟MIMO、FMCW电磁波的传播，并且可对回波做数字信号处理GNSS/IMU支持GNSS信号丢失时住车的位置、速度、航向的累积误差，以及主车自身相关的GNSS/IMU信息V2X可以与路侧传感器相结合，仿真并下放路侧传感器的目标识别结果数据，并根据周边动态环境仿真信号的传输效率和丢包率理想传感器返回在距离主车一定范围内探测到的Ground truthRef：
[*]【RTX光线追踪-1】专业图形显卡支持的「光线追踪」是什么原理？_哔哩哔哩_bilibili
[*]PBR学习笔记（二） BRDF和微表面模型_哔哩哔哩_bilibili
[*]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模拟。
Camera仿真的过程
[*]镜头投影仿真
镜头的仿真参照了现实中的成像方式：通过相机外参 (R,t) ，将世界坐标 C_{world} 下的点 P(X,Y,Z) 先投影到相机坐标 C_{camera} ，再投影至归一化平面，最终投影到像素平面。之后，还需要对镜头存在的光学特性以及误差项进行仿真，比如焦距、径向畸变、切向畸变、炫光、泛光、晕影等。
当然具体地可以有小孔相机和鱼眼相机的类型，这仅仅是相机个数以及投影模型公式的不同，不算什么难点。
[*]传感器 + DSP仿真
主要是对成像的传感器以及数据转换过程进行仿真，比如：光圈、快门、ISO、像素的调节（拍照流程），Gamma校正、白平衡、景深、HDR调整、色彩空间等等（DSP的调节）。以上概念不熟悉的话读起来会十分枯燥乏味，仍然建议学习Digital Camera的原理。
总之，Camera仿真的核心在于虚拟场景的渲染，后面的镜头投影的仿真、信号处理的仿真、以及误差项仿真都不算太困难。
[*]输出项
相机的仿真输出应当包含RGB图、以及各种深度图、语义分割（Ground truth）、实例分割、光流等结果，从而可以对感知算法进行评价，或者作为感知模型的训练材料。
仿真Camera的输出（原图就黑白的，没找到彩色的，凑合看吧）
3.2.2 LiDAR仿真
激光雷达的模拟有几个重点，分别是：基于RayCasting的反射模拟，不同材质反射率的模拟，多种激光雷达原理的模拟。
[*]基于Ray Casting的反射原理
LiDAR仿真的思路是还原真实LiDAR扫描的方式，模拟以下过程：激光束发射—与场景中物体相交—根据相交物体的物理材质属性计算反射强度与噪声—接收反射信号—处理反射信号。
以禾赛Pandar128线LiDAR为例，其角分辨率为0.1°，频率为10Hz，这也意味着每秒钟会发射约461万条激光射线。对于探测范围内的每一个有效点，需要执行一次较为复杂的求交算法，对于算力的开销比较大。不过这算不上什么问题，实际过程中一般会利用GPU来负担LiDAR的仿真的算力开销。几乎所有的仿真平台都是支持基于RayCasting的激光雷达仿真的。
不过，仿真的LiDAR与真实的LiDAR存在一个很重要的不同，真实的LiDAR采集过程中，汽车处在不停的运动前进过程，因此单帧点云的时间戳是不一样的。但仿真的LiDAR工作时，会默认汽车停止在当前位置，直至LiDAR采集完当前帧，因此其单帧点云时间戳是一样的。
51sim 仿真软件中的激光雷达仿真结果示例
[*]反射率的模拟
激光雷达仿真的一个难点在于对其接收信号强度的模拟。现实中，影响LiDAR的信号强度主要有以下因素：
[*]目标物体的物理材质对激光波段（905nm or 1550nm）的反射率；
[*]目标物体与激光源的距离；
[*]激光反射的角度；
[*]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和距离分辨率、噪声参数等。对于某些兼有长距和中距探测功能的毫米波雷达，仿真时则需要同时支持两者的参数设置。
VTD 雷达仿真支持的参数设置
3.2.4 IMU、GNSS、V2X
无力调研，略
3.3 传感器仿真厂商
前面提到，传感器仿真的上限很高，但下限也比较低，囫囵做个模型出来是十分简单的事情。因此，基本上所有的仿真平台都会提供传感器模型。据说业界做的比较好的有VTD、RightHook(创业公司，已经并入VI-Grade)、Metamoto等，SImulink的自动驾驶工具箱的传感器模型也不错。
Ref：
[*]Background: Physics and Math of Shading by Naty Hoffman；
[*]基于物理的 BSDF：Microfacet Model（微表面模型） - 知乎 (zhihu.com)；
[*]CARLA模拟器中有激光雷达和毫米波雷达的模型吗？ - 知乎 (zhihu.com)；
[*]-Unity实时光线追踪技术介绍_哔哩哔哩_bilibili
[*]Background: Physics and Math of Shading by Naty Hoffman
[*]图形渲染基础：微表面材质模型 - 知乎 (zhihu.com)
[*]基于物理的 BSDF：Microfacet Model（微表面模型） - 知乎 (zhihu.com)
[*]游戏引擎PBR的前世今生--使用微表面模型进行渲染 - 知乎 (zhihu.com)
[*]Ray tracing (graphics) - Wikipedia
[*]基于Unreal游戏引擎的lidar传感器仿真及3D场景重建（混合点云）_JhonLocke的博客-CSDN博客
[*]走进自动驾驶传感器（一）——激光雷达 - 知乎 (zhihu.com)
4. 场景仿真1: 静态场景建模（2022.05.24）
4.1 静态场景的建模方法
前面讲过，主流的静态场景搭建基于游戏引擎，这使得自动驾驶仿真的场景更加真实，包括了更加真实的图形渲染，以及更加真实的物理规律两个方面。但Unreal、Unity本身并非具体的场景建模工具，而是可以理解为一个“装配”工具。因此详细的模型素材仍然需要借助其他软件完成，典型如的Autodesk公司的3DS Max、Maya等等。
用细粒度的3D建模软件来构建大型场景显然是低效的，因此也会有一些专业的粗粒度的建模软件用搭积木的方式来构建。举个例子，一般的场景大概包含了道路、地形、以及建筑物的构建，那么就可以用对应的软件/插件来解决。比如下面是围绕 Unity引擎的一些较为典型的建模软件。
构建要素软件/工具备注道路RoadArchitectRoadArchitect一些典型的Unity道路编辑软件VTPEasyRoads3D地形Unity Terrain ToolkitTerrain Toolkit - Tutorial - YouTubeWorld Composer一个从真实世界提取高度贴图数据和卫星图像的工具城市建筑ArcGIS CityEngine快速生成城市模型的软件UDST/vizicities虚拟城市，使用了开放地图数据，结合3d生成的建筑物进行缩放链接：RoadArchitect、VTP、EasyRoads3D、Unity Terrain Toolkit、World Composer、ArcGIS CityEngine、UDST/vizicities
但总归而言，这种场景中所有的模型都是需要人手动来参与搭建的，使用工具、插件也总得去输入不少参数，其效率始终不是很高。并且，尽管基于Unreal/Unity引擎构建的场景在这几年看起来越来越逼真，但仍然与真实的图像有所差别。
因此，业界的另一种方法则是根据实采的点云与图像数据，采用神经渲染的方法自动化的生成3D虚拟场景。这种方式最显著的两个优点是：大幅度提升了场景搭建的效率，大幅提升了场景渲染的真实性。并且，生成的具体模型还可以作为资源库，用于构建新的场景或者更改已有场景。（我在此领域的知识了解太少，需要进一步学习补充）
4.1.1 基于高精地图的场景生成
针对于“面向自动驾驶的3D场景构建”，业界常用的方式是基于高精地图来生成场景。高精地图的生成方法可以参考：BUAA火车侠：高精地图（一）：自动驾驶HDmap流水账科普
而基于高精地图的场景生成即是将高精地图的结构化的矢量图形再次进行3D渲染。其方法是将高精地图的每一种矢量图形建立一 一对应的标准模型素材库，然后根据矢量图形的语义调用素材库中不同的资源进行重新渲染，即可完成对道路场景的建立。
基于HDMap的静态场景的构建
显然，相较于人工去对道路进行建模，这种方式更加高效、低成本，且构建的道路也是对应实际场景的。之后，再对道路两边添加建筑，植被、地形等要素，即可构成面向自动驾驶仿真的静态三维场景。
目前，一些综合仿真平台/软件都自带了支持高精地图的道路/场景编辑器，可以证实的做的比较好的有VTD、SCANeR studio、Prescan等（也仅仅是相对地）；还有的场景编辑能力比较孱弱，比如Carla，需要借助第三方的场景编辑软件RoadRunner。当然RoadRunner作为一个单纯的场景编辑软件对这些仿真平台几乎一视同仁，其能够导出适配多种仿真平台的格式，这在后面会专门提到。
场景编辑工具备注RoadRunnerRoad Runner，可设计复杂路口（如转盘路、立交桥等），支持根据高精地图的重建，导出格式几乎可支持所有主流的仿真平台；仿真软件自带场景编辑器如VTD、Prescan、SCANeR、Panosim、LGSVL等都自带道路编辑器，支持导入高精地图。最后，基于高精地图生成静态场景也需要这些仿真软件支持统一的高精地图标准与场景标准，当前的主流标准一般是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表面元素，一个对象由一组密集的点或者带有光照信息的面元来表示。
其主要步骤是：
[*]扫描环境，重建一个由有纹理的表面元素（Surface element）构成的场景；
[*]然后用相机轨迹对表面元素进行渲染，同时进行语义分割和实例分割。接着通过GAN生成逼真的相机图像。
更加详细的信息可以阅读论文，论文链接见下方，本文就不做过多解读（主要我也不懂）。
还有近期的Block-Nerf的工作，论文和Demo见Ref。这种方式的静态场景构建显然是更加高效，省去了太多的地图编辑任务，并且模型面元来自真实图像，其渲染真实性更高。
参考资料：
官网 & 介绍：
[*]官网：Home – Waymo
[*]论文： SurfelGAN: Synthesizing Realistic Sensor Data for Autonomous Driving (arxiv.org)
[*] Block-NeRF: Scalable Large Scene Neural View Synthesis (arxiv.org)
[*]Demo：Block-NeRF - YouTube
教程 & 案例：
[*]黄浴：WayMo在CVPR 2020自动驾驶研讨会的报告 - 知乎 (zhihu.com)
[*]数据不够，Waymo用GAN来凑：生成逼真相机图像，在仿真环境中训练无人车模型 - 知乎 (zhihu.com)
4.2 软件：RoadRunner——自动驾驶仿真设计三维场景
对于场景建模软件，某种程度上，其开放权限与建模效率很难两者得兼。例如使用Prescan建立场景时候，只需根据需求拖动素材并更改参数即可，但其对特殊形状的路段的支持就比较差。VTD的场景编辑功能比较灵活，但建模的工作量就比较大。而在这方面Mathwork旗下的RoadRunner基本能够做到两者兼顾。
RoadRunner的功能特性与包含模块
前面提到，Mathworks收购RoadRunner，旨在提升其开发链条上的场景构建能力。其具备特点有：
[*]创建三维场景的功能十分丰富，可导入OpenDrive格式地图（常规操作）；可以导入LAS、LAZ、和PCD；
[*]借助Asset Library素材库，可以使用多种三维模型快速填充三维场景；
[*]借助Scene Builder，可将OpenDRIVE®地图自动转化为3D场景，十分高效；这也是RoadRunner最attractive的点；在Ref里面的介绍视频里有体现；
[*]可导出OpenDRIVE® 格式的道路网络，三维场景输出的格式极为全面：包含FBX®、glTF™、OpenFlight、OpenSceneGraph、OBJ 和 USD 等格式；导出场景可适配几乎所有的自动驾驶仿真器和游戏引擎。
[*]对GIS的支持较好，GIS数据可作为参考或提供地形数据；
RoadRunner的导出格式，可支持几乎所有的仿真平台
REF：
[*]自动驾驶系统之软件仿真测试 - 知乎 (zhihu.com)
[*]Unity自动驾驶仿真 - 知乎 (zhihu.com)
[*]Ray Tracing渲染：-Unity实时光线追踪技术介绍_哔哩哔哩_bilibili
RoadRunner场景搭建：
[*]手把手教你使用 RoadRunner 为自动驾驶模拟设计 3D 场景_哔哩哔哩_bilibili（推荐观看，这个视频对RoadRunner的介绍极为全面，看完后基本不需要再看其他的介绍了）
[*]MATLAB收购的RoadRunner是什么？自动驾驶场景软件市场又添波澜 - 知乎（推荐阅读）
[*]MathWorks中国工程师最全问答 | 自动驾驶场景编辑器——RoadRunner - 知乎 (zhihu.com)
[*]MATLAB新杀器 RoadRunner实战篇 | 基于MATLAB、RoadRunner、虚幻引擎和Speedgoat的驾驶员在环系统 - 知乎 (zhihu.com)
[*]How to make a new map with RoadRunner - CARLA Simulator
VTD的场景搭建：
[*]VTD（Virtual Test Drive）基础培训-QuickStart_哔哩哔哩_bilibili
[*]VTD场景搭建从听说到入门（零） - 知乎 (zhihu.com)
[*]VTD场景搭建从听说到入门（二）- 静态场景 - 知乎 (zhihu.com)
[*]VTD场景搭建从听说到入门（三）- 动态场景 - 知乎 (zhihu.com)
Prescan场景搭建：
[*]【Simcenter Prescan 快速入门系列】 第1期：Prescan架构及基础场景建模_哔哩哔哩_bilibili
[*]小编最近安装使用了PreScan2021,参考文档，总结了一下2021的变化 (360doc.com)
LGSVL 2021版本场景编辑：
[*]Using VSE - SVL Simulator
[*]LGSVL官方文档理解（三）：最新发布版的新特性 - 知乎 (zhihu.com)
SCANeR场景搭建：
[*]上海益罗的个人空间_哔哩哔哩_bilibili（SCANeR代理商）
5. 场景仿真2: 动态场景搭建（2022.05.26）
5.1 需求与难点
当前，自动驾驶最容易落地的场景有两种：一种是低速的清扫、物流机器人，缓慢的移动速度 + 保守的算法，总不至于捅出什么篓子；其二是封闭的工厂、园区、港口等场景，没有复杂、随机的动态环境、沿着既定的线路运行，使得环境的熵值被有效控制。
然而，消费级的自动驾驶车辆最终是要跑在复杂且随机交通环境之下的，车辆必须要处理很多与其他车辆、行人之间的交互任务。因此需要构建动态的场景以测试、迭代自动驾驶算法。事实上，业界经常提到的非常宝贵的自动驾驶Corner Cases大多都是一些较为极端、特殊的动态场景。
前面已经给出，动态场景主要是交通参与者的仿真（机动 车、非机动车、行人的行为、交通管控），其次是环境气候的仿真。那我们的需求有：
[*]动态场景中各交通参与者的行为要趋近真实、合理；
[*]环境仿真要基于物理模型；
[*]动态场景库的设计具有代表性，能够以少量场景覆盖所有现实中存在的交通状况（场景库的建设在后面会介绍）；
动态的交通场景
[*]动态场景建模难点
从直观感受上，对单个元素的动态行为建模需要描述“谁在哪里做了什么事情，持续了多长时间”，这要比静态环境建模难了许多，参数化的描述也十分晦涩难懂。这使得动态场景的标准化较为艰难，比如，后面提到的动态场景标准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：
[*]RoadRunner Scenario 是一个交互式的动态场景编辑器，其功能为：设计用于自动驾驶仿真测试的动态场景。
[*]其操作流程较为简单：放置车辆和路径，定义逻辑，并将场景参数化。然后即可在编辑器中模拟、回放该场景。车辆可以从内置车辆对象中选择，也可以用Simulink或者Carla定义。
[*]RoadRunner Scenario设计的场景可以连接到其他仿真器上进行联合仿真（目前未知有那些平台，不过Mathwork外部接口一贯做的比较好）。也可以将动态场景导出为OpenScenario 1.0格式，然后就可以用于任何支持OpenScenario的仿真平台或者场景编辑器，如后面会提到的esmini。
[*]RoadRunner API允许更改场景参数，为自动测试创建许多变体。可以使用该API自动化工作流，例如在不同场景中放置场景、模拟场景和导出。
RoadRunner Scenario界面
官网 & 介绍：
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的教学工具。项目本身也有较好的易集成性以及可移植性。其组成有（摘抄）：
[*]RoadManager（esminiRMLib）：提供以OpenDRIVE格式描述的道路网络接口库。
[*]ScenarioEngine（esminiLib）：提供viewer和与以OpenSCENARIO格式描述的交通场景交互的主库。该库包括RoadManager。
esmini还提供了一些可以原样使用或为定制解决方案提供灵感的应用模块：
[*]esmini ：一个静态链接到esmini模块的场景播放器程序。
[*]esmini-dyn ：一个使用esminiLib播放OpenSCENARIO文件的mini示例。
[*]odrplot ：能用于从OpenDRIVE产生数据文件，并使用Python绘制路网。
[*]odrviewer ：使用虚拟交通可视化OpenDRIVE道路网络。
[*]replayer ：重播以前执行过的场景。
[*]osiecever ：一个通过UDP从esmini接收OSI消息的简单应用程序。请注意：从版本1.5开始，esmini仅支持OpenSCENARIO v1.0。所有demo场景均已从0.9.1更新到1.0。ASAM提供了一种转换方案。可以与自动迁移XML文件的工具一起使用
ESmini运行截图
[*]最后是OpenScenario Editor：
OpenScenario Editor是基于Esmini的项目的一个开源的场景编辑器，比RoadRunner Scenario简陋了很多。
OpenScenario Editor
官网 & 介绍：
[*]Py_Scenariogeneration：GitHub - pyoscx/scenariogeneration: Python library to generate linked OpenDRIVE and OpenSCENARIO files
[*]Welcome to scenariogeneration (pyoscx.github.io)
[*]Esmini：https://github.com/esmini/esmini
[*]esmini team - YouTube
[*]OpenScenario Editor：GitHub - ebadi/OpenScenarioEditor: ASAM Open Scenario Editor
[*]Esmini介绍：esmini | A basic OPENSCENARIO player (qq.com)
教程 & 案例：
[*]在Carla里做一个Robotaxi （三） - 知乎 (zhihu.com)（用的Scenario generation）
5.2.3 其他软件：
细粒度的动态场景编辑总体而言不算什么困难的事情，当前51Sim-One、VTD、Cognata、AAI、Carmaker、dSPACE这些仿真软件，都是可以实现基于OpenScenario的场景编辑的。如下方即为51world的案例以及英国布里斯托大学的Demo。
案例：
[*]51World：51Sim-One场景标准OpenSCENARIO的应用实践_哔哩哔哩_bilibili
[*]Bristol大学：Online openScenario GUI editor - YouTube
5.3 粗粒度：交通流仿真
上述对个体行为的细粒度建模可针对于一些精细化的刁钻的场景建模。但对于大型的场景，如果要编辑每一辆车、每一个行人的行为，则完全是不现实的，多个对象之间的行为也非常容易产生干涉。这个时候就需要使用其他的方法：
1. 基于真实的交通流的数据：
即通过传感器采集真实世界的交通信息，经过基于AI的识别、跟踪算法处理之后置入仿真场景之中。其次，还可以在真实数据的基础上进行一定程度上的泛化，对真实场景的所有变量进行一定程度上的合理变形，例如在十字路口中，将机动车、非机动车、行人的到达时间、停留时间、移动速度等数值在合理的范围内变动。Waymo的仿真平台Carcraft即借鉴了该技术方案。
真实的交通流数据还可以用于训练AI模型，然后再由AI模型自动生成拟真的车辆、行人交通流，这也是近年来随着AI技术兴起的一个热点方向。
不过从实践上，将真实的交通数据转化为机动车的交通流并不是理想化的。从我方所作赤峰项目来看，视频流-车牌提取-路由文件的转化过程会带来一定的失真。同时，想要大规模获取真实交通数据的成本也是比较高的，路侧采集设备的覆盖总是不够理想。
2. 基于微观交通仿真系统：
然后就是交通工程领域的交通流仿真，这是当前主流的方案。该学科研究始于上世纪50年代，主要研究每个车辆的行为交互，宏观层面上关注区域内的车流平均速度、路口平均等待时间等统计指标。微观交通流仿真一直都是交通系统的规划、优化、以及评价的主流方式。不过在自动驾驶领域，其主要的价值是提供随机、复杂的动态环境。
交通流系统模型通常分为三类，具体取决于它们在哪个级别上运行：
[*]微型模型：分别代表每辆车，并尝试复现驾驶员行为。
[*]宏观模型：从交通密度（每公里车辆）和交通流量（车辆每分钟）的角度描述车辆的整体移动。它们通常类似于流体的流动。
[*]中观模型：是结合微观和宏观模型特点的混合模型，将流量建模为车辆的&#34;包&#34;。
一般而言，自动驾驶场景都是使用相对精细的微观交通流模型。现有的综合自动驾驶仿真平台一般也配备了交通流仿真功能，比如比如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中的路网与车流数据
当然，在自动驾驶仿真中，SUMO仅是提供交通流的，比如2020年开始，CARLA开始支持和SUMO联合仿真，后面也会提到基于此衍生出的仿真平台OpenCDA。
官网 & 介绍：
[*]Eclipse SUMO - Simulation of Urban MObility
[*]Documentation - SUMO Documentation (dlr.de)
教程：
[*]SUMO软件基本教学_哔哩哔哩_bilibili
5.3.2 PTV Vissim - 1979
Vissim是由德国PTV公司开发的交通流仿真软件。PTV公司位于卡尔斯鲁厄，2017年后由保时捷全资控股。Vissim可以在仿真场景中模拟包括机动车、卡车、轨道交通以及行人的交互行为，包括微观个体的跟驰行为和变道行为，以及群体的合作和冲突。其具体的功能应用和SUMO比较类似，具体的介绍可见下方的参考链接，十分详尽。
Vissim 的交通流仿真
Vissim的软件支持很好，可支持的联合仿真有：Carmaker、Prescan、VTD、Carla、Carsim、dSPACE ASM、Simulink、Unity、Unreal、rFpro等等。
对比SUMO与Vissim：作为一款开源软件，SUMO支持跨平台的开发，但其模型相对不够完善，比如缺少非机动车的专用模型，因此可信度存疑。而Vissim仅支持Win平台，作为商用软件，模型较完备，可信度也较高；支持一定程度的二次开发，但费用较高（大约10W RMB）。
市面上还有其他交通流仿真软件，如同济开发的微观交通流仿真TESS NG等，但那些市占率基本无法与上面两款相提并论，也就不多介绍。
官网 & 介绍：
[*]PTV Group - PTV Vissim - ptvgroup.com
[*]Vissim在自动驾驶仿真工具链中的作用_哔哩哔哩_bilibili（推荐观看）
[*]面对进入自动驾驶仿真的IT巨头，PTV VISSIM的优势何在？-电子工程世界 (eeworld.com.cn)
教程 & 案例：
[*]Vissim扫地僧的个人空间_哔哩哔哩_bilibili（Vissim中国官方账号）
Ref：
[*]交通工程跨界思考：何为无人驾驶仿真中的交通流仿真以及可用平台有哪些？ - 知乎 (zhihu.com)
[*]Co-simulation with SUMO and PTV-Vissim - 知乎 (zhihu.com)
交通流仿真
[*]《Fundamentals of Traffic Simulation》
[*]《Verkehrsdynamik und -simulation: Daten, Modelle und Anwendungen der Verkehrsflussdynamik》
[*]《Traffic Flow Dynamics》
5.4 环境气候的控制
天气系统是游戏引擎的强项，当前在游戏引擎中可以实现较为复杂、且拟真程度极高的天气模拟。天气系统的仿真有两种方式：一种是基于材质纹理（类似于给表面贴图），另一种则是基于物理模型的仿真（例如Unreal Engine最强的动态天气系统插件Ultra Dynamic Sky）。前者的渲染不够真实，但资源占用少，后者更加真实但资源占用极大。
两者的区别，举个例子：当模拟下雨天的时候，地上有一个小水坑，那么基于物理模型仿真中，小水坑的水就会越积越多，同时积水对于地面的摩擦系数也会产生影响。而基于贴图的模拟则仅仅是贴上了“表面有水”的效果动化，仿真世界的物理参数并未发生变化，其真实性无法与物理模型相比。
基本所有的自动驾驶仿真平台都有对天气的控制，或简单或复杂。例如，Carla可以通过Python脚本来更改天气参数，大概包含了：
[*]太阳位置(仰角，方位角)控制；
[*]阳光的色温、强度、大气散射；
[*]云、雨、风、雾等场景（当前还没有雪）；
其气候系统不是基于物理模型的，因此相对而言也比较粗糙。
Carla提供的天气控制API
Ref：
[*]自动驾驶模拟软件Carla上手-操纵天气，手动驾驶模式_哔哩哔哩_bilibili
[*]《技术启发艺术》虚幻4（UE4)资产：Ultra Dynamic Sky（UDS）光照系统以及（UDW）天气系统简述 2021 07 01_哔哩哔哩_bilibili
5.5 综合场景搭建厂商
综合静态和动态场景搭建的需求，一款理想的场景搭建工具需要具备的特性要有：
静态编辑方便灵活的静态场景编辑功能，支持OpenDrive格式导入导出，这点Roadrunner做的最好。
最好可以定义路面的微观特征，支持OpenCRG。（参考《标准》那一章）动态编辑方便灵活的细粒度动态场景编辑，支持OpenScenario格式的导入导出，这点RoadRunner Scenario做的不错，其他几家也不差。交通流可与专业的微观交通流仿真软件Vissim、SUMO联合仿真，生成拟真的交通流。环境气候支持基于物理模型的环境、天气控制。
5.4.1 rFpro - 2007 - 第一个关注路面的厂商
rFpro在场景搭建领域的方案比较有趣，尤其是注重“路面的特征”。但网上对该软件的描述大多数都是抄来抄去，并没有很好的阐述其特点。
rFpro 是一家英国公司， 成立于2008年，开始是一个为赛车项目进行赛道重建以及DIL-驾驶员在环的模拟软件，主要为车队提供服务，并可对赛车手进行训练。这就决定了，其场景必然十分真实精确，物理模型真实细致，仿真实时性较高。
[*]rFpro是选择基于真实世界，自己搭建场景，利用高精度的干涉激光雷达扫描路面，可以1mm内的精度构建出高精度路面数字模型。然后，使用普通ToF激光雷达扫描路侧街道，构建场景。rFpro使用该方法创建了许多赛道以及测试场景的高精度虚拟场景，包括F1，NASCAR, IndyCar，东京C1高速 - YouTube。即rFpro直接出售建好的场景，而并非场景编辑软件。
[*]这种建图的方式最大特点在于对路面微观特性的关注，可以较好的还原路面的粗糙度、凹凸、摩擦系数等细节，因此可为汽车的动力学仿真提供十分真实的虚拟场景，这与后面要提到的OpenCRG标准异曲同工。
[*]商业化团队构建出的虚拟环境，必然在完成度、精细度方面更有保障，在当前场景编辑工具不够完善、环境构建流程非常繁琐的当下不失为一种好的解决方法。但另一方面，目前没有证据表明其场景支持Open X标准，在标准化方面仍然不足。
[*]动态场景方面，rFpro 可以接入 SUMO 或者 Vissim，用它们生成连续的交通流来填充整个场景；并且，其天气场景都是基于物理模型的，精确度也非常高。
[*]rFpro可以与Carmaker 联合仿真，为Carmaker提供更真实的传感器和测试场景。
[*]rFpro也支持导入第三方地图模型，包括如IPG ROAD5（Carmaker的格式），.max，.fbx，OpenFlight，Open Scene Graph，.obj等，但可以想到外部模型的精度应该是无法与rFpro自建地图相比。
rFpro建立的东京C1高速道路
总之，rFpro最大的特点就是第一个将“精细化的道路微观特性”作为重点的公司，尽管这原本是赛车领域的需求，在自动驾驶领域属于无心插柳。理论上，rFpro拥有的道路模型很好的满足了：静态场景 + 高精度路面 + 动态交通流 + 基于物理模型的天气场景。将这四者结合起来并不容易，直到2022年的今天，能完成的厂家也不多。
官网 & 介绍：
[*]Driving Simulation for autonomous driving, ADAS, vehicle dynamics and motorsport (rfpro.com)
[*]rFpro - Wikipedia
教程 & 案例：
[*]rFpro Tokyo Digital Twin - YouTube（rFpro重建东京C1高速）
5.4.3 Parallel Domain - 2017
Parallel Domain 是一家位于加州的初创公司。其主要业务方向是“利用AI自动生成高质量的虚拟环境，用于自动驾驶的仿真测试”。
结论：目前没什么实质进展，官网的几个Demo，看起来Carla基本都能做到，场景建立给的自由度也不高，知道有这么个公司就行。
Parallel Domain宣传
官网 & 介绍
[*]Parallel Domain | The New Data Pipeline for Computer Vision
[*]仿真初创公司 - Parrallel Domain（2017创立） - 知乎 (zhihu.com)
[*]提供的一个公开数据集：Bicycle Detection - Parallel Domain、
[*]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自定义动态厂商，其他看来没什么新鲜的，知道名字就行了。
Cognata自定义场景
官网 & 介绍：
[*]Cognata 科纳特 - 自动驾驶和ADAS仿真测试软件 机器人仿真软件
[*]Cognata Ltd. - YouTube（YT官方账号）
[*]SUMO联合仿真Demo：Cognata Traffic model - Sumo 3rd party Integration - YouTube
官网提供了一些公开的数据集（虚拟数据），可邮件申请。
本章Ref：
[*]白皮书系列；
[*]交通工程跨界思考：何为无人驾驶仿真中的交通流仿真以及可用平台有哪些？ - 知乎 (zhihu.com)（交通流领域概况，推荐阅读）
[*]UE4-Vehicle车辆载具探索-运动 - 知乎 (zhihu.com)
[*]微观交通流仿真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 仿真接口
“仿真”作为自动驾驶开发链路中的一环，其需要和其他环节紧密结合在一起。但很多软件在上下游链路打通时则非常麻烦。比如：
[*]一些仿真软件只能支持WIN，而现在自动驾驶开发的环境都是在Ubuntu环境下；
[*]一些传统仿真软件的云端并行仿真兼容性不好，有些是最近版本才开始兼容云端仿真。
[*]目前仿真企业的商业模式是几台电脑装软件就收几套License费用，显然这种模式对用户十分不友好。随着云端并行仿真的兴起，按照服务收费的SaaS+PAAS模式对客户显然更加友好。
对于一些科技巨头，除了研发仿真软件外，还更加注重仿真平台与其他工具链的集成与打通，形成一套全栈式的解决方案。比如华为的Octopus的仿真模块是与VTD合作开发，嵌入了Carmaker的动力学。在此基础上提供了云端一站式的仿真评测工具链，从代码仓库接入、版本管理，到仿真、评测，可以实现开发链条的闭环。这样，车企使用起来，上手更容易，适配成本也更低。
通信协议：
这是个完全开源的自动驾驶仿真软件，后端是UE4，客户端用Python和C++都可以写，官方的Python文档写得很好很好，而且数据接口是RPC式的，比起一些基于自定义协议的（比如VTD的RDB，腾讯TADSim的基于Protobuf自定义协议等）要方便很多，不用自己写解析协议的代码，一些关于同步、频率的问题可以暂时往后放放，先实现功能，看到反馈。
链接：https://www.zhihu.com/question/469263088/answer/2223537795
Ref：
[*]两万字详解自动驾驶开发工具链的现状与趋势-面包板社区 (eet-china.com)（推荐阅读）
[*]云仿真场景库 - CSDN
6.1.2 案例与Matlab 的联合仿真（基于ROS2 Bridge）
[*]Matlab与Carla或Lgsvl联合仿真之matlab配置 - 知乎 (zhihu.com)
6.2 云仿真与并行加速
不懂，待学习
云端并行仿真无疑能大大提升自动驾驶开发效率，科技背景的企业如华为、腾讯的仿真平台可以无缝衔接其云平台。当然其他仿真公司的产品也开始逐渐支持并行仿真，以及支持部署在私有云和公有云上，例如VTD的方案。
VTD的仿真方案
Ref：
万字长文 | 谈谈自动驾驶仿真 - 知乎 (zhihu.com)
7. 自动驾驶仿真平台/软件（2022.06.01）
该章节读者没必要浪费精力浏览，直接看自己感兴趣的平台即可。互联网上类似文章基本基本上是抄来抄去，且废话连篇。想要真正将一款软件平台的特性阐述完整需要很大的篇幅，并且结合众多图例和视频Demo，受限于篇幅和精力，本文不会这么做。
我会沿着本文的逻辑，重点介绍一下其动力学、静态场景、动态场景、仿真运行的一些方案以及软件的核心特色。详细介绍的文档、视频演示放在对应的ref栏里，想要详细了解的可以查阅。
另外，由于专业领域算比较小众，商业化软件大部分都是没有破解版本的。除了Carsim、Prescan、Matlab、Vissim这些用户基数大一些的软件会有盗版存在。
[*]细分领域仿真软件 2022.06
类型软件引擎系统国家价格说明动力学仿真Carsim*Unreal PluginWin美国基础20000USD
破解版易得最常用的动力学仿真软件，主流仿真平台一般会预留其接口dSPACE ASM*/Win德国很贵，打包销售作为dSPACE公司快速原型开发工具链的一环，具有封闭性。公开资料少，大型车企用的多。ADAMS*/Win美国多体动力学仿真，RT版本简化AVL-Cruise/德国纯数据流，无图形化界面VeDYNA/德国以Matlab为基础开发静态场景编辑RoadRunner*/美国30W两个licMathworks收购，专业的场景搭建软件动态场景编辑RoadRunner Scenario*/美国未知Mathwork旗下OpenScenario编辑器OpenScenario Editor/开源开源OpenScenario编辑器交通流仿真SUMO*/All德国开源开源微观交通流仿真软件PTV Vissim*/Win德国10W+目前最好的微观交通流仿真软件TESS NG中国同济团队开发综合场景搭建rFpro英国未知第一家关注路面微观特征的公司，创建场景可导入CarmakerParallel Domain美国未知创业公司CognataUnity以色列未知创业公司传感器仿真RightHook/美国未知创业公司，被VI-Grade合并
综合自动驾驶仿真软件/平台 - 2022.06
传统厂商VTD*/Linux德国30-50W有道路、场景编辑器，Open X标准制定者、维护者CarmakerUnigine德国Prescan*Unreal德国百万级，贵全链条仿真，在国内的商业化较好SCANeR*Unreal法国100W+雷诺、达索投资，ANSYS合PanoSim*UnityWin中国较便宜动力学仿真起家，现已发展为商用的一体化仿真平台VI-GradeUnreal德国动力学+驾驶模拟器起家，合并创业公司RightHookSimulinkUnrealAll美国正版贵
破解版易得万能的数学建模工具，传统ADAS开发的中心开源平台Carla*UnrealWin/Linux西班牙
美国开源server-client结构LGSVL*UnityWin/Linux美国开源
2022停止更新一个基于Unity的自动驾驶仿真器，提供对Apollo5.0、Apollo3.5、Autoware的支持，AirSim*UnrealAll美国开源
停止更新github上标星数目最多的开源仿真软件，对windows的支持力度更大一些。国外科技&创业公司NvidiaOmniverse美国Carcraft美国Waymo内部使用AAI德国MetamotoUnity以色列国内科技&创业公司腾讯TAD Sim*Unreal中国仅对核心客户开放百度AADS中国华为Octopus中国仿真软件与VTD合作，嵌入Carmaker动力学模型，更重视云端仿真；阿里中国暂未有什么大新闻51Sim-one中国价格便宜以数字孪生起家，因而环境构建方面较强GaiA中国初创公司做的仿真软件，在传感器建模方面表现良好*热门的比较有特色的仿真软件用*标出，相对冷门软件用后续不做介绍，感兴趣读者可自行调研。
7.1 传统仿真厂商
这些传统的仿真厂商开发的仿真软件，一些是由动力学软件进化而来，比如Carmaker、PanoSim，另一些则是做ADAS仿真起家，比如Prescan、VTD。其特点有：
[*]一般支持与Carsim 的联合仿真、也能较好的支持Simulink仿真；
[*]支持从MIL到HIL的在环仿真；
[*]仍然是较为可靠的OEM、Tier1的生产力工具，基本靠卖给企业、研究团队License赚钱；
一个趋势是，此类传统仿真供应商，在最近的版本中，也基本都开始使用游戏引擎来对增强场景的渲染，具体可见本章开头的那张表，在后面的叙述中就不再重复提及。可见游戏引擎作为3D技术的集大成者，基本在自动驾驶仿真业界达成共识。例如下图中Prescan最新版本即采用Unreal引擎取得了还不错的场景仿真效果。
最新版Prescan基于Unreal Engine渲染场景
7.1.1 Vires - VTD（Vitual Test Drive）
在自动驾驶仿真软件中，VTD是一套绕不开的软件。这是因为其开发者德国VIRES公司（2017被MSC收购）是ASAM-OpenDrive，OpenCRG以及OpenScenario标准的主要贡献者和维护者，VTD的功能和存储也依托于这些开放格式。VIRES公司很大程度上推动了静态、动态场景的标准化进程，其中也包括高精地图的标准化。
其功能模块基本也就是上面提到的那些：
[*]路网搭建：VTD提供了图形化路网编辑器Road Network Editor (ROD)，可以构建较为复杂的静态道路环境的同时，还可以导入、导出OpenDrive高精地图。不过，VTD应该不支持自定义的场景元素库。
[*]动态场景配置：VTD提供了图形化的交互式场景编辑器Scenario Editor， 在地图上可添加自定义行为控制的交通体，或者是连续运行的交通流，还可以接入SUMO、VISSIM的交通流（常规操作）。
[*]场景渲染：VTD并未基础游戏引擎做渲染，从Demo可以看出，其场景渲染效果比较糟糕。
[*]动力学仿真：VTD可以接入Carsim、Carmaker、以及MSC自家的ADAMS RT。
[*]仿真运行：支持SIL、HIL，支持与Apollo的联动、算此类仿真企业的传统艺能。
较多德系汽车厂商和Tier1，比如Bosch都采购了该软件。后面其他软件的特性基本和VTD大差不差，因此简要叙述。
官网：
[*]Virtual Test Drive (VTD) – Complete Tool-Chain for Driving Simulation (mscsoftware.com)
教程&介绍：
[*]Virtual Test Drive——驾驶仿真应用的完整工具链_哔哩哔哩_bilibili（能看出场景渲染很差）
[*]VTD（Virtual Test Drive）基础培训-QuickStart_哔哩哔哩_bilibili
[*]VTD-敢卖100w+人民币的自动驾驶仿真器 - 知乎 (zhihu.com)
[*]VTD和CarMaker/Carsim车辆动力学的联合仿真方案 - 知乎 (zhihu.com)
7.1.2 IPG - Carmaker
[*]Carmaker是以动力学仿真起家的仿真平台，自家的动力学比较优秀；
[*]IPG Road静态场景：可以配置GUI模拟多种道路场景（支持HERE地图导入，OpenDrive导出），可以对道路的几何形状以及不平度、粗糙度进行定义（支持OpenCRG）；
[*]IPG Traffic动态场景：没什么新鲜的，支持OSC 1.0；
[*]IPG Driver：自适应的驾驶员模型；
[*]可以导入rFpro的场景，前面也提过；
[*]支持Docker，支持云计算；
[*]支持AUTOSAR、FMI标准接口；
官网 & 介绍：
[*]CarMaker | IPG Automotive (ipg-automotive.com)
[*]CarMaker 10.0 Release By IPG Automotive | UNIGINE: real-time 3D engine
7.1.3 Siemens - Prescan - 2013
[*]Tass International 研发，2017 年 8 月被西门子收购，在中国市场化做的不错；
[*]地图编辑器：还不错，包含动态+静态，该有的元素都有。也支持导入OpenDrive，不过应该不能像RoadRunner一样根据OpenDrive自动生成道路，也不支持导出。
[*]传感器仿真：还挺全，有V2X和超声。
[*]动力学模型：没有动力学模型，因此支持与第三方动力学软件联合仿真，如CarSim、dSPACE ASM、 VI-Grade、AmeSIM等；
[*]对于传统的“基于MBD，围绕Simulink的设计流程、MIL到HIL的仿真测试”的支持都不错。
[*]支持基于云端布置大规模仿真；
[*]老版本的盗版非常多，人们用的比较多；
Prescan仿真步骤
Prescan的地图编辑器
官网：
Simcenter Prescan 2020.4 -Create more realistic images | Simcenter (siemens.com)
视频教程：
【Simcenter Prescan 快速入门系列】 第1期：Prescan架构及基础场景建模_哔哩哔哩_bilibili
7.1.4 PanoSim - 2014
[*]国产软件，创始人邓伟文原为吉林大学千人教授，现为北航交通学院院长；
[*]动力学：PanoSim也是从动力学模型起家；
[*]静态场景：有地图编辑器，支持导入OpenDrive生成数据，自动生成场景；
[*]场景渲染：也是基于游戏引擎，但相对粗糙；
[*]对MBD、Simulink、X in Loop那一套支持比较好，这几年建设自动驾驶仿真平台，该有的模块也都有；
官网 & 介绍：
[*]PanoSim—面向汽车自动驾驶技术与产品研发的一体化仿真与测试平台
[*]PanoSim的个人空间_哔哩哔哩_bilibili（B站官方账号）
教程&案例：
基于PanoSim5.0虚拟仿真平台的自主代客泊车AVP系统开发教程_counteryida的博客-CSDN博客_panosim下载
7.1.5 VI-Grade + RightHook - 2005
[*]VI-Grade动力学：创业初期核心团队是ADAMS出身，因此是车辆动力学起家；
[*]做下图所示的汽车驾驶模拟器，驾驶员在环仿真比较强，经常举办、赞助大学生虚拟方程式大赛；
[*]VI-WorldSim交通流仿真：2020年推出，需要搭配RoadRunner创建静态环境使用；
[*]RightHook传感器：2021年与硅谷创业公司RightHook合并，传感器仿真能力大幅增强；
[*]仿真还是Simulink那一套支持的比较好；
VI-Grade驾驶模拟器
VI Simworld场景
官网 & 介绍：
[*]Driving Simulator | VI-grade
[*]VI-grade中国的个人空间_哔哩哔哩_bilibili (B站官方号)
[*]VI-WorldSim交通流仿真软件线上系列教程_哔哩哔哩_bilibili（VI-WorldSim）
[*]虚幻引擎：为无人驾驶汽车开发和训练提供优质的用户体验 - 知乎 (zhihu.com)
7.1.6 SCANeR - 2017
[*]SCANer是OKTAL与雷诺、达索成立的合资公司AVSimulation研发，并且与ANSYS合作，作为ANSYS的自动驾驶仿真平台核心；尽管成立年限不长，但其技术、商业模式、合作方仍然比较老套，因此将其算作传统仿真厂商；这家公司也做上面VI-Grade做的那种模拟驾驶舱；
[*]TERRAIN：SCANeR自带了一个静态场景编辑器，界面类似于RoadRunner，可以比较灵活的编辑道路、编辑地形，并添加树木、建筑，形成完整的静态场景。生成场景文件为OpenSceneGraph格式，可用Unreal Engine渲染；
[*]支持OpenCRG对道路表面的定义；
SCANeR地图编辑器
[*]SCENARIO：定义动态场景；
[*]VEHICLE：包含车辆动力学定义以及基于物理模型的传感器等；
[*]SIMULATION：
[*]支持MIL到HIL的仿真；
[*]支持和Simulink联合仿真，传统艺能；
[*]提供API控制；
[*]ANALYSIS：仿真分析；
官网 & 介绍：
SCANeR studio - AVSimulation
教程 & 案例：
[*]上海益罗的个人空间_哔哩哔哩_bilibili（B站官方账号）
[*]SCANeR Studio教程目录索引 - 哔哩哔哩 (bilibili.com)
[*]自动驾驶仿真软件：SCANeR使用介绍 - 知乎 (zhihu.com)（详细、推荐阅读）
[*]学习笔记|自动驾驶仿真工具-SCANeR studio_智驾仿真李慢慢的博客-CSDN博客_scaner
[*]虚幻引擎官宣：将为多用途汽车模拟环境注入新力量 _ 游民星空 GamerSky.com
7.1.7 Matlab Simulink + RoadRunner + RoadRunner Scenario
[*]Simulink在传统的整车软件开发中发挥了重要作用，甚至是主要的生产工具；当前Mathworks的自动驾驶开发仿真工具链也一直在不断进化；
[*]动力学：Automated Driving Toolbox - Vehicle Dynamics Block Set；
[*]静态场景：RoadRunner，前面介绍过，目前业界最好的静态场景编辑器；
[*]动态场景：RoadRunner Scenario，前面也介绍过，目前最好的动态场景编辑器；
[*]场景渲染+传感器：基于Simulink Unreal Plugin，还可以；
[*]仿真：Simulink；
官网 & 介绍：
MathWorks - MATLAB 和 Simulink的制造者 - MATLAB & Simulink
7.2 开源平台
前面的商用仿真软件的优点在于其完成度和严谨性都比较有保障，作为OEM稳定的生产力使用。但是对于研究者而言，往往需要对软件进行深层改动，以满足特定需求以及研究目标，对实际生产中的很多问题并不看重。
因此，这个时候Carla、LGSVL、AirSim等开源模拟器是更好的选择，这些模拟器通常作为研究平台创建，以支持强化学习或机器学习的合成数据生成，通常需要不小的额外的努力来集成用户的自动驾驶系统和通讯模块。
7.2.1 Carla
[*]开发者：巴塞罗那自治大学 + Intel + Toyota北美，Server/Client架构；
[*]交互控制：目前通过Python API操作，无GUI；
[*]动力学：Carsim接口；
[*]静态场景：
[*]自建：RoadRunner导出OpenDrive与Fbx；
[*]开源：提供几个开源的测试训练场景；
[*]动态场景：可导入RoadRunner Scenario场景编辑、与SUMO、VISSIM联合仿真；
[*]场景渲染：算做的比较好的，但不是PBR；暂时没有RayTracing；
[*]传感器仿真：Lidar用CPU跑的，暂时还没有用GPU跑Lidar仿真；
[*]仿真测试：支持ROS、ROS-Bridge，包含自动驾驶系统的3种方法:
[*]经典的感知、定位、决策、控制模块化方法；
[*]End to End强化学习方法；
[*]End to End模仿学习方法；
[*]拓展：OpenCDA = Carla + SUMO；
官网 & 介绍：
[*]GitHub - carla-simulator/carla: Open-source simulator for autonomous driving research.
[*]CARLA Simulator - YouTube（YT官方账号）
[*]An in depth look at CARLA&#39;s sensors - YouTube
联合仿真案例：
[*]Carla学习——1.Carla和sumo联合仿真 - 知乎 (zhihu.com)
[*]Matlab与Carla或Lgsvl联合仿真之matlab配置 - 知乎 (zhihu.com)
OpenCDA：
[*]ucla-mobility/OpenCDA: A generalized framework for prototyping full-stack cooperative driving automation applications under CARLA+SUMO. (github.com)
[*]叶小飞 - 知乎 (zhihu.com)（Open CDA作者，其有Carla的文章）
[*]OpenCDA：一个开源的多车协同自动驾驶仿真平台 - 知乎 (zhihu.com)
7.2.2 LVSVL——LG Silicon Valley Lab
[*]2022年1月宣布停更，SVL Simulator Sunset Plan；
[*]交互控制：Python API；
[*]传感器：都有，包含Velodyne 128, 64, 32线激光雷达，Conti毫米波雷达；
[*]静态场景：貌似不能编辑，可以RoadRunner导入；
[*]动态场景：API；
[*]高精地图：提供高精地图插件；
[*]导入：Apollo5.0、Autoware Vector map、Lanelet2、OpenDrive 1.4；
[*]导出：Apollo 5.0、Lanelet2、OpenDrive 1.4；
[*]仿真：支持ROS、ROS2（Autoware）和Cyber RT（Apollo）；
[*]支持SIL和HIL；
LGSVL架构
官网 & 介绍：
[*]GitHub - lgsvl/simulator: A ROS/ROS2 Multi-robot Simulator for Autonomous Vehicles
[*]Home - SVL Simulator（官方文档）
[*][中文] LGSVL Simulator: A High-fidelity Autonomous Driving Simulator - YouTube（详细的特性介绍，推荐）
[*]LGSVL_Simulator的个人空间_哔哩哔哩_bilibili
[*]驾驶模拟器之LGSVL篇：一个高保真的自动驾驶模拟器 - 知乎 (zhihu.com)
[*]Lgsvl自动驾驶仿真器介绍（一） - 知乎 (zhihu.com)
教程&案例：
自动驾驶 - 知乎 (zhihu.com)
7.2.3 AirSim
[*]无人机及自动驾驶模拟开源项目，已永久停更；
[*]交互控制：C++、Python、C#、Java API；
[*]动力学：自带动力学模型，糙；
[*]传感器：无Radar，有供红外相机与事件相机；
[*]静态场景：提供开源城市街景，还算丰富；
[*]动态场景：未知；
[*]延续了微软一贯风格，封装过于严密，自定义地图，NPC，天气都不可行；
[*]仿真测试：支持ROS、ROS-Bridge，主要用于测试深度学习、 计算机视觉和自主车辆的端到端的强化学习算法；
官网 & 介绍：
GitHub - microsoft/AirSim: Open source simulator for autonomous vehicles built on Unreal Engine / Unity, from Microsoft AI & Research
开源平台的对比，后面还是Carla更有希望
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连接的设计软件
Omniverse如同3D设计界的协作文档那样，极大加速了设计的工作流程。而且将Ray Tracing、AI技术、计算等集成到3D设计的pipeline中。因此Omniverse也被称为是“元宇宙”的基建工程。
Omniverse：
[*]Omniverse Platform for 3D Design Collaboration and Simulation | NVIDIA
[*]连接未来，NVIDIA Omniverse为何成为新一代创作神器？ (baidu.com)
[*]Omniverse的View功能怎么用？ - 知乎 (zhihu.com)
[*]Drive Sim——Powered by Omniverse
Nvidia的Drive Sim是一款基于Omniverse平台开发的、端到端的自动驾驶平台。其主要的作用是进行自动驾驶的传感器仿真以及场景仿真。传感器仿真是基于物理模型，实时Ray tracing技术也是英伟达的绝活。
而在静态场景搭建方面，英伟达亦采用和Waymo类似方案，用到深度神经网络对实际采集数据进行合成，快速、自动化地生成静态场景（不过，这里具体地技术方案没有查到）。下图的案例中，Nvidia和奔驰合作，在斯图加特采集数据构建了道路的数字孪生。
利用Omniverse，用户是可以构建扩展的传感器模型、动态交通流模型、3D资源等等。
案例：斯图加特Digital Twin，与戴姆勒合作
Nvidia Drive Sim：
[*]NVIDIA DRIVE Sim | NVIDIA Developer
[*]NVIDIA DRIVE Sim Powered By Omiverse | NVIDIA Blog（推荐阅读）
[*]NVIDIA DRIVE Sim, Powered By Omniverse - YouTube（推荐观看）
[*]用于DRIVE Sim 的 Omniverse Replicator 加速自动驾驶汽车开发|传感器|drive|sim|神经网络_网易订阅 (163.com)
[*]Drive Constellation = Drive Sim +AI ECU
最终来到了Nvidia的自动驾驶仿真平台Drive Constellation，其在Drive Sim的基础上又增加了一套车辆的ECU服务器。平台由两台服务器构成：
服务器1硬件8 x Nvidia RTX Turing GPU；服务器1作用运行Nvidia DRIVE Sim软件，依托于强大的图形计算能力，模拟仿真自动驾驶车辆上的传感器数据（包括摄像头、毫米波雷达、激光雷达、IMU和GNSS）以及驾驶场景数据；服务器2硬件自动驾驶车辆目标AI ECU（DRIVE AGX
Pegasus车载电脑）；服务器2作用运行自动驾驶全栈的算法，处理第一台服务器传输过来的模拟数据；服务器2再将驾驶决策信号输出给服务器1，形成了仿真闭环。
英伟达- DriveConstellation 仿真平台架构
那么由上述架构可知，其属于与自家的ECU硬件耦合的实时HIL方案，真实性很高；并支持大规模部署。
[*]动力学模型：主要由dSPACE ASM合作提供，也有Carmaker的模型；
[*]静态场景：基于Nvidia Omniverse；
[*]如在上面给到的Demo里面，Nvidia团队在斯图加特进行了实际路采，而后利用神经渲染将其转换为静态场景；
[*]也可以由Mathworks RoadRunner建立静态场景导入，可使用Hum3D的资源库；
[*]传感器：该有的也都有，尤其是支持Luminar的转镜式激光雷达模型；
[*]高精地图：Nvidia目前已收购高精地图厂商DeepMap，未来必然会进行整合；
[*]验证系统：可接入Foretellix；
Nvidia Drive Constellation合作伙伴
官网 & 介绍：
NVIDIA DRIVE Sim | NVIDIA Developer
教程 & 案例：
[*]NVIDIA DRIVE Sim - YouTube（推荐观看）
[*]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在这方面的确非常头铁。
官网 & 介绍：
[*]Waymo Driver – Waymo
[*]Waymo - YouTube（YT官方账号）
[*]Waymo details &#39;Carcraft&#39; simulation software, &#39;Castle&#39; testing site for self-driving car training - 9to5Google
7.3.4 AAI - 2017
[*]AAI（Automotive Artificial Intelligence），2017年成立于柏林的初创公司；
[*]静态场景：有道路编辑器和场景编辑器，类似RoadRunner，场景文件格式为fbx；这家公司也做一些数字孪生的场景，比如柏林市的一些道路；
[*]交通流仿真：基于真实的交通流数据，应用了监督学习以及强化学习技术生成，可以调节车流的密度、车辆混合、以及攻击性水平等（相对比较创新的方法）。可以可以自动抓取生成OpenScenario文件；
[*]仿真支持： 使用实际驾驶数据，训练AI模型生成驾驶员模型。
[*]i-Label：有个简陋的图像标注工具
[*]主要合作方：Conti、Audi、四维图新；
AAI功能
官网 & 介绍：
[*]Automotive Artificial Intelligence (AAI) GmbH (automotive-ai.com)
[*]Automotive Artificial Intelligence - YouTube（官方YT账号，里面不少展示的Demo）
7.3.5 Metamoto - 2016
[*]美国的创业公司，被以色列的Foretelix收购，Foretelix是OpenScenario2.0的重要起草单位，其推出了场景描述语言M-SDL（Measurable Scenario Description Language）；
[*]评价：看起来完成度仍然不高，没什么新鲜的；据说传感器仿真做的还不错；
官网 & 介绍：
[*]Foretellix - Automated driving systems testing tools for simulations
[*]Metamoto, Inc. - YouTube（YT官方账号）
7.4 国内互联网公司平台
国内互联网公司的仿真平台的特点：
[*]巨头们手上的资源极为丰富，因此架构极为宏大，平台几乎涵盖自动驾驶开发的每个角落，“仿真”仅仅是其中的一部分；
[*]新闻和宣传很多，但废话连篇，官网也几乎没有详细的介绍与Demo演示，平时基本也只对合作客户开放，公开的细节信息很少；因此下面的介绍也只能是特别宽泛；
[*]基本在各类白皮书、商业报告都会刷存在感，凑个个数。但除此之外捂的非常严实；
[*]这些厂商云技术是强项，这方面的支持会好很多；
7.4.1 腾讯TADSim
[*]腾讯云与智慧产业事业群 - 自动驾驶事业部开发，算是信息披露多，且能商用的；
[*]动力学：有集成的车辆动力学模型，也可以用Carsim的；
[*]高精地图：内置了腾讯高精地图，支持全国高速和快速路仿真（腾讯已完成测绘）；
[*]传感器自研，交通流自研，虚实一体交通流，可实现场景的几何还原、逻辑还原及物理还原；
[*]场景编辑自研，支持OpenX标准，有一部分数字孪生资产；
[*]该腾讯团队在OpenScenario、OSI标准制定时候深度参与；
[*]分布式架构，支持在Windows、Linux和Web环境下部署；支持海量场景的并行计算；
[*]仿真：
[*]支持MIL/SIL/HIL/VIL需求，覆盖V-Shape开发流程，可做生产力工具；
[*]支持ROS、Simulink、LCM等多种接口；
腾讯云平台系统架构（来源-自动驾驶云论坛演讲报告）
官网 & 介绍
[*]TAD Sim和腾讯在OpenX系列标准 制订过程中的相关工作（C-ASAM的一个介绍，比较细致，推荐）
[*]腾讯TAD Sim仿真平台，助力破解自动驾驶落地困境 - 云+社区 - 腾讯云 (tencent.com)
7.4.1 百度AADS
[*]这就是百度在19年发在《Science：robotics》上的一篇论文的工作。三年过去系统进展如何、是否商用化存疑。
[*]AADS (Augmented autonomous driving simulation using data-driven algorithms) 是百度研发的增强现实的自动驾驶仿真系统。
[*]静态场景：基于图像渲染的场景图片合成框架； 使用 LiDAR 和相机扫描街景实现自动化3D建模。
[*]交通流仿真：基于真实数据；
AADS架构
官网 & 介绍：
告别「五毛」仿真环境：百度增强现实自动驾驶仿真系统登上 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
[*]自动驾驶部门与诺亚方舟实验室合作完成；
[*]架构很复杂，细节都没有，内容全靠猜；以华为的体量，应该做了很多工作，但相关信息少的可怜；
[*]只知道核心仿真模块是基于VTD做的；也用了Carmaker的动力学模型；
华为Octopus架构
官网 & 介绍：
[*]HUAWEI Octopus 自动驾驶云服务-华为云 (huaweicloud.com)
[*]揭秘“华为八爪鱼”，自动驾驶云服务加速智能汽车时代到来_自动驾驶云服务_华为云论坛 (huaweicloud.com)
[*]详解华为“八爪鱼”的六大关键特性 - 知乎 (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）
[*]51SimOne是51World在智能汽车领域推出的仿真产品，本身51World是做数字孪生、智慧城市这类业务起家，因此在场景构建上的能力十分出众；
[*]动力学：SimOne-Bus、SimOne-Car、SimOne-Truck都是自研的；
[*]静态场景：有道路编辑器WorldEditor，功能方面和RoadRunner比较像
[*]支持OpenDrive文件的导入、导出、编辑，
[*]支持导入GIS数据还原路网；
[*]支持导入点云数据还原路网；
[*]平台内置了一系列场景库和测试案例库，
[*]动态场景搭建：支持配置全局交通流，编辑独立的交通智能体（车辆、行人），支持OpenScenario；光照、天气这些属于基本操作；
[*]传感器：基于物理模型、自研，强项；
[*]Camera：包含单目、广角、鱼眼，输出语义分割图、 深度图、 2D/3D包围盒（常规操作）
[*]LiDAR：点云原始数据，标注点云数据，Bounding Box（常规操作）；
[*]Radar：目标级毫米波Radar检测物数据；
[*]仿真：
[*]C++、Py、OSI、ROS接口；
[*]支持MIL到HIL的V-Shape开发；
[*]支持多车协同互动；
[*]PAAS商业模式，可以本地部署，也可以私有云、公有云部署；
[*]51SimOne有一套开源的版本，链接见Ref；
[*]51SimOne也做驾驶模拟器；
[*]案例：毫末物流车
51World的驾驶模拟器
51SimOne场景库
官网 & 介绍：
[*]官网：智慧交通_汽车_高速_城轨_机场_解决方案提供商｜51WORLD (51aes.com)
[*]开源版本：51Sim-One Cloud (51aes.com)（推荐点进去试试）
[*]驾驶模拟器：国内首个多车互动仿真系统，加速自动驾驶商业化落地_哔哩哔哩_bilibili
7.6 理想的仿真平台与工具链
纵观这些自动驾驶仿真的平台、工具，可以看出自动驾驶仿真实在是一个庞大的议题，其中的一些子模块都可以单独作为一门学科，一个能够实现流程纵向打通的、完整的仿真平台体量必然不会太小。而现存的仿真平台或多或少都嗨存在一些缺点和不足。
那么，比较理想的自动驾驶仿真平台应当具备以下特性：
领域应当具备的特性/ 功能汽车动力学1. 预留与Carsim、Carmaker等顶尖动力学仿真软件的接口，也支持自建简单的动力学模型；
2. 道路仿真支持OpenCRG，可模拟道路的微观表面特性，提升汽车动力学的仿真的真实性；静态场景搭建1. 如同RoadRunner那样，可以方便快捷的搭建、编辑静态场景，并输出多种标准格式；
2. 支持OpenDrive高精地图，可自动将高精地图转化为路网模型；也支持导入GIS数据和点云数据来搭建场景；
3. 可基于神经渲染的方法，将图像、雷达数据直接自动化合成为3D模型数据；
4. 拥有标准化场景库资源，如主要城市的数字孪生模型、以及能够涵盖绝大部分交通情况的典型交通场景；动态场景搭建1. 支持OpenScenario（1.0、后续2.0），可以灵活方便的编辑单个交通参与者的行为，并输出OSC标准文件，如此可以最细致的还原、交换一些关键场景；
2. 预留与专业交通流仿真软件VISSIM、SUMO的接口，实现围观交通流仿真；
3. 可基于AI技术，利用采集到的真实交通流数据生成虚拟交通流；场景渲染1. 基于Unreal Engine开发（Unity颓势），实现基于物理模型（PBR）的场景渲染（比如：微表面模型、 RayTracing实时光线追踪）；
2. 基于物理模型的天气系统（雨、雪、舞、阴云、阳光、季节等）；
（当然，实现此两项对硬件要求比较高）传感器仿真1. 支持所有自动驾驶常用传感器仿真，种类越多越好，比如包括超声雷达、V2X、红外相机等，可设置的参数越灵活越好；
2. 所有传感器模型均基于物理模型，还原传感器真实的工作流程，如Lidar的RayCsting、Radar的FMCW连续调频波的发射与接收等；
3. Lidar用GPU来跑；通信接口1. 支持ROS、ROS2、OSI、Autosar、CyberRT等主流仿真接口，方便自动驾驶算法的接入；仿真支持1. 支持高精地图（此高精地图用于自动驾驶算法，非前面的场景搭建）；
2. 支持从MIL、SIL、HIL、到VIL的V-Shape开发流程，可作为OEM的实际生产力；
3. 可在公有云、私有云部署，实现大规模的仿真；此时，可以回过头看1.2.3节的内容，随着对各个模块的展开叙述，我们对“仿真平台的趋势和需求”也逐渐细化、清晰。
8. 自动驾驶测试标准——ASAM为例（2022/06/20）
前言：
关于这一节的内容，业界也正处在一个摸索发展的阶段。在测试场景标准方面，德国的ASAM Open X标准基本得到了业界的广泛认可，不出什么意外今后应当会是静态 + 动态场景的主流标准。
关于场景库，各家自动驾驶公司已经积累了一批场景库，而官方背景的中汽研也在主导建立一个大而全的场景库，意欲对后续的自动驾驶车辆功能进行测试认证。（注意：中汽研拥有对汽车标准法规认证的权力，所有主机厂车型上市前都需要通过其主导的各项认证）
下面的文字读起来会有些务虚，听上去空话套话多。但很多时候，也正是因为对标准建设的不重视，导致我国一些行业的长期落后与混乱。Anyway，可以为感兴趣读者提供一些视角。
8.1 概述
从上述的动力学仿真、传感器仿真到场景构建，到仿真接口与云计算，这些上下游仿真工具的打通以及平台的集成化发展，我们可以称之为“行业的纵向打通”（通过前面的内容也可以看出，这的确是一个较为复杂痛苦的过程）。除此之外，行业内还需要有“横向打通”，这包含了：
[*]不同的软件平台间动态、静态场景的统一兼容格式标准；
[*]统一的仿真标准接口；
[*]标准化的场景库，以及标准化的测试用例；
其中最关键的是场景格式的标准化，毕竟场景才是当前自动驾驶仿真的核心以及最宝贵的资源。标准化场景的好处就不再赘述，基本都是些正确的废话。前面提到的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项。
ASAM OpenX 自动驾驶仿真测试标准体系
标准名称类型初版发布说明格式OpenDrive静态道路模型2015.11精细化的道路模型信息，可作为高精地图标准格式XMLOpenCRG道路表面特性2020.09专注于车辆动力学、以及车辆对路面信息的反馈CustomizeOpenScenario动态行为场景2020.03描述自动驾驶的测试场景XMLOSI仿真接口2021.03比如传感器仿真接口或是信息接口Protocol BufferOpenLabel数据标注2021.11场景标签、传感器原始数据JSONOpenODD运行设计域研发中定义自动驾驶系统的运行场景，限制系统工作边界未知
8.2.1 场景举例
下面用一个简单的动态场景案例来理解OpenX标准中的“场景标准部分”，在一个配备了红绿灯的路口：
[*]左边有一辆自动驾驶车辆A，A当前面临黄灯，不知是否能通过路口；
[*]A后方左侧有一辆车B ，B前方有路障，大概需要并到A所在车道；
[*]路口下方是货车C，其正在等红灯结束；
[*]此时上方的人行道有一位行人P正在横穿马路；
动态场景案例
那么这个场景大概需要以下描述内容：
环境信息路网信息（XODR）、天气、光照信息（OSC）；道路表面情况比如路面材质是水泥还是沥青，是否有凸起、裂痕等对行驶产生影响的要素（CRG）；约束条件国家道路法规要求等：比如有的国家可以闯黄灯，有的则不允许；交通参与者A车：路口的距离（XODR），速度与加速度等驾驶状态（OSC），切换至黄灯时候的计时器（OSC），可能的路口驾驶意图（OSC）；B车：速度与加速度等驾驶状态（OSC），与路口的距离，与A的距离，对于A车辆动作的反应；C车：初始静止情况（OSC），绿灯后的反应时间（OSC）；（有交通灯管制，不必考虑AB的行为）行人：行人的速度（OSC）、距绿灯结束的时间；其他的交通参与者、随机的交通流（OSC）、静态障碍物信息（XODR）。一个场景主要的要素为，是谁（目标物体），在哪里（与道路或参照物关系），发生了什么（场景的动作描述），持续了多久（场景运行的时间），可见真实的动态交通场景要素极为复杂。
在Open X中，OpenDrive、OpenCRG、OpenScenario三个标准组合起来即可构成对上述静态+动态要素的全面覆盖，如下图所示。
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对路面的描述
OpenCRG的文件可以集成在OpenDrive中对道路表面的定义中（即<surface>部分），如此使用更为方便。OpenCRG除了提供详细的说明文档外，还提供了C-API以及Matlab-API，可以对路面数据进行读写、修改、生成、评估、可视化等操作。（如此是正确的标准制定方式，一份完善的标准不应当仅仅是一纸文件，这在后续的Scenario、OSI也有体现）。
OpenCRG可集成在OpenDrive中
[*]工业界
目前业界基于OpenCRG已有一些比较有趣的工作。比如，比利时的激光雷达公司XenoTrack推出了专门扫描路面的激光雷达，并且可以直接输出OpenCRG文件，导入到自动驾驶仿真软件如Carmaker、SCANeR中。
XenoTrack采集的路面情况
Ref：
ASAM官网：
[*]ASAM OpenCRG®
[*]Digital Twin of a road with the help of OpenCRG - YouTube（Demo）
[*]路面形状のOpenCRG/OpenDriveデータ化 - YouTube
[*]Jeongseon-gun detailed road 3D model for CarMaker - YouTube
[*]Tank following a path defined by an openCRG road - YouTube
XenoTrack路面测量：
[*]XenoTrack | Road Profile Lidar | XenomatiX
[*]XenoTrack固态激光雷达道路测量结果输出OpenCRG数据以及在IPG Carmaker中的应用_哔哩哔哩_bilibili
[*]XenoTrack采集的OpenCRG数字化道路数据导入SCANeR Studio仿真软件_哔哩哔哩_bilibili
8.2.3 OpenScenario——谁在哪儿干什么
在OpenDrive构建的静态路网基础上，OpenScenario是对虚拟动态场景的参数化描述。这包括了：
[*]对象：车辆（车型、轴距、外观几何等）、行人（男女老幼）、非机动车等；
[*]轨迹：在OpenDrive路网上的车道级路径规划、速度规划、车辆操作等；
[*]环境：天气、光照、时间等；
[*]OSC 1.0-1.X
当前的OSC 1.0版本描述的过程中还涉及非常具体的分层，比如，从故事Story、活动Act、顺序Sequence、动作Maneuver、事件Event，行动Action——就如同导演电影一样。
OSC的分层
OSC1.0 案例
前面讲到的不少软件VTD、51World、TADSim、Carla都支持了OpenScenario V1.0（下方Ref中有51Sim对OpenScenario的解读以及产品特性），腾讯更是深度的参与了OSC后续的1.X 标准的制定，不过目前各模拟期间xosc的兼容性都比较差。
腾讯与OSC
[*]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:
struct storm_data:
storm: storm_type
wind_velocity: speed
scenario env.snowstorm:
storm_data: storm_data with:
keep(it.storm == snow)
keep(soft it.wind_velocity >= 30kph)
cover(it.wind_velocity, unit: kph)
extend traffic:
car1: my_car with:
keep(it.max_speed == 60kph)
Ref：
官网 & 介绍：
[*]ASAM OpenSCENARIO®
[*]51Sim-One场景标准OpenSCENARIO的应用实践_哔哩哔哩_bilibili（推荐观看）
[*]OpenSCENARIO编辑器OpenScenarioEditor_郭明江_AD的博客-CSDN博客
[*]中文版ASAM OpenSCENARIO 1.0标准解读—维科号 (ofweek.com)
OpenScenario 2.0 M-SDL：
[*]Foretellix - Automated driving systems testing tools for simulations
[*]ASAM的OpenSCENARIO 2.0概念使用Foretellix M-SDL加以演示 (baidu.com)
[*]Webinar: Open M-SDL for scenario-based verification of ADAS & Autonomous Vehicles - YouTube
8.2.4 Open Simulation Interface（OSI）——仿真接口
OSI使用Google Protocol Buffer格式，定义了一个“自动驾驶算法”与“仿真框架”之间的标准接口，主要是通过标准化接口将传感器信息以及动力学模型连接到自动驾驶算法、或者仿真平台。
目前OSI内容并不能够完全满足自动驾驶仿真测试的需求，而是需要一个更加完整的体系，因此，OSI将会从物理传感器仿真、工具开发支撑、交通流信息、其他Open标准关联进行拓展。同样地，腾讯也深度参与了OSI标准地制定。
腾讯与OSI
官网 & 介绍：
[*]ASAM OSI®
[*]OpenSimulationInterface/open-simulation-interface: A generic interface for the environmental perception of automated driving functions in virtual scenarios. (github.com)
8.2.5 OpenLABEL
OpenLABEL则是定义了一个数据标注（图像、点云）的标准，包含了标注方法、标注结构以及文件格式，主要为了解决不同厂商间标注数据无法互通，难以交易的难点。标注的方法基本还是Bound ingBox、语义分割、实例分割那些，采用预设的Json格式输出，方便解析，没什么太新鲜的。
OpenLabel的Json格式表达
官网 & 介绍：
[*]ASAM OpenLABEL®
[*]OpenLABEL Concept Paper (asam.net)
[*]7 Demo of How to label ASAM OpenLABEL®with OpenLABEL - YouTube
8.2.6 OpenODD
[*]ODD定义
ODD的全称是Operational Design Domain（运行设计域）。提出这个概念的原因是：当前的自动驾驶技术还处于发展阶段，无法保证自动驾驶车辆在任何道路环境、任何天气条件下的安全行驶的。所谓ODD也就是自动驾驶系统的能力边界、或者说自动驾驶系统工作的前提条件，只有满足系统工作的前提，自动驾驶系统才会运作。比如，一些L2+级别的辅助驾驶功能即对使用场景做出了比较严格的限制，比如高速脱手系统、ACC什么的。
场景案例
上图是一个典型的场景案例，我们能归纳出的信息大概有：
[*]乡村道路，
[*]铺装路面
[*]可能会有动物
[*]其他车辆、行人不会很多
[*]天气较好
[*]etc
现实中描述驾驶环境的参数必然更多，也更加具体，但其形式基本类似于上面的范例。通过限制行驶环境以及行驶方法，并且在车辆脱离设计域之后采取紧急停车、驾驶员接管等动作，如此才能防止因自动驾驶能力不足而产生的事故。
[*]ASAM-OpenODD
OpenODD也很好理解，其目的就是创建一种可机器解释的、可交换的ODD的标准规范。当前，该标准正在研发阶段。2021年11月发布了Konzept版本。
官网 & 介绍：
[*]独家解读丨ASAM OpenODD V1.0.0 提案研讨会会议回顾_测试行业动态__汽车测试网 (auto-testing.net)
[*]全新的自动驾驶汽车安全标准概念——ASAM OpenODD概念发布_测试行业动态__汽车测试网 (auto-testing.net)
[*]浅谈自动驾驶ODD(Operational Design Domain) - 知乎 (zhihu.com)
8.2 C-ASAM——OpenX标准的中国化
每个国家的驾驶场景都有所不同，道路施工结构、交通标志、信号灯、交通状况都各有特点，因此场景标准需要有针对性地实施“中国化”，才能解决一些中国特色相关的问题。
2018年开始，中汽研下属的中汽数据有限公司与ASAM开始合作，并于2019年成立C-ASAM工作组，统筹管理中国区的ASAM标准。当前国内几乎所有主机厂都加入了C-ASAM，自动驾驶行业的互联网大厂如腾讯、百度、华为、大疆、51VR，清华、北航等高校都加入了C-ASAM。
Open X标准不是其他标准一样只给出几十页文档的花架子，其在Document、测试案例、开发接口方面的完善程度都比较高，版本的持续迭代也已经进入了正向循环。因此，笔者十分倾向于OpenX将来会是自动驾驶领域的一项极为重要的标准体系。
目前C－ASAM工作组的成员单位
当然，这并不代表目前Open X标准体系已经足够覆盖自动驾驶仿真测试中的所有需求，它还处于不断地建设过程中。OpenX标准也有助于让我们在更高的层面理解自动驾驶开发过程中的关键问题。
8.3 ISO标准
除了ASAM OpenX外，国际标准化组织 ISO 于2018年成立了 TC22/SC33/WG9 自动驾驶场景工作组，制定自动驾驶测试场景相关标准。工作组已于 2019 年通过了四项标准以及一项预留标准的立案，具体标准见下表：
编号内容牵头国家ISO 34501自动驾驶系统测试场景术语与通用信息中国ISO 34502基于自动驾驶车辆安全认证为目的的场景工程框架设定日本/德国ISO 34503自动驾驶系统的设计运行域分类英国/日本ISO 34504场景特征及场景分类定义（预留标准）德国/荷兰ISO 34505基于场景的自动驾驶系统的评测体系中国/英国私货：比较遗憾的是，在新一轮的浪潮中，中国再次在标准化方面没有取得先机，而是跟着国外的屁股后面走。大多数国内的标准风格都是：某个企业拉上一个国家部门做背书，发布一个干巴巴的文档就是所谓标准，没有实现细节、没有demo，没有API，也没有版本迭代，更遑论像OpenX一样的标准体系的建设，除了玄学的“指导作用”完全没有任何工程价值。
ASAM OpenX宝贵的地方在于“代码优先”，所有自然语言描述都有对应的XML代码实现，也有面向应用的API。
Ref：
[*]中汽数据周博林：ASAM 标准助力自动驾驶仿真测试落地 - 知乎 (zhihu.com) （推荐阅读）
[*]GitHub - BMEAutomatedDrive/ZalaZONE-automotive-proving-ground-virtual-simulation-models: Models of the ZalaZONE automotive proving ground in different file formats for simulation software (IPG CarMaker, PreScan, VTD Vires, SUMO, Unity 3D)
9. 自动驾驶的场景库（2022.06.20）
这一段较为乏味，技术较为淡化，更为关注产业。
9.1 场景库构建的目的
自动驾驶车辆在落地之前，需要经过大量虚拟以及实地测试。而如何进行这种测试？比较无脑的方式就是堆里程——无论是虚拟的里程还是现实的里程，只要测的里程足够多，可能覆盖到的场景也就越全面。但显然，此种方式成本极高，耗时极长；并且某种意义上，现实场景的多样性几乎是无限的，也几乎是不可预测的。因此，单纯的堆里程并不能解决问题。
业界的想法是：构建一批有代表性的测试场景，来覆盖现实驾驶中可能出现的情况，覆盖度越高，测试的结果也就更有意义。反过来说，这些测试场景也完全可以用于算法的训练和迭代。
这种场景库可以是虚拟的仿真场景库，对应前面提到的应用各种方法构建的仿真场景；另一方面，这些场景也可以是实际的场景，对应各大OEM在试车场搭建的各种测试道路、以及地方政府建设的 “XX自动驾驶试验园区”。
构建一个统一的标准场景库（虚拟 + 现实），对于推进自动驾驶落地的正面意义还有：
[*]顶层的设计避免各企业重复投入资源构建基础场景库，造成浪费，企业只需要构建一些个性化的场景库作为补充；
[*]统一的测试场景也有利于得到可量化的测试结果；
9.2 测试场景：概念 + 标准 + 构建方法 + 场景库
场景标准无非还是前述ASAM那一套；构建方法无非是前述的静态、动态场景的构建方法；场景库无非就是由很多不同区域、工况、环境组成的场景来覆盖现实中可能的场景。
因此省略该部分的叙述，详见Ref。
9.3 国内典型场景库
国内做的相对好的有三家：天津中汽研下属的中汽数据，重庆中国汽研，以及腾讯。具体可以参考下方九章智驾的文章，比较全面
来自九章智驾
Ref：
[*]一文读懂自动驾驶仿真测试场景与场景库_九章智驾的博客-CSDN博客
[*]中国汽研和中汽研是一个机构吗？ - 知乎 (zhihu.com)
10. Backups
10.1 场景的三层体系
目前相对比较通用的场景形式是由德国PEGASUS项目提出的功能场景-逻辑场景-具体场景三层体系。
场景类型详情举例场景语言形式功能场景“自车（被测车）在当前车道运行，在自车前方有前车加速运行，自车跟随前车行驶。”M-SDL等高级场景语言逻辑场景提炼出关键场景参数，并赋予场景参数特定的取值范围，如以上描述的场景可提取自车车速，前车车速以及加速度，自车与前车距离等参数，每个参数都有一定的取值范围和分布特性，参数之间可能还存在相关性。具体场景需要选取特定的场景参数值，组成场景参数向量，并通过具体的场景语言表示。OpenSCENARIO
GeoScenario*以上示例只是为了说明三层场景体系的内涵，具体的表述形式会有更多细节，需要有更多的标准和约束。
具体场景需要转换为计算机可理解的语言即场景语言才能发挥作用。场景语言是一种可用以描述自动驾驶系统待处理的外部环境的计算机可解析的形式化语言。
不同仿真软件支持的场景语言也不同：如CARLA和lgsvl等都支持基于Python脚本的场景语言；CARLA、VTD和最新版本的51Sim-One1.2等支持基于XML的场景语言。此外，protobuf、JSON都可以作为承载具体场景语言的格式。
这其中的关键不在于语言本身，而在于能全面且不冗余的覆盖交通元素的体系标准。
功能场景-逻辑场景-具体场景 By 51-World
10.2 Carla的交通流模型
来自动生成车辆、行人、交通管控等动态要素。比如Carla采用了基于标准UE4车辆模型PhysXVehicles，构建车辆并实现车道跟踪、遵循交通信号灯、限速、交叉口决策等基本功能，车辆和行人可发现并躲避对方。但实际上，其交通流仿真功能并不算优秀。
10.3 仿真平台的对比
来自公众号、报告，可以随便看看，但是个人认为这些表格说明不了什么问题——具备对应的功能不代表够用、好用，主要还是应该关注其具体的实现方案。同时这些信息有一定实效性，一些软件/平台没有的功能在后续可能会加上。
From 研报
九章的这篇文章里面的对比也很全面
一文读懂自动驾驶仿真测试技术现状 原创 陈康成 九章智驾 7月7日-爱建模 (aijianmo.com) 估计这么搞会让人失去阅读欲望的，我后面花点心思再把这篇拆分一下。拆成几篇万字左右的文章，这样读起来容易一些。 我读完了 这篇文章很干货 牛逼，兄弟 厉害，找个时间细细看，感觉不用拆分，毕竟想看的只会觉得太短了。 [调皮] 这是我看到的对于ADAS仿真最完整的系统梳理，牛逼。 非常好的文章，感谢作者分享[赞]！ Camera、Lidar这类传感器仿真还好做。IMU这种高帧率的传感器仿真作者有调研到什么好办法吗？感觉要么放弃渲染端以物理端为主