CN114553933B - 一种无人车的控制权限接管方法、装置及系统 - Google Patents

Abstract

本公开涉及自动驾驶技术领域，提供了一种无人车的控制权限接管方法、装置及系统。该方法包括：通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求；接收服务器返回的与期望接管车辆对应的权限加密数据；断开与服务器之间的第一通信链路，建立与期望接管车辆之间的第二通信链路；通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据；若验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。本公开不再依赖服务器获取无人车的控制权限，数据传输更加稳定、可靠，且相较于传统的遥控器近场驾驶控制方案，功能更加丰富多样化，不需要额外的设备支持，控制成本相对较低。

Description

一种无人车的控制权限接管方法、装置及系统

技术领域

本公开涉及自动驾驶技术领域，尤其涉及一种无人车的控制权限接管方法、装置及系统。

背景技术

随着科学技术的迅速发展，无人驾驶智能车在民用、军事和科学领域的诸多方面得到了广泛的应用。

现有技术中，一般都是通过远程驾驶舱（如手机端、PC端（个人电脑端）等）来实时跟踪无人驾驶智能车的自动驾驶动态，并在出现紧急状况的情况下，对无人驾驶智能车进行实时接管控制，避免发生意外，从而保障无人驾驶智能车的安全运行。

现有的通过远程驾驶舱接管无人驾驶智能车的车辆控制权限的方案中，整个接管控制过程均需要由服务器进行相关数据的转发，且需要保证车辆外网通讯正常（如网络设备正常、网络通信信号良好，传输延迟最高不超过400ms）。在一些极端情况下，例如，由于无人驾驶智能车的通信信号较差而无法实现远程驾驶舱的远程驾驶时，需要近场人员介入，使用遥控器操作或者重启/检查设备。但是，遥控器的功能有限，只能用于驾驶，并且遥控器需要额外的设备支持，成本较高。

可见，现有的近场驾驶控制方案，全程需要依赖服务器转发相关数据，对网络通信的要求较高，一旦传输延迟较高，则容易出现“失控”的情况，且所使用的遥控器功能较单一，需要额外的设备支持，控制成本较高。

发明内容

有鉴于此，本公开实施例提供了一种无人车的控制权限接管方法、装置及系统，以解决现有技术中的近场驾驶控制方案，全程需要依赖服务器转发相关数据，对网络通信的要求较高，一旦传输延迟较高，则容易出现“失控”的情况，且所使用的遥控器功能较单一，需要额外的设备支持，控制成本较高的问题。

本公开实施例的第一方面，提供了一种无人车的控制权限接管方法，包括：

通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆；

接收服务器通过第一通信链路返回的与期望接管车辆对应的权限加密数据；

断开与服务器之间的第一通信链路，建立与期望接管车辆之间的第二通信链路；

通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果；

若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。

本公开实施例的第二方面，提供了一种无人车的控制权限接管装置，包括：

数据获取模块，被配置为通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆；

数据接收模块，被配置为接收服务器通过第一通信链路返回的与期望接管车辆对应的权限加密数据；

链路建立模块，被配置为断开与服务器之间的第一通信链路，建立与期望接管车辆之间的第二通信链路；

请求发送模块，被配置为通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果；

权限接管模块，被配置为若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。

本公开实施例的第三方面，提供了一种无人车的控制权限接管系统，包括：

接管控制设备；

与接管控制设备通过第一通信链路连接的服务器；

与接管控制设备通过第二通信链路连接的期望接管车辆；

服务器与期望接管车辆通过第一通信链路连接；

接管控制设备包括上述的无人车的控制权限接管装置。

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

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

本公开实施例与现有技术相比，其有益效果至少包括：本公开实施例可应用于手机端、个人电脑端等，通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆；接收服务器通过第一通信链路返回的与期望接管车辆对应的权限加密数据；断开与服务器之间的第一通信链路，建立与期望接管车辆之间的第二通信链路；通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果；若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。也即，在获取到与期望接管车辆对应的权限加密数据后即断开了与服务器的通信的第一通信链路，并建立起与期望接管车辆之间的第二通信链路，之后的接管控制相关的数据均系通过第二通信链路获取得到，无需全程依赖服务器转发相关数据，数据传输更加稳定、可靠，有效地降低了因服务器传输延时较高而容易出现“失控”的现象，且替代了传统的遥控器接管控制方式，功能更加丰富多样化，不局限于驾驶操作，不需要额外的设备支持，控制成本相对较低，同时还能够更加直观、多角度地显示车辆状态等数据。

附图说明

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

图1是本公开实施例的一种应用场景的场景示意图；

图2是本公开实施例提供的一种无人车的控制权限接管方法的流程示意图；

图3是本公开实施例提供的无人车的控制权限接管方法中的一应用示例的时序图；

图4是本公开实施例提供的一种无人车的控制权限接管装置的结构示意图；

图5是本公开实施例提供的一种无人车的控制权限接管系统的结构示意图；

图6是本公开实施例提供的一种电子设备的结构示意图。

具体实施方式

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

下面将结合附图详细说明根据本公开实施例的一种无人车的控制权限接管方法、装置及系统。

图1是本公开实施例的一种应用场景的场景示意图。该应用场景可以包括车辆端101、控制接管端102、服务器103、局域网104、外网105、远程驾驶舱106。

