CN116661744A - 运营设计域建立方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请涉及无人驾驶技术领域，提供了一种运营设计域建立方法、装置、电子设备及存储介质。该方法包括：响应于车辆进入预设地理围栏，自云服务器或者第一路侧装置获取第一条件向量，第一条件向量用于指示地理围栏区域内的环境条件；自第一路侧装置获取第二条件向量，第二条件向量用于指示第一路侧装置检测范围内的环境条件；通过车辆的车载传感装置，获取第三条件向量，第三条件向量用于指示车辆检测范围内的环境条件；根据第一条件向量、第二条件向量和第三条件向量，建立运营设计域。采用本申请实施例提供的方法，能够在车辆进入地理围栏区域后实时建立运营设计域，为自动驾驶能否进行提供实时判断条件。

Description

运营设计域建立方法、装置、电子设备及存储介质

技术领域

本申请涉及无人驾驶技术领域，尤其涉及一种运营设计域建立方法、装置、电子设备及存储介质。

背景技术

软件定义汽车(Software Defined Vehicles，SDV)是新能源智慧网联汽车的持续发展过程，也是产业升级的重要方向。汽车电子电气架构正逐渐被域控制器甚至中央计算架构替代，软件应用能够与底层硬件实现解耦，朝网联IT运营的方向转变。

自动驾驶是SDV支持的重要场景，通过先进的通信网络、路测装置和车载传感器，并综合运用数字孪生、人工智能等技术，智慧网联汽车正朝着驾驶自动化第三级别(L3)的自动驾驶场景稳步推进。

为保证自动驾驶能够在不同类型的道路以及不同环境下均能正确工作，需要在运营设计域(Operational Design Domain，ODD)中对自动驾驶系统进行验证和约束。其中，ODD如何设计以保证自动驾驶测验证和约束的完整性，是需要解决的技术问题。

发明内容

有鉴于此，本申请实施例提供了一种运营设计域建立方法、装置、电子设备及计算机可读存储介质，以解决现有技术中运营设计域的建立效率不高的问题。

本申请实施例的第一方面，提供了一种运营设计域建立方法，包括：

响应于车辆进入预设地理围栏，自云服务器或者第一路侧装置获取第一条件向量，第一条件向量用于指示地理围栏区域内的环境条件；

自第一路侧装置获取第二条件向量，第二条件向量用于指示第一路侧装置检测范围内的环境条件；

通过车辆的车载传感装置，获取第三条件向量，第三条件向量用于指示车辆检测范围内的环境条件；

根据第一条件向量、第二条件向量和第三条件向量，建立运营设计域。

本申请实施例的第二方面，提供了一种运营设计域建立装置，包括：

第一获取模块，被配置为响应于车辆进入预设地理围栏，自云服务器或者第一路侧装置获取第一条件向量，第一条件向量用于指示地理围栏区域内的环境条件；

第二获取模块，被配置为自第一路侧装置获取第二条件向量，第二条件向量用于指示第一路侧装置检测范围内的环境条件；

第三获取模块，被配置为通过车辆的车载传感装置，获取第三条件向量，第三条件向量用于指示车辆检测范围内的环境条件；

建立模块，被配置为根据第一条件向量、第二条件向量和第三条件向量，建立运营设计域。

本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并且可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。

本申请实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例与现有技术相比存在的有益效果是：本申请实施例通过分别自云端服务器获取用于指示地理围栏区域内的环境条件的第一条件向量、用于指示路侧装置检测范围内的环境条件的第二条件向量以及用于指示车辆检测范围内的环境条件的第三条件向量，并基于第一条件向量、第二条件向量和第三条件向量，建立ODD，提供了ODD的建立方法，能够在车辆进入地理围栏区域后实时建立ODD，为自动驾驶能否进行提供实时判断条件。

附图说明

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

图1是本申请实施例的应用场景的场景示意图。

图2是本申请实施例提供的一种运营设计域建立方法的流程示意图。

图3是本申请实施例提供的一种运营设计域建立方法的流程示意图。

图4是本申请实施例提供的一种运营设计域建立方法的流程示意图。

图5是本申请实施例提供的一种运营设计域建立方法的流程示意图。

图6是本申请实施例提供的一种运营设计域建立方法的流程示意图。

图7是本申请实施例提供的一种运营设计域建立方法的应用场景的示意图。

图8是典型的移动边缘计算融合架构的示意图。

图9是本申请实施例提供的一种ODD建构方法流程图。

图10是本申请实施例提供的数字运营区域的示意图。

图11是本申请实施例提供的RSU小环境区域的示意图。

图12是本申请实施例提供的一种ODD建构方法流程图。

图13是本申请实施例提供的一种运营设计域建立装置的示意图。

图14是本申请实施例提供的电子设备14的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

下面将结合附图详细说明根据本申请实施例的一种运营设计域建立方法和装置。

图1是本申请实施例的应用场景的场景示意图。该应用场景可以包括车辆1、路侧装置2、服务器3以及网络4。

