自动驾驶仿真，是该基于场景评价，还是基于功能评价？

大家好，我是李慢慢。

如题。这个问题，曾问懵了很多人，哪怕是自动驾驶的仿真工程师。

倒不是问题有多难，而是这个问法比较新颖，涉及到新的词组定义。

所以，开篇先来申明一下定义，与大伙儿保持了共识再说。

先说下背景：

众所周知，自动驾驶仿真是用来测试算法的，测试完是需要给出结论的，结论里是需要对具体的场景仿真结果给出评价的。

评价时肯定需要将一些信号提取出来，可这个信号从哪儿来呢？

仿真测试中，算法模块和仿真软件同时运行，各司其职，算法模块收集来自仿真软件的车辆信息及环境信息等，根据一系列神秘运算，给出控制指令到仿真软件里，控制车辆的行驶。

定义和分类：

所以，评价的信号，可以从这两个模块分别提取，如果是从算法模块提取出来的话，就称为基于功能的评价；如果是从仿真软件提取的信号，就称为基于场景的评价吧。

如果将上述定义进行扩展，按照评价方法将仿真方法进行分类，可以把仿真分为两类，即基于功能的仿真，以及基于场景的仿真。

之所以这么分，是因为不同公司确实做法不一样。有些是基于功能的仿真，有些则是基于场景的仿真。

来举一个LKA的例子：

以LKA（车道保持辅助）功能的仿真评价为例。让我们假设，评价方法是看车辆在某个场景中是否压线，压线了則评价为Failed，没有压线則评价为Passed。

如果是基于功能的评价，我们会从算法端（数据接口）获取这个是否压线的信号，它可能是摄像头模块识别计算算出来的，也可能是定位算法检测到的，也可能是数据融合后得到的。具体是怎么得来的，是由算法人员来定义的。

如果是基于场景的评价，我们会直接从仿真软件里输出这个信号，有可能仿真软件自带这个信号，也有可能需要仿真人员写代码进行一定的几何判断来确定。但不管如何，这个信号是仿真是由仿真人员来定义的。

两种评价方法，孰优孰劣？

这么发问自然是落了下成，既然仿真界出现了这两种方法，存在即合理，那肯定是各有优劣的。

基于功能的仿真，提取的信号来自算法模块，那么仿真人员提交的报告中，对于结果的评价，算法人员更容易理解，从而直接根据该信号去排查算法中可能的问题。而且这种评价方法，简单粗暴，往往能直指问题核心。因为评价信号是算法模块定义的，因此仿真的结果更容易被双方理解，从而你好我好大家好。在自动驾驶算法模块测试初期，以及单一ADAS功能，这种方法比较适用，但它有一个短板，扩展性差。

试想一下，一旦算法模块的接口发生变化，仿真平台都需要重新对接一遍，而且针对不同功能，还需要拉出来不同的信号来评价，这实在是太麻烦了。对于快速的软件迭代来讲，仿真测试反倒成了拉后腿的了。

所以，是有必要让算法和仿真解耦的。

任由你算法模块如何迭代更新，我仿真测试都使用同一个评价标准。任由你测试的是单一ADAS功能，还是ADS全自动驾驶功能，我仿真还是同一套场景库同一套评价方法。

他强由他强，清风拂山岗。

他横由他横，明月照大江。

让算法和仿真解耦，仿真模块评价的信号由仿真模块自行提供。这个其实和实车测试非常相似，我们仅基于车辆的表现来评分，不care什么乱七八糟的算法信号。

所以，实际使用中如何应用两种评价方法呢？

1、算法迭代初期，基于功能的测试完成初步测试，此时仿真与算法融为一体。此前的文章（如下），其实都是基于此而有所想。

2、算法迭代后期，基于场景的测试，完成大规模测试，寻找corner case，完成充分测试，此时仿真与算法解耦，各司其职。

以上，仅为个人偶有所感，未经任何验证，如哪位道友更好的idea，欢迎前来battle，瑞斯拜。