CN114138303A - 一种车辆应用程序更新方法、装置、介质及车辆 - Google Patents

Abstract

本公开关于一种车辆应用程序更新方法、装置、介质及车辆，方法包括：基于接收到服务器发送的更新请求确定对应应用程序的更新时长；在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于用车时段预测模型中的时序预测组件得到车辆使用时序列；车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，车辆使用时序列包括多个相邻的时间点，各个时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；若时间间隔大于更新时长，则执行应用程序的更新。本文的实施提高车辆应用程序程序的实效性，避免在用户需要使用车辆时对车辆应用程序进行更新，提高用户体验。

Description

一种车辆应用程序更新方法、装置、介质及车辆

技术领域

本公开涉及车辆中应用程序更新技术领域，尤其涉及一种车辆应用程序更新方法、装置、车辆及系统。

背景技术

车辆应用程序的更新越来越普及，车企可以通过空中下载技术(OTA，Over-the-Air Technology)完成应用程序的更新，以快速修复系统缺陷、快速迭代、提升产品和使用体验、节约用户和车企双方的时间和金钱。但汽车OTA升级和手机、电脑的系统升级还不一样，汽车的OTA升级比较耗时，这个耗时主要是车内CAN网络传输速率慢以及刷写需要时间，汽车OTA升级通常是以小时来计算的，升级的控制器越多升级时间也就越长。通常汽车OTA升级过程中，汽车处于不可用的状态，因此，在要给汽车进行升级时，汽车以及环境的稳定性非常重要，需要选择合适的时间、地点下进行升级。

发明内容

第一方面，本公开提供一种车辆应用程序更新方法，所述方法包括：

基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

基于获取的车辆状态数据确定车辆是否处于驻车状态；

在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

进一步地，所述方法还包括：

若所述时间间隔小于所述更新时长，则在所述车辆使用时序列中选取连续的停放标签对应的时间间隔大于所述更新时间的时间段作为更新时段；

在所述更新时段且车辆处于驻车状态时，执行所述应用程序的更新。

进一步地，所述车辆历史行为数据还包括与所述历史停车行为对应的停车地点；所述用车时段预测模型还包括：位置预测组件；

所述方法还包括：

将所述停车地点输入至预先建立的用车时段预测模型中，基于所述位置预测组件得到携带有目标停车地点的车辆使用时序列，所述目标停车地点与所述停放标签对应；

相应的，所述执行所述应用程序的更新包括，所述方法包括：

获取车辆的当前位置，并判断所述当前位置与所述当前时间对应的目标停车地点是否相同；

在所述当前位置与所述当前时间对应的目标停车地点相同时，执行所述应用程序的更新。

进一步地，所述方法还包括：

所述当前位置与所述当前时间对应的目标停车地点不相同，则在所述更新时段、车辆处于驻车状态且车辆停车位置与所述更新时段对应的目标停车地点相同时，执行所述应用程序的更新。

进一步地，所述用车时段预测模型的训练过程包括：

获取多个时间周期的车辆样本使用时序列，所述车辆样本使用时序列包括多组所述样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段，所述样本停车行为对应有停车地点；

建立所述用车时段预测模型，其中，所述用车时段预测模型包括：时序预测组件和位置预测组件，所述时序预测组件和位置预测组件均包括多个模型参数；

将多组所述样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段作为所述时序预测组件的输入数据，将下一时间周期的车辆使用时序列作为所述时序预测组件的输出数据，对所述时序预测组件进行训练，调整所述时序预测组件的所述模型参数，直至所述时序预测组件达到预设要求；

将多组所述样本用车行为对应的用车时段、多组所述样本停车行为对应的停车时段以及所述样本停车行为对应有停车地点作为所述位置预测组件的输入数据，将下一时间周期的携带有目标停车地点的车辆使用时序列作为所述位置预测组件的输出数据，对所述位置预测组件进行训练，调整所述位置预测组件的所述模型参数，直至所述位置预测组件达到预设要求。

进一步地，所述更新请求中携带有第一更新标识，所述更新请求是在所述服务器基于监管系统完成待备案信息备案完成的情况下发送的，所述待备案信息包括：第二更新标识；

所述执行所述应用程序的更新，包括：

将所述第一更新标识发送至车辆对应的所述监管系统，以验证所述第一更新标识和所述第二更新标识是否匹配；

接收所述监管系统返回的更新指令，所述更新指令是在所述监管系统验证所述第一更新标识和所述第二更新标识匹配的情况下发送的；

基于所述更新指令下载所述更新请求对应的应用程序更新安装包；

基于所述更新安装包更新对应的应用程序。

进一步地，所述更新安装包携带有第一数据包验证标识；

在接收所述监管系统返回的更新指令时，所述方法还包括：接收所述监管系统返回的与所述第二更新标识关联的第二数据包验证标识：

所述基于所述更新安装包更新对应的应用程序之前，所述方法包括：