车辆1可以是硬件，也可以是软件。当车辆1为硬件时，其可以是支持与路侧装置2和服务器3通信的各种车载电子设备，包括但不限于车载通信装置(Telematics-BOX，TBOX)、车载单元(On board Unit，OBU)、车载娱乐系统等；当车辆1为软件时，其可以安装在如上所述的电子设备中。车辆1可以实现为多个软件或软件模块，也可以实现为单个软件或软件模块，本申请实施例对此不作限制。进一步地，车辆1上可以安装有各种应用，例如数据处理应用、即时通信工具、社交平台软件、搜索类应用、购物类应用等。

路侧装置2可以是硬件，也可以是软件。当路侧装置2为硬件时，其可以是支持与车辆1和服务器3通信的各种电子设备。当路侧装置2为软件时，其可以安装在如上所述的电子设备中。

服务器3可以是提供各种服务的服务器，例如，对与其建立通信连接的车辆1和路侧装置2发送的请求进行接收的后台服务器，该后台服务器可以对终端设备发送的请求进行接收和分析等处理，并生成处理结果。服务器3可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者还可以是一个云计算服务中心，本申请实施例对此不作限制。

需要说明的是，服务器3可以是硬件，也可以是软件。当服务器3为硬件时，其可以是为车辆1和路侧装置2提供各种服务的各种电子设备。当服务器3为软件时，其可以是为车辆1和路侧装置2提供各种服务的多个软件或软件模块，也可以是为车辆1和路侧装置2提供各种服务的单个软件或软件模块，本申请实施例对此不作限制。

网络4可以是采用同轴电缆、双绞线和光纤连接的有线网络，也可以是无需布线就能实现各种通信设备互联的无线网络，例如，蓝牙(Bluetooth)、近场通信(Near FieldCommunication，NFC)、红外(Infrared)等，本申请实施例对此不作限制。

车辆1经由侧链路通信Sidelink网络与路侧装置2建立通信连接，并通过蜂窝网络4与服务器3建立通信连接，以接收或发送信息等。

需要说明的是，车辆1、路侧装置2、服务器3以及网络4的具体类型、数量和组合可以根据应用场景的实际需求进行调整，本申请实施例对此不作限制。

上文提及，为保证自动驾驶能够在不同类型的道路以及不同环境下均能正确工作，需要在ODD中对自动驾驶系统进行验证和约束。这是因为，目前自动驾驶技术还处于发展阶段，无法保证自动驾驶车辆在任何道路环境中以及任何天气条件下都能够安全行驶。因此，需要根据车辆自动驾驶系统的能力来提前设定好ODD，通过限制行驶环境和行驶方法来防患于未然。

第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)定义了4种车辆网(Vehicle to X，V2X)应用，包括车辆与车辆的通信(Vehicle to Vehicle，V2V)、车辆与基础设施的通信(Vehicle to Infrastructure，V2I)、车辆与网络的通信(Vehicle toNetwork，V2N)、车辆与行人的通信(Vehicle to Pedestrian，V2P)，并进一步定义了新空口(New Radio，NR)下的4种场景，即编队驾驶、传感共享、高级驾驶和远程驾驶。这对L3级别的ODD建立提出了很高的要求。SAE J3016《驾驶自动化分级》中，将ODD定义为“特定驾驶自动化系统或其功能专门设计的运行条件，包括但不限于环境、地理和时间限制，和/或某些交通或道路特征的存在或缺失”。

也就是说，ODD需定义在哪些工况下能够支持自动驾驶，脱离这些工况，应该切换到什么形式的驾驶状态。相关技术中存在一些判断车辆当前实际运行区域是否满足ODD的方案，但如何建立ODD相关文献中尚无记载。

鉴于此，本申请实施例提供了一种ODD建立方法，通过分别自云端服务器获取用于指示地理围栏区域内的环境条件的第一条件向量、用于指示路侧装置检测范围内的环境条件的第二条件向量以及用于指示车辆检测范围内的环境条件的第三条件向量，并基于第一条件向量、第二条件向量和第三条件向量，建立ODD，提供了ODD的建立方法，能够在车辆进入地理围栏区域后实时建立ODD，为自动驾驶能否进行提供实时判断条件。

图2是本申请实施例提供的一种运营设计域建立方法的流程示意图。如图2所示，该运营设计域方法包括：

在步骤S201中，响应于车辆进入预设地理围栏，自云服务器或者第一路侧装置获取第一条件向量。

其中，第一条件向量用于指示地理围栏区域内的环境条件。

在步骤S202中，自第一路侧装置获取第二条件向量。

其中，第二条件向量用于指示第一路侧装置检测范围内的环境条件。

在步骤S203中，通过车辆的车载传感装置，获取第三条件向量。

其中，第三条件向量用于指示车辆检测范围内的环境条件。

在步骤S204中，根据第一条件向量、第二条件向量和第三条件向量，建立运营设计域。

