CN115320622A - 车辆控制方法、系统、电子设备及计算机程序产品 - Google Patents

Abstract

本申请实施例提供一种车辆控制方法、系统、电子设备及计算机程序产品。本申请实施例提供的技术方案中，车端和服务端中的一端在执行目标场景对应的多个操作过程中出现无法执行下去的情况（即无法执行多个操作中的一个操作）时，在无法执行的操作处中断执行，并向另一端发送调度信息，以调度另一端自中断位置（即无法执行的操作）处接续执行所述多个操作中未被执行的操作。可见，本申请提供的方案实现了车端和服务端协同执行目标场景的方式，可充分的利用车端资源和云端资源，提供更精准、多样的主动服务。

Description

车辆控制方法、系统、电子设备及计算机程序产品

技术领域

本申请涉及计算机技术领域，尤其涉及一种车辆控制方法、系统、电子设备及计算机程序产品。

背景技术

目前，为了能在车辆上实现更为智能的主动服务，提出了服务场景（或称为场景化服务）的设计理念。服务场景可简单理解为是映射到现实世界中的一个或多个“事件”，如主动推荐目的地附近充电桩事件、雨天主动推荐歌曲事件、停车后主动调整座舱为休闲放松氛围的事件等等。服务场景由多个操作组成，执行主体执行这些操作，便能控制车辆上至少一个功能部件工作以为驾乘人员提供相应的场景化服务。

现有技术中有一种方式是服务场景单由车端执行，另一种方式是服务场景单由服务端（如云端）。前一种方式，车端资源有限，可实现一些较为简单的场景。后一种方式车端仅作为指令接收端，受控于云端。

发明内容

本申请提供一种车辆控制方法、系统、电子设备及计算机程序产品，以充分利用到车端和服务端的资源。

在本申请的第一个实施例中，提供了一种车辆控制方法，适于第一端。具体的，所述车辆控制方法包括：

确定目标场景，所述目标场景对应可执行的多个操作；

执行所述多个操作；

在执行所述多个操作过程中监测到无法执行的第一操作时，在所述第一操作处中断执行；

向第二端发送第一调度信息，以调度所述第二端自所述第一操作出接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务；所述第一操作是所述多个操作中的一个操作。

在本申请的第二个实施例中，提供了一种适于第二端的车辆控制方法。该方法包括：

响应于第一端发送的第一调度信息，确定目标场景对应的第一操作；其中，所述目标场景对应可执行的多个操作，所述第一操作为所述多个操作中的一个操作；

自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一调度信息是所述第一端在执行所述多个操作过程中监测到无法执行的第一操作时发送的；

所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务。

在本申请的第三个实施例中，提供了一种车辆控制系统。该车辆控制系统包括：

第一端，用于确定目标场景，所述目标场景对应可执行的多个操作；执行所述多个操作；在执行所述多个操作过程中监测到无法执行的第一操作时，在所述第一操作处中断执行，并向第二端发送第一调度信息；

第二端，用于响应于所述第一调度信息，确定目标场景对应的所述第一操作；自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述目标场景中的操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务；所述第一操作是所述多个操作中的一个操作。

在本申请的第四个实施例中，提供了一种车辆控制方法，该方法适于车端，该方法包括：

执行所述车端当前所处的目标场景对应的多个操作中的第一操作，以控制至少一个第一车端功能部件工作；

接收服务端发送的控制指令，根据所述控制指令控制至少一个第二车端功能部件工作，所述控制指令是所述服务端执行所述多个操作中的第二操作生成的，所述第二操作为所述目标场景对应的多个操作中所述车端无法执行的操作。

在本申请的第五个实施例中，提供了一种电子设备。该电子设备为车端设备或服务端设备。所述电子设备包括存储器和处理器，其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于实现上述第一实施例提供的所述车辆控制方法中的步骤，或者实现第二实施例提供的所述车辆控制方法中的步骤。

在本申请的另一个实施例中，提供了一种计算机程序产品，包括计算机程序/指令，当所述计算机程序/指令处理器被执行时用于实现如上所述本申请第一个实施例所述车辆控制方法中的步骤，或者实现如上所述本申请第二个实施例项所述车辆控制方法中的步骤，或实现如上所述本申请第四个实施例所述车辆控制方法中的步骤。

本申请多个实施例提供的技术方案中，车端和服务端中的一端在执行目标场景对应的多个操作过程中出现无法执行下去的情况（即无法执行多个操作中的一个操作）时，会在无法执行的一个操作处中断执行，并向另一端发送调度信息，以调度另一端自中断的操作处接续执行多个操作中未被执行的操作。可见，本申请提供的方案实现了车端和服务端协同执行目标场景的方式，可充分的利用车端资源和服务端资源，提供更精准、多样的主动服务。

附图说明

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

图1a为本申请一实施例提供的场景化的车辆控制系统的一种实现的原理性示意图；

图1b为本申请一实施例提供的场景化的车辆控制系统的另一种实现的原理性示意图；

图2为本申请一实施例提供的第一场景引擎的结构示意图；

图3为本申请一实施例提供的场景引擎的结构示意图；

图4为本申请一实施例提供的车辆控制方法的流程示意图；

图5为本申请一实施例提供的一场景的示意图；

图6为本申请另一实施例提供的车辆控制方法的流程示意图；

图7a为本申请一实施例提供的车端和服务端协同执行场景的第一种模式的原理性示意图；

图7b为本申请一实施例提供的车端和服务端协同执行场景的第二种模式的原理性示意图；

图7c为本申请一实施例提供的车端和服务端协同执行场景的第三种模式的原理性示意图；

图8为本申请又一实施例提供的车辆控制方法的流程示意图；

图9为本申请另一实施例提供的车端和服务端协同执行场景的第三种模式的原理性示意图；

图10为本申请一实施例提供的一种电子设备的结构示意图；

图11为本申请一实施例提供的计算机程序产品的结构示意图。

具体实施方式

现有方案中，场景执行多为单端执行，即单由车端或服务端执行。场景是若干个操作的集合，换句话也就是说，场景由同一执行主体对应的若干操作组成。比如，雨天场景包括如下顺序执行的多个操作：

操作11：车辆行驶过程中检测到下雨时，播放询问语音，以询问用户是否想要听适于雨天听的歌曲；

操作13：若检测到用户确认要听的语音，则在本地音乐库中搜索适于雨天听的多首歌曲；

操作14：顺序播放所述多首歌曲；

操作15：控制车辆氛围灯切换到雨天适配的氛围模式。

上述各操作（也可称为步骤或规则）的执行主体均为车端。车端可记录用户行为信息，如出行时段、驾驶习惯、交互行为（如交互界面操作行为、语音互动行为等等），并利用本地部署的分析模型（如神经网络模型）分析用户在各种场景（雨天、特定出行时段、晴天等等）下的喜好。上述操作13便可根据分析出的用户雨天喜好（如喜欢哪一类或哪一位歌手的歌、喜欢暖色氛围灯等等），在本地音乐库中搜索用户雨天常听的歌曲和/或推荐符合用户喜好的适于雨天听的歌曲，并控制车辆氛围灯切换到暖色模式。

从上面的单由车端执行的雨天场景实例可以看出，仅利用本地数据（音乐库）非常有限，不能为用户提供更为多元的数据（如歌曲）。除此之外，车端设备性能有限；为适应车端设备性能，车端部署的分析模型（如神经网络模型）可能较为轻量，分析出的结果精准度有限。又或者，因车端硬件设备性能的限制，车端设备不适于部署分析模型，上述操作13仅基于历史上用户在雨天听歌的记录为用户主动推送适于雨天听的歌曲；或根据预配置的关键词匹配操作，搜索符合匹配操作的歌曲作为适于雨天听的歌曲；这就导致车端不能执行较为复杂的服务场景，能为用户提供的服务场景有限，影响用户体验。

再比如，雨天场景包括如下顺序执行的多个操作：

操作21：服务端基于第三方数据确定**区域下雨，基于接收到的车辆上传的定位信息，获取在**区域内行驶的至少一个车辆的车辆标识。

操作22：服务端根据至少一个车辆的车辆标识，向各车辆发送询问语音，以询问用户是否想要听适于雨天听的歌曲；

操作23：服务端接收车辆反馈的响应信息；并基于接收到响应信息，确定用户确认要听的目标车辆；

操作24：服务端根据所述目标车辆的历史数据，搜索适于雨天听的多首歌曲；

操作25：服务端基于搜索到的所述多首歌曲，采用多媒体流的方式下发至目标车辆，以使得目标车辆在线播放歌曲。

