再谈自动驾驶测试场景(仿真)

在知乎上,黄浴博士提出了下面这个问题。

自动驾驶研发中模拟仿真的作用有多大?感知定位模块、行为建模预测以及规划控制,甚至包括端到端系统,哪些会收益于模拟仿真?感知系统模拟数据和真实数据的差距可以忽略吗?采用GAN能否弥补模拟数据到真实数据的跳跃?规划控制方法甚至端到端系统是否容易在模拟仿真平台验证?像谷歌所所说的fuzziness,可以帮助产生大量的极端情况验证新算法吗?

在答案列表里我看到了一篇非常喜欢的回答。经允许后转载至专栏中,与大家一同分享。转载过程中对原答案略有整理,主要是提取出了关于场景的部分,并基于自己的理解增删了部分内容。原答内容更为丰富,可直接点击以下链接阅读。

作者:明月
链接:https://www.zhihu.com/question/367321729/answer/1165343444

自动驾驶的行业先锋和领头羊Waymo对仿真测试非常上心,从公布的测试数据来看,截止2020年1月,Waymo的道路实测20,000,000(2000万)英里,仿真测试100,000,000,000(100亿),这完全是两个数量级。如果自动驾驶的行业先锋和领头羊Waymo对仿真测试如此上心的话,我们有理由认为仿真在自动驾驶的研发中很重要,更大胆的推测——基至是核心要素之一。

仿真到底有何用?除了低成本和可针对极端情况进行测试之外,还主要体现在自动驾驶进入市场的三个阶段,分别是算法研发、系统测试和评测机构安全性验证。算法开发过程中的可重复性、可配置性、基于人工定义、具有一定覆盖率的测试用例的定义和执行;系统测试过程中的自动生成、高覆盖率的测试用例的定义和执行;评估和评测机构基于“安全”导向对测试用例的定义和执行三个阶段相辅相成、缺一不可!

针对算法研发的仿真

针对算法研发的仿真测试用例定义可比喻为教科书练习题。这相对而言是最基础的仿真应用场景。在这一方面,商业仿真软件中PreScan和VTD的市占率较高。它们拥有相对完备的基于Scenario测试的工具链,包括Vehicle Dynamics,SensorSimulator(主要是Camera)、DatabaseBuilder、ScenarioEditor、ScenarioExecutor和UI,支持自定义地图、创建3D数据库、算法嵌入、自定义并执行场景等基于场景测试核心工具集。不过因为时代的局限性,包括这两个工具在内的大多数市面上的成熟仿真工具用户对象并非是高等级自动驾驶,而是ADAS。整体的工作流可概括为:手动创建地图和3D数据库、手动创建Sc场景、对被测自动驾驶系统行仿真测试,整体逻辑类似单元测试。

此阶段的测试用例类似教科书每章后的练习题,经过专业人员精心挑选,旨在用最小的精力做最大的产出。这种自定义的仿真测试方法在算法研发阶段,可以基本满足ADAS和自动驾驶的需求。此外一个从路测采集的数据中数字化Scenario的工具在这一阶段也能发挥很大价值!对于ADAS,由于其复杂度较低,可以通过专家知识设计具有足够高的测试覆盖率的场景库,因此以上测试方法在系统测试和安全性验证阶段也都可担当仿真测试用例来源的主力。但对于高等级自动驾驶系统测试,来源于人工创建以及只基于路测数据的场景还存在一定局限性。

针对系统测试的仿真

针对系统测试的仿真测试场景/用例可比喻为五年高考三年模似。系统测试的重点在于测试用例的冗余度、持续性和可回归性。当自动驾驶系统1.0发布之后,怎么说明系统的功能边界?怎么能够持续的添加重复性足够低的测试用例?如果发现并解决了一个bug,怎么确定当前改动没有破坏已有功能?答案是完备的Scenario数据库和以及具体场景(concrete scenario)自行化生成和执行。

在此需要特别注意的是,基于PEGASUS的功能场景(functional scenario)-逻辑场景(logical scenario)-具体场景(concrete scenario)体系分析,该场景库中的场景数量可能是一个天文数字,因为这是一个乘法游戏,很容易造成场景参数空间爆炸。假设功能场景的数量为基数$N$,针对每个逻辑场景,我们能获得$n_1n_2 \dots n_i$个具体场景。($n_i$是关键场景的离散维度,车道数离散型参数取值较易获得;对于行人过马路时的速度等连续型参数如过马路时速度,进行合适程度的离散化是一个挑战,太粗的离散化可能会导致在测试过程中存在未发现的问题;太细的离散化会产生不必要的测试用例。)总之,场景库中的具体场景个数$S=Nn_1n_2\dots n_i$。假设功能场景有200个,每个功能场景有6个关键参数(保守估计)、每个参数取10个离散维度。则具体场景数量2亿个,单次仿真按30s算,60亿秒=190.26年。当前,在实际测试过程中,可通过此方法降低具体场景的数量,但总数量的恐怖仍可见一斑。

在此时仿真软件虽然是上述测试的基础,但本身已经不是主战场了,更核心的需求是云仿真、场景执行的性能及并行性和评测系统。另外,关于这方面也可多关注专栏中提到的OpenX系列,这些相关的仿真标准在未来可能是构建这些场景库的基础。

总的来说,系统测试就像是五年高考三年模拟一样,一方面要把往年的真题(已有的测试场景)收罗进来,另一方面又要根据量纲推除出新(泛化出新的测试用例),甚至能成功压题是最好的。压谁的题?当然是高考啊!

针对评测机构安全性验证的仿真测试

安全性验证可以比喻为高考。有权进行安全性验证的是各国的授权机构,像德国的TUEV和中国的中汽研。这些机构的着眼点是“安全”的定义,这个宏大的命题不光涉及到技术问题,还涉及到论理和法律问题。怎么做自动驾驶验证阶段的安全性测试,现在还没有公论,但据推测,基于场景和基于里程的测试方法都是需要的。

场景数据库作为底线可以保证测试的回归性;基于里程的测试增加了不确定性,是考卷最后的几道大题。此处提到的基于里程的测试并非指实车测试,而是基于仿真的里程测试。让被测自动驾驶系统在虚拟环境里中运行特定的里程,然后分析测试过程、记录关键点并进行评分。每次测试原则上需有一定的随机性,表现在加载的地图、3D的数据库、路上的Agent驾驶行为的随机上。其中的难点在于如何准确高效地模拟驾驶员的行为,也即Micro Traffic Simulation上。关于这一点,学术界有一套“基于规则-基于学习”的方法,后续会继续介绍。总之,授权机构的安全性验证阶段就像高考里的最终递给你的那张考卷一样,使用仿真能大大降低考试时间。

总结

在自动驾驶领域,算法研发、系统测试和安全验证三个测试阶段中,仿真都是必不可少的,这已经成为了国内外主要玩家的共识。而传统的基于路测数据、现有事故数据库和人工创建的有限的Scenario的测试方式在自动驾驶的测试领域已经远远不够了。自动驾驶公司和相关验证机构应该致力于创建一个具有高度覆盖率的Scenario数据库。除了兼容Euro NCAP的Scenario数据库并研究Logical Scenario的参数化,新一代仿真工具也应该专注于如何快速产生大量的新的Scenario,并能够证明新产生的Scenario是新的有意义的,而在此过程中Micro Traffic Simulation是重中之重。

0%