本申请实施例中，运营设计域方法可以由图1中车辆1或2的车载单元执行。其中，车载单元(On board Unit，OBU)可以是车载电子单元，包括电源管理、车辆信息管理以及通信模块。OBU可以与路侧装置(Road Side Unit，RSU)通信。具体的，OBU可以与RSU以侧链路(Sidelink)通信的方式进行连接，以实现低时延高可靠通信(Ultra Reliable&LowLatency Communication，URLLC)。其中，RSU中可以部署边缘计算单元，例如部署边缘云，以对接收和检测到的时效性要求不高的数据进行预处理后发送至OBU，从而减少OBU的计算负担，提高数据处理能力。

另一方面，OBU还可以与云端服务器通过5G等蜂窝网络进行通信。同时，云端服务器与RSU之间也可以通过5G等蜂窝网络进行通信。

本申请实施例中，响应于车辆进入预设地理围栏，车载OBU可以自云服务器或者第一路侧装置获取第一条件向量。其中预设地理围栏可以是预先划定的，可以进行自动驾驶的区域，例如自动驾驶测试路段区域。地理围栏可以是电子围栏。当车辆进入该区域时，车载OBU可以被触发，实时建立ODD，并根据建立的ODD判断当前是否满足ODD条件，若是则继续自动驾驶，若非则终止自动驾驶。

具体的，OBU可以获取车辆的实时位置，并在确定车辆实时位置位于预设地理围栏范围内时，由OBU向云端服务器发送获取第一条件向量的请求消息，云端服务区在接收到该请求消息后，下发第一条件向量至OBU。另一方面，也可以由OBU上报车辆的实时位置至云端服务器，云端服务器在确定车辆实时位置位于预设地理围栏范围内时，直接下发第一条件向量至OBU。其中，第一条件向量用于指示地理围栏区域内的环境条件。

本申请实施例中，OBU还可以自第一RSU获取第二条件向量。其中，第一RSU是车辆当前连接的RSU。为支持车辆正确执行自动驾驶操作，需要在路旁安装RSU，以收集、处理并转发环境信息和车辆信息。车辆在驶入RSU的通信覆盖范围内时，可以与RSU建立通信连接，该通信连接可以是Sidelink通信连接，即OBU与RSU之间通过5G NR Sidelink的PC5接口，实现设备与设备通信(Device to Device，D2D)。OBU以Sidelink通信方式直接自RSU获取第二条件向量，不受基站转发能力以及蜂窝网络带宽分配限制。其中，第二条件向量用于指示第一路侧装置检测范围内的环境条件。

本申请实施例中，OBU还可以通过车辆的车载传感装置，获取第三条件向量。其中，车载传感装置可以包括车载全景相机、车载激光雷达、车载加速度传感器、车载陀螺仪、车载温湿度传感器、胎压传感器等。通过整车的各个电子控制单元(Electronic ControlUnit，ECU)和域控制器，车辆可以获取传感器参数，并将传感器参数处理为运行数据集，得到第三条件向量。其中，第三条件向量用于指示车辆检测范围内的环境条件。

本申请实施例中，可以根据第一条件向量、第二条件向量和第三条件向量，建立运营设计域。也就是说，OBU在获取的指示地理围栏区域内的环境条件的第一条件向量、指示第一RSU检测范围内的环境条件的第二条件向量以及指示车辆检测范围内的环境条件的第三条件向量后，可以认为OBU当前已经获取了用于建立ODD的全部条件，基于第一向量、第二条件向量和第三条件向量，可以建立车辆自动驾驶的实时ODD。

根据本申请实施例提供的技术方案，通过分别自云端服务器获取用于指示地理围栏区域内的环境条件的第一条件向量、用于指示路侧装置检测范围内的环境条件的第二条件向量以及用于指示车辆检测范围内的环境条件的第三条件向量，并基于第一条件向量、第二条件向量和第三条件向量，建立ODD，提供了ODD的建立方法，能够在车辆进入地理围栏区域后实时建立ODD，为自动驾驶能否进行提供实时判断条件。

ODD的设计要素种类繁多，不同的组织规定的ODD需要包含必要条件存在细微差异，但其包括的要素大致相同。可以参考美国国家交通安全管理局(National HighwayTraffic Safety Administration，NHTSA)在分类标准《AFramework for AutomatedDriving System Testable Cases and Scenarios》中给出的定义，使用基础设施(Physical Infrastructure)、驾驶操作限制(Operational Constraints)、周边物体(Objects)、互联(Connectivity)、环境条件(Environmental Conditions)和区域(Zones)六要素来构建ODD。

表1给出六要素的具体含义。

表1

