2万字长文说清自动驾驶仿真的8大问题

98 阅读 0 评论 65 点赞

我是靠谱客的博主怕黑钥匙，最近开发中收集的这篇文章主要介绍2万字长文说清自动驾驶仿真的8大问题，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

交流群 | 进“传感器群/滑板底盘群”请加微信号：xsh041388

交流群 | 进“汽车基础软件群”请加微信号：Faye_chloe

备注信息：群名称 + 真实姓名、公司、岗位

对自动驾驶仿真中的很多知识点（排名第一的就是“用真实道路数据做仿真”），笔者已经好奇了两年多时间，但此前一直没有机会学习。去年4月份的疫情期间，偶尔得到了一次跟某仿真公司创始人闲聊的机会，笔者便趁机向其请教了许多问题。

此后，为交叉验证，笔者又陆陆续续向近20位在自动驾驶仿真业务一线的专家请教。

对本系列学习笔记提供支持的专家包括但不限于智行众维CEO安宏伟、深信科创创始人杨子江、智行众维CTO李月、51 World CTO 鲍世强及毫末智行和轻舟智航、车右智能的仿真专家等。在此表示感谢。

问题一：场景来源——从合成数据到真实道路数据

据公众号“车路慢慢”的作者李慢慢及智行众维CTO李月介绍，仿真测试场景的来源，大体上可以有2种思路：

第一种思路是由德国PEGASUS项目提出的功能场景-逻辑场景-具体场景三层体系：1）、通过真实道路数据采集和理论分析等方式，得到不同的场景类型（即功能场景）；2）、再分析出这些不同场景类型中的关键参数，并通过真实数据统计和理论分析等方法得到这些关键参数的分布范围（即逻辑场景）；3）、最后选取其中一组参数的取值作为一个测试场景（即具体场景）。

如下图所示：

举个例子，功能场景可以描述为，“自车（被测车）在当前车道运行，在自车前方有前车加速运行，自车跟随前车行驶。” 逻辑场景则提炼出关键场景参数，并赋予场景参数特定的取值范围，如以上描述的场景可提取自车车速、前车车速以及加速度、自车与前车距离等参数，每个参数都有一定的取值范围和分布特性，参数之间可能还存在相关性。具体场景则需要选取特定的场景参数值，组成场景参数向量，并通过具体的场景语言表示。

这其实就是通常所说的“虚拟搭建/用算法生成的场景”，尽管对场景的理解仍来自于真实道路场景，但实践中更多地是基于这种理解在软件里面“人为地拟定”一个行驶轨迹、一组场景，因而，这种场景背后的数据也被称为“合成数据”。

在实操中，这种思路面临的主要挑战是，仿真工程师对车辆的正常驾驶场景的理解是否足够深。如果工程师不理解场景，任性地去“拟定”出一个场景，那当然是不能用的。

第二种思路是：采集自动驾驶车辆预定工作区域内的交通流量数据，并将这些数据输入交通仿真工具中产生交通流，并使用该交通流充当自动驾驶车辆的“周围交通车辆”，实现测试场景的自动生成。

据深信科创创始人杨子江介绍，为确保能获得比较准确的“真值”，通常，工程采集车上的传感器配置要比普通的自动驾驶汽车高许多，如定位系统会采用20W以上的设备以及高线束的激光雷达，产生的数据会更加精确。

UberACT前首席科学家Raquel Urtasun创办的仿真公司Waabi，据说无需激光雷达等高精度的传感器，直接用摄像头收集的数据来做仿真。

用真实道路数据做仿真，最大的优势是，场景的多样性不会受限于工程师对场景的理解不足，因而，更容易将那些“谁也想不到”的未知场景给“打捞”出来。

此外，某自动驾驶公司仿真负责人说：为了提高仿真的真实度，后面大家就会尽可能地少采用合成数据，多采用真实道路数据。实际上现在的仿真已经在往这个方向发展了——真实数据和模块越来越多了。

不过，有一线仿真实践的工程师们普遍反映，这一思路过于理想化。具体地说，用真实道路数据做仿真，存在如下几点局限性——

1.数据需要做人工校核

实际上，传感器采集到的数据并不能直接用于仿真——数据类型及格式需要转换，有很多无效数据需要清洗，也要从中辨别出有效的场景，某些特定的要素需要进行标注，不同传感器之间的数据需要实时同步和融合等等。

正常情况下，自动驾驶车辆的感知数据无需经过人工校核，而是直接给到决策算法，但如果是做仿真，对感知数据的人工校核就是必不可少的步骤。

2. 逆向过程的实现难度比正向过程大