验证所述第一数据包验证标识和所述第二数据包验证标识是否匹配；

相应的，所述基于所述更新安装包更新对应的应用程序是在所述第一数据包验证标识和所述第二数据包验证标识匹配时更新的。

另一方面，本发明提供一种车辆应用程序更新装置，所述装置包括：

更新时长确定模块，用于基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

驻车状态判断模块，用于基于获取的车辆状态数据确定车辆是否处于驻车状态；

车辆使用时序列预测模块，用于在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

更新时长判断模块，用于判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

更新模块，用于若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

另一方面，本发明提供一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如上述所述车辆应用程序更新方法。

另一方面，本发明提供一种车辆，所述车辆设置有车辆应用程序更新装置，所述装置包括：

更新时长确定模块，用于基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

驻车状态判断模块，用于基于获取的车辆状态数据确定车辆是否处于驻车状态；

车辆使用时序列预测模块，用于在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

更新时长判断模块，用于判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

更新模块，用于若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

本公开的实施例提供的技术方案至少带来以下有益效果：

本说明书实施例提供的一种车辆应用程序更新方法、装置、介质及车辆，在车辆中应用程序更新时，可以根据车辆的历史行为数据对车辆的使用时段和停用时段进行预测，进而确定出车辆使用时序列，并在当前时间与首个占用标签对应的时间点的时间间隔更新时长时，对应用程序进行更新，提高车辆应用程序程序的实效性，避免在用户需要使用车辆时对车辆应用程序进行更新，提高用户体验，同时本公开提出的车辆应用程序更新方法无需用户确认，可做到用户无感更新，提高应用程序更新的及时性，避免车辆使用历史版本的应用程序所引起的安全隐患，进而提高了车辆的安全性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种应用环境的示意图；

图2是根据一示例性实施例示出的一种车辆应用程序更新方法的流程图；

图3是根据一示例性实施例示出的另一种车辆应用程序更新方法的流程；

图4是根据一示例性实施例示出的一种车辆应用程序更新装置框图；

图5是根据一示例性实施例示出的一种用于车辆应用程序更新的电子设备的框图。

具体实施方式

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

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

请参阅图1，图1是根据一示例性实施例示出的一种应用环境的示意图，该应用环境可以包括终端110(车辆)、服务器120(车企)和监管系统130，该终端110、服务器120和监管系统130两两之间可以通过有线网络或者无线网络连接。

终端110包括智能手机、台式电脑、平板电脑、笔记本电脑、数字助理、智能可穿戴设备等类型的实体设备，也可以包括运行于实体设备中的软件，如应用程序(Application，简称为App)，该应用程序可以是专门提供用于控制车辆行驶的应用程序，也可以是具有控制车辆行驶的其他应用程序，例如配置有如动力系统、制动系统的应用程序等。本申请实施例中实体设备上运行的操作系统可以包括但不限于安卓系统、IOS系统、linux、Unix、windows等。终端110可以包括UI(User Interface，车辆应用程序更新对象界面)层，终端110通过UI层对外提供查询信息的输入及显示，另外，基于API(Application ProgrammingInterface，应用程序接口)将相应的信息发送给服务器120和/或监管系统130。

服务器120可以是为终端110中的应用程序提供后台服务的服务器，具体的，服务器120提供的服务可以是应用程序的更新服务。服务器120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

监管系统130可以是设定的用于监管车企(服务器)的第三方平台或机构，其与服务器120的配置相似，均是为终端110中的应用程序提供后台服务的服务器。可以理解的是，监管系统130可以是作为数据存储和数据验证的服务器。

第一方面，本说明书实施例以终端为执行主体介绍本公开，图2是根据一示例性实施例示出的一种车辆应用程序更新方法的流程图，如图2所示，所述方法可以包括以下步骤：

在步骤S201中，基于接收到服务器发送的更新请求确定对应应用程序的更新时长。

具体的，服务器可以是车辆对应厂商的服务器，该服务器可以在车辆应用程序更新时向车辆发送更新请求，该更新请求可以用于指示车辆更新对应的应用程序。

在一个可选的实施例中，所述更新请求包括：更新安装包的描述信息；

具体的，更新安装包的描述信息可以用于概述应用程序更新的具体内容，如允许应用程序更新的当前版本号和目标版本的版本号、更新安装包的大小、预计更新时长、修改点说明，更新的部件信息，更新涉及的车辆技术参数、车辆系统或功能信息(功能新增、变更、缺陷修复还是改善用户体验等)等信息。

在实际应用中，车辆可以根据上述更新请求的预计更新时长确定出对应应用程序的更新时长。该应用时长可以是其他车辆的实际更新时长确定的。

在步骤S203中，基于获取的车辆状态数据确定车辆是否处于驻车状态。

具体的，车辆状态数据可以包括车辆的速度、车辆电池剩余电量、车辆的当前档位等，其中，当前档位可以是驻车档位、前进档位、后退档位或空挡。

