一．仿真中的“一天多少万公里”该怎么理解？

跟真实道路测试类似的是，一些仿真公司也强调“行驶里程”，比如，每天“几十万公里”，那这个数字背后的真实含义究竟是什么呢？它跟真实道路上的行驶里程有何区别呢？

跟真实道路测试类似的是，一些仿真公司也强调“行驶里程”，比如，每天“几十万公里”，那这个数字背后的真实含义究竟是什么呢？它跟真实道路上的行驶里程有何区别呢？

二.超实时仿真

在采访中，笔者反复问到一个问题：仿真平台上跑的车，跟真实世界中的车，是在同一个时间维度上的吗？换个说法：仿真平台上的1小时，等于真实世界中的1小时吗？会有“人间一年，天上十年”的情形出现吗？

答案是：可以等于（实时仿真），也可以不等于（超实时仿真）。超实时仿真又可分为“时间加速”和“时间减速”两者情况——时间加速即仿真平台上的时间比真实世界中的时间快，时间减速即仿真平台上的时间比真实世界慢。

仿真比真实世界的时间快是为了提高效率，那么，比真实世界的时间慢又是为了什么？

安宏伟的解释是：“举个例子，有一些仿真测试对图像渲染的精度要求非常高，为了追求精度，单帧图像的渲染可能无法在实时情况下完成。这种比真实时间慢的仿真，不是做实时的闭环测试，而是做离线测试。” 

具体地说，在实时仿真中，图片在生成后直接发给算法去识别，这个过程也许能在100毫秒内完成，但在离线仿真下，图片在生成后先保存，在离线条件下发送给算法处理。

根据安宏伟的解释，在仿真平台上做超实时仿真需要满足如下两个前提条件：服务器的算力资源足够强大；被测算法能接收虚拟时间。

算法能接受虚拟时间，这个怎么理解？安宏伟的解释是，有一些算法在结合硬件运行平台的条件下，可能需要读取硬件上的授时或网络授时，而无法读取仿真系统提供的虚拟时间。

某Tier1的仿真专家说：在仿真系统的工程框架PoseidonOS里做到精确的时间对齐和同步，然后就可以把算法部署在集群服务器上，进而仿真空间的时间可以跟真实物理世界的时间解耦，解开了就能“随意加速”了。

那么，在做时间加速的的时候，能加速2倍还是3倍，这个加速倍数又取决于什么呢？

安宏伟的答案是：服务器的算力资源、测试场景的复杂度、算法的复杂程度、算法的运行效率等。即理论上，在同等场景复杂程度、同样算法的条件下，服务器的算力资源越强大，可实现的加速倍数就可能越多。

时间加速倍数的上限是多少呢？这个问题，我们得结合时间加速的原理来回答。

据某自动驾驶公司仿真负责人解释，由于算法复杂度不一致等原因，训练模块、车辆控制模块等各模块的计算速度是不一样的，而超实时最常规的方法就是通过对各个参与计算的模块做统一调度。 所谓加速，就是计算速度比较快的模块“取消等待时间”——不管你另外一个模块又没有算完，时间到了我就同步。

如果各模块之间计算周期的差异太小，这个被取消的等待时间就很小，因此，加速倍数会很低；另一方面，如果各模块的计算周期差异特别大，比如这个需要1秒，而另外一个需要100秒，那也没法“取消等待”。

因此，时间加速的倍数往往是有限的——能达到2-3倍就算很高了。

甚至，有不少专家说，在实践中，要真正做到时间加速很难。

深信科创创始人杨子江称，如果自动驾驶系统的算法已被编译部署到了域控制器或工控机中（在HIL阶段就是如此），则它在仿真系统中就只能以实时的方式运行——此时，超实时仿真行不通。

安宏伟也说：“硬件在环（HIL，半实物仿真）本身必须是实时仿真，不存在‘超实时’的概念，也不适用‘并行仿真’或者‘时间加速’的提法。”

鲍世强说：“时间加速的前提是，对时间的精确控制，以及时间同步。感知很难加速，因为不同传感器的频率不一样，摄像头可能是30 Hz,然后激光雷达是10Hz，类似于这种，你如何保证不同传感器的信号可以强同步？”

此外，一位在硅谷供职多年的仿真专家认为，现在还没有哪个公司能真正做到超实时仿真，“能做到实时就不错了”。 在这位专家看来，要提高仿真效率，大规模并行仿真是更可取的方案。

而安宏伟认为，时间加速能力取决于每个实例上的超实时水平、总实例数及场景的质量。“实际上，对于云算力仿真而言，单实例上的超实时水平并不很重要，核心还是关注该实例上仿真的质量需要。”

轻舟智航仿真专家甚至认为，“加速倍数”这个说法其实不太成立。因为，仿真中的时间跟真实世界的时间之间，并不是一个简单的倍数关系，它们甚至没有关系。在实践中，更多地是用技术的手段来降低算力的占用，提升时序调度效率，来达到运算时间的提升。

在真实路测中，车辆行驶的连续的，你不会说这是个corner case，我跑一下，那里不是corner case，我就不跑了，而是跑了很长一段路，再在其中筛选出corner case；在仿真平台上，工程师们通常只截取了跟corner case有关的那些片段（即“有效场景”），处理完这个事情后，时钟就会跳到下一个时间段，而不需要在无效场景上浪费时间。

因此，在做仿真时，如何高效地筛选出有效场景，是比时间加速倍数更重要的事。

说到这里，我们便可以发现，尽管时间加速看上去不明觉厉，但要增加在仿真平台上的虚拟行驶里程，其实不能主要依赖时间加速，关键还是得靠“多实例并发”，其实就是要做云算力仿真，增加服务器和仿真实例的数量。

三．大规模并发测试

可否支持在云端的高并发、支持多大规模的并发，这个难点到底在哪里？是不是只靠堆服务器就行了？

听起来没错，但问题在于，服务器的规模每增加一个数量级，就会带来新的问题——

（1）服务器的成本挺高的，每台服务器几十万，如果有一百台服务器，直接成本就是几千万，理想的解决方案是上公有云，但国内的主机厂接受公有云还需要一段时间；

（2）大规模并发的情况下，传感器的原始数据极其庞大，这些数据不仅存储成本很高，而且传输也很难——在不同的服务器上做数据的同步会出现延迟，进而影响到智行效率；

（3）每一路跑的并不是连续交通流场景，而是很某个很简短的片段，可能只有30秒，但通常是上千路并行，如果1000路有1000个算法在1000个场景上跑，这对仿真平台的架构设计提出了很严峻的挑战。（某仿真公司CEO）

不过，针对上述最后一条，安宏伟的说法是：这是云算力仿真的基本需求，对我们来说并不算挑战，苏州相城区的云仿真平台早在2019年就已解决了这个问题。此外，云仿真平台跑的场景也会有数公里的连续的复杂/组合场景，相城的Robo-X仿真测评体系里就包括这类（组）场景。基于这类场景可以进行虚拟仿真下“接管”的测试。