某无人驾驶卡车公司仿真工程师说：用合成数据做仿真，是一个正向的过程，即你先知道自己需要去做哪些测试，然后再自己主动去设计这样一个场景；用真实数据做仿真是一个逆向的过程，即你先遇到一个问题，然后再去解决这个问题。两者相比较，后者的难度要大得多。

3.无法解决交互问题

复睿微电子负责人Jame Zhang在一次公开分享中提到，WorldSim（用虚拟数据做仿真）像在玩游戏，而LogoSim（用真实道路数据做仿真）则更像是电影，你只能看，没法参与，因此，LogoSim天然没法解决交互性的问题。

4.无法做闭环

复睿微电子负责人Jame Zhang还提到了这两种仿真方法的另一个区别：使用真实道路数据做回放，能采集的片段永远是有限的，经常是，采集开始的时候，危险可能已经发生了一段时间了，之前的数据你很难获得了，但如果用虚拟数据（合成数据），就无需面对这个问题。

某主机厂的仿真负责人说：“上述专家表述的是采集的过程。的确，考虑到采集设备的容量以及有效场景的定义，采集打点的场景都是有长度的，一般都是功能触发前后一段时间，尤其是触发前的缓存不会特别长。另一方面，在数据采集后用来回灌的时候，则只能是功能触发前的场景是有效的，而功能触发后的真实场景却是无效的。”

这位主机厂的专家说：真实道路数据用来训练感知算法是可以的，但要测试整个算法链路的话，还是得依赖合成场景数据。

不过，这位主机厂的仿真主管最后也强调：“所谓的‘没法实现闭环’也是相对的，已经有供应商可以把采集到的场景里面的元素都完成参数化，这样就可以闭环了，但这种设备的价格是非常昂贵的。”

5.数据的真实度仍然难以保障

用真实交通流数据做仿真，也被称为“回灌”。

据深信科创创始人杨子江介绍，“回灌”需要用到核心技术有两个：一个是在仿真环境中还原路采数据的路网结构，二是将路采数据中的动态交通参与者（行人，车辆等）在不同坐标系下的位姿信息映射到仿真世界路网下的全局坐标系中。

这个过程中需要使用的工具有SUMO或openScenario——用于读入交通参与者的位点信息。

某主机厂仿真专家说：“原始数据的回灌也不能保证百分之百真实，因为在将原始数据注入仿真平台后，还得加上车辆动力学仿真。但如此一来，场景是否还与真实道路上的场景一致，就不好说了。”

究其原因，现有的交通流仿真软件往往还存在如下几大缺陷：

生成的交通流不够保真，往往只支持车辆轨迹导入，而车辆间的双向交互不够真实；

仿真模块（自车）和交通流模块（其他道路参与者）之间的数据传输接口受限（如路网格式不同，需要路网匹配），第三方可操作性有限；

基于规则的交通流模型是面向交通效率评价的，可能会出现过于简化的问题（往往采用一维模型，假设设立是沿着中心线行驶的，较少考虑横向影响），难以满足交互安全评价的需求。

某Tier 1的仿真工程师说，用真实交通流数据生成仿真场景，如何选择交通流模型（比如跟驰模型、换道模型怎么定义）、如何定义交通流仿真模块接口都是有相当难度的。同时，来自自车的数据和其他道路使用者的数据如何做好时间同步，也会是一个很大的问题。

6.数据的通用程度低、泛化难度大

智行众维CEO安宏伟和CTO李月都特别提到了仿真数据的“通用性”问题。所谓数据通用性，即指车辆及场景的参数是可以调整的。比如，在数据是用一辆轿车去采集的，摄像头的视角很低，但在变成仿真场景之后，摄像头的的视角可以调高，这组数据可以用于卡车模型的测试。

如果场景是虚拟搭建/算法生成的，各参数可根据需要任意调整；那么，如果场景是基于真实道路数据的呢？

某工具链公司的仿真负责人说，在用真实道路数据做仿真的情况下，一旦传感器的位置或者型号有变更，这一组数据的价值就降低，甚至会“作废”。

轻舟智航的仿真专家说，也可以用神经网络对真实道路数据做调参，这种调参的智能化程度会更高一些，但可控性会比较弱。

用真实交通流数据做仿真，又称为“回灌”，而回灌又可分两种，直接回灌和模型回灌——

所谓“直接回灌”，是指对传感器数据不做处理直接喂给算法，在这种模式下，车辆及场景的参数是不可调整的，用某款车型采的数据，就只能用于同款车型的仿真测试；

“模型回灌”，则是指先将场景数据抽象化、模型化，用一组数学公式将其表达出来，在这个数学公式里面，车辆及场景的参数都是可调的。