具体的，当车辆的当前档位处于驻车档位且车辆的速度为零时，可以确定车辆处于驻车状态。

在一个可选的实施例中，当车辆的当前档位处于驻车档位、车辆的速度为零且车辆电池剩余电量大于应用程序更新所需的电量时，可以确定车辆处于驻车状态。

在步骤S205中，在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签。

具体的，车辆历史行为数据可以包括历史用车行为对应的用车时段和历史停车行为对应的停车时段。

在实际应用中，车辆历史行为数据可以是预设时间周期内的，预设时间周期内可以是一周。其中，每天的时间可以以10分钟为单位，划分成24*6个时间序列，然后每个时间序列以用户是否用车定义对应的值，如果在用车则记为占用标签，没有用车则记为停放标签。

示例地，如下表所示的某一日的12:00-12:30的历史行为数据。

时间片	值	说明
			12:00-12:10	1	未用车
12:10-12:20	1	未用车
			12:20-12:30	0	用车

按照上述时间片以及对应的车辆使用情况，可以得到，每天的车辆行为数据可形成如下1*144的时间序列向量：V_t：(1,1,1,1,1,0,0,0,1,1…,0,0,0,1,1,1)。

具体的，用车时段预测模型可以是预先训练好的模型。该模型的输入可以是车辆历史行为数据，该模型的输出可以是车辆使用时序列，其中，车辆使用时序列可以是以当前时间为起始点的一天内的车辆使用情况的序列表，如当前时间为12:00，则车辆使用时序列V_d：(1,1,0,1,1,0,0,0,1,1…,0,0,0,1,1,1)。

在一个可选的实施例中，所述用车时段预测模型根据如下方式建立：

获取多个时间周期的车辆样本使用时序列，所述车辆样本使用时序列包括多组所述样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段，所述样本停车行为对应有停车地点；

建立所述用车时段预测模型，其中，所述用车时段预测模型包括：时序预测组件和位置预测组件，所述时序预测组件和位置预测组件均包括多个模型参数；

将多组所述样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段作为所述时序预测组件的输入数据，将下一时间周期的车辆使用时序列作为所述时序预测组件的输出数据，对所述时序预测组件进行训练，调整所述时序预测组件的所述模型参数，直至所述时序预测组件达到预设要求。

在具体的实施过程中，可以建立用车时段预测模型，用车时段预测模型可以包括时序预测组件，所述时序预测组件和位置预测组件均包括多个模型参数，模型参数可以表示约束条件，具体可以根据专家经验等进行设置。可以利用多组样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段，对用车时段预测模型进行模型训练。将多组样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段作为用车时段预测模型的输入，下一时间周期的车辆使用时序列作为所述时序预测组件的输出数据，对时序预测组件中的模型参数进行不断的调整，直至时序预测组件达到预设要求，如：满足预设精度、模型参数调整次数满足预设次数要求，则完成模型训练，具体可以参考机器学习算法如：LSTM(Long Short-Term Memory)长短期记忆网络等进行模型训练。

在步骤S207中，判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长。

具体的，根据上述记载可知，车辆时处于驻车状态的，即当前时间对应的车辆行为数据是停车行为，因此，可以确定车辆使用时序列中的首个时间片对应的标签为停放标签。可以理解的是，相邻时间点之间为上述时间片。

在实际应用中，可以确定出当前时间与首个占用标签对应的时间点确定出上述时间间隔。其中，时间点可以对应有占用标签和/或停放标签，如12:00-12:10为停放标签，12:10-12:20为占用标签，则时间点12:10对应有占用标签和停放标签。

在步骤S209中，若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

具体的，在时间间隔大于更新时长时，表征应用程序能够在车辆停放期间完成更新，进而可以对应用程序的更新。

本说明书实施例提供的车辆应用程序更新方法，在车辆中应用程序更新时，可以根据车辆的历史行为数据对车辆的使用时段和停用时段进行预测，进而确定出车辆使用时序列，并在当前时间与首个占用标签对应的时间点的时间间隔更新时长时，对应用程序进行更新，提高车辆应用程序程序的实效性，避免在用户需要使用车辆时对车辆应用程序进行更新，提高用户体验，同时本公开提出的车辆应用程序更新方法无需用户确认，可做到用户无感更新，提高应用程序更新的及时性，避免车辆使用历史版本的应用程序所引起的安全隐患，进而提高了车辆的安全性。

在上述实施例基础上，本说明书一个实施例中，所述方法还包括：

若所述时间间隔小于所述更新时长，则在所述车辆使用时序列中选取连续的停放标签对应的时间间隔大于所述更新时间的时间段作为更新时段；

具体的，连续的停放标签可以对应有车辆的停车时段。

在实际应用中，可以依次在车辆使用时序列中选取连续的停放标签对应的时间间隔，并在上述时间间隔中选取大于更新时间的时间段作为更新时段。在实际应用中，大于更新时间时间间隔往往会有多个，此时，可以按照时间顺序依次选取更新时段，也可以任意选取。

