广告
从功能场景到逻辑场景：基于关键字的场景描述细化方法
2020-09-01 23:12:44· 来源：同济智能汽车研究所
编者按：智能驾驶汽车在开发和测试中用到的场景主要有三种类型：功能场景（Functional scenarios）、逻辑场景（Logical scenarios）和具体场景（Concrete scenar
编者按：智能驾驶汽车在开发和测试中用到的场景主要有三种类型：功能场景（Functional scenarios）、逻辑场景（Logical scenarios）和具体场景（Concrete scenarios）。功能场景在概念阶段可用于项目定义、危险分析和风险评估，逻辑场景是基于状态空间变量对功能场景的进一步详细描述。在测试过程中，往往需要将功能场景转换为逻辑场景，并转换为可用于相应仿真环境的数据格式（如VTD中的OpenDRIVE和OpenSCENARIO），本文主要介绍了一种在模拟环境中自动描述基于关键字的场景描述方法，并为测试用例生成提供了依据。
摘要：基于场景的开发和测试过程是验证自动驾驶功能的一种很有前途的方法。为此，必须在开发过程中以可跟踪的方式生成场景。在开发的早期阶段，将要开发的项目的操作场景通常以抽象的语言方式描述。在辅助模拟测试过程的范围内，这些语言描述的场景必须转换为状态空间表示，并转换为可用于相应仿真环境的数据格式。目前，详细描述场景的这一步需要大量的手动操作。此外，由于多个作者以及场景参数之间的许多约束，无法保证语言描述场景的标准化解释和数据格式的一致转换。本文提出了一种在模拟环境中自动描述基于关键字的场景描述方法，并为测试用例生成提供了依据。首先，将基于关键字的描述转换为参数空间表示。同时，关于参数值的选择和组合的约束被记录在下面的过程步骤中（例如进化或随机测试方法）。第二步，将参数空间表示转换为仿真环境所需的数据格式。以德国高速公路为例，将其转换为OpenDRIVE（道路描述）和OpenSCENARIO（交通参与者和环境条件描述）两种数据格式，在模拟环境虚拟试驾中执行。
1 前言
在引入自动驾驶功能之前，必须保证特定的安全级别，驾驶员辅助系统一般通过基于距离的方法进行测试。对于自动化程度更高的系统，Wachenfeld和Winner[1]提出了66.2亿公里的测试里程，以假设（50%的可能性）证明这些系统的性能是人类驾驶员的两倍。因此，Wachenfeld和Winner得出结论，对于更高级别自动化系统的发布，基于距离的方法在经济上是不可接受的。因此，Schuldt[2]提出了一种基于场景的方法作为一种有前途的替代方法。
在基于场景的方法中，场景生成是安全论证的敏感步骤，对于系统的发布至关重要，因此必须系统地导出和记录这些场景，而且它们必须沿着开发过程进行跟踪。为此，Menzel等[3]提出了场景表示的三个抽象层次：功能场景、逻辑场景和具体场景。功能场景以语言方式描述，这样专家就可以在开发过程开始时讨论场景；逻辑场景指定场景的参数并定义参数范围；具体场景为每个参数指定一个具体值，是可重复测试用例的基础。因此，这些抽象层次支持概念阶段的活动、系统开发以及基于V模型的开发过程的测试活动，并为开发过程中场景的结构化生成和使用奠定基础，如图1所示。
图1 V模型开发过程中的场景[4]；HARA：危害分析和风险评估
为了自动生成功能场景，Bagschik等[5]提出基于知识的方法，生成的场景使用定义的词汇表和语法进行描述，每个场景由起始场景和结束场景组成。对于从功能场景到逻辑场景的转换，基于关键字的表示必须在参数空间表示中进行详细说明，并转换为仿真环境的格式。在模拟顺序控制的范围内，该步骤还包括起始场景和结束场景之间的交通参与者交互的说明。为了根据数据格式一致地模拟道路和交通参与者之间的交互作用，必须考虑参数和参数值之间的关系和依赖关系。
目前，场景细化和场景转换的步骤需要大量的人工操作，特别是在多作者的情况下，无法确保语言场景的标准化解释和符合模拟环境数据格式的一致表示。本文以德国高速公路场景为例，提出了一种从基于关键字的场景描述到参数空间表示的自动转换方法，并将其转换为仿真环境的格式。在参数空间表示中，对场景中元素和参数之间的关系和依赖关系进行了建模，这是为了确保交通参与者的交互根据各自功能场景的规范进行解析，并确保场景的实现与数据格式一致。对于道路网的表示，采用OpenDRIVE的数据格式；对于交通参与者和环境的表示，采用OpenSCENARIO的数据格式。
本文基于早期的德语版本[6]，结构如下：第二节提供了基于知识的场景生成和基于所选相关工作的场景细化的背景；第三节介绍了一种方法，详细描述用于在模拟环境中执行的基于关键字的场景，并作为生成测试用例的基础。在第四节中，评估了用于详细描述场景的工具。最后，第五节指出了该方法的局限性，并给出了一个简短的结论。
2 概率逻辑推理综述
Schuldt等[7]提出一个基于场景的测试方法以及一个用于构建场景的4层模型。Ulbrich等[8]提供了术语scene、situation和scenario的定义。Menzel等[3]使用这些定义作为基础，并使用ISO 26262标准的例子，使用不同的符号来表示开发过程中的场景。因此，Menzel等[3]提出场景的三个抽象层次：功能场景、逻辑场景和具体场景。在本文中，术语参照Ulbrich等[8]和Menzel等[3]使用的定义。
目前，生成场景的过程有两种方法——数据驱动和知识驱动，使用Menzel等[3]的术语，可以比较两种方法，如图2所示。
图2 知识驱动和数据驱动的场景生成方法比较
数据驱动方法的主要思想是收集测量数据并识别和分类发生的场景。De Gelder等[10]提出了一种为虚拟测试（如硬件在环测试）生成真实测试用例的方法。为此，De Gelder等[10]收集真实场景，将这些场景参数化并存储在数据库中。对于现实生活中的场景，假设它们可以完全由感官和外部信息（如数字地图和天气数据）构建，并举例说明了参数化方法，但表示各自场景所需的参数没有详细描述。在将参数化的场景存储到数据库中之后，数据分布适合对场景参数进行建模。这个表示描述了要测试的参数空间，包括每个参数的概率密度函数。遵循Menzel[3]等人的术语，这个表示相当于一个逻辑场景。根据逻辑场景建模中的分布，de Gelder等[10]对新的（具体的）场景进行采样，并在模拟环境中执行它们，这种抽样构成了蒙特卡罗模拟的基础。然而，De Gelder等[10]的方法和类似的方法被归类为数据驱动流程，因为所有生成的场景都是基于真实场景的，并且不会执行场景的语义变化。
Pütz等[11]提出了一种类似的方法，该方法描述了工具链的概念，用于收集数据（例如测量数据和交通模拟数据），计算用于描述场景的指标，并将其作为逻辑场景进行聚类，提供这些逻辑场景作为生成测试用例的基础。
Waymo LLC[12]提出了一种测试方法，其中记录的部分试驾可以在模拟中再现，其中的参数如描述交通参与者的参数可以改变，这种方法需要试驾的测量数据以及高精度数字地图。第一步，该方法将测量数据转换为可在仿真环境中执行的基于场景的表示；第二步，这些场景被泛化为后续参数变化的逻辑场景，用于生成具体场景的各个测试用例。
这三种方法来自于De Gelder[10]和Pütz等[11]，Waymo LLC[12]遵循虚拟测试范围内数据驱动测试过程的理念，对基于形式化知识的合成道路或场景的生成不进行描述。对于那些纯数据驱动的方法，有几个挑战。首先，测量数据并不能描述场景的所有方面，与De Gelder等[10]根据感官和外部数据构建完整场景的假设相反，场景中会有一些被测量车辆的传感器感知不到的元素（例如，由于距离限制）。此外，当将基于场景的表示归纳为逻辑场景时，必须进一步考虑知识来指定参数依赖关系。例如，在超车情况下，可以选择不同的车辆速度，但超车车辆的速度必须始终高于被超越车辆的速度。在测试用例生成中，基于逻辑场景生成具体场景时，必须考虑这些约束。最后但并非最不重要的是，到目前为止，数据驱动方法没有提供操作设计领域遇到的问题的信息，这些方法只对测试车辆遇到的情况进行分组，并改变参数值。根据操作设计领域，没有给出对所有可能的集群（语义变化）的引用。因此，这些基于数据的方法没有提供关于情景多样性的信息。
为了弥补上述问题，可以将数据驱动方法与知识驱动方法相结合，其主要思想是根据现有知识生成场景，如监管建议，然后使用从测量数据中收集的信息来扩展这些合成场景。作为生成功能场景的第一步，可用知识必须是结构化的，用语言描述的，在语义层次上变化的。因此，Bagschik等[13]提出了一种基于知识的本体生成起始场景的方法。为了构建本体中所表示的知识，Bagschik等人基于Schuldt等[7]的4层模型提出了5层模型。在后来的文章中，Bagschik等人扩展了基于知识生成起始场景的概念，并以德国高速公路为例实现了基于知识的运行场景生成，每个操作场景包括起始场景和结束场景，在语义层（功能场景）上进行语言描述，并使用Web本体语言（OWL）表示。为了将这些场景作为在虚拟测试范围内生成具体场景的基础，Bagschik等人生成的功能场景必须转换成可在模拟环境中执行的符号。
对于自动驾驶功能的模拟测试，可提供多种模拟环境，例如dSPACE GmbH的ASM Traffic、IPG Automotive GmbH的Automotive或VIRES Simulationstechnologie GmbH的虚拟试驾（VTD）。这些仿真环境使用不同的数据格式来描述场景。
本文提出的工具将功能场景转换为仿真环境虚拟试驾（VTD）的数据格式。对于道路网络的描述，VTD要求数据格式为OpenDRIVE；对于交通参与者和环境的描述，VTD驱动使用基于事件的数据格式OpenSCENARIO。
有些文章描述了基于事件的场景表示。Bach等[14]描述了概念和原型实现，用于抽象表示具体场景，特别是交通参与者之间的交互，这个概念是基于将每个场景划分为多个行为和事件，实现了与数据格式OpenSCENARIO类似的交通参与者交互结构。Xiong[15]提出了一种模拟环境中基于知识库的场景编排，在本体的帮助下表示场景中动作和事件的序列，本体详细描述了道路网络的要素和交通参与者之间的交互作用以及要使用的模型（例如驾驶员模型），如有必要可根据驾驶环境的功能和顺序调整驾驶场景，该方法明确定义了被测车辆，使用本体来控制其他交通参与者完成场景中定义的场景。因此，Bach和Xiong为具体的场景和测试用例提供了基于事件的记法，但没有描述将基于关键字的场景描述自动细化到基于事件的场景描述作为测试用例生成的基础的方法，然而，这两篇文章都有助于虚拟测试范围内逻辑场景的结构化和建模。本文介绍的概念和实现使用了Bagschik等生成的功能场景作为场景细化和转换为OpenDRIVE和OpenSCENARIO数据格式的起点。
3 细化在模拟环境中执行的基于关键字的场景描述
从基于关键字的场景描述到用于在仿真环境中执行的格式的转换分两步实现，如图3所示。流程的起点是使用功能场景，每个功能场景都是基于关键字的语义描述，并使用Web本体语言（OWL）进行建模。Bagschik等[5]描述了功能场景的生成。
图3 场景转换过程概述，矩形代表工作产品，圆角代表过程步骤
在细化中，功能场景被导入并转换为参数空间表示，各个功能场景的每个术语（如“车”或“跟”）通过参数详细指定，通过检查哪些参数必须在模拟的数据格式中定义来表示相应的元素，从而推导出参数。此外，还对参数之间的依赖关系以及参数值选择的约束进行了建模。这些依赖和约束产生于功能场景中指定的参数和交互作用的物理关系，以及模拟数据格式的要求。
在格式转换中，对于每种数据格式，需要从参数空间表示中提取所需的信息，并转换成相应数据格式指定的语法。此外，选择参数值的约束被记录为附加文件中的一组规则，给接下来的过程步骤（例如测试用例生成）提供生成有效参数值组合的基础。然后，对于每个参数，根据定义的规则集选择一个默认值。转换后的场景确定要更改的参数，形式化它们在模拟环境中执行的意义，并为每个参数定义一个符合规则的有效的默认值。因此，根据Menzel等[3]的定义，提取的场景为逻辑场景奠定了基础。本文没有介绍根据定义的测试概念为每个逻辑场景生成具体场景的代表性样本。
A. 场景细化
语义场景表示是场景细化的基础，采用OWL数据格式进行建模。功能场景利用定义的词汇以及词汇之间的语义关系来描述道路等级、交通基础设施、可移动物体和环境条件，道路等级和交通基础设施的词汇由Bagschik等人[5]定义，参考德国标准《如何修建高速公路》[16]。对于交通参与者之间的相互作用的描述，Bagschik等人[5]使用Reschka[17]基于Tölle[18]和Nagel and Enkelmann[19]定义的策略。
细化的第一步是根据5层模型[13]构造用于场景描述的术语，每一项都用参数来扩充，这些参数详细地指定了相应的元素，如图4所示。描述每个元素所需的参数取决于仿真环境的数据格式。因此，在本文的研究范围内，参数是从仿真环境VTD所使用的OpenDRIVE和OpenSCENARIO的数据格式规范中得来的。数据格式OpenDRIVE描述了道路网络，从而描述了5层模型的前三层。数据格式OpenSCENARIO描述了交通参与者之间的交互作用以及环境条件，从而描述了5层模型的第4层和第5层。
图4 Bagschik等[13]基于Schuldt[2]提出的5层模型到结构场景，蓝框表示功能场景中的关键字，Y形方框根据模拟的数据格式表示参数。
在OpenSCENARIO中，交通参与者的轨迹通过动作（策略和模拟控制的进一步命令）和触发这些动作的事件来描述。在功能场景中，每辆车的运动通过其在起始和结束场景中与其他交通参与者的相对位置以及要执行的策略来描述。为了借助OpenSCENARIO中的参数来表示功能场景中定义的策略，必须将交通参与者的交互转换为基于事件的表示，如图5所示。因此，在功能场景中定义的策略是通过附加的设计元素（如动作和事件）来详细说明的。
图5 通过基于事件的表示法对交通参与者之间交互的时间顺序的规范
细化的第二步是建立元素之间的关系和约束以及元素的参数，已经确定了三类关系，用于场景描述：排列关系、对象依赖和参数依赖。这三种关系相互独立，关注场景的不同方面。
排列关系描述了元素之间的相对位置。为此，场景的所有对象都表示为图表结构中的节点。在图表里边的帮助下，相邻或相互作用的对象被设置成关系。其中，排列关系包括从车道到路段的映射、路段内车道的排列、交通参与者在道路上的位置以及交通参与者之间的相对位置。Bagschik [5]提出的功能场景词汇已经描述了排列关系，以便可以直接进行转换。
对象依赖关系描述了每个场景的对象之间的依赖关系。每个对象依赖关系都包含一组规则，这些规则描述了链接对象的参数之间要满足的约束，要求满足功能场景的条件或满足仿真环境的数据格式的要求。例如，在Bagschik等[5]描述的功能场景中，借助策略在语义层面上描述了交通参与者之间的交互作用。为了在参数水平上实施策略，超车车辆的速度必须高于前方车辆的速度。另外，在OpenDRIVE中，多条车道被构造为路段，并组合在一起形成道路网。由于这种结构，连续车道在其连接点处必须具有相同的车道宽度。
参数依赖关系描述一个对象的参数之间的依赖关系，故一个参数可以受同一对象的一个或多个参数的影响。参数依赖性描述了在选择和组合参数值时要满足的条件，这些条件是由标准或物理关系决定的。例如，在Bagschik[5]等描述的功能场景中，道路的立面轮廓采用德国标准《如何修建高速公路》[16]中的设计模式进行建模，如平面、凹形曲线或凸形曲线，波峰曲线的长度不能独立于初始和最终倾斜，而是必须根据施工标准进行计算，如图6所示。因此，参数依赖性有助于根据管理准则和物理依赖性选择单个对象的参数值。
图6 用排列关系以及对象和参数依赖关系扩充参数空间，波峰的切线长度T必须根据半径R以及初始倾斜s1和最终倾斜s2进行计算
B.格式转换
格式转换是指将参数空间表示中建模的信息转换为OpenDRIVE和OpenSCENARIO的数据格式。第一步，利用OpenDRIVE生成道路表示，将5层模型的第1层到第3层的元素转换为OpenDRIVE格式的语法。同时，将根据参数空间表示中模型约束计算出有效默认值分配给每个参数。
第二步，生成OpenSCENARIO中交通参与者和环境条件的表示，将5层模型的第四层和第五层的元素转换成OpenSCENARIO格式的语法，并赋予参数有效的初始值。因此，将先前生成的OpenDRIVE文件作为道路表示的参考。此外，用于计算每个参数的默认值的规则集记录在另一个文件中。通过这种方式，可以在以下过程步骤中使用规则集来生成有效的参数值组合，例如作为测试用例生成的一部分。
4 评价
在本节中，将检查生成的OpenDRIVE和OpenSCENARIO文件。由于缺少设备和测试的度量以及一组联合场景，此检查形式上不是评估，而是提示场景是否正确转换。为此，根据Bagschik等[5]提出的基于知识的方法生成功能场景，然后利用本文提出的工具，将生成的场景自动转换为参数空间表示，并转换为OpenDRIVE和OpenSCENARIO格式，对于这两种格式，分别选择和评估测试场景。
A. OpenDRIVE
为了描述道路网络，功能场景的词汇表包括立面轮廓（如倾斜或下降）、线形（如直线或曲线）和车道类型（如硬路肩或行车车道）的多种变化。此外，还描述了交通基础设施的各种要素（如交通标志或护栏），这些要素的不同组合可以生成大量不同的路段。在Bagschik等[5]的基于知识的场景生成中，每个功能场景的路网仅由一个路段组成，目前尚未将连续路段与较长道路相结合，因此限制了用于评估的输入数据的多样性。
在OpenDRIVE格式中，只有连续的路段和车道之间存在依赖关系，道路横断面的设计元素（如立面轮廓和道路几何图形）可以独立指定。由于生成的功能场景的每个路网仅由一个路段组成，因此并非所有可能的组合都必须进行测试。对于评估，只需测试道路描述的每个单字是否正确映射（根据OpenDRIVE格式中所需的类和属性）到OpenDRIVE数据格式。因此，为了进行评估，我们选择了所有五个场景中的所有场景，这些场景利用了完整的道路描述词汇。
OpenDRIVE文件分两步评估。第一步，根据指定的功能场景检查生成的道路的执行情况，以及参数化是否符合标准。例如，在OpenDRIVE查看器的帮助下，通过检查坐标方向来评估几何体（线形和立面轮廓）（见图7a）。第二步，将道路描述加载到VTD中（见图7b），并检查是否显示了所有三维图形，以及是否正确连接了所有车道。因此，定义了一个虚拟车辆沿模型路线行驶，通过该程序，道路描述的参数空间是根据各自的功能场景和给定的标准生成的，并被正确地转换成OpenDRIVE数据格式。
(a) OpenDRIVE查看器中显示的OpenDRIVE轨迹
(b) VTD中显示的OpenDRIVE轨迹
图7 在OpenDRIVE Viewer和VTD中显示了弯道三车道高速公路的下坡、限速和护栏
B.OpenSCENARIO
描述交通参与者的功能场景词汇包括各种车辆类型（如汽车或卡车）和策略（如变道或超车），利用车道相对位置网格将车辆的位置相互关联。此外，还根据不同的天气条件（如雨或晴天）和一天中的不同时间（如上午或中午）描述了不同的环境特征。
OpenSCENARIO文件也分两步进行评估。第一步，生成的OpenSCENARIO文件在静态测试中与模式文件进行检查，将每个OpenSCENARIO文件的语法与OpenSCENARIO数据格式的格式规范进行比较，这样可以识别缺失的元素和属性。对于使用模式文件的静态测试，选择了六个场景，其中包括实现Bagschik等[5]生成的功能场景词汇表所需的所有OpenSCENARIO设计元素。检查表明，根据数据格式规范，功能场景被转换为OpenSCENARIO文件；然而，这样的静态测试并不能揭示功能场景中定义的所有元素是否都在相应的OpenSCENARIO文件中实现并使用有效的默认值初始化。
因此，第二步是在模拟环境中加载和执行OpenSCENARIO文件，检查每个生成的OpenSCENARIO文件是否根据各自的功能场景在模拟中执行。在本次测试中，主要问题有：
· 所有车辆是否在起始场景中定义的位置启动？
· 每辆车的行为是否符合起始场景中定义的策略？
· 所有策略是否在正确的时间点开始和结束，以便不会造成碰撞？
· 所有车辆在完成策略后是否都在结束场景中定义的位置结束？
为了为测试创建输入数据，作者使用Bagschik等[5]描述的方法生成了10000多个功能场景，大量的场景无法手动评估，因此作者定义了9个测试目标，并基于这9个目标选择了要测试的相关场景，每个测试目标都描述了细化和转换场景的程序的一部分（例如计算交通参与者的起始速度），这是应该被明确检查的。此外，每个测试目标都定义了一个测试草图，它描述了可用于检查各个测试目标的粗略结构和场景提要。根据测试目标，总共选择了30个场景，并在仿真环境中正确执行（按照各自功能场景中指定的）。
5 结论与展望
本文提出了一种将基于关键字的场景描述转换为仿真格式的方法，每个基于关键字的场景被转换为参数空间表示，然后转换为OpenDRIVE和OpenSCENARIO的数据格式，自动生成的场景根据指定的功能场景在仿真中进行了评估和执行。
Bagschik等[5]提出的基于知识的场景生成实现了场景的语义变化，为逻辑场景的建立奠定了基础。与数据驱动方法相结合，这些逻辑场景可以作为从测量数据中聚类场景的基础。此外，这些逻辑场景可以为场景的多样性建立一个参考，从而确保场景的语义变化很广泛。
然而，所提出的方法有一些局限性。首先，在功能场景和为仿真生成的数据文件中，只定义了通过仿真控制的车辆，未来必须增加通过自动驾驶功能控制的车辆标准。由于被测系统的未定义行为而产生的自由度可能会导致不必要的策略和交互顺序，在模拟的顺序控制中必须考虑这些可能的行动方案，因此必须在模拟的数据文件中加以描述。
此外，在当前的执行中，将关键字细化到参数空间和从关键字中导出约束的知识直接在源代码中建模。在开发过程中可跟踪的场景生成的范围内，这些知识应该显式地建模，例如作为一个本体；当场景变得更加复杂（关系和约束的数量不断增加）时，这一点变得更加重要。如上所述，当定义测试中的系统或在更复杂的领域（如城市地区）中指定场景时，就是这种情况。
另一个可能的局限是对约束的定义，它确保生成的场景在物理上是合理的，必须仔细选择这些约束条件，以确保只排除不相关的场景。
参考文献：
END
广告
广告
最新资讯
-
氢燃料电池卡车创企“冰河时代”！HVS命悬
2024-11-17 09:45
-
小米端到端大模型：智能驾驶的“新大脑”
2024-11-17 09:44
-
阿斯顿马丁推出新款 F1 模拟器
2024-11-17 09:43
-
汽车动力电池系统试验综述
2024-11-16 08:25
-
汽车可靠性前沿技术研讨会在重庆成功召开
2024-11-16 07:33
广告
广告