上述各操作（也可称为步骤或规则）的执行主体均为服务端。服务端资源多样，可为用户提供更多元、更精准的服务。但在车辆数量较大时，全部或大部分均由服务端处理，势必增加服务端的负载。为满足计算需求，服务场景提供方需花费大量成本提高服务端的硬件和软件性能。

针对上述提及的问题，本申请提供一种能灵活、充分利用车端和服务端资源的方案。本申请实施例提供的方案可自适应各类配置（如各级别硬件性能）的车辆，在车辆自行判定无法执行场景中的一个操作时，能中断执行，转交由服务端执行，由服务端接续车端执行该场景。本申请实施例提供的方案还可以是：服务端如果在执行某一场景的过程中监测到无法执行其中一个操作时，同样可中断执行，转交由车端执行，由车端接续服务端执行该场景。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。另外，下述的各实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在介绍本申请各实施例提供的技术方案之前，先对下文中涉及到的一些名词或术语进行详细介绍说明。

本文中的“场景”、“目标场景”等，即背景技术中提及的服务场景，具体是指通过分析用户在出行的各种场景下对服务的需求，将服务进行场景化，以提供面向用户的更具有个性化、情感化、场景化主动式出行服务。由此可见，场景是相对人（如用户）而言的。比如，疲劳场景下可为用户（如驾驶员）提供音乐、氛围灯等主动式服务；下雨场景下可提供关闭天窗和/或车窗、打开雨刮、推荐雨天歌曲、启动除雾功能等主动式服务。一般地，这些场景可由驾乘人员和/或产品方人员等预先编排定义，然后存储于场景库中。场景引擎可对场景库中的场景进行订阅，以在监测到一个场景满足触发条件时，触发并执行该场景。场景由一个或多个操作组成，执行场景就是执行场景中的各操作。场景中的操作类似于执行流程中的各步骤，各步骤间通过执行逻辑关联。

这里需要说明的是，一个场景中可包含一个或多个事件，一个事件反映了用户的意图，意图反映了用户的行为目的，目的包括用户需求的服务。比如，雨天场景可包括可执行的多个操作，多个操作中的部分操作执行完可为用户推荐雨天适于听的歌曲（第一个事件）、另一部分操作执行完可启动雨刮器（第二个事件）、再有一部分操作执行完可关闭车窗（第三个事件），等等。

本申请各实施例中提及的场景（如目标场景）可以是但不限于：疲劳场景（推荐最近的服务区、欢快的音乐、氛围灯等主动式醒神服务）、推荐场景（目的地充电桩推荐、目的地美食推荐、目的地景点推荐、目的影院电影推荐、目的地附近酒店推荐等）、雨雪天场景（雨天音乐、雨刷器自启动、暖色系氛围灯等主动式服务）、晴天场景（晴天音乐、遮阳等主动式服务）、拥堵场景（路况播报、推荐相声等）、驻车休息场景（驻车后播放放松的音乐、调座椅角度等）；等等。

以下对本申请各实施例提供的技术方案进行详细介绍说明。

图1a和1b示出了本申请一实施例提供的一种场景化的车辆控制系统。如图1a和1b所示，所述车辆控制系统包括第一端和第二端。其中，第一端和第二端中的一个为车端11，另一个为服务端12。

第一端，用于确定目标场景，所述目标场景对应可执行的多个操作；执行所述多个操作；在执行所述多个操作过程中监测到无法执行的第一操作时，在所述第一操作处中断执行，并向所述第二端发送第一调度信息；

第二端，用于响应于所述第一调度信息，确定目标场景对应的所述第一操作；自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一端和所述第二端中的一个为车端11，另一个为服务端12；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务；所述第一操作是所述多个操作中的一个操作。车辆上的功能部件包括但不限于车窗、车门、车灯、空调、座椅、扬声器、多媒体播放器、香氛系统、显示屏、音响系统、辅助驾驶系统、自动驾驶系统、休闲娱乐系统等。

服务端12还可称为车联网平台或后台服务器。服务端12可以是但不限于：服务器、部署在物理机上的虚拟服务器、服务器集群或云端等。车端11可以是但不限于：电动车、汽油车、混动车等等，更具体的是指：车辆上的电器设备，如处理芯片、存储器等。服务端12与车端11之间可通过移动网络（如4G、5G等）通信。

进一步的，服务端具有与车端交互的接口，例如可包括：上行接口和下行接口。其中，上行接口用于接收车端发送的信息，如上文中的第一调度信息、车端自主上传的数据或驾乘人员操作上传的数据（如定位信息）等等。下行接口用于向车端发送信息。本实施例对于所述上行接口接收的信息和下行接口发送的信息不作具体限定。

参见图1a示出的第一端为车端11，第二端为服务端12的实施例，第一端确定出目标场景后，执行目标场景对应的多个操作，监测到无法执行多个操作中的操作3，此时第一端中断执行，并向服务端12发送第一调度信息（该第一调度信息中含有表征操作3为目标场景中断位置的信息，更具体地，如含有目标场景的场景标识及第一操作的操作标识）。服务端12在接收到该第一调度信息后，基于第一调度信息，确定操作3为接续起始操作；随后自操作3起执行所述多个操作中未被执行的操作，以接续车端11执行。

图1b示出了第一端为服务端12，第二端为车端11的实施例。

在一可实现的技术方案中，所述第一端上可部署有第一场景引擎20。参见图2所示，所述第一场景引擎20包括：第一执行器23、第一中断器24及第一调度器25。其中，

第一执行器23，用于执行所述多个操作；

第一中断器24，用于监测所述第一执行器23执行所述多个操作的过程；若监测到所述第一执行器23无法执行第一操作时，向所述第一执行器23发送中断信号；

所述第一执行器23，还用于响应于所述中断信号，在所述第一操作处中断执行；

第一调度器25，用于向所述第二端发送所述第一调度信息。

在一具体实施例中，上述第一中断器24在监测到第一执行器23无法执行第一操作时，除了可向第一执行器23发送中断信号外，还可以执行根据获取到的目标场景的场景标识和第一操作的操作标识，生成目标场景对应的中间执行状态信息；并对该中间执行状态信息进行编码得到第一调度信息；然后，再将第一调度信息交由第一调取器25以发送至第二端。

或者，在另一具体实施例中，上述第一中断器24在监测到第一执行器23无法执行第一操作时，除了可向第一执行器23发送中断信号外，还可基于所述第一操作，标定目标场景对应的第一中断位置；相应地，第一调度器25可根据所述第一中断位置，向所述第二端发送所述第一调度信息。

有关标定第一中断位置的具体实现，将下文本申请提供的方法实施例中展开详细描述。

进一步的，在一种可实现的方案中，本实施例中的所述第一中断器24，还用于响应于所述第二端发送的第二调度信息，向所述第一执行器23发送重启信号；其中，所述第二调度信息是所述第二端自所述第一操作处接续所述第一端执行所述多个操作中未被执行的操作过程中监测到无法执行的第二操作发送的；所述第二操作是所述多个操作中的一个操作。相应地，

所述第一执行器23，用于响应于所述重启信号，确定所述第二操作；自所述第二操作处重启执行，以接续所述第二端执行所述多个操作中未被所述第一端和所述第二端执行的操作。

具体实施时，上述有关第二端向第一端发送第二调度信息的具体实现，可参见上文描述的第一端向第二端发送第一调度信息的实现过程，此处不再作具体赘述。

这里需要补充的是：此处的第二操作可以与上文的第一操作为目标场景中的同一操作，也可为不同的操作。

再进一步的，参见图2所示，所述第一场景引擎20除包括第一执行器23、第一中断器24和第一调度器25之外，还可包括但不限于：第一触发器21、第一仲裁器22、第一交互装置26等等。其中，第一仲裁器22用于根据数据信息确定至少一个场景，从至少一个场景中挑选一个或多个场景作为目标场景。其中，所述数据信息可包括：与用户交互的交互信息、车辆上多个传感器采集到的信息等等。第一触发器21用于响应于接收到的信号或指令，触发目标场景的启动。第一交互装置26用于生成与用户交互的交互信息，如生成交互语音，交互文本、图像或视频等等。第一交互装置26将生成的交互信息发送至车端上的相应设备（如扬声器或显示器等），如通过扬声器播放出来或通过显示器显示出来。第一交互装置26可响应于所述第一执行器23发送的生成指令，生成所述交互信息。例如，第一执行器23执行一操作“获取到附近充电桩信息后，触发第一交互装置26生成所述附近充电桩信息对应的语音信息”后，生成触发指令。第一交互装置26响应于该触发指令，将所述附近充电桩信息转化为语音信息，以便车端扬声器播放。