在所述更新时段且车辆处于驻车状态时，执行所述应用程序的更新。

具体的，在执行应用程序的更新之前，仍需要对车辆的驻车状态进行判断，只有在车辆处于驻车状态且在上述更新时段时执行应用程序的更新。

本说明书实施例在当前时间不能够执行应用程序更新时，可以推荐出满足应用程序更新的更新时段，并在该更新时段执行应用程序的更新，提高应用程序更新的效率，同时避免用户用车时段执行应用程序的更新，从而提高用户好感度。

在上述实施例基础上，本说明书一个实施例中，所述车辆历史行为数据还包括与所述历史停车行为对应的停车地点。

具体的，车辆在历史进行停车时，可以将存储该停车地点，即停车行为对应的停车时段对应有具体的停车地点。

所述方法还包括：

将所述停车地点输入至预先建立的用车时段预测模型中，基于所述位置预测组件得到携带有目标停车地点的车辆使用时序列，所述目标停车地点与所述停放标签对应。

具体的，车时段预测模型还包括：位置预测组件。

具体的，用车时段预测模型可以还可以包括位置预测组件，所述时序预测组件和位置预测组件均包括多个模型参数，模型参数可以表示约束条件，具体可以根据专家经验等进行设置。可以利用多组样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段，对用车时段预测模型进行模型训练。将多组所述样本用车行为对应的用车时段、多组所述样本停车行为对应的停车时段以及所述样本停车行为对应有停车地点作为所述位置预测组件的输入数据，将下一时间周期的携带有目标停车地点的车辆使用时序列作为所述位置预测组件的输出数据，对所述位置预测组件进行训练，调整所述位置预测组件的所述模型参数，直至所述位置预测组件达到预设要求，如：满足预设精度、模型参数调整次数满足预设次数要求，则完成模型训练，具体可以参考机器学习算法如：LSTM(Long Short-Term Memory)长短期记忆网络等进行模型训练。

可以理解的是，用车时段预测模型还可以通过位置预测组件预测出车辆使用时序列中停放标签对应的目标停车地点。该目标停车地点表征车辆经常停放的地方，如家或工作地点。

相应的，所述执行所述应用程序的更新，所述方法包括：

获取车辆的当前位置，并判断所述当前位置与所述当前时间对应的目标停车地点是否相同。

具体的，车辆的当前位置可以通过车辆的定位系统确定出，并将该当前位置传输至车辆的行车电脑，经由行车电脑判断当前位置与当前时间对应的目标停车地点是否相同。

在所述当前位置与所述当前时间对应的目标停车地点相同时，执行所述应用程序的更新。

在上述实施例基础上，本说明书一个实施例中，所述方法还包括：

所述当前位置与所述当前时间对应的目标停车地点不相同，则在所述更新时段、车辆处于驻车状态且车辆停车位置与所述更新时段对应的目标停车地点相同时，执行所述应用程序的更新。

具体的，在当前位置与所述当前时间对应的目标停车地点不相同，说明车辆当前停车位置并不是常用的停车地点，此时，可以在更新时段、车辆处于驻车状态且车辆停车位置与更新时段对应的目标停车地点相同时，执行应用程序的更新。

本说明书实施例提供的车辆应用程序更新方法，通过预先构建用车时段预测模型输出携带有目标停车地点的车辆使用时序列，并通过对获取的当前位置与目标停车地点进行比对，只有在当前位置与目标停车地点相同时，在执行应用程序的更新，有效提高车辆应用程序更新的准确性，避免车辆当前位置与预设的目标停车地点不相同时更新。

在上述实施例基础上，本说明书一个实施例中，所述更新请求中携带有第一更新标识，所述更新请求是在所述服务器基于监管系统完成待备案信息备案完成的情况下发送的，所述待备案信息包括：第二更新标识；

请参阅图3，所述执行所述应用程序的更新，包括：

在步骤302中，将所述第一更新标识发送至车辆对应的所述监管系统，以验证所述第一更新标识和所述第二更新标识是否匹配。

具体的，服务器在对车辆中的应用程序进行更新时，可以将监管系统要求的待备案信息发送给监管系统，待备案信息中可以包括相互关联的第二更新标识、第二数据包验证标识和第二车辆标识。其中，第二更新标识是唯一的，第二更新标识可以用于验证车辆更新的应用程序是否已经备案。第二数据包验证标识可以是应用程序对应的更新安装包的唯一标识，可以是数字签名等，第二数据包验证标识可以用于验证对应的更新安装包是否为服务器提供的。第二车辆标识也可以是唯一的，如车辆型号，可以理解的是该车辆型号是服务器(车企)提供的表征该类型车辆的唯一标识。