车辆端101，是指无人驾驶智能车，包括车辆VCU（Vehicle Control Unit，电动汽车整车控制器）、装载在无人驾驶智能车上的控制芯片（如装载有各种无人车驾驶控制功能程序的Xavier芯片等）以及链路服务节点。无人驾驶智能车上还可设置有相机、激光雷达、定位装置（如组合导航）、惯性测量单元等部件等。

接管控制端102，可以是硬件，也可以是软件。当接管控制端102为硬件时，其可以是具有显示屏且支持与车辆端101、服务器103通信的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机、嵌入式终端和台式计算机等；当接管控制端102为软件时，其可以安装在如上的电子设备中。接管控制端102可以实现为多个软件或软件模块，也可以实现为单个软件或软件模块，本公开实施例对此不作限制。进一步地，接管控制端102上可以安装有各种应用，例如数据处理应用、即时通信工具、搜索类应用等。

服务器103，可以是提供各种服务的服务器，例如，对与其建立通信连接的接管控制端102发送的请求进行接收的后台服务器，该后台服务器可以对接管控制端102发送的请求进行接收和分析等处理，并生成处理结果。服务器103可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者还可以是一个云计算服务中心，本公开实施例对此不作限制。

需要说明的是，服务器103可以是硬件，也可以是软件。当服务器103为硬件时，其可以是为车辆端101、接管控制端102提供各种服务的各种电子设备。当服务器103为软件时，其可以是为车辆端101、接管控制端102提供各种服务的多个软件或软件模块，也可以是为车辆端101、接管控制端102提供各种服务的单个软件或软件模块，本公开实施例对此不作限制。

局域网104，可以是车载局域网，例如，CAN（Controller Area Network，控制器局域网络），也可以是车载以太网等。

外网105，通常是指广域网（WAN）。

远程驾驶舱106，可以是硬件，也可以是软件。当远程驾驶舱106为硬件时，其可以是具有显示屏且支持与服务器103通信的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机、嵌入式终端和台式计算机等；当远程驾驶舱106为软件时，其可以安装在如上的电子设备中。远程驾驶舱106可以实现为多个软件或软件模块，也可以实现为单个软件或软件模块，本公开实施例对此不作限制。进一步地，远程驾驶舱106上可以安装有各种应用，例如数据处理应用、即时通信工具、搜索类应用等。

在本公开实施例中，接管控制端102可以通过第一通信链路（如外网105）向服务器103发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆；接收服务器103通过第一通信链路返回的与期望接管车辆（即车辆端101）对应的权限加密数据；断开与服务器103之间的第一通信链路，建立与期望接管车辆之间的第二通信链路（如局域网104）；通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果；若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。上述整个接管控制流程无需全程依赖服务器转发相关数据，有效地降低了“失控”的现象，且替代了传统的遥控器近场驾驶控制模式，功能更加丰富多样化，不局限于驾驶操作，不需要额外的设备支持，控制成本相对较低，同时还能够更加直观、多角度地显示车辆状态等数据。

在远程驾驶模式下，无论期望接管车辆当前是否为接管状态，实时数据都会不断的发给服务器，周期为40ms发送一次，即一秒25次。CAN总线上底盘数据轮询间隔为40ms，所以采样数据视为实时数据。服务器为订阅了期望接管车辆的车辆数据的远程驾驶舱转发。

远程驾驶模式的工作流程大致如下：远程驾驶舱106将接管请求发送到服务器103时，服务器会判断车辆到服务器的数据链路是否正常，如果正常则转发接管请求到车辆端101，车辆端收到接管请求数据后，通过CAN报文指令尝试接管车辆。同时启动超时检测机制。无论当前是否接管成功，如果超时检测机制触发，都会立即驻车并退出远程驾驶模式，并反向通知到服务器车辆端主动退出接管，服务器端断开驾驶数据转发关系，并反向通知远程驾驶舱106。接管成功后，远程驾驶舱106发来驾驶数据将被发送到车辆VCU。远程驾驶舱106将退出接管请求发送给服务器103时，驾驶数据会立刻停止，服务器端断开驾驶数据转发关系，并转发退出接管请求到车辆端。车辆端收到退出接管请求，会立即驻车并退出远程驾驶模式。

需要说明的是，车辆端101、控制接管端102、服务器103、局域网104、外网105和远程驾驶舱106的具体类型、数量和组合可以根据应用场景的实际需求进行调整，本公开实施例对此不作限制。

图2是本公开实施例提供的一种无人车的控制权限接管方法的流程示意图。图2的无人车的控制权限接管方法可以由图1的控制接管端102执行。如图2所示，该无人车的控制权限接管方法包括：

步骤S201，通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆。

作为一示例，若无人驾驶车辆在自动驾驶的过程中出现紧急情况需要近距离驾驶、紧急制动、故障恢复、设备重启等紧急且无法通过自身车辆完成这些紧急控制任务，则可通过近场驾驶操作人员操控控制接管端102（如手机或者平板电脑等）通过第一通信链路（外网105）向服务器103发送获取无人车控制权限数据的获取请求，其中，该获取请求包括期望接管车辆。期望接管车辆，即系出现紧急情况需要控制接管端102做接管控制的车辆。无人车控制权限数据，包括但不限于期望接管车辆的标识信息（如车辆唯一标识编码）、车辆位置信息、待接管的驾驶控制任务（如紧急制动、紧急刹车等）等。