按李月的说法，直接回灌是无需用到数学模型的，“比较简单，基本上，只要有大数据能力都能做到”，但在他们的模型回灌方案中，不管是传感器模型还是车辆的行驶轨迹、车速，都是要通过数学公式来完成的。

模型回灌的技术门槛很高，成本也不低，一位仿真工程师说：“要把传感器录制的数据转换成仿真数据，数据解析的过程非常难。因此，当前，这一技术主要停留在PR层面上。在实践中，各家的仿真测试都是以算法生成的场景为主，以采自真实道路集的场景为补充。”

某自动驾驶公司仿真负责人说：用真实交通流的数据做仿真，目前还是很前沿的技术，这些数据的调参难度很大（仅可在一个很小的范围内调参）。因为路采的都是一堆日志、一条条的记录，它记录的是这个车第一秒第二秒怎么运行的，而不像人工编辑的一些场景是由一系列的公式组成的。

这位仿真专家说，模型回灌存在的最大挑战是：在场景比较复杂的情况下，要将场景用公式表达的难度极高，这个过程是可以通过自动化的方式来实现的，但最终做出来的场景能不能用也是个问题。

Waymo在2020年公布了的“通过将传感器收集到的数据直接生成逼真的图像信息来做仿真”的ChauffeurNet，其实就是在云端用神经网络将原始道路数据转换成数学模型，然后做模型回灌。但一位在硅谷多年的仿真专家说，这个还停留在试验阶段，距离成为真正的产品还有一段时间。

这位仿真专家说，比回灌更有意义的是引入机器学习或强化学习。具体地说，仿真系统在充分学习各类交通参与者行为习惯的基础上训练出一些自己的逻辑，并将这些逻辑公式化，然后，在这些公式中调参。

不过，智行众维CTO李月和副总经理冯宗磊的说法是，他们目前已经能够实现模型回灌了。

冯宗磊认为，一个仿真公司是否具备做模型回灌的能力，这主要取决于他们所使用的工具及场景管理能力。

“场景管理中，切片是非常重要的一环——不是所有的数据都是有效的，比如，1小时的数据中，真正有效的可能只有不到5分钟，在做场景管理的时候，仿真公司需要将有效的部分切出来，这个过程便被称为‘切片’。

“切片完成后，仿真公司还需做一个相应的带语义信息的管理环境（比如哪个是行人、哪个是十字路口），方便下次去筛选。具体地说，需要先对数据切片做分类，然后再做动态目标列表的精修，精修完之后再导入到仿真环境的模型里去，如此一来，模型就有相应的语义信息了。有了语义信息，就可以调参了，然后，数据就可以复用了。

“多数公司基于真实交通流的数据之所以不能调参，是因为他们没有做好场景管理。”

深信科创创始人杨子江说：“如果要将路采数据泛化，并且要保持数据的真实性，可以在场景初始化以及开始阶段回放路采数据，在某一时刻由smart-npc模型来接管道路中的背景车辆，使背景车辆不会按照路采数据运行。smart-npc接管后通过把泛化后的场景记录下来，以做到泛化后的关键场景可回放。”

某主机厂的仿真工程师认为，模型回灌尽管听上去“不明觉厉”，但实际上“必要性不大”。原因是：将数据模型化与回灌的初衷不符——回灌的初衷是想要真实的数据，但既然模型化了，参数可调了，就不是最真实的了；费时费力，数据格式转换非常麻烦，费力不讨好。

这位工程师说：“既然你想要更多场景，那直接用仿真器大规模生成泛化场景就行了啊，大可不必走真实数据模型化这条路。”

对此，冯宗磊的回应是：

“用算法直接生成场景，这在开发的早期当然是没问题的，但局限性也很明显——那些工程师们‘想不到’的场景怎么办？真实的交通状况千变万化，你的想象力不可能穷举所有。

“更关键的是，在工程师想象出的场景中，目标物之间的交互关系往往是不自然的。比如前方有车辆插入，它是以多大的角度插入？在距离你10米时还是5米时插入？在用算法生成场景的实践中，场景参数的制定往往带有非常的大主观性、随意性，工程师拍脑袋想出了一组参数注入模型，但这组参数是否具有代表性呢？”

冯宗磊认为，在无人驾驶还处于Demo阶段时，靠算法生成的虚拟场景能满足需求，但在前装量产时代，基于大规模的自然驾驶数据（真实交通流数据）来做场景泛化，还是很有必要的。

据一位跟Momenta有过接触的人士说：“Momenta已经具备了用真实道路数据做场景泛化（调参）的能力，但他们的技术只给自己用，不对外。”

51 World车载仿真负责人鲍世强，认为，自然驾驶数据做泛化目前还比较前瞻，但未来肯定会成为很重要的方向，因此，他们也在探索。