如表1所示，基础设施可以包括道路类型、道路表面、道路边缘和道路几何等；驾驶操作限制可以包括速度限制和交通条件等；周边物体可以包括标志标牌、道路使用者和非道路使用者障碍物/物体等；互联可以包括车辆、交通密集信息、远程车队管理系统和设施传感器等；环境条件可以包括天气、天气导致的路面条件、颗粒物和光照等；区域可以包括地理围栏、交通管制区域、学校区域、国家/州和干扰区域等。其中，基础设施、驾驶操作限制、周边物体中的标志标牌和区域元素通常为静态元素，可以由云端服务器获取并下发至OBU。周边物体中的道路使用者和非道路使用者障碍物/物体、环境条件以及互联元素可能随车辆所处位置不同而变化，因此可以通过RSU或者OBU实时采集。进一步的，本申请还考虑车辆运行时的状态以及其他车辆与人员条件，这些条件由车辆的传感器直接采集，并传输至OBU集中处理，计算ODD。即，可以对建立ODD的各类元素进行分类，针对不同类型的元素采用不同的采集获取方式。

本申请实施例中，可以通过云端服务器获取地理围栏区域内的基础设施条件、法律法规条件、网络基础设施与路网条件以及道路条件，并基于获取的各条件构建第一条件向量。也就是说，第一条件向量可以包括地理围栏区域内的基础设施条件、法律法规条件、网络基础设施与路网条件和/或道路条件。其中，基础设施条件包括驾驶操作限制条件、标志标牌条件、非道路使用者障碍物/物体条件和区域条件等，道路条件包括国土规划条件等。

具体的，将基础设施条件用向量表示，将法律法规条件用向量/>表示，网络基础设施与路网条件用向量/>表示，道路条件用向量/>表示，则第一条件向量/>可以由下式计算得到：

其中，*为卷积运算符。

本申请实施例中，可以通过RSU获取RSU检测范围内的道路变化条件和气候条件，并基于获取的各条件构建第二条件向量。也就是说，第二条件向量包括道路变化条件和/或气候条件。

其中，RSU检测范围是指RSU中安装的传感器能够进行的范围，以及RSU能够与周围车辆建立通信连接的范围。例如，若RSU中安装了图像传感器，则可以确定图像传感器能够获取周边图像的检测范围。将各传感器的检测范围与RSU能够与周围车辆建立通信连接的范围求并集，得到的最大范围可以作为该RSU的检测范围。

进一步的，道路变化条件可以包括临时交通管制条件、道路施工等人工和组织条件等，气候条件可以包括天气条件、颗粒物条件、光照条件、横风条件、积水条件、结冰条件、大雾条件等。其中，道路变化条件可以来自相关部分的信息发布，可以由云端服务器下发至地理围栏区域内的所有RSU。在某些情况下，云端服务器也可以将道路变化条件直接下发至OBU。

更进一步的，将道路变化条件用向量表示，将气候条件用向量/>表示，则第二条件向量/>可以由下式计算得到：

本申请实施例中，可以通过OBU获取车辆运行状态条件以及车辆检测到的其他车辆与人员条件，并基于获取的各条件构建第一条件向量。也就是说，第三条件向量包括车辆运行状态条件和/或车辆检测到的其他车辆与人员条件。

具体的，将车辆运行状态条件用向量表示，将车辆检测到的其他车辆与人员条件用向量/>表示，则第三条件向量/>可以由下式计算得到：

进一步的，建立的ODD可以通过下式计算得到：

其中，向量表示建立得到的ODD。

根据本申请实施例提供的技术方案，通过将建立ODD需要的元素分为对应地理围栏范围的大环境元素、对应RSU检测区域的小环境元素以及对应车辆检测区域的实时环境元素，分别由云端服务器获取大环境下的第一条件向量，由RSU获取小环境下的第二条件向量，并由车辆获取实时环境下的第三条件向量，能够提高清晰高效地获取建立ODD的条件向量，提高ODD建立的效率及可靠性。

本申请实施例中，云端服务器可以将计算得到的第一条件向量直接发送至OBU，以使OBU根据接收到的向量/>自RSU接收到的向量/>以及OBU根据车辆传感器采集的数据计算得到的向量/>计算得到向量/>另一实施方式中，由于向量/>与向量/>的通常都不是实时大幅变化的向量，且RSU中可以部署边缘计算模块，该边缘计算相比OBU而言处理能力更强，因此可以将云端服务器计算得到的向量/>首先发送至RSU，RSU将接收的向量/>与RSU自身确定的向量/>首先进行卷积运算，然后将运算结果/>发送至OBU，以使OBU可以直接将该运算结果与OBU自身确定的向量/>进行卷积计算，即可得到向量/>完成ODD的建立。

根据本申请实施例提供的技术方案，通过在RSU中首先计算第一条件向量和第二条件向量的卷积运算结果，然后由OBU基于接收到的该卷积运算结果与第三条件向量进行卷积运算，得到ODD，能够减少OBU侧计算复杂度，进一步提高ODD建立效率。

图3是本申请实施例提供的一种运营设计域建立方法的流程示意图。其中，图3所示实施例中的步骤S301至步骤S304与图2所示实施例中的步骤S201至步骤D204相同，此处不再赘述。如图3所示，该方法还包括：

在步骤S305中，自云服务器接收更新后的第一条件向量。