期望接管车辆上安装有远程监控系统，远程终端（如电脑、手机等电子设备）可以通过该远程监控系统实时监控期望接管车辆的驾驶运行状态，并在发现驾驶异常情况（如紧急避障、紧急刹车、故障恢复等）时，立刻通知距离期望接管车辆最近（或者同处于一个局域网范围内）的控制接管端102的操作员（例如，可以通过电话呼叫等方式通知操作员），以使操作员能够及时操作控制接管端102对出现驾驶异常的无人车辆进行接管控制，从而保障无人车辆的安全运行。

步骤S202，接收服务器通过第一通信链路返回的与期望接管车辆对应的权限加密数据。

在一实施例中，可以预先将无人驾驶车辆与其车辆控制权限进行一一对应存储，生成映射表。具体的，可以将无人驾驶车辆的唯一标识信息（如车辆底盘编号）与其车辆控制权限进行绑定存储在服务器中。其中，车辆控制权限包括但不限于近距离驾驶、紧急制动、紧急刹车、故障恢复、设备重启等。

权限加密数据，是通过对无人驾驶车辆的车辆控制权限数据进行加密后得到的加密数据。

当服务器接收到控制接管端102发送的获取无人车控制权限数据的获取请求时，可以根据上述映射表，从其内存中调取出与期望接管车辆对应的权限加密数据，再通过第一通信链路（外网）返回给控制接管端102。

步骤S203，断开与服务器之间的第一通信链路，建立与期望接管车辆之间的第二通信链路。

当控制接管端102在接收到服务器103返回的与期望接管车辆对应的权限加密数据之后，断开与服务器之间的第一通信链路，即切断与服务器之间的外网连接。与此同时，建立起与期望接管车辆之间的第二通信链路。

步骤S204，通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果。

控制接管端102可进一步通过第二通信链路（如车载局域网）向期望接管车辆发送控制权限接管请求，期望接管车辆在接收到该控制权限接管请求后，对其中的权限加密数据进行合法性验证，并将验证结果通过第二通信链路返回给控制接管端102。

步骤S205，若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。

期望接管车辆对从控制接管端102处接收到的权限加密数据进行验证，若验证结果为验证成功，则释放权限加密数据中所请求的车辆控制权限（如紧急刹车、紧急制动、设备重启、重新授时等），同时将验证结果通过第二通信链路返回给控制接管端102。控制接管端102在接收到期望接管车辆返回的验证结果后，即可接管控制期望接管车辆所释放的车辆控制权限，并对该期望接管车辆进行相应的驾驶控制，保障期望接管车辆的安全运行。

本公开实施例提供的技术方案，在获取到与期望接管车辆对应的权限加密数据后即断开了与服务器的通信的第一通信链路，并建立起与期望接管车辆之间的第二通信链路，之后的接管控制相关的数据均系通过第二通信链路获取得到，无需全程依赖服务器转发相关数据，数据传输更加稳定、可靠，有效地降低了“失控”的现象，且替代了传统的遥控器接管控制方式，功能更加丰富多样化，不局限于驾驶操作，不需要额外的设备支持，控制成本相对较低，同时还能够更加直观、多角度地显示车辆状态等数据。

在一些实施例中，上述权限加密数据由如下步骤得到：

期望接管车辆通过第一通信链路向服务器发送权限明文数据，权限明文数据包括期望接管车辆的车辆标识信息和由期望接管车辆随机生成的第一随机数；

服务器根据车辆标识信息和第一随机数，生成权限加密数据，并将权限加密数据、第一随机数和车辆标识信息进行对应存储，通过第一通信链路将权限加密数据返回给期望接管车辆；

期望接管车辆接收权限加密数据，将权限加密数据和第一随机数进行对应存储。

权限明数据，可包括用于验证期望接管车辆的车辆身份信息的车辆标识信息以及第一随机数，还还包括与其对应的车辆控制权限方面的相关权限配置数据，如，重启设备、紧急停车、故障自检信息、重新授时、实时车辆数据等。

车辆标识信息，可以是无人驾驶车辆的车辆底盘编号，每辆无人车的车辆底盘编号唯一。

第一随机数，可以是无人驾驶车辆随机生成的8位（bit）随机数。

服务器103在接收到期望接管车辆通过外网发送过来的权限明文数据时，可以通过AES算法（Advanced Encryption Standard，高级加密标准）对权限明文数据进行加密，得到权限加密数据。然后，再将权限加密数据通过外网返回给期望接管车辆。与此同时，将权限加密数据、第一随机数和车辆标识信息进行对应存储。例如，期望接管车辆的车辆标识信息为01，第一随机数为X，权限加密数据为S，那么可将其存储为[01,X,S]的数组。期望接管车辆在接收到服务器返回的权限加密数据S后，将权限加密数据S与第一随机数进行对应存储，例如，存储为[X,S]的数组。当然，也可以一并将其车辆标识信息也进行绑定存储，即存储为[01,X,S]的数组。

作为一示例，期望接管车辆可将上述权限加密数据内置于其控制芯片中。

在实际应用中，期望接管车辆可将其部分或全部的车辆控制权限均打包至权限明文数据，与其车辆标识信息和随机生成的第一随机数一并发送给服务器，经由服务器对这些数据进行加密，得到权限加密数据。

在一些实施例中，期望接管车辆通过第一通信链路向服务器发送权限明文数据，具体包括如下步骤：

期望接管车辆通过第一通信链路向服务器发送车辆身份认证请求，车辆身份认证请求包括期望接管车辆的车辆标识信息；

期望接管车辆若接收到服务器通过第一通信链路返回的车辆身份认证成功的响应信息，则随机生成第一随机数，并通过第一通信链路向服务器发送权限明文数据。