在监管系统将接收到的待备案信息存储至区块链节点中后，即表征该待备案信息完成备案，监管系统可以向服务器返回备案完成指令，以指示服务器可以对对应的应用程序下发更新请求，更新请求用于指示车辆对应用程序进行更新。

具体的，更新请求中可以携带有第一更新标识，第一更新标识可以是与备案的第二更新标识相同的标识，也可以是与第二更新标识不同的标识。

可以理解的是，上述第一更新标识、第二更新标识、第二数据包验证标识和第二车辆标识的具体格式在本说明书实施例中不做具体限定，其可以是字符串，如100-132-ad2*等。

可以理解的是，服务器发送更新请求可以采用推送的方式，即服务器可以根据上述车辆标识推送该更新请求。

在一个可选的实施例中，将所述第一更新标识发送至车辆对应的所述监管系统，以验证所述第一更新标识和所述第二更新标识是否匹配，可以包括：在符合预设要求时，将所述第一更新标识发送至车辆对应的所述监管系统。

具体的，预设要求可以是预先设定的，其与车辆的状态数据相关联，当状态数据可以包括车辆的速度、车辆电池剩余电量、与更新请求对应的应用程序的当前版本号时，在车辆的速度为零、车辆电池剩余电量大于预设电量阈值、与更新请求对应的应用程序的当前版本号与更新请求对应的应用程序的目标版本号的差值为预设差值，则可以认定状态数据满足预设要求。其中，车辆的速度用于表征车辆是否在行驶，当车辆行驶时是不能够进行应用程序的更新的，车辆电池剩余电量用于表征其是否能够支撑应用程序的更新，当前版本号用于表征应用程序是否能够执行更新，如当前版本号为1.1.1，目标版本号为1.1.2，则说明该应用程序能够完成更新。

在状态数据满足预设要求时，可以将第一更新标识发送至车辆对应的监管系统，监管系统在接收到第一更新标识后可以将其与备案的第二更新标识进行匹配，第一更新标识和第二更新标识匹配，则说明对应的应用程序对应的更新是已经备案的。在第一更新标识和所述第二更新标识不匹配，则说明该应用程序对应的更新未进行备案，此时可以向对应的车辆返回表征不能够更新的指令，以使得车辆不进行该应用程序的更新。

在步骤304中，接收所述监管系统返回的更新指令，所述更新指令是在所述监管系统验证所述第一更新标识和所述第二更新标识匹配的情况下发送的。

具体的，在监管系统验证所述第一更新标识和所述第二更新标识匹配时，监管系统可以返回更新指令，更新指令表征更新请求对应的应用程序可以进行更新，即更新指令可以用于指示车辆更新更新请求对应的应用程序。

在步骤S306中，接收所述监管系统返回的更新指令，所述更新指令是在所述监管系统验证所述第一更新标识和所述第二更新标识匹配的情况下发送的。

在步骤S308中，基于所述更新指令下载所述更新请求对应的应用程序更新安装包。

具体的，更新请求可以携带有待更新应用程序的更新安装包的下载地址，在接收到更新指令后，车辆可以访问上述下载地址，以下载应用程序更新安装包。

在步骤S310中，基于所述更新安装包更新对应的应用程序。

具体的，车辆可以运行更新安装包，以完成应用程序的更新。

本说明书实施例提供的车辆应用程序更新方法，在车辆中应用程序更新时，车企可以将指定车辆的更新内容发送给对应的监管系统进行备案登记，以明确具体的更新内容、更新的车辆，在备案登记后，车辆进行对应应用程序更新时，可以向监管系统发送对应的第一更新标识，并通过监管系统完成第一更新标识的验证，在验证通过后，车辆才能够对应用程序进行更新，保证了每个车辆中应用程序更新的详细记录，避免车企为了避免召回更新应用程序情况的发生，进而降低了车辆的安全隐患。

在上述实施例基础上，本说明书一个实施例中，所述更新安装包携带有第一数据包验证标识。

具体的，更新安装包是可以更新应用程序的可执行文件，更新安装包可以携带有第一数据包验证标识，第一数据包验证标识可以是数字签名(又称公钥数字签名、电子签章)。数字签名是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。

数字签名，就是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

在接收所述监管系统返回的更新指令时，所述方法还包括：接收所述监管系统返回的与所述第二更新标识关联的第二数据包验证标识。

具体的，监管系统中备案有与第二更新标识关联的第二数据包验证标识。监管系统在返回更新指令时，可以同时将与第二更新标识关联的第二数据包验证标识一并返回。其中第二数据包验证标识是服务器(车企)在备案是提供的。

所述基于所述更新安装包更新对应的应用程序之前，所述方法包括：

验证所述第一数据包验证标识和所述第二数据包验证标识是否相同。

相应的，所述基于所述更新安装包更新对应的应用程序是在所述第一数据包验证标识和所述第二数据包验证标识相同时更新的。

