如何在无人驾驶的各个模块高速迭代的同时保持整体系统的能够完全应对当前的环境场景？模拟器（又称仿真器）就是为了解决这一问题而诞生的。
模拟器的必要性
随着车辆及测试场景的增多，我们得到的一个实际经验是：“No Simulation, No Scalability”（没有模拟仿真，就没有可扩展性）。
模拟器的优势：
- 极大地提高开发效率
- 测试和验证极端场景
- 最大化发挥沉淀数据的作用
- 孵化人工智能和场景驱动的重要先决条件
模拟器平台将以两种方式处理每个模块的输出数据，一种是进行多方位多角度的显示，便于开发人员对模块的输出结果进行校验和调试。另一种是基于某种评价标准，自动对输出数据进行评判和打分，并且将评判和打分的结果以详细数据报告的形式呈现。
对模拟器系统的要求
数据信息在车与外部环境的相互作用中产生了一个闭环。无人车的仿真系统就是寻求在软件环境中重塑这样的一个数据闭环，以测试车上的主要软件算法模块。
- 模拟器系统有一个比较好的前端，从而更好地与后期的云端大规模模拟兼容。
- 模拟器后端由四个部分组成：模块调度（调度引擎根据输入数据时序，调用各个软件模块，生成输出的数据包）、打分系统（根据数据包，自动判断各模块是否正确处理了该输入场景）、智能引擎（模拟器通过接收配置文件，自动生成场景元素，可以采用人工智能的解决方案，灵活改造和生成场景）、完美控制（采用完美控制车辆的方式，剔除车辆控制方面的误差）。
- 针对任何场景的完整数据闭环仿真，在逻辑层面都需要运行在同一个模拟器实例内。
模拟器驱动方式
基于外部数据的不同，模拟器的驱动方式主要有两类：WorldSim 和 LogSim。
角度 | WorldSim | LogSim | |
|---|---|---|---|
0 | 理念 | 虚拟仿真概念 | 数据仿真概念 |
1 | 产生方式 | 计算引擎生成，或者基于特定数据加工后生成 | 实际测试发现问题时的短暂数据落盘 |
2 | 时间长短 | 一般是一个完整的场景，可以比较长 | 往往比较短，集中在一个特定场景的前后约十几秒 |
3 | 障碍物智能 | 可以智能地，或者临时增加一些有简单互动逻辑的障碍物 | 周边障碍物体的运动线路已经进行提前录制 |
4 | 重要性 | 可以预见性地设置并处理一些未曾遇到的问题 | 积累已经解决的问题，保证不会重复出现 |
5 | 特点 | 将系统置于一个完整的虚拟世界或者“游戏场景” | 真实场景，模拟感知的不确定性，以此帮助系统处理这种真实情景，甚至容忍某些感知错误 |
6 | 存在的问题 | 测试有效性存疑 | 在模拟过程中出现异于录制的车辆状态的新的虚拟位置状态 |
模拟器实际使用场景
模拟器现状
模拟器是一个团队或者公司的核心竞争力，因此真正开放给普通开发者和用户使用的无人驾驶模拟器系统屈指可数。
作为最通用简单的机器人操作系统，ROS提供了一套基于Rviz和Gazebo的简单模拟器环境，其具有简单和易用的特点。但也有很多的问题：
- 只具有LogSim功能，不具备任何WorldSim定制化能力。
- 不是专门为无人驾驶系统定制的，功能上既有冗余，又有不足，定制化能力偏弱。
- 没有Web调试界面，必须在本机上启动调试程序，增加了调试的不便。
- 不具备闭环功能，无法智能地产生障碍物和场景，只能做简单的LogSim验证。
- 无法自动打分。
- 难以和未来云端的大规模模拟集成。
线上开放的平台也有很多，像是百度的Apollo平台的模拟器。但是Apollo模拟器在某种意义上更像是一个服务，具有一定的封闭性。
真正进行无人驾驶研究的公司一定需要自行研发一套完整的模拟器系统的，所以模拟器的研发也是一个很重要的任务。
主要用户
模拟器的主要用户有两类，测试人员（QA）和研发人员（RD）
代码语言：javascript复制flowchart TB
qa1["测试时发现问题"]
qa2["原始数据落盘累积"]
re1["发版，重新进行测试"]
rd1["研发人员复现定位问题并加以修复"]
rd2["1. 人工验证：使用发现问题时的数据，n确认问题已经修复n2. 机器验证：使用累积的过往历史数据n集合，确认修复该接管问题后，n没有导致新的问题"]
rd3["研发新功能"]
rd4["验证新功能不破坏原有其他功能"]
rd5["针对建立新功能的场景"]
re2["提交测试人员测试"]
subgraph 研发人员 RD
rd1-->rd2
rd3-->rd4-->rd5
end
subgraph 测试人员 QA
qa1-->qa2-..->rd1
end
subgraph 循环 RE
rd2-.->re1
rd5-.->re2
end