在实际应用中，期望接管车辆在向服务器发送权限明文数据之前，需要先进行车辆身份认证。具体的，无人车运营商（服务商）可以先将其旗下的所有无人驾驶车辆的车辆标识信息统一上传并保存在服务器中，以便于规范以及后期核实期望接管车辆的身份的合法性，避免其他非法设备截取或者破坏无人驾驶车辆的相关车辆数据，从而保障无人车自动驾驶的安全运行。

期望接管车辆可通过外网向服务器发送其车辆标识信息，服务器在接收到该车辆标识信息时，可通过遍历内置于其中的车辆标识信息列表来确认该车辆标识信息是否合法，即是否被记录在车辆标识信息列表中，并通过第一通信链路（外网）向期望接管车辆返回身份认证结果。期望接管车辆若接收到服务器通过第一通信链路返回的车辆身份认证成功的响应信息，则随机生成第一随机数，并通过第一通信链路向服务器发送权限明文数据。

在一些实施例中，在期望接管车辆接收权限加密数据，将权限加密数据和第一随机数进行对应存储之后，还包括：

期望接管车辆按照预设的更新步长，随机生成第二随机数，并将第二随机数和车辆标识信息通过第一通信链路发送给服务器；

服务器若成功接收到第二随机数和车辆标识信息，则根据车辆标识信息和第二随机数，生成更新权限加密数据，并使用更新权限加密数据覆盖权限加密数据，使用第二随机数覆盖第一随机数，通过第一通信链路向期望接管车辆返回更新权限加密数据；

期望接管车辆接收更新权限加密数据，并使用更新权限加密数据覆盖权限加密数据，使用第二随机数覆盖第一随机数。

预设的更新步长，即系更新随机数的间隔时长，该间隔时长可以根据实际情况灵活设置，例如，可以设置为2、3小时等，具体在此不做限制。

作为一示例，假设预设的更新步长为2小时，那么期望接管车辆在每间隔2小时，更新一次之前发送给服务器的随机数。示例性的，期望接管车辆在向服务器发送其车辆标识信息和第一随机数2小时后，重新随机生成第二随机数，并将该第二随机数和车辆标识信息通过第一通信链路发送给发送给服务器。服务器若成功接收到该第二随机数和车辆标识信息，则可使用AES算法对第二随机数和车辆标识信息进行加密，生成更新权限加密数据，并使用更新权限加密数据覆盖与该车辆标识信息对应的权限加密数据，使用第二随机数覆盖之前的第一随机数，再将更新权限加密数据通过第一通信链路返回给期望接管车辆。期望接管车辆在接收到更新权限加密数据后，对其之前存储的权限加密数据、第一随机数进行相应的覆盖。

本公开实施例提供的技术方案，通过期望接管车辆按照预设的更新步长更新前次发送给服务器的随机数，使得服务器在成功接收到新的随机数以及车辆标识信息后，使用新的随机数和车辆标识信息重新进行加密计算，得到更新权限加密数据，从而提高了无人车的控制权限数据的安全性。

在一实施例中，若服务器与期望接管车辆之间的网络信号状态较差，或者是断网的情况下，服务器则难以成功接收到期望接管车辆发送的第二随机数和车辆标识信息。此时，仍可沿用之前的权限加密数据。

在一些实施例中，在期望接管车辆按照预设的更新步长，随机生成第二随机数，并将第二随机数和车辆标识信息通过第一通信链路发送给服务器之后，还包括：

若接收到服务器返回的更新失败的消息，则以接收到更新失败的消息为计时起算点，从计时起算点开始计时，在计时累计达到第一预设时长后，持续通过第一通信链路向服务器发送第二随机数和车辆标识信息，直至达到第二预设时长。

第一预设时长，可以根据实际情况灵活设置，通常设置为1分钟。

第二预设时长，可以根据实际情况灵活设置，例如，可以设置为5分钟、10分钟等。

作为一示例，若期望接管车辆在向服务器发送第二随机数和车辆标识信息后，超过预设的响应时长（如超过20秒等）都没有接收到服务器返回的更新权限加密数据，则视为接收到服务器返回的更新失败的消息，或者接收到服务器返回的更新失败的响应消息，则在接收到服务器返回的更新失败的消息开始计时，在计时累计达到第一预设时长（假设为1分钟）后，持续通过第一通信链路（外网）向服务器发送第二随机数和车辆标识信息，直至达到第二预设时长，停止本轮次的随机数更新操作。等到下一次的更新步长时，再继续向服务器发送第二随机数（或者是新生成的随机数）和车辆标识信息。若随机数更新操作一直没有成功，则可将第一随机数记录在本地，这样即使重新启动期望接管车辆，仍可延续使用第一随机数。

在一些实施例中，期望接管车辆对权限加密数据进行验证，并返回验证结果，包括：

对权限加密数据进行解密，得到解密数据，解密数据包括解密随机数；

若解密随机数与第一随机数一致，则通过第一通信链路向服务器发送随机数覆盖请求，随机数覆盖请求包括覆盖随机数，以使服务器根据接收到的覆盖随机数覆盖与第一随机数，并返回认证成功的验证结果。

覆盖随机数，可以是期望接管车辆随机生成的与第一随机数、第二随机数不重复的随机数。

当期望接管车辆接收到接管控制端通过第二通信链路发送过来的权限加密数据时，可按照前述的加密过程的逆向过程对该权限加密数据进行解密，得到解密数据。解密数据包括解密随机数和车辆标识信息。若解密随机数与第一随机数一致，则对接管控制端的身份认证成功。此时，可进一步通过第一通信链路（外网）向服务器发送随机数覆盖请求，以请求服务器将与其车辆标识信息对应的第一随机数进行覆盖，例如，将第一随机数替换为覆盖随机数。

