CN115687163B - 场景库构建方法、装置、设备和存储介质 - Google Patents

Abstract

本发明公开了一种场景库构建方法、装置、设备和存储介质。该方法包括：获取待创建的测试场景与待构建的场景库之间的目标标准体系；根据目标标准体系，建立测试场景的分解结构，并确定结构描述信息；接收用户输入的场景创建指令，并基于测试场景的分解结构和结构描述信息，创建对应的测试场景，并基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将静态节点的xodr类型文件，以及动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，再进行格式转换以及场景泛化，得到创建完的测试场景，根据创建完的测试场景和场景标签，构建场景库。本发明提高了场景库构建效率。

Description

场景库构建方法、装置、设备和存储介质

技术领域

本发明涉及数据识别与表示领域，尤其涉及场景库构建方法、装置、设备和存储介质。

背景技术

智能网联汽车作为新一代信息技术与交通运输融合发展的产物，是我国科技创新支撑加快建设交通强国的重要内容。在智能网联汽车大规模生产之前，利用仿真软件进行智能网联汽车安全性验证必不可少，而智能驾驶仿真验证是智能网联汽车安全性验证中重要一环，且场景数据是进行仿真验证的关键基础，为此，场景数据与智能驾驶仿真形成了有机结合。

目前，由于不同标准之间存在数据不互通的问题，因此在没有统一的、直接可对接的数据标准下，现有技术存在生成数据困难，场景库自动构建效率低的技术问题，严重阻碍了智能网联汽车量产落地及商业使用。

有鉴于此，特提出本发明。

发明内容

为了解决上述技术问题，本发明提供了一种场景库构建方法、装置、设备和存储介质，能够基于OpenXOntology提供的共同语义库与逻辑映射关系，打通OpenLABEL、OpenDRIVE、OpenSCENARIO标准间的定义以及框架，使各标准高度兼容，实现场景数据互通与互认，解决现有技术中存在的生成数据困难，场景库自动构建效率低的技术问题。

本发明实施例提供了一种场景库构建方法，该方法包括：

获取待创建的测试场景与待构建的场景库之间的目标标准体系；

根据所述目标标准体系，建立所述测试场景的分解结构，并确定结构描述信息；其中，所述测试场景的分解结构是由对所述测试场景的要素逐级分解得到的静态节点和动态节点构成的层级结构，所述结构描述信息包含所述测试场景的分解结构中每一个节点的描述信息；

接收用户输入的场景创建指令，并基于所述测试场景的分解结构和所述结构描述信息，创建与所述场景创建指令对应的测试场景，并在创建过程中，基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将所述静态节点的xodr类型文件，以及所述动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，将所述OpenLABEL标准的数据进行格式转换，得到抽象场景，将所述抽象场景进行泛化，得到创建完的所述测试场景；

获取预设的标签模板；其中，所述预设的标签模板包括场景模板和自定义模板，所述自定义模板包含标签输入框和确认按键；

针对创建完的所述测试场景中每一个配置完的节点，显示用于为所述配置完的节点添加标签的添加界面；所述添加界面为包括场景类和非场景类的标签类型选择界面；

响应于用户基于所述标签类型选择界面选择场景类的第一选择指令，从所述场景模板中查找与所述配置完的节点对应的标签数据；或，响应于用户基于所述标签类型选择界面选择非场景类的第二选择指令，显示所述自定义模板，以供用户在所述输入框内输入非场景类标签，并点击所述确认按键，生成与所述配置完的节点对应的标签数据；

根据所有所述配置完的节点对应的标签数据，为所述测试场景添加对应的场景标签；

根据创建完的所述测试场景和所述场景标签，构建场景库。

本发明实施例提供了一种场景库构建装置，该装置包括：

第一获取模块，用于获取待创建的测试场景与待构建的场景库之间的目标标准体系；

建立确定模块，用于根据所述目标标准体系，建立所述测试场景的分解结构，并确定结构描述信息；其中，所述测试场景的分解结构是由对所述测试场景的要素逐级分解得到的静态节点和动态节点构成的层级结构，所述结构描述信息包含所述测试场景的分解结构中每一个节点的描述信息；

创建模块，用于接收用户输入的场景创建指令，并基于所述测试场景的分解结构和所述结构描述信息，创建与所述场景创建指令对应的测试场景，并在创建过程中，基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将所述静态节点的xodr类型文件，以及所述动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，将所述OpenLABEL标准的数据进行格式转换，得到抽象场景，将所述抽象场景进行泛化，得到创建完的所述测试场景；

第二获取模块，用于获取预设的标签模板；其中，所述预设的标签模板包括场景模板和自定义模板，所述自定义模板包含标签输入框和确认按键；