总结：两种路线相互渗透，界限越来越模糊

复睿微仿真负责人James Zhang在前段时间的一段分享中提到，特斯拉的仿真有两种方法：场景完全虚拟（算法生成）的叫 WorldSim，将真实数据回放给算法看的叫LogSim，“但WorldSim中的路网也是在对来自真实道路的数据做自动标准的基础上生成的，因此，WorldSim与LogSim的界限越来越模糊”。

轻舟智航的仿真专家说：“真实场景数据转化为标准格式化数据后，可通过规则去进行赴泛化，从而产生更有价值的仿真场景。”

51 World 车载仿真业务负责人鲍世强也认为，未来的趋势是，用真实道路数据做仿真和用算法生成的数据做仿真这两种路线会相互渗透。

鲍世强说：“一方面，用算法生成场景，也依赖于工程师对真实道路场景的理解，对真实场景的理解越透彻，建模就越能接近真实。另一方面，用真实道路数据做场景，也需要对数据做切片、提取（将有效部分筛选出来），再设定参数、触发规则，再做精细化的分类，然后可以将它们逻辑化、公式化。”

问题二：场景泛化与场景提取

上面几段反复提到的对场景数据做“调参”，又被称为“场景泛化”——通常主要指对虚拟搭建的场景做泛化。用某主机厂系统工程师的话说，场景泛化的优势是，我们可以“凭空造”一些现实世界当中从来都没有过的场景。

一个仿真公司的场景泛化能力越强，对某个场景调参后得到的可用场景的数量就越多，因此，场景泛化能力也是仿真公司的一项关键竞争力。

不过，轻舟智航的算法专家说，场景泛化可以通过数学模型、机器学习等方法去实现，但关键的问题是如何保证泛化的场景是真实、而且更加有价值。

决定一个公司的场景泛化能力强或者弱的关键要素有哪些？

深信科创创始人杨子江认为，场景泛化中有一个很大的难点是，如何将轨迹抽象为更高级别的语义，用一形式化的描述语言来表达。

某Tier 1仿真工程师说：主要看该公司所采用的仿真工具是用什么语言（比如openscenario）来描述不同的交通场景的，这门语言对交通环境中各个层次的定义是否合理（可表示需要的细节，同时又具备可拓展性）。

针对功能场景、逻辑场景以及具体场景都有相应的场景语言：如针对前两者，有M-SDL等高级场景语言；针对后者有OpenSCENARIO、GeoScenario等。

还有一个层面可能是对干扰行为的仿真，对各种驾驶行为、驾驶“性格”的泛化程度。

△图表摘自孙剑、田野、余荣杰所著《自动驾驶虚拟仿真测试评价理论与方法》一书

深信科技创始人杨子江说：“基于交通流的泛化和驾驶员的智能化，如果模型足够好，由于随机因子的存在，场景运行10次，就相当于泛化了10个。”

不过，智行众维CTO李月认为，不能为了泛化而泛化。“我们一定要对被测的功能有深刻的理解，然后再去设计泛化方案，而不是为了泛化而泛化，更不能漫无边际地去泛化。场景泛化虽然是虚拟，但也要尊重现实。”

另外一位仿真专家也说：“说到底，仿真还是要为测试服务的，我们是已经在路上遇到了一个问题，然后看如何通过仿真解决，而不是说我先有了一个仿真的技术，然后看用在什么问题上吧？”

前文提到的一位仿真专家称，据他了解，目前还没有多少公司能真正做到场景泛化的自化，在大多数情况下，调参都是靠人工来完成的。“场景泛化能力，尽管很重要，但现阶段，还没有哪个公司真能做得很好。”

51 World车载仿真业务负责人鲍世强认为，做场景泛化，最重要的是要对自动驾驶仿真测试需要什么样的场景有一个深刻的理解。事实上，现在的问题不是生成的场景太少，实在是太多，而且有很多并不会真实发生，算不上有效的测试场景，这就是对需求理解不到位造成的。

有专家称，第三方仿真公司面临的最大挑战是，由于自己并没有亲自上阵做自动驾驶，因而对自动驾驶究竟需要什么样的仿真理解是不足的。

而那些有能力、对仿真需求理解比较深入的L4级自动驾驶公司，其实并没有足够的动力把场景泛化做得非常深入。因为，Robotaxi通常只在某个城市的一个很小的区域里跑，他们只要采集这一个区域的场景数据做训练和测试就行了，没有太大的必要去泛化出很多他们在相当长一段时间内都不会接触的场景。