在一实施例中，期望接管车辆向服务器发送随机数覆盖请求的过程，需要期望接管车辆和服务器两端同时进入预备销毁状态。若期望接管车辆向服务器连续三次向服务器发送随机数覆盖请求，均没有接收到服务器反馈的销毁成功（覆盖成功）的响应消息，则确认随机数销毁失败，则继续使用销毁前的随机数，并且通过第二通信链路向接管控制端返回认证成功的验证结果。

本公开实施例中，在期望接管车辆通过了对接管控制端的身份认证时，可向服务器发送随机数覆盖请求，以覆盖当前所使用的随机数，以防止除了该接管控制端之外的其他设备通过某种渠道获取到与期望接管车辆的车辆标识信息对应的权限加密数据，并认证成功，从而使得一辆期望接管车辆出现至少两辆认证成功的接管控制端，导致后续的车辆控制权限接管混乱，进而影响无人驾驶车辆的安全运行。若是一些非法设备通过非法途径（如黑客）获取到与期望接管车辆的车辆标识信息对应的权限加密数据，并认证成功，那么就很可能会直接威胁到无人驾驶车辆的车辆数据安全和运行安全。

在一些实施例中，上述步骤S203包括：

通过第一通信链路向服务器发送获取隐藏通信通道信息的请求；

在接收到服务器通过第一通信链路返回的隐藏通信通道信息时，断开与服务器之间的第一通信链路；

使用隐藏通信通道信息，建立与期望接管车辆之间的第二通信链路。

隐藏通信通道信息，是指局域网范围内的所有WiFi信息，包括多个路由设备或者车载设备发射的WiFi名称和密码。

接管控制端在接收到服务器通过第一通信链路返回的隐藏通信通道信息时，断开与服务器之间的第一通信链路，然后使用无线网络ID和密码连接到局域网，从而建立起与期望接管车辆之间的第二通信链路。

在一些实施例中，使用隐藏通信通道信息，建立与期望接管车辆之间的第二通信链路，包括：

从隐藏通信通道信息中筛选出与期望接管车辆对应的车载通信通道信息；

将与车载通信通道信息对应的网络连接通道设置为最高连接优先级；

自动切换至最高连接优先级对应的网络连接通道，建立起与期望接管车辆之间的第二通信链路。

为了防止接管控制端切换到其他WiFi（例如，其他终端设备或者路由设备的WiFi），可以预先将车辆WiFi设置为最优优先级，但是即使是将车辆WiFi设置到最高连接优先级，接管控制端仍可能会连接到其他无人车的车载WiFi。本公开为解决该技术问题，通过接管控制端先从服务器获取到的隐藏通信通道信息中筛选出与期望接管车辆对应的车载通信通道信息，即期望接管车辆的WiFi名称和密码。然后，将与车载通信通道信息对应的网络连接通道的优先级设置为最高；再自动切换至该最高连接优先级对应的网络连接通道，即切换至期望接管车辆的车辆WiFi，从而建立起与期望接管车辆之间的第二通信链路，使得接管控制端能够准确地连接到期望接管车辆的车辆WiFi，提高了与期望接管车辆之间的网络通信稳定性和针对性。

在实际应用中，还可以通过集群路由节点，生成路由表，路由表中记录局域网中的所有车载WiFi的名称和密码。接管控制端在向服务器发送的获取隐藏通信通道信息的请求时，可以同时将期望接管车辆的车辆标识信息一并发送给服务器，此时服务器可以经由集群路由实时将期望接管车辆的车载WiFi的名称和密码转发给接管控制端。

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

图3是本公开实施例提供的无人车的控制权限接管方法中的一种应用示例的时序图。如图3所示，该应用示例包括如下步骤：

步骤S301，车辆端101（期望接管车辆），创建与服务器103之间的第一通信链路（外网），并通过第一通信链路向服务器103发送身份认证信息（如车辆标识信息）。

步骤S302，服务器103，接收车辆端101发送的身份认证信息，并对该身份认证信息进行认证，并将认证结果通过第一通信链路返回给车辆端101。

步骤S303，车辆端101，在接收到服务器103返回的认证结果，并且确认该认证结果为认证成功时，随机生成8位的第一随机数并进行本地保存，并将第一随机数和车辆标识信息（如车辆底盘编号）通过第一通信链路发送给服务器103。

步骤S304，服务器103，在接收到车辆端101发送的第一随机数和车辆标识信息时，根据ASE算法对第一随机数和车辆标识信息进行加密，得到权限加密数据，并将权限加密数据、车辆标识信息和第一随机数进行对应存储，并将权限加密数据返回给车辆端101。

步骤S305，接管控制端102（如手机），获取拥有接管权限的无人车列表，并创建与服务器103之间的第一通信链路，从无人车列表中选定期望接管车辆，以及选择相应的接管控制模式（如近场驾驶控制模式或者远程驾驶控制模式），进入选定的接管控制模式对应的车辆接管界面（如近场驾驶模式的车辆接管界面），通过第一通信链路向服务器103发送获取无人车控制权限数据的获取请求，该获取请求包括期望接管车辆。

步骤S306，服务器103，响应接管控制端102的获取请求，并通过第一通信链路返回与期望接管车辆对应的权限加密数据。

