CN118202213A

CN118202213A - 道路布局索引和查询

Info

Publication number: CN118202213A
Application number: CN202280069590.6A
Authority: CN
Inventors: 马文·艾伦·琼斯
Original assignee: Faber Artificial Intelligence Co ltd
Current assignee: Faber Artificial Intelligence Co ltd
Priority date: 2021-10-14
Filing date: 2022-10-13
Publication date: 2024-06-14
Also published as: GB202114685D0; EP4374135A2; WO2023062166A3; WO2023062166A2

Abstract

一种计算机***，包括：计算机存储器、拓扑索引部件、几何索引部件以及场景查询引擎；计算机存储器被配置为存储静态道路布局；拓扑索引部件被配置为生成静态道路布局的内存拓扑索引，拓扑索引是节点和边的图的形式，其中每个节点对应于静态道路布局的道路结构元素，并且边对道路结构元素之间的拓扑关系进行编码；几何索引部件被配置为生成静态道路布局的至少一个内存几何索引，用于将几何约束映射到静态道路布局的道路结构元素；场景查询引擎被配置为接收几何查询，搜索几何索引以定位满足几何查询的一个或更多个几何约束的至少一个静态道路元素，并且返回至少一个道路结构元素的描述符，其中场景查询引擎被配置为接收包括至少一个道路元素的描述符的拓扑查询，搜索拓扑索引以定位对应的节点，基于在拓扑索引的边中编码的拓扑关系来识别满足拓扑查询的至少一个其他节点，并且返回满足拓扑查询的其他节点的描述符。

Description

道路布局索引和查询

技术领域

本公开涉及自主车辆的支持工具。此类工具具有离线应用以支持自主车辆***的开发和测试(包括基于模拟的测试)、以及自主车辆内的在线应用，以促进实时规划、预测和/或其他在线功能。

背景技术

自主车辆领域取得了重大而快速的发展。自主车辆(autonomous vehicle,AV)是一种配备有传感器和控制***的车辆，使该车辆能够在没有人类控制其行为的情况下运行。自主车辆配备有传感器，使该车辆能够感知其物理环境，这样的传感器包括例如相机、雷达和激光雷达。自主车辆配备有适当编程的计算机，该计算机能够处理从传感器接收的数据，并且基于传感器感知的环境做出安全和可预测的决策。

自主车辆可以是完全自主的(至少在某些情况下，它被设计为在没有人为监督或干预的情况下运行)或半自主的。半自主***需要不同级别的人为监督和干预。高级驾驶员辅助***(Advanced Driver Assist System,ADAS)和某些级别的自主驾驶***(Autonomous Driving System,ADS)可以归类为半自主。“5级”车辆是在任何情况下都能完全自主运行的车辆，因为它总能保证达到一定的最低安全水平。这种车辆根本不需要手动控制(方向盘、踏板等)。相比之下，3级和4级车辆可以完全自主运行，但只能在某些限定环境内(例如在地理围栏区域内)运行。3级车辆必须配备自主处理任何需要立即响应(例如紧急制动)的情况；然而，环境的变化可能会引发“过渡需求”，要求驾驶员在某些有限的时间表内控制车辆。4级车辆也有类似的限制；然而，在驾驶员没有在所需时间表内做出响应的情况下，4级车辆还必须能够自主实现“最小风险策略”(minimum risk maneuver,MRM)(即一些适当的动作)以将车辆带到安全状态(例如减速和停车)。2级车辆要求驾驶员随时准备干预，并且如果自主***未能随时做出正确响应，驾驶员有责任进行干预。对于2级自动化，驾驶员有责任确定何时需要他们的干预；对于3级和4级，这一责任转移到车辆的自主***，当需要干预时，车辆必须提醒驾驶员。

精确捕获和描述驾驶场景的能力是自主车辆技术的基石。典型的驾驶场景包括静态道路布局和自主车辆(自我车辆(ego vehicle))需要导航的各种动态代理(其他车辆、行人、骑自行车的人、动物等)。在复杂的道路网络内，可能需要自我车辆来预测其他代理的运动并进行安全规划。在在线环境中，预测和规划部件需要足够详细和精确的场景描述。在离线环境中，可能需要场景描述作为模拟器的输入，以便于在部署到真实世界的车辆上之前对自主车辆堆栈进行基于模拟的测试。

ASAM OpenSCENARIO(R)定义了一种用于描述动态驾驶场景内容的文件格式。OpenSCENARIO可以与ASAM OpenDRIVE(R)模式一起用于描述静态道路网络。OpenDRIVE的既定目的“是提供一种道路网络描述，可以将其输入到模拟中，以开发和验证ADAS和AD[自主驾驶]功能”[1]。OpenDRIVE是一种基于XML的模式，该模式允许以分层方式描述道路网络。道路由道路元素(<road>)描述，可经由道路元素内的链接元素(<link>)连接。当链接两个以上的道路时，需要交叉路口元素(＜junction＞)。每个道路元素都由单个由参数化几何元素构建的道路参考线来表征。OpenDRIVE将相对于参考线的纵向和横向坐标指示为“s”和“t”(参考线坐标)。车道由道路元素内的车道元素(<lane>)描述。每个道路元素必须包含宽度为零的中心车道元素和非零宽度的至少一个“侧车道”元素。中心车道用作车道编号的参考。默认情况下，中心车道沿着道路参考线，但可以偏离道路参考线。为了简洁起见，“侧车道”在本文中可以简称为含义明确的车道。侧车道可以具有固定或可变宽度。沿着给定路段，侧车道的宽度可能为零，但应避免长距离的零宽度侧车道。道路元素可以划分为部分(车道段)，以适应车道数量变化的道路，其中每个车道段都有固定数量的车道。道路和交叉路口分配了字符串标识符，该字符串标识符在道路网络内应该是唯一的。车道经由相对于中心车道的增量车道编号来识别，并且车道编号仅在车道段内是唯一的。两个链接的道路内的各个车道可以经由车道元素内的附加链接元素进行链接。道路/车道几何形状根据函数来描述，其中函数可以沿着道路变化(例如，道路参考线可以被描述为给定区间上的直线函数，然后是螺旋函数，再是弧函数；车道可以根据在某个区间上恒定的宽度函数来描述，然后变为线性增加的函数等)。

在开放式驾驶中，并非所有侧车道都可驾驶。相反，“侧车道”是广义的概念，用于描述任何道路几何形状。不可驾驶侧线的示例包括限制区域、人行路面/人行道、矮树篱等。每个侧车道都具有可配置的属性，除其他外，该属性指示其是否可驾驶。

发明内容

本文解决的一个问题是静态道路布局的查询效率。受益于道路布局的速度优化查询的AV应用是多种多样的。在在线环境中，可以实时查询地图以支持预测和规划操作。在离线环境中，可能需要在模拟中查询地图，或者在构建要在模拟环境中部署的动态层的设计阶段查询地图。许多AV环境中所需的“高清”(high definition,HD)地图尤其具有挑战性，因为此类地图包含高度详细的几何信息，例如需要处理的厘米精度。

在本文中，场景查询引擎由一个或更多个索引支持，以促进在线和/或离线环境中对静态道路布局的快速结构化查询。在AV应用中，静态道路布局通常以高度结构化的格式(例如OpenDRIVE或其他场景描述语言(或格式、模式)等)表示。

本文的第一方面提供了一种计算机***，包括：计算机存储器、拓扑索引部件、几何索引部件以及场景查询引擎；计算机存储器被配置为存储静态道路布局；拓扑索引部件被配置为生成静态道路布局的内存拓扑索引，拓扑索引是节点和边的图的形式，其中每个节点对应于静态道路布局的道路结构元素，边对道路结构元素之间的拓扑关系进行编码；几何索引部件被配置为生成静态道路布局的至少一个内存几何索引，用于将几何约束映射到静态道路布局的道路结构元素；场景查询引擎被配置为接收几何查询，搜索几何索引以定位满足几何查询的一个或更多个几何约束的至少一个静态道路元素，并且返回至少一个道路结构元素的描述符。场景查询引擎被配置为接收包括至少一个道路元素的描述符的拓扑查询，搜索拓扑索引以定位对应的节点，基于拓扑索引的边中编码的拓扑关系来识别满足拓扑查询的至少一个其他节点，并且返回满足拓扑查询的其他节点的描述符。

道路结构元素可以例如是车道。道路结构元素可以替代地或附加地采取其他形式，例如道路/交叉路口(其中边表示道路/交叉路口之间的拓扑关系)、车道段、车道标记/边界、或者呈现拓扑关系的任何其他类型的道路结构元素。所描述的实施例涉及车道，但一般描述同样适用于其他形式的道路结构元素。

对于车道，拓扑索引的每个节点可以表示静态道路布局的车道，并且每个边可以是从表示第一车道的节点到表示第二车道的节点的定向边，并且指示从第一车道到第二车道的许可车道变更。

拓扑查询可以包括起始车道和目的车道的描述符，场景查询引擎被配置为确定从起始车道到目的车道的车道序列，该车道序列对应于通过图的从表示起始车道的节点到表示目的车道的节点的路径。

每个定向边可能与车道变更成本相关联，并且车道序列可能具有最低的总车道变更成本。

定向边可包括指示许可向前车道变更的向前边和指示许可横向车道变更的横向边。

从表示第一车道的节点到表示第二车道的节点的每个向前边的车道变更成本可以基于第一车道的纵向范围。

从表示第一车道的节点到表示第二车道的节点的每个横向边的车道变更成本可以基于第一车道和第二车道之间的横向距离。

静态道路布局可以包括双向可驾驶车道，其由拓扑索引中的两个单独节点表示，这两个单独节点表示沿着双向可驾驶车道的不同驾驶方向。

几何查询可以是提供位置的控制查询。场景查询引擎可以被配置为使用空间索引来返回包含所提供的位置的道路结构元素的描述符，或者如果没有道路结构元素包含该位置则返回空结果。

场景查询引擎可以被配置为接收提供位置的距离查询，并且返回距距离查询中提供的位置最近的道路结构元素的描述符。

场景查询引擎可以被配置为基于距离查询中提供的位置不包含在任何道路结构元素中的假设来识别最近的道路结构元素。

几何查询可以是提供位置和所需道路结构元素类型的控制查询(特定类型的控制查询)，场景查询引擎被配置为使用空间索引来返回包含所提供的位置的所需道路结构元素类型的车道的描述符，或者如果没有所需道路结构元素类型的道路结构元素包含该位置则返回空结果。

场景查询引擎可以被配置为接收提供位置和所需道路结构元素类型的距离查询(特定类型的距离查询)，并且返回所需道路结构元素类型中距距离查询中提供的位置最近的道路结构元素的描述符。

场景查询引擎可以被配置为基于距离查询中提供的位置不包含在所需道路结构元素类型的任何道路结构元素中的假设来识别最近的道路结构元素。

几何索引部件可以被配置为生成一个或更多个线段索引，该一个或更多个线段索引包含位于道路结构元素之间的边界上的线段，每个线段与道路结构元素标识符相关联地存储。位于两个道路结构元素之间的边界上的每个线段的两个副本可以与这两个道路结构元素的不同道路结构元素标识符相关联地存储在一个或更多个线段索引中。一个或更多个线段索引可以用于处理距离查询。

场景引擎可以被配置为将对特定类型的距离查询的所需道路结构元素类型进行编码的过滤器应用于一个或更多个线段索引，以过滤出与所需道路结构元素类型不匹配的线段，由此过滤出与所需道路结构元素类型不匹配的、关联于第一道路结构元素标识符的线段的第一副本，但是不过滤出与所需道路结构元素类型匹配的、关联于第二道路结构元素标识符的该线段的第二副本。过滤后的一个或更多个线段索引可以用于处理距离查询。

至少一个空间索引可以包括边界框索引，该边界框索引包含用于处理控制查询的道路结构元素或其部分的边界框，每个边界框与道路结构元素标识符相关联。

场景引擎被配置为将对特定类型的控制查询的所需道路结构元素类型进行编码的过滤器应用于边界框索引，以过滤出与所需道路结构元素类型不匹配的线段，过滤后的边界框索引用于处理控制查询。

道路结构元素的描述符可以允许道路结构元素直接根据描述符位于静态道路布局中。

静态道路布局可以被编码在符合结构化场景描述格式的规范中，该描述符允许道路结构元素位于规范中。

计算机***可以被配置为生成规范的内存表示。

规范(或其内存表示)可用于应用该(或每个)过滤器，一个或更多个线段索引或边界框索引中的道路结构元素标识符可用于在规范(的内存表示)中定位所识别的道路结构以应用过滤器。

计算机***可以包括第二应用编程接口，该第二应用编程接口被配置为接收道路结构元素的描述符，使用该描述符来定位静态道路布局中的道路结构元素，从静态道路布局中提取关于道路结构元素的信息片段，并且返回包括提取的信息片段的响应。

从上述规范的内存表示中提取信息片段。

一个或更多个线段索引可以包括内边界线段索引和外边界线段索引。内边界线段索引可用于定位所需道路结构元素类型的最近内边界线段，外边界线段索引可用于定位所需道路结构元素类型的最近外边界线段，并且可以将最近内边界线段和最近外边界线段与所提供的位置进行比较，以确定哪个最接近所提供的位置。

本文的第二方面提供了一种处理对静态道路布局的查询的计算机实现方法，该方法包括：在索引阶段：在内存中生成静态道路布局的车道图，该静态道路布局包括多个车道的网络，该方法包括：为多个车道中的每个车道生成表示车道的车道图的节点；识别静态道路网络中的许可车道变更集合，并且为从第一车道到第二车道的每个许可车道变更，生成从表示第一车道的节点到表示第二车道的节点的定向边；计算每个车道变更的车道变更成本；与边相关联地存储每个边的车道变更成本；在运行时间阶段：接收指示起始车道和目的车道的查询；使用车道图将从起始车道到目的车道的路线确定为车道序列，该车道序列对应于通过车道图的从表示起始车道的节点到表示目的车道的节点的路径，该路径具有最低的总车道变更成本；以及输出对查询的响应，该响应包括路线的描述符。

