技术领域
[0001] 本申请涉及车辆技术领域，尤其涉及一种车辆控制方法、装置、车辆及服务器。
相关背景技术
[0002] 远程控制车辆是一种车联网技术，用户可以通过手机向车辆远程下发开窗、通风等指令。当车辆处于在线状态时，手机中的应用发送指令给云平台，云平台将指令下发给对应车辆，车辆执行相应动作后将结果返回给云平台，云平台再将结果告知应用，形成远程车辆控制的闭环。
[0003] 在现有技术中，当车辆处于离线状态时，需要借助调用第三方的接口，控制车辆进入在线状态之后，执行上述指令的接收、执行、以及返回结果给应用端。
[0004] 然而，上述的实现过程中，极大的增加了远程控制的损耗时间，导致响应效率低下。
具体实施方式
[0065] 为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0066] 在介绍本申请的实施例之前，首先对本申请实施例的应用背景进行解释：
[0067] 远程控制车辆是一种车联网技术，用户可以通过手机向车辆远程下发开窗、通风等指令。当车辆处于在线状态时，手机应用程序(Application，APP)发送指令给云平台，云平台将指令下发给对应车辆，车辆执行相应动作后将结果返回给云平台，云平台再将结果告知APP，形成远程车辆控制的闭环。
[0068] 当车辆处于离线状态时，车辆上的车载通信终端处于休眠状态，无法接收云平台指令。此时当APP下发远程控制指令时，云平台先通过短信的方式唤醒车辆，再下发相应的远程控制指令。
[0069] 例如，图1为本申请实施例提供的现有技术的流程示意图，云平台为执行主体，如图1所示：
[0070] S11，接收用户的远控请求，将远控请求按照目标报文协议进行封装，得到远控指令，并检测车辆是否为离线状态；
[0071] S12，在检测到车辆为离线状态的情况下，缓存远控指令，调用目标服务运营商接口，发送唤醒短信至车辆；
[0072] S13，接收车辆基于唤醒短信由离线状态进入在线状态后生成的登录指令后，发送远控指令至车辆，使得车辆执行远控请求。
[0073] 具体的，图2为本申请实施例提供的现有技术的架构示意图，如图2所示，该架构包括：用户终端(APP)、汽车远程服务提供商(Telematics Service Provider，TSP)平台、网关、运营商、车辆中的车载通信终端(Telematics Box，TBox)、数据库(如，Redis)。
[0074] 其中，TSP平台包括以下组件：应用‑车辆(英文：App‑Vehicle)：用于车辆与APP端的消息转发、远程(英文：Remote)：为TSP平台的远程控制方法、登录状态(英文：Login‑Status)：负责检测车辆在线状态。
[0075] 在一种可能的实现下，车主通过手机APP发起远控请求，该远控请求在App‑Vehicle进行相应的权限校验，然后调用Remote的远控方法，在远控方法中首先调用Login‑Status检测当前车辆状态。
[0076] 接着，在当前车辆状态为在线状态时，则直接将远控请求发送至网关层，在网关层根据不同的远控请求，按照协议进行相应的指令封装，之后将封装好的远控指令发向TBox。
[0077] 在当前车辆状态为离线状态时，则根据用户识别模块(Subscriber Identity Module，SIM)卡号，调用相应的服务运营商接口，进而发送唤醒短信对车辆进行唤醒，TBox在被唤醒之后，以唤醒短信登入的方式登入平台，网关层将唤醒登入报文发送到Login‑Status。该Login‑Status从Redis中获取缓存的没有下发的远控请求，将远控请求发送至网关层，在网关层根据不同的远控请求，按照协议进行相应的指令封装，之后将封装好的远控指令发向TBox。
[0078] 其次，TBox在接收到远控指令后，车辆执行远控请求，并将远控结果回复给TSP平台，其中，消息格式按照协议文档的格式进行封装，包含成功和失败标识，网关层将收到远控结果的成功、失败等状态更新到相应的远控日志的表中，最终可以在TSP平台中进行查看，远控结果事件信号的结果再用消息队列遥测传输(Message Queuing Telemetry Transport，MQTT)的方式推送给手机APP，进行相应的展示更新。
[0079] 本申请实施例需要解决的现有技术存在的问题：当车辆处于离线状态时，车辆联网模组进入休眠状态后，为了重新与车辆取得连接，需要先用短信唤醒模组，模组被唤醒后重新拨号，连接上云平台，唤醒整车，之后才能进行远程控制。这一过程极大增加了远程控制的耗时时间，最终导致远程控制耗时较大，如8秒左右。
[0080] 针对现有技术中存在的技术问题，本申请发明人的构思如下，如果能够保持车辆在一定条件下处于在线状态，便不需要短信拨号唤醒的方式，影响响应效率，此时，可以在检测到车辆处于休眠时，通过车辆中的车载通信终端向汽车远程服务服务器发送心跳包，以使所述车载通信终端与所述汽车远程服务服务器保持连接状态，以上便可以保证用户终端在需要控制车辆时，汽车远程服务服务器可以直接将该指令封装后发送给车辆，以使得车辆执行。该构思可以有效避免汽车远程服务服务器在车辆休眠期间因为太长时间未监测到网络活动而断开连接，从而始终保持车端与汽车远程服务服务器的网络通讯，这一创新点省去了车辆离线状态下被唤醒后重新拨号连接服务器的时间。
[0081] 进一步地，考虑到发送心跳包的方式，还可以设置一些先决条件，降低车辆的能耗，如电池电量的剩余量、整车休眠时长、蓄电池电压、环境温度等等。
[0082] 下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
[0083] 值得说明的是：本公开车辆控制方法、装置、车辆及服务器的应用领域不作限定。
[0084] 图3为本申请实施例提供的车辆控制方法的流程示意图一，如图3所示，该方法以车辆和汽车远程服务服务器(即可以是TSP平台)之间的交互进行介绍，可以包括如下步骤：
[0085] 步骤31、汽车远程服务服务器基于预先配置的第一在线策略，向车辆中的车载通信终端发送用户终端触发的远程控制指令；
[0086] 其中，第一在线策略为车载通信终端以预设频率向汽车远程服务服务器(即MQTT)发送心跳包、以使车载通信终端与汽车远程服务服务器保持连接状态。
[0087] 在本步骤中，第一在线策略，可以认为是车辆通过车载通信终端，如车载通讯模块(即TBox)与TSP平台建立连接后，为了确保连接的稳定性，以预设频率的方式定期向TSP平台发送心跳信号(即心跳包)，一种可能的实现向TSP平台中的消息队列遥测传输(英文简称：MQTT)服务器(英文：Broker)发送，告知车辆处于在线状态。
[0088] 进一步地，由于车辆处于在线状态，当TSP平台接收到来自用户终端(具体可以是终端上安装的车辆的相应服务程序)的远程控制指令之后，可以直接基于MQTT转发至车辆中的车载通信终端。
[0089] 在一种可能的实现中，当用户通过APP下发远程控制指令，该指令首先经过协议封装，发送给TSP云，之后TSP云根据与APP的协议解析出指令后，再将指令根据与车辆的车载通信终端应用的协议封装成报文，通过MQTT Broker发送给Tbox。
[0090] 可选的，预设频率可以是10min/次，具体可以基于实际情况进行调整，即：如果设置的太短，那么TBox需要频繁唤醒发送心跳包，增加休眠时功耗；如果设置的太长，虽然节省功耗，但是TBox如果掉线将无法及时被TSP云感知到，影响正常功能的使用。
[0091] 可选的，远程控制指令可以是：控制空调开启、寻车、自动泊车、自动驶向用户、打开车门、打开后备箱、锁车、座椅加热等等相指令。
[0092] 应理解：汽车远程服务服务器(即TSP平台)可以包括：云端服务和消息队列遥测传输服务(即MQTT)；车辆包括：车载通信终端(即TBox)和整车网络。
[0093] 步骤32、车辆根据远程控制指令，唤醒整车网络，以使车辆执行远程控制指令对应的操作。
[0094] 在本步骤中，车辆在接收到远控指令之后，为了确保指令能够正确、安全地执行，需要先唤醒整车网络，即有助于协调和同步所有相关的系统和模块，确保指令的执行能够顺利完成并避免任何潜在的冲突或故障，之后，根据远程控制指令，控制车辆执行用户终端触发的操作，在一种可能的实现中，可以是远程控制指令对应的域控制器执行相应操作。
[0095] 可选的，TBox可以包括：调制解调器(英文：Modem)和Tbox应用；整车网络包括：多个域控制器。
[0096] 在一种可能的实现中，Tbox中的Modem收到来自TSP云的远程控制指令，首先会唤醒Tbox应用，并将收到的报文传递给Tbox应用，该Tbox应用接收到指令，根据协议解析出原始的远控指令，唤醒整车网络，并将指令发送给车辆对应的域控制器，相应的域控制器执行原始的远控指令。
[0097] 本申请实施例提供的车辆控制方法，应用于车辆和汽车远程服务服务器，其中，汽车远程服务服务器基于预先配置的第一在线策略，向车辆中的车载通信终端发送用户终端触发的远程控制指令，该第一在线策略为车载通信终端以预设频率向汽车远程服务服务器发送心跳包、以使车载通信终端与汽车远程服务服务器保持连接状态；车辆根据远程控制指令，唤醒整车网络，以使车辆执行远程控制指令对应的操作。该技术方案中，车载通信终端以预设频率向汽车远程服务服务器发送心跳包、以使车载通信终端与汽车远程服务服务器保持连接状态，从而可以在用户端发起车辆控制的相应指令时，可以快速通过汽车远程服务服务器转达至车辆端，以实现车辆的高效、低耗时控制。
[0098] 图4为本申请实施例提供的车辆控制方法的流程示意图二，如图4所示，上述步骤中“步骤31：基于预先配置的第一在线策略，通过车辆中的车载通信终端获取汽车远程服务服务器发送的用户终端触发的远程控制指令”可以有以下实现方式，包括步骤41和步骤42。
[0099] 应理解，下述步骤42和步骤43基于实际情况择一执行，步骤43为基于第二在线策略实现：
[0100] 步骤41、车辆和汽车远程服务服务器分别通过车载通信终端获取车辆信息；
[0101] 其中，车辆信息包括至少一项：车辆中高压电池的蓄电数值、车辆当前的休眠时长、车辆中蓄电池的电压数值、以及车辆所处环境温度；
[0102] 在本方案中，在整车休眠之前，车辆中的传感器会采集车辆信息，通过车载数据网络将车辆信息发送给TBox。Tbox会记录数据，并将信息发送给TSP云。
[0103] 之后，Tbox和TSP云会通过这些车辆信息，决定是否采用上述第一在线策略还是下述的第二在线策略。
[0104] 可选的，下述为车辆信息的可能的采集实现：
[0105] 1，车辆中高压电池的蓄电数值：一般指电池的电量或剩余能量，通常由车辆内部的电池管理系统(Battery Management System，BMS)来监控和报告，BMS通过监测电池的电流、电压、温度等参数来估算电池的剩余能量或可用电量；
[0106] 2，车辆当前的休眠时长：车辆停止使用或进入节能模式后的时间长度，车辆的电子系统会记录车辆进入休眠模式的时间点，以及从那时起的累计休眠时长；
[0107] 3，车辆中蓄电池的电压数值：可以直接检测蓄电池的输出电压获取；
[0108] 4，车辆所处环境温度：车辆内部的温度传感器或者气象站传感器来测量，这些传感器通常分布在车辆内部的各个位置，以及外部，例如车辆前部。
[0109] 应理解：上述提及的车辆信息仅为示例，实际场景下可不限于上述。
[0110] 步骤42、若车辆信息中的所有项均符合预设条件，车辆基于第一在线策略，通过车载通信终端获取汽车远程服务服务器发送的远程控制指令；
[0111] 其中，预设条件为：蓄电数值大于第一预设数值、休眠时长小于第二预设数值、电压数值大于第三预设数值、以及环境温度大于第四预设数值。
[0112] 在本步骤中，由于第一在线策略的实现存在车辆的能量使用，为了避免亏电风险，可以在获取到车辆信息之后，以一定的使用条件限定是否使用第一在线策略实现远控指令的一系列执行事件。
[0113] 可选的，对车辆信息与预设条件判断的意义进行逐一说明：
[0114] 1，蓄电数值大于第一预设数值：
[0115] 以高压电池的电池充电状态(State of Charge，SOC)为例，也称为动力电池，由数个电池单体、CSC信息采集系统、电池管理控制单元、电池高压分配单元、冷却系统等组成，是整车最重要的系统之一，作为新能源汽车的动力来源，直接决定了车辆的续航里程，时长等；虽然TBox不由动力电池直接供电，而是由12V蓄电池供电。但12v蓄电池电压过低时，会通过动力电池进行补能，因此，为了减小动力电池负担，只有当动力电池可用容量(即蓄电数值)大于10％(即第一预设数值的示例)时，可以采用第一在线策略。
[0116] 2，休眠时长小于第二预设数值：
[0117] 即，整车休眠时间指从车辆进入休眠状态开始计算的时间间隔，由于TBox的数据来源于整车传感器与整车通信网络，因此在整车休眠时，Tbox无法获取到相关数据，在休眠超过七天(即第二预设数值的示例)后，七天前采集的数据可能和实际状况已有了较大偏差，继续间隔唤醒维持心跳有较大的亏电风险，因此当整车休眠时间在七天之内，可以采用第一在线策略。
[0118] 3，电压数值大于第三预设数值：
[0119] 蓄电池用于整车低压电器及电控系统供电，包括TBox也由蓄电池进行供电，因此，TBox每10分钟唤醒一次维持连接策略，将直接消耗蓄电池中储存的电能，虽然智能补电策略会定时使用动力电池给蓄电池供电。但是当蓄电池电压小于或等于10.8v(即第三预设数值的示例)，相比于正常的12v已经处于一个极低的数值，一旦动力电池供电不及时，或供电机制失效，继续维持心跳策略，会大大增加蓄电池亏电的风险，因此，在电压数值大于第三预设数值时，可以采用第一在线策略。
[0120] 4，环境温度大于第四预设数值：
[0121] 在上述实施例中介绍高压电池SOC与蓄电池时，提到了智能补电，该智能补电，是一种车辆处于休眠状态下动力电池向低压蓄电池充电的策略。当车辆休眠时，车端相关ECU会定期检查12V蓄电池电压，一旦低于一定阈值，将会唤醒整车网络，高压上电，进行补电。这是本申请实施例不会造成蓄电池亏电，以及消耗完蓄电池电量进而影响整车功能的一个重要保障。在蓄电池温度低于一定温度(如‑20℃)时，智能补电策略不执行，因此当休眠前检测到环境温度大于‑18℃(即第四预设数值的示例)时，可以采用第一在线策略。
[0122] 可选的，第一在线策略的实现，即向车载通信终端发送远程控制指令之前，还可以的实现为：
[0123] 第1步、在车辆休眠时，以预设频率唤醒车载通信终端；
[0124] 在该实现中，当车辆休眠时，TBox随之休眠，MQTT服务器长时间检测不到与上述Tbox之间的网络活动，主动断开连接，导致车辆离线，因此，可以使得Tbox会设置一个定时器，当车辆休眠时，以预设频率唤醒Tbox。
[0125] 例如，10min/次。
[0126] 第2步、车载通信终端向汽车远程服务服务器发送心跳包，以使车载通信终端与汽车远程服务服务器保持连接状态；
[0127] 在该实现中，在Tbox被唤醒后，会通过Modem向MQTT服务器发送心跳包，从而避免MQTT服务器因长时间没有收到心跳信号而断开连接。
[0128] 即：Tbox始终都和MQTT服务器保持连接，TSP云可以观察到车辆一直处于在线状态。当APP在车辆休眠时远程下发控制指令，不需要先发短信唤醒，而是直接下发远程控制指令，节约了响应时间。
[0129] 第3步、控制车载通信终端再次进入休眠状态。
[0130] 在该实现中，发送完心跳包后，Tbox再重新进入休眠。
[0131] 应理解：在实际中，车辆通过MQTT服务和TSP云相连，使用MQTT的心跳机制，有以下实现：
[0132] 在通过MQTT，以使车辆连接TSP云时发送的连接报文中，有一个字段keepAlive，该字段用于告知TSP云心跳时间间隔。在建立连接后，如果TSP云没有在一定倍(如1.5倍)的心跳时间间隔内收到车辆发布消息或发来心跳请求，那么TSP云就会认为这个车辆已经掉线。
[0133] 在本申请实施例中，KeepAlive这一字段被设置为600秒，即10分钟(预设频次的示例)。在车辆休眠后，TBox每10分钟唤醒一次发送心跳包以告知TSP云中的MQTT保持连接。如果KeepAlive被设置的太短，那么TBox需要频繁唤醒发送心跳包，增加休眠时功耗。如果KeepAlive设置的太长，虽然节省功耗，但是TBox如果掉线将无法及时被TSP云感知到，影响正常功能的使用。
[0134] 步骤43、若车辆信息中的任一项不符合预设条件，汽车远程服务服务器基于预先配置的第二在线策略，向车载通信终端发送远程控制指令；
[0135] 其中，第二在线策略为汽车远程服务服务器以短信唤醒的方式，使车载通信终端处于在线状态。
[0136] 在本步骤中，在上述判断出存在以下任一项：蓄电数值不大于第一预设数值、休眠时长不小于第二预设数值、电压数值不大于第三预设数值、以及环境温度不大于第四预设数值，则需要通过第二在线策略，向车载通信终端发送远程控制指令。
[0137] 可选的，第二在线策略的实现，即向车载通信终端发送远程控制指令之前，还可以的实现为：调用车辆对应服务运营商接口，以使服务运营商向车辆发送唤醒信息，即短信唤醒；
[0138] 其中，短信唤醒用于使得车辆由离线状态进入在线状态。
[0139] 在该实现中，可以根据SIM卡号，调用相应的服务运营商接口，进而发送唤醒信息对车辆进行唤醒，TBox在被唤醒之后，以唤醒信息登入的方式登入TSP平台，网关层将唤醒登入报文发送到登录状态(即，Login‑Status)。Login‑Status从Redis中获取缓存的没有下发的远程控制指令，将远程控制指令发送至网关层，在网关层根据不同的远程控制指令，按照协议进行相应的指令封装，之后将封装好的远程控制指令发向TBox。
[0140] 本申请实施例提供的车辆控制方法，应用于车辆和汽车远程服务服务器，其中，车辆和汽车远程服务服务器分别通过车载通信终端获取车辆信息；车辆信息包括至少一项：车辆中高压电池的蓄电数值、车辆当前的休眠时长、车辆中蓄电池的电压数值、以及车辆所处环境温度；若车辆信息中的所有项均符合预设条件，车辆基于第一在线策略，通过车载通信终端获取汽车远程服务服务器远程控制指令，预设条件为：蓄电数值大于第一预设数值、休眠时长小于第二预设数值、电压数值大于第三预设数值、以及环境温度大于第四预设数值；若车辆信息中的任一项不符合预设条件，汽车远程服务服务器基于预先配置的第二在线策略，向车载通信终端发送远程控制指令，第二在线策略为汽车远程服务服务器以短信唤醒的方式，使车载通信终端处于在线状态。该技术方案中，以车辆信息来判断执行发送心跳包、还是调用服务运营商接口的方式来实现车辆在线状态的保持，从而避免了车辆存在能耗降低、亏电等情况的发生。
[0141] 在上述实施例的基础上，下述图5、图6和图7为本申请实施例提供的几个具体实施例，不对应用场景作限制，仅为便于理解方案：
[0142] 图5为本申请实施例提供的车辆控制方法的流程示意图三，如图5所示，该方法包括：
[0143] 以用户终端(APP)、TSP云、以及车辆三侧实现说明。
[0144] 车辆：休眠前向TSP云发送整车信息(上述的车辆信息)、以及判断是否存在亏电风险；若是，则休眠，不维持与MQTT的连接(心跳包)，执行短信唤醒的方式；若否，休眠，维持与MQTT的连接，并唤醒TBox；
[0145] TSP云：获取到整车信息后，判断是否存在亏电风险；若是，先不唤醒TBox，等待APP端下发远控指令，之后执行短信唤醒的方式；若否，则当APP下发远控指令后，接收该远控指令；并通过MQTT下发该远控指令给车辆；
[0146] 车辆：在被唤醒以及收到远控指令后，执行远控指令，并获取执行结果，向TSP云返回执行结果，以使TSP云将执行结果发给APP。
[0147] 上述方式的一种具体实现中：在车辆休眠前，会采集整车数据，并通过高压电池SOC，环境温度，蓄电池电压来判断车辆是否存在亏电风险，如果具有亏电风险，TBox不会维持MQTT连接。当休眠超过七天，也不会维持MQTT连接。否则，如前所述，TBox每隔一段时间主动唤醒，发送心跳包，始终维持MQTT连接，车辆也始终在线；同时，整车信息数据也会上传到TSP云，供TSP云使用。通过本方法，最终将车辆休眠状态下的远程控制执行时间其从8秒减少到1.5秒，显著提升了远程的控制车辆方法的即时性和智能性。
[0148] 图6为本申请实施例提供的车辆控制方法的流程示意图四，如图6所示，以远程控制车辆打开空调为例进行说明：
[0149] 在该实施例中，用户首先离车闭锁，一段时间后，车辆进入休眠状态。用户下发打开空调远程控制指令，TSP云通过MQTT唤醒TBox，并将指令传递给TBox。TBox收到远程控制指令，首先下发上高压指令给VGM。在整车中，VGM负责协调不同结构和特征的CAN总线网络及其他数据网络之间的协议转换、数据交换等工作。在本实施例中，VGM会将上高压指令发送给对应的电子控制单元(Electronic Control Unit，ECU)，进而整车被唤醒并上电。
[0150] 上电后，TBox将打开空调指令及其参数下发给VGM，VGM将指令传递给对应的域控制器，域控制器执行指令，并返回结果。最终，远程控制指令结果通过TSP云，返回到用户手机APP上。
[0151] 图7为本申请实施例提供的车辆控制方法的流程示意图五，如图7所示，以远程寻找车辆为例进行说明：
[0152] 在该实施例中，用户首先离车闭锁，一段时间后，车辆进入休眠状态。用户下发远程寻车指令，指令通过TSP云传递给TBox。与图6不同，寻车功能不需要上高压，TBox直接将寻车指令发送给驾驶信息及娱乐主机(Digital Cockpit Head Unit，DHU)。在该车型中，DHU负责传递车载通信与管理控制器(Telematics Control and Management，TCAM)指令给车端。
[0153] 其余部分和图6相同，车辆的域控制器接收指令后执行相应动作并返回结果。
[0154] 图5‑图7所示的技术方案与技术效果，与上述实施例类似，此处不再赘述。
[0155] 下述为本申请提供的装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。
[0156] 图8为本申请实施例提供的车辆控制装置的结构示意图一。如图8所示，该车辆控制装置应用于车辆，包括：
[0157] 获取模块81，用于基于预先配置的第一在线策略，通过车辆中的车载通信终端获取汽车远程服务服务器发送的用户终端触发的远程控制指令；第一在线策略为车载通信终端以预设频率向汽车远程服务服务器发送心跳包、以使车载通信终端与汽车远程服务服务器保持连接状态；
[0158] 处理模块82，用于根据远程控制指令，唤醒整车网络，以使车辆执行远程控制指令对应的操作。
[0159] 在一个或多个实施例中，获取模块81，用于：
[0160] 通过车载通信终端获取车辆信息，车辆信息包括至少一项：车辆中高压电池的蓄电数值、车辆当前的休眠时长、车辆中蓄电池的电压数值、以及车辆所处环境温度；
[0161] 若车辆信息中的所有项均符合预设条件，基于第一在线策略，通过车载通信终端获取远程控制指令，预设条件为：蓄电数值大于第一预设数值、休眠时长小于第二预设数值、电压数值大于第三预设数值、以及环境温度大于第四预设数值。
[0162] 在一个或多个实施例中，获取模块81，还用于：
[0163] 若车辆信息中的任一项不符合预设条件，基于预先配置的第二在线策略，通过车载通信终端获取远程控制指令；第二在线策略为汽车远程服务服务器以短信唤醒的方式，使车载通信终端处于在线状态。
[0164] 在一个或多个实施例中，在通过车辆中的车载通信终端获取汽车远程服务服务器发送的用户终端触发的远程控制指令之前，处理模块82，还用于：
[0165] 在车辆休眠时，以预设频率唤醒车载通信终端；
[0166] 车载通信终端向汽车远程服务服务器发送心跳包，以使车载通信终端与汽车远程服务服务器保持连接状态；
[0167] 控制车载通信终端再次进入休眠状态。
[0168] 本申请实施例提供的车辆控制装置，可用于执行上述执行主体为车辆的任一实施例中的车辆控制方法，其实现原理和技术效果类似，在此不再赘述。
[0169] 图9为本申请实施例提供的车辆控制装置的结构示意图二。如图9所示，该车辆控制装置应用于汽车远程服务服务器，包括：
[0170] 发送模块91，用于基于预先配置的第一在线策略，向车辆中的车载通信终端发送用户终端触发的远程控制指令，以使车辆执行远程控制指令对应的操作；第一在线策略为车载通信终端以预设频率向汽车远程服务服务器发送心跳包、以使车载通信终端与汽车远程服务服务器保持连接状态。
[0171] 在一个或多个实施例中，发送模块91，还用于：
[0172] 获取车载通信终端发来的车辆信息，车辆信息包括至少一项：车辆中高压电池的蓄电数值、车辆当前的休眠时长、车辆中蓄电池的电压数值、以及车辆所处环境温度；
[0173] 若车辆信息中的任一项不符合预设条件，基于预先配置的第二在线策略，向车载通信终端发送远程控制指令；预设条件为：蓄电数值大于第一预设数值、休眠时长小于第二预设数值、电压数值大于第三预设数值、以及环境温度大于第四预设数值，第二在线策略为汽车远程服务服务器以短信唤醒的方式，使车载通信终端处于在线状态。
[0174] 在一个或多个实施例中，在向车载通信终端发送远程控制指令之前，发送模块91，还用于：
[0175] 调用车辆对应服务运营商接口，以使服务运营商向车辆发送唤醒信息，唤醒信息用于使车辆由离线状态进入在线状态。
[0176] 本申请实施例提供的车辆控制装置，可用于执行上述执行主体为汽车远程服务服务器的任一实施例中的车辆控制方法，其实现原理和技术效果类似，在此不再赘述。
[0177] 需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。此外，这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
[0178] 图10为本申请实施例提供的电子设备的结构示意图，如图10所示，该电子设备可以是车辆或汽车远程服务服务器。
[0179] 该电子设备包括：处理器101、存储器102及存储在所述存储器102上并可在处理器101上运行的计算机程序指令，所述处理器101执行所述计算机程序指令时实现前述任一实施例提供的方法。
[0180] 可选的，该电子设备的上述各个器件之间可以通过系统总线连接。
[0181] 存储器102可以是单独的存储单元，也可以是集成在处理器101中的存储单元。处理器101的数量为一个或者多个。
[0182] 应理解，处理器101可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器101、数字信号处理器101(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)等。通用处理器101可以是微处理器101或者该处理器101也可以是任何常规的处理器101等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器101执行完成，或者用处理器101中的硬件及软件模块组合执行完成。
[0183] 系统总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。存储器102可能包括随机存取存储器102(random access memory，RAM)，也可能还包括非易失性存储器102(non‑volatile memory，NVM)，例如至少一个磁盘存储器102。
[0184] 实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一可读取存储器102中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储器102(存储介质)包括：只读存储器102(read‑only memory，ROM)、RAM、快闪存储器102、硬盘、固态硬盘、磁带(英文：magnetic tape)、软盘(英文：floppy disk)、光盘(英文：optical disc)及其任意组合。
[0185] 本申请实施例提供的电子设备，在为车辆时可用于执行上述车辆相关的任一方法实施例提供的方法，在为汽车远程服务服务器时可用于执行上述汽车远程服务服务器相关的任一方法实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。
[0186] 本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述方法。
[0187] 上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器，电可擦除可编程只读存储器，可擦除可编程只读存储器，可编程只读存储器，只读存储器，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。
[0188] 可选的，将可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific Integrated Circuits，ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。
[0189] 本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中，至少一个处理器可以从该计算机可读存储介质中读取该计算机程序，所述至少一个处理器执行所述计算机程序时可实现上述方法。
[0190] 应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。