显示模块，用于针对创建完的所述测试场景中每一个配置完的节点，显示用于为所述配置完的节点添加标签的添加界面；所述添加界面为包括场景类和非场景类的标签类型选择界面；

查找模块，用于响应于用户基于所述标签类型选择界面选择场景类的第一选择指令，从所述场景模板中查找与所述配置完的节点对应的标签数据；或，响应于用户基于所述标签类型选择界面选择非场景类的第二选择指令，显示所述自定义模板，以供用户在所述输入框内输入非场景类标签，并点击所述确认按键，生成与所述配置完的节点对应的标签数据；

添加模块，用于根据所有所述配置完的节点对应的标签数据，为所述测试场景添加对应的场景标签；

构建模块，用于根据创建完的所述测试场景和所述场景标签，构建场景库。

本发明实施例提供了一种电子设备，所述电子设备包括：

处理器和存储器；

所述处理器通过调用所述存储器存储的程序或指令，用于执行任一实施例所述的场景库构建方法的步骤。

本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行任一实施例所述的场景库构建方法的步骤。

本发明实施例具有以下技术效果：

通过待创建的测试场景与待构建的场景库之间的目标标准体系，建立测试场景的分解结构，并确定结构描述信息；基于测试场景的分解结构和结构描述信息，自动创建与场景创建指令对应的测试场景，并在创建过程中，基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将所述静态节点的xodr类型文件，以及所述动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，将所述OpenLABEL标准的数据进行格式转换，得到抽象场景，将所述抽象场景进行泛化，得到创建完的所述测试场景。本发明基于OpenXOntology提供的共同语义库与逻辑映射关系，打通OpenLABEL、OpenDRIVE、OpenSCENARIO标准间的定义以及框架，使各标准高度兼容，实现场景数据互通与互认的特性，提出通过共同语义库与逻辑映射关系进行数据映射的方式，由于OpenXOntology针对场景中的静态节点以及动态节点，均提供了统一的、完整的描述，因此通过OpenXOntology提供的共同语义库与逻辑映射关系进行数据映射的方式，避免了不同标准之间存在数据不互通导致的生成数据困难，场景库自动构建效率低的技术问题，提高了场景库构建效率，进而提高场景识别的准确率。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种场景库构建方法的流程图；

图2是本发明实施例提供的另一种场景库构建方法的示意图；

图3是本发明实施例提供的一种场景库构建装置的结构示意图；

图4为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将对本发明的技术方案进行清楚、完整的描述。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例，都属于本发明所保护的范围。

本发明实施例提供的场景库构建方法，主要适用于在筛选目标场景，并利用该目标场景的场景数据对目标车辆进行测试之前的场景库构建的情况。本发明实施例提供的场景库构建方法可以由集成在车辆的主控制器内或者独立于该目标车辆的电子设备执行。

实施例1：

本实施例中的自动驾驶场景管理平台主要有四个功能模块，第一个功能模块用于创建场景，第二功能模块用于自动创建标签与标签模板管理，第三个功能模块用于场景筛选，第四个功能模块用于场景数据导出。其中，实施例1具体描述自动驾驶场景管理平台的第一功能模块和第二功能模块的功能。而第三功能模块和第四模块的功能见下述实施例2，此处不做赘述。

图1是本发明实施例提供的一种场景库构建方法的流程图。参见图1，该场景库构建方法具体包括以下步骤S21~S28，其中：

S21、获取待创建的测试场景与待构建的场景库之间的目标标准体系。

在本实施例中，目标标准体系可以指PEGASUS项目六层模型，该模型是对场景内各项元素的分类方法描述，其作为一个场景搭建的参考说明，本实施例进行的是基于模型中元素分类的方法，对场景内各项元素在平台内进行分类设置，得到上述测试场景的分解结构以及结构描述信息，进而可以通过自动驾驶场景管理平台的显示界面将测试场景的分解结构以及结构描述信息进行显示，以便于用户对应配置。

本实施例以国际标准组织ASAM所提出的OpenDRIVE及OpenSCENARIO为基准，实现对PEGASUS项目六层模型的应用，将该模型作为目标标准体系完成对场景中静态元素及动态元素的定义，保证该平台内场景的通用性及标准性，以便于场景文件输出至各类仿真软件中进行后续仿真测试。

S22、根据目标标准体系，建立测试场景的分解结构，并确定结构描述信息。其中，测试场景的分解结构是由对测试场景的要素逐级分解得到的静态节点和动态节点构成的层级结构，结构描述信息包含测试场景的分解结构中每一个节点的描述信息。

