远程控制请求处理方法、相关装置、云端服务器与流程

1.本公开涉及数据处理技术领域，具体涉及自动驾驶、远程驾驶、智能交通等技术领域，尤其涉及一种远程控制请求处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品、云端服务器、自动驾驶车辆、云端驾驶舱。


背景技术：

2.随着自动驾驶技术的发展，已经陆续开发出可用于无人或有人驾驶车辆的辅助自动驾驶技术，但当前的辅助自动驾驶技术往往还难以应对复杂的交通情况，因此发展出了通过远程控制该车辆的远程驾驶技术。
3.如何兼顾远程驾驶技术应用下可能面临的各种场景、要求，提供更好的远程控制服务，是本领域技术人员亟待解决的问题。


技术实现要素：

4.本公开实施例提出了一种远程控制请求处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品。
5.第一方面，本公开实施例提出了一种远程控制请求处理方法，包括：根据接收到的远程控制请求确定发起请求的目标车辆；响应于目标车辆关联有重点保障标识，确定与重点保障标识对应的指定远程驾驶舱；其中，目标车辆与重点保障标识之间的关联关系基于目标车辆的出行计划和/或实际安保等级确定；向指定远程驾驶舱下发第一远程控制指令；其中，第一远程控制指令用于指示指定远程驾驶舱远程控制目标车辆。
6.第二方面，本公开实施例提出了一种远程控制请求处理装置，包括：远程控制请求接收单元，被配置成根据接收到的远程控制请求确定发起请求的目标车辆；指定远程驾驶舱确定单元，被配置成响应于目标车辆关联有重点保障标识，确定与重点保障标识对应的指定远程驾驶舱；其中，目标车辆与重点保障标识之间的关联关系基于目标车辆的出行计划和/或实际安保等级确定；第一远程控制指令下发单元，被配置成向指定远程驾驶舱下发第一远程控制指令；其中，第一远程控制指令用于指示指定远程驾驶舱远程控制目标车辆。
7.第三方面，本公开实施例提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现如第一方面中任一实现方式描述的远程控制请求处理方法。
8.第四方面，本公开实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行时能够实现如第一方面中任一实现方式描述的远程控制请求处理方法。
9.第五方面，本公开实施例提供了一种包括计算机程序的计算机程序产品，该计算机程序在被处理器执行时能够实现如第一方面中任一实现方式描述的远程控制请求处理方法。
10.第六方面，本公开实施例提供了一种云端服务器，包括如第三方面描述的电子设备。
11.第七方面，本公开实施例提供了一种自动驾驶车辆，包括：
12.向云端服务器发起远程控制请求；其中，云端服务器为第六方面描述的云端服务器；
13.接收响应于云端服务器下发的第一远程控制指令的指定远程驾驶舱发来的远程控制参数；其中，第一远程控制指令在云端服务器确认发起远程控制请求的自动驾驶车辆关联有重点保障标识时、向与重点保障标识对应的云端驾驶舱下发。
14.第八方面，本公开实施例提供的一种云端驾驶舱，包括：
15.接收云端服务器下发的第一远程控制指令；其中，第一远程控制指令在云端服务器确认发起远程控制请求的自动驾驶车辆关联有重点保障标识时、向与重点保障标识对应的云端驾驶舱下发，云端服务器为第六方面描述的云端服务器、自动驾驶车辆为第七方面描述的自动驾驶车辆；
16.根据第一远程控制指令向自动驾驶车辆下发远程控制参数。
17.本公开实施例提供的远程控制请求处理方法，包括：根据接收到的远程控制请求确定发起请求的目标车辆；响应于目标车辆关联有重点保障标识，确定与重点保障标识对应的指定远程驾驶舱；其中，目标车辆与重点保障标识之间的关联关系基于目标车辆的出行计划和/或实际安保等级确定；向指定远程驾驶舱下发第一远程控制指令；其中，第一远程控制指令用于指示指定远程驾驶舱远程控制目标车辆。
18.相比于各远程驾驶舱基于自动接单的方式来处理各远程控制请求的现有处理方式，本公开基于车辆的出行计划和/或实际安保等级来确定是否要为其关联用于指定某些远程驾驶舱的重点保障标识，从而通过指定远程驾驶舱来为关联有该重点保障标识的车辆提供更全面、更有效的远程控制服务，同时也拓展了一种新的远程控制请求处理方式，可覆盖更多样的要求和场景。
19.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
20.通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：
21.图1是本公开可以应用于其中的示例性系统架构；
22.图2为本公开实施例提供的一种远程控制请求处理方法的流程图；
23.图3为本公开实施例提供的远程控制请求处理方法中一种基于出行计划为车辆关联重点保障标识的方法的流程图；
24.图4为本公开实施例提供的远程控制请求处理方法中一种基于实际安保等级为车辆关联重点保障标识的方法的流程图；
25.图5为本公开实施例提供的远程控制请求处理方法中一种基于包含的多模式控制标识提供其它控制模式的远程驾驶方法的流程图；
26.图6为本公开实施例提供的远程控制请求处理方法中一种主动式远程驾驶控制方
法的流程图；
27.图7为本公开实施例提供的一种结合实际应用给出的一种完整的远程控制请求处理时序图；
28.图8为本公开实施例提供的一种远程控制请求处理装置的结构框图；
29.图9为本公开实施例提供的一种适用于执行远程控制请求处理方法的电子设备的结构示意图。
具体实施方式
30.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。
31.本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
32.图1示出了可以应用本公开的远程控制请求处理方法、装置、电子设备及计算机可读存储介质的实施例的示例性系统架构100。
33.如图1所示，系统架构100可以包括支持远程控制功能的车辆101、102、103(其中车辆102预先基于出行计划和/或实际安保等级被关联有重点保障标识)，网络104和服务器105。网络104用以在车辆101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
34.车辆101、102、103通过网络104与服务器105交互，以接收或发送消息等，例如车辆101、102、103通过网络104向服务器105发送实时的车辆行驶状态、服务器105通过网络104向车辆101、102、103发送用于远程驾驶的控制指令等。车辆101、102、103和服务器105上可以安装有各种用于实现两者之间进行信息通讯的应用，例如自动驾驶辅助类应用、车况诊断类应用、远程驾驶类应用等。
35.车辆101、102、103和服务器105可以直接是硬件产物，也可以是软件模拟产物。当车辆101、102、103为硬件产物时，可以是具有用于支持实现远程控制服务的各式车辆；当车辆101、102、103为软件模拟产物时，可以实现成多个软件或软件模块运行后模拟出的虚拟产物，也可以实现成单个软件或软件模块，在此不做具体限定。当服务器105为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器；服务器为软件时，可以实现成多个软件或软件模块，也可以实现成单个软件或软件模块，在此不做具体限定。
36.服务器105通过内置的各种应用可以提供各种服务，以可以为支持远程控制服务的车辆提供远程控制请求处理服务的远程控制类应用为例，服务器105在运行该远程控制类应用时可实现如下效果：首先，通过网络104接收车辆101、102、103发起的远程控制请求；根据接收到的远程控制请求确定相应的车辆是否关联有重点保障标识，车辆与重点保障标识之间的关联关系基于该车辆的出行计划和/或实际安保等级确定；为关联有重点保障标识的车辆102确定与重点保障标识对应的指定远程驾驶舱(所有远程驾驶舱的一部分，未在图1中示出)；为未关联有重点保障标识的车辆101、103按照预设的分配方式分配给空闲的
远程驾驶舱，以使被分配有远程控制请求的远程驾驶舱通过远程控制的方式控制车辆101、102、103。
37.本公开后续各实施例所提供的远程控制请求处理方法一般由介于车辆和远程驾驶舱中间的服务器105来执行，相应地，远程控制请求处理装置一般也设置于服务器105中。
38.应该理解，图1中的车辆、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的车辆、网络和服务器。
39.请参考图2，图2为本公开实施例提供的一种远程控制请求处理方法的流程图，其中流程200包括以下步骤：
40.步骤201：根据接收到的远程控制请求确定发起请求的目标车辆；
41.本步骤旨在由远程控制请求处理方法的执行主体(例如图1所示的服务器105)在接收到某辆车发起的远程控制请求后，根据该远程控制请求将发起该请求的车辆确定为目标车辆。
42.其中，目标车辆可以是一辆无人驾驶的车辆，也可以是一辆有人驾驶的车辆，但该车辆支持自动驾驶和远程控制(驾驶)功能，自动驾驶功能是指在无驾驶员控制的情况下车辆控制中枢根据收集到的车况自行控制车辆行驶的能力，远程控制功能则是指该车辆可接收外部传入的远程控制指令，并通过执行远程控制指令来达成正常驾驶效果的能力。
43.根据目标车辆上是否有人、自动驾驶功能是否开启，可将远程控制请求的生成方式划分为以下几类，其一：目标车辆的驾驶员主动通过目标车辆发起该远程控制请求；其二：开启自动驾驶功能的目标车辆基于对车况的分析主动生成并发起该远程控制请求，即发起远程控制请求的原因主要是当前驾驶员或自动驾驶功能提供的驾驶能力无法满足当前场景的需求，因此需要外部的帮助，以提升安全性。
44.具体的，远程控制请求除整体使接收者将其识别为请求提供远程控制服务的信息外，通常还包含多个不同字段，不同的字段用于记录与目标车辆或之所以发起该远程控制请求的原因的不同信息，例如包含用于记录车辆识别编码的字段、用于记录车辆所在“组织(或预先确定有分组规则下的实际组别)”的字段、用于记录近期车况的字段、用于记录请求发起类型(由驾驶员主动发起还是由自动驾驶功能主动发起)的字段等等，出上述列举的一些字段外，还可以包括实际应用场景下所有可能因特殊影响因素或特殊要求存在的特殊字段，例如近期或当前的出行计划。
45.进一步的，为了提升从远程控制请求提取到特定字段或特定信息的效率，记录不同信息的字段还可以按照预设顺序或固定顺序进行排列，以使得基于此构成的远程控制请求可在后续直接使用预设的提取位置快速提取到想要的信息，而不用将所有字段的信息都提取出来再识别哪些是想要的。
46.步骤202：响应于目标车辆关联有重点保障标识，确定与重点保障标识对应的指定远程驾驶舱；
47.在步骤201的基础上，本步骤旨在由上述执行主体在根据远程控制请求确定目标车辆关联有重点保障标识的情况下，进一步的确定与该重点保障标识对应的指定远程驾驶舱。实际情况下，该关联关系通常建立在指代目标车辆的身份标识与重点保障标识之间，为简化描述，后续不再着重强调车辆的身份标识，直接使用目标车辆。
48.顾名思义，重点保障标识意味着需要对该车辆的驾驶安全进行重点保障，因此本
公开基于能够影响驾驶安全的目标车辆的出行计划和/或表征重要性等级的实际安保等级来确定是否应当为一辆车关联该重点保障标识。当然，可能除上述列举出的出行计划、实际安保等级之外还存在其它的能够表征是否应当为其关联重点保障标识的影响因素，这些其它的影响因素根据实际应用场景下的需求，也可以按照影响程度共同参与进是否应当为其关联该重点保障标识。
49.即本公开预先建立有重点保障标识与某些远程驾驶舱之间的绑定关系，即本步骤中将其称为指定远程驾驶舱，指定远程驾驶舱可以是从所有的普通远程驾驶舱中选择出的具备符合具体重点保障要求的能力的部分远程驾驶舱，也可以是区别于普通远程驾驶舱的另一些具备符合具体重点保障要求的能力的远程驾驶舱。
50.相反，若目标车辆未关联有重点保障标识，也就意味着其不需要被重点保障，因此可直接分配给普通的远程驾驶舱处理即可。
51.其中，在远程控制请求中包含有用于记录重点保障标识的专用字段的情况下，确定是否关联有重点保障标识可直接根据该专用字段中记录的内容来进行；在远程控制请求中未包含该专用字段的情况下，则可以根据从远程控制请求中提取出的目标车辆的识别码在上述执行主体维护的识别码
‑
重点保障标识对应表中进行查询确定，进一步的，该对应表也可以不直接由上述执行主体进行维护，仅需上述执行主体可以访问到即可。
52.步骤203：向指定远程驾驶舱下发第一远程控制指令。
53.在步骤202的基础上，本步骤旨在由上述执行主体向指定远程驾驶舱下发第一远程控制指令，该第一远程控制指令用于指示指定远程驾驶舱远程控制目标车辆，即通过向指定远程驾驶舱下发该控制指令的方式使得接收到该控制指令的指定远程驾驶舱为目标车辆提供远程控制服务。
54.具体的，指定远程驾驶舱通常需要根据该第一远程控制指令与该目标车辆建立控制连接，在控制连接建立后才能够由该指定远程驾驶舱将后续的、实际用于控制目标车辆的远程控制参数传达至目标车辆，使得目标车辆的控制中枢通过执行接收到的远程控制参数实现对车辆的控制。
55.相比于各远程驾驶舱基于自动接单的方式来处理各远程控制请求的现有处理方式，本公开实施例提供的远程控制请求处理方法，基于车辆的出行计划和/或实际安保等级来确定是否要为其关联用于指定某些远程驾驶舱的重点保障标识，从而通过指定远程驾驶舱来为关联有该重点保障标识的车辆提供更全面、更有效的远程控制服务，同时也拓展了一种新的远程控制请求处理方式，可覆盖更多样的要求和场景。
56.请参考图3，图3为本公开实施例提供的远程控制请求处理方法中一种基于出行计划为车辆关联重点保障标识的方法的流程图，其中流程300包括以下步骤：
57.步骤301：从远程控制请求中提取目标车辆的出行计划，或在预先上传的出行计划集合中查询匹配于目标车辆的出行计划；
58.即出行计划可以由目标车辆的驾驶员或乘客预先输入并同步至上述执行主体，也可以直接包含在发起的远程控制请求中。该出行计划中至少包括出行的目的地，以及到达目的地的至少一条路线，
59.步骤302：根据出行计划确定行经位置集合；
60.在步骤301的基础上，本步骤旨在根据到达目的地的路线确定路线中经过的各位
置，即该行经位置集合中至少一个按路线行驶经过的位置，不同的行经位置在集合中可以按照经过的时间顺序进行排列，以便于更好的结合时间差异对相应位置的危险程度的影响。
61.步骤303：响应于行经位置集合中存在超过预设数量的具有超过预设危险程度的行经位置，为目标车辆关联第一重点保障标识；
62.其中，预设数量可以根据行经位置集合中不同的行经位置的数量动态调整，以更好的结合出行规划的情况。
63.其中，危险程度基于地形复杂程度、车流密度、行驶缓慢程度中的至少一项确定，在结合多项影响因素来共同确定实际的危险程度的情况下，参与共同决策的多项影响因素可以按照与其影响程度对应的权值进行加权处理，以提升最终结论的准确性。
64.具体的，由于本实施例是基于出行计划中经过多个较为危险的位置而为其关联重点保障标识，因此该第一重点保障标识也表示与因行经危险位置对应的重点保障需求。
65.相反，若行经位置集合中不存在超过预设数量的具有超过预设危险程度的行经位置，则无需为目标车辆关联该第一重点保障标识，也就无需为其调配绑定的指定远程驾驶舱。
66.步骤304：将关联有高超驾驶能力标签的远程驾驶舱确定为与第一重点保障标识的指定远程驾驶舱。
67.其中，高超驾驶能力标签基于具有解决超过预设危险程度的行车危险的驾驶能力生成。不同远程驾驶舱可预先被评定过针对不同危险程度的危险的远程驾驶能力，以便于根据评估出的应对危险的远程驾驶能力来为其附加不同的能力标签，例如除高超驾驶能力标签之外，还可以存在普通驾驶能力标签。
68.请参考图4，图4为本公开实施例提供的远程控制请求处理方法中一种基于实际安保等级为车辆关联重点保障标识的方法的流程图，其中流程400包括以下步骤：
69.步骤401：根据预设的安保配备规则确定目标车辆的实际安保等级；
70.本步骤旨在由上述执行主体根据预先记录有不同车辆和不同安保等级之间的对应关系的安保配备规则，确定目标车辆对应的实际安保等级。其中，该安保配备规则通常被记录在上述执行主体中。
71.进一步的，也可以考虑时间因素对安保等级的影响，将确定出的实际安保等级具体到目标车辆在当前时段的实际安保等级，即不同车辆在不同时段将会对应有不同的安保等级，以对应该车辆的归属性质和因时间不同对行驶安全的影响。除因常规的时间因素影响，也可以根据该车辆是否需要参加某项重要的活动、其中乘坐的乘客的身份、数量等共同确定。
72.步骤402：响应于实际安保等级超过预设安保等级，为目标车辆关联第二重点保障标识；
73.在步骤401的基础上，本步骤旨在由上述执行主体在实际安保等级超过预设安保等级的情况下，为目标车辆关联第二重点保障标识。
74.进一步的，考虑到某些场景下目标车辆可能会在某些地区内经过，且该地区的路况或行车环境不佳，需要重点保障这段路程的远程控制安全性，就可以通过预估该段路程的耗时来为该第二重点保障标识设置一个预设时长，即该预设时长用于表征该第二重点保
障标识与目标车辆之间关联关系的保持时长，若实际时长超过该预设时长，也可以采用多种方式进行调整，例如下调一个级别的安保等级、调整重点保障标识的重点保障程度，甚至直接去除关联的重点保障标识。
75.预设时长的具体时间长度除可以与上面提及的预估通过危险路段的耗时外，还可以同时结合实际安保等级、周边存在活动的持续时间、当前行车环境下的平均行车速度、乘客数量、身份等等。
76.相反，如果实际安保等级未超过预设安保等级，也就无需为目标车辆关联该第二重点保障标识，也就无需为其调配绑定的指定远程驾驶舱。
77.步骤403：将附加有高安保等级标签的远程驾驶舱确定为与第二重点保障标识的指定远程驾驶舱。
78.其中，高安保等级标签基于能提供超过预设安保等级的安保能力生成。不同远程驾驶舱可预先被评定过能够提供何种程度的安保能力，此处所指的安保等级除包含必要的驾驶能力，还包括安全行车能力、安全警戒意识的察觉、敏感能力等，以便于根据评估出的安保能力来为其附加不同的能力标签，例如除高安保等级标签之外，还可以存在普通安保等级标签。
79.图3和图4分别从出行计划和实际安保等级两个方面，分别给出了一种具体的是否为相应车辆关联重点保障标识的实现方式，也可以在此指导思想下结合图3和图4给出的实现方式，组合得到同时结合出行计划和实际安保等级来判别是否应当关联重点保障标识的方案，以实现更细程度的区分，此处不再一一列举。
80.在上述任意实施例的基础上，为尽可能的提升为关联有重点保障标识的目标车辆提供的远程控制服务的可靠性，可为每辆关联有重点保障标识的目标车辆对应的指定远程驾驶舱的数量设置为多个(例如2个、3个甚至更多)，并进一步的控制至少有预设数量(例如设置为1个或2个)的指定远程驾驶舱处于接替准备状态，或控制处于接替准备状态的指定远程驾驶舱的数量占比不小于预设占比(例如1/3或30％)，以避免之前为目标车辆提供远程控制服务的某个指定远程驾驶舱因突发性或未知因素导致的控制中断问题出现，该接替准备状态指可在预设时长内将为目标车辆提供远程控制服务的指定远程驾驶舱更换为自身的状态。
81.在上述任意实施例针对重点保障标识来为相应车辆提供指定远程驾驶舱的方案的基础上，考虑到远程控制服务场景下的复杂性和多样性，本公开还分别通过图5和图6提供了区别于采用同步控制方式对目标车辆进行远程控制的普通远程驾驶舱、指定远程驾驶舱的目标远程驾驶舱，以通过该目标远程驾驶舱来满足某些车辆或某些场景下需要通过其它控制方式接入车辆进行远程控制的需求。
82.请参考图5，图5为本公开实施例提供的远程控制请求处理方法中一种基于包含的多模式控制标识提供其它控制模式的远程驾驶方法的流程图，其中流程500包括以下步骤：
83.步骤501：响应于远程控制请求中包含有多模式控制标识，将包含有多模式控制标识的远程控制请求发送至预设的第一目标远程驾驶舱；
84.其中，与多模式控制标识对应的多种控制模式包括：直接控制、间接控制和同步控制。即包含该多模式控制标识就意味着发出该远程控制请求的车辆支持除默认使用的同步控制外的其它控制方式，因此本步骤将包含此类标识的远程控制请求发送至预设的第一目
标远程驾驶舱，以借助拥有多控制模式处理能力的目标远程驾驶舱来更好的处理此类远程控制请求。
85.其中，间接控制模式是一种在远程驾驶舱接入该车辆进行远程控制之前，需要该车辆先处于静止状态的控制模式；直接控制模式则是一种不需要车辆先处于静止状态，直接将远程驾驶舱的控制指令传达至该车辆来执行的控制模式；同步控制模式是在直接控制模式基础上更新来的一种控制模式，区别于直接将远程驾驶舱的控制指令传达至该车辆，该模式下先收集该车辆的自动驾驶指令，以让远程驾驶舱适应、对接，然后在适应完成后再将自身的控制指令下发至该车辆。
86.步骤502：控制第一目标远程驾驶舱根据多模式控制标识，确定与目标车辆对应的第一目标控制模式；
87.在步骤501的基础上，本步骤旨在由上述执行主体控制第一目标远程驾驶舱根据多模式控制标识确定与目标车辆对应的第一目标控制模式，在多种控制模式中进行选择的方式可根据该辆车的实际情况或该第一目标远程驾驶舱的偏好进行，此处不做具体限定。
88.步骤503：向第一目标远程驾驶舱下发第二远程控制指令。
89.其中，第二远程控制指令用于指示第一目标远程驾驶舱按第一目标控制模式远程控制目标车辆。
90.区别于图5所提供的被动式控制方式，图6提供了一种主动式远程驾驶控制方法的流程图，其中流程600包括以下步骤：
91.步骤601：获取各自动驾驶车辆返回的自动驾驶数据；
92.步骤602：接收第二目标远程驾驶舱根据自动驾驶数据发起的主动远程控制请求；
93.本步骤旨在由上述执行主体接收第二目标远程驾驶舱根据自动驾驶数据发起的主动远程控制请求，即步骤601获取到的各车辆的自动驾驶数据将会呈现给第二目标远程驾驶舱，第二目标远程驾驶舱自己或交由其他分析设备对自动驾驶数据进行分析，并根据分析结果确定存在某些问题、需要通过远程驾驶来及时修正该问题、保障该车辆行车安全的车辆，并对该车辆发起主动远程控制请求。
94.当然，除因发现问题来试图修正的场景外，也可以在测试场景下结合测试需求来主动为某辆测试车辆发起主动远程控制请求。
95.步骤603：根据主动远程控制请求确定待控制车辆、待控制车辆支持的第二目标控制模式；
96.在步骤602的基础上，本步骤旨在由上述执行主体根据主动远程控制请求确定待控制车辆、待控制车辆支持的第二目标控制模式，以便于后续使第二目标远程控制舱通过其支持的控制模式来对其进行控制。
97.步骤604：响应于待控制车辆允许第二目标远程驾驶舱接入，向第二目标远程驾驶舱下发第三远程控制指令。
98.其中，第三远程控制指令用于指示第二目标远程驾驶舱按第二目标控制模式远程控制待控制车辆。
99.为加深理解，本公开还结合一个具体应用场景，给出了一种具体的实现方案，请参见如图7所示的时序图，图7为本公开实施例提供的一种结合实际应用给出的一种完整的远程控制请求处理时序图：
100.如图7所示，整体划分为三个阶段：调度阶段、处理阶段、归还阶段，涉及多个端，其中最左侧为车端(自动驾驶车辆，系统的任务发起者，也是需要服务的对象)、云调度端(channel，接受车端任务请求，执行调度，以及通过siam service任务调度信息互通、中间服务端(siam service，驾驶舱控制界面和调度服务的中间服务，负责展示任务信息，和收集代驾员对于任务调度的反馈)、驾驶舱端(user/seat)。
101.调度阶段的任务主要分为五种状态：
102.调度开始(schedule_start)、
103.调度请求中(schedule_request_phantom)、
104.调度接受(schedule_phantom_accept)、
105.调度拒绝(schedule_phantom_refuse)、
106.调度请求超时(schedule_phantom_timeout)、
107.以及，调度整体超时(schedule_timeout)，调度整体架构也是围绕这五种状态展开：
108.一、新工单请求
109.当有车辆需要远程介入时，该车辆发出工单请求；云调度端接受请求通知中间服务端创建工单，得到工单的id。此时调度流程处于上述五种状态中的：调度开始(schedule_start)。
110.二、调度启动：
111.启动调度流程：
112.1.创建任务请求超时计时，每个任务调度阶段不得超过35s调度时间；超时未结束修改状态调度整体超时(schedule_timeout)；
113.2.推送任务到调度队列中，并触发一次调度循环的一次执行：
114.其中，调度循环执行前会根据车辆上报的任务的紧急性进行排序；循环调度队列中每个任务，处于待分配状态的订单，调用资源分配算法参考下一步；处于已分配的调度中的任务循环忽略；处于结束态的任务修改其任务状态为失效。
115.3.调用资源分配：根据资源池范围和调度干扰策略选择对应驾驶舱，选择到对应的驾驶舱此刻状态：
116.调度中(schedule_request_phantom)，若没有匹配驾驶舱则依然处于：调度开始(schedule_start)的状态。
117.调度资源池：在系统中以组织的形式出现，系统管理员定义远程驾驶的组织，明确资源池中人、车、舱都是哪些；而这些资源和组织不是1对1的关系，一个资源(人/车/舱)可以属于多个组织；但是使用时候一个人只能占用一个舱，一个舱运行时能在一个组织当中。
118.当一辆车发出远程脱困请求的时候，非特殊化设置会在改车相关的所有组织中寻找驾驶舱。
119.4.处于调度请求中(schedule_request_phantom)的任务，匹配的驾驶舱用户端会询问代驾员是否接单，代驾员有三种选择，接受则任务状态更改为调度接受(schedule_phantom_accept)，拒绝则任务状态更改为调度拒绝(schedule_phantom_refuse)，或者不处理等待10s调度后任务状态更改为：
120.调度拒绝(schedule_phantom_timeout)。
121.5.若处于任务状态为调度请求超时(schedule_phantom_timeout)的状态，则会再次触发调度循环的一次执行到达步骤2，即更换下一个匹配的驾驶舱，继续询问下一个驾驶舱的代驾员是否接单，直至总体等待时长超过35s或有一个代驾员选择接受。
122.三、调度结束态：
123.三种结束态：调度接受、调度拒绝、调度整体超时；调度接受后任务流程到处理阶段，其他两种则直接结束任务，并提示车端自行处理。
124.上述内容对应图7中的上半部分，下半部分示出了对三种自动驾驶的处理流程，应当首先明确的是，原先发出远程控制请求的自动驾驶车辆之所以会触发自动驾驶，是因为远程控制服务已经提供完成或无法提供远程控制服务或车端要求主动解除，所以车端会再次恢复至原先的自动驾驶模式，case1所示的是一种因车端要求主动解除的情况，在此种情况下云调度端将触发结束流程，从而释放之前为该车辆占用的驾驶舱资源，并标记库状态为结束；case2所示的是一种已经提供远程控制服务的情况，在此情况下云调度端在确认车端成功进入自动驾驶，才会触发结束流程，以真正退出同步驾驶的方式保障车端后续自动驾驶的安全性；case3所示的是一种无法提供远程控制服务的情况，即驾驶舱端选择拒绝接单后，云调度端将提示车端自行处理，因此车辆将触发自动驾驶。
125.在上述图7所示的远程控制请求处理方案的基础上，本公开上述实施例分别给出的基于重点保障标识提供的指定远程控制舱的远程控制服务，和通过区别于普通远程驾驶舱和指定远程驾驶舱的目标远程驾驶舱来提供区别于同步控制模式的其它模式的远程控制服务，则可被划归在上述基础方案上的补充干扰策略。
126.另外，还可以基于负载均衡策略，在同类型的远程驾驶舱中基于接单量、接单代驾时间来尽量控制工作量相同。
127.进一步参考图8，作为对上述各图所示方法的实现，本公开提供了一种远程控制请求处理装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。
128.如图8所示，本实施例的远程控制请求处理装置800可以包括：远程控制请求接收单元801、指定远程驾驶舱确定单元802、第一远程控制指令下发单元803。其中，远程控制请求接收单元801，被配置成根据接收到的远程控制请求确定发起请求的目标车辆；指定远程驾驶舱确定单元802，被配置成响应于目标车辆关联有重点保障标识，确定与重点保障标识对应的指定远程驾驶舱；其中，目标车辆与重点保障标识之间的关联关系基于目标车辆的出行计划和/或实际安保等级确定；第一远程控制指令下发单元803，被配置成向指定远程驾驶舱下发第一远程控制指令；其中，第一远程控制指令用于指示指定远程驾驶舱远程控制目标车辆。
129.在本实施例中，远程控制请求处理装置800中：远程控制请求接收单元801、指定远程驾驶舱确定单元802、第一远程控制指令下发单元803的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201
‑
203的相关说明，在此不再赘述。
130.在本实施例的一些可选的实现方式中，远程控制请求处理装置800中还可以包括：
131.出行计划获取单元，被配置成从远程控制请求中提取目标车辆的出行计划，或在预先上传的出行计划集合中查询匹配于目标车辆的出行计划；
132.经行位置集合确定单元，被配置成根据出行计划确定行经位置集合；
133.第一重点保障标识关联单元，被配置成响应于行经位置集合中存在超过预设数量的具有超过预设危险程度的行经位置，为目标车辆关联第一重点保障标识；其中，危险程度基于地形复杂程度、车流密度、行驶缓慢程度中的至少一项确定；
134.对应的，指定远程驾驶舱确定单元被进一步配置成：
135.将附加有高超驾驶能力标签的远程驾驶舱确定为与第一重点保障标识的指定远程驾驶舱；其中，高超驾驶能力标签基于具有解决超过预设危险程度的行车危险的驾驶能力生成。
136.在本实施例的一些可选的实现方式中，远程控制请求处理装置800中还可以包括：
137.实际安保等级确定单元，被配置成根据预设的安保配备规则确定目标车辆的实际安保等级；其中，安保配备规则中记录有不同车辆和不同安保等级之间的对应关系；
138.第二重点保障标识关联单元，被配置成响应于实际安保等级超过预设安保等级，为目标车辆关联第二重点保障标识；
139.对应的，指定远程驾驶舱确定单元被进一步配置成：
140.将附加有高安保等级标签的远程驾驶舱确定为与第二重点保障标识的指定远程驾驶舱；其中，高安保等级标签基于能提供超过预设安保等级的安保能力生成。
141.在本实施例的一些可选的实现方式中，远程控制请求处理装置800中还可以包括：
142.冗余保护单元，被配置成响应于指定远程驾驶舱的数量为多个，控制至少有预设数量的指定远程驾驶舱处于接替准备状态，或控制处于接替准备状态的指定远程驾驶舱的数量占比不小于预设占比；其中，接替准备状态指可在预设时长内将为目标车辆提供远程控制服务的指定远程驾驶舱更换为自身的状态。
143.在本实施例的一些可选的实现方式中，远程控制请求处理装置800中还可以包括：
144.多控制控制标识处理单元，被配置成响应于远程控制请求中包含有多模式控制标识，将包含有多模式控制标识的远程控制请求发送至预设的第一目标远程驾驶舱；
145.第一目标控制模式确定单元，被配置成控制第一目标远程驾驶舱根据多模式控制标识，确定与目标车辆对应的第一目标控制模式；其中，与多模式控制标识对应的多种控制模式包括：直接控制、间接控制和同步控制；
146.第二远程控制指令下发单元，被配置成向第一目标远程驾驶舱下发第二远程控制指令；其中，第二远程控制指令用于指示第一目标远程驾驶舱按第一目标控制模式远程控制目标车辆。
147.在本实施例的一些可选的实现方式中，远程控制请求处理装置800中还可以包括：
148.自动驾驶数据获取单元，被配置成获取各自动驾驶车辆返回的自动驾驶数据；
149.主动远程控制请求接收单元，被配置成接收第二目标远程驾驶舱根据自动驾驶数据发起的主动远程控制请求；
150.待控制车辆及第二目标控制模式确定单元，被配置成根据主动远程控制请求确定待控制车辆、待控制车辆支持的第二目标控制模式；其中，控制模式包括：直接控制、间接控制和同步控制；
151.第三远程控制指令下发单元，被配置成响应于待控制车辆允许第二目标远程驾驶舱接入，向第二目标远程驾驶舱下发第三远程控制指令；其中，第三远程控制指令用于指示第二目标远程驾驶舱按第二目标控制模式远程控制待控制车辆。
152.本实施例作为对应于上述方法实施例的装置实施例存在，本实施例提供的远程控制请求处理装置，基于车辆的出行计划和/或实际安保等级来确定是否要为其关联用于指定某些远程驾驶舱的重点保障标识，从而通过指定远程驾驶舱来为关联有该重点保障标识的车辆提供更全面、更有效的远程控制服务，同时也拓展了一种新的远程控制请求处理方式，可覆盖更多样的要求和场景。
153.根据本公开的实施例，本公开还提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现上述任意实施例所描述的远程控制请求处理方法。
154.根据本公开的实施例，本公开还提供了一种可读存储介质，该可读存储介质存储有计算机指令，该计算机指令用于使计算机执行时能够实现上述任意实施例所描述的远程控制请求处理方法。
155.本公开实施例提供了一种计算机程序产品，该计算机程序在被处理器执行时能够实现上述任意实施例所描述的远程控制请求处理方法。
156.在此基础上，本公开实施例还提供了一种包括有上述电子设备的云端服务器，以用于作为实现本公开上述技术方案的整个远程控制请求的处理或调度平台。
157.相对应的，本公开实施例还可以提供一种自动驾驶车辆，包括：
158.向上述实施例描述的云端服务器发起远程控制请求；
159.接收响应于云端服务器下发的第一远程控制指令的指定远程驾驶舱发来的远程控制参数；其中，第一远程控制指令在云端服务器确认发起远程控制请求的自动驾驶车辆关联有重点保障标识时、向与重点保障标识对应的云端驾驶舱下发。
160.相对应的，本公开实施例还可以提供一种云端驾驶舱，包括：
161.接收上述实施例描述的云端服务器下发的第一远程控制指令；其中，第一远程控制指令在云端服务器确认发起远程控制请求的自动驾驶车辆(即上述实施例描述的自动驾驶车辆)关联有重点保障标识时、向与重点保障标识对应的云端驾驶舱下发；
162.根据第一远程控制指令向自动驾驶车辆下发远程控制参数。
163.图9示出了可以用来实施本公开的实施例的示例电子设备900的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
164.如图9所示，设备900包括计算单元901，其可以根据存储在只读存储器(rom)902中的计算机程序或者从存储单元908加载到随机访问存储器(ram)903中的计算机程序，来执行各种适当的动作和处理。在ram 903中，还可存储设备900操作所需的各种程序和数据。计算单元901、rom 902以及ram 903通过总线904彼此相连。输入/输出(i/o)接口905也连接至总线904。
165.设备900中的多个部件连接至i/o接口905，包括：输入单元906，例如键盘、鼠标等；输出单元907，例如各种类型的显示器、扬声器等；存储单元908，例如磁盘、光盘等；以及通
信单元909，例如网卡、调制解调器、无线通信收发机等。通信单元909允许设备900通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
166.计算单元901可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元901的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元901执行上文所描述的各个方法和处理，例如远程控制请求处理方法。例如，在一些实施例中，远程控制请求处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元908。在一些实施例中，计算机程序的部分或者全部可以经由rom 902和/或通信单元909而被载入和/或安装到设备900上。当计算机程序加载到ram 903并由计算单元901执行时，可以执行上文描述的远程控制请求处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元901可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行远程控制请求处理方法。
167.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
168.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
169.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd
‑
rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
170.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
171.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
172.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端
‑
服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(vps，virtual private server)服务中存在的管理难度大，业务扩展性弱的缺陷。
173.相比于各远程驾驶舱基于自动接单的方式来处理各远程控制请求的现有处理方式，本公开实施例基于车辆的出行计划和/或实际安保等级来确定是否要为其关联用于指定某些远程驾驶舱的重点保障标识，从而通过指定远程驾驶舱来为关联有该重点保障标识的车辆提供更全面、更有效的远程控制服务，同时也拓展了一种新的远程控制请求处理方式，可覆盖更多样的要求和场景。
174.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
175.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。