具体的，第一数据包验证标识和第二数据包验证标识中的一个可以是用于签名，另一个用于验证。如，监管系统将第二数据包验证标识用监管系统的私钥加密，与原文一起传送给终端(车辆)。终端(车辆)只有用监管系统的公钥才能解密被加密的第二数据包验证标识，然后用HASH函数对第二数据包验证标识进行处理，与解密的第二数据包验证标识对比。如果相同，则说明收到的第二数据包验证标识是完整的，在传输过程中没有被修改，否则说明第二数据包验证标识被修改过。

本说明书实施例在应用程序进行更新之前，通过监管系统备案的第二数据包验证标识与更新安装包中的第一数据包验证标识进行验证，在匹配成功后才执行应用程序的更新，确保更新应用程序的安全性，避免更新安装包被篡改，造成错误的更新。

在上述实施例基础上，本说明书一个实施例中，所述待备案信息还包括：与所述第二更新标识关联的第二车辆标识。

具体的，第二车辆标识可以与第一车辆标识相同，均可用于表征车辆类型。

在一个可选的实施例中，所述将所述第一更新标识发送至车辆对应的所述监管系统，包括：

将所述第一更新标识和车辆的第一车辆标识发送至车辆对应的监管系统，以使得所述监管系统验证所述第一更新标识和所述第二车辆标识是否匹配，以及验证所述第一更新标识与所述第二更新标识是否匹配。

具体的，第一车辆标识可以是预先植入到车辆中的标识，其可以是车架号等具有唯一性的标识。即第一车辆标识可以对应有第二车辆标识。即车架号可以对应有具体的车辆类型。

监管系统中备案有第二车辆标识以及所属区域内的第一车辆标识，监管系统在接收到第一更新标识和车辆的第一车辆标识后，可以分别验证第一更新标识和第二车辆标识是否匹配验证所述第一更新标识与所述第二更新标识是否匹配。只有在上述两者均匹配时，监管系统才会返回更新指令至对应的终端(车辆)。

相应的，所述监管系统返回的更新指令是在所述监管系统验证所述第一更新标识和所述第二车辆标识匹配，且所述第一更新标识与所述第二更新标识匹配的情况下发送的。

本说明书实施例提供的车辆应用程序更新方法，通过双重验证的方式验证车辆中的应用程序是否满足更新要求，只有在双重验证均通过时，才能够执行对应的应用程序的更新，避免车辆更新错误的应用程序，造成安全事故的发生，同时也进一步提高了车辆应用程序更新的安全性。

在上述实施例基础上，本说明书一个实施例中，所述基于所述更新安装包更新对应的应用程序，包括：

将所述更新安装包存储于第一分区执行更新，当前版本的应用程序存储在第二分区，所述第一分区和所述第二分区均能被读取或调用；

将更新完成后目标版本的应用程序设置为优先被读取或调用。

具体的，终端(车辆)中可以设置有至少两个分区，分别为第一分区和第二分区，第一分区和所述第二分区均能被读取或调用。其中一个分区用于存储更新前的应用程序，另一个分区用于存储更新后的应用程序。即第一分区和第二分区分别作为对方的备份分区。在应用程序更新完成，可以将历史版本的应用程序所在的分区格式化，也可以保留历史版本应用程序，但是在利用应用程序执行相应的任务时，可以使用最新版本的应用程序去执行相应的任务。在更新失败时，仍使用更新前的应用程序执行相应的任务。

本说明书实施例提供的车辆应用程序更新方法，使用双备份的方式执行应用程序的更新，更新成功后可以使用更新后的应用程序执行任务，更新失败后使用更新前的应用程序执行任务，提高应用程序的可靠性，避免应用程序更新失败造成不能够使用该应用程序的场景发生。

在上述实施例基础上，本说明书一个实施例中，所述方法还包括：

更新完成后向所述监管系统和所述服务器发送携带有第一车辆标识的更新完成信息，以使得所述监管系统将接收到的更新完成信息存储在对应的区块链节点中，以使所述服务器将接收到的更新完成信息记录存储，所述更新完成信息包括应用程序更新的内容。

具体的，为了避免更新请求的重复发送或避免部分车辆中的应用程序更新不及时，可以在应用程序更新后，车辆可以将第一车辆标识的更新完成信息发送给监管系统和服务器。

具体的，更新完成信息中可以包括应用程序当前版本和目标版本的版本号信息、更新安装包的大小、实际升级时长、修改点说明，升级的部件信息，升级涉及的车辆技术参数、车辆系统或功能信息(功能新增、变更、缺陷修复还是改善用户体验等)等信息。

监管系统可以按照第一车辆标识将上述更新完成信息存储在区块链中，为第一车辆标识对应的车辆记录更新数据，同时也避免在车辆因为应用程序更新发生事故时，服务器方更改上述更新完成信息，提高用户好感度。