示例性的，在建立测试场景的分解结构时，本实施例可以仅使用该模型中的五层，即道路结构、交通设施、交通临时改变、交通参与者和自然环境。道路结构中的节点包括但不限于几何结构、拓扑、路面质量、边界；交通设施中的节点包括但不限于标志牌、信号灯；交通临时改变为道路的临时性设施，其包含的节点包括但不限于临时封路、道路施工现场；交通参与者包括但不限于机动车、非机动车、行人、动物；自然环境为天气光照、场景周围建筑设施。

应理解，静态节点或称为静态元素，包括但不限于：道路结构中的节点、交通设施中的节点、交通临时改变中的节点、交通参与者中的节点、自然环境中的节点；动态节点或称为动态元素，包括但不限于：信号灯控制逻辑对应的节点、事件对应的节点。其中，信号灯控制逻辑对应的节点，用于实现对信号灯的控制。一个场景下可以有多个场景故事，用于定义触发条件、动作（如换道、超车等）及姿态，也就是说，该场景故事下的事件包括但不限于：查看基本信息的第一事件、创建触发条件的第二事件、配置动作对应的第三事件、配置姿态对应的第四事件。

S23、接收用户输入的场景创建指令，并基于测试场景的分解结构和结构描述信息，创建与场景创建指令对应的测试场景，并在创建过程中，基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将静态节点的xodr类型文件，以及动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，将OpenLABEL标准的数据进行格式转换，得到抽象场景，将抽象场景进行泛化，得到创建完的测试场景。

S24、获取预设的标签模板；其中，预设的标签模板包括场景模板和自定义模板，自定义模板包含标签输入框和确认按键。

其中，场景模板用于构成标准化标签库，自定义模板用于构成自定义标签库。本实施例基于对行业标准知识体系及在场景方面的标准研究基础，提供标签库管理模块，包括标准化标签库和自定义标签库，可以从多角度满足用户对于场景特征的描述。其中标准化标签库为用户提供包含ODD、SOTIF、交通事故、标准法规、场景等类型的标签库。同时，为进一步满足用户自定义需求，本实施例还支持用户根据自身习惯、喜好等新建标签，并形成自定义标签库，用于对场景进行标签管理。

其中，ODD类型的标签库，是符合ISO 34503 Operational Design Domain (ODD)及国标《智能网联汽车自动驾驶系统设计运行条件》的ODD标签模板，用于定义场景动静态元素的关键特征。

SOTIF类型的标签库，是符合ISO 21448预期功能安全(SOTIF)标准的标签模板，用于定义环境感知、地图定位、决策规划等模块的随机失效和系统性失效情况。

场景类型的标签库，是符合ISO 34504 Road vehicles — Test scenarios forautomated driving systems - Scenario categorization标准的标签模板，用于定义场景动静态元素的关键特征。

基于此，本实施例基于以上体系将标签数据的格式定义为符合OpenLABEL标准的标签格式，并实现OpenLABEL与OpenDRIVE、OpenSCENARIO的相互映射。

S25、针对创建完的测试场景中每一个配置完的节点，显示用于为配置完的节点添加标签的添加界面；添加界面为包括场景类和非场景类的标签类型选择界面。

在本实施例中，场景类的标签数据为OpenDRIVE和OpenSCENARIO文件中定义的节点的标签数据，例如：车道类型为直道、车道数量为4。而非场景类的标签数据为对场景的文本描述，如该场景为危险场景。本实施例提供的标签模板中可能既含有场景类的标签数据，又含有非场景类的标签数据。

S26、响应于用户基于标签类型选择界面选择场景类的第一选择指令，从场景模板中查找与配置完的节点对应的标签数据；或，响应于用户基于标签类型选择界面选择非场景类的第二选择指令，显示自定义模板，以供用户在输入框内输入非场景类标签，并点击确认按键，生成与配置完的节点对应的标签数据。

例如，对场景中动态元素“能见度”进行定义并添加对应标签：（1）平台内自然环境中“能见度”设置为1000米；（2）本实施例可以在OpenSCENARIO标准描述文件（即.xosc文件）中对应生成；（3）本实施例也可以在OpenLABEL标签文件（即.json文件）中对应生成。

应理解，由于平台内置有多种标签模板，且一个标签模板由多个标签组成，因此，不同标签模板之间可能存在标签重合的情况，例如：“直道”标签，既存在于ODD标签模板下，又存在于场景标签模板下，该场景元素（即节点）可对应多个标签数据。

通过上述描述可知，在生成场景标签对应的标签文件的过程中，本实施例可以为各节点添加标签数据，进而为场景添加场景标签。为节点添加标签的方式采用以下两种方式：第一种是生成场景类标签的方式，在该方式下，场景类标签根据场景模板提供的节点与标签之间的映射关系自动生成，同时，也支持用户再次手动添加其他的场景类标签；第二种是选择非场景类标签的方式，此方式由用户手动添加，最终场景下所有节点的标签数据可以构成一个完整的标签文件，为后续通过节点的标签数据筛选目标场景提供便利。