步骤S307，接管控制端102，在接收到服务器103返回的权限加密数据时，断开与服务器103之间的第一通信链路，并切换网络连接至车载局域网（期望接管车辆的车辆WiFi），并向车辆端101的链路服务节点发送连接请求，当车辆端101的链路服务节点响应接管控制端102的连接请求，则建立起与期望接管车辆之间的第二通信链路。其中，链路服务节点除了可以完成驾驶数据的转发外，还可向外提供紧急动作的接口。

步骤S308，接管控制端102，通过第二通信链路向车辆端101发送权限加密数据和本地设备信息（如设备名称、设备编码等信息）。

步骤S309，车辆端101，接收接管控制端102通过第二通信链路发送的权限加密数据，并对该权限加密数据进行解密，得到解密数据，然后，判断该解密数据中的解密随机数是否与第一随机数一致；若一致，则向服务器103发送销毁第一随机数的请求（即覆盖随机数请求），该请求包括覆盖随机数。

步骤S310，服务器103，若成功接收到车辆端101发送的销毁第一随机数的请求，同时与车辆端进入预备销毁状态，并使用覆盖随机数覆盖第一随机数；无论是否销毁成功，均通过第一通信网络向车辆端101返回认证成功的响应消息；

步骤S311，车辆端101，在接收到服务器103返回的认证成功的响应消息时，释放接管控制端102所请求的车辆控制权限，此时，车辆端101即成功接管期望接管车辆的车辆控制权限，可实施对期望接管车辆的驾驶控制。

本公开实施例中，车辆端、服务器和接管控制端在离线的情况下也可以完成多端的互相认证过程，降低了在接管控制过程中对网络状态的依赖性，可有效避免接管过程因网络状态差而出现“失控”的现象。

车辆端101记录本次近场接管记录，并提交至服务器进行记录保存。

当接管控制端退出对期望接管车辆的控制后，将本次近场退出接管记录提交给服务器进行记录保存。

在应用本公开方法之前，需要保证接管控制端的外网连接正常，除了近场驾驶的要求，手机端其他功能也需要联网，并且车辆端曾经至少一次成功连接过服务器。

在一实施例中，在上述步骤中，接管控制端102进入车辆接管界面后，可向服务器发送获取车辆隐藏局域网WiFi的ID和密码，若获取失败，则退出车辆接管界面；若获取成功，则进一步向服务器103发送获取期望接管车辆的权限加密数据的请求。若没有接收到服务器返回的权限加密数据，则退出车辆接管界面。若接收到服务器返回的权限加密数据，则将权限加密数据进行保存，并销毁与服务器之间的第一通信链路。接着，若失败切换至WiFi连接到局域网（第二通信链路），则退出车辆接管界面；若成功切换至WiFi连接到局域网，则向车辆端的链路服务节点发送连接请求。若没有与链路服务节点连接成功，则退出车辆接管界面；若成功与链路服务节点连接，则通过第二通信链路向车辆端101提交权限加密数据和本地设备信息进行验证。若认证失败，则退出车辆接管界面；若认证成功，则成功接管车辆端101释放的车辆控制权限。

本公开实施例提供的技术方案，除了可以实现近场驾驶控制外，还可以拥有现场处置的能力，灵活性好；并且，可以打断传统的远程驾驶的控制操作，迅速完成抢占，使得车辆接管控制更加及时、可靠，可更有效地保障无人驾驶车辆的运行安全；同时可支持重启设备、紧急停车、故障自检信息、重新授时、实时车辆数据可视化的功能，功能多样化。

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

图4是本公开实施例提供的一种无人车的控制权限接管装置的示意图。如图4所示，该无人车的控制权限接管装置包括：

数据获取模块401，被配置为通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆；

数据接收模块402，被配置为接收服务器通过第一通信链路返回的与期望接管车辆对应的权限加密数据；

链路建立模块403，被配置为断开与服务器之间的第一通信链路，建立与期望接管车辆之间的第二通信链路；

请求发送模块404，被配置为通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果；

权限接管模块405，被配置为若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。

本公开实施例提供的技术方案，数据获取模块401通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆；数据接收模块402接收服务器通过第一通信链路返回的与期望接管车辆对应的权限加密数据；链路建立模块403断开与服务器之间的第一通信链路，建立与期望接管车辆之间的第二通信链路；请求发送模块404通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果；权限接管模块405若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。也即，在获取到与期望接管车辆对应的权限加密数据后即断开了与服务器的通信的第一通信链路，并建立起与期望接管车辆之间的第二通信链路，之后的接管控制相关的数据均系通过第二通信链路获取得到，无需全程依赖服务器转发相关数据，数据传输更加稳定、可靠，有效地降低了因服务器传输延时较高而容易出现“失控”的现象，且替代了传统的遥控器接管控制方式，功能更加丰富多样化，不局限于驾驶操作，不需要额外的设备支持，控制成本相对较低，同时还能够更加直观、多角度地显示车辆状态等数据。

在一些实施例中，权限加密数据由如下步骤得到：

期望接管车辆通过第一通信链路向服务器发送权限明文数据，权限明文数据包括期望接管车辆的车辆标识信息和由期望接管车辆随机生成的第一随机数；

服务器根据车辆标识信息和第一随机数，生成权限加密数据，并将权限加密数据、第一随机数和车辆标识信息进行对应存储，通过第一通信链路将权限加密数据返回给期望接管车辆；

期望接管车辆接收权限加密数据，将权限加密数据和第一随机数进行对应存储。

