浅谈自动驾驶仿真-场景库的那些事

厚势汽车 4天前

以下文章来源于仿真秀App ，作者李慢慢

仿真秀App
仿真秀App

提供专业仿真知识服务，搭建沟通桥梁，专注内容生产与分享

图片

图片

导语

自动驾驶仿真有三个要素：场景库、仿真平台、以及结果评价。关于场景库的创建，学问很多：什么是场景库？为什么要创建场景库？车辆行驶场景无穷无尽，如何对其进行抽象提炼和归类管理？如何根据真实场景快速提取虚拟场景？如何利用场景库快速创建测试用例？如何定义场景库统一的标准？等等。这篇文章试图找到一些答案。


一、为什么要进行基于场景的仿真测试？
先说点宏观的东西：随着L3级别自动驾驶自动驾驶的开发，传统汽车的测试方法（如场地测试和道路测试）已经不能满足自动驾驶汽车测试的需求，基于场景的虚拟仿真测试方法可以大幅优化测试效率、降低测试成本、提高场景覆盖率、具有巨大的技术优势，是未来自动驾驶汽车测试试验的重要手段。
再说说具体的做法：目前主流的自动驾驶功能的测试方法有两种，一种是基于里程的测试，一种是基于场景的测试。前者需要车队经过漫长的时间在真实道路中进行测试，后者则是从真实世界中抽象出各种不同的驾驶场景，在仿真环境中进行模拟测试。后者的好处不言而喻，效率高、成本低、场景覆盖率高、可重复性高。缺点嘛也有，真实度不够，所以产品最终也还是需要进行至少一次真实道路测试的。
图片
有一组数据，是来自美国兰德公司的测算，能更进一步帮助我们理解基于里程测试的难度：“在95%的置信度水平下，要证明自动驾驶车辆相比于人类驾驶能够减少20%的交通事故死亡率，则需要进行50亿英里的公共道路测试，如果采用100辆车组成的车队每年365天每天24小时不间歇地以25英里每小时的平均速度进行测试的话，大概需要225年。”
看到这里，你可能会想，既然基于里程测试这么费时，为什么还有waymo等公司组建车队还在不断测试？这里就要谈到另一个基于场景测试方法的场景来源问题了。
二、场景从哪儿来？
先说答案：场景由真实数据采集而来。对于场景数据的采集，一般来源包括自然驾驶场景数据、事故现场场景数据和测试过程场景数据。其中第一种数据能够全面覆盖各类场景，也更具有采集可行性，因此，自然驾驶数据的采集是场景采集的主要手段。这也就是为什么还有车队在道路上进行自动驾驶测试的原因了，他们其实不只是在测试，也是在采集。
场景的采集内容为了尽可能全面的描述交通细节，一般都是以摄像头为主采集图像，辅以毫米波雷达、激光雷达等收集交通参与者信息，并实时采集主车的速度加速度等动力学参数等，共同汇聚，形成场景数据。
图片
三、采集到的数据需要经过哪些处理？
传感器采集到的数据并不是直接能用的，有很多无效数据需要清洗，也要从中辨别出有效的场景，某些特定的要素要对其进行标注，不同传感器之间的数据需要实时同步和融合等等。因为数据量庞大，也因此诞生出一些场景处理的“工具链”，比如场景提取软件、场景标注软件、场景生成软件、场景转换软件等。
图片
四、目前基于场景仿真测试的关键问题是什么？
鉴于自动驾驶的仿真测试的巨大优势，各个OEM或者独角兽公司都在积极布局仿真测试的能力，也因此出现百花齐放的盛况：软件层出不穷，方法各式各样，数据格式万千。。。这就导致了从研发到测试，从功能场景到测试用例，从传感器到功能模块各阶段的数据和接口等都缺乏统一的标准。没有标准的引导，就如没有法律的制约下的社会，天下大乱。
图片
五、什么是场景库？
场景是对现实驾驶场景的简化抽象，比如，“天气晴朗，城市辅路中，主车以30km/h的速度直行，右侧相邻车道的目标车以40km/h的速度切入本车道，并保持直行。”就是一个简单的场景描述，针对主车的每一种功能（如AEB，ACC等）都必须在这一个场景下进行测试并通过。那么驾驶场景千千万，我们都对其进行抽象，因此就形成了“场景库”：一种按照某种逻辑方式保存的各个种场景要素的数据库。场景库是自动驾驶测试的宝库，自动驾驶的所有功能都必须经过千千万的场景的测试并通过，历经“磨难”方能出师。
图片
六、场景库怎么管理？
在上文介绍的简单场景中，随意更改一个因素，都会是一个不同的场景。比如，天气晴朗改为天气大雾，也比如城市辅路改为乡村小路，又比如主车直行改为右转等。这样我们就大概懂了，不同的场景之间可能存在极大的相似度或者重复度。所以，我们需要将这些因素一个一个分别剥离出来，单独存放，然后组合调用，这样我们就能依据不同因素的定义快速地组建出一个特定的场景了。
那么又该如何管理这些因素呢？目前业界最著名的分类方法是ISO-34502提出的结构化场景的六层模型分类方法。栗子如下：
图片
图：ISO34502的六层场景模型
图片
图：依据六层模型及描述具体场景实例
图片
图：结构化场景的要素展开分类
图片
图：目标物的分类
图片
图：车辆目标物的行为定义及组合
图片
图：场景分析及快速模拟示例
七、场景库标准-OpenX
ASAM（德国汽车工业标准协会）推出的OpenX系列仿真标准，涵盖从研发到测试，从传感器到功能模块各阶段的数据接口标准，支持整车厂、供应商、技术服务商以及自动驾驶企业的开发和测试需求，促进标准化和未来产业发展，使其成为目前业界大部分企业采用的自动驾驶和仿真场景数据格式的官方标准。
OpenX系列包含以下内容：
图片
图片
Open DRIVE定义了静态地图的标准格式，包含以下内容：
图片
可以简单来看下其定义的数据的格式：
图片
八、场景库标准-ISO34502
上面其实已经讲到过了，ISO-34502是一个关于场景的结构化分层的标准，用来帮助企业进行场景库的创建以及管理的。我在猜，最重要的是为了促进国家级场景库的创建吧？试想，今后所有的企业以及测试机构都用同一套场景库，会是非常方便的一件事。比如中汽研i-VISTA新公开的场景库（官方可下载），可能就是这样一个东西。
图片
图：ISO34502的六层场景模型
关于场景库，其实还有很多内容，比如，场景库软件、数据处理的细节、工具链开发等。因为李慢慢本人也是一个计划转岗的人，对于本文的内容，也大都是自学自悟，难免有不妥之处，还请大佬路过多给两句点评，感激不尽。
从CAE仿真转战自动驾驶仿真，我本以为仅仅是从被动安全转到主动安全，换了些软件来做类似的事而已。开启自学模式，断断续续大半年，才逐渐认识到，两者真不可同日而语。
首先是重要性，相比于CAE体系的成熟，目前自动驾驶仿真还仅仅是处于起步阶段的婴儿，标准不成熟，软件不成熟，技术也不成熟，但自驾仿真还是依然重要，战略核心地位的那种重要，因为鉴于自驾的危险性和高成本，必须由自驾仿真来完成功能安全的验证和测试，所以有过"CAEer即计算器"的经历的我，马上就认识到，自驾仿真者最起码能获得更多的尊重。
其次是知识体系的不一样，简单来说CAE仿真是【有限元法+力学】的知识体系，而自驾仿真则是【汽车理论+控制理论+概率统计+机器学习+大数据分析】等一系列知识体系的综合。编程也是自驾仿真的必备能力，几乎每一个公司的招聘JD中都要求应聘者熟悉C语言/C++/Python，可见一斑。
也正是因为知识体系不一样，我才在一边学习的同时，也一边在输出，写了些浅薄的文章，希望有朝一日，也能构建出自己的知识系统，帮助到可能如我一般的后来者吧。
本文完。
图片
END

图片