S27、根据所有配置完的节点对应的标签数据，为测试场景添加对应的场景标签。

在本实施例中，一个场景可添加多个标签模板中的多个标签，例如：场景A添加了ODD标签模板、场景标签模板、SOTIF标签模板及其他自定义模板，用户可从以上模板中选择多个标签数据作为场景标签来标注场景。

通过执行S24~S27，本实施例中的自动驾驶场景管理平台，可以实现场景标签的自动标注功能。基于此，本实施例实现了OpenLABEL与OpenSCENARIO、OpenDRIVE的映射转换，创建标签，从而实现场景标注，便于后续检索管理。

本实施例支持用户在创建或导入场景后，采用OpenLABEL标准格式对成功导入的场景文件自动创建场景标签，添加具体的场景标签主要分为两个部分，一部分是生成场景类标签，其是根据OpenSCENARIO、OpenDRIVE与OpenLABEL的映射关系自动添加的标签。另一部分是选择非场景类标签，该类标签主要是针对预期功能安全、危险事故以及法律法规等场景，并对其手动添加标签。用户为场景添加符合描述的对应标签后，将整体为该场景生成符合OpenLABEL标准的标签文件，该文件用来描述场景特性，同时作为实际应用中场景检索部分（即上述场景筛选阶段）的依赖文件。

S28、根据创建完的测试场景和场景标签，构建场景库。

在本实施例中，测试场景的场景数据以OpenLABEL形式进行存储，场景存储时，还可以实现对场景进行标签管理。

示例性的，静态节点的xodr类型文件，以及动态节点的xosc类型的文件，通过数据映射的方式，基于OpenXOntology标准的共同语义库与逻辑映射关系，将其映射为OpenLABEL标准的数据，进而进行格式转换，得到具有OpenSCENARIO2.0版本的、ADSL类型的场景数据的抽象场景，再进行场景泛化，得到具有OpenSCENARIO1.0版本的场景数据的具体场景。

通过上述描述可知，本实施例中的自动驾驶场景管理平台，基于OpenXOntology标准的共同语义库与逻辑映射关系，打通OpenLABEL、OpenDRIVE、OpenSCENARIO标准间的定义以及框架，使各标准高度兼容，实现场景数据互通与互认，并支持多仿真器仿真应用。

在一种具体的实施方式中，在S23中，基于测试场景的分解结构和结构描述信息，创建与场景创建指令对应的测试场景，包括以下步骤S231~S233，其中：

S231、响应于场景创建指令，显示包含测试场景的分解结构和结构描述信息的配置界面。

在本实施例中，创建N个场景时，可以重复执行S231~S233整个流程N次。配置界面可以指用于场景编辑与创建的界面。

S232、获取待创建的测试场景在分解结构中各节点的配置信息，并根据配置信息，结合结构描述信息中与配置信息所对应的节点的描述信息，在配置界面上对配置信息所对应的节点进行配置，得到配置完的节点。

在本实施例中，平台创建的场景一般由多个节点组成，在配置节点时，用户可以基于下拉菜单进行点击、输入等操作完成填写。配置界面可以包括场景编辑器。

另外，结构描述信息中与配置信息所对应的节点的描述信息可以作为预设的填写规则辅助用户进行填写。进一步的，本实施例在对动态节点进行事件创建时，可以由用户根据测试需求自定义添加。

例如，道路结构中的路段1为一个静态节点，该静态节点的配置信息包括：道路类型、车道方向、单向车道数目、车道宽度、车道长度、车道线等，其中，道路类型包括但不限于直道、倾斜、中心偏移道路、辅路。

又例如，标志牌的配置信息包括标志牌的基本信息和标志牌的定位信息，其中，标志牌的基本信息包括类型、朝向和状态，标志牌的定位信息包括y轴位置和x轴位置。

又例如，信号灯包括横式和立式两种类型的交通信号灯，横式交通信号灯和立式交通信号灯的配置信息均包括：基本信息和定位信息两大类，其中，立式交通信号灯的基本信息包括编号、类型、方向、高度、状态等，立式交通信号灯的定位信息包括中心横向位置、中心纵向位置和朝向。

本实施例中的平台支持用户对场景内的静态节点的配置信息和动态节点的配置信息进行编辑、存储等。

S233、将所有配置完的节点构成的场景确定为与场景创建指令对应的测试场景。

在所有节点配置完之后，用户可以在配置界面上触发保存事件，进而生成包含该测试场景的场景数据的场景文件。该场景文件能够以OpenDRIVE、OpenSCENARIO、excel/csv等文件格式进行批量的导入与导出。