鲍世强认为，蔚小理这些主机厂，真实道路数据比较多，对场景泛化也没有太强的需求。相反，对这些公司来说，比场景泛化更迫切的，是对场景做精细化分类管理，筛选出真正有效的场景。

轻舟智航的仿真专家也认为，随着车队规模的增加、来自真实道路的数据规模急剧膨胀，对仿真公司来说，如何充分挖掘出这些数据中的有效场景确实比做场景泛化重要得多。“我们也许会探索出智能化程度更高的泛化手段，能更快地对算法做大规模验证。”

杨子江说：“针对参数层面的泛化，例如车道数量、交通参与者的种类数量、天气，以及速度、TTC等关键参数，各家产生泛化场景的能力都差不多，但场景泛化能力的核心在于如何识别有效场景，过滤无效场景（包括重复的、不合理的）；而场景识别的难点在于，复杂场景需要识别多个对象之间相互关系。”

上述几位提到的“识别有效场景，过滤无效场景”，又被称为“场景提取”。

场景提取的前提是，先搞清楚究竟什么是“有效场景”。据几位仿真专家介绍，除法律规定应当测试的场景外，有效场景还包括如下两类：做系统正向设计时，工程师根据算法的开发需求定义的场景；测试中被挖掘出的那些“算法搞不定”的场景。

当然，有效和无效都是相对的，这跟公司的发展阶段、算法的成熟阶段有关——原则上，随着算法的成熟、问题的解决，很多原来的有效场景都会成为无效场景。

那大家是如何高效地筛选出有效场景的？

学术界有一种设想是：在感知算法里面设定一些熵值，当场景的复杂度超过了这些值，感知算法就把改场景标记为一个有效的场景。但这个熵值怎么设，存在很大挑战。

某仿真公司采用的是“排除法”，即如果一个原本表现非常好的算法在某一些泛化场景中“问题频发”，那这个场景大概率就是“无效场景”，可以排除了。

某主机厂的系统工程师说：“目前还没有很好的做场景筛选的方法。如果吃不准，那就放到云仿真上去算，总归是能算出来这些极限场景，然后再拿这些极限条件在自己的HIL台架上或者VIL台架上做验证，那么效率就会高很多”。

问题三：仿真究竟难在哪？

在跟很多仿真公司的专家及其下游用户交流的过程中，我们了解到，当下，自动驾驶的仿真，最难的环节之一是传感器的建模。

按智行众维CTO李月的说法，传感器建模可分为功能信息级建模、现象信息级/统计信息级建模及全物理级建模几个级别。这几个概念的区别如下——

功能信息级建模简单地描述摄像头输出图像、毫米波雷达在某个范围内探测目标这些具体功能，主要目的在于测试验证感知算法，但对传感器本身的性能并不关注；

现象信息和统计信息级建模是混合的、中间层级的建模，它包括一部分功能信息级建模，也包括一部分物理级建模；

全物理级建模，指对传感器工作的整个物理链路做仿真，其目标在于测试传感器本身的物理性能，比如，毫米波雷达的滤波能力如何。

狭义上的的传感器建模拟特指全物理级的建模。这种建模，很少有公司能做好，具体原因如下：

1.图像渲染的效率不够高

从计算机图形成像原理看，传感器模拟包括光线（输入、输出模拟）、几何形状、材质模拟、图像渲染等模拟，而渲染能力和效率的差别则会影响到仿真的真实性。

2.传感器的类型太多&模型精度、效率和通用性的“不可能三角”

仅有单个传感器的精度高还不够，你还需要所有的传感器都能同时达到一个理想的状态，这就要求建模有很广的覆盖度，但在成本压力下，仿真团队显然不可能对激光雷达做10个、20个版本的建模吧？另一方面，又很难用一个通用的模型去将各种不同款式的传感器表达出来。

模型的精度、效率和通用性是一个“不可能三角”的关系，你可以去提升其中的一面或者两个角两面，但你很难去持续性地把三个维度同时提升。当效率足够高的时候，模型精度一定是下降的。

车右智能的仿真专家说：“再复杂的数学模型也可能只能以99%的相似度模拟真实传感器，而这剩下的1%可能就是会带来致命问题的因素。”

3.传感器建模受制于目标物的参数

传感器仿真需要外部的数据，即外部环境数据跟传感器有强耦合，然而，外部环境的建模其实也挺复杂的，并且成本也不低。

城市场景下建筑物的数量太多，这会严重消耗用来做图像渲染的计算资源。有的建筑物会遮挡路上的车流、行人及其他目标物体，而有遮挡没遮挡，计算量是完全不一样的。