进一步的方面提供了一种计算机***，该计算机***包括被配置为实现本文公开的方法步骤/***功能中的任何一个的一个或更多个计算机、以及用于对计算机***进行编程以实现该方法步骤/***功能的可执行程序指令。

附图说明

为了更好地理解本公开，并且显示本公开的实施例如何生效，仅通过示例的方式参考以下附图，其中：

图1A显示了自主车辆堆栈的示意性功能框图；

图1B显示了自主车辆测试范式的示意性视图；

图1C显示了场景提取流水线(pipeline)的示意性框图；

图2显示了测试流水线的示意性框图；

图3A显示了用于呈现图形用户界面的可视化部件的示意性框图，测试结果显示在该图形用户界面上；

图3B显示了图形用户界面内可用的视图；

图4显示了场景访问***的示意性框图；

图4A显示了支持场景查询引擎的空间索引集合的示例；

图5显示了示例道路网络；

图6显示了用OpenDRIVE元素注释的道路网络的部分，OpenDRIVE元素用于描述道路网络；

图7显示了从静态道路布局中提取的内存车道图；

图7A显示了具有相关联边成本的车道图的部分；

图8显示了包括双向车道的道路网络的车道图；

图8A显示了具有双向车道的道路网络的部分的另一个示例、以及该道路网络的部分的车道图；

图9显示了道路和在道路上构建的道路分割索引；

图10A显示了包含内车道边界线段的线段树的部分；

图10B显示了线段树中不同级别包含的边界框和内边界线段；

图10C显示了图10B中一些内边界线段的展开视图；

图10D显示了包含外车道边界线段的线段树的部分；

图10E显示了线段树中不同级别包含的边界框和外边界线段；

图10F显示了图10E中一些外边界线段的展开视图；

图11A显示了示例边界框树的部分；

图11B显示了在边界框树中以不同级别存储的边界框；

图11C显示了在图11B的树的最低级别中存储的一些框的展开视图；

图12显示了由道路分割索引支持的几何索引部件的细节；

图13显示了处理控制查询的流程图；

图14A显示了处理轨迹坐标查询的流程图；

图14B显示了处理查询以找到车道中线上最靠近给定(x,y)点的点的流程图；

图15A显示了处理距离查询的流程图；

图15B说明了如何使用外车道边界线段树来找到距给定点最近的未指定类型的车道；以及

图15C说明了如何使用内车道边界线段树和外车道边界线段树来找到距离给定点最近的指定类型的车道；

具体实施方式

描述了一种场景查询引擎(scenario query engine,SQE)，它允许对静态道路布局进行有效的几何和拓扑查询。静态道路布局可以例如在OpenDRIVE或一些其他模式中进行公式化。几何查询和拓扑查询都以可以在原始道路布局描述的上下文中解释的形式返回结果。OpenDRIVE主要针对“在线(on the wire)”处理进行优化。在某种程度上，模式试图避免信息的重复(尽管这绝非硬性规定)。总而言之，OpenDRIVE模式的构建不太适合某些形式的查询，这使得OpenDRIVE的某些应用看起来不切实际。SQE解决了如下所述的这些问题，这开辟了OpenDRIVE和类似模式的新的实际应用。

所描述的技术在自主驾驶中既有“在线”应用，也有“离线”应用。

在线(或“运行时间”)应用是指自主车辆堆栈内支持自主规划或其他决策功能(例如运动规划、运动预测、路线规划等)的实现。在在线环境中，需要规划器实时响应于场景中的变更来为给定场景规划驾驶动作。

离线应用是指其他形式的应用，例如作为支持AV***的开发、测试和/或训练的一套工具的部分。作为示例，下面描述了用于评估真实或模拟场景中的驾驶性能的测试流水线。性能可以包括安全性、舒适性或朝向某个既定目标前进的不同方面。

无论是真实的还是模拟的，场景都需要自我代理来导航真实的或建模的物理环境。自我代理是真实或模拟的移动机器人，该移动机器人在测试中堆栈的控制下移动。物理环境包括静态和/或动态元素，测试中的堆栈需要对该静态和/或动态元素进行有效响应。例如，移动机器人可以是在堆栈的控制下的全自主或半自主车辆(自我车辆)。物理环境可以包括静态道路布局和给定的环境条件(例如天气、一天中的时间、照明条件、湿度、污染/颗粒物水平等)集合，环境条件可以随着场景进展而保持或变化。动态场景还包括一个或更多个其他代理(“外部”代理，例如其他车辆、行人、骑自行车的人、动物等)。

在离线模拟环境中，场景描述作为输入提供给离线模拟器，以便将测试中的堆栈暴露给模拟场景。在在线环境中，感知***可用于生成场景描述，该场景描述可用作更高级功能(例如运动预测和规划)的基础，这可能涉及某种形式的在线模拟，以模拟可能的未来并相应地进行计划。

场景描述可以使用场景描述语言(scenario description language,SDL)进行编码，或者以可以由需要它的部件使用的任何其他形式进行编码。如前所述，ASAM OpenDRIVE(R)标准定义了道路网络的静态描述的存储格式，OpenSCENARIO(R)可用于添加动态内容。可以使用其他形式的场景描述，包括定制的语言和格式，本技术不限于任何特定的SDL、存储格式、模式或标准。

“场景运行”或“场景实例”是指(可选地在一个或更多个其他代理存在的情况下)导航物理环境的代理的具体情况。单个场景描述可以产生多个模拟运行，具有不同的结果，尤其是因为这些结果取决于测试中的堆栈所做的决策。术语“运行”和“实例”在此上下文中可互换使用。

示例AV堆栈

图1A显示了AV运行时间堆栈100的高度示意性框图。堆栈100可以是完全自主或半自主的。例如，堆栈100可以作为自主驾驶***(ADS)或高级驾驶员辅助***(ADAS)来运行。

运行时间堆栈100显示为包括感知(子)***102、预测(子)***104、规划(子)***(规划器)106和控制(子)***(控制器)108。

在真实世界的环境中，感知***102从AV的车载传感器***110接收传感器输出，并使用这些传感器输出来检测外部代理并测量其物理状态，例如其位置、速度、加速度等。车载传感器***110可以采取不同的形式，但通常包括各种传感器，例如图像捕获设备(相机/光学传感器)、激光雷达和/或雷达单元、卫星定位传感器(GPS等)、运动/惯性传感器(加速度计、陀螺仪等)等。车载传感器***110因此提供了丰富的传感器数据，可以从中提取关于周围环境以及AV和该环境内的任何外部参与者(车辆、行人、骑自行车的人等)的状态的详细信息。传感器输出通常包括多个传感器模态的传感器数据，例如来自一个或更多个立体光学传感器、激光雷达、雷达等的立体图像。可以使用过滤器、融合部件等来组合多个传感器模态的传感器数据。

感知***102通常包括多个感知部件，多个感知部件协作以解释传感器输出，从而向预测***104提供感知输出。

在模拟环境中，根据测试的性质，特别是根据堆栈100为测试目的“切片”的位置(见下文)，可能有必要也可能没有必要对车载传感器***100进行建模。对于更高级切片，不需要模拟的传感器数据，因此不需要复杂的传感器建模。

预测***104使用来自感知***102的感知输出来预测外部参与者(代理)(例如AV附近的其他车辆)的未来行为。

由预测***104计算的预测被提供给规划器106，规划器106使用该预测来做出自主驾驶决策，该自主驾驶决策由AV在给定的驾驶场景中执行。规划器106接收的输入通常指示可驾驶区域，还将捕获可驾驶区域内的任何外部代理(从AV的角度来看的障碍物)的预测运动。可以使用来自感知***102的感知输出结合诸如HD(高清)地图之类的地图信息来确定可驾驶区域。

规划器106的核心功能是考虑预测的代理运动而规划AV的轨迹(自我轨迹)。这可以被称为轨迹规划。规划轨迹是为了在场景内实现期望目标。目标可以例如是进入环形交叉路口，然后在期望出口处离开；超过前面的车辆；或者以目标速度停留在当前车道上(车道跟随)。目标可以例如由也被称为目标生成器116的自主路线规划器116来确定。

控制器108通过向AV的车载参与者***112提供合适的控制信号来执行规划器106所做的决策。特别地，规划器106规划AV的轨迹，控制器108生成控制信号以实现所规划的轨迹。通常，规划器106将规划未来，使得在规划器106规划新轨迹之前，所规划的轨迹可以仅在控制级上部分地实现。参与者***112包括“主要”车辆***，例如制动、加速和转向***，以及次要***(例如信号、雨刷、前灯等)。

图1A的示例考虑了相对“模块化的”架构，具有可分离的感知、预测、规划和控制***102-108。子堆栈本身也可以是模块化的，例如在规划***106内具有可分离的规划模块。例如，规划***106可以包括多个轨迹规划模块，该多个轨迹规划模块可以应用于不同的物理环境(例如简单车道驾驶与复杂交叉路口或环形交叉路口)。由于上述原因，这与模拟测试相关，因为它允许单独地或以不同的组合测试部件(例如规划***106或其单独的规划模块)。为避免疑义，对于模块化堆栈架构，术语堆栈不仅可以指完全堆栈，还可以指其任何单独的子***或模块。

在不同堆栈实现之间，各种堆栈功能的集成或可分离程度可能会有很大差异—在某些堆栈中，某些方面可能紧密耦接，无法区分。例如，在其他堆栈中，可以集成规划和控制(例如此类堆栈可以直接根据控制信号进行规划)，而其他堆栈(例如图1A中描绘的堆栈)可以以在两者之间画出明显区别的方式来构建(例如根据轨迹进行规划，以及通过单独的控制优化来确定如何在控制信号水平上最好地执行所规划的轨迹)。类似地，在某些堆栈中，预测和规划可以更紧密地耦接。在极端情况下，在所谓的“端到端”驾驶中，感知、预测、规划和控制可能本质上不可分割。除非另有说明，否则本文中使用的感知、预测规划和控制术语并不意味着这些方面的任何特定耦接或模块化。

“完全”堆栈通常涉及从低级传感器数据(感知)的处理和解释到主要的更高级功能(例如预测和规划)的所有内容，以及生成适当控制信号以实现规划级决策(例如控制制动、转向、加速等)的控制逻辑。对于自主车辆，3级堆栈包括一些实现过渡需求的逻辑，4级堆栈还包括一些用于实现最小风险策略的逻辑。堆栈还可以实现辅助控制功能，例如信号、前灯、挡风玻璃雨刷等。

术语“堆栈”也可以指完全堆栈的单独子***(子堆栈)，例如感知、预测、规划或控制堆栈104、106、108，它们可以单独地测试或以任何期望的组合进行测试。堆栈可以纯粹指软件，即可以在一个或更多个通用计算机处理器上执行的一个或更多个计算机程序。应当理解，术语“堆栈”包括软件，但也可以包括硬件。在模拟中，在最终上传到物理车辆的车载计算机***之前，可以在“通用”车外计算机***上测试堆栈的软件。然而，在“硬件在环(hardware-in-the-loop)”测试中，测试可能会扩展到车辆本身的底层硬件。例如，为了测试的目的，堆栈软件可以在耦接到模拟器的车载计算机***(或其副本)上运行。在这种情况下，测试中的堆栈扩展到车辆的底层计算机硬件。作为另一示例，堆栈110的某些功能(例如感知功能)可以在专用硬件中实现。在模拟环境中，硬件在环测试可能涉及将合成的传感器数据馈送到专用硬件感知部件。

在堆栈100内，场景描述116可以用作规划和预测的基础。场景描述116使用感知***102与高清(HD)地图114一起生成。通过在地图上定位自我车辆114，可以将感知***104中提取的信息(包括动态代理信息)与HD地图114中包含的预先存在的环境信息相结合。场景描述116又被用作预测***104中运动预测的基础，所得到的运动预测118与场景描述116组合使用，作为用于规划***106中的规划的基础。

示例测试范式

图1B显示了自主车辆的测试范式的高度示意性概述。通过在模拟器202中运行多个场景实例，并且在测试预言机252中评估堆栈100(和/或其单个子堆栈)的性能，例如图1A中所描绘类型的ADS/ADAS堆栈100在模拟中经受重复测试和评估。测试预言机252的输出向专家122(团队或个人)提供信息，允许他们识别堆栈100中的问题并修改堆栈100以缓解这些问题(S124)。该结果还帮助专家122选择进一步的场景进行测试(S126)，并且该过程继续，在模拟中重复修改、测试和评估堆栈100的性能。改进的堆栈100最终结合(S125)在配备有传感器***110和参与者***112的真实世界的AV 101中。改进的堆栈100通常包括在车辆101的车载计算机***的一个或更多个计算机处理器(未示出)中执行的程序指令(软件)。在步骤S125处，将改进的堆栈的软件上传到AV 101。步骤S125还可以涉及对底层车辆硬件的修改。在AV 101上，改进的堆栈100从传感器***110接收传感器数据，并向参与者***112输出控制信号。真实世界测试(S128)可以与基于模拟的测试结合使用。例如，在通过模拟测试和堆栈细化的过程达到可接受的性能水平之后，可以选择适当的真实世界场景(S130)，并且可以在测试预言机252中捕获和类似地评估AV 101在那些真实场景中的性能。

可以以各种方式(包括手动编码)获得用于模拟目的的场景。该***还能够从真实世界的运行中提取用于模拟目的的场景，允许在模拟器202中重新创建真实世界的情况及其变化。

图1C显示了场景提取流水线的高度示意性框图。真实世界运行的数据140被传递到“地面实况”流水线142，用于生成场景地面实况的目的。运行数据140可以包括，例如，在一个或更多个车辆(其可以是自主的、人类驱动的或其组合)上捕获/生成的传感器数据和/或感知输出、和/或从诸如外部传感器(CCTV等)的其他源捕获的数据。在地面实况流水线142内处理运行数据，以便为真实世界运行生成适当的地面实况144(“迹线”和上下文数据)。地面实况处理可以基于“原始”运行数据140的手动注释，或者该处理可以是完全自主的(例如使用离线感知方法)，或者可以使用手动和自主地面实况的组合。例如，3D边界框可以被放置在运行数据140中捕获的车辆和/或其他代理周围，以便确定它们的迹线的空间和运动状态。场景提取部件146接收场景地面实况144，并且处理场景地面实况144以提取可用于模拟目的的场景描述148。场景描述148由模拟器202使用，从而允许从中导出多个模拟运行。为每个模拟运行提供地面实况150。

“迹线”是在场景过程中代理的位置和运动的历史。迹线有多种表示方式。迹线数据通常将包括环境内的代理的空间和运动数据。该术语用于真实场景(具有真实世界迹线)和模拟场景(具有模拟迹线)。

术语“感知”通常指用于感知真实世界数据140中的结构的技术，例如2D或3D边界框检测、位置检测、姿势检测、运动检测等。例如，迹线可以被提取为(例如在鸟瞰参考系中的)3D空间或2D空间中的边界框或其他空间状态的时间序列、以及相关联的运动信息(例如速度、加速度、急动等)。在图像处理背景下，这类技术通常被归类为“计算机视觉”，但术语感知涵盖了更广泛的传感器模态。

测试流水线

现在将描述包含测试预言机252的示例测试流水线的进一步细节。下面的示例专注于基于模拟的测试。然而，如前所述，测试预言机252同样可以应用于评估真实场景上的堆栈性能，下面的相关描述同样适用于真实场景。以下描述以图1A的堆栈100为例进行说明。然而，如前所述，测试流水线200是高度灵活的，并且可以应用于以任何自主级运行的任何堆栈或子堆栈。

图2显示了测试流水线的示意性框图，该测试流水线由附图标记200表示。测试流水线200被示出为包括模拟器202和测试预言机252。模拟器202运行模拟场景以测试AV运行时间堆栈100的全部或部分，测试预言机252评估堆栈(或子堆栈)在模拟场景上的性能。如所讨论的，可能仅测试运行时间堆栈的子堆栈，但为了简单起见，以下描述通篇涉及(完全)AV堆栈100。然而，该描述同样适用于子堆栈而不是完全堆栈100。术语“切片”在本文中用于选择用于测试的堆栈部件的集合或子集。

基于模拟的测试的想法是运行模拟驾驶场景，自我代理必须在被测试的堆栈100的控制下导航。通常，通常在存在一个或更多个其他动态代理(例如其他车辆、自行车、行人等)的情况下，该场景包括自我代理需要导航的静态可驾驶区域(例如特定的静态道路布局)。为此，将模拟输入203从模拟器202提供给测试中的堆栈100。

堆栈的切片决定了模拟输入203的形式。例如，图2显示了正在测试的AV堆栈100内的预测、规划和控制***104、106和108。为了测试图1A的完全AV堆栈，也可以在测试期间应用感知***102。在这种情况下，模拟输入203将包括合成的传感器数据，该合成的传感器数据使用适当的传感器模型生成并在感知***102内以与真实传感器数据相同的方式进行处理。这需要生成足够真实的合成的传感器输入(例如真实感图像数据和/或同样真实的模拟激光雷达/雷达数据等)。感知***102的结果输出将依次馈送到更高级预测和规划***104、106。

相比之下，所谓的“规划级”模拟将基本上绕过感知***102。模拟器202将直接向预测***104提供更简单、更高级的输入203。在一些情况下，甚至可以适当地绕过预测***104，以便在直接从模拟场景获得的预测(即“完美”预测)上测试规划器106。

在这些极端之间，存在许多不同级输入切片的范围，例如仅测试感知***102的子集，例如“稍后”(更高级)感知部件，例如对较低级感知部件(例如对象探测器、边界框探测器、运动探测器等)的输出进行操作的过滤器或融合部件等部件。

作为合成的传感器数据的替代方案，可以对感知***102的全部或部分进行建模，例如使用一个或更多个感知误差模型将真实误差引入模拟输入203。例如，可以使用感知统计性能模型(Perception Statistical Performance Model,PSPM)或同义词“PRISM”。PSPM的原理以及用于构建和训练这样的模型的适当技术的进一步细节可以结合在国际专利公开号WO2021037763、WO2021037760、WO2021037765、WO2021037761和WO2021037766中，这些国际专利中的每一个都通过引用整体并入本文。

无论它们采取何种形式，模拟输入203都被(直接或间接地)用作规划器108做出决策的基础。控制器108又通过输出控制信号109来实现规划器的决策。在真实世界背景中，这些控制信号将驱动AV的物理参与者***112。在模拟中，自我车辆动态模型204用于将所得到的控制信号109转换为模拟内的自我代理的真实运动，从而模拟自主车辆对控制信号109的物理响应。

或者，一种更简单的模拟形式假设自我代理在规划步骤之间精确地遵循每个所规划的轨迹。该方法(在其与规划可分离的程度上)绕过控制***108并且消除对自我车辆动态模型204的需要。这可能足以测试规划的某些方面。

在一定程度上，外部代理在模拟器202内表现出自主行为/决策，某种形式的代理决策逻辑210被实现以执行这些决策并确定场景内的代理行为。代理决策逻辑210的复杂性可能与自我堆栈100本身相当，也可能具有更有限的做出决策的能力。目的是在模拟器202内提供足够真实的外部代理行为，以便能够有效地测试自我堆栈100做出决策的能力。在一些情况下，这根本不需要任何代理决策逻辑210(开环模拟)，并且在其他情况下，可以使用相对有限的代理逻辑210(例如基本自适应巡航控制(adaptive cruise control,ACC))来提供有用的测试。如果合适的话，可以使用一个或更多个代理动态模型206来提供更真实的代理行为。

根据场景描述201运行场景，该场景描述201通常具有静态和动态元素。静态元素通常包括静态道路布局。动态元素通常包括场景内的一个或更多个外部代理，例如其他车辆、行人、自行车等。场景运行由测试编排部件260编排。

为每个外部代理提供给模拟器202的动态信息的范围可以变化。例如，可以通过可分离的静态层和动态层来描述场景。给定的静态层(例如定义道路布局)可以与不同的动态层组合使用，以提供不同的场景实例。对于每个外部代理，动态层可以包括代理要遵循的空间路径以及与该路径相关联的运动数据和行为数据中的一个或两个。在简单的开环模拟中，外部参与者简单地遵循在动态层中定义的空间路径和运动数据，该动态层是非反应性的，即不对模拟内的自我代理做出反应。这样的开环模拟可以在没有任何代理决策逻辑210的情况下实现。然而，在闭环模拟中，动态层反而定义了沿着静态路径要遵循的至少一种行为(例如ACC行为)。在这种情况下，代理决策逻辑210以反应性方式在模拟内实现该行为，即对自我代理和/或其他外部代理作出反应。运动数据仍然可以与静态路径相关联，但在这种情况下是不太规范的，并且可以例如用作沿着路径的目标。例如，对于ACC行为，可以沿着代理将寻求匹配的路径设置目标速度，但是可以允许代理决策逻辑210在沿着该路径的任何点处将外部代理的速度降低到目标以下，以便保持与前方车辆的目标车头时距。

给定模拟的模拟器202的输出包括自我代理的自我迹线212a和一个或更多个外部代理的一个或更多个代理迹线212b(迹线212)。每个迹线212a、212b是具有空间分量和运动分量的模拟内的代理行为的完整历史。例如，每个迹线212a、212b可以采取空间路径的形式，该空间路径具有与沿着该路径的点相关联的运动数据，例如速度、加速度、急动(加速度变化率)、突然移动(snap)(急动变化率)等。

还提供了附加信息，以补充并向迹线212提供上下文。这样的附加信息被称为“上下文”数据214。上下文数据214属于场景的物理上下文，并且可以具有静态分量(例如道路布局)和动态分量(例如天气条件在模拟过程中变化的程度)。

测试预言机252接收迹线212和上下文数据214，并根据一组性能评估规则254对这些输出进行评分。性能评估规则254被示出为被提供作为测试预言机252的输入。

规则254本质上是分类的(例如通过/失败类型的规则)。某些性能评估规则还与用于“评分”轨迹的数字性能度量(例如指示成功或失败的程度或有助于解释分类结果或与分类结果相关的某些其他量)相关联。规则254的评估是基于时间的—给定规则在场景中的不同点处可能具有不同的结果。评分也是基于时间的：对于每个性能评估度量，测试预言机252跟踪该度量的值(分数)如何随着模拟的进行而随时间变化。测试预言机252提供输出256，输出256包括每个规则的分类(例如通过/失败)结果的时间序列256a、以及每个性能度量的分数-时间图256b，如稍后进一步详细描述的。结果和分数256a、256b向专家122提供信息，并且可以用于识别和缓解测试堆栈100内的性能问题。测试预言机252还提供该场景的总体(聚合)结果(例如总体通过/失败)。测试预言机252的输出256与关于输出256所属的场景的信息相关联地存储在测试数据库258中。

图3A显示了可视化部件320的示意性框图。可视化部件320被示出为具有连接到测试数据库258的输入，用于在图形用户界面(graphical user interface,GUI)300上呈现测试预言机252的输出256。GUI被呈现在显示***322上。

图3B显示了GUI 300的示例视图。该视图属于包含多个代理的特定场景，并且被示为包括场景可视化301和一组驾驶性能评估结果302。在该示例中，测试预言机输出526属于多个外部代理，并且根据代理来组织结果。对于每个代理，在场景中的某个点处，适用于该代理的每个规则都有结果的时间序列。彩色编码用于区分特定规则的通过/失败周期。

场景查询引擎

上述场景描述116、148、201通常非常详细。3D道路和车道几何形状需要高水平的精度，通常达到厘米精度。复杂的驾驶场景可能涉及道路网络和交叉路口。直接从场景描述中提取所需的信息片段通常是低效和耗时的。为此，提供了一种场景查询引擎，该场景查询引擎允许对驾驶场景描述执行结构化查询的快速处理。场景查询引擎有许多应用，包括图1A中所描绘类型的在线应用和图1C和图2中所描绘类型的离线应用。

图4显示了场景访问***400的示意性框图。场景访问***400代表需要访问驾驶场景描述412的其他***部件而提供优化的信息检索。

场景描述412被示为具有静态层414和动态层416。在该示例中，静态层414被编码在符合OpenDRIVE模式或OpenDRIVE的某个变体(或其他结构化场景描述格式)的规范(文档)中，使用OpenSCENARIO对动态层416进行编码。

场景访问***被示为包括场景查询引擎(SQE)402和提取部件404。SQE 402经由第一应用编程接口(403)被调用，信息提取部件404经由第二API(application programminginterface，应用编程接口)405被调用。

第一API 403提供一组场景查询函数，该组场景查询函数可以灵活组合以对驾驶场景412执行复杂查询，第二API 405提供一组信息提取函数，用于从驾驶场景412选择性地提取信息。描绘了构建在API 403、405上的***部件401。可以以这种方式在API 403、405上构建不同的***部件，从而减轻软件开发人员的负担。***部件401可以例如是在线堆栈100的部件(例如规划或预测***104、106或其某些部件)或离线部件(例如测试流水线200内的模拟器202)。

SQE 402接受对场景描述412的“几何”和“拓扑”查询。各种场景查询函数以“描述符”的形式提供结果，该“描述符”允许信息位于底层场景描述412中。以下示例考虑在静态层414上的几何查询和拓扑查询。

几何查询418指示一个或更多个几何约束419(几何输入)，并且以描述符的形式返回响应420，该描述符标识满足几何约束419的一个或更多个道路结构元素。

描述符包括每个道路结构实体的标识符，该标识符允许定位静态层412的相应部分(即，描述该道路结构元素的部分)(由描述符420的附图标记421表示)。描述符可以包含关于满足查询的道路结构元素的附加信息。例如，几何输入419可以定义点或框(矩形)，响应可以指示与该点或框相交的任何道路结构元素。

为了便于几何查询，提供了几何索引部件408。几何索引部件408建立场景描述412的静态层414的几何(空间)索引409。几何索引409是将几何输入映射到场景描述412内的相应道路结构元素的内存数据结构。在以下示例中，“道路”和“车道”是考虑的主要道路元素类型。如下面进一步详细描述的，在OpenDRIVE中，道路根据<road>元素描述，车道根据<lane>元素描述。尽管描绘了单个几何索引409，但是可以为不同类型的道路结构元素提供单独的几何索引，例如用于道路和车道的单独的空间索引。

为了支持高效的几何查询，引入了新颖的“道路部分”和“车道部分”概念。这些概念及其利用方式在下面的表1中进行了描述。

几何索引409是二维的(two-dimensional,2D)，定义在道路网络的鸟瞰图平面中。静态层414可以是三维的(three-dimensional,3D)(例如用于描述变化的道路高程)，即使几何索引409是2D的。在其他实现中，几何索引409是三维的。三维空间索引可能是有用的，例如在解决与下/上通道相关联的平面视图中固有的模糊性方面(其中一个道路从另一个道路下通过，导致2D平面视图中的模糊性)。

虽然几何索引409在图4中被描绘为单个元素，但在所描述的实现中，API 403由几何索引的集合支持。

图4A显示了多个几何索引，即边界框树450、内边界线段树452a和外边界线段树454b，每一个都在下面详细描述。

拓扑查询422包括一个或更多个道路结构元素(输入元素)的输入描述符423，并且以满足拓扑查询的一个或更多个道路结构元素(输出元素)(因为它们与输入元素具有某些定义的拓扑关系)的输出描述符424的形式返回响应。例如，拓扑查询可能指示起始车道和目的车道，并且请求从起始车道到目的车道的一组“微路线(micro route)”，其中微路线被定义为从前者到后者的可穿越的车道序列。这是本文所称的“微规划”的示例(进一步的细节参见图6)。可以为不同类型的拓扑关系定义不同的拓扑查询类型。

为了便于拓扑查询，拓扑索引部件410构建静态层414的拓扑索引411。拓扑索引411是道路结构元素的内存图。图的节点对结构元素进行编码，图的边表示道路结构元素之间的代码拓扑关系。节点在内存中体现为可寻址存储器位置，而边作为内存点指向相应的存储器地址。尽管描绘了单个索引，但在以下示例中，构建了单独的拓扑索引—“道路图”和“车道图”。进一步的细节参见图7和图8。

第二API 426将描述符426中提供的信息映射到场景描述412的相应部分。响应于静态层416的描述符426，信息提取部件404提供从静态层414的相应部分提取的一条或更多条场景数据428。例如，给定指示特定车道的描述符426，信息提取部件404将能够提供例如来自静态层414的车道的3D几何形状或来自动态层416的某些相关联的信息片段(例如指示起始位置位于特定道路或车道内的任何代理)。

几何查询和拓扑查询可以灵活组合。例如，从某些几何约束开始，几何查询可以返回相应道路或车道的描述(例如以找到包含点x的车道)。后者然后可以用作拓扑查询的基础(例如以找到连接到包含点x的车道的所有车道)。

几何查询和拓扑查询都以可以在原始静态层414的上下文中解释的形式返回结果。在几何查询418上返回的描述符420直接映射到静态层414中的相应部分(例如对与点x相交的车道的查询将返回直接映射到描述所讨论车道的部分的描述符)。拓扑查询也是如此。

虽然图4描绘了具有静态层和动态层416的驾驶场景412，但该技术可应用于没有动态层的静态道路布局的描述。

还显示了道路分割索引407，该道路分割索引407由道路索引部件432生成，并在下文中详细描述。道路分割索引407用于建立几何索引408，并且还用于直接在SQE API 403处支持某些查询模式。道路索引部件432由道路分割部件430支持，其功能在下文描述。

下面的表1中总结了支持SQE 402内的几何查询的某些新概念。该概念在OpenDRIVE模式中找不到，引入该概念是为了允许构造几何查询，以便快速处理该几何查询。

表2总结了图4和图4A中所示的各种索引的构建。

表3总结了如何使用这些索引来支持SQE API 403处的某些查询模式。

表1至表3引用了某些OpenDRIVE概念，这些OpenDRIVE概念的进一步描述遵循表3。虽然OpenDRIVE被用作参考点，但所描述的技术可以应用于其他道路网络模式，具有与本文所述相同的优点。

/>

表1：附加概念的概述。

/>

表2：索引的概要。

/>

表3：查询模式的概要。

对于使用上述树的特定类型的查询，直接从包含静态层414的文档的内存表示中检索所需的任何侧车道属性。谓语应用于整个树，并且只考虑那些满足谓语的索引值。可以支持一系列谓语(例如车道类型、支持道路类型(是否在交叉路口)等)，也可以支持任意组合，例如“给我最近的侧车道，该侧车道是在交叉路口的驾驶车道或自行车道”。因此，在图9中，所描绘的道路函数902、…、910可以存储在文档本身的内存表示中，并且使用由道路分割索引407返回的束从文档的内存表示进行检索。

在所描述的示例中，道路/车道属性未存储在空间索引内(但可以存储在其他实现中)。相反，首先基于活动谓语对索引进行过滤，并且在过滤后的索引上运行查询(使得在处理查询时不考虑不满足活动谓语的元素)。

如将理解的，上面总结的索引和查询类型的特定选择并不旨在穷举，而仅仅是说明如何在特定实现中应用该技术。

示例道路网络：

图5示意性地描绘了在静态层414中编码的示例类型的道路网络500。以下描述假设使用OpenDRIVE模式或采用来自OpenDRIVE的某些定义和约定的类似格式来描述道路网络500。然而，应当理解，该原理更一般地扩展到其他格式，并且所描述的技术不限于任何特定的数据格式或模式。

道路网络500显示为包括第一道路502、第二道路504、第三道路506和第四道路508(道路1至4)，这些道路分别用具有道路标识符(ID)1、2、3和4的＜road＞元素来描述。道路502-508经由由＜junction＞元素描述的交叉路口510互连。道路502-508中的每一个都由单个道路参考线定义，指示为粗实心箭头，并且包含宽度为零的单个中心车道。中心车道没有单独描绘，并且为了简单起见，假设每个道路502-508的中心车道沿着道路参考线(尽管如前所述，可以定义道路参考线和中心车道之间的非零偏移)。第一道路502和第二道路504的道路参考线分别由附图标记503和505指示。道路参考线是定向的，并且可以更准确地描述为道路的纵轴或“s轴”，s坐标沿着该轴运行，t坐标与之正交运行。如参考线503、505所描绘的，正t方向定义为延伸到s轴的左边。车道相对于中心车道进行编号；中心车道始终编号为0，中心车道左边的侧车道(+t)分配了递增的正车道编号(1、2、3、…)，右边的车道(-t)分配了递减的负车道编号(-1、-2、-3、…)。

每个侧车道都有车道类型，可能的类型分为仅支持单向驾驶的车道和支持双向驾驶的车道。在SQE API 403中引入了“侧车道方向”概念来处理这一问题。然后，可以根据道路参考曲线的取向和由场景描述412提供的支持道路的道路交通规则来推导单向侧车道的方向。

每个道路至少有一个侧车道。在该示例中，第一道路502在中心车道的左边仅具有正编号的侧车道，而第二道路504在中心车道的左边具有两个正侧车道，并且在右边具有一个负侧车道。道路可划分为“车道段”，以容纳具有不同车道数量的道路路段(参见下文)。

在以下描述中，“车道n”是指车道编号为“n”的车道，“道路m”是指道路ID为“m”的道路。其他道路元素(例如交叉路口)也以同样的方式提及。在OpenDRIVE中，车道段没有指定明确的标识符。在静态层描述416中通过车道链接明确描述了单个道路内的连续车道部分中的侧车道之间的关系，并且这些关系用于构建由道路支持的拓扑索引411的部分。相邻关系隐含在侧车道编号***中，尽管有向侧车道图不支持穿过中心车道的边遍历，因为这意味着进入迎面而来的交通流(参见下文关于双向侧车道的内容)。

为了简洁起见，相邻车道段可被称为“车道段n”和“车道段n+1”，即使车道段编号n、n+1不构成OpenDRIVE模式的部分。

本示例描绘了左侧交通(left-hand traffic,LHT)道路***。然而，该模式可以用于LHT或右侧交通(right-hand traffic,RHT)网络。每个<road>元素的“规则”属性指示道路是LHT(车辆在左边驾驶)还是RHT(车辆在右边驾驶)。

定义了全局笛卡尔坐标系，其中x方向向东，y轴向北延伸(OpenDRIVE称之为惯性坐标系)。

车道编号仅指示道路内交通流的相对方向：对于任何给定的道路，编号为正的单向侧车道的交通流方向相同，编号为负的单向侧车道则方向相反。双向车道支持双向交通流，而不考虑道路交通规则。然而，单独的车道编号不足以推断交通流的方向，因为s轴的方向可以(或多或少)任意选择，并且不指示驾驶方向。例如，在图5中，第二道路504的s轴505从东朝向交叉路口延伸，而第四道路508的s轴从西朝向交叉路口510沿着相反方向延伸。因此，沿着第二道路504，正车道编号指示从东到西的交通流方向，而沿着第四道路508，由负车道编号指示东西向交通流。对于LHT道路，道路参考线的左边(+t)的车道承载道路参考线方向(+s)的交通，而道路参考线的右边(-t)的车道承载相反方向(-s)的交通。在RHT道路中，道路中心线的左边(+t)的车道承载与道路参考线的相反方向(-s)的交通，而右边(-t)的车道承载道路参考线的方向(+s)的交通。

还可以定义双向侧车道，通过将<lane>元素的^@类型属性设置为“双向”，允许双向交通流。下文更详细地介绍了双向车道。

因此，为了确定交通流的绝对方向，车道编号是不够的；道路参考线的方向(s轴)也必须考虑，^@类型属性也必须考虑。

车道不一定可以驾驶。例如，道路2的车道段2的车道1不可驾驶。道路的外边界也可以由不可驾驶的车道(例如人行路面/人行道类型的车道)来定义。

链接元素用于明确定义道路和车道之间的链接。在只有两个道路的情况下，只要链接是明确的，就可以直接使用道路之间的链接元素来定义链接。更复杂的链接需要使用交叉路口元素。

＜link＞元素可以具有＜successor＞元素和＜predecessor＞元素中的一个或两个。道路的前驱(Predecessor)/后继(successor)可以是另一个道路或交叉路口。车道的前驱/后继是另一个车道。“前驱”和“后继”关系相对于所讨论道路的s轴来定义(道路的t轴从其前驱(如果有)运行到其后继(如果有))，并且不指示驾驶方向。道路的s轴从其前驱(如果有)朝向其后继(如果有)运行。

前驱/后继关系可能是“不对称的”。例如，如果道路n是道路m的前驱，这并不意味着道路m是道路n的后继；如果道路n的s轴与道路m的s轴方向相反，则道路m也可以是道路n的前驱。作为另一个示例，如果道路m是交叉路口的部分，则道路m不能是道路n的前驱或后继，因为该交叉路口将是道路n的前驱/后继(进一步的示例参见下文)。

使用车道段容纳具有不同车道数量的道路。在OpenDRIVE模式内，车道在<road>元素的<lanes>元素内进行描述。<lanes>元素可以通过<laneSection>元素划分为多个部分(车道段)。每个单独的车道由<laneSection>元素内的<lane>元素定义。每个车道段都有固定数量的车道，按照上述约定进行编号。例如，第一道路502被显示为划分为两个车道段(道路1的车道段1和车道段2)：在接近交叉路口510时，车道的数量被显示为从两个增加到三个。在从第一道路502的车道段1进入车道段2时，创建了新的最右侧车道，其宽度从零逐渐增加。在车道段1中，(中心车道的左边的)最左侧和最右侧车道分别编号为2和1，而在车道段2中，最左侧车道和新的最右侧车道分别编号为3和1；现在中间车道编号为2。

使用<link>元素描述了相邻车道段中车道之间的链接。在车道段2中，车道段1的车道2是车道段2的车道3的前驱，车道段1的车道1是车道段2的车道2的前驱。也就是说，描述车道段2的车道3的车道元素将包含指示车道2作为其前驱的链接元素，并且隐含地，该链接指的是紧接在前的车道段(车道段1)等。

同样，在车道段1中，车道段2的车道3是车道段1的车道2的后继，车道段2的车道2是车道段1的车道1的后继。也就是说，描述车道段1的车道2的车道元素将指示车道3作为其后继，并且隐含地，该链接指的是下一个车道段(车道段2)等。

由于车道段2的车道1最初的宽度为零，因此它未链接到车道段1的任何车道。然而，在不同情况下，车道可能有多个后继或前驱，例如如果一个车道立即拆分为两个车道，每个车道在车道段边界处的宽度均为非零。

在图的交叉路口元素510中，定义了附加道路，其参考线被描绘为粗实心箭头。在该示例中，第五道路至第九道路512、514、516、518、520(道路5至9)被描绘在交叉路口510内。尽管图5中未描绘交叉路口510内的侧车道，但是交叉路口510内的每个道路也需要有至少一个非零宽度的侧车道。

在图5中，交叉路口510是第一道路502、第二道路504和第四道路508的后继，因为它们各自的s轴朝向交叉路口510延伸。因此，描述那些道路502、504、508的＜road＞元素将包含具有＜successor＞元素的＜link＞元素，＜successor＞元素指示交叉路口510。交叉路口510是第三道路506的前驱，因为其s轴远离交叉路口延伸，描述第三道路506的<road>元素因此将包含具有指示交叉路口510的<predecessor>元素的<link>元素。

在交叉路口元素510内，连接道路由＜road＞和＜connection＞元素描述。

第五道路512(道路5)被示为连接第一道路502和第三道路506。第五道路512由<junction>元素510内的<road>元素定义，第一道路502是其前驱，第三道路506是其后继(经由描述第五道路506的<road>元素中的<predecessor>和<successor>元素定义)。类似地，第六道路514具有作为其后继的第四道路508和作为其前驱的第二道路504。第七道路516连接第二道路504和第三道路506，其中第二道路504作为其前驱，第三道路506作为其后继。第八道路518连接第二道路504和第一道路502，其中第二道路504作为后继，第一道路502作为前驱。最后，第九道路520连接第一道路502和第四道路508，其中第四道路508作为其后继，第一道路502作为其前驱。同样，前驱/后继关系并不是驾驶方向的直接指示。

＜connection＞元素用于指示连接交叉路口的交通的驾驶方向。连接元素指示进场道路(incoming road)和连接道路(但未明确定义出场道路(outgoing road))，其中交通从进场道路进入交叉路口到连接道路。例如，将提供第一＜connection＞元素，其指示ID＝1的道路(第一道路502)作为进场道路并且ID＝5的道路(第五道路512)作为连接道路；该连接元素指示交通可以从第一道路502进入交叉路口510到第五道路512。第二＜connection＞元素将第一道路502指示为进场道路，将第八道路518指示为连接道路等。在该示例中，第七连接道路516是双向道路，承载从第二道路504到第三道路506的交通以及相反方向的交通。因此，将使用两个＜connection＞元素，一个将第二道路指示为进场并且将第七道路516指示为连接，而另一个将第三道路506指示为进场并且将第七道路516指示为连接。OpenDRIVE规范强烈建议不要使用双向连接道路，尽管使用该模式可以实现双向连接道路。第七连接道路516违背了这一建议，但并不违反这一建议(而且，在实践中，更有可能定义两个单向连接道路)。第四道路508不是到交叉路口510的进场道路(即使其s轴朝向交叉路口510延伸)，因为它是仅将交通从交叉路口510带走的单向道路。

当交叉路口510内可能发生车道变更时，使用具有多个车道的连接道路；如果不允许车道变更，将使用多个单车道道路。

“虚拟”连接也可以在没有任何连接道路的情况下使用<connection>元素进行描述。虚拟连接限于“虚拟”交叉路口，不需要拆分主干道。

车道之间的链接经由描述这些车道的<lane>元素内的链接元素来描述，其中前驱车道和后继车道的描述方式与道路相似。为了使第一道路的第一车道成为第二道路的第二车道的前驱或后继，第二道路必须是第一道路的前驱或后继。由于交叉路口510是第一道路502、第二道路504和第四道路508的后继，因此这些道路502、504、508没有直接的后继道路；因此，他们的任何车道都不可能有车道后继。同样地，由于交叉路口510是第三道路506的前驱，因此第三道路506不具有直接的前驱道路；因此，它的车道不可能具有任何前驱。然而，在交叉路口501内，连接道路512-5120中的每一个都具有直接的后继道路和直接的前驱道路；例如，第五道路512的直接的后继道路是第一道路502并且其直接的前驱是第三道路506。因此，连接道路512-520的车道可以链接到它们的前驱道路和它们的后继道路的车道。例如，第五道路512通常将包含两个正编号的侧车道1和2。图5中未描绘道路5的侧车道，但是图6中示出了该侧车道。描述道路5的车道2和1的车道元素将依次包含链接元素，该链接元素指示车道编号“3”和“2”作为其各自的前驱(隐含地，这些是道路5’的后继车道，即道路1)，车道编号“2”和“1”作为其相应的后继(隐含地是指道路5’的后继，即道路3)。<connection>元素还包含应用于它的任何车道链接(进一步的细节参见图6和下文的描述)。

在许多情况下，根据车道确定通过道路网络500的全部或部分的路线是有用的。这在本文中被称为“微规划”。微规划的目的是确定符合某些给定标准(例如当前和目标车道)的一个或更多个定向车道序列(“微路线”)。虽然通常感兴趣的是可行驶的侧车道序列，但可以考虑不可驾驶的序列，例如用于引导行人。

例如，给定当前车道和目标车道(目标)，应用可能需要，例如，从目标车道到目标车道的最短路线、或者从前者到后者的所有可能路线。例如，假设当前车道是车道段1的车道2或道路1，目标是道路3的车道1。以下车道序列(车道序列1)是从前者到后者的一种可能的路线：

((车道2、车道段1、道路1)、(车道3、车道段2、道路1)、(车道2、道路5)、(车道2、道路3)、(车道1、道路3))。

为了简洁起见，上述语法仅包括具有多个车道段的道路的车道段索引，以避免歧义。在实践中，每个OpenDRIVE道路具有至少一个车道段，“(车道M、道路M)”暗示(车道M、车道段1、道路N)，其中车道段1是道路N中定义的单个车道段(除非另有说明)。

也就是说，从道路1的车道段1的车道2向前行进到道路1的车道段2的车道3，进入道路5的车道2处的交叉路口510，在道路3的车道2的交叉路口处离开，然后变更到道路3的车道1。

另一种可能的车道序列(车道序列2)是：

((车道2、车道段1、道路1)、(车道1、车道段1、道路1)、(车道2、车道段2、道路1)、(车道1、道路5)、(车道1、道路3))。

也就是说，从道路1的车道段1的车道2开始，变更到同一车道段的车道1，移动到道路1的车道段2的车道2中，进入道路5的车道1处的交叉路口510，以及在车道1或道路3处的交叉路口离开。

虽然具有驾驶经验的人相对容易确定这样的车道序列，

图6显示了图5的道路网络500的部分，用OpenSCENARIO代码的部分来注释，OpenSCENARIO代码定义了道路网络的某些元素。

从任何进场道路502、506、506的任何车道开始，交叉路口内的＜connection＞元素描述了通过交叉路口510(在道路级)的所有可能的路线。对于给定道路上的给定车道，获得通过交叉路口的所有路线的列表将意味着定位所有<connection>元素，该<connection>元素经由其道路ID将所讨论道路标识为进场道路，并且还具有与所讨论车道链接的车道。为了获得进一步的车道链接，则需要定位其连接道路的＜road＞元素，以便识别出场道路(对于第五道路512，出场道路将是第三道路506)，并且确定连接道路和出场道路之间的车道链接。

第一代码部分602包含连接元素(连接ID＝0)，该连接元素将第一道路502(ID为1的道路)指示为进场道路并且将第五道路512(ID为5的道路)指示为连接道路。第一和第二<laneLink>元素将道路1(其进场道路)的车道3链接到道路5的车道2，并且将道路1的车道2链接到道路5的车道1。代码604的第二部分包含描述交叉路口510(交叉路口ID＝0)内的道路5的＜road＞元素。道路元素内的<link>元素包含<successor>和<predecessor>元素。前驱元素中的道路链接将道路1指示为道路5的前驱，这反映了相应<connection>元素(连接0)中的车道链接。后继元素将第三道路506(ID为3的道路)指示为道路5的后继。在描述道路5的车道2的道路5的道路元素内还示出了＜lane＞元素(为了简洁起见，省略了其他车道元素)；车道元素包含链接元素，该链接元素依次指示车道2作为其后继，指示车道3作为其前驱。为了有意义地解释车道链接，有必要考虑道路链接信息；道路1是道路5的前驱，因此道路1的车道3是道路5的车道2的前驱；道路3是道路5的后继，因此道路3的车道2是道路5的车道2的后继。第三代码部分606包含描述道路3的道路元素。交叉路口510(交叉路口ID＝0)被指示为道路3的前驱，并且示出了描述道路3的车道2的车道元素(为了简洁起见，省略了其他车道元素)。

从上面的示例中可以看出，提取相对基本的信息片段—在这种情况下，从道路1的车道3或车道段2到道路3的车道2的交叉路口的直接路线—效率相当低。

此外，对于微规划，仅仅考虑车道链接是不够的，因为这会忽略涉及车道变更的其他微路线。因此，有必要单独考虑车道变更。车道编号在这里很有用，因为它允许识别同一驾驶方向上的相邻车道。然而，车道编号不一定是决定性的。例如，简单返回图5，不可能从道路2的车道2移动到道路2的车道1，因为后者是不可驾驶的。尽管图5中没有描绘，但是可以使用附加车道来描述道路的边界，例如边界车道或路肩车道、或者仅可由某些形式的代理使用的车道(例如公共汽车或自行车车道)。

此外，OpenDRIVE容纳双向车道，原则上，如果目的车道是双向的，则可以从正编号车道变更为负编号车道，反之亦然。也就是说，在该特定实现中，通过SQE API 403暴露的拓扑索引411(`DirectedSideLaneGraph`)不支持跨越道路中心线的车道变更转换(即使目标车道是双向的)。在任何情况下，拓扑索引411保证任何可用的转换都将由一致的驾驶方向支持(路线将永远不会沿着错误方向的单行道返回)。

车道图

图7显示了为道路网络500生成的有向侧车道图700的部分。为了简洁起见，有向侧车道图700被简称为车道图700。车道图700描述了从道路1穿过交叉路口510的车道互连。如上所述，车道图700是用作拓扑查询的索引的内存数据结构。

车道图700在内存中实现为用于指代图的顶点(有向侧车道参考)的顶点描述符的集合以及用于指代它们之间的链接(有向边)的边描述符的集合；每个顶点描述符然后与进场边描述符的集合和出场边描述符的集合相关联。这些描述符与图4中所示的公开暴露的描述符是分开的，但是顶点描述符确实对应于有向侧车道描述符(该关联在内部管理)。

例如，第一节点702和第二节点704分别对应于道路1的车道段1的车道1和道路1的车道段2的车道2。向前边706指示这些车道之间的拓扑关系，即后者是从前者的“向前”车道(即车辆可以从前者穿过到后者，而无需执行车道变更策略)。边描述符与节点702、704相关联，该边描述符定义了从前者到后者的有向边以及边类型的指示(在这种情况下为“向前”)。节点或边描述符可以包含在单个存储器地址或多个存储器地址中(例如包含在存储器地址块中)。

车道图700通过解释静态层414的代码来构建。注意，车道图的边指示驾驶方向。为了确定向前边，需要考虑车道链接，但是也需要考虑驾驶方向。

还为左右关系提供了边。例如，描绘了第三节点708和第四节点710，分别表示道路1的车道段2的车道3和1。从第二节点704到第四节点710的右边711表示经由右车道变更策略从该车道段的车道2移动到车道1的可能性。从第二节点704到第三节点708的左边709表示经由左车道变更策略从车道2移动到车道3的可能性。左边709和右边711作为边描述符存储在存储器中，并且指示它们各自的类型(“左”和“右”)。该信息未在底层描述的＜link＞元素中提供，而是从如上所述的道路结构中获得。

第五节点714表示道路5的唯一道路路段中的车道1，该车道1是车道段2或道路1中的车道2的向前车道。因此，向前边712从表示前者的第二节点704指向表示后者的第五节点714。

如将理解的，可以通过各种方式将这种性质的图结构编码在存储器中，使得道路网络500内的拓扑关系被编码为表示道路结构元素的节点之间的内存指针。虽然图7描绘了车道图，但是可以在道路级构建类似的几何索引，其中节点表示道路，指针表示道路之间的拓扑关系。

在车道图700中，如果存在从第一车道到第二车道的边，则称第二车道连接到第一车道(意味着可能从第一车道移动到第二车道中)。如前所述，车道图中的“连接”概念与OpenDRIVE中的链接概念不同。

考虑到上面的微规划查询，可以高效地容纳拓扑查询。例如，给定当前车道和目标车道，可以容易地将从前者到后者的微路线确定为通过车道图700的从表示前者的节点到表示后者的节点的一组路径。

车道段在OpenDRIVE中没有明确的标识符。但是，它们通过它们在适用的<Road>元素中出现的顺序隐式地来索引。这些隐式索引用于引用SQE 402内的车道段。具体地，SQE402使用road.lanes().lane_sections()集合中的车道部分的基于零的索引。

图7A显示了车道图700的部分的进一步的细节。每个边都有与之关联存储的相关联成本。例如，成本可以包含在描述该边的边描述符中。为了便于说明，该图显示了与分别从第二节点704指向第三节点708、第四节点710和第五节点714的左边、右边和向前边相关联的成本709C、711C和712C。图中未示出其他边的成本，但是车道图700的每个边以这种方式与成本相关联。

成本采用距离惩罚的形式，有助于快速搜索从一个节点到另一个节点的最短微路线。在实践中，这种搜索将是近似的。对于给定的车道序列，在实践中，实际行进距离将在一定程度上取决于驾驶员(或其他参与者)行为，例如车道变更策略的时间、车道内横向移动的程度等。然而，可以为图700的每个边分配通常表示行进距离的成本。

当穿过有向侧车道图700中的向前边时，产生的成本等于(从支持车道部分的开始测量的)源侧车道中线的物理长度。也就是说，对于从一个车道到另一个车道的向前边，前者的长度(纵向范围)是重要的。因此，与从第二节点704到第五节点714的向前边相关联的距离惩罚712C取决于道路1的车道段2中的车道2的长度。从概念上讲，从给定节点(在路线的起点处或沿着路线)开始的路线规划在车道的起点处开始，由驾驶方向定义。要从当前车道的起点到达向前车道，需要驾驶(或以其他方式穿过)给定车道才能到达向前车道。因此，为了支持这种形式的路线规划，从当前车道到向前车道的向前边的成本由当前车道(而不是向前车道)的长度或当前车道的长度的任何合适的函数给出。

当穿过车道图700中的相邻边时，产生的成本等于支持侧车道中线之间的距离。也就是说，对于左边或右边，横向距离是重要的。例如，从当前车道到相邻(左或右)车道的左边或右边的成本可以是当前车道和相邻车道之间的横向距离。横向距离只需要是近似的，并且通常代表由车道变更引起的附加行进距离。事实上，一个目的是防止基于成本的图搜索返回具有过多左右车道变更的路线(例如在相同的两个车道之间反复来回切换)，并且为了实现这一点，可以使用足够大的任何非零成本(因为每一个“不必要的”左/右车道变更都会增加总成本)。

测量横向距离的点是任意的，一种选择是使用支持车道部分(以保持其对称)的起点和终点处的内侧车道中线距离的最大值。在这种情况下，左/右边的距离惩罚被视为在当前车道开始或当前车道结束时(以较大者为准)当前车道和相邻车道之间的横向间隔(或其某些函数)。理想地，人们可能希望使用更能代表通过进行车道变更所引入的任何多余弧长的东西，但更简单的启发式方法就足以满足当前的目的。在任何情况下，如前所述，任何足以防止重复或不必要的左/右车道变更的横向距离惩罚都可能是足够的。

可以理解，基于距离的成本可以通过其他方式构建，并且具体的选择将取决于特定实现。在路线规划查询的上下文中，基于距离的成本通常只需要表示与车道变更相关联的行进距离(在广义上)，目的是在图700的任意两个给定节点之间找到近似的最短路线(在几何意义上)。还可以定义其他形式的成本以支持其他类型的拓扑查询。在这种情况下，尽管查询和车道图700本质上是拓扑的，但是成本基于车道几何形状。几何成本允许在不影响运行时间性能的情况下将几何信息输入到拓扑查询中。

如前所述，SQE API 403处的拓扑查询的一个示例是提供期望起始车道和期望结束车道的描述符423的路线规划查询。为了响应该查询，在考虑边成本的情况下执行深度优先搜索，目的是找到从起始车道到结束车道的最低成本路线(车道序列)。这将不一定是车道变更最少的路线；尽管查询本质上是拓扑的，但是成本基于车道几何形状。尽管成本通常会阻碍车道变更，但重要的是总成本。例如，在具有高曲率的道路中，更靠近曲率中心的车道可能比距曲率中心更远的车道短得多(纵向)(一个具体示例是环形交叉路口；环形交叉路口的最内侧车道可能比最外侧车道短得多)。在这种情况下，一次或更多次左车道或右车道变更所产生的附加惩罚可能小于通过选择更靠近曲率中心的较短车道所获得的“节省”。

图8显示了包括双向车道802的道路网络的第二车道图800。双向车道802由车道图800内的两个单独的节点804A、804B表示(一个用于每个驾驶方向，或者更一般地，用于每个遍历方向)。为了更一般地进行路线规划和拓扑查询，这些节点804A、804B是独立的，具有不同的进场/出场边，因此与图中的其他节点具有不同的拓扑关系。双向车道的这种“分割”意味着可以构建车道图800，以防止违反与网络相关联的驾驶规则的车道变更。在所示的示例中，车道1是允许第一驾驶方向(如图所示为从下到上)的单向车道，而车道-2是只允许相反驾驶方向(第二驾驶方向，如图所示为从上到下)的单向车道。双向车道是车道-1，支持两个驾驶方向。当在第一驾驶方向驾驶时，允许在车道1和车道-1之间变更，但不允许进入车道2；同样，当以相反驾驶方向驾驶时，允许在车道2和车道1之间变更，但不允许在车道1和车道-1之间变更。这些限制被捕获在车道图800的结构中：节点808表示车道-2，节点804A表示第二驾驶方向上的双向车道-1，其中这些节点之间的边(在两个方向上)表示第二驾驶方向上车道-1和车道-2之间的许可车道变更。节点806表示车道1，并且不直接连接到节点804A。相反，节点804B表示第一驾驶方向上的车道-1，节点806和节点804B之间的边(在两个方向上)表示车道1和车道-1之间的许可车道变更(节点804B和节点808之间没有直接边)。因此，从车道1开始，可以找到涉及移动到车道-1的路线，因为存在从节点806到804B的边。然而，不可能从车道-1移动到车道-2中，因为从节点804B到节点808不存在这样的边。同样，从车道-2开始，可以找到涉及从车道-2移动到车道-1的路线，因为存在从节点808到节点804A的边。然而，不可能从车道-1移动到车道1，因为从节点804A到节点806不存在这样的边。

注意，图8中描绘的示例要求穿过道路的中心线801，以便从车道1移动到车道-1。这被认为是高风险策略，并且SQE 402的某些实现完全排除了这种策略。在这样的实现中，车道图800排除了导致穿过道路中心线的任何边。在这种情况下，节点804B将被省略，双向车道-1将仅由单个节点804A表示，并且从车道-1变更到车道1的可能性将不会在车道图800中被捕获。可以引入新的API来处理从车道图800中排除的这种高风险策略，以使任何这样的策略在任何结果代码中明确。这样的架构在设计上将这种策略与由SQE 402所考虑的其他“正常”策略分开。

当双向车道可能被沿着任一方向的交通流进入而不穿过中心线时，可能会出现这种情况。例如，连接两个双向道路的双向车道可以在任意一端处进入。

图8A显示了具有双向车道的道路网络860的一部分的另一个示例。两个道路862、864，每个道路都有单个左车道和单个右车道，该左车道和右车道由单个车道道路866连接，其中该车道是双向的。例如，这种布局有时用于在住宅街道等中实现交通控制措施。显示了车道图850的部分，其中双向车道(“{＂1＂,1,1}”)表示为两个独立的节点(“＜{＂1＂,1,1}”和{＂1＂,1,1}>”)，对于每个交通方向，具有如图所示的向前连接边。

道路分割索引

简单地返回图5，OpenDRIVE使用连续的参数化数学函数来描述道路和车道几何形状(以及更普遍的道路/车道结构)。这对几何索引和高效查询提出了挑战，如下所述。

至少，道路必须有道路参考线，该道路参考线由一对标量值函数(x(s),y(s))描述，或者更可能的是作为惯性坐标(x,y)的函数，由沿着道路具有不同支持的一组此类函数对来描述。具体操作方式取决于曲线的特性。对于线、圆弧和螺旋，通过指定曲线的特征特性(例如曲率等)来隐式地定义曲线，但对于参数三次曲线，则显式地定义。目前，OpenDRIVE中可用于描述道路参考线的函数类有：直线、螺旋、圆弧、多项式和参数多项式。多项式和参数多项式可以最多定义为三阶(三次)。函数可以改变，因为函数类改变(例如从直线到螺旋)，或者如果函数类没有改变，但至少有一个参数改变(一个示例是具有不同参数的两个多项式函数)。例如，在一些s坐标区间s＝[0,s1)上，道路参考线可以由第一线性(直线)函数来描述，该函数由一些s＝0处的起始坐标(x0,y0)和该线的倾斜度(斜率)，s＝s1处的结束坐标(x1,y1)参数化。在随后的s区间[s1,s2)上，道路参考线可以由第二螺旋函数来描述，该第二螺旋函数在惯性坐标中的(x1,y1)处开始(在道路坐标中s＝s1)，继续到(x2,y2)(s＝s2)，并且由s1和s2处的起始和结束曲率参数来描述。然后，在随后的区间[s2,s3)上，道路参考线可以由恒定曲率所参数化的第三圆弧函数来描述，或者由参数(a,b,c,d)所描述的诸如三次多项式y＝a+b*x+c*x^2+d*x^3之类的一些其他第三函数来描述(事实上，OpenDRIVE更灵活，并且允许在局部(u,v)坐标中定义多项式，相对于惯性(x,y)坐标旋转，用于描述世界中任意旋转的道路；为了简单起见，以下描述和附图涉及(x,y)中的多项式，但同样适用于所选择的(u,v)坐标)。区间[0,s1)，[s1,s2)，[s2,s3)分别是第一函数、第二函数和第三函数的支持(在数学意义上)，其中s1和s2是沿着道路的道路参考线函数变化的点。这种变化可以发生在沿着道路的任何任意点处。

此外，还使用了其他函数来描述相对于道路参考线的道路/车道几何形状。一个这样的函数是车道宽度函数，它定义了车道相对于其内边界的外边界(反过来，内边界可以是另一个车道或道路中心线的外边界)。例如，虽然不容易看到，但在图5中，ID＝2的道路的车道段2中的车道-1的宽度可能略有增加，并且由三个侧车道宽度函数描述：第一s区间上的第一恒定宽度函数、第二区间上的线性增加宽度函数和最终s区间上的第二恒定宽度函数。同时，道路参考线505本身可以由多个函数(例如直线函数然后是三次函数)来描述，其支持与车道宽度函数的支持没有特定关系。可能需要考虑的其他函数包括中心偏移函数，定义道路参考线和道路中心线(OpenDRIVE术语中的中心线)之间的偏移。

上述考虑也延伸到非几何函数。例如，在沿着标记车道边界的某个点处，标记的形式可能会发生变化(例如从实线变为虚线)。在一些实现中，这可以被视为(为了索引的目的)车道标记函数的改变。在其他实现中，可以单独考虑非几何函数；例如，可以针对车道几何形状构建第一道路分割索引，并且可以针对道路/车道的一些其他特性(例如标记、速度限制等)构建第二道路分割索引(具有不同分割)。在下面描述的示例中，道路分割的主要原因是允许在车道边界上或车道本身内的有效定位点，并且在这种情况下，可能希望仅考虑在道路分割索引407中描述车道几何形状的那些函数。替代地或附加地，可以选择以不同的方式分割道路，以支持在很大程度上独立于该任务的其他任务(例如计算车道标记或速度限制等)。因此，可以构建在不同程度上特定于任务的一个或多个道路分割索引(每个索引根据相同的原理构建，但基于不同的函数集合，因此通常具有由其各自的函数集合的支持所定义的不同分割)。

为道路网络中的每个道路生成单独的道路分割索引。每个道路标识符都与“RoadLookups”实例相关联，该实例管理“RoadPartition”实例。这些都在构建ScenarioQueryEngine实例时初始化(此后是不可变的)。

图2的道路分割索引407的结构考虑到了上述考虑。OpenDRIVE以示例方式考虑，但道路分割索引可以有效地应用于具有多个组成部分(例如参考线、中心车道/中心线、车道/侧车道)的道路，其中道路的每个组成部分由至少一个函数描述，该函数可以沿着道路变化，与其他组成部分和/或函数无关(至少在一定程度上)。组成部分的数量和/或性质也可以沿着道路变化，也可以不变化(例如在开放式驾驶中，组成部分的数量可以随着侧车道数量的变化而变化)。因此，在这些函数的各个支持之间通常没有特定的关系或对齐，并且这些支持可以或多或少地任意地彼此重叠。道路分割索引407可以考虑描述道路的所有可能的函数(例如所有所需的几何函数，加上任何非几何函数，例如车道标记等)或仅考虑函数的子集(例如仅考虑几何函数、或者取决于最终应用的几何函数的某个子集)。

车道宽度函数描述了外车道边界相对于其内边界的几何形状。OpenDRIVE还允许使用车道边界函数作为车道宽度函数的替代方案，以直接描述车道边界(边界)(这意味着曲线评估策略略有不同)。

道路分割索引407的原理如下。给定所考虑的一组函数，对道路进行分割，使得在每个道路部分内，描述该道路部分的函数子集不会改变。这意味着函数的数量不会改变，并且这些函数中的每一个的类型和参数在道路部分内保持不变。

换言之，道路部分是道路分割的元素，而道路分割又是覆盖道路全长的s区间序列，因此，在每个区间中，整个道路跨越部分(cross-section)的函数结构(相对于所考虑的一组函数)保持固定。

图9显示了在朝向图顶部所示的道路900(道路M)上构建的道路分割索引407的简化示例。在该示例中，仅考虑了道路参考线和侧车道边界函数，这对于某些应用可能足够，而对于其他应用则过于简化。应当理解，所描述的技术可以容易地扩展以包括附加函数和/或道路组成部分。道路900最初具有第一车道段中的s区间[s0,s2)中的单个车道(车道-1)。在s2处，第一车道段开始，并且具有两个车道(车道-1和车道-2)的新车道段开始。

在第一区间[s0,s1)中，仅存在单个车道(车道-1)，其外边界由第一常数函数902描述。在第二区间[s1,s2)中，仍然只有单个车道，但是其外边界现在由第二多项式函数904来描述。在s2处，第二车道段开始，其中有两个车道。车道-2是在前一车道段中并且在区间[s2,s3)中车道-1的向前车道。车道-2的外边界由第三函数906(也是多项式)描述，车道-1的外边界由第五函数910(多项式，从s2开始从零逐渐增加)描述。在s3处，描述车道-2的外边界的函数发生变化；在区间[s3,s5]中，该边界现在由第四线性函数908来描述。注意，在s3处，车道-1的边界函数没有发生变化；仅在s4处，车道-1的边界函数才改变(为区间[s4,s5]上的第六常数函数912)。同样，在s4处，车道-2的边界函数没有发生变化。虽然图9考虑了边界函数，但同样的原则也应用于使用宽度函数来描述车道边界的情况。

每个函数902-912都存储在存储器中。在实践中，这意味着存储函数的参数、以及函数的形式和类型(无论是显式还是隐式)的一些指示。每个函数可以存储在一个或多个存储器地址处。

图9的函数总结在下表4中。除非另有说明，否则函数的“类型”指的是它所描述的物理属性，其中“类”和“形式”分别指的是其一般和特定的数学属性。

/>

表4：图9的车道边界函数。

对于给定的道路属性(例如车道边界)，函数变化的点在本文中被描述为变化点，并且不同属性(例如车道边界)之间的变化点在其函数支持未对准的程度上表现出纵向未对准。在图9的示例中，属性是车道边界：具体来说，最外侧车道边界从s0延伸到S5，在s1、s2和s3(第一边界)处具有附加变化点；相邻车道边界(车道-2的内边界和车道-1的外边界)从s2延伸到s5，在s4(第二边界922)处具有附加变化点。第一边界920的变化点s1和s3以及第二边界922的变化点s4表现出相互的纵向错位，其中根据表9在每个变化点(s0、s1、s2、s3、s4、s5)处分割道路。

每个属性都被称为由描述函数来描述，其函数形式在该属性的变化点处发生变化。因此，第一函数902、第二函数904、第三函数906和第四函数908构成第一车道920的描述函数的不同函数形式，而第五函数910和第六函数912构成第二车道边界922的描述函数的不同函数形式。

在图9中，“ds”指示相对s坐标，从所讨论元素开始测量。因此，对于从s2处开始的函数，ds＝0对应于s＝s2。换句话说，对于给定的函数，ds＝0指示该函数的支持的开始。注意，在OpenDRIVE中，“ds”专门用作相对于车道部分边界(或车道偏移或车道宽度函数定义边界)的开始测量的轨迹位置增量。对于支持道路参考曲线的几何形状，增加了复杂性，(从支持道路的起点的开始测量的)轨迹位置s和底层函数的参数之间存在中间对应关系。这种增加的复杂性在当前上下文中不被认为是直接相关的，因此为了便于说明，在以下示例中被忽略。

在OpenDrive模式中，每当新车道段开始时，描述侧车道的某些属性的函数必然会发生变化，因为每个车道的函数必须从车道段开始定义。函数在数学意义上可能改变，也可能不改变(例如在图9的示例中，单个多项式函数在原则上可以描述区间[s1,s3)中最外侧车道边界)；然而，在OpenDRIVE中，该函数需要在新车道段的开始处重新定义，其中ds＝0现在指示新函数和新车道段的开始)。在当前实现中，这被视为函数的变化，以匹配OpenDRIVE模式。因此，第二函数904和第三函数906分开存储(并且它们的参数将是不同的，因为它们根据“ds”而不是“s”来定义)。然而，在其他实现和/或模式中(例如使用单个函数来描述s1和s3之间的最外侧边界)可以对这种情况进行不同的处理。

为了简化说明，假设道路参考线函数在区间[s1,s5]中不改变。因此，道路参考线由单个附加函数(未描绘)来描述，该函数是由s0处的起始坐标(x0,y0)(在该示例中，s0＝0，道路的起点)和倾斜度(hdg)定义的直线函数，使得[s0,s5]中的点s的道路参考线上的(x,y)坐标由下式给出：

x＝x0+ds/sqrt(1+hdg^2)；

y＝y0+ds/sqrt(hdg^(-2)+1)。

在这个特定示例中，ds＝s，作为道路的起点，s＝0，与单个道路参考线函数的起点相同。

道路分割索引407的构造如下。首先，基于所考虑的一组函数(参考线和边界函数)，在上述意义上分割道路900。道路部分的选择使任何道路部分都不会发生函数变化。在本示例中，这一要求意味着至少有五个分割，在表5中做了概述，其中粗体用于指示需要新道路部分的任何更改。

/>

表5：图5的道路M的示例道路分割。

表5假设道路参考线函数不变。如果道路参考线函数确实发生了变化，这将需要至少一个附加道路部分(除非道路参考线函数的变化恰好与车道边界函数中的一个的变化一致，但如前所述，不要求函数支持以这种方式对齐)。

所描述的实现采用了所需的最小分割(车道部分可以任意长，前提是函数不变)。下面在线段树452a的上下文中考虑了子部分，但是在该示例中在道路分割索引407中未考虑子部分。其他实现可能会增加分割的范围(例如即使没有发生函数变化，也会划分更长的区间)，但在本示例中避免了这一点：目的是使道路分割索引的每个条目都包含尽可能多的几何信息，承受任何道路部分内的没有感兴趣的函数变化的约束。

针对每个道路部分，道路分割索引407具有条目，该条目包含对描述该道路部分的函数子集的引用。每个函数引用都标识了所讨论函数所存储的位置。因此，在图9中，道路分割索引407显示为具有五个条目，用于表5中列出的五个道路部分及其各自的函数。这意味着一定程度的重复：例如，区间S3和区间S4的条目分别由附图标记407A和407B指示，并且每个条目都包含对描述最外车道边界的第三函数908的引用。注意，在道路分割索引407中重复的是函数引用；函数本身形成静态层(StaticLayer)文档本身(包含静态层414)的部分并且函数引用允许它们例如经由第二API 405位于文档(或其内存表示)中。这减少了所需的存储器开销，同时在运行时间处仍能显著提高性能。

例如，道路分割索引407的每个条目可以采用键值对的形式，该键是道路部分的某个标识符(例如定义道路部分的区间、或映射到该区间的某个其他标识符)，并且该值是该道路部分的函数引用。

对道路分割索引407的查询提供道路部分描述符，允许定位该道路部分的相应条目。通过设计，在运行时间处，只需要考虑单个函数集合，并且保证每个函数保持不变(因为函数的形式不会改变)，从而允许使用所引用的函数高效地计算道路部分的几何形状(或更一般的属性)。

空间索引

每个空间索引覆盖整个静态层414，这只需要道路标识符在静态层414内是唯一的。

除了道路分割索引407之外，e车道部分边界框也被索引(在框树450中)，位于每个侧车道部分的内车道边界和外车道边界上的一组线段也是如此(内边界和外边界分别在内线段树452a和外线段树452b中被单独索引，如上所述)。如上所述，车道部分(或更具体地为侧车道部分)是侧车道与道路部分(在上述意义上)的交叉点。

放置在空间索引中的每个几何形状(线段或边界框)都与车道束相关联，车道束是一种数据结构，包含对支持侧车道、支持道路部分和任何其他支持查找表的引用。

道路分割索引407用于计算空间索引450、452a、452b中保持的边界框和线段。索引450、452a、452b也以与道路分割索引407互补的方式构建：对空间索引450、452a、452a中的一个的某些类型的内部或外部查询返回链接回道路分割索引407的内部或内部响应，以允许对道路分割索引407的进一步的查询。空间索引450、452a、452b被配置为允许快速且有效地生成这样的响应。

图12大致描绘了如何根据道路分割索引407生成框树450和线段树(统称为542)。作为几何索引部件408的部分，显示了线几何形状计算部件1200、部分计算部件1202、部分框计算部件1204和车道框计算部件1206。

道路部分的s区间是道路部分ID的一种形式。将与各个道路部分相对应的区间传递给API 403和/或从API 403传递与各个道路部分相对应的区间、和/或在内部传递，基本上使用区间作为道路部分描述符，这可能很方便。这提供了在从API返回时对“位置”的精确估计，并且提供了键，当传递到API时，该键可用于加速查询。由于道路分割被存储为根据相应的轨迹位置区间的下限排序的道路部分的集合，因此也可以简单地使用给定的轨迹位置来有效地定位相应的道路部分。因此，在当前上下文中，道路部分的区间内的单个轨迹坐标也可以用作道路部分标识符。以离散的一组道路部分描述符的形式引入更高级抽象，在内部使用和/或在外部传递到API 203/在外部从API 203传递，也可能是有益的。

线段树

图10A以线段树的形式描绘了图9的道路900的示例内边界索引452a、以及存储在索引452a中的某些几何元素的示意图。

图10D以线段树的形式描绘了图9的道路900的示例外边界索引452b，并对相应道路几何形状进行了类似的描绘。

以下描述主要集中在内边界树452a上。显而易见，大部分描述同样应用于外边界树452b。

内边界树452a具有叶节点和非叶节点，其边对应于父子关系。在树452a的底部处，每个叶节点表示在给定的s区间内与单个内车道边界的一部分接近的单个线段。遵循与道路分割索引407类似的原理，对于任何给定的叶节点，其线段的s区间完全包含在道路部分内(也就是说，没有线段区间跨越多个道路部分)。在叶节点级，线段可以跨越整个道路部分或其子区间，但始终包含在单个道路部分内。

每个非叶节点都是具有一个或更多个子节点(可以是叶节点或非叶节点)的父节点。每个父节点都包含边界框，该边界框是包含其子节点(对于非叶子节点)的所有边界框或其子节点的线段(对于叶子节点)的边界框。

参考图12，根据道路分割索引407构建每个线段树，如下所示。线几何形状计算部件1200使用在道路分割索引407的相应条目中引用的函数来计算每个道路部分的道路和车道几何形状。道路部分的区间被细分。优选地，每个子区间的大小的确定取决于道路几何形状，特别是基于道路和/或车道曲率。在每个子区间中，所有内/外边界(如适用)由(段计算部件1202根据线几何形状计算的)直线段近似。因此，对于高度弯曲的边界，需要较短的子区间来保持近似的给定精度水平。相同的子区间用于每个边界，并且在这种情况下，可以例如由具有最高曲率的边界确定子区间的大小(例如在这种情况下，对于具有基本直的中心线但外边界弯曲的单个侧车道道路，中心线和道路参考线在相同的子区间上被细分，其大小由外边界的曲率确定)。段框计算部件1206计算每个所计算线段周围的边界框以及父边界框。每个边界框都是一个与惯性坐标系的x轴和y轴对齐的矩形，因此每个边界框完全由两个对角点的坐标定义。

返回图10A，在树的底部处，描绘了表示线段L0、…、L3、L7和L8的叶节点，它们是表示边界框A4的非叶节点的子节点。线段L0、L1和L2大致位于车道段2中的车道-2的内边界上，L3大致位于(由道路中心线定义的)同一车道段中的车道-1的内边界上，L7和L8大致位于(也由道路中心线定义的)车道段1中的车道-1的内边界上。如将理解的，树542a在实践中可以包含更多的叶节点，具有不同的父节点。为了简洁起见，表示给定线段Ln或边界框An的节点可以被称为节点Ln或节点An。

车道宽度可能为零，但在实践中，车道宽度往往仅在一个轨迹位置处(在车道部分中的第一个或最后一个点处)为零。然而，从理论上讲，侧车道部分的内边界和外边界可以在部分的起点或终点以外的位置处有效地重合。在实践中，这一点可能基本上被忽略(也就是说，在构建侧车道部分的闭合边界时，可以特别考虑这一事实，例如用于最终控制测试；如果宽度实际上为零，则位于内车道边界和外车道边界的开始(或结束)处的点不会重复)。或者，如果在特定情况下需要，识别和忽略零宽度的车道部分将是一种相对直截了当的改进。

如所讨论的，每个叶节点都包含车道部分的束。注意，尽管每个线段在道路部分的子区间内计算，但是束引用其所属的整个车道部分(根据车道ID和链接回道路分割索引407中的相应条目的道路部分ID)。对查询的响应也根据整个道路部分的描述符而返回。从外部看，划分为子区间是“不可见的”；线段树452a上的查询的目的通常是找到满足某些几何查询的整个道路或车道部分，并且进一步划分为子区间只是为了允许快速且合理准确地回答这样的查询。

叶节点中的车道ID标识了具有其线段所在的内边界的车道(因此，对于位于ID为-1的车道的内边界上的线段L8、L7和L3，车道ID＝-1，其中车道段在引用相应道路部分时隐含地定义；对于位于车道-2的内边界上的线段L2、L1和L0，车道ID＝-2)。

因此，叶节点之间存在引用/束的显著重复，可能有许多叶节点引用道路分割索引407中的相同道路部分。注意，在线段树452a的叶级处复制的是对道路分割索引407中的相应条目的引用，而不是函数引用，(如所注意到的，单独地，在相应函数跨越多个道路部分的程度上，函数引用也在道路分割索引407上被复制)。

父节点A4存储边界框A4，该边界框A4继而界定其所有子线段L0、…、L8的边界。

表示边界框A5的祖父母节点是节点A4的直接父节点，而表示边界框A3的第二节点(依次由其子节点的线段(未描绘)定义)。边界框A5界定其直接子节点的边界框A3和A4。

图10A的示例是高度示意性的。

在树的较高级上，树的结构和道路900的结构之间没有特别的相关性。叶节点可以任意分组在一起，并且没有什么可以阻止父节点跨越树的除叶级以外的任何级的多个道路部分，因为不同道路部分内包含的叶节点可以分组在同一直接父节点下。附近的叶节点通常应分组在一起，以确保有意义的父边界框，并且通常通过合理平衡的树来实现最佳性能。可以使用任何合适形式的树数据结构，包括可以在构建树时动态地确定父/子关系的“自平衡”结构。

图10B显示了边界框(通常指示为An)和线段(通常指示为Ln)，该边界框和线段可以为更真实的道路几何形状而存储，用于树的三个级(叶级加上两个非叶级)。这里，“A”指示整个索引的边界框(整个索引的外极限)。

图10C显示了存储在叶级的线段的展开视图。道路显示为具有多个内边界，可以看出，相同的子区间用于每个边界。在指示为1000的区域中，两个最外边界的曲率随着车道中的一个的宽度的增加而短暂增加。这会导致所有车道边界(包括保持基本直的边界)的子区间更小。

图10D显示了根据相同原理构建的示例外边界树452b，但在外车道边界而不是内车道边界上。这里，叶节点显示为表示车道-1的外边界上的线段L1和L2(其也出现在内边界树452a中-参见下文)、以及车道-2的外边界上的线段L9、L10、L11。如前所述，每个叶节点都包含束，该束引用其线段所属的整个车道部分、以及具有该线段所在的外边界的车道ID。

从内边界树中排除外车道边界。在实践中，大多数边界充当一个车道的内边界和相邻车道的外边界。因此，总的来说。对于给定的车道段，仅排除道路的两个最外边界。相同原理适用于图10B的外边界树452b。在这种情况下，通常只排除中心线，因为它不是任何车道的外边界。因此，在实践中，大多数车道边界在两个线段树452a、452b上都是重复的。然而，线段本身与两个树452a、452b中的不同束相关联。

然而，在所描绘的双向道路中，中心线确实充当了车道1和车道-1的内边界，因此，中心线的线段在车道1和车道-1的内边界树中重复。出现这种重复是因为过滤器可能会导致这些车道中的一个或另一个被有效忽略，只留下一个边界完好无损。过滤器可以根据谓语(或谓语的组合)来构建。

参考图10A和图10D，线段L1和L2位于车道-1和车道-2之间的边界上，即车道-2的内边界和车道-1的外边界。在内边界树452a中，相应节点包含车道ID-2，因为这些线段大致位于其内边界上。相反，在图10D中，外边界树452b的相应节点包含车道ID-1，因为这些线段L1、L2大致位于其外边界上。

图10E和图10F显示了与图10B和图10C相同道路的更真实的外边界索引中存储在三个级的父框和叶级线段的示例。

框树

图11A显示了图10A和图10D中道路900的示例框树。框树根据一些相似的原理构建，尽管它的构建通常更简单。每个叶节点表示整个车道部分(如前所述，是车道和道路路段的交叉点)，并且包含该道路部分的边界框。描绘了叶级边界框R1、R2、R3，其中在框树450中具有相应叶节点。每个叶节点都包含类似的束，该束包括它所界定的车道的车道ID、以及对道路分割索引407中相应道路路段的引用。

主要基于彼此的接近度和平衡树450的总体目标，叶节点可以或多或少地任意分组在共同的父节点下。每个父节点都包含边界框，该边界框界定其子节点的边界框。在这种情况下，叶节点和非叶节点都包含边界框，但原理在其他方面类似于线段树452。

所描绘的叶节点的直接父节点表示边界框R5，该边界框R5又界定子叶节点的边界框R1、R2、R3。节点R5又是表示边界框R7的节点的子节点。节点R7另外是表示边界框R4和R6的节点的直接父节点，边界框R7界定所有R4、R5和R6。

图11A是高度示意性的，图11B和图11C显示了更真实的框，该框可以存储在框树的三个级(3级是叶级)。边界框通常将在每个级(包括叶级)都有一定程度的重叠。在几乎所有情况下，叶级边界框将包括所讨论车道部分之外的一个或更多个区域。

参考图12，由车道部分框计算部件1206基于计算出的线几何形状计算框树的叶级的车道部分边界框。

控制查询

图13说明了如何在两个阶段中使用框树450来回答控制查询1300。在SQE API 402处接收控制查询1300，并且控制查询1300包含(在该示例中)指定的(x,y)点。控制查询可以是特定类型的，也可以是非特定类型的。特定类型的控制查询经由控制查询1300中设置的一个或更多个车道标志来指定车道类型。

对于特定类型的查询，最初将过滤器应用于框树450，以过滤出指定类型以外的节点。结果是过滤后的子树，然后在其上运行查询。以下描述涉及对框树450的查询，并且应当理解，在特定类型的查询的情况下，相关描述适用于通过应用活动谓语而获得的子树的过滤后的版本。

对于非特定类型的控制查询1300，如果点(x,y)包含在车道部分内，则响应1302返回包含车道部分的描述符；否则返回空结果。对于特定类型的控制查询，如果(x,y)不包含在任何车道中，但如果(x,y)包含在与指定lage标志不匹配的车道中，则返回空响应；如果(x,y)包含在指定类型的车道中，则返回包含车道部分的描述符。

图13的示例假设点(x,y)位于图11A中所描绘的车道部分(车道ID＝2，车道部分＝[s2,s3))内。步骤1304、1306和1308在第一阶段中执行。在步骤1304处，评估了顶级边界框，可以快速确定(x,y)位于顶级边界框R7内(1304)。从这一点开始，只需要考虑节点A7的子节点。仅根据节点R7的子节点，可以快速地确定(x,y)位于边界框R5内；因此，只有节点R5的子节点需要在下一级被考虑。在这些子节点中，可以快速确定(x,y)位于边界框R2内，从而在叶节点R2处终止第一阶段。在第二阶段中，存储在节点R2中的束用于对道路分割索引407执行中间内部查询，以获得(步骤1310)计算所讨论车道(道路部分S2＝[s2,s3)中的车道-2)的几何形状所需的函数集合。现在可以将该几何形状计算(步骤1312)到任何期望精度，并且反过来，所计算的几何形状用于明确地回答控制查询1300。在一些实现中，精度级可以在查询本身1300中被指定，以允许开发者在精度和性能之间设置期望的权衡。注意，该第二阶段不依赖于预先计算的几何形状，也不使用框树450中的几何信息(在这一点上，框树450已经通过提供车道ID和对所需道路部分的引用来达到其目的)。第二阶段是必要的，因为第一阶段不足以得出点(x,y)位于道路部分S2的车道-2中(它可以位于边界框R2内，但在车道外的区域中)的结论。因此，第一阶段的结果是至少一个“候选”车道部分，其可能包含(x,y)。

可以理解的是，图11A的道路900被高度简化。特别是，道路参考线的取向使得边界框都不重叠，这在实践中是不可能的。图11B和图11C更为真实。从这些图中可以明显看出，在实践中，在这些多个框(例如图11C中标记为R18和R19的框)之间的重叠区域中，点(x,y)可能包含在多个边界框中。这将导致在查询结束时出现多个候选车道部分，多个候选车道部分中的每一个都需要以相同的方式考虑控制。不能保证(x,y)包含在任何候选车道部分中，但可以保证(x,y)不包含在任何其他车道部分中。

虽然上面考虑了车道部分，但也可以在道路级执行控制查询(以找到包含的道路部分)。这可以是单独的查询，或者如果在特定上下文中不需要，可以简单地忽略车道信息。

轨迹坐标查询

图14A显示了SQE API 403处的轨迹坐标查询1400。在这种情况下，查询1400包含点(x,y)，但也包含道路部分的描述符，该描述符包含(x,y)(在该示例中为区间S2)。在实践中，后者通过首先运行如图13所示的控制查询1300来确定。

SQE 402使用轨迹坐标查询1400中的信息来定位道路分割索引407中的相应条目(步骤1402)，检索道路参考线函数(步骤1404)并且计算所讨论道路部分的道路参考线的几何形状(步骤1406)。在实践中，这通过在指定道路部分S2内的道路参考线上找到最接近(x,y)的点((x,y)的s坐标或其“ds”坐标，然后将其添加到指定道路部分S2的起始s坐标S2，以产生s坐标)来实现。在响应1401中返回(x,y)的s坐标及其t坐标，即点(x,y)与其s坐标之间的横向偏移。这里有一个微妙之处，即如果(x,y)接近指定道路部分的一端，那么道路参考线上的最接近(x,y)的点实际上可能位于另一个道路部分。在这种情况下，响应1401在车道段的起始或结束处(对于道路部分S2在s2或s3处)提供最接近(x,y)的点，该点不是精确的(s,t)坐标。这可能在响应1401中是明确的或隐含的，并且由开发人员根据需要解决—在某些应用中，在这些情况下，道路/车道部分的起始/结束处的点可能就足够了。在其他需要精确坐标的应用中，在这些情况下，开发人员自由地在最近的相邻道路/车道部分上向API编码附加道路分割查询。在一些应用中，近似(s,t)坐标可能是足够的。如果不是，开发人员可以通过对同一点(x,y)和与(x,y)最近的相邻车道部分(在这种情况下为S1或S3)运行第二轨迹坐标查询，并且根据需要重复，直到找到实际(s,t)坐标为止，来容易地获得精确(s,t)坐标。在替代实现中，在生成对查询1400的响应1401的过程中，在这些情况下，可以在SQE402内自主执行那些相同的步骤。在这样的实现中，对指定道路部分(例如S2)的查询1400总是返回实际(s,t)坐标，即使这些(s,t)坐标位于不同道路部分中。

注意，直接使用道路分割索引407来回答查询1400(尽管如前所述，可以经由在第一阶段中使用框树450的早期控制查询来找到道路部分)。

查询以找到车道中心线上最近的点

图14B显示了查询1450，用于找到指定车道部分(在本示例中为(车道-2，道路部分S2))的中心线上最近的点。原理与图14B相似。在内部查询道路分割索引407(步骤1402)以获得(步骤1454)计算道路部分S2中的车道-2的几何形状所需的函数。反过来，该函数用于计算车道的中线，并且由此计算中线上最接近(x,y)的点的(s,t)坐标。如前所述，如果(x,y)接近道路部分的一端，则最近的点可能位于不同道路部分(可能属于相同或不同的车道段)。如图14A中所示，根据需要，可以经由对相邻车道部分的进一步查询来解决这一问题，相邻车道部分可以是外部的(使用API 403向下到开发人员)，也可以是内部的和自主的。

距离查询

图15A显示了API 403处的距离查询1500，其中包含点(x,y)。距离查询作为一种工具提供，当控制查询返回空结果时使用距离查询。以与控制查询相同的方式，距离查询可以是特定类型的，也可以是非特定类型的。为响应于非特定类型的距离查询而执行的步骤假设点(x,y)不包含在任何侧车道中；同样，在响应于特定类型的距离查询时，假设(x,y)不包含在指定类型的侧车道中。因此，距离查询1500应该仅在已经验证了(例如通过较早的控制查询)这些假设有效时运行(对于特定类型的距离查询，点(x,y)可以包含也可以不包含在一些其他类型的侧车道中，并且这不需要预先验证)。

对于特定类型的查询，首先将过滤器应用于线段树452a、452b，以过滤出指定类型以外的节点。结果是过滤后的内边界子树和外边界子树，然后在其上运行查询(与特定类型的控制查询的原理相同)。

内车道边界和外车道边界被分开索引，因为如果使用谓语来过滤出具有特定属性集合的所有车道部分(例如只考虑不在交叉路口的可驾驶车道)，那么剩余车道最终可能会被“空白”(被拒车道所在的位置)分隔开。这意味着，通常情况下，道路内部可能会出现空白，因此，当测量到最近的侧车道时，必须考虑可以测量到车道的内边界或外边界的距离(这在图15C所附的以下描述中得到了进一步的说明)。

当不使用谓语(并且考虑所有侧车道)时，通常只对外边界进行测量(参见以下随附图15B的描述)。

这涉及制作两个索引，它们包含几乎相同的数据，但关联不同，这就是内边界段索引和外边界段索引提供的。这种复制因其简单性而受到青睐，使得SQE 402的代码更易于维护。

响应1501针对非特定类型的距离查询(在本示例中为道路M的道路部分S2中的车道-2)，返回与任何类型的(x,y)最近的侧车道的描述符。对于特定类型的距离查询，响应1501返回经由距离查询1500中的一个或更多个车道标志指定的最接近类型的侧车道。

使用内线段树452a和外线段树452b找到最近的侧车道。

对于每个树452a、452b，基于父边界框，通常可以定位其边界框(在这种情况下为A4)包含与(x,y)最近的线段的单个最低级父节点，或者至少定位少量候选父节点。

为此，***找到满足所有活动谓语的候选线段，然后测量从查询点到该线段的距离。该值(及其相关联的引用)存储为“最佳”距离。从该点开始，位于边界框内的距查询点超过“最佳”距离的所有线段都可以丢弃，而无需进一步检查(这就是实现加速度的方式)。对于距“最佳”距离较近的边界框，考虑了所有子边界框。当遇到满足所有活动谓语的叶节点(实际上包含线段的节点)时，测量从查询点到线段的距离，并且将其与“最佳”距离进行比较。如果它更小，它将替换先前的最佳距离，依此类推。在此过程结束时，距查询点最近的线段是与“最佳”距离相关联的线段。这种“分治算法(divide and conquer algorithms)”本身是已知的，在本文中不作进一步详细描述。

在确定了该(或每个)最低级父节点之后，只需要考虑它的(或它们的)叶节点的子节点。在这些子节点中，树中最近的线段提供了最接近(x,y)的内车道边界或外车道边界(如适用)。

对于特定类型的查询，除指定类型之外的车道将尽早被忽略。

图15B举例说明了在点1520上的非特定类型的距离查询的原理，该点1520已返回非特定类型的控制查询的空结果。该空结果意味着(x,y)不位于作为控制查询的主题的道路或道路网络的任何侧车道内。这反过来意味着只需要考虑外车道边界。因此，可以仅对外边界树452b执行上述步骤，以便识别距点1520最近的外边界线段1522。相应叶节点束依次提供最近车道(具有最近线段所在的外边界的车道)的车道ID。

图15C举例说明了点1524上特定类型的距离查询的原理。点1524不位于指定类型的任何侧车道中，并且这应当在进行查询之前进行验证。它可能包含也可能不包含在另一种类型的侧车道中，并且在进行查询之前无需验证。在所描绘的示例中，点1524位于车道3中，该车道3不是指定类型的。相邻车道车道2和车道4属于指定类型。

总共显示了八个车道(6、…、1、-1、-2)，车道边界汇总在表6中。在表6中，粗体用于指示查询中指定类型的车道(与指定的车道标志匹配)。

表6：图15C的车道边界。

如上所述，线段可以出现在内边界树452a和外边界树452b中。这将适用于图15C中所示的所有车道边界上的线段，但车道6和-2的外边界1502、1518(不是内边界)和中心线1514(不是外边界)除外。例如，描绘了第一线段1526和第二线段1528，它们分别是在边界1508和1510上距点1524最近的线段。

在内边界树452a中，第一线段1526与车道3(位于其内边界上)相关联，而在外边界树452b中，同一线段1526与车道2(位于其外边界上)相关联。在内边界树452a中，第二线段1528与车道4(位于其内边界上)相关联，而在外边界树中，它与车道3(位于其外边界上)相关联。车道3(恰好包含点1524)与查询中指定的类型不匹配，并且第一线段1526因此将在内边界树452a上的搜索中被排除(由于其与内边界树454a中的车道3相关联)；该查询将替代地将第二线段1528定位为内边界树452a中与指定车道类型相匹配的最近线段(由于其与内边界树454a中的车道4相关联)，并且返回车道4的束。出于相同原因，第二线段1528将不会在对外边界树452b的查询中返回(因为它与外边界树454b中的不匹配车道3相关联)，并且该查询将替代地将第一线段1526识别为最近的匹配线段(由于它与车道2相关联，匹配指定车道类型)。最后，这只是从(如在外边界树452b上的搜索所返回的)第一线段1526和(如在内边界树452a上的搜索所返回的)第二线段1528中选择最近线段的情况。

由于在查找侧车道部分时从不希望检索中心车道部分参考，因此中心车道本身不会被索引。也就是说，由车道参考线(由车道偏移所偏移的道路参考线)支持的线段在内侧车道边界线段索引中被索引，其中它们与车道部分的内左侧车道和内右侧车道都相关联。然而，这些线段只有在存在某些谓语的情况下位于外部时才支持最近的查询(例如其中内左车道被过滤掉，而内右车道留在原地的线段)。在这种情况下，最内右侧车道的内边界是“暴露的”，因此在计算距另一个实体最近的侧车道时必须考虑该内边界。

在上述示例中，仅使用边界索引252a、252b来回答距离查询。在查询点处不使用道路分割索引407。***简单地返回与索引中最近的线段相关联的实体。如果人们对已经***到线段索引中的线段的近似性质感到满意，那么这就足够了。

上述技术的改进基于线段树的搜索返回k个最近邻居。然后对这些k个最近邻居中的每一个执行更高分辨率的测试(距离测量)，以确定它们中的哪个实际上是最近的。以这种方式，提供了精度高于线段树452a、452b的结果。

应用

所述技术的一个应用是支持图形场景编辑器，在该图形场景编辑器中，用户可以在道路布局上“放置”点，并且自动生成穿过这些点的路径。SQE 402的API 403可以用于使用上述查询来支持图形界面。例如，国际专利申请号PCT/EP2021/064283(其整体内容通过引用并入本文)公开了一种图形场景编辑器工具，用于创建/编辑用于模拟的场景。用户在道路的图形表示上标记位置，这些位置用于自动生成路径。SQE 402可以用于经由响应于GUI输入而生成的对API 403的结构化查询来支持这样的工具。

另一个应用是环形交叉路口检测。可以通过从车道图表示700识别道路图中的单向环路来识别环形交叉路口。可以为此目的提供用于找到任何单向环路的附加查询模式(或者更一般地，车道图700的同构子图)。有向车道图的轻微“粗化”可用于检测仅保留道路链接的环形交叉路口。该***专门查找有向道路图中的环路，该环路始于交叉路口的连接道路，并且仅由只有左车道或右车道的单侧道路()道路组成。形成环形交叉路口本身的连接环路中的所有车道都将支持相同兼容方向的交通流。

在模拟上下文中，SQE 402可以支持场景模拟器，并且在运行时间上下文中，它可以支持堆栈100内的规划/预测功能。

上述SQE 402方法的替代方案是经由原始文档的轻量级视图直接在静态层412(OpenDRIVE文档)上运行此类查询。然而，当前的OpenDRIVE格式(v1.6.1)对道路网络的描述过于含蓄，无法有效地做到这一点。

相反，几何索引409和拓扑索引411提供了文档414的几何和拓扑“视图”(在形式数据库意义上)。

索引409、411不可变，因为它们从静态层414中导出一次，并且不发生变化。

本文中对部件、功能、模块等的引用指示计算机***的功能部件，功能部件可以以各种方式在硬件级实现。一种计算机***包括执行硬件，该执行硬件可以被配置为执行本文公开的方法/算法步骤和/或实现使用本技术训练的模型。术语执行硬件包括被配置为执行相关方法/算法步骤的硬件的任何形式/组合。执行硬件可以采取一个或更多个处理器的形式，其可以是可编程的或不可编程的，或者可以使用可编程和不可编程硬件的组合。合适的可编程处理器的示例包括基于指令集架构的通用处理器，例如CPU(中央处理器，CentralProcessing Unit)、GPU(图形处理器，Graphics Processing Unit)/加速器处理器等。这样的通用处理器通常执行保持在耦接到处理器或在处理器内部的存储器中的计算机可读指令，并根据这些指令执行相关步骤。其他形式的可编程处理器包括具有可通过电路描述代码编程的电路配置的现场可编程门阵列(field programmable gate array,FPGA)。不可编程处理器的示例包括专用集成电路(application specific integrated circuit,ASIC)。代码、指令等可以适当地存储在暂时性或非暂时性介质(后者的示例包括固态、磁性和光学存储设备等)上。图1A的运行时间堆栈的子***102-108可以在可编程或专用处理器或两者的组合中实现，在测试等环境中，在车辆上或在非车载计算机***中实现。图2的各种部件，例如模拟器202和测试预言机252，可以类似地在可编程和/或专用硬件中实现。

参考文献：

上文引用了以下内容，每一项内容均通过引用整体并入本文：

[1]ASAM OpenDRIVE V1.6.1(及随附的用户指南)，发布日期为2021年3月4日[在https://www.asam.net/standards/detail/opendrive/处可获得]

Claims

1.一种计算机***，包括：

计算机存储器，被配置为存储静态道路布局；

拓扑索引部件，被配置为生成所述静态道路布局的内存拓扑索引，所述拓扑索引是节点和边的图的形式，其中，每个节点对应于所述静态道路布局的道路结构元素，并且所述边对所述道路结构元素之间的拓扑关系进行编码；

几何索引部件，被配置为生成所述静态道路布局的至少一个内存几何索引，用于将几何约束映射到所述静态道路布局的道路结构元素；以及

场景查询引擎，被配置为接收几何查询，搜索所述几何索引以定位满足所述几何查询的一个或更多个几何约束的至少一个静态道路元素，并且返回所述至少一个道路结构元素的描述符，

其中，所述场景查询引擎被配置为接收包括至少一个道路元素的描述符的拓扑查询，搜索所述拓扑索引以定位对应的节点，基于在所述拓扑索引的边中编码的拓扑关系来识别满足所述拓扑查询的至少一个其他节点，并且返回满足所述拓扑查询的其他节点的描述符。

2.根据权利要求1所述的计算机***，其中，所述拓扑索引的每个节点表示所述静态道路布局的车道，其中，每个边是从表示第一车道的节点到表示第二车道的节点的定向边，并且指示从所述第一车道到所述第二车道的许可车道变更。

3.根据权利要求2所述的计算机***，其中，所述拓扑查询包括起始车道和目的车道的描述符，并且所述场景查询引擎被配置为确定从所述起始车道到所述目的车道的车道序列，所述车道序列对应于通过所述图的从表示所述起始车道的节点到表示所述目的车道的节点的路径。

4.根据权利要求3所述的计算机***，其中，每个定向边与车道变更成本相关联，所述车道序列具有最低的总车道变更成本。

5.根据权利要求2至4中任一项所述的计算机***，其中，所述定向边包括指示许可向前车道变更的向前边和指示许可横向车道变更的横向边。

6.根据权利要求4和5所述的计算机***，其中，从表示第一车道的节点到表示第二车道的节点的每个向前边的所述车道变更成本基于所述第一车道的纵向范围；

其中，从表示第一车道的节点到表示第二车道的节点的每个横向边的所述车道变更成本基于所述第一车道和所述第二车道之间的横向距离。

7.根据权利要求2至6中任一项所述的计算机***，其中，所述静态道路布局包括双向可驾驶车道，所述双向可驾驶车道由所述拓扑索引中的两个单独节点表示，所述两个单独节点表示沿着所述双向可驾驶车道的不同驾驶方向。

8.根据任一前述权利要求所述的计算机***，其中，所述几何查询是提供位置的控制查询，其中，所述场景查询引擎被配置为使用所述空间索引来返回包含所提供的位置的道路结构元素的描述符，或者如果没有道路结构元素包含所述位置则返回空结果。

9.根据权利要求8所述的计算机***，其中，所述场景查询引擎被配置为接收提供位置的距离查询，并且返回距所述距离查询中提供的位置最近的道路结构元素的描述符，所述场景查询引擎被配置为基于所述距离查询中提供的位置不包含在任何道路结构元素中的假设来识别最近的道路结构元素。

10.根据权利要求1至7中任一项所述的计算机***，其中，所述几何查询是提供位置和所需道路结构元素类型的控制查询，其中，所述场景查询引擎被配置为使用所述空间索引来返回包含所提供的位置的所需道路结构元素类型的车道的描述符，或者如果没有所述所需道路结构元素类型的道路结构元素包含所述位置则返回空结果。

11.根据权利要求10所述的计算机***，其中，所述场景查询引擎被配置为接收提供位置和所需道路结构元素类型的距离查询，并且返回所述所需道路结构元素类型中距所述距离查询中提供的位置最近的道路结构元素的描述符，所述场景查询引擎被配置为基于所述距离查询中提供的位置不包含在所述所需道路结构元素类型的任何道路结构元素中的假设来识别最近的道路结构元素。

12.根据权利要求9或11所述的计算机***，其中，所述几何索引部件被配置为生成一个或更多个线段索引，所述一个或更多个线段索引包含位于道路结构元素之间的边界上的线段，每个线段与道路结构元素标识符相关联地存储，其中，位于两个道路结构元素之间的边界上的每个线段的两个副本与这两个道路结构元素的不同道路结构元素标识符相关联地存储在所述一个或更多个线段索引中，所述一个或更多个线段索引用于处理所述距离查询。

13.根据从属于权利要求11的权利要求12所述的计算机***，其中，所述场景引擎被配置为将编码所述所需道路结构元素类型的过滤器应用于所述一个或更多个线段索引，以过滤出与所述所需道路结构元素类型不匹配的线段，由此过滤出与所述所需道路结构元素类型不匹配的、关联于第一道路结构元素标识符的线段的第一副本，但是不过滤出与所述所需道路结构元素类型匹配的、关联于第二道路结构元素标识符的所述线段的第二副本，过滤后的一个或更多个线段索引用于处理所述距离查询。

14.根据权利要求8至13中任一项所述的计算机***，其中，所述至少一个空间索引包括边界框索引，所述边界框索引包含用于处理所述控制查询的道路结构元素或其部分的边界框，每个边界框与道路结构元素标识符相关联。

15.根据从属于权利要求10的权利要求14所述的计算机***，其中，所述场景引擎被配置为将对所述所需道路结构元素类型进行编码的过滤器应用于所述边界框索引，以过滤出与所述所需道路结构元素类型不匹配的线段，过滤后的边界框索引用于处理所述控制查询。

16.根据任一前述权利要求所述的计算机***，其中，所述道路结构元素的描述符允许所述道路结构元素直接根据所述描述符位于所述静态道路布局中。

17.根据权利要求16所述的计算机***，其中，所述静态道路布局编码在符合结构化场景描述格式的规范中，所述描述符允许所述道路结构元素位于所述规范中。

18.根据权利要求16或17所述的计算机***，包括第二应用编程接口，所述第二应用编程接口被配置为接收道路结构元素的描述符，使用所述描述符来定位所述静态道路布局中的道路结构元素，从所述静态道路布局中提取关于所述道路结构元素的信息片段，并且返回包括所提取的信息片段的响应。

19.根据权利要求17和18所述的计算机***，其中，所述计算机***被配置为生成所述规范的内存表示，所述信息片段从所述规范的所述内存表示中提取。

20.根据从属于权利要求13或14的权利要求19所述的计算机***，其中，所述规范的内存表示用于应用所述过滤器，所述一个或更多个线段索引或所述边界框索引中的道路结构元素标识符用于在所述规范的内存表示中定位所识别的道路结构以应用所述过滤器。

21.根据权利要求11和12或从属于权利要求11或12的任一权利要求所述的计算机***，其中，所述一个或更多个线段索引包括内边界线段索引和外边界线段索引，其中，所述内边界线段索引用于定位所述所需道路结构元素类型的最近内边界线段，所述外边界线段索引用于定位所述所需道路结构元素类型的最近外边界线段，将所述最近内边界线段和所述最近外边界线段与所提供的位置进行比较以确定哪个最接近所提供的位置。

22.一种处理对静态道路布局的查询的计算机实现方法，所述方法包括：

在索引阶段：

在内存中生成所述静态道路布局的车道图，所述静态道路布局包括多个车道的网络，所述方法包括：

为所述多个车道中的每个车道，生成表示所述车道的车道图的节点；

识别所述静态道路网络中的许可车道变更集合，并且为从第一车道到第二车道的每个许可车道变更，生成从表示所述第一车道的节点到表示所述第二车道的节点的定向边；

计算每个车道变更的车道变更成本；

与所述边相关联地存储每个边的所述车道变更成本；

在运行时间阶段：

接收指示起始车道和目的车道的查询；

使用所述车道图将从所述起始车道到所述目的车道的路线确定为车道序列，所述车道序列对应于通过所述车道图的从表示所述起始车道的节点到表示所述目的车道的节点的路径，所述路径具有最低的总车道变更成本；以及

输出对所述查询的响应，所述响应包括所述路线的描述符。

23.一种计算机***，包括被配置为执行权利要求22的方法的一个或更多个计算机处理器。

24.一种计算机程序，被配置为实现任一前述权利要求的***功能或方法。