在本实施例中，本实施例提供了交互便利的场景编辑与创建界面，支持用户快速手动创建场景，将上述场景中的静态节点的配置信息和动态节点的配置信息填写后进行存储，以满足OpenLABEL格式生成的.json文件存储于平台的预设数据库内，场景创建流程结束。

在一种具体的实施方式中，在S232中，在配置界面上对配置信息所对应的节点进行配置，得到配置完的节点，包括以下步骤S1~S2，其中：

S1、确定配置信息所对应的节点的类型。

应理解，节点的类型包括：静态节点和动态节点两种，其中，静态节点为静态场景下的节点，动态节点为动态场景下的节点。

S2、当配置信息所对应的节点的类型为静态节点时，按照预设静态格式，在配置界面上对配置信息所对应的节点进行配置，得到配置完的节点；或，当配置信息所对应的节点的类型为动态节点时，按照预设动态格式，在配置界面上对配置信息所对应的节点进行配置，得到配置完的节点。

在本实施例中，静态场景的创建符合OpenDRIVE标准定义，该标准定义对应预设静态格式，而动态场景的创建符合OpenSCENARIO标准定义，该标准定义对应预设动态格式。

通过上述描述可知，本实施例对不同类型的节点，分别按照对应格式进行配置，提高了配置的准确性。

综上，本实施例的目的在于提供一种场景库构建方法，与现有技术相比，本实施例的有益效果为：

（1）在行业引领方面，本实施例将大力推动检测单位与各汽车设计生产企业在自动驾驶汽车领域的合作，进一步扩展技术服务内容，帮助企业构建虚拟仿真测试工具链及关键技术接口，增强企业研发能力，加强企业、高校、检测机构、政府部门的沟通合作，进而形成可持续发展的智能网联生态圈。

（2）在成果应用方面，本实施例将进一步完善自动驾驶领域标准现状。一方面，通过本实施例的研究，将大力支持虚拟仿真测试相关技术标准的快速推进，通过大量工程试验数据与测试结果，确保标准制定的科学性合理性。另一方面，通过寻找现有标准应用欠缺，完善仿真内容及测试体系欠缺。

（3）在社会效益方面，通过本实施例的实施可以推动模拟仿真关键工具的自主化，加快自动驾驶汽车的落地，同时增强该场景库构建方法在国内仿真测试的影响力。

实施例2：

图2是本发明实施例提供的另一种场景库构建方法的示意图。在上述实施例1的基础上，对车辆的测试过程进行了示例性说明。参见图2，本实施例包括以下步骤S110~S120，其中：

S110、响应于用户对目标车辆的待测项进行测试的测试请求，确定待测项对应节点的标签数据，并从场景库中筛选出目标场景；其中，目标场景为具有包含待测项对应节点的标签数据的场景标签的测试场景。

在本实施例中，目标车辆为待测车辆，待测项可以是车辆安全性测试中的任一项目，例如，可以指目标车辆在直路中的安全性测试，其中，该待测项对应节点为标签数据为“直路”的节点，一个节点可以包含至少一个标签数据，例如，标签数据为“直路”的节点，其标签数据还可以包括“长度50米”、“宽度3米”。在上述情况下，目标场景为包含标签数据为“直路”的节点的场景，在其场景标签中可以查到标签数据“直路”。

为了便于实施上述步骤，以接收到用户的测试请求，本实施例提供了一种基于ASAM OpenX系列标准的自动驾驶场景管理平台（简称为平台），该平台向用户、管理者同时开放。用户通过浏览器进行访问，具体的，在场景筛选阶段，向用户提供设置有包含场景筛选框的界面，用户进行搜索的流程如下：（1）用户在场景筛选框内输入与测试请求有关的节点的标签；（2）输入完成之后，触发该界面上的搜索事件，以使该平台通过ajax请求搜索接口将与测试请求有关的节点的标签数据以浏览器服务请求的方式传递到该平台的后台服务器；（3）后台服务器通过后端语言（ASP.NET Core）实现浏览器服务请求的接收；（4）后台服务器将浏览器服务请求中的内容作为搜索条件查询该平台的数据库；（5）该数据库在查询到目标场景之后，将目标场景的场景数据作为查询到的结果，通过搜索接口约定格式返回至浏览器；（6）浏览器通过前端JS将返回到的结果渲染显示在页面上，场景筛选阶段结束。

应理解，待测项描述的越详细，符合要求的节点越少，进而筛选出的目标场景越精确，反之，筛选出的目标场景越多，因此本实施例在场景筛选阶段可以在模糊搜索和精确搜索之间进行选择。