一种可实现的方式是，第一仲裁器22挑选（或仲裁）出所述目标场景后，通过第一交互装置26生成“询问用户是否需要被提供所述目标场景对应的服务”的交互信息；若接收到用户回复的“确认”语音，或监测到用户通过相应控件触发“确认”操作等，则生成针对该目标场景的执行指令。第一触发器21响应于该执行指令，触发所述目标场景的启动。或者另一种情况：在第一仲裁器22仲裁出所述目标场景后，第一仲裁器22根据历史数据确定用户是否接受所述目标场景对应的服务，若确定接受，则生成针对该目标场景的执行指令。第一触发器21响应于该执行指令，触发所述目标场景的启动。当然，除上述两种情况外，还可包括但不限于：用户主动触发调取执行所述目标场景的情况，响应于用户主动触发的调取指令，所述第一触发器21触发所述目标场景的启动。

同所述第一端，所述第二端上也可部署有第二场景引擎。所述第二场景引擎包括：第二中断器和第二执行器。其中，

第二中断器，用于响应于第一端发送的第一调度信息，确定目标场景对应的第一操作；基于所述第一操作，向第二执行器发送启动信号；

第二执行器，用于响应于启动信号，自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作。

进一步的，所述第二场景引擎还可包括第二调度器。具体的，所述第二中断器还用于监测所述第二执行器自所述第一操作处操接续所述第一端执行所述多个操作中未被执行的操作的过程；若监测到无法执行的第二操作，则向所述第二执行器发送中断信号；所述第二执行器，还用于响应于所述中断信号，在所述第二操作处中断执行；所述第二调度器，用于向所述第一端发送第二调度信息，以调度所述第一端自所述第二操作处接续所述第二端执行所述多个操作中未被所述第一端和所述第二端执行的操作。

这里需要说明的是，上述第二端上部署的第二场景引擎的结构可与第一端上部署的第一场景引擎相同或相似。即所述第二场景引擎除包括第二执行器、第二中断器及第二调度器外，还可包括第二触发器、第二仲裁器和第二交互装置等等。另外，上述第一场景引擎和第二场景引擎各自包含的执行器、中断器、调度器等器件的具体功能实现，可参见下文本申请其他实施例中的相关内容。

相应的，本申请的另一实施例提供了一种用于部署在第一端和第二端上的场景引擎。如图3所示，所述场景引擎包括执行器33、中断器34及调度器35。其中，

执行器33，用于执行目标场景对应可执行的多个操作；

中断器34，用于监测所述执行器33执行所述多个操作的过程；若监测到所述执行器33无法执行的第一操作时，向所述执行器33发送中断信号；其中，所述第一操作为所述多个操作中的一个；

所述执行器33，还用于响应于所述中断信号，在无法执行的第一操作处中断执行；

调度器35，用于向所述第二端发送第一调度信息，以调度所述第二端自所述无法执行的第一操作处接续所述第一端执行所述多个操作中未被执行的操作。

上述执行器、中断器及调度器对应的功能均是以所述场景引擎部署在第一端的角度描述的。若场景引擎部署在第二端，则上述调度器35就是向第一端发送第一调度信息，以调度第一端自所述无法执行的第一操作处接续所述第二端执行所述述多个操作中未被执行的操作。

其中，所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务。

进一步的，如图3所示，所述中断器34可包括但不限于如下模块：

监测模块341，用于监测所述执行器33执行所述多个操作的过程；若监测到所述执行器33无法执行的第一操作时，向所述执行器33发送中断信号；

生成/标定模块342，用于获取所述目标场景的场景标识及无法执行的第一操作对应的操作标识；基于所述目标场景的场景标识和所述第一操作对应的操作标识，生成所述目标场景对应的中间执行状态信息；

编解码模块343，用于对所述中间状态信息进行编码得到第一调度信息；将所述第一调度信息发送至所述第一调度器，以便所述第一调度器调度所述第二端。

这里需要补充说明的是，在其他的一些实施例中，上述中断器34在监测到所述执行器33无法执行所述多个操作中的一个操作时，除了可向所述执行器33发送中断信号外，还可以执行：基于无法执行的第一操作，标定目标场景对应的第一中断位置；换句话也可以说，基于无法执行的第一操作，标定所述执行器33中断执行时对应的第一中断位置。相应地，上述生成/标定模块324，在生成目标场景对应的中间执行状态信息后，可以将该中间执行状态信息，作为第一中断位置的标记。也即，上述生成的中间状态信息表征了所述目标场景对应的所述第一中断位置。

再进一步的，如图3所示，所述中断器34还可包括重启模块344。其中，

所述编解码模块343，用于响应于所述第二端发送的第二调度信息，对所述第二调度信息进行解码，得到解码后的信息；其中，所述第二调度信息是所述第二端自所述无法执行的第一操作处接续所述第一端执行所述多个操作中未被执行的操作过程中监测到无法执行的第二操作时发送的；第二操作为所述多个操作中的一个，第一操作和第二操作可以相同，也可以不同。

重启模块344，用于根据所述解码后的信息，确定所述第二操作；基于所述第二操作，向所述执行器33发送重启信号；

所述执行器33，用于响应于所述重启信号，自所述第二操作处接续所述第二端执行所述多个操作中未被所述第一端和所述第二端执行的操作。

其中，编解码模块343可将上述中间状态信息编码为适于网络传输的数据形式，如符合传输协议的二进制数据；相应的，解码过程就是将符合传输协议的二进制的第二调度信息进行解码，以解码为符合车端或服务端要求的信息。

场景引擎为解决场景触发、执行、交互等的技术架构，其可基于车辆数据、用户数据、环境数据及交通数据等各种数据的深度融合，利用人工智能（AI）算法对用户在用车期间的下一步需求进行预判，触发并执行与用户下一步需求相适配的服务场景，从而实现主动地向用户推荐一些适当的内容或提供一些适当的服务，以此增加用户的行车安全、优化智能体验、驱动智行生活。

参见图3所示，本申请实施例提供的场景引擎30还可包括但不限于：触发器31、仲裁器32、交互装置36等等。其中，触发器31、仲裁器32及交互装置36的具体功能，可参见上文中有关第一触发器、第一仲裁器及第一交互装置的描述，此处不作赘述。

图4示出了本申请一实施例提供的车辆控制方法的流程示意图，所述车辆控制方法是一种基于场景的车辆控制方法，且该方法的执行主体为第一端，更具体的是第一端上部署的场景引擎（如上文中实施例提供的场景引擎）。如图4所示，所述场景处理方法包括以下步骤：

100、确定目标场景；其中，所述目标场景对应可执行的多个操作；

101、执行所述多个操作；

102、在执行所述多个操作过程中监测到无法执行的第一操作时，在所述第一操作处中断执行；

103、向第二端发送第一调度信息，以调度所述第二端自所述第一操作处接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务；所述第一操作是所述多个操作中的一个操作。

这里需要补充的是：为了区别第一端和第二端上部署的场景引擎，下文中将部署于第一端的场景引擎称为第一场景引擎；将部署于第二端的场景引擎称为第二场景引擎。另外，在下文介绍本实施例内容时主要是以第一端为车端为例进行说明的。

上述100中，目标场景可以是场景库中的一个场景。第一场景引擎可以对场景库中存储的所有场景（或部分场景）进行订阅，并在订阅之后，当第一场景引擎根据车端收集到的如车辆数据、用户数据等各种数据确定其所订阅的多个场景中的某一个场景满足触发条件时，便会将该服务场景作为本实施例中的目标场景，执行该目标场景。

比如，用户在车辆上的触摸屏上操作，搜索“**大厦”，则第一场景引擎基于该操作信息，从多个场景中仲裁（或确定）出“推荐**大厦附近充电桩”的推荐场景为目标场景；然后根据历史数据，判定用户接受该目标场景对应的服务的概率大于一阈值之后，执行该目标场景。

即，在一可实现的技术方案中，上述100“确定目标场景”，可具体包括如下步骤：

100a、获取数据信息；

其中，所述数据信息可包括但不限于：车辆数据（空调状态、车窗状态、车内温度、行驶速度、剩余电量、目的地等）、与服务对象相关的数据（服务对象包括驾乘人员、动物等，数据包括座位分布、面部表情、驾驶动作、与车辆交互信息、是否有宠物等）、车辆检测到的环境数据（空气指数、车道数据、气温、雨雪、周围车辆和/或行人的数据）等等。