在一些实施例中，期望接管车辆通过第一通信链路向服务器发送权限明文数据，包括：

期望接管车辆通过第一通信链路向服务器发送车辆身份认证请求，车辆身份认证请求包括期望接管车辆的车辆标识信息；

期望接管车辆若接收到服务器通过第一通信链路返回的车辆身份认证成功的响应信息，则随机生成第一随机数，并通过第一通信链路向服务器发送权限明文数据。

在一些实施例中，期望接管车辆接收权限加密数据，将权限加密数据和第一随机数进行对应存储之后，还包括：

期望接管车辆按照预设的更新步长，随机生成第二随机数，并将第二随机数和车辆标识信息通过第一通信链路发送给服务器；

服务器若成功接收到第二随机数和车辆标识信息，则根据车辆标识信息和第二随机数，生成更新权限加密数据，并使用更新权限加密数据覆盖权限加密数据，使用第二随机数覆盖第一随机数，通过第一通信链路向期望接管车辆返回更新权限加密数据；

期望接管车辆接收更新权限加密数据，并使用更新权限加密数据覆盖权限加密数据，使用第二随机数覆盖第一随机数。

在一些实施例中，上述期望接管车辆按照预设的更新步长，随机生成第二随机数，并将第二随机数和车辆标识信息通过第一通信链路发送给服务器之后，还包括：

若接收到服务器返回的更新失败的消息，则以接收到更新失败的消息为计时起算点，从计时起算点开始计时，在计时累计达到第一预设时长后，持续通过第一通信链路向服务器发送第二随机数和车辆标识信息，直至达到第二预设时长。

在一些实施例中，链路建立模块403包括：

请求发送单元，被配置为通过第一通信链路向服务器发送获取隐藏通信通道信息的请求；

断开单元，被配置为在接收到服务器通过第一通信链路返回的隐藏通信通道信息时，断开与服务器之间的第一通信链路；

建立单元，被配置为使用隐藏通信通道信息，建立与期望接管车辆之间的第二通信链路。

在一些实施例中，建立单元，可被具体配置为：

从隐藏通信通道信息中筛选出与期望接管车辆对应的车载通信通道信息；

将与车载通信通道信息对应的网络连接通道设置为最高连接优先级；

自动切换至最高连接优先级对应的网络连接通道，建立起与期望接管车辆之间的第二通信链路。

在一些实施例中，期望接管车辆对权限加密数据进行验证，并返回验证结果，包括：

对权限加密数据进行解密，得到解密数据，解密数据包括解密随机数；

若解密随机数与第一随机数一致，则通过第一通信链路向服务器发送随机数覆盖请求，随机数覆盖请求包括覆盖随机数，以使服务器根据接收到的覆盖随机数覆盖与第一随机数，并返回认证成功的验证结果。

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

图5是本公开实施例提供的一种无人车的控制权限接管系统的结构示意图。如图5所示，该无人车的控制权限接管系统包括：接管控制设备501；与所述接管控制设备501通过第一通信链路连接的服务器103；与所述接管控制设备501通过第二通信链路连接的期望接管车辆502；所述服务器103与所述期望接管车辆502通过第一通信链路连接；所述接管控制设备501包括如图4所示的无人车的控制权限接管装置。

接管控制设备501（即上述的接管控制端102）可以通过第一通信链路（如外网105）向服务器103发送获取无人车控制权限数据的获取请求，获取请求包括期望接管车辆；接收服务器103通过第一通信链路返回的与期望接管车辆（即车辆端101）对应的权限加密数据；断开与服务器103之间的第一通信链路，建立与期望接管车辆之间的第二通信链路（如局域网104）；通过第二通信链路向期望接管车辆发送控制权限接管请求，控制权限接管请求至少包括权限加密数据，以使期望接管车辆对权限加密数据进行验证，并返回验证结果；若接收到期望接管车辆通过第二通信链路返回的验证结果为验证成功，则接管期望接管车辆释放的车辆控制权限。上述整个接管控制流程无需全程依赖服务器转发相关数据，并且在离线状态下仍可完成车辆端、服务器和接管控制端之间的信息认证流程，有效地降低了“失控”的现象，且替代了传统的遥控器近场驾驶控制模式，功能更加丰富多样化，不局限于驾驶操作，不需要额外的设备支持，控制成本相对较低，同时还能够更加直观、多角度地显示车辆状态等数据。

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

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

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

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

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

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

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

Claims (10)

1.一种无人车的控制权限接管方法，其特征在于，包括：

控制接管端通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，所述获取请求包括期望接管车辆，所述控制接管端位于所述期望接管车辆的近场；

接收所述服务器通过所述第一通信链路返回的与所述期望接管车辆对应的权限加密数据，所述权限加密数据，包括通过对所述期望接管车辆的车辆控制数据进行加密后得到的加密数据，所述车辆控制数据包括车辆标识信息和待接管的驾驶控制任务；

断开与所述服务器之间的第一通信链路，建立与所述期望接管车辆之间的第二通信链路；

通过所述第二通信链路向所述期望接管车辆发送控制权限接管请求，所述控制权限接管请求至少包括所述权限加密数据，以使所述期望接管车辆对所述权限加密数据进行验证，并返回验证结果；

若接收到所述期望接管车辆通过所述第二通信链路返回的验证结果为验证成功，则接管所述期望接管车辆释放的车辆控制权限。

2.根据权利要求1所述的方法，其特征在于，所述权限加密数据由如下步骤得到：