可选地，预设的场景库中包含大量的场景。例如，包含节点1、2、3的第一场景，包含节点2、4、10的第二场景，包含节点1、3、7的第三场景。

待测项对应的节点的数量可以是一个，也可以是多个。当待测项对应节点为多个（例如：节点1和节点3）时，若节点1的标签数据为A，节点3的标签数据为B，那么可以从第一场景和第三场景中进行筛选目标场景，若第一场景中节点1、3的标签数据分别与待测项对应节点1、3的标签数据一致，则将第一场景和第三场景均确定为目标场景。若第三场景中节点1的标签数据与待测项对应节点1的标签数据一致且第三场景中节点3的标签数据为C与待测项对应节点3的标签数据不一致，则只将筛选出的第一场景确定为目标场景。

S120、根据目标场景的场景数据，对目标车辆进行测试，得到目标车辆在待测项下的测试结果。

通过S110~S120的描述可知，本实施例预设的场景库存储有N个场景，每个场景涉及M个元素（如直路、交通设施中的节点等），根据待测项对应节点的标签筛选场景，即从所有场景的场景标签中的多个标签数据中选择“直路”标签，进而从N个场景中检索出场景标签中包含“直路”标签的全部场景。

需要注意的是，本实施例支持通过场景的不同特征要素（节点）进行全场景库的快速场景筛选。此外，本实施例还支持用户自定义筛选模板，并提供丰富的标签库供用户参考选择。

在自动驾驶研发加速落地的行业背景下，为实现数字孪生智慧城市仿真复现，本实施例提出的场景库构建方法，可以应用于面向智能汽车的、基于ASAM OpenX系列标准的自动驾驶场景管理平台，旨在解决智能驾驶场景数据存储格式不统一、分类检索困难、本地化场景库分散、无法同时选择多标签库等问题，实现驾驶场景数据统一管理、测试场景高效检索等功能。

本实施例基于一个目标场景由多个节点构成，并且不同标签数据的节点的组合能够构成不同的目标场景的特性，提出通过节点的标签数据来筛选目标场景的方式，由于节点的粒度远远小于场景，因此通过节点的标签数据筛选目标场景的方式，避免了通过场景文件的名称或对场景的描述来识别目标场景导致的识别准确率差、测试结果与实际严重不符的技术问题，提高了目标场景的场景数据识别准确率，进而提高了测试结果的准确率。

在一种具体的实施方式中，在从场景库中筛选出目标场景之后，该场景库构建方法还包括：

S130、响应于用户针对测试请求中的待测项的勾选操作，将目标场景的场景数据存储至预设常用数据库中，并将待测项作为历史筛选条件显示在历史搜索框中。

通过该步骤，本实施例支持用户保存常用的筛选组合，方便用户根据自身习惯快速筛选出对应的目标场景。

在一种具体的实施方式中，在从预设的场景库中筛选出目标场景之后，该场景库构建方法还包括：

S140、判断包含目标场景的场景数据的场景文件是否接入目标应用。

应理解，目标应用可以指各类仿真软件。

S150、根据场景文件是否接入目标应用的判断结果，确定场景文件的输出格式。

本实施例在导出场景文件时，首先判断该场景文件是否接入仿真软件。如果未接入仿真软件，则将场景文件以excel格式直接导出；如果接入仿真软件，则将已经存储在平台中的场景文件进行格式转化，一方面针对静态信息（静态节点的相关数据）进行OpenDRIVE格式的转化，从而生成OpenDRIVE格式文件，另一方面对动态信息（即动态节点的相关数据）进行OpenSCENARIO格式的转化，从而生成OpenSCENARIO格式文件。最终将不同格式的场景文件进行导出，流程结束。

针对场景文件导出成OpenX标准文件（包括本实施例所涉及的OpenX标准有OpenDRIVE及OpenSCENARIO）做如下说明：

（1）本实施例提出一种基于ASP.NET Core框架的OpenDRIVE和OpenSCENARIO标准数据结构，该数据结构非常灵活，耦合度低，扩展性较强，可以直接生成标准仿真场景。

（2）本实施例的通用数据结构excel与OpenX标准出入较大，故在两者之间建立了一种数据映射关系。该映射关系将本实施例的通用数据结构做了裁剪与分析，相同字段原样保留，相近字段做算法分析后赋值到标准数据字段。

本实施例具有以下技术效果：

本实施例可以进一步对保存在数据库中的场景文件进行OpenX格式转化，并支持导出OpenX格式文件，能够应用于行业中各类主流的仿真软件。

实施例3：

图3是本发明实施例提供的一种场景库构建装置的结构示意图。本实施例的装置可以为软件和/或硬件的形式。如图3所示，本实施例提供的场景库构建装置，包括：第一获取模块31、建立确定模块32、创建模块33、第二获取模块34、显示模块35、查找模块36、添加模块37和构建模块38。其中：