服务器也可以记录上述更新完成信息，并根据第一车辆标识对更新后的车辆添加更新完成标识，便于统计第二车辆标识对应车辆的应用程序的更新情况。并可以在预设时间后对未更新应用程序的车辆再次发送上述更新请求，提高车辆应用程序更新的范围，提高用户体验。

第二方面，以下以监管系统为执行主体介绍本公开，本公开提供一种车辆应用程序更新方法，所述方法包括：

接收服务器发送的待备案信息，所述待备案信息包括：相互关联的第二更新标识、第二数据包验证标识和第二车辆标识；

将所述待备案信息存储至区块链节点中，并向所述服务器返回备案完成指令，使得所述服务器基于所述备案完成指令向第二车辆标识对应的车辆发送携带有第一更新标识的更新请求；

接收车辆发送的第一更新标识；

在验证所述第一更新标识与所述第二更新标识匹配的情况下向车辆发送更新指令，所述更新指令用于指示车辆完成所述第一更新标识对应的应用程序的更新。

在上述实施例基础上，本说明书一个实施例中，所述方法还包括：

向车辆发送与所述第二更新标识关联的第二数据包验证标识。

在上述实施例基础上，本说明书一个实施例中，所述方法还包括：

接收车辆发送的携带有第一车辆标识的更新完成信息；

将所述更新完成信息存储在与所述待备案信息对应的区块链节点中。

由于监管系统侧的方法与上述终端侧的方法相关，已经在上述终端侧公开，其具有终端侧相同的技术效果，不再赘述。

再一方面，本公开提供一种车辆应用程序更新装置，图4是根据一示例性实施例示出的一种车辆应用程序更新装置框图，参照图4，该装置包括：

更新时长确定模块501，用于基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

驻车状态判断模块502，用于基于获取的车辆状态数据确定车辆是否处于驻车状态；

车辆使用时序列预测模块503，用于在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

更新时长判断模块504，用于判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

更新模块505，用于若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

由于车辆应用程序更新装置与前文公开的终端侧的车辆应用程序更新方法的过程相同，技术效果相当，在此不在累述。

再一方面，本公开提供一种车辆，所述车辆设置有车辆应用程序更新装置，所述装置包括：

更新时长确定模块501，用于基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

驻车状态判断模块502，用于基于获取的车辆状态数据确定车辆是否处于驻车状态；

车辆使用时序列预测模块503，用于在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

更新时长判断模块504，用于判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

更新模块505，用于若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

由于该车辆应用程序更新装置与前文公开的在监管系统侧的车辆应用程序更新方法的过程相同，技术效果相当，在此不在累述。

再一方面，本公开提供一种监管系统，所述监管系统设置有车辆应用程序更新装置，所述装置包括：

信息接收模块，用于接收服务器发送的待备案信息，所述待备案信息包括：相互关联的第二更新标识、第二数据包验证标识和第二车辆标识；

备案模块，用于将所述待备案信息存储至区块链节点中，并向所述服务器返回备案完成指令，使得所述服务器基于所述备案完成指令向第二车辆标识对应的车辆发送携带有第一更新标识的更新请求；

标识接收模块，接收车辆发送的第一更新标识；

指令发送模块，用于在验证所述第一更新标识所述第二更新标识匹配的情况下返回更新指令，所述更新指令用于指示车辆完成所述第一更新标识对应的应用程序的更新。

由于该车辆应用程序更新装置与前文公开的在监管系统侧的车辆应用程序更新方法的过程相同，技术效果相当，在此不在累述。

再一方面，本公开提供一种车辆应用程序更新系统，包括服务器、车辆和监管系统，所述服务器、所述车辆和所述监管系统相互交互完成上述的车辆应用程序更新方法。

图5是根据一示例性实施例示出的一种用于车辆应用程序更新的电子设备的框图，该电子设备可以是终端，也可以是监管系统，其内部结构图可以如图5所示。该电子设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种车辆应用程序更新的方法。该电子设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该电子设备的输入装置可以是显示屏上覆盖的触摸层，也可以是电子设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图5中示出的结构，仅仅是与本公开方案相关的部分结构的框图，并不构成对本公开方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在示例性实施例中，还提供了一种电子设备，包括：处理器；用于存储该处理器可执行指令的存储器；其中，该处理器被配置为执行该指令，以实现如本公开实施例中的车辆应用程序更新方法。

在示例性实施例中，还提供了一种计算机可读存储介质，当该计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行本公开实施例中的车辆应用程序更新方法。计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行本公开实施例中的车辆应用程序更新的方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种车辆应用程序更新方法，其特征在于，所述方法包括：

基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

基于获取的车辆状态数据确定车辆是否处于驻车状态；

在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

2.根据权利要求1所述车辆应用程序更新方法，其特征在于，所述方法还包括：

若所述时间间隔小于所述更新时长，则在所述车辆使用时序列中选取连续的停放标签对应的时间间隔大于所述更新时间的时间段作为更新时段；

在所述更新时段且车辆处于驻车状态时，执行所述应用程序的更新。