所述期望接管车辆通过所述第一通信链路向所述服务器发送权限明文数据，所述权限明文数据包括所述期望接管车辆的车辆标识信息和由所述期望接管车辆随机生成的第一随机数；

所述服务器根据所述车辆标识信息和第一随机数，生成权限加密数据，并将所述权限加密数据、第一随机数和车辆标识信息进行对应存储，通过所述第一通信链路将所述权限加密数据返回给所述期望接管车辆；

所述期望接管车辆接收所述权限加密数据，将所述权限加密数据和第一随机数进行对应存储。

3.根据权利要求2所述的方法，其特征在于，所述期望接管车辆通过所述第一通信链路向所述服务器发送权限明文数据，包括：

所述期望接管车辆通过所述第一通信链路向所述服务器发送车辆身份认证请求，所述车辆身份认证请求包括所述期望接管车辆的车辆标识信息；

所述期望接管车辆若接收到所述服务器通过所述第一通信链路返回的车辆身份认证成功的响应信息，则随机生成第一随机数，并通过所述第一通信链路向所述服务器发送权限明文数据。

4.根据权利要求2所述的方法，其特征在于，所述期望接管车辆接收所述权限加密数据，将所述权限加密数据和第一随机数进行对应存储之后，还包括：

所述期望接管车辆按照预设的更新步长，随机生成第二随机数，并将所述第二随机数和所述车辆标识信息通过所述第一通信链路发送给所述服务器；

所述服务器若成功接收到所述第二随机数和所述车辆标识信息，则根据所述车辆标识信息和第二随机数，生成更新权限加密数据，并使用所述更新权限加密数据覆盖所述权限加密数据，使用所述第二随机数覆盖所述第一随机数，通过所述第一通信链路向所述期望接管车辆返回所述更新权限加密数据；

所述期望接管车辆接收所述更新权限加密数据，并使用所述更新权限加密数据覆盖所述权限加密数据，使用所述第二随机数覆盖所述第一随机数。

5.根据权利要求4所述的方法，其特征在于，所述期望接管车辆按照预设的更新步长，随机生成第二随机数，并将所述第二随机数和所述车辆标识信息通过所述第一通信链路发送给所述服务器之后，还包括：

若接收到所述服务器返回的更新失败的消息，则以接收到所述更新失败的消息为计时起算点，从所述计时起算点开始计时，在计时累计达到第一预设时长后，持续通过所述第一通信链路向所述服务器发送所述第二随机数和所述车辆标识信息，直至达到第二预设时长。

6.根据权利要求1所述的方法，其特征在于，断开与所述服务器之间的第一通信链路，建立与所述期望接管车辆之间的第二通信链路，包括：

通过所述第一通信链路向所述服务器发送获取隐藏通信通道信息的请求；

在接收到所述服务器通过所述第一通信链路返回的隐藏通信通道信息时，断开与所述服务器之间的第一通信链路；

使用所述隐藏通信通道信息，建立与所述期望接管车辆之间的第二通信链路。

7.根据权利要求6所述的方法，其特征在于，使用所述隐藏通信通道信息，建立与所述期望接管车辆之间的第二通信链路，包括：

从所述隐藏通信通道信息中筛选出与所述期望接管车辆对应的车载通信通道信息；

将与所述车载通信通道信息对应的网络连接通道设置为最高连接优先级；

自动切换至所述最高连接优先级对应的网络连接通道，建立起与所述期望接管车辆之间的第二通信链路。

8.根据权利要求2所述的方法，其特征在于，所述期望接管车辆对所述权限加密数据进行验证，并返回验证结果，包括：

对所述权限加密数据进行解密，得到解密数据，所述解密数据包括解密随机数；

若所述解密随机数与所述第一随机数一致，则通过所述第一通信链路向所述服务器发送随机数覆盖请求，所述随机数覆盖请求包括覆盖随机数，以使所述服务器根据接收到的所述覆盖随机数覆盖与所述第一随机数，并返回认证成功的验证结果。

9.一种无人车的控制权限接管装置，其特征在于，包括：

数据获取模块，被配置为控制接管端通过第一通信链路向服务器发送获取无人车控制权限数据的获取请求，所述获取请求包括期望接管车辆，所述控制接管端位于所述期望接管车辆的近场；

数据接收模块，被配置为接收所述服务器通过所述第一通信链路返回的与所述期望接管车辆对应的权限加密数据，所述权限加密数据，包括通过对所述期望接管车辆的车辆控制数据进行加密后得到的加密数据，所述车辆控制数据包括车辆标识信息和待接管的驾驶控制任务；

链路建立模块，被配置为断开与所述服务器之间的第一通信链路，建立与所述期望接管车辆之间的第二通信链路；

请求发送模块，被配置为通过所述第二通信链路向所述期望接管车辆发送控制权限接管请求，所述控制权限接管请求至少包括所述权限加密数据，以使所述期望接管车辆对所述权限加密数据进行验证，并返回验证结果；

权限接管模块，被配置为若接收到所述期望接管车辆通过所述第二通信链路返回的验证结果为验证成功，则接管所述期望接管车辆释放的车辆控制权限。

10.一种无人车的控制权限接管系统，其特征在于，包括：

接管控制设备；

与所述接管控制设备通过第一通信链路连接的服务器；

与所述接管控制设备通过第二通信链路连接的期望接管车辆；

所述服务器与所述期望接管车辆通过第一通信链路连接；

所述接管控制设备包括如权利要求9所述的无人车的控制权限接管装置。

Images