第一获取模块31，用于获取待创建的测试场景与待构建的场景库之间的目标标准体系。

建立确定模块32，用于根据目标标准体系，建立测试场景的分解结构，并确定结构描述信息；其中，测试场景的分解结构是由对测试场景的要素逐级分解得到的静态节点和动态节点构成的层级结构，结构描述信息包含测试场景的分解结构中每一个节点的描述信息。

创建模块33，用于接收用户输入的场景创建指令，并基于测试场景的分解结构和结构描述信息，创建与场景创建指令对应的测试场景，并在创建过程中，基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将静态节点的xodr类型文件，以及动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，将OpenLABEL标准的数据进行格式转换，得到抽象场景，将抽象场景进行泛化，得到创建完的测试场景。

第二获取模块34，还用于获取预设的标签模板；其中，预设的标签模板包括场景模板和自定义模板，自定义模板包含标签输入框和确认按键。

显示模块35，用于针对创建完的测试场景中每一个配置完的节点，显示用于为配置完的节点添加标签的添加界面；添加界面为包括场景类和非场景类的标签类型选择界面。

查找模块36，用于响应于用户基于标签类型选择界面选择场景类的第一选择指令，从场景模板中查找与配置完的节点对应的标签数据；或，响应于用户基于标签类型选择界面选择非场景类的第二选择指令，显示自定义模板，以供用户在输入框内输入非场景类标签，并点击确认按键，生成与配置完的节点对应的标签数据。

添加模块37，用于根据所有配置完的节点对应的标签数据，为测试场景添加对应的场景标签。

构建模块38，用于根据创建完的测试场景和场景标签，构建场景库。

本实施例提供的场景库构建装置，可用于执行上述任意方法实施例提供的场景库构建方法，其实现原理和技术效果类似，此处不做赘述。

图4为本发明实施例提供的一种电子设备的结构示意图。如图4所示，电子设备400包括一个或多个处理器401和存储器402。

处理器401可以是中央处理单元（CPU）或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备400中的其他组件以执行期望的功能。

存储器402可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器（RAM）和/或高速缓冲存储器（cache）等。所述非易失性存储器例如可以包括只读存储器（ROM）、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器401可以运行所述程序指令，以实现上文所说明的本发明任意实施例的场景库构建方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如初始外参、阈值等各种内容。

在一个示例中，电子设备400还可以包括：输入装置403和输出装置404，这些组件通过总线系统和/或其他形式的连接机构（未示出）互连。该输入装置403可以包括例如键盘、鼠标等等。该输出装置404可以向外部输出各种信息，包括预警提示信息、制动力度等。该输出装置404可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图4中仅示出了该电子设备400中与本发明有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备400还可以包括任何其他适当的组件。

除了上述方法和设备以外，本发明的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本发明任意实施例所提供的场景库构建方法的步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本发明实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本发明的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本发明任意实施例所提供的场景库构建方法的步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

需要说明的是，本发明所用术语仅为了描述特定实施例，而非限制本申请范围。如本发明说明书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者设备中还存在另外的相同要素。

还需说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。除非另有明确的规定和限定，术语“安装”、“相连”、“连接”等应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

还需说明的是，本申请所涉及的用户信息和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案。

Claims (9)

1.一种场景库构建方法，其特征在于，包括：

获取待创建的测试场景与待构建的场景库之间的目标标准体系；

根据所述目标标准体系，建立所述测试场景的分解结构，并确定结构描述信息；其中，所述测试场景的分解结构是由对所述测试场景的要素逐级分解得到的静态节点和动态节点构成的层级结构，所述结构描述信息包含所述测试场景的分解结构中每一个节点的描述信息；

接收用户输入的场景创建指令，并基于所述测试场景的分解结构和所述结构描述信息，创建与所述场景创建指令对应的测试场景，并在创建过程中，基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将所述静态节点的xodr类型文件，以及所述动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，将所述OpenLABEL标准的数据进行格式转换，得到抽象场景，将所述抽象场景进行泛化，得到创建完的所述测试场景；

获取预设的标签模板；其中，所述预设的标签模板包括场景模板和自定义模板，所述自定义模板包含标签输入框和确认按键；

针对创建完的所述测试场景中每一个配置完的节点，显示用于为所述配置完的节点添加标签的添加界面；所述添加界面为包括场景类和非场景类的标签类型选择界面；

响应于用户基于所述标签类型选择界面选择场景类的第一选择指令，从所述场景模板中查找与所述配置完的节点对应的标签数据；或，响应于用户基于所述标签类型选择界面选择非场景类的第二选择指令，显示所述自定义模板，以供用户在所述输入框内输入非场景类标签，并点击所述确认按键，生成与所述配置完的节点对应的标签数据；