100b、基于所述数据信息，确定至少一个适配的场景；

100c、从所述至少一个适配的场景中，选出目标场景；

上述步骤100b“基于所述数据信息，确定至少一个适配的场景”可包括：基于所述数据信息，分析用户意图；从多个场景中确定适配用户意图的至少一个场景。

其中，用户意图的分析可利用神经网络模型、知识图谱等实现。例如，将所述数据信息作为神经网络模型的入参，执行所述神经网络模型，以预测用户意图。

例如，数据信息包括：车辆停驻、在预设时长内未开门锁车、中午12:00~1:00时段等，基于这些信息，分析出用户意图为车内小憩。

再例如，数据信息包括：车内有宠物、车辆行驶等，基于这些信息，分析出用户意图为车窗关闭、香氛关闭。

上述100c中“从所述至少一个适配的场景中，选出目标场景”，可包括：根据与驾乘人员相关的历史数据，确定所述驾乘人员接受所述至少一个适配的场景对应服务的接受度；基于所述接受度，从所述至少一个适配的场景中选出目标场景。

具体实施时，上述接受度能反映出驾乘人员接收一个场景对应服务的概率。进行目标场景选择时，可以将至少一个适配的场景中对应接受度大于预设阈值的场景，作为目标场景。或者，也可以基于所述接受度，对至少一个适配的场景进行排序，将至少一个适配的场景中排序在前的预设数量个场景作为目标场景，例如，可以将排序第一的场景作为目标场景。

这里需要补充说明的是：本实施例中提及的与服务对象有关的数据，是在用户（如驾乘人员）授权或确认后才获取的，未经用户授权或确认的数据不获取。用户数据可包括但不限于：用户主动输入的信息（如音乐喜好、驾驶喜好等）、用户与车端交互设备（如语音、控件、触摸屏等）交互产生的行为信息、经用户授权采集到用户面部图像、用户肢体动作影像等等。车辆数据可包括但不限于：车辆定位信息、车辆上多个传感器采集到的信息（如雷达、距离传感器等采集的车辆周围的环境信息、摄像头采集到的车外图像等等）。

目标场景包括可执行的多个操作，多个操作通过内在的执行逻辑关联在一起，如图5所示的例子。由此，上述101“执行所述多个操作”实际上就是按照执行逻辑执行各操作。如若有分支，可能就会跳过某一个操作不执行。具体的，执行多个操作中的一个操作，可能会因很多因素导致无法执行，此时便可启动中断机制，即中断针对多个操作的执行，具体地是在无法执行的操作处中断执行。

实际上，上述102中，某一操作无法执行的原因可以有多种，比如：车辆故障、车辆当前数据处理量大、CPU占用量大无法执行该操作；也可能是执行该操作需借助服务端的数据才能执行；也可能是执行该操作需要使用服务端强大的计算模型（如神经网络模型、专家系统、知识图谱等等）。比如，车端执行某一操作需获取服务端的数据，则车端就无法执行该操作。同样的，若服务端执行一个操作需车端数据，则服务端就无法执行该操作。又比如，车端执行某一操作需车端硬件设备满足**配置以上，若没达到，则车端无法执行该操作。再比如，车端执行某一个操作需借助服务端侧的深度学习模型（Deep Learning，DL），车端未部署该模型，则车端无法执行该操作。

基于上述描述的导致某一操作无法执行的原因内容，在一种可实现的实施例中，本实施例提供的方法还可包如下中的至少一步骤：

S11、确定执行所述第一操作依赖的资源；判断所述第一端的可用资源与所述第一操作依赖的资源是否适配；若不适配，则无法执行所述第一操作；

S12、若监测到所述第一端故障，则无法执行所述第一操作。

上述S11中，执行第一操作依赖的资源可包括但不限于如下中的至少一项：执行第一操作依赖的数据、执行第一操作依赖的硬件、执行第一操作依赖的计算模型。其中，所述计算模型可包括：机器学习模型（如深度学习模型）、知识图谱、专家系统等等。

第一端的可用资源指的是第一端上的可被使用（或调度）的资源，其可包括但不限于如下中的一种或组合：硬件资源（如内存、CPU）、软件资源（如各种模型，更具体地如分析模型、计算模型等）、数据资源。

上述所述的“资源适配”可简单理解为：第一端的可用资源能满足第一操作的执行需求，可为执行第一操作执行提供其依赖的所有资源。若第一端的可用资源与第一操作依赖的资源适配，则可以利用第一端的可用资源执行第一操作。反之，若第一端的可用资源与第一操作依赖的资源不适配，则确定无法执行第一操作。例如，为保证第一操作的执行速率及精准度等，车端执行第一操作的执行需求为：第一端上的CPU占用率不超过M%，若第一端上的CPU占用率超过M%，则第一端的可用CPU资源与第一操作依赖的CPU资源便不适配，第一操作无法在第一端上执行。

进一步地，在确定无法执行第一操作时，除了通过上述步骤102执行在第一操作处中断执行外，还可以针对此次中断标定中断位置，以便在调度第二端接续执行时能自中断位置（即第一操作）处执行。基于此，在上述102和上述103之间，本实施例提供的所述方案还可包括如下步骤：

S21、基于所述第一操作，标定中断执行时对应的第一中断位置；相应地，

一种可实现技术方案中，上述103中“向第二端发送第一调度信息”可具体包括：根据所述第一中断位置，向所述第二端发送第一调度信息。

上述S21中，标定中断位置实质上就是标记目标场景对应的多个操作执行中断时的中间状态，以便被转交的另一端能基于中间状态，接续继续执行多个操作中未被执行的其他操作。实际实施时，上述第一中断位置可使用目标场景的场景标识及第一操作的操作标识来表征。即，一具体可实现的技术方案中，上述S21“基于所述第一操作，标定中断执行时对应的第一中断位置”可采如下步骤实现：

S211、获取所述目标场景的场景标识及所述第一操作的操作标识；

S212、基于所述目标场景的场景标识和所述第一操作的操作标识，生成所述目标场景对应的中间执行状态信息；

S213、将所述中间执行状态信息，作为所述第一中断位置的标记。

有上，也就是说，上述中间执行状态信息表征了所述目标场景的所述第一中断位置。

场景包括的多个操作，多个操作中操作间通过执行逻辑关联。比如，图5所示的一个较为简单的场景示例，场景包括操作1、操作2、操作3和操作4；图5中箭头表征了操作间的执行逻辑。假设第一端无法执行操作3，则将该场景的场景标识及操作3的操作标识，作为该场景对应的中间状态信息。第二端接收到该中间状态信息后，便可获知操作3为第一端中断位置，接续第一端执行该场景时从操作3启动执行。

需说明的是，上述生成的目标场景对应的中间状态信息还可保存在第一端，以便第一端对目标场景对应的多个操作的执行过程进行跟踪和记录。

上述103中，在根据第一中断位置向第二端发送第一调度信息时，可以但不限于直接将第一中断位置作为第一调度信息发送至第二端。

上文描述步骤103的实现时，是从借助“中断位置”的角度来实现向第二端发送相应的调度信息的。当然，在其他可实现技术方案中，也可以直接基于上述S212中生成的目标场景对应的中间执行状态信息，实现向第二端发送相应的调度信息。基于此，

另一种可实现的技术方案中，上述103中“向第二端发送第一调度信息”可具体包括：

1031、获取所述目标场景的场景标识及所述第一操作的操作标识；

1032、基于所述目标场景的场景标识和所述第一操作的操作标识，生成所述目标场景对应的中间执行状态信息；

1033、根据所述中间执行状态信息，向所述第二端发送所述第一调度信息。

有关上述1031~1032的相关描述，可参见上文相关内容。

上述1033中，可以通过但不限于对应中间状态进行编码处理，以此来得到第一调度信息。即，一实施例中，上述1033“根据所述中间执行状态信息，向所述第二端发送所述第一调度信息”，可采用如下具体步骤来实现：

10331、对所述中间执行状态信息进行编码，得到所述第一调度信息；

10332、向所述第二端发送所述第一调度信息。

具有实施时，可以按照第一端和第二端间的传输协议中规定的编码方式，对中间执行状态进行编码，以将中间状态信息编码为适于网络传输的数据形式，如符合传输协议的二进制数据。