其中，更新后的第一条件向量是在第一条件向量中的任意一项或者多项环境条件发生变化时，由云端服务器对第一条件向量进行更新后得到的。

在步骤S306中，基于更新后的第一条件向量、第二条件向量和第三条件向量，建立运营设计域。

本申请实施例中，第一条件向量可能发生变化。例如，若云端服务器自相关部门接收到通知，地理围栏范围内某区域将在预设时间进行交通管制，则云端服务器可以计算车辆在自动驾驶状态下，在该预设时间范围内是否将驶入交通管制区域，若是则更新第一条件向量，并将该更新后的第一条件向量发送至OBU，以使OBU基于更新后的第一条件向量、第二条件向量和第三条件向量，建立运营设计域。

本申请实施例中，云端服务器也可以首先将更新后的第一条件向量发送至RSU，再由RSU转发至OBU，从而可以仅使用一次蜂窝网下发数据，随后由RSU基于Sidelink直接转发数据至一个或多个OBU，提高数据发送的效率和可靠性。

图4是本申请实施例提供的一种运营设计域建立方法的流程示意图。其中，图4所示实施例中的步骤S401至步骤S406与图3所示实施例中的步骤S301至步骤D306相同，此处不再赘述。如图4所示，该方法还包括：

在步骤S407中，响应于车载单元与第一路侧装置断开连接，并与第二路侧装置建立连接，且第二路侧单元中不包括更新后的第一条件向量，自第二路侧装置获取更新后的第二条件向量。

其中，更新后的第二条件向量用于指示第二路侧装置检测范围内的环境条件。

在步骤S408中，根据第一条件向量、更新后的第二条件向量和第三条件向量，建立运营设计域。

在步骤S409中，响应于车载单元与第一路侧装置断开连接，并与第二路侧装置建立连接，且第二路侧单元中包括更新后的第一条件向量，自第二路侧装置获取更新后的第一条件向量和更新后的第二条件向量。

其中，更新后的第二条件向量用于指示第二路侧装置检测范围内的环境条件。

在步骤S410中，根据更新后的第一条件向量、更新后的第二条件向量和第三条件向量，建立运营设计域。

本申请实施例中，RSU的小环境中，环境条件可能发生变化，但由于车辆具有一定的行驶速度，且RSU的检测范围通常不会特别大，因此可以假设车辆在一个RSU的检测范围内行驶时，小环境的环境条件是稳定的。即，一个RSU仅确定一次第二条件向量。当道路变化条件和/或气候条件发生变化时，变化影响范围内的RSU都可以接收到该变化信息。例如，RSU可以通过从气象部门获取的天气信息得知，地理围栏范围内某区域可能在预设时间后出现大雾。由于大雾并非瞬时出现的，因此，可以由车辆行驶中连接的下一个RSU来基于获取的大雾信息更新第二条件向量，从而在保证ODD正确的前提下，降低ODD计算频率，减少资源消耗。

进一步的，车辆在行驶过程中，会经过多个RSU，因此，可以在车辆切换RSU时进行第二条件向量的更新。即，可以在车辆的OBU与第一RSU断开连接，并与第二RSU建立连接时，自第二RSU获取更新后的第二条件向量。

更进一步的，RSU还可以判断RSU中是否保存了更新后的第一条件向量，若是，则将该更新后的第一条件向量与该更新后的第二条件向量发送至OBU，以使OBU基于更新后的第一条件向量、更新后的第二条件向量和第三条件向量，建立运营设计域。否则，RSU仅将更新后的第二条件向量发送至OBU，以使OBU基于第一条件向量、更新后的第二条件向量和第三条件向量，建立运营设计域。

图5是本申请实施例提供的一种运营设计域建立方法的流程示意图。其中，图5所示实施例中的步骤S501至步骤S510与图4所示实施例中的步骤S401至步骤D410相同，此处不再赘述。如图5所示，该方法还包括：

在步骤S511中，周期性更新第三条件向量。

在步骤S512中，根据第一条件向量或者更新后的第一条件向量，第二条件向量或者更新后的第二条件向量，以及更新后的第三条件向量，建立运营设计域。

本申请实施例中，第三条件向量也可能发生变化。例如，车辆检测车辆运行状态出现状况，例如车辆的图像采集装置被异物覆盖，导致车辆无法正确采集图像。此时，可以更新第三条件向量，同时判断OBU是否接收了更新后的第一条件向量和/或更新后的第二条件向量，并根据判断结果则基于第一条件向量或者更新后的第一条件向量，第二条件向量或者更新后的第二条件向量，以及更新后的第三条件向量，建立运营设计域。

图6是本申请实施例提供的一种运营设计域建立方法的流程示意图。其中，图6所示实施例中的步骤S601至步骤S604与图2所示实施例中的步骤S201至步骤D204相同，此处不再赘述。如图6所示，该方法还包括：

在步骤S605中，获取车辆行驶参数，响应于行驶参数不满足运营设计域要求，生成终止自动驾驶提示消息。