此外，目标物的反射率、材质，很难通过传感器建模搞清楚。比如，可以说一个目标是个桶状的，但它究竟是铁桶还是塑料桶，这个很难通过建模来表达清楚；即使能表达清楚，要在仿真模型中把这些参数调好，又是一个超级大的工程。

而目标物的材质等物理信息不清楚的话，仿真的模拟器就难以选择。

4.传感器的噪声加多少很难确定

某Tier 1仿真工程师说：“深度学习算法识别物体是一个从真实世界的传感器数据收集到信号去噪的过程，相比之下，传感器建模则是要在理想的物理模型的基础上合理地加入噪声，而其难点就在于噪音如何加得才能跟真实世界足够接近，以便既能让深度学习模型识别出来，又能有效提升模型识别的泛化。”

言外之意，仿真生成的传感器信号既要跟真实世界中的传感器信号“足够像”（能识别出对应物体），又不能“太像”（模拟corner case让感知模型能在更多情况下实现识别——泛化）。然而，问题在于，在真实世界中，传感器的噪音在很多情况下是随机的，这意味着，仿真系统如何去模拟这些噪音，是一个很大的挑战。

从传感器原理的角度看，相机建模的过程中还需要做相机模糊化（先生成理想的模型，然后加噪音）、畸变模拟、暗角模拟、颜色转换、鱼眼效果处理等而以激光雷达模型也可分为理想点云模型（步骤包括场景裁剪、可见判断、遮挡判断和位置计算）、功率衰减模型（包括对接受激光功率、反射激光功率、反射天线增益、目标散射截面、接口孔径、目标距离、大气传输系数、光学传输系数等子的设定）和考虑天气噪点的物理模型等。

5.资源的限制

智行众维CEO安宏伟提到了资源对感知虚拟仿真的限制：“我们要对传感器做完全的物理级建模，比如摄像头的光学物理参数等都要清楚，还需要知道目标物（感知对象）的材质、反射率等数据，这个工程量巨大——在有足够人力的情况下，一公里场景的建设周期需要差不多1个月。即使真能建好，模型的复杂度也极高，很难在当前的物理机上跑起来（实在太耗费算力了）。”

“未来，仿真都是要上云的，看起来，云端的算力‘无穷无尽’，但具体分摊到某个单一节点的单一模型上，云端的计算能力可能还不如物理机——并且，在物理机上做仿真时，如果一台机器的计算资源不够，可以上三台，一台负责传感器模型，一台负责动力学，一台负责规控，但在云上跑仿真，能用在单一场景单一模型上的算力并不是无穷无尽的，那么这个就限制了我们这个模型的复杂度。”

6.仿真公司很难拿到传感器的底层数据

全物理级建模需要把传感器的各种表现都用数学模型构建出来。比如，将信号接收器的某个具体性能、传播路径（中间受空气的影响、反射折射的整个链路）用数学公式表达出来。然而，在软硬件尚未真正解耦的阶段，传感器内部的感知算法是个黑盒子，仿真公司无法了解算法究竟是个什么样子。

全物理建模需要获取传感器元器件（如CMOS芯片、ISP）的底层参数，对这些参数做建模，而且，还需要知道传感器的底层物理原理，并对激光雷达的激光波、毫米波雷达的电磁波做建模。

对此，有一位仿真专家说：“要做好传感器建模，得深刻理解传感器的底层硬件知识，基本上相当于要知道怎么设计一款传感器。”

然而，传感器厂商一般不愿意开放底层数据。

智行众维CTO李月说：“这些底层参数你如果拿到了，拿着它去做建模，那你基本上就能把这个传感器造出来了”

智行众维CEO安宏伟说：“通常主机厂在和传感器供应商打交道的时候，不要说拿到材质物理参数这些细节，能拿到接口协议就已经很不容易了。如果主机厂足够强势，传感器供应商也积极配合，他们可以拿到接口协议，但也不是全部。连主机厂都很难拿到的东西，仿真公司就更难了。”

事实上，传感器的物理级仿真是只能由传感器厂商去自己去做的。国内很多传感器厂商更多地外采芯片等零部件来做集成，因此，能对做传感器物理级仿真的，实际上是TI、恩智浦这些上游供应商。

某商用车无人驾驶公司的仿真工程师说：“传感器的仿真难做，导致传感器选型的过程很复杂。我们要做传感器选型，基本上都是传感器公司先把样件寄给我，我们再把各种类型的都装上到车上去测试。如果传感器厂商能跟仿真公司合作，他们之间就可以把接口全部拉通，提供精准的传感器建模，那我们就可以以很低的成本获知传感器的信息，做传感器选型的工作量会大幅度减少。”

不过，51 World CTO鲍世强的说法是：“感知仿真现在还处在初期，还远远没做到需要把传感器里边的建模搞得那么精细的阶段。把传感器里边拆开建模那些东西，我觉得毫无意义。”