本实施例提供的技术方案中，车端和服务端中的一端在执行目标场景对应的多个操作过程中出现无法执行下去的情况（即无法执行多个操作中的一个操作）时，在无法执行的操作处中断执行，并向另一端发送调度信息，以调度另一端自中断位置（即无法执行的操作）处接续执行目标场景对应的多个操作中未被执行的操作。可见，本申请提供的方案实现了车端和服务端协同执行目标场景对应的多个操作的方式，可充分的利用车端资源和服务端资源，为车辆驾乘人员提供更精准、多样的主动服务。

进一步的，本实施例提供的所述方法还可包括如下步骤：

108、响应于所述第二端发送的第二调度信息，确定所述目标场景对应的第二操作；

109、自所述第二操作处重启执行，以接续所述第二端执行所述多个操作中未被所述第一端和所述第二端执行的操作；

其中，所述第二调度信息是所述第二端在自所述第一操作出接续所述第一端执行所述多个操作中未被执行的操作过程中，监测到无法执行的第二操作时发送的。所述第二操作是所述目标场景中的一个可执行的操作。具体的，第二操作和第一操作可以是同一操作，也可是不同操作。

上述108~109的实现，具体可由第一场景引擎20内的第一中断器来完成，第一中断器的具体结构可参见图3示出的中断器34的结构，有关图3中示出的中断器34包含的各单元的具体介绍可参见上文本申请各实施例相关内容。另外，有关上述108~109的具体实现描述，可参见下文本申请图6示出的实施例中的相关内容，具体地，如与下文描述的与步骤201~202相关的内容，此处就不再做具体赘述。

综上内容可知，本申请实施例提供的技术方案，场景对应操作的执行可在车端和服务端自由流转，不用考虑该场景对应的操作是否适于某一类型或某一配置的车辆。场景可部署在任意类型或任意配置的车辆上，车端在触发某一场景后，可自行判断其中的操作是否能执行，能执行在车端执行；不能执行就会中断执行并转由服务端执行；同样的，服务端在触发某一场景时，也可自行判定其中的操作是否能执行，能执行在服务端执行，不能执行就会中断并转由服务端执行。也就是说，场景对应操作的执行可在车端和服务端自由流转，流转触发条件就是各端自行判断是否能执行；本实施例不限定流转次数，理论上可多次流转。但考虑到网络流量、网络延时等，具体实施时，可将场景中一端执行的操作编排在一起，尽量控制中断流转次数。其中，有关场景操作编排的具体实现可参见现有内容。

现有技术中单端执行场景的方案，车端需要获取服务端（如云端）资源时，会在场景中编排向云端请求资源的操作；车端通过执行操作生成相应的请求，并将请求发送至云端。车端处于等待状态，即该场景对应的进程一直存在，等待接收云端的反馈，以根据云端反馈的数据继续执行。而本申请实施例中，车端在监测到无法执行场景中的某一操作时，会在无法执行的操作处中断执行；转交由服务端接续执行。因车端中断场景的执行，就意味着该场景对应的进程关闭，车端的处理资源不会被该场景持续占用。可见，较现有技术，本申请实施例提供的技术方案可及时的释放一端的资源，转交由另一端执行；两端资源可被充分利用，降低因等待一方数据继续执行的资源占用率。另外，现有技术中单端执行场景的方案，编排人员需关注执行主体，如果该场景是车端执行，编排场景中的所有操作应适用于车端；如果该场景是云端执行，编排场景中的所有操作需适用于云端。除此之外，现有技术方案中编排人员还需考虑车端型号、配置等，需有针对性的编排场景。而本申请实施例提供的方案，因场景执行中各端（即车端和云端）在流转至自身端时可自行判断自己是否能执行，在不能执行时及时中断，释放执行进程占用的资源，交由云端执行；编排人员无需考虑车端型号、配置等，只需按场景逻辑编排即可，执行过程就转交由车端和云端自行协同。

图6示出了本申请另一实施例提供的车辆控制方法的流程示意图，该车辆控制方法是与图4示出的车辆控制方法相对应的另一种方法实施例，该方法的执行主体为第二端，更具体的是第二端上部署的场景引擎（如上文中实施例提供的场景引擎）。如图6所示，所述方法包括以下步骤：

201、响应于第一端发送的第一调度信息，确定目标场景对应的第一操作；其中，所述目标场景对应可执行的多个操作，所述第一操作为所述多个操作中的一个操作；

202、自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一调度信息是所述第一端在执行所述多个操作过程中监测到无法执行的第一操作时发送的。所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务。

上述201~202的实现，具体可由第二场景引擎内的第二中断器来完成，第二中断器的具体结构可参见图3示出的中断器34的结构，有关图3中示出的中断器34包含的各单元的具体介绍可参见上文本申请各实施例相关内容，此处不再作具体赘述。

上述201中，有上文本申请其他实施例中描述的与“第一调度信息”相关的内容可知，第一端可采用不同的方式来确定第一调度信息，与之相对应的，本步骤201也可采用相应的不同方式来实现。具体地，

一种可实现技术方案中，上述步骤201“响应于第一端发送的第一调度信息，确定目标场景对应的第一操作”，可具体包括：

2011、根据所述第一调度信息，获取所述目标场景对应的中间执行状态信息；

2012、基于所述中间执行状态信息，确定所述目标场景对应的第一操作。

上述2011中，第二中断器可以通过其内的编解码模块对第一调度信息进行解码，以获得相应的中间执行状态信息。即，上述2011“根据所述第一调度信息，获取所述目标场景对应的中间执行状态信息”，可采用如下步骤来实现：

20111、对所述第一调度信息进行解码，得到所述第一中间执行状态信息；

其中，所述中间执行状态信息包括所述目标场景的场景标识和所述第一操作的操作标识。

具体实施时，上述解码过程就是将第一调度信息解码为符合第二端（如服务端）要求的信息。

相应地，上述2012“基于所述中间执行状态信息，确定所述目标场景对应的第一操作”，可采用如下具体步骤来实现：

20121、根据所述目标场景的场景标识，调取所述目标场景对应的多个操作；

20122、基于所述第一操作的操作标识，从所述多个操作中获取所述第一操作。

具体实施时，可以根据场景标识，向所订阅的场景库发送调取请求，以此获取到目标场景对应的多个操作。或者，也可以先根据场景标识，先从本地查找是否存储有目标场景，若存有，则直接从本地调取目标场景对应的多个操作；反之，若未存有，再执行向所订阅的场景库发送调取请求。

进一步地，上述202“自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作”，可具有包括：

2021、将所述第一操作，作为重启执行的起始操作；

2022、利用所述第二端的资源，自所述起始操作起执行所述多个操作中未被执行的操作。

具体实施时，第二中断器将第一操作作为重启执行的起始操作后，可以向第二场景引擎中的第二执行器发送重启信号，重启信号中携带有起始操作；第二执行器响应于重启信号，也就会调用第二端的资源，开始执行自起始操作起执行多个操作中未被执行的操作。例如，参见图1a，第二端为服务端，起始操作为操作3，第二执行器接收到重启信号后，便会自操作3处重启执行。

另一种可实现技术方案中，上述步骤201“响应于第一端发送的第一调度信息，确定目标场景对应的第一操作”，换一种表述，也可以表达为：步骤201’、响应于第一端发送的第一调度信息，确定所述目标场景对应的第一中断位置；相应地，

上述202“自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作”，换一种表述，也可以表达为：步骤202’自所述第一中断位置处，接续所述第一端执行所述第一端执行所述多个操作中未被执行的操作；

上述步骤201’“响应于第一端发送的第一调度信息，确定目标场景对应的第一中断位置”，可包括：

2011’、根据所述第一调度信息，获取表征所述第一中断位置的中间状态信息；

2012’、基于所述中间状态信息，确定所述目标场景的场景标识和所述第一操作的操作标识。

相应的，上述步骤202’“自所述第一中断位置处，接续所述第一端执行所述第一端执行所述多个操作中未被执行的操作”，可包括：

2021’、根据所述目标场景的场景标识，调取所述目标场景对应的多个操作；

2022’、基于所述第一操作的标识，定位针对所述多个操作启动执行的起始操作；

2023’、利用所述第二端的资源，自所述起始操作起执行所述多个操作中未被执行的操作。

具体实施时，上述2022’中，定位起始操作，就是基于第一操作的标识，从多个操作中查找到相应的第一操作，以此将第一操作作为启动执行的起始操作。

有关上述2021’和2023’的具体实现描述，可参见上文其他实施例中描述的相关内容，此处不再作具体赘述。

进一步的，本申请实施例提供的所述方法还可包括如下步骤：