本申请实施例中，车载单元可以实时获取车辆行驶参数，包括车辆行驶状态、车辆行驶环境、车辆行驶路况等参数，并将获取的车辆行驶参数与计算得到的ODD进行比较，当车辆行驶参数满足ODD要求时，车辆继续自动驾驶；当车辆行驶参数不满足ODD要求时，OBU生成终止自动驾驶提示消息，提示驾驶员介入。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

图7是本申请实施例提供的一种运营设计域建立方法的应用场景的示意图。如图7所示，该方法可应用于“云-网-车”系统。该系统中包括云端服务器智驾云，网端RSU，以及车端车辆。智驾云可以与RSU和车分别通过蜂窝网络通信，车与RSU、车与车均可以通过Sidelink通信。该系统可以是一个典型的车联网V2X应用。

V2X中对通信延时和数据带宽要求非常高，是5G场景增强移动宽带(EnhancedMobile Broadband，eMBB)和uRLLC的一种典型应用。因此，可以将核心网元部分下沉到边缘，以减少用户侧数据时延，提高系统效率。

图8是典型的移动边缘计算融合架构的示意图。如图8所示，移动边缘计算(MobileEdge Computing，MEC)架构中，可以包括边缘云和中心云，其中边缘云和中心云中均包括用户面功能(UPF)模块，这是5G核心网的关键网元，能全面处理用户面的各种功能，所有数据经UPF转发后才能流向外部网络。本申请实施例中，网络可以采用UPF+RSU+OBU的方式构建。

进一步的，边缘云中还可以包括提供公共服务的MEC模块，中心云中还可以包括5G核心网控制面(5GC CP)和统一数据管理(UDM)模块，其中，UDM与5GC CP连接，5GC CP与基站gNB通过N2接口连接，与边缘云UPF通过N4结果连接，与中心云UPF通过N6接口连接。边缘云UPF与中心云UPF通过N9接口连接，与gNB通过N3接口连接。中心云UPF通过N6接口与公网连接，MEC模块通过N6接口与边缘云UPF连接。

地理信息系统(GIS)是LBS服务的核心，本申请实施例中，还可以以GIS为基础，融合环境信息系统(EIS)信息，为自动驾驶运营企业提供了宏观运营尺度。即，本申请实施例中，可以以GIS+EIS作为信息面基础。

图9是本申请实施例提供的一种ODD建构方法流程图。如图9所示，本申请实施例中，可以遵循大环境→小环境→微环境的构建思路，构建ODD。具体的：

在步骤S901中，融合GIS和数字大屏技术，构建数字运营区域。

在步骤S902中，以RSU为信息和发布源，构建小环境区域。

在步骤S903中，以车载OBU为边缘计算单元，构建实时运行区域。

本申请实施例中，可以在云端基于GIS构架数字运营区域，并通过数字大屏实时展示该数字运营区域，且数字大屏还可以结合数字孪生技术，对数字运营区域内的车辆和环境情况进行实时展示。进一步的，还可以以RSU为信息和发布源，构建小环境区域。更进一步的，也可以将边缘计算单元进一步下沉至车载OBU，在OBU构建实时运行区域。

图10是本申请实施例提供的数字运营区域的示意图。如图10所示，数字运营区域可以是以GIS为数据基础，对路网、建筑和高程信息开展数字建模，得到的可视化的GIS大屏，可以通过大屏管理云端数据和策略，为自动驾驶运营赋能。

图11是本申请实施例提供的RSU小环境区域的示意图。如图11所示，数字运营区域中可以包括多个RSU，每个RSU接收相关部门发布的信息，例如气象部门发布的天气条件信息。OBU可以将相关信息通知驾乘人，并在进入管制区RSU划定的围栏前予以警报。城市空间热岛效应和街巷地形复杂，本申请实施例可以将小环境的条件统一由RSU负责集中侦测和发布，从而利用5G NR的低延时通信能力，在RSU上实现边缘计算，减少车机的计算负荷，将有限的本地计算能力运用到提升驾驶安全性和驾乘体验上。

其中，RSU部署阶段需完成位置标定(包括经纬度和高程)，自动驾驶车辆与RSU间通过5G PC5接口，采用Sidelink通信方式，在公网环境下实现D2D通信，数据不过基站，减少核心网数据拥塞。OBU通过RSU获取当前和临近区域的环境信息，并对积水、结冰、颗粒物等不利于驾驶的路况进行实时告警。

城市环境行车过程中OBU可以处理的动态因素包括但不限于其他人员和车辆。例如路人、执法人员、宠物、车型、车距、特种车辆等，以及车辆运行状态，例如车速、胎压、转向等。通过车载全景相机和激光雷达等传感器，可以识别人员和车辆类型，基于5G NRSidelink的D2D和D2I通信方式，以RSU标定为绝对位置为定位基点，车载OBU能够识别其它车辆和人员，并通过出发角度法(Angle of Departure，AoD)定位和路径微分实现相对位置和相对加速度的判断。根据判断结果，向整车控制器发送减速、紧急避让等主动安全动作指令。车辆的运行状态可通过传感器获取，包括但不限于加速度传感器、陀螺仪、温湿度传感器、胎压传感器等，通过整车各ECU和域控制器，传感器参数能够组成运行数据集。一些被动安全策略如制动防抱死系统(Sntilock Brake System，ABS)、车身电子稳定系统(Electronic Stability Program，ESP)等，以及主动安全策略依赖上述数据集。