此外，按某无人驾驶公司仿真负责人的说法，传感器仿真做不了，并不等于感知的仿真完全做不了。

比如，硬件在环（HIL）可以接入传感器实物（传感器和域控制器，都是实物）来测试。接入传感器实物，既可以测试感知算法，也可以测试传感器本身的功能和性能。这种模式下，传感器是真实的，相比于传感器仿真，仿真精确度更高。

但由于涉及到配套硬件，集成起来复杂，而且这种方式依然需要传感器模型来控制环境信号的生成，成本也更高，因而，实践中很少使用这种方法。

附：自动驾驶仿真测试的两个阶段

（摘自公众号“车路慢慢”在2021年3月26日推送的文章《自动驾驶虚拟仿真测试介绍》）

考虑到近期的实际情况，自动驾驶仿真大致要分为两个发展阶段（当然这两个阶段可能并没有明显的时间界限）。

（1）阶段一：

在试验室和封闭试验场内对传感器的感知识别模块进行测试，在虚拟仿真环境对决策控制模块进行测试，仿真环境直接向决策控制模块提供目标列表。

这主要是因为目前对传感器的建模还有很多局限，从而不能进行有效（甚至是正确）的仿真。比如摄像头输出的图片较容易仿真，但是污渍、强光等特性仿真难度较大；而对于毫米波雷达如果建立精度较高的模型，则计算速度较慢，不能满足仿真测试的需求。

在试验室和封闭试验场可以对测试环境进行完整的控制和数据记录。比如布置不同类别、位置和速度的行人和车辆，甚至可以对雨、雪、雾和强光的环境要素进行模拟，并将传感器处理输出的目标列表与真实环境进行对比，从而给出对感知识别模块的评估结果和改进建议。

这么做的好处是，在传感器建模有很多局限的情况下，依然能够在仿真环境下对决策控制模块进行测试，提前享受仿真测试的优势。

（2）阶段二：

在虚拟仿真环境进行高精度的传感器建模，从而对完整的自动驾驶算法进行测试。

这样不仅可以在同一环境下进行测试，从而提高测试效率、测试场景覆盖率和复杂度；而且可以对一些基于AI的算法进行端到端的测试。

这一阶段的难点，一方面是前面提到的满足测试需求的传感器建模，另外一方面是不同传感器厂家和OEM厂家直接交互的接口很可能不一致（有些情况下可能并不存在）。

问题四：较低和较高等级自动驾驶仿真测试的差异是什么？

对低等级自动驾驶阶段而言，仿真只是一个辅助手段，而到了高等级自动驾驶，仿真便成为准入门槛了——L3需要做过足够里程的仿真才能上路。

某主机厂仿真专家说：通常，自动驾驶公司做L4仿真的能力更强一些，而第三方仿真公司做的仿真则以L2为主。那么，两个阶段的仿真的具体差异有哪些呢？

1.功能边界

轻舟智航仿真专家：“L2的产品定义成熟，功能边界清晰，因而，仿真服务商提供给各家主机厂的服务通用程度很高；而L4的功能边界在哪里，大家都还在探索，因此，客户对仿真的需求有很高程度的定制化。”

2.场景库的规模

深信科创创始人杨子江：“从测试场景的角度讲，L4因为ODD复杂度更高，场景库的数量级远高于L2。”

3.对场景复现度的要求

某主机厂仿真专家说：“L4仿真对场景复现度的要求更高，即道路中发现的一个问题，能不能在仿真场境下去复现；但很多做L2仿真的公司还没有思考过这个问题。”

4.对数据挖掘能力的关注度

低等级自动驾驶仿真，大家主要拼场景的真实度，高等级自动驾驶对数据挖掘的关注度更高了。

5.数据构成

51 WORLD 车载仿真业务负责人鲍世强：“L2对功能定义得比较明确，仿真可以以合成数据为主，以真实道路数据为辅；而到了L4阶段，数据驱动的重要性会更高，因此，需要以真实道路数据为主，以算法生成的数据为辅。”

6.感知

高等级自动驾驶车辆摄像头数量多、像素高，对仿真系统的图像渲染能力、数据同步能力及仿真引擎的稳定性都提出了更高的要求。

7.高精地图

智行众维CTO李月：“低等级自动驾驶基本都不需要高精地图，但高等级自动驾驶在目前阶段则高度依赖高精地图，这也是构建场景的时候就需要建数字孪生的原因之一，跟真实世界做对比。”

8.决策