203、自所述第一操作处接续所述第一端执行所述多个操作中未被执行的操作过程中监测到无法执行的第二操作时，在所述第二操作处中断执行；

204、向所述第一端发送第二调度信息，以调度所述第一端自所述第二操作处接续所述第二端执行所述多个操作中未被所述第一端和所述第二端执行的操作。

上述第二端在监测到无法执行的第二操作时，除了可执行在第二操作处中断执行外，还可以针对此次中断标定中断位置，以便在调度第二端接续执行时能自中断位置（即第一操作）处执行。基于此，在上述203和上述204之间，本实施例提供的所述方法还可包括如下步骤：

S31、基于所述第二操作，标定所述目标场景对应的第二中断位置；

相应地，在一实施例中，上述204中可基于第二中断位置，向第一端发送第二调度信息。当然，也可以采用其它方式来实现向第一端发送第二调度信息。

有关上述第二端向第一端发送第二调度信息、以及确定无法执行的第二操作的具体实现，可参见本申请其他实施例中描述的第一端向第二端发送第一调度信息、以及确定无法执行的第一操作的相关内容，此处不再作具体赘述。

这里需要说明的是：本实施例提供的技术方案是基于上述图4所示的实施例的基础上，从第二端角度来撰写的。实际上，场景引擎可具有这两个实施例包括的所有步骤对应的功能。即在本实施例提供的方案中除可实现上述201~204步骤外，还可实现上文中图4对应实施例中的步骤101~109中的部分步骤，同样的，上文中图4对应实施例也可包括本实施例中201~204中的部分步骤，比如步骤2011~2012。

本申请各实施例提供的车端和服务端协同执行场景的方案，可包括如下几种模式：

模式1、

参见图7a所示，车端触发目标场景的执行，车端执行目标场景对应的多个操作（即操作1~操作n）过程中发生中断时，交由服务端从中断处接续执行目标场景。服务端执行完后或执行过程中，向车端发送相应的执行数据，以控制车辆上至少一个功能部件工作，提供相应的场景化服务。

模式2、

参见图7b所示，服务端触发目标场景的执行，服务端执行目标场景对应的多个操作（即操作1’~操作n’）过程中发生中断时，交由车端从中断处接续执行目标场景。所述车端执行完后或执行过程中，控制车辆上至少一个功能部件工作，提供相应的场景化服务。

模式3、

参见图7c所示，车端或服务端触发目标场景的执行，车端或服务端执行目标场景过程中发生中断时，交由另一端从中断处接续执行目标场景。执行目标场景的一端再次发生中断，再交由另一端从再次中断处接续执行目标场景；这样来回流转，直至目标场景执行完成。

模式3适用于较为复杂的场景。模式1和模式2将流转控制在一次，模式3在车端和服务端之间流转多次。这样多次流转会影响场景执行效率。因此在场景编排时，可尽量将车端执行的操作编排在一起，将服务端执行的操作编排在一起，以减少流转次数。

需补充说明的是：车端和服务端部署的场景可相同，如图7a~7c所示的例子。实际上，车端和服务端上可部署同一场景中的不同操作。比如，车端部署场景中的操作1~操作i；服务端部署场景中的操作i~操作n。

本申请又一实施例提供了另一种车辆控制方法，该方法包括：

执行车端当前所处的目标场景对应的多个操作中的第一操作，以控制至少一个第一车端功能部件工作；

接收服务端发送的控制指令，根据控制指令控制至少一个第二车端功能部件工作，该控制指令是服务端执行车端当前所处的目标场景对应的多个操作中的第二操作生成的，第二操作为所述目标场景对应的多个操作中所述车端无法执行的操作。

本申请实施例提供的方案实现了车端和服务端协同执行目标场景的方式，可充分的利用车端资源和服务端资源，提供更精准、多样的主动服务。

本申请实施例中的服务端可以为云端，下面图8和图9所示实施例以云端为例描述。

图8示出了本申请又一实施例提供的车辆控制方法的流程示意图，该方法的执行主体为图1a或图1b示出的车端，具体实施时，车端11可指的是但不限于：电动车、汽油车、混动车等车辆，具体地，车端11可指的是车辆上具有逻辑运算处理、控制等能力的电控部件，比如，处理芯片（如整车控制器（Vehicle control unit，VCU）），电控部件上部署有图2示出的第一场景引擎，更具体地，该方法是利用第一场景引擎来实现。如图8所示，本实施例提供的所述车辆控制方法包括如下步骤：

301、确定所述车端当前所处的目标场景，所述目标场景对应可执行的多个操作；

302、执行所述多个操作中的第一操作，以控制至少一个第一车端功能部件工作；

303、接收云端发送的控制指令，根据所述控制指令控制至少一个第二车端功能部件工作；所述控制指令是所述云端执行所述多个操作中的第二操作生成的，所述第二操作为所述目标场景对应的多个操作中所述车端无法执行的操作。

上述301是可选步骤，即目标场景可以是车端根据监测到的数据信息来确定的，其中，监测到的数据信息可包括但不限于与服务对象相关的数据、车辆检测到的环境数据、车辆数据等。有关上述各种数据可包括的具体内容、以及车端根据上述监测到的数据信息确定目标场景的具体实现，可参见上文本申请其他实施例中相关的内容，比如可参见图4示出的实施例中与步骤100相关的内容。

当然，在其他实例中，目标场景也可以是由云端根据获取到的数据信息确定的，这种情况下车端不执行上述301。云端获取到的数据信息可包括但不限于第三方数据（如气象数据、车辆定位信息（可由车辆上安装的第三方定位应用（如导航应用）提供））、车辆历史数据、以及从车端接收到的数据信息等。同样的，云端确定目标场景的具体实现，也可参见与图4示出的实施例中步骤100相关的内容。

云端确定出目标场景后，可先在本地执行目标场景对应的多个操作，当在执行过程中监测到无法执行的操作时，自无法执行的操作处中断执行并向车端发送调度信息。车端根据接收到的云端发送的调度信息，可获取目标场景的标识，从而基于目标场景的标识来确定当前所处的目标场景。有关云端发送调度信息以及车端根据调度信息获取目标场景的标识的具体实现，可参见本申请其它实施例中相关的内容，此处不再作赘述。

需说明的是，上述云端中的“云”是由基于云计算（Cloud Computing）的大量主机或网络服务器构成，由此，云端可指的是基于云计算的计算机集合；其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。云端与车端之间可通过移动网络（如4G、5G等）通信。

上述302中，在一实例中，上述第一操作与上文图4或图6所示本申请其它实施例中所述的“第一操作”，可不相同。

例如，参见图9，假设一目标场景对应的多个操作包括：操作11、操作12、.....、操作1x、.....、操作1n，其中，明确示出的操作11、操作1x为需在云端才能够完成执行的操作，操作12为需在车端才能够完成执行的操作。在该示例中此目标场景是由云端确定，云端针对确定出的此目标场景会先在本地执行，当在执行过程中监测到无法执行的操作12时，便会在操作12处中断执行，并交由车端自操作12处接续执行，这种情况下，操作12便为车端执行的多个操作中的第一操作，即也就是说，车端所执行的多个操作中的第一操作（如操作12）是从云端接续过来的，为云端无法执行但车端能够执行的操作。而在上文图4或图6所示本申请其它实施例中所述的第一端为车端的情况下，图4或图6所示实施例中所描述的“第一操作”为车端无法执行的操作，如可为操作11。

基于上述示例，一种可实现方案中，上述执行所述多个操作中的第一操作，可具体包括：

3021、接收所述服务端发送的第二调度信息，所述第二调度信息用于指示所述服务端在所述第一操作处中断执行；

3022、响应于所述服务端发送的第二调度信息，自所述多个操作中所述第一操作处接续执行。

有关上述3021~3022的具体实现描述，可参见本申请其它实施例中相关内容。

若第一操作关联有至少一个第一车端功能部件，第一操作的执行结果可以是控制对应的该至少一个第一车端功能部件工作。例如，车端可以根据第一操作控制该至少一个第一车端功能部件工作，以提供该至少一个第一车端功能部件对应的功能服务。例如，第一操作关联的车辆功能部件为氛围灯，车端可以根据第一操作生成相应的控制信号，通过控制信号来控制氛围灯切换到适配的氛围模式。若第一操作未关联有车端功能部件，则该第一操作的执行结果，可以是作为与其存有逻辑关系的操作的输入。