图12是本申请实施例提供的一种ODD建构方法流程图。如图12所示，该方法包括：

在步骤S1201中，车载OBU配置双网络和机卡绑定，进入数字运营区域围栏后，容器化部署数字地图信息。

在步骤S1202中，开启5G NR切片和PC5接口，与RSU建立通信，并获取小环境信息。

在步骤S1203中，车载OBU运行实时控制算法，完成车辆控制。

在步骤S1204中，车辆超出数字运营区域，通知驾驶员介入。

本申请实施例中，车载OBU可以配置双数据网络标识(Data Network Name，DN)进行机卡绑定，即OBU连接两个网络，一个为公网，另一个为自动驾驶通信专网。在车辆进入数字运营区域的围栏后，可以容器化部署数字运营区域的数字地图信息。可以理解的是，车辆在行驶中可能途径多个不同的数字运营区域，因此可以在进入每个数字运营区域时，分别部署各数字运营区域对应的数字地图信息。

进一步的，在获取数字地图信息，得到大环境信息后，OBU还可以开启5G NR切片和PC5接口，与RSU建立通信，获取小环境信息。更进一步的，车载OBU运行实时控制算法，获取实时环境信息，建立ODD并完成车辆控制。最后，在车辆超出数字运营区域时，ODD通知驾驶员介入。

采用本申请实施例的技术方案，面向城市空间特点，结合5G NR的V2X技术，利用其高带宽和低延时特性，相比其它无线通信方式，能减少信号串扰，将纯粹由车机开展的“端计算”升级为RSU+OBU的“边缘计算”，节省了有限的车载算力。同时，双DNN核机卡绑定等运营商策略，进一步提升了车机的信息安全能力。进一步的，本申请实施例采用数字孪生和大屏技术，能够提供了可实现、可维护的自动驾驶运营系统，实用性强。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图13是本申请实施例提供的一种运营设计域建立装置的示意图。如图13所示，该装置包括：

第一获取模块1301，被配置为响应于车辆进入预设地理围栏，自云服务器或者第一路侧装置获取第一条件向量，第一条件向量用于指示地理围栏区域内的环境条件；

第二获取模块1302，被配置为自第一路侧装置获取第二条件向量，第二条件向量用于指示第一路侧装置检测范围内的环境条件；

第三获取模块1303，被配置为通过车辆的车载传感装置，获取第三条件向量，第三条件向量用于指示车辆检测范围内的环境条件；

建立模块1304，被配置为根据第一条件向量、第二条件向量和第三条件向量，建立运营设计域。

根据本申请实施例提供的技术方案，通过分别自云端服务器获取用于指示地理围栏区域内的环境条件的第一条件向量、用于指示路侧装置检测范围内的环境条件的第二条件向量以及用于指示车辆检测范围内的环境条件的第三条件向量，并基于第一条件向量、第二条件向量和第三条件向量，建立ODD，提供了ODD的建立，能够在车辆进入地理围栏区域后实时建立ODD，为自动驾驶能否进行提供实时判断条件。

本申请实施例中，第一条件向量包括地理围栏区域内的法律法规条件、网络基础设施条件、路网条件和/或道路条件；第二条件向量包括道路变化条件和/或气候条件；第三条件向量包括车辆运行状态条件和/或车辆检测到的其他车辆与人员条件。

本申请实施例中，根据第一条件向量、第二条件向量和第三条件向量，建立运营设计域，包括：对第一条件向量、第二条件向量和第三条件向量进行卷积运算，得到运营设计域。

本申请实施例中，还包括：自云服务器接收更新后的第一条件向量，其中，更新后的第一条件向量是在第一条件向量中的任意一项或者多项环境条件发生变化时，由云端服务器对第一条件向量进行更新后得到的；基于更新后的第一条件向量、第二条件向量和第三条件向量，建立运营设计域。

本申请实施例中，还包括：响应于车载单元与第一路侧装置断开连接，并与第二路侧装置建立连接，且第二路侧单元中不包括更新后的第一条件向量，自第二路侧装置获取更新后的第二条件向量，更新后的第二条件向量用于指示第二路侧装置检测范围内的环境条件；根据第一条件向量、更新后的第二条件向量和第三条件向量，建立运营设计域；或者响应于车载单元与第一路侧装置断开连接，并与第二路侧装置建立连接，且第二路侧单元中包括更新后的第一条件向量，自第二路侧装置获取更新后的第一条件向量和更新后的第二条件向量，更新后的第二条件向量用于指示第二路侧装置检测范围内的环境条件；根据更新后的第一条件向量、更新后的第二条件向量和第三条件向量，建立运营设计域。