3.根据权利要求2所述车辆应用程序更新方法，其特征在于，所述车辆历史行为数据还包括与所述历史停车行为对应的停车地点；所述用车时段预测模型还包括：位置预测组件；

所述方法还包括：

将所述停车地点输入至预先建立的用车时段预测模型中，基于所述位置预测组件得到携带有目标停车地点的车辆使用时序列，所述目标停车地点与所述停放标签对应；

相应的，所述执行所述应用程序的更新包括，所述方法包括：

获取车辆的当前位置，并判断所述当前位置与所述当前时间对应的目标停车地点是否相同；

在所述当前位置与所述当前时间对应的目标停车地点相同时，执行所述应用程序的更新。

4.根据权利要求3所述车辆应用程序更新方法，其特征在于，所述方法还包括：

所述当前位置与所述当前时间对应的目标停车地点不相同，则在所述更新时段、车辆处于驻车状态且车辆停车位置与所述更新时段对应的目标停车地点相同时，执行所述应用程序的更新。

5.根据权利要求3所述车辆应用程序更新方法，其特征在于，所述用车时段预测模型的训练过程包括：

获取多个时间周期的车辆样本使用时序列，所述车辆样本使用时序列包括多组所述样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段，所述样本停车行为对应有停车地点；

建立所述用车时段预测模型，其中，所述用车时段预测模型包括：时序预测组件和位置预测组件，所述时序预测组件和位置预测组件均包括多个模型参数；

将多组所述样本用车行为对应的用车时段和多组所述样本停车行为对应的停车时段作为所述时序预测组件的输入数据，将下一时间周期的车辆使用时序列作为所述时序预测组件的输出数据，对所述时序预测组件进行训练，调整所述时序预测组件的所述模型参数，直至所述时序预测组件达到预设要求；

将多组所述样本用车行为对应的用车时段、多组所述样本停车行为对应的停车时段以及所述样本停车行为对应有停车地点作为所述位置预测组件的输入数据，将下一时间周期的携带有目标停车地点的车辆使用时序列作为所述位置预测组件的输出数据，对所述位置预测组件进行训练，调整所述位置预测组件的所述模型参数，直至所述位置预测组件达到预设要求。

6.根据权利要求1-5任一项所述车辆应用程序更新方法，其特征在于，所述更新请求中携带有第一更新标识，所述更新请求是在所述服务器基于监管系统完成待备案信息备案完成的情况下发送的，所述待备案信息包括：第二更新标识；

所述执行所述应用程序的更新，包括：

将所述第一更新标识发送至车辆对应的所述监管系统，以验证所述第一更新标识和所述第二更新标识是否匹配；

接收所述监管系统返回的更新指令，所述更新指令是在所述监管系统验证所述第一更新标识和所述第二更新标识匹配的情况下发送的；

基于所述更新指令下载所述更新请求对应的应用程序更新安装包；

基于所述更新安装包更新对应的应用程序。

7.根据权利要求6所述车辆应用程序更新方法，其特征在于，所述更新安装包携带有第一数据包验证标识；

在接收所述监管系统返回的更新指令时，所述方法还包括：接收所述监管系统返回的与所述第二更新标识关联的第二数据包验证标识：

所述基于所述更新安装包更新对应的应用程序之前，所述方法包括：

验证所述第一数据包验证标识和所述第二数据包验证标识是否匹配；

相应的，所述基于所述更新安装包更新对应的应用程序是在所述第一数据包验证标识和所述第二数据包验证标识匹配时更新的。

8.一种车辆应用程序更新装置，其特征在于，所述装置包括：

更新时长确定模块，用于基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

驻车状态判断模块，用于基于获取的车辆状态数据确定车辆是否处于驻车状态；

车辆使用时序列预测模块，用于在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

更新时长判断模块，用于判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

更新模块，用于若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如权利要求1-7中任一项所述车辆应用程序更新方法。

10.一种车辆，其特征在于，所述车辆设置有车辆应用程序更新装置，所述装置包括：

更新时长确定模块，用于基于接收到服务器发送的更新请求确定对应应用程序的更新时长；

驻车状态判断模块，用于基于获取的车辆状态数据确定车辆是否处于驻车状态；

车辆使用时序列预测模块，用于在车辆处于驻车状态时，将车辆历史行为数据输入至预先建立的用车时段预测模型中，基于所述用车时段预测模型中的时序预测组件得到车辆使用时序列；所述车辆历史行为数据包括历史用车行为对应的用车时段和历史停车行为对应的停车时段，所述车辆使用时序列包括多个相邻的时间点，各个所述时间点对应有表征车辆被使用的占用标签或表征车辆未被使用的停放标签；

更新时长判断模块，用于判断当前时间与首个所述占用标签对应的时间点的时间间隔是否大于所述更新时长；

更新模块，用于若所述时间间隔大于所述更新时长，则执行所述应用程序的更新。

Images