在另一实施例中，上述第一操作与上文图4或图6所示本申请其它实施例中所述的“第一操作”，也可以相同。例如，若第一端为云端、第二端为车端，则图4或图6所示实施例中第一操作是云端无法执行，需要由车端接续执行的操作，则该第一操作便可与在上文本申请其它实施例中所述的“第一操作”相同，即都为车端执行的操作（如图9示出的操作12）。

上述303中，第二操作为服务端可执行但车端无法执行的操作。控制指令可以是在服务端在确定第二操作关联有至少一个第二车端功能部件的情况下，基于执行第二操作所得的执行结果生成的。

例如，继续参见图9，假设操作1x为云端可执行但车端无法执行的操作，具体地，操作1x为：为车辆推荐附近的充电桩，并在车端上进行显示；相应地，操作11关联的车端功能部件为车端上的交互装置，如中控。车端监测到操作1x无法执行，在操作1x处中断执行，并向云端发送调度信息。云端根据接收到的调度信息，自操作1x处接续车端执行操作11至操作1n中未被执行的操作；操作1x执行完成后，会生成一控制指令，其中，控制指令用于控制车辆上的交互装置对搜索到的位于车辆附近的充电桩进行显示；进一步地，云端将所生成的控制指令下发至车端。车端根据接收到的控制指令便会控制交互装置工作，在交互装置提供的交互界面上展示出车端附近的充电桩。

这里需要补充说明的是，本步骤中的第二车端功能部件与上述步骤302中所述的第一车端功能部件可能相同，也可能不同，本实施例对此不作限定。另外，同上述301中的第一操作，在一实例中，本步骤302中的第二操作与上文本申请其它实施例中所描述的“第二操作”可不相同，例如，本步骤302中的第二操作为云端可执行但车端无法执行的操作，而在上文本申请其它实施例中所述的第一端为车端、第二端为云端的情况下，上文本申请其它实施例中所描述的“第二操作”为云端无法执行但车端可执行的操作，如可为操作11。在另一实施例中，本步骤302中的第二操作与上文本申请其它实施例中所描述的“第二操作”，也可相同，例如，在上文本申请其它实施例中所述的第一端为云端、第二端为车端的情况下，上文其它实施例中所述的“第二操作”为车端无法执行但云端可执行的操作，这种情况下便可能与本并步骤302中所述的第二操作相同。

基于上述示例，在上述接收云端发送的控制指令之前，本实施例提供的所述方法还可包括如下步骤：

S41、在执行所述多个操作过程中监测到无法执行的第二操作时，在所述第二操作处中断执行；

S42、向所述云端发送第一调度信息，以调度所述远端自所述第二操作处接续所述车端执行所述多个操作中未被执行的操作。

有关上述S41~S42的具体实现描述，可参见上文本申请其它实施例中相关的内容。

这里需要补充说明的是，有关上述步骤302~303的执行顺序，本实施例对此不作限定。本实施例中提供的车辆控制方法除了可包括上述所述的步骤之外，还可包括其它步骤。有关本实施例提供的车辆控制方法中还可包括的其它步骤，可参见本申请其它实施例中相关的内容，此处不再作具体赘述。

下面以第一端为车端，第二端为云端为例，对本申请各实施例提供的技术方案进行说明。在如下各应用举例中，将结合各端场景引擎进行描述。

应用举例1

目标场景A为：推荐目的地附近充电桩

触发条件：车端执行路线规划

目标场景A对应如下多个操作：

操作31：判断目的地是否为用户固定使用充电桩所在地址，若是，退出目标场景A；否则，执行操作32。

操作32：获取车辆电池剩余电量、路线规划距离及车端存储的历史数据。

操作33：根据所述剩余电量、路线规划距离及历史数据，预测用户是否有充电意愿或车辆到达目的地是否有必要充电，若用户有意愿充电或车辆有必要充电，则执行操作34；否则，退出目标场景A。

操作34：获取距目的地预设距离范围内充电桩信息。

其中，所述充电桩信息可包括：充电桩位置信息、充电桩当前是否在使用，充电桩在车辆到达时段是否还运营，充电桩使用价格等等。

操作35：过滤掉使用中的充电桩、过了营业时间的充电桩、不对外运营的充电桩等等，得到可用充电桩；若可用充电桩为多个，则执行操作36；否则执行操作37。

操作36：若可用充电桩数量为多个，则按照距离目的地远近、价格等对多个可用充电桩进行排序。

操作37：通过扬声器和/或显示屏，播放和/显示目的地附近至少一个可用充电桩。

该目标场景A的执行过程具体为：驾驶员在车辆上的触摸屏上输入“####大厦”，并点击“导航”后，车端响应于驾驶员的点击操作，以当前位置为起点，“####大厦”为目的地，执行路线规划。同时，车端的第一场景引擎监测到路线规划事件，触发执行上述目标场景A。车端的第一场景引擎启动执行操作31。若“####大厦”不是用户固定使用充电桩所在地，则执行操作32、操作33。若车端的第一场景引擎预测用户有意愿充电或车辆有必要充电，则执行操作34。车端的第一场景引擎触发执行操作34，在执行过程中监测到执行操作34需使用云端数据，自身无法执行操作34。此时，车端第一场景引擎中断目标场景A的执行，并基于操作34，标记中断位置；然后根据所述中断位置，向云端发送调度信息。云端接收到该调度信息后，基于调度信息中携带的中断位置，确定车端执行的场景为上述目标场景A，且在操作34处中断。云端第二场景引擎启动执行目标场景A，并将操作34作为起始操作执行。云端第二场景引擎顺利执行完操作34、执行35和36后，将排序后的多个可用充电桩信息或一个可用充电桩信息转换为语音信息和/或文本信息，发送至车端。车端接收到云端发送语音信息和/或文本信息后，执行操作37，以通过扬声器和/或显示屏播放和/或显示至少一个可用充电桩。

后续用户便可从中选择一个可用充电桩，车端以该可用充电桩所在位置作为目的地，重新操作导航路径。

应用举例2

目标场景B为：雨天推荐适于雨天听的歌曲

触发条件：获取到下雨信息

目标场景B对应如下多个操作：

操作41：获取处于下雨范围的**区域内行驶的车辆，得到多个目标车辆。

操作42：获取所述多个目标车辆的数据信息。

操作43：基于各目标车辆的数据信息，预测各目标车辆对应驾乘人员是否有意愿接受雨天歌曲推荐；将预测结果为有意愿接受雨天歌曲推荐的车辆作为待推荐车辆。

操作44、搜索音乐库，以得到雨天适合听的多个歌曲，并生成歌曲列表。

操作45、根据歌曲列表生成交互信息。

操作46：基于交互信息，采用语音、文本和/或视频动画等询问是否要听雨天适合听的歌曲列表，若接收到用户要听的交互信息，则获取所述歌曲列表对应的流媒体信息，并进行播放。

操作47：检测到有雨滴时，关闭门窗、天窗等；打开雨刷器。

该目标场景B的执行过程具体为：云端收集天气信息，其中，信息源可以是网络侧或天气检测装置等等。云端基于天气信息确定**区域下雨时，触发执行上述目标场景B。云端的第二场景引擎启动执行操作41，以获取**区域内行驶的车辆。云端的第二场景引擎在执行所述操作41时，可获取车辆的定位信息，然后根据定位信息确定出在**区域内行驶的车辆。这里需要说明的是：车辆的定位信息需车端上传。接入网络的车辆在启动后，可通过询问的方式询问是否能获取车辆实时位置；若用户确认可以获取实时位置，云端便可在车辆启动并成功接入网络后，获取到车端自动上传的实时定位信息。本目标场景B适用于那些可被允许能获取实时位置的车辆。

云端的第二场景引擎执行完41，执行操作42以获取多个目标车辆的数据信息。目标车辆的数据信息可包括：驾乘人员的喜好信息（如用户画像信息），目标车辆历史时段产生的数据（如接受推荐场景的情况等）等等。这些数据信息可从云端侧的相应数据库中获取。获取到各目标车辆的数据信息后，云端的第二场景引擎执行操作43，以锁定有意愿接受雨天歌曲推荐的车辆作为待推荐车辆。然后，云端的第二场景引擎执行操作44时，可从云端音乐库中搜索以得到雨天适合听的多个歌曲，并生成歌曲列表。然后再执行操作45，以基于歌曲列表生成交互信息，将交互信息下发至待推荐车辆。云端的第二场景引擎在执行操作46时，监测到该操作46需使用到车端资源，如交互装置（如扬声器、显示屏等），无法执行。此时，云端的第二场景引擎中断目标场景B的执行，并基于操作46，标定中断位置。随后，根据中断位置向车端发送调度信息。