智行众维CTO李月：“L2的方案对决策的策略逻辑及执行机构的测试关注比较多，但并不会把重点放在规划算法上，但到了L4方案中，对如何避障、如何绕路等路径规划算法的考虑就比较多。”

9.是否需要驾驶员模型

对低等级自动驾驶来说，系统不会完全控制车辆的行为，而只是起到辅助作用，因此，仿真公司在做场景设计的时候还要去设计很多驾驶员模型；而对高等级自动驾驶来说，车辆控制通过自动驾驶来实现，因此，仿真场景设计中就不需要设计驾驶员模型。

10.是否事先设定测试过程

对这个逻辑，公众号“车路慢慢”在一篇文中更详细的解释：

较低等级的自动驾驶面对的工况复杂度和工况范围比较小，或者说由于驾驶行为主要由人类驾驶员负责，自动驾驶系统仅需处理有限数量的、确定的工况即可；较高等级的自动驾驶的驾驶行为主要由自动驾驶系统负责，其处理的工况复杂度和工况范围很大，甚至不能提前预知。

基于两者的这个差异，较低等级自动驾驶可以使用基于用例的测试方法较好的进行测试，而较高等级自动驾驶则需要使用基于场景的测试方法。

基于用例的测试方法，即是预设测试输入和测试过程，通过查看被测算法是否实现预期的功能来评价是否通过测试。比如对ACC的测试，预先设定被测车辆和前车的初始车速，以及前车减速的时刻和减速度，查看被测车辆是否能够跟随减速停车。

基于场景的测试方法，即是预设测试输入，但不预先设定测试过程，只设定交通车辆的行为，给予被测算法较大的自由度，通过查看被测算法是否达成预期的目标来评价是否通过测试。比如对直线道路行驶的测试，预先设定被测车辆和前车的初始车速，以及前车减速的时刻和减速度，但是不限定被测车辆是通过减速还是换道超车的方式避免与前车相撞。

造成对于不同等级的自动驾驶功能需要使用不同的测试方法的一个原因是：低等级的自动驾驶一般能够分解为简单而独立的功能，可以把单一功能作为被测对象；而高等级的自动驾驶较难分解成简单而独立的功能，只得把整个自动驾驶系统或其相对较大的一部分作为被测对象。

11.产业生态

深信科创创始人杨子江：“从产业生态的角度讲，对L2，车企基本不会自研，而是直接采用外购方案，测试会以HIL甚至道路测试为主；而对L4的仿真，许多车企会倾向于从SIL开始自研。”

问题五：仿真中的“一天多少万公里”该怎么理解？

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

虚拟里程是指一个海量仿真平台在单位时间内并行仿真节点行驶里程的总和。单位时间内的仿真里程数取决于整个平台算力支持并行运行的节点数和不同仿真场景复杂度下的超实时指数。

简单来讲，一个仿真节点就是一辆车，就是仿真平台能支持同时并行跑多少辆“测试车”。

据智行众维CEO安宏伟解释：简单来讲，假如一个仿真平台有100台GPU服务器的算力，每台部署8个仿真实例，则这个仿真平台就拥有同时并行800个仿真的能力。仿真里程就取决于每个实例每天跑的里程数了。

一台GPU服务器上能跑多少个实例，取决于GPU的性能和仿真求解器能不能在一台服务器上并行仿真。

安宏伟说：“我们云仿真平台的仿真节点，实现了多种部署方式，能够灵活满足客户的各种云资源的状况，都能实现大规模、弹性的节点部署。目前我们在苏州相城建设的云仿真平台已实现过超过400节点的部署。”

结合每个实例每天跑的里程，就可以大致计算出仿真平台上每日的仿真总里程。如果一个实例（虚拟车）平均每小时跑120公里，每天跑24小时，那每日就是将近3000公里，如果有33个实例，那该台服务器上每天就差不多有10万公里。

但据安宏伟的说法，业界平时所说的仿真“每天多少万公里”其实是不太严谨的。“需要结合合理的仿真测试方案和海量的场景作为支撑，在场景的覆盖度和有效性上进行不断地扩展，最后能够跑出来有效的场景才是根本。”

问题六：超实时仿真

在采访中，笔者反复问到一个问题：仿真平台上跑的车，跟真实世界中的车，是在同一个时间维度上的吗？换个说法：仿真平台上的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仿真测评体系里就包括这类（组）场景。基于这类场景可以进行虚拟仿真下“接管”的测试。

问题八：衡量一个公司的仿真能力强弱，最关键的指标是什么？

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

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

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

本文写作中引用了大量来自微信公众号“车路慢慢”的干货知识。该公众号的作者李慢慢是仿真工程师，该号聚焦于仿真专业知识的梳理，推荐对这个赛道感兴趣的朋友关注。