在目前阶段，不同公司的仿真，从工具链到使用的场景数据、从方法论到数据的来源，都有较大差别。大家说的都是“仿真”，但实际上说的未必是同一个概念。那么，衡量一个公司的仿真能力强弱，最关键的指标有哪些呢？这一轮访谈下来，我们得到的答案有如下几点——

1. 可复现性

即真实道路测试中发现的问题，能否在仿真环境下复现。（轻舟智航，毫末智行）

关于这个问题，本文后半部分会有更详细的解读。

2. 场景定义能力

即该公司定义的仿真场景能否真正帮助提升自动驾驶的实际通过能力。

3. 场景数据获取能力

场景数据的获取、生产能力，数据通用和可复用性（详情参考仿真系列第一篇文章 《自动驾驶科普文之一：场景来源、场景泛化及提取》）

4. 场景数据的质量和数量

即仿真场景跟真实场景的接近程度有多高，场景数据的精度、置信度、鲜度，以及有效场景的数量，暨是否有足以支撑多实例并行仿真所需要的海量仿真场景数据。

5. 仿真效率

即如何自动化高效率做数据挖掘，去产生仿真所需要的环境模型，从而快速发现真问题。

6. 技术架构

即是否有适合被测对象需求的完整技术闭环体系。（IAE智行众维 李月）

7. 是否具备大规模并发测试的能力

只有在大规模的测试中（实例及场景的数量都足够多），一个公司才能去对模型精度、系统稳定性等进行评价体系的建设，这考验了一家公司的数据管理、数据挖掘、资源调度等能力。（轻舟智航）

8. 仿真的精度

面向规控的仿真和面向感知的仿真对精度要求不同——前者可能要看车辆动力学模型是怎样的，有哪些抽象层次，交通流中的干扰行为颗粒度；后者可能要看不同传感器根据不同成像原理加的噪音等。

通常，用户出于成本的考虑，希望技术架构能通用。然而，过于通用的方案，在某些方面会牺牲掉精度——模型的精度、模型的效率和模型的通用性，是三角互搏的关系。

说到仿真数据的真实度，我们还有必要再追加一个问题：毫末的 MANA在仿真系统中引入了真实交通流场景，毫末称通过与阿里以及德清政府合作，利用路端设备将路口处每时每刻的真实交通流都记录下来，再通过log2world的方式导入到仿真引擎里面，加上驾驶员模型之后，就可以用于路口场景的调试验证。那么，这种数据的精度如何保障？

对此，毫末的仿真专家说：“目前这种数据当前主要还是用来做认知模块的研发测试，所以，我们需要的是尽量真实的交通动态行为，数据本身就是对连续世界做了离散化，只要采集频率满足认知算法计算的需求就可以了，我们不需要去将这个数据去和真值做比较（也没有办法获取绝对真值）,简单来说就是我们追求的是动作的合理性和多样性，并不是精度。”

9. 仿真测试与实车测试的一致性

有商用车无人驾驶公司的仿真工程师说，他们经常会发现SIL测试的结果跟真实路测相反——在真实路测中没问题的场景，在SIL中有问题；而在真实路测中有问题的场景，在SIL中却没有问题。

有主机厂自动驾驶仿真负责人称，他们在做HIL测试时发现，车辆在仿真场景中的性能跟其在真实道路上的性能或多或少会有点差异。出现这种差异的原因可能在于：（1）虚拟传感器、EPS等并没有做得跟实车上完全一致；（2）虚拟场景跟真实场景没做到完全一致；（3）车辆动力学的标定做得不准。

10. 仿真在公司研发体系中的地位

仿真在实际业务的渗透率，也就是在研发流程中，仿真数据在整个业务使用数据中的占比，仿真是否被作为研发和测试的基础工具。（毫末仿真专家）

11. 是否形成商业闭环

某自动驾驶公司仿真专家说：“对仿真公司来说，率先构建起商业闭环比技术本身的优势更重要。”

51 World车载仿真负责人鲍世强称，客户在选择仿真供应商时关注的点主要有：A.仿真模块是不是足够全，该有的都有吗？B.你能给他提供什么样的工具链。C.仿真平台的开放性。

提到开放性，鲍世强说：“整体的趋势是，用户其实并不希望直接买一个软件去解决某个具体的问题，而是希望搭自己的平台，因此，他们更希望仿真供应商的技术模块能够赋能他们去搭建自己的仿真平台。所以，仿真供应商需要考虑API接口怎么设计、跟客户已有的模块怎么集成，甚至是开放一部分代码给客户。”

附：如何提高场景的可复现性

“道路中发现的一个问题，能不能在仿真环境下去复现”被轻舟智航等公司视为衡量一个公司仿真能力强弱的最关键指标之一。那么，究竟哪些因素会影响到场景的可复现性呢？

带着这一问题，笔者对多位专家进行反复追问，得到的答案如下：

1. 车辆模型、传感器模型、道路模型、天气模型会跟真实情况有出入。

2. 云端和车端的评价标准可能不一致。

3. 仿真系统中的通信时序、调度时序跟实车上的时序不一致。比如接收一个消息，如果不小心早接收一帧或者晚接收一帧，最后在蝴蝶效应下，差别就会很大。

4. 仿真系统中的车辆控制参数跟实车不一致。实车测试中，油门、刹车、方向盘、轮胎这些都是以物理的形态存在的，而仿真系统中并没有这样的物理部件，因而只能用模拟手段，如果车辆动力学的问题处理不好，模拟的真实程度就会打折扣。

5. 仿真系统中的场景数据不完整。在做仿真时，我们可能只会截取场景的某一片段，如红绿灯前后几秒的数据是没有的。

6. 问题可能被描述环境的逻辑语言覆盖，语言定义的层次和覆盖度可能不够完善。

7. 仿真软件本身跟各种场景的适配性不够好，语言之间的切换不流畅，难以支持大规模、多节点运行。

8. 真实道路中的数据，变量很多，在做仿真的时候，为了尽快地发现问题，工程师们需要“假定”某几个参数不变，以减少对某个关键变量的干扰。

9. 对自动驾驶的感知、预测、定位等模块之间的计算顺序，可能在云端跟车端是不一样的；也可能车端并没有把某些信息严严实实地记录下来——只要有一帧的差异，就可能导致一个结果出现问题。

10. 如果是感知层面的问题，场景复现需要将三维场景做到比较好的逆向生成，再通过泛化和视角变换，对数据进行增广，这里每一步都是有点难度的。如果是规控层面的问题，那么想要准确地复现场景，需要识别场景的交互行为以及关键参数，从而准确地生成场景并触发场景。（深信科创创始人 杨子江）

触发场景指的是，本场景希望测试的内容是否实现。比如要测一个行人突然在主车前穿马路，如果主车都开过去了行人才走，那么就没有起到测试效果，也就是没有触发场景。例如一个行人穿马路又折返，行走的速度、折返的时间点、主车的速度都很关键，这是单车单人。多交通参与者就复杂得多，互相的关系是耦合的，甚至一个参数稍有偏差，仿真的效果就大打折扣。