车端的第一场景引擎接收到该调度信息后，确定云端中断执行的场景是目标场景B，且中断位置为操作46。此时，车端的第一场景引擎启动执行目标场景B，并将操作46作为起始操作开始执行。车端的第一场景引擎执行操作46和47。

综上，本申请提供的技术方案具有以下几点有益效果：

1、支持车端和云端协同的场景执行模式，场景的执行过程可以在车端和云端之间流转，充分利用了车端和云端的数据和计算能力；

2、能够支持更丰富、更灵活的场景的执行，一个场景定义里面可以融合车端和云端的事件和能力；

3、支持更灵活的场景编排，场景编排的时候，可以忽视车端和云端的差异，灵活组合不同的操作。

这里需要补充说明的是，本申请提供的技术方案，除了适用于上文所述的车联网领域下的场景执行之外，还可适用于其他非车联网领域下的场景执行，比如商品推荐领域。

图10示出了本申请一实施例提供一个电子设备的结构示意图。如图10所示，所述电子设备包括：存储器41以及处理器42。其中，所述存储器41用于存储一条或多条计算机指令；所述处理器42，与所述存储器41耦合，用于一条或多条计算机指令（如实现数据存储逻辑的计算机指令），以用于实现上述各车辆方法实施例中的步骤。

若所述电子设备为车端设备或服务端设备，所述处理器执行一条或多条计算机指令，用于实现上述各车辆控制方法实施例中的步骤。

存储器41可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步，如图10所示，电子设备还可包括：通信组件43、电源组件44及音频组件45等其它组件。图10中仅示意性给出部分组件，并不意味着电子设备只包括图10所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例提供的车辆控制方法中步骤或对应功能。

图11示意性地示出了本申请提供的一计算机程序产品的框图。所述计算机程序产品包括计算机程序/指令51，当所述计算机程序/指令51被诸如图10所示的处理器42之类的处理器执行时，可实现上文所描述的车辆控制方法中的各个步骤。计算机程序/指令可以被加载到车端或服务端上，车端或服务端执行所述计算机程序/指令时，全部或部分地执行本申请各实施例所述的流程或功能。

通过以上实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。

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

Claims (17)

1.一种车辆控制方法，其特征在于，适于第一端，所述方法包括：

确定目标场景，所述目标场景对应可执行的多个操作；

执行所述多个操作；

在执行所述多个操作过程中监测到无法执行的第一操作时，在所述第一操作处中断执行；

向第二端发送第一调度信息，以调度所述第二端自所述第一操作处接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务；所述第一操作是所述多个操作中的一个操作。

2.根据权利要求1所述的方法，其特征在于，还包括如下中至少一项：

确定执行所述第一操作依赖的资源，判断所述第一端的可用资源与所述第一操作依赖的资源是否适配，若不适配，则无法执行所述第一操作；

若监测到所述第一端故障，则无法执行所述第一操作。

3.根据权利要求2所述的方法，其特征在于，执行所述第一操作依赖的资源包括如下中的至少一项：

执行第一操作依赖的数据、执行所述第一操作依赖的硬件配置、执行所述第一操作依赖的计算模型。

4.根据权利要求1至3中任一项所述的方法，其特征在于，向第二端发送第一调度信息，包括：

获取所述目标场景的场景标识及所述第一操作的操作标识；

基于所述目标场景的场景标识和所述第一操作的操作标识，生成所述目标场景对应的中间执行状态信息；

根据所述中间执行状态信息，向所述第二端发送所述第一调度信息。

5.根据权利要求4所述的方法，其特征在于，根据所述中间执行状态信息，向所述第二端发送所述第一调度信息，包括：

对所述中间执行状态信息进行编码，得到所述第一调度信息；

向所述第二端发送所述第一调度信息。

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

响应于所述第二端发送的第二调度信息，确定所述目标场景对应的第二操作；

自所述第二操作处重启执行，以接续所述第二端执行所述多个操作中未被所述第一端和所述第二端执行的操作；

其中，所述第二调度信息是所述第二端自所述第一操作处接续所述第一端执行所述多个操作中未被执行的操作过程中监测到无法执行的第二操作时发送的；

所述第二操作是所述多个操作中的一个操作。

7.根据权利要求1至3中任一项所述的方法，其特征在于，确定目标场景，包括：

获取数据信息，其中，所述数据信息包括车辆数据、与服务对象相关的数据、车辆所处环境的环境数据中的至少一项；

基于所述数据信息，确定至少一个适配的场景；

从所述至少一个适配的场景中，选定所述目标场景。

8.一种车辆控制方法，其特征在于，适于第二端，所述方法包括：

响应于接收到第一端发送的第一调度信息，确定目标场景对应的第一操作；其中，所述目标场景对应可执行的多个操作，所述第一操作为所述多个操作中的一个操作；

自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一调度信息是所述第一端在执行所述多个操作过程中监测到无法执行的所述第一操作时发送的；

所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述多个操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务。

9.根据权利要求8所述的方法，其特征在于，响应于第一端发送的第一调度信息，确定目标场景对应的第一操作，包括：

根据所述第一调度信息，获取所述目标场景对应的中间执行状态信息；

基于所述中间执行状态信息，确定所述目标场景对应的第一操作。

10.根据权利要求9所述的方法，其特征在于，根据所述第一调度信息，获取所述目标场景对应的中间执行状态信息，包括：

对所述第一调度信息进行解码，得到所述中间执行状态信息；

其中，所述中间执行状态信息包括所述目标场景的场景标识和所述第一操作的操作标识。

11.根据权利要求10所述的方法，其特征在于，自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作，包括：

根据所述目标场景的场景标识，调取所述目标场景对应的多个操作；

基于所述第一操作的操作标识，所述多个操作中获取所述第一操作，并将所述第一操作作为重启执行的起始操作；

利用所述第二端的资源，自所述起始操作起执行所述多个操作中未被执行的操作。

12.一种车辆控制系统，其特征在于，包括：

第一端，用于确定目标场景，所述目标场景对应可执行的多个操作；执行所述多个操作；在执行所述多个操作过程中监测到无法执行的第一操作时，在所述第一操作处中断执行，并向第二端发送第一调度信息；

第二端，用于响应于所述第一调度信息，确定所述目标场景对应的所述第一操作；自所述第一操作处重启执行，以接续所述第一端执行所述多个操作中未被执行的操作；

其中，所述第一端和所述第二端中的一个为车端，另一个为服务端；执行所述目标场景中的操作能控制车辆上至少一个功能部件工作，以提供所述目标场景对应的场景化服务；所述第一操作是所述多个操作中的一个操作。

13.一种车辆控制方法，其特征在于，适于车端，所述方法包括：

执行所述车端当前所处的目标场景对应的多个操作中的第一操作，以控制至少一个第一车端功能部件工作；

接收服务端发送的控制指令，根据所述控制指令控制至少一个第二车端功能部件工作，所述控制指令是所述服务端执行所述多个操作中的第二操作生成的，所述第二操作为所述目标场景对应的多个操作中所述车端无法执行的操作。

14.根据权利要求13所述的方法，其特征在于，在所述接收服务端发送的控制指令之前，所述方法还包括：

在执行所述多个操作过程中监测到无法执行的第二操作时，在所述第二操作处中断执行；

向所述服务端发送第一调度信息，以调度所述服务端自所述第二操作处接续所述车端执行所述多个操作中未被执行的操作。

15.根据权利要求13或14所述的方法，其特征在于，所述执行所述多个操作中的第一操作，包括：

接收所述服务端发送的第二调度信息，所述第二调度信息用于指示所述服务端在所述第一操作处中断执行；

响应于所述服务端发送的第二调度信息，自所述多个操作中所述第一操作处接续执行。

16.一种电子设备，其特征在于，包括：存储器和处理器，其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于实现如权利要求1至7中任一项所述车辆控制方法中的步骤，或实现如权利要求8至11中任一项所述车辆控制方法中的步骤，或实现如权利要求13至15中任一项所述车辆控制方法中的步骤；

所述电子设备为车端设备或服务端设备。

17.一种计算机程序产品，包括计算机程序/指令，其特征在于，当所述计算机程序/指令处理器被执行时用于实现如权利要求1至7中任一项所述车辆控制方法中的步骤，或者实现如权利要求8至11中任一项所述车辆控制方法中的步骤，或实现如权利要求13至15中任一项所述车辆控制方法中的步骤。

Images