根据所有所述配置完的节点对应的标签数据，为所述测试场景添加对应的场景标签；

根据创建完的所述测试场景和所述场景标签，构建场景库。

2.根据权利要求1所述的方法，其特征在于，所述基于所述测试场景的分解结构和所述结构描述信息，创建与所述场景创建指令对应的测试场景，包括：

响应于所述场景创建指令，显示包含所述测试场景的分解结构和所述结构描述信息的配置界面；

获取待创建的测试场景在所述分解结构中各节点的配置信息，并根据所述配置信息，结合所述结构描述信息中与所述配置信息所对应的节点的描述信息，在所述配置界面上对所述配置信息所对应的节点进行配置，得到配置完的节点；

将所有配置完的节点构成的场景确定为与所述场景创建指令对应的测试场景。

3.根据权利要求2所述的方法，其特征在于，所述在所述配置界面上对所述配置信息所对应的节点进行配置，得到配置完的节点，包括：

确定所述配置信息所对应的节点的类型；

当所述配置信息所对应的节点的类型为所述静态节点时，按照预设静态格式，在所述配置界面上对所述配置信息所对应的节点进行配置，得到配置完的节点；或，当所述配置信息所对应的节点的类型为所述动态节点时，按照预设动态格式，在所述配置界面上对所述配置信息所对应的节点进行配置，得到配置完的节点。

4.根据权利要求1所述的方法，其特征在于，在构建完所述场景库之后，还包括：

响应于用户对目标车辆的待测项进行测试的测试请求，确定所述待测项对应节点的标签数据，并从所述场景库中筛选出目标场景；其中，所述目标场景为具有包含所述待测项对应节点的标签数据的场景标签的测试场景；

根据所述目标场景的场景数据，对所述目标车辆进行测试，得到所述目标车辆在所述待测项下的测试结果。

5.根据权利要求4所述的方法，其特征在于，在从所述场景库中筛选出目标场景之后，还包括：

响应于用户针对所述测试请求中的待测项的勾选操作，将所述目标场景的场景数据存储至预设常用数据库中，并将所述待测项作为历史筛选条件显示在历史搜索框中。

6.根据权利要求4所述的方法，其特征在于，在从所述场景库中筛选出目标场景之后，还包括：

判断包含所述目标场景的场景数据的场景文件是否接入目标应用；

根据所述场景文件是否接入目标应用的判断结果，确定所述场景文件的输出格式。

7.一种场景库构建装置，其特征在于，包括：

第一获取模块，用于获取待创建的测试场景与待构建的场景库之间的目标标准体系；

建立确定模块，用于根据所述目标标准体系，建立所述测试场景的分解结构，并确定结构描述信息；其中，所述测试场景的分解结构是由对所述测试场景的要素逐级分解得到的静态节点和动态节点构成的层级结构，所述结构描述信息包含所述测试场景的分解结构中每一个节点的描述信息；

创建模块，用于接收用户输入的场景创建指令，并基于所述测试场景的分解结构和所述结构描述信息，创建与所述场景创建指令对应的测试场景，并在创建过程中，基于预设的OpenXOntology提供的共同语义库与逻辑映射关系，通过数据映射的方式，将所述静态节点的xodr类型文件，以及所述动态节点的xosc类型的文件均映射为OpenLABEL标准的数据，将所述OpenLABEL标准的数据进行格式转换，得到抽象场景，将所述抽象场景进行泛化，得到创建完的所述测试场景；

第二获取模块，用于获取预设的标签模板；其中，所述预设的标签模板包括场景模板和自定义模板，所述自定义模板包含标签输入框和确认按键；

显示模块，用于针对创建完的所述测试场景中每一个配置完的节点，显示用于为所述配置完的节点添加标签的添加界面；所述添加界面为包括场景类和非场景类的标签类型选择界面；

查找模块，用于响应于用户基于所述标签类型选择界面选择场景类的第一选择指令，从所述场景模板中查找与所述配置完的节点对应的标签数据；或，响应于用户基于所述标签类型选择界面选择非场景类的第二选择指令，显示所述自定义模板，以供用户在所述输入框内输入非场景类标签，并点击所述确认按键，生成与所述配置完的节点对应的标签数据；

添加模块，用于根据所有所述配置完的节点对应的标签数据，为所述测试场景添加对应的场景标签；

构建模块，用于根据创建完的所述测试场景和所述场景标签，构建场景库。

8.一种电子设备，其特征在于，所述电子设备包括：

处理器和存储器；

所述处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至6任一项所述的场景库构建方法的步骤。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至6任一项所述的场景库构建方法的步骤。

Images