本申请实施例中，还包括：周期性更新第三条件向量；根据第一条件向量或者更新后的第一条件向量，第二条件向量或者更新后的第二条件向量，以及更新后的第三条件向量，建立运营设计域。

本申请实施例中，还包括：获取车辆行驶参数，响应于行驶参数不满足运营设计域要求，生成终止自动驾驶提示消息。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

图14是本申请实施例提供的电子设备14的示意图。如图14所示，该实施例的电子设备14包括：处理器1401、存储器1402以及存储在该存储器1402中并且可在处理器1401上运行的计算机程序1403。处理器1401执行计算机程序1403时实现上述各个方法实施例中的步骤。或者，处理器1401执行计算机程序1403时实现上述各装置实施例中各模块/单元的功能。

电子设备14可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备14可以包括但不仅限于处理器1401和存储器1402。本领域技术人员可以理解，图14仅仅是电子设备14的示例，并不构成对电子设备14的限定，可以包括比图示更多或更少的部件，或者不同的部件。

处理器1401可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

存储器1402可以是电子设备14的内部存储单元，例如，电子设备14的硬盘或内存。存储器1402也可以是电子设备14的外部存储设备，例如，电子设备14上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(FlashCard)等。存储器1402还可以既包括电子设备14的内部存储单元也包括外部存储设备。存储器1402用于存储计算机程序以及电子设备所需的其它程序和数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种运营设计域建立方法，其特征在于，所述方法由车辆的车载单元执行，包括：

响应于所述车辆进入预设地理围栏，自云服务器或者第一路侧装置获取第一条件向量，所述第一条件向量用于指示所述地理围栏区域内的环境条件；

自所述第一路侧装置获取第二条件向量，所述第二条件向量用于指示所述第一路侧装置检测范围内的环境条件；

通过所述车辆的车载传感装置，获取第三条件向量，所述第三条件向量用于指示所述车辆检测范围内的环境条件；

根据所述第一条件向量、第二条件向量和第三条件向量，建立所述运营设计域。

2.根据权利要求1所述的方法，其特征在于，所述第一条件向量包括所述地理围栏区域内的法律法规条件、网络基础设施条件、路网条件和/或道路条件；

所述第二条件向量包括道路变化条件和/或气候条件；

第三条件向量包括车辆运行状态条件和/或车辆检测到的其他车辆与人员条件。

3.根据权利要求1所述的方法，其特征在于，所述根据所述第一条件向量、第二条件向量和第三条件向量，建立所述运营设计域，包括：

对所述第一条件向量、第二条件向量和第三条件向量进行卷积运算，得到所述运营设计域。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

自所述云服务器接收更新后的第一条件向量，其中，所述更新后的第一条件向量是在所述第一条件向量中的任意一项或者多项环境条件发生变化时，由云端服务器对所述第一条件向量进行更新后得到的；

基于所述更新后的第一条件向量、第二条件向量和第三条件向量，建立所述运营设计域。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

响应于所述车载单元与所述第一路侧装置断开连接，并与第二路侧装置建立连接，且所述第二路侧单元中不包括所述更新后的第一条件向量，自所述第二路侧装置获取更新后的第二条件向量，所述更新后的第二条件向量用于指示所述第二路侧装置检测范围内的环境条件；

根据所述第一条件向量、更新后的第二条件向量和第三条件向量，建立所述运营设计域；或者

响应于所述车载单元与所述第一路侧装置断开连接，并与第二路侧装置建立连接，且所述第二路侧单元中包括所述更新后的第一条件向量，自所述第二路侧装置获取所述更新后的第一条件向量和更新后的第二条件向量，所述更新后的第二条件向量用于指示所述第二路侧装置检测范围内的环境条件；

根据所述更新后的第一条件向量、更新后的第二条件向量和第三条件向量，建立所述运营设计域。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

周期性更新所述第三条件向量；

根据所述第一条件向量或者更新后的第一条件向量，第二条件向量或者更新后的第二条件向量，以及更新后的所述第三条件向量，建立所述运营设计域。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取车辆行驶参数，响应于所述行驶参数不满足所述运营设计域要求，生成终止自动驾驶提示消息。

8.一种运营设计域建立装置，其特征在于，包括：

第一获取模块，被配置为响应于所述车辆进入预设地理围栏，自云服务器或者第一路侧装置获取第一条件向量，所述第一条件向量用于指示所述地理围栏区域内的环境条件；

第二获取模块，被配置为自所述第一路侧装置获取第二条件向量，所述第二条件向量用于指示所述第一路侧装置检测范围内的环境条件；

第三获取模块，被配置为通过所述车辆的车载传感装置，获取第三条件向量，所述第三条件向量用于指示所述车辆检测范围内的环境条件；

建立模块，被配置为根据所述第一条件向量、第二条件向量和第三条件向量，建立所述运营设计域。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并且可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述方法的步骤。