CN112099829B - 车辆升级控制方法及系统、ota后台、车辆 - Google Patents

Abstract

本申请公开了一种车辆升级控制方法及系统、OTA(空中下载技术)后台、车辆、计算机存储介质。具体实现方案为包括：所述第一OTA后台，用于生成至少一个车辆所对应的升级包以及刷写任务；所述第二OTA后台，用于生成至少一个车辆的更新刷写任务及其对应的新升级包；所述目标车辆，用于处于第一环境的情况下，基于所述目标刷写任务，下载对应的目标升级包并进行升级处理；以及处于第二环境的情况下，基于目标更新刷写任务下载对应的新升级包并进行升级处理。

Description

车辆升级控制方法及系统、OTA后台、车辆

技术领域

本申请涉及车辆控制领域，尤其涉及一种车辆升级控制方法及系统、OTA(空中下载技术，Over-the-Air Technology)后台、车辆和计算机存储介质。

背景技术

随着信息技术的发展，在车辆领域的信息处理技术也越来越智能化，目前在针对车辆的智能化处理中，通常需要通过云端与车辆配合进行信息的处理，比如在车辆的软件升级过程中，需要获取升级包，进而车辆根据升级包进行刷写升级等处理。然而，如何在不同环境中对车辆进行不同的升级控制是需要解决的问题。

发明内容

为了解决现有技术中上述至少一个问题，本申请实施例提供一种车辆升级控制方法及系统、OTA后台、车辆、计算机存储介质。

第一方面，本申请实施例提供一种车辆升级控制系统，包括：第一OTA后台、第二OTA后台、以及目标车辆；其中，

所述第一OTA后台，用于生成至少一个车辆所对应的升级包以及刷写任务；

所述第二OTA后台，用于生成至少一个车辆的更新刷写任务及其对应的新升级包；

所述目标车辆，用于处于第一环境的情况下，基于所述目标刷写任务，下载对应的目标升级包并进行升级处理；以及处于第二环境的情况下，基于目标更新刷写任务下载对应的新目标升级包并进行升级处理；其中，所述新目标升级包与所述目标升级包中对应ECU的软件版本不同；所述目标刷写任务为所述至少一个车辆对应的刷写任务中之一；所述目标更新刷写任务为所述至少一个车辆对应的更新刷写任务中之一。

第二方面，本申请实施例提供一种车辆升级控制方法，应用于第一OTA后台，包括：

生成至少一个车辆所对应的升级包以及刷写任务；

将所述至少一个车辆所对应的刷写任务发送至第一TSP；其中，所述第一TSP用于在基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；所述目标车辆为所述至少一个车辆中之一；其中，所述目标刷写任务为所述至少一个车辆对应的刷写任务中之一。

第三方面，本申请实施例提供一种车辆升级控制方法，应用于目标车辆，包括：

处于第一环境的情况下，接收目标刷写任务；

基于所述目标刷写任务获取对应的目标升级包；

基于所述目标升级包进行升级。

第四方面，本申请实施例提供一种车辆升级控制方法，应用于第二OTA后台，包括：

生成至少一个车辆的更新刷写任务及其对应的新升级包；

将所述至少一个车辆所对应的更新刷写任务发送至第二TSP；其中，所述第二TSP用于在确定对所述目标车辆进行升级的情况下，向所述目标车辆发送对应的目标更新刷写任务；所述目标车辆为所述至少一个车辆中之一。

第五方面，本申请实施例提供一种车辆升级控制方法，应用于目标车辆，包括：

处于第二环境的情况下，接收目标更新刷写任务；

基于所述目标更新刷写任务下载对应的新目标升级包；

基于所述新目标升级包进行升级。

第六方面，本申请实施例提供一种第一OTA后台，包括：

第一处理模块，用于生成至少一个车辆所对应的升级包以及刷写任务；

第一传输模块，用于将所述至少一个车辆所对应的刷写任务发送至第一TSP；其中，所述第一TSP用于在基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；所述目标车辆为所述至少一个车辆中之一；其中，所述目标刷写任务为所述至少一个车辆对应的刷写任务中之一。

第七方面，本申请实施例提供一种目标车辆，包括：

第三传输模块，用于处于第一环境的情况下，接收目标刷写任务；

第一下载模块，用于基于所述目标刷写任务获取对应的目标升级包；

第一升级控制模块，用于基于所述目标升级包进行升级。

第八方面，本申请实施例提供一种第二OTA后台，包括：

第二处理模块，用于生成至少一个车辆的更新刷写任务及其对应的新升级包；

第四传输模块，用于将所述至少一个车辆所对应的更新刷写任务发送至第二TSP；其中，所述第二TSP用于在确定对所述目标车辆进行升级的情况下，向所述目标车辆发送对应的目标更新刷写任务；所述目标车辆为所述至少一个车辆中之一；其中，所述目标更新刷写任务为所述至少一个车辆对应的更新刷写任务中之一。

第九方面，本申请实施例提供一种目标车辆，包括：

第五传输模块，用于处于第二环境的情况下，接收目标更新刷写任务；

第二下载模块，用于基于所述目标更新刷写任务下载对应的新目标升级包；

第二升级控制模块，用于基于所述新目标升级包进行升级。

第十方面，本申请实施例提供一种车辆，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请任意一项实施例所提供的方法。

第十一方面，本申请实施例提供一种第一OTA后台，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请第二方面实施例所提供的方法。

第十二方面，本申请实施例提供一种第二OTA后台，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请第四方面实施例所提供的方法。

第十三方面，本申请实施例提供一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行本申请任意一项实施例所提供的方法。

上述申请中的一个实施例具有如下优点或有益效果：在不同的环境中，通过不同的OTA后台生成针对车辆的刷写任务及其对应的升级包，在目标车辆处于第一环境的情况下，从第一OTA后台生成的刷写任务中确定目标刷写任务，并基于目标刷写任务下载对应的升级包进行升级；在目标车辆处于第二环境的情况下，可以获取第二OTA后台生成的更新刷写任务并下载对应的新的升级包，这样的处理，使得目标车辆在不同的环境中，通过不同的系统获取到相应的升级包，由于在第一环境下目标车辆预先并不知道自身的标识，则需要通过其ECU的相关信息可以确定其对应的标识进而确定对应的升级包，在第二环境下目标车辆涉及到的主要是更新后的刷写任务，则通过第二OTA后台获取新的升级包即可。可见，通过本实施例提供的方案，使得OTA后台的功能划分更加清晰，也使得针对目标车辆的处理更加符合其所处环境的情况，提升了升级处理的准确性以及效率。

上述可选方式所具有的其他效果将在下文中结合具体实施例加以说明。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请一实施例的车辆升级控制系统组成结构示意图一；

图2是根据本申请一实施例的车辆升级控制系统组成结构示意图二；

图3是根据本申请一实施例的车辆升级控制系统组成中生产系统的组成结构示意图；

图4是根据本申请一实施例的车辆升级控制系统组成中售后系统的组成结构示意图；

图5是根据本申请一实施例的各个组成部分之间的接口示意图；

图6是根据本申请实施例的一种目标车辆组成结构示意图一；

图7是根据本申请实施例的一种车辆升级控制方法流程示意图一；

图8是根据本申请实施例的一种车辆升级控制方法流程示意图二；

图9是根据本申请实施例的一种车辆升级控制方法流程示意图三；

图10是根据本申请实施例的一种车辆升级控制方法流程示意图四；

图11是根据本申请实施例的一种车辆升级控制方法流程示意图五；

图12是根据本申请实施例的一种车辆升级控制方法流程示意图六；

图13是根据本申请实施例的一种车辆升级中供电维持的处理流程示意图；

图14是本申请实施例的一种第一OTA后台组成结构示意图；

图15是本申请实施例一种第一TSP组成结构示意图；

图16是本申请实施例又一种目标车辆组成结构示意图二；

图17是本申请实施例一种第二OTA后台组成结构示意图；

图18是本申请实施例一种目标车辆组成结构示意图三；

图19是本申请实施例一种第二TSP组成结构示意图；

图20是本申请另一实施例的一种硬件组成架构示意图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

第一方面，本申请实施例提供了一种车辆升级控制系统，如图1所示，包括：第一OTA(Over-the-Air Technology，空中下载技术)后台101、第二OTA后台102、以及目标车辆105；其中，

所述第一OTA后台101，用于生成至少一个车辆所对应的升级包以及刷写任务；

所述第二OTA后台102，用于生成至少一个车辆的更新刷写任务及其对应的新升级包；

所述目标车辆105，用于处于第一环境的情况下，基于所述目标刷写任务，下载对应的目标升级包并进行升级处理；以及处于第二环境的情况下，基于目标更新刷写任务下载对应的新目标升级包并进行升级处理；其中，所述新目标升级包与所述目标升级包中对应ECU的软件版本不同；所述目标刷写任务为所述至少一个车辆对应的刷写任务中之一；所述目标更新刷写任务为所述至少一个车辆对应的更新刷写任务中之一。

其中，所述第一OTA后台可以为生产OTA后台，第二OTA后台可以为售后OTA后台。也就是第一OTA后台以及第二OTA后台分别用于不同环境的目标车辆的升级处理。

所述第一环境可以为生产环境，第二环境为售后环境。

这里，生产环境中第一OTA后台可以根据将排产车辆作为至少一个车辆以生成刷写任务及其对应的升级包。所述排产车辆可以为当前位于产线上的车辆，具体可以由运维人员来确定排产车辆为哪些或哪个，即可以由运维人员来确定当前所要生成刷写任务以及升级包的至少一个车辆。

上述第一OTA后台生成至少一个车辆所对应的升级包及刷写任务中，所述升级包可以指的是针对每一个车辆的每一个ECU的升级包。所述刷写任务可以指的是每一个车辆的一个或多个ECU的升级包的下载地址以及升级约束条件。

进一步地，升级包的下载地址可以指的是升级包存储或缓存的地址；升级约束条件可以理解为使用升级包对ECU进行升级的过程中需要满足的约束条件。所述升级约束条件，可以包括ECU的优先级、是否可以并行刷写、ECU刷写的先后顺序中至少之一。

所述系统如图2所示，还可以包括：第一TSP(Telematics Service Planfoem，内容服务平台)103、第二TSP 104；其中，

所述第一TSP 103，用于获取所述第一OTA后台发来的至少一个车辆的刷写任务；以及在基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；

所述第二TSP 104，用于向所述目标车辆发送对应的目标更新刷写任务。

所述第一OTA后台生成针对每一个车辆的升级包以及刷写任务之后，可以将刷写任务推送到第一TSP；相应的，第一TSP，用于接收并保存所述第一OTA发来的至少一个车辆的刷写任务。

进一步地，第一TSP可以在接收到触发针对目标车辆的刷写指令的时候，向所述目标车辆发送对应的目标刷写任务。

其中，目标车辆为所述至少一个车辆中之一，所述目标刷写任务为预先生成的刷写任务中的刷写任务。

对于第二OTA后台来说，与第一OTA后台不同之处在于，第二OTA后台更注重为至少一个车辆生成更新刷写任务及其对应的新升级包。

具体来说，由于第二OTA后台是应用于售后环境，因此，每一个车辆可能在售后环境出现与出厂的时候或上一次售后环境使用时候的状态变化，比如，硬件更新、软件漏洞、软件版本更新等情况下，在第二OTA后台则需要结合车辆的状态对车辆更换的硬件进行刷写、对车辆出现的软件漏洞进行更新或升级、在软件版本出现更新版本的时候也需要对车辆进行新版本刷写，从而可以使得每一个车辆得到更新后的新目标升级包并进行更新。

还需要指出的是，在售后环境中，第二OTA后台可以分批次生成更新刷写任务及其对应的新升级包。在每一个批次中可以只选择一部分车辆，即至少一个车辆进行更新刷写任务以及新升级包的生成。在每一个批次完成预设比例的车辆的更新刷写任务以及新升级包的生成之后，可以针对下一批次的车辆生成更新刷写任务以及新升级包，依次类推。其中，预设比例根据实际情况进行设置，比如可以为80％。

第二TSP可以是先接收到第二OTA后台生成的每一个车辆的更新刷写任务，在通过第二OTA后台接收到针对目标车辆的任务下发指令的时候，向所述目标车辆发送目标更新刷写任务。

这里，每一个车辆的刷写任务或更新刷写任务中可以包括有每一个车辆的一个或多个ECU的升级包的下载地址以及升级约束条件，在前面已经说明。需要指出的是，刷写任务或更新刷写任务中还可以携带有每一个车辆的标识。

这里，将每一个车辆的标识称为车辆识别码(VIN)。

上述目标车辆可以在不同环境下与不同的OTA后台以及不同的TSP进行交互得到相应的刷写任务。比如，在第一环境也就是生产环境的时候，目标车辆会收到第一TSP下发的目标刷写任务；在第二环境也就是售后环境的时候，目标车辆会通过第二TSP收到下发的更新刷写任务。

如图2所示，所述系统还包括：下载服务器106以及CDN(Content DeliveryNetwork，即内容分发网络)107；其中，

所述下载服务器106，用于接收并保存第一OTA后台发来的至少一个车辆所对应的升级包；以及为所述目标车辆提供目标升级包；

所述CDN 107，用于接收并保存第二OTA后台发来的至少一个车辆所对应的新升级包；以及为所述目标车辆提供新目标升级包；

相应的，

所述第一OTA后台101，用于将所述至少一个车辆所对应的升级包发送至下载服务器；

所述第二OTA后台102，用于将所述至少一个车辆所对应的新升级包发送至CDN；

所述目标车辆105，用于处于第一环境的情况下，基于所述目标刷写任务，从所述下载服务器下载对应的目标升级包；以及处于第二环境的情况下，基于目标更新刷写任务从所述CDN下载对应的新目标升级包。

也就是说，第一OTA后台生成至少一个车辆的升级包之后就会将升级包发送至下载服务器进行缓存；相应的，目标车辆在接收到目标刷写任务的时候，会从下载服务器下载对应的目标升级包。

另外，第二OTA后台会将新升级包发送至CDN进行缓存；相应的，目标车辆在售后环境的时候，可以从CDN下载新目标升级包。

针对生产环境来说，如图3所示，所述系统还包括：

下线检测服务器108，用于获取至少一个ECU的相关信息，以及确定至少一个车辆的升级任务；其中，所述升级任务中包含车辆的标识、以及至少一个ECU对应的升级包的版本信息；将所述至少一个车辆的升级任务通过所述第一TSP发送至所述第一OTA后台；

所述第一OTA后台101，用于根据所述至少一个车辆的升级任务，生成所述至少一个车辆所对应的刷写任务及升级包。

所述下线检测服务器108，还用于在所述目标车辆处于第一环境的情况下，基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识，并基于所述目标车辆的标识触发所述第一TSP向所述目标车辆发送目标刷写任务。

上述下线检测服务器可以为EOL即end of line服务器。

结合图3对生产环境中针对目标车辆进行升级包下发进行说明，具体的：

所述下线检测服务器(即EOL)，用于获取至少一个ECU的相关信息，以及确定至少一个车辆的升级任务；其中，所述升级任务中包含车辆的标识、以及至少一个ECU对应的升级包的版本信息；将所述至少一个车辆的升级任务通过所述第一TSP发送至所述第一OTA后台。

其中，至少一个ECU的相关信息可以为至少一个ECU对应的设备ID，其获取方式，可以为通过扫码(比如扫SN码)设备对每一个ECU的设备ID进行扫描并录入到下线检测服务器(即EOL)。

在下线检测服务器(EOL)进行升级任务定义的时候，可以是定义车辆的标识、ECU的相关信息、原始版本、目标版本等内容。升级任务中可以绑定每一个车辆及其对应的特征(feature)包。其中，所述特征包中可以包括：ECU、类型、原始软件版本、本次升级软件的版本等内容。另外，所述特征包中还可以包括：每一个ECU所依赖的其他ECU，以及其他ECU的升级软件名称以及版本等等。

可以是，EOL生成了定义的任务即车辆的标识以及特征包后，EOL将特征包推送到第一OTA后台，第一OTA后台生成对应的刷写任务。在刷写任务中可以包括VIN、升级包的下载地址、配置、升级约束条件等等，这些刷写任务在第一OTA后台可以预先准备好。也就是哪些VIN可以支持哪些任务都是在任意一个车辆进入产线之前可以预先定义好的。

EOL获取至少一个ECU的相关信息的时候，可以是零件设备(比如ECU)从库房拿出要到对应的车辆中安装。此时，车辆的标识也就是为每一个车辆分配的VIN码在MES系统中，即MES(生成管理系统中)中包含有每一个车辆的VIN(标识)。第一TSP此时不知道每一个车的VIN是什么，因为没有写入车中。

在需要装配目标辆车的时候，EOL才会知道车辆的标识即VIN；具体的，可以由在所述目标车辆扫码得到关键的设备ID，也就是可以得到ECU的相关信息；此时可以根据ECU的相关信息以及车辆的标识进行绑定，以确定目标车辆对应的标识；进而可以将目标设备的标识以及对应的ECU的相关信息的绑定关系传输到第一TSP。

在EOL触发针对目标车辆的刷写任务的时候，将该目标车辆的标识可以发送到第一TSP；相应的，第一TSP从预先获取的多个车辆的多个刷写任务中选择与所述目标车辆的标识相对应的目标刷写任务，并将目标刷写任务与下发到目标车辆；

所述目标车辆根据该目标刷写任务从下载服务器下载对应的升级包；并且，所述目标车辆根据目标刷写任务中包含的升级约束条件采用所述升级包进行升级。比如，在生产环境中当目标车辆到某一个工位的时候，EOL触发针对该目标车辆下发刷写任务，目标刷写任务会通过第一TSP下发给目标车辆，然后目标车辆下载对应的目标升级包执行刷写升级的处理。

另外，上述EOL绑定车辆的ECU的相关信息以及车辆的标识的时候，EOL可以将绑定的ECU的相关信息以及车辆的标识的关系发送给第一TSP，第一TSP还可以将该信息同步给第一OTA。

再进一步地，第一OTA后台可以是将刷写任务都预先发送给第一TSP；相应的，EOL触发刷写任务的时候，可以是由第一TSP选择对应的目标任务并下发给目标车辆；

又或者，EOL可以触发刷写任务的时候，将目标车辆的标识发送给第一TSP，第一TSP将该目标车辆的标识发送给第一OTA后台；第一OTA后台基于目标车辆的标识确定对应的目标刷写任务，第一OTA后台可以将目标刷写任务ID通过第一TSP发送至目标车辆；然后目标车辆从第一TSP下载目标刷写任务。

针对生产环境还需要指出的是，第一TSP会向第一OTA后台同步产线车辆信息，关于产线车辆信息的内容可以包括：车辆的标识(VIN)等等。

本实施例中针对售后环境，如图2所示，所述系统，还包括：

运营平台109，用于确定至少一个车辆的ECU所对应的新升级任务，将所述至少一个车辆的ECU所对应的新升级任务推送至二OTA后台；

所述第二OTA后台102，用于根据所述至少一个车辆的ECU所对应的新升级任务，生成所述至少一个车辆的更新刷写任务及其对应的新升级包。

这里，所述运营平台可以理解为用于控制第二OTA后台，或者与远端进行交互的一个前端的用于展示以及内容监控、以及信息输入或定义的设备。通过运营平台可以使得运维人员进行直接的界面化的操作。

关于新升级任务与上述生产环境中的升级任务的不同之处在于，新升级任务若与生产环境的升级任务针对同一个ECU进行定义的时候，版本是不同的，或者新升级任务中的ECU的软件版本高于生产环境的升级任务中的ECU的软件版本。另外，新升级任务中还可能存在一部分车辆刚刚更换的ECU所对应的软件的最新版本。

相应的，第二OTA基于新升级任务生成更新刷写任务以及新升级包的内容，可以与前述生产环境中的刷写任务与升级包的内容以及关系类似这里不再赘述。

如图2所示，所述系统还包括：

产品质量服务器110，用于同步至少一个车辆变更信息至所述第二TSP；其中，所述车辆变更信息用于表征车辆的最新状态信息；

所述第二TSP 104，用于将至少一个车辆的变更信息发送至第二OTA后台；

所述第二OTA后台102，用于基于所述至少一个车辆的变更信息、以及所述至少一个车辆的ECU所对应的新升级任务，生成所述至少一个车辆的更新刷写任务及其对应的新升级包。

产品质量服务器可以称为QCloud。

车辆变更信息可以是每次车辆出现变更零件比如ECU更换的时候，同步至产品质量服务器中的。和/或，车辆变更信息还可以包括车辆的当前版本的上报和/或备份版本等内容。

另外，第二OTA后台获取到的车辆变更信息可以除了从产品质量服务器获取到之外，还可以是车辆本身通过第二TSP上传给第二OTA后台；或者，还可以通过其他途径传输到第二OTA后台，本实施例不做穷举。

进一步地，第二OTA后台可以及时获取到车辆的变更信息、以及结合预先定义的升级任务，生成针对车辆的更新刷写任务及其对应的新升级包。当然，可能存在部分车辆未上报对应的更新信息，那么第二OTA后台针对这部分车辆就根据新升级任务生成对应的更新刷写任务以及新升级包即可。

相应的，若获取到车辆变更信息，第二OTA后台可以根据车辆的当前版本和/或备份版本，确定刷写任务对应了更新后的新升级包之外是否还需要对应针对车辆的更新后的备份版本。基于此，生成针对车辆的刷写任务及其对应的新升级包。

结合图4对上述售后环境中的处理进行说明：

所述运营平台可以用于定义至少一个车辆的新升级任务；该新升级任务中包括车辆标识以及新升级任务的版本。同样的，该新升级任务的版本同样可以基于特征包来定义，关于特征包的内容与前述实施例的说明相同，不再重复说明。

运营平台会定义至少一个任务，将定义好的任务发送给第二OTA后台；第二OTA后台根据至少一个任务生成OTA新升级包。第二OTA后台，用于基于至少一个车辆的新升级任务生成更新刷写任务，并生成每一个更新刷写任务所对应的新升级包，将新升级包推送至内容分发网络(CDN)。

产品质量服务器，用于同步售后车辆信息至第二TSP；售后车辆信息用于指示售后车辆的最新状态信息，比如，车辆发生换件则零部件信息会发生变化，此时需要同步至第二OTA后台。

第二TSP将同步售后车辆信息发送给第二OTA后台。第二OTA后台进行新升级包的生成的时候会用到该售后车辆信息。

当前存在一个车辆需要做售后服务，比如可以为售后服务中进行换件、或者售后服务中进行软件升级等处理的情况下，将该车辆作为目标车辆。

运营平台，还用于为目标车辆触发任务至第二OTA后台；第二OTA后台，用于通过第二TSP向目标车辆发送更新刷写任务。所述目标车辆，用于根据更新刷写任务从CDN下载对应的新目标升级包。

需要理解的是，第二OTA后台可以针对至少一个车辆的新升级任务生成刷写任务，并生成每一个刷写任务所对应的新升级包的时候，将新升级包推送至内容分发网络(CDN)；此时将刷写任务推送到第二TSP，等到目标车辆上线通信后；第二OTA后台将目标更新刷写任务ID通过第二TSP发送至目标车辆；然后目标车辆从第二TSP下载目标更新刷写任务。

通过以上实施例的说明，可以看出，本申请实施例可以在不同的环境中，通过不同的OTA后台生成针对车辆的刷写任务及其对应的升级包，在目标车辆处于第一环境的情况下，根据目标车辆的ECU的相关信息确定其对应的标识，进而从第一OTA后台生成的刷写任务中确定目标刷写任务，并基于目标刷写任务下载对应的升级包进行升级；在目标车辆处于第二环境的情况下，可以获取第二OTA后台生成的更新刷写任务并下载对应的新目标升级包，这样的处理，使得目标车辆在不同的环境中，通过不同的系统获取到相应的升级包，由于在第一环境下目标车辆预先并不知道自身的标识，则需要通过其ECU的相关信息可以确定其对应的标识进而确定对应的升级包，在第二环境下目标车辆涉及到的主要是更新后的刷写任务，则通过第二OTA后台获取新的升级包即可。可见，通过本实施例提供的方案，使得OTA后台的功能划分更加清晰，也使得针对目标车辆的处理更加符合其所处环境的情况，提升了升级处理的准确性以及效率。

进一步地，如图2所示，所述系统，还包括：

诊断仪后台111，用于向诊断仪发送诊断序列以及诊断任务；以及获取所述诊断仪反馈的所述目标车辆的诊断结果，将所述诊断结果同步至产品质量服务器；

诊断仪116，用于基于所述诊断序列以及诊断序列对目标车辆进行诊断，得到所述目标车辆的诊断结果。

具体的，运维人员可以预先生成诊断序列(或可以称为诊断脚本)；然后诊断仪后台通过与诊断仪之间的连接，将所述针对序列发送至诊断仪，由诊断仪对目标车辆进行诊断。其中，诊断仪可以是根据诊断序列，比如其中可以包括顺序执行的一个或多个诊断指令，基于一个或多个诊断指令对目标车辆进行诊断，并得到相应的诊断结果；诊断仪将诊断结果发送给诊断仪后台后，由诊断仪后台将目标车辆本次的诊断结果同步至产品质量服务器。

又一种示例中，提供另外一种诊断的处理，如图2所示，所述系统还包括：

远程诊断仪后台112，用于通过所述第二TSP向目标车辆发送诊断序列，并获取到对应的诊断结果，将所述诊断结果同步至所述产品质量服务器。

这种方式中，远程诊断仪后台可以预先获取运维人员编写的诊断序列或诊断脚本；然后通过第二TSP向目标车辆发送该诊断序列；由目标车辆执行完成后得到相应的诊断结果并通过第二TSP将该诊断结果发送至远程诊断仪后台，此时远程诊断仪后台将该目标车辆的诊断结果同步至产品质量服务器。

又一示例中，如图2所示，所述系统还包括：车辆软件平台(VSP)113，用于为第一OTA后台以及第二OTA后台提供升级包及其版本信息、以及ECU的相关信息。

又一示例中，如图2所示，所述系统还包括：USS 114，用于对运维人员进行账号鉴权处理；以及针对所述运维人员的登录状态进行管理。

具体来说，VSP可以用于在第一OTA以及第二OTA需要基于升级任务或新升级任务进行升级包生成的时候，可以从VSP获取原始升级包，进而基于原始升级包进行新的升级包的生成。

在运维人员需要进行任务配置、诊断序列生成等处理的时候，基于自身的账号进行登录的时候，通过USS对该账号进行鉴权，具体的鉴权处理这里不做赘述。又或者是对运维人员的登录状态进行管理，比如当前处于登录状态的记录、登录时长的记录、登录操作的日志记录等等。

如图2所示，所述系统，还包括：

终端设备115，用于下载所述目标车辆的新目标升级包或目标升级包；在与所述目标车辆建立通信连接的情况下，将所述新目标升级包或目标升级包发送至所述目标车辆；

所述目标车辆105，还用于从所述终端设备获取所述新目标升级包或目标升级包。

具体来说，终端设备115，用于接收针对目标车辆的目标更新刷写任务；从CDN下载所述针对目标车辆的目标更新刷写任务所对应的升级包；在与所述目标车辆建立通信连接的情况下，将所述升级包发送至所述目标车辆。需要指出的是，终端设备还可以从下载服务器获取目标车辆的目标升级包；在与所述目标车辆建立通信连接的情况下，将目标升级包发送给目标车辆。

也就是说，终端设备可以从CDN下载目标车辆的新目标升级包，也可以从下载服务器下载目标车联的目标升级包。

所述终端设备可以为用后使用的智能终端或移动终端，比如，可以为手机、平板电脑等设备。

所述终端设备115，用于发送下载请求。

比如，用户可以通过查看终端设备预设应用查看到是否有云端发来的升级任务，若查看到有新的升级任务，则用户可以选择终端设备侧进行下载，此时终端设备会向云端发送针对所述升级任务的升级包下载请求。

进一步的，用户可以在查看预设软件的展示内容的时候，看到当前有至少一个待下载的升级包；相应的，可以选择下载其中一个或多个升级包，又或者，可以选择全部下载，可以根据具体情况来确定。若下载一个或多个升级包，用户可以在操作界面进行点击，然后向云端发送包含一个或多个升级包的下载请求。若下载全部升级包，用户可以在操作界面全部选择，然后终端设备向第二OTA后台或第二TSP发送下载全部升级包的下载请求。

终端设备115，用于根据刷写任务(目标刷写任务，或目标更新刷写任务)中包含的至少一个升级包的下载地址，从所述CDN或所述下载服务器的下载地址处下载所述针对目标车辆的至少一个升级包(目标升级包或新目标升级包)。

所述终端设备115与所述目标车辆105的所述通信连接可以为WIFI连接。

通过以上处理，终端设备通过与目标车辆之间的连接向目标车辆发送升级包，如此，可以减少目标车辆直接从下载服务器获取升级包所带来的流量消耗。

另一实施例提供的方案中，

所述终端设备115，还用于对所述目标车辆进行升级控制；其中，所述升级控制包括：对所述目标车辆进行立即升级或预约升级；

相应的，所述目标车辆105，还用于根据终端设备的升级控制，基于下载的新目标升级包或目标升级包进行升级；或者，基于终端设备的预约升级控制在预约时间进行升级。

所述终端设备115，还用于收到目标车辆的新版本更新通知；若确认对所述目标车辆进行升级，则向所述目标车辆发送升级指令；其中，所述升级指令用于指示所述目标车辆基于获取到的升级包(目标升级包或新目标升级包)执行升级。

具体来说，终端设备实时通过预设应用可以查看当前目标车辆的系统状态，若目标车辆完成升级包的下载，则终端设备可以收到目标车辆的新版本更新通知。该新版本更新通知可用于指示所述目标车辆完成新的升级包的下载、或者是用于指示所述目标车辆需要根据新的升级包进行更新。

当然，上述目标车辆的新版本更新通知还可以为所述终端设备通过SMS短信获取到的，本实施例不对其获取方式进行穷举。

此时，还需要指出的是，所述终端设备115，还用于对所述升级包(新目标升级包或目标升级包)进行合法性校验；在所述合法性校验通过的情况下，接收所述目标车辆发来的临时许可信息。

具体的，对所述升级包进行合法性校验的处理，可以是在确认对所述目标车辆进行升级之后执行的；若合法性校验通过，则可以向所述目标车辆发送校验通过的信息。

相应的，所述目标车辆在接收到终端设备发来的校验通过的信息的时候，可以检测自身的状态，若当前状态为休眠状态，则唤醒所述目标车辆，并且所述目标车辆再次对升级包进行校验，否则，当前状态为工作状态，则所述目标车辆直接再次对所述升级包进行校验。

当然，判断目标车辆的状态的处理，也可以由终端设备来执行，也就是，所述终端设备针对所述升级包完成校验并且校验通过的情况下，所述终端设备检测所述目标车辆的状态，若所述目标车辆的状态为休眠状态，则所述终端设备可以向所述目标车辆进行远程唤醒，在所述目标车辆收到远程唤醒指令的时候，转换至工作状态，然后所述目标车辆可以对所述升级包进行校验；或者，在终端设备检测所述目标车辆的状态为工作状态的情况下，可以直接通知所述目标车辆当前要对升级包进行升级，然后所述目标车辆可以执行对所述升级包进行校验的处理。

进一步地，在所述目标车辆完成校验并且校验为通过的情况下，所述目标车辆可以生成一个临时许可信息(或称为临时license)；所述目标车辆可以将该临时许可信息发送至所述终端设备。需要指出的是，该临时许可信息还可以包括一个有效时长。

相应的，所述终端设备在收到所述临时许可信息之后，若执行立即升级，则可以向所述目标车辆发送携带有所述临时许可信息的升级指令。然后，所述目标车辆在收到升级指令之后，可以验证所述升级指令中的临时许可信息，若验证通过，则可以基于所述升级指令对升级包执行升级处理(或称为刷写处理)。

至此，终端设备控制所述目标车辆完成立刻升级的处理。

另一实施例，所述终端设备115，还用于收到目标车辆的新版本更新通知；若确认对所述目标车辆进行预约升级，则向所述目标车辆发送预约升级指令；其中，所述预约升级指令中包含预约升级时间，所述预约升级指令用于指示所述目标车辆在所述预约升级时间基于所述升级包执行升级。

所述终端设备115，确认对所述目标车辆进行升级，可以为响应于用户通过前述预设应用点击确认升级的选项生成的确认信息，此时，用户还可以通过预设应用设置预约升级时间。预约升级时间可以根据实际情况进行设置。

此时，还需要指出的是，所述终端设备115，还用于对所述升级包(新目标升级包或目标升级包)进行合法性校验；在所述合法性校验通过的情况下，接收所述目标车辆发来的临时许可信息。关于这部分的处理与前述实施例相同，也不做赘述。

本实施例提供的系统中，所述第二OTA后台与第二TSP之间通过开放应用程序接口API进行连接；

所述远程诊断仪后台与第二TSP之间通过开放API进行连接；

所述下线检测服务器与第一TSP之间通过开放API进行连接；

所述第一OTA后台与第一TSP之间通过开放API进行连接；

所述诊断仪与车辆之间通过UDS协议进行通信。

参见图5，其中，OTA后台可以是第一OTA后台和/或第二OTA后台，TSP可以是第一TSP或第二TSP。

在生产环境中，OTA后台为第一OTA后台，TSP为第一TSP，在生产环境中，与TSP通过开放API连接的还包括下线检测服务器即EOL。

在售后环境中，OTA后台为第二OTA后台，TSP为第二TSP，并且，售后环境中，与TSP通过开放API连接的还包括有远程诊断仪后台。另外，售后环境中，诊断仪可以通过UDS协议与目标车辆进行通信，并且诊断仪以及诊断仪后台之间通过UDS协议进行通信。

进一步地，目标车辆中可以包括网关以及OTA组件，网关与OTA组件之间也可以通过开放API进行通信或连接。

基于以上架构，在一实施例中，进一步针对目标车辆的供电的处理进行说明，具体的，如图6所示，

所述目标车辆，包括：唤醒模块61、电源管理模块62、OTA组件63；其中，

所述唤醒模块61，用于收到唤醒指令的情况下，向电源管理模块发起唤醒请求，以及向OTA组件发起唤醒请求；以及从电源管理模块发起持续上电请求；

所述电源管理模块62，用于基于唤醒模块的请求，为至少一个ECU进行供电。

所述唤醒模块61，还用于向OTA组件发起升级请求；

所述OTA组件63，用于根据升级请求检测是否具备升级条件。

其中，所述OTA组件可以包括目标车辆中的ECU。

这里检测OTA组件检测是否具备升级条件可以包括：检测车辆的状态、当前其他ECU的状态、存在依赖关系的ECU的状态、以及升级约束条件等。

上述唤醒模块61，可以接收本地预约唤醒指令或者是远程唤醒指令。

其中，本地预约唤醒指令可以是根据终端设备的预约升级指令确定的。远程唤醒指令可以是用户根据实际情况设置或触发的。

唤醒模块61，可以在确定需要升级的时候，从电源管理模块获取供电维持，然后向OTA组件发起唤醒请求；此时，电源管理模块被唤醒模块唤醒之后可以向OTA组件供电并且为唤醒模块供电。

所述OTA组件63，还用于在确定具备升级条件的情况下，切换至升级模式进行刷写，以及向唤醒模块发送升级请求响应成功的信息；以及向电源管理模块发送持续上电请求；或者，在确定不具备升级条件的情况下，向所述唤醒模块发送升级请求响应失败的信息；

相应的，所述唤醒模块61，用于接收到送升级请求响应成功的信息后，停止向电源管理模块发送持续上电请求；或者，接收到升级请求响应失败的信息，停止向电源管理模块发送持续上电请求。

在OTA组件确定具备升级条件的情况下，OTA组件可以开始升级，此时，OTA组件对应的至少一个ECU可以根据预先下载的升级包对ECU进行刷写升级。这里，预先下载的升级包可以为前述目标升级包或新目标升级包。

另外，OTA组件开始升级的时候，可以向唤醒模块发送升级请求响应成功的信息；相应的，唤醒模块可以停止向电源管理模块发送持续上电请求。也就是说，此时唤醒模块可以不再上电或不再进行控制，而是由OTA组件完成刷写。进一步地，在OTA组件完成刷写之后，还可以停止向电源管理模块获取供电维持，此时可以全车下电。当然，也可以根据用户的操作全车上电进行后续的自动驾驶等处理，不再赘述。

另一种情况中，OTA组件在确定不具备升级条件的情况下，向所述唤醒模块发送升级请求响应失败的信息；相应的，唤醒模块可以停止向电源管理模块发送持续上电请求。此时，OTA组件也可以停止从电源管理模块请求持续上电，也就是无法进行升级，即无法响应本次升级唤醒，OTA组件，可以将响应失败的原因上报至OTA后台(比如第二OTA后台)，然后进行下电，也就是此时可以全车下电。当然，也可以根据用户的操作全车上电进行后续的自动驾驶等处理，不再赘述。

基于上述实施例的说明，结合图1、2的架构，另一实施例可以包括：

所述运营平台，用于针对所述至少一个车辆的目标车辆的第一ECU的N个软件模块确定新升级任务；N为大于等于1的整数；其中，所述N个软件模块为同一类软件模块；

相应的，所述第二OTA后台，用于基于包含针对所述目标车辆的第一ECU的N个软件模块的新升级任务生成对应的新目标升级包。

所述软件模块包括以下类型中至少一种：系统类软件模块、应用类软件模块、数据类软件模块。

上述目标车辆可以为至少一个车辆中的任意一个车辆。

第一ECU可以为目标车辆中多个ECU中的任意一个，针对每一个ECU都可以采用相同的处理，因此不再一一赘述。

以上处理中，不再将同一个ECU的全部升级在一次执行，可以对同一个ECU的升级任务进行组合，在一次升级任务中仅针对同一类软件模块进行定义，比如，当前可能存在M个系统类软件模块需要升级，在一次升级任务的定义中，可以仅定义升级其中的N个系统类软件模块。

需要指出的，在一次针对一个ECU进行定义的时候，仅能够组合相同类型的软件模块，不会针对其不同类型的软件模块进行组合的定义。

比如，在针对第一ECU的任务定义中，可以包括系统包名、配置信息、本次任务中升级的软件模块名1-n，以及具体的字段的定义，比如可以包括零件信息(partinfo)以及更新信息(updateinfo)两部分内容，其中，更新信息中包含了每一个软件模块的相关信息，比如，包括软件模块的类型、依赖关系等等。

其中，软件模块的类型可以为类型对应的编号，比如，0可以是系统包、1可以是应用包、2可以是数据包；当然，还可以存在其他类型的划分，以及与上述不同的编号对应关系，这里不再穷举。

在针对第一ECU的一次任务定义中，软件模块名1-n应该都是同一个软件模块的类型的，比如软件模块的类型对应的编号可以都是0或都是1等等。

上述依赖关系可以指的是，每一个软件模块依赖的本ECU(也就是第一ECU)的其他软件版本、每一个软件模块依赖的其他ECU的软件版本的关系中至少之一。

也就是一种情况下，第一ECU的某一个软件模块仅定义了与本ECU的其他软件模块之间的依赖关系，那么可以将第一ECU的某一个软件模块与其依赖的软件模块一起升级，需要指出的是，如果其依赖的软件模块与其类型相同，可以在本次一起升级；否则，可以在该软件模块升级之前，需要先升级其依赖的软件模块才可以执行。

进一步地，这种情况中，所述第二OTA后台，还用于确定针对所述第一ECU的N个软件模块的升级包为全量包或差量包，生成针对第一ECU的全量新升级包或差量新升级包。

具体的，在进行新升级包的生成的时候，可以判断第一ECU升级为全量升级包还是差分升级包，可以是根据运维人员的设定来确定的，比如，运维人员可以设置，针对目标车辆进行全量升级，那么此时就会生成全量升级包；或者，针对目标车辆的部分ECU进行全量升级，另一部分ECU进行差分升级，此时可以根据第一ECU具体被设置的情况，来确定生成对应的全量或差分升级包。

又或者，可以是根据第一ECU的当前情况来自动确定的，比如，预先可以由目标车辆上传当前的软件版本，第二OTA后台可以根据目标车辆的第一ECU的当前软件版本的情况来确定是否生成全量升级包或差分升级包。比如，第一ECU的软件版本出现问题或存在漏洞，需要进行全量升级，可以为其生成全量升级包；或者，第一ECU的当前软件版本仅需要进行差分升级，那么就为其生成差分升级包。

当然，还可能存在其他确定方式，本实施例不进行穷举。

另一种情况下，目标车辆的第二ECU的某一个软件模块依赖与其他一个或多个ECU，具体的是依赖于其他一个或多个ECU的软件模块的软件版本(或升级后的软件版本)，这种情况，可以将第二ECU与其他一个或多个ECU配置为一起升级。

这里，第一ECU与第二ECU可以相同可以不同。

具体来说，所述第二ECU为可以与其他相关ECU共同升级的任意一个ECU。也就是说，目标车辆中可以有多个ECU，并非全部ECU均存在相关ECU，那么这部分ECU中不存在前述第二ECU；若存在相关ECU，并且该ECU可以与其相关ECU共同升级的情况下，可以将其作为前述第二ECU。

所述运营平台，还用于在所述目标车辆的所述第二ECU具备至少一个相关ECU的情况下，针对所述目标车辆的第二ECU以及所述至少一个相关ECU确定新升级任务；其中，所述至少一个相关ECU为与所述第二ECU之间具备软件依赖关系的ECU；

所述第二OTA后台，还用于基于包含针对所述目标车辆的第二ECU以及所述至少一个相关ECU的新升级任务生成对应的更新刷写任务。

也就是说，在定义升级任务的时候，运营平台还可以针对第二ECU及其依赖的其他ECU共同进行任务定义；相应的，第二OTA后台根据任务生成针对第二ECU及其依赖的其他一个或多个ECU的更新刷写任务，以及每一个ECU对应的升级包。

关于确定第二ECU及其依赖的ECU的方式如前所述不再进行赘述。关于其他ECU本身的处理可以与前述第二ECU的同一类软件模块同一次升级相同，也不再进行赘述。

相应的，目标车辆可以根据接收到的刷写任务从CDN下载对应的升级包。

所述目标车辆，还用于基于第一ECU所对应的新目标升级包对所述N个软件模块进行升级刷写。也就是，针对每一个ECU都采用升级包对相同类型的软件模块进行刷写。

或者，

所述目标车辆，还用于基于所述第二ECU及至少一个相关ECU分别对应的新目标升级包进行升级刷写；若所述第二ECU以及所述至少一个相关ECU中存在ECU刷写失败，则所述第二ECU以及所述至少一个相关ECU联合回滚。

需要指出的是，在车辆进行第二ECU以及其依赖的其他一个或多ECU的升级刷写的过程中，若存在任意一个ECU刷写失败或无法升级，则第二ECU与其他全部ECU均回滚至之前的软件版本。

也就是第二ECU与其他ECU共同升级的处理中，若成功，则完成处理，若失败则联合回滚。

本申请的另一实施例中，

所述目标车辆，还用于软件升级启动情况下，控制电子控制单元(ECU，ElectronicControl Unit)处于通信静默状态；对第一类ECU的第一优先级的待刷写队列中的ECU进行升级；其中，所述第一优先级队列的ECU升级早于其他优先级队列的ECU；在所述第一优先级的待刷写队列中的第一类ECU完成升级的情况下，将所述第一类ECU切换至正常通信状态，并保持所述车辆中其他未完成升级的ECU处于通信静默状态。

所述目标车辆中的ECU可以为全部ECU。也就是在确定针对车辆开始进行ECU升级的情况下，将车辆中的全部ECU控制在通信静默状态。

所述第一类ECU可以为：门控相关ECU。需要理解的是，门控相关ECU可以包括一个或多个ECU。可以先预先设置车辆中哪些ECU属于第一类ECU，并且预先设置第一类ECU具备第一优先级。

所述目标车辆，还用于判断本次待刷写ECU是否包含第一类ECU；若包含，则将所述第一类ECU添加至第一优先级的待刷写队列中。

对所述车辆中包含第一类ECU的第一优先级的待刷写队列中的ECU进行升级，在对第一优先级的待刷写队列中的ECU进行升级的处理中，可以为：

在升级时，所述目标车辆，还用于控制全车通信静默，在对第一优先级的第一类ECU完成升级之后，控制第一类ECU恢复至正常通信状态；如此，可以保证在车辆升级过程中优先完成升级的ECU能够尽早恢复通信，进而可以及时响应用户需求；并且，通过以上方案可以避免由于等待全车的ECU完成升级的过程中无法对车辆进行控制所带来的安全隐患问题。

所述目标车辆，还用于在对第K-1优先级的待刷写队列中的ECU完成升级的情况下，对包含第二类ECU的第K优先级的待刷写队列中的ECU进行升级；其中，K为大于等于2的整数；将所述第K优先级的待刷写队列中的所述第二类ECU切换至高压下电状态；对处于高压下电状态的所述第二类ECU进行升级；在所述第二类ECU完成升级的情况下，将所述第二类ECU切换至正常通信状态、并切换至高压上电状态。

其中，第二类ECU可以为：高压相关ECU。需要理解的是，高压相关ECU可以由一个或多个ECU组成。

上述K大于等于2。也就是说，在第一优先级的待刷写队列完成刷写后，可以对第二优先级的待刷写队列的ECU进行刷写，依次类推直至全部优先级的待刷写队列完成刷写为止，完成本次刷写。

一种优选的示例中，K等于三，也就是可以预先设置高压相关ECU的优先级为第三优先级。

所述目标车辆，还用于在对第二类ECU进行升级之前，需要先将所述第二类ECU进行高压下电，并且保持其通信静默状态。一种优选的示例中，高压相关ECU在升级之前，将高压相关ECU进行高压下电。

需要理解的是，本实施例提供的方案中虽然仅对第一类ECU以及第二类ECU进行了相关说明。实际处理中，还可以划分更多ECU类别，以及更多优先级及其对应的待刷写队列。

一种示例中，所述目标车辆，还用于对全部优先级及其对应的待刷写队列进行升级，比如，按照优先级从高到低的顺序，依次对每一个优先级对应的待刷写队列中的ECU进行升级。并且，在依次升级的过程中，先控制全车的ECU进入通信静默状态，在第一优先级的待刷写队列完成升级的时候，第一优先级的待刷写队列中的ECU可以全部切换至正常通信状态，此时保持其他优先级的待刷写队列的ECU为通信静默状态；再对第二优先级的待刷写队列的ECU进行升级，依次类推，直至全部待刷写队列中的全部ECU完成升级为止，此时无论车辆中存在本次未升级的ECU，均可控制所述车辆恢复正常通信状态、以及正常上电状态。

进一步地，所述目标车辆中可以包括M个待刷写队列，其中，每一个待刷写队列中包含至少一个ECU；不同的待刷写队列对应不同的优先级；所述M为大于等于2的整数；所述目标车辆，还用于从所述M个待刷写队列中的第m个待刷写队列中获取第i个ECU；其中，i为大于等于1的整数，m为大于等于1且小于等于M的整数；在对所述第i个ECU进行升级的过程中、且所述第m个待刷写队列中存在未升级的ECU的情况下，从所述第m个待刷写队列中获取第i+1个ECU，对第i+1个ECU进行升级；直至所述第m个待刷写队列中不存在未升级的ECU，确定所述第m个待刷写队列完成升级。

这里，第m个待刷写队列为第m优先级的待刷写队列。

还需要指出的是，第i个ECU在刷写之前，还会判断是否与正在刷写的一个或多个ECU之间是否存在网络竞合关系(或网络竞争关系)，若不存在，则可以对第i个ECU进行刷写或升级。其他获取到的ECU也会进行相同判断，不再一一赘述。

如此，可以在进行ECU的升级的时候，进行并行刷写，减少升级时间，提升升级效率。

第二方面，本申请实施例提供了一种车辆升级控制方法，应用于第一OTA后台，如图7所示，包括：

S701：生成至少一个车辆所对应的升级包以及刷写任务；

S702：将所述至少一个车辆所对应的刷写任务发送至第一TSP；其中，所述第一TSP用于在基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；所述目标车辆为所述至少一个车辆中之一；其中，所述目标刷写任务为所述至少一个车辆对应的刷写任务中之一。

针对生产环境来说，系统中还包括下载服务器，相应的，所述方法还包括：将至少一个车辆的升级包发送至下载服务器；其中，所述下载服务器用于为所述目标车辆发送对应的目标升级包。

所述系统还包括下线检测服务器；相应的，所述方法还包括：获取下线检测服务器发来的所述至少一个车辆的升级任务；根据所述至少一个车辆的升级任务，生成所述至少一个车辆所对应的刷写任务及升级包。

第三方面还提供了一种车辆升级控制方法，应用于第一TSP，如图8所示，包括：

S801：接收第一OTA后台发来的至少一个车辆所对应的刷写任务；

S802：在基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；所述目标车辆为所述至少一个车辆中之一；所述目标刷写任务为所述至少一个车辆对应的刷写任务中之一。

也就是在EOL触发针对目标车辆的刷写任务的时候，将该目标车辆的标识可以发送到第一TSP；相应的，第一TSP从预先获取的多个车辆的多个刷写任务中选择与所述目标车辆的标识相对应的目标刷写任务，并将目标刷写任务与下发到目标车辆。

另外，上述EOL绑定车辆的ECU的相关信息以及车辆的标识的时候，EOL可以将绑定的ECU的相关信息以及车辆的标识的关系发送给第一TSP，第一TSP还可以将该信息同步给第一OTA。

再进一步地，第一OTA后台可以是将刷写任务都预先发送给第一TSP；相应的，EOL触发刷写任务的时候，可以是由第一TSP选择对应的目标任务并下发给目标车辆；

又或者，EOL可以触发刷写任务的时候，将目标车辆的标识发送给第一TSP，第一TSP将该目标车辆的标识发送给第一OTA后台；第一OTA后台基于目标车辆的标识确定对应的目标刷写任务，第一OTA后台可以将目标刷写任务ID通过第一TSP发送至目标车辆；然后目标车辆从第一TSP下载目标刷写任务。

针对生产环境还需要指出的是，第一TSP会向第一OTA后台同步产线车辆信息，关于产线车辆信息的内容可以包括：车辆的标识(VIN)等等。

关于第一TSP以及EOL的具体处理与前述第一方面的实施例相同，不再赘述。

第四方法，本实施例还提供一种车辆升级控制方法，应用于目标车辆，如图9所示，包括：

S901：处于第一环境的情况下，接收目标刷写任务；

S902：基于所述目标刷写任务获取对应的目标升级包；

S903：基于所述目标升级包进行升级。

所述目标车辆根据目标刷写任务从下载服务器下载对应的升级包；并且，所述目标车辆根据目标刷写任务中包含的升级约束条件采用所述升级包进行升级。比如，在生产环境中当目标车辆到某一个工位的时候，EOL触发针对该目标车辆下发刷写任务，目标刷写任务会通过第一TSP下发给目标车辆，然后目标车辆下载对应的目标升级包执行刷写升级的处理。

第五方面，一种车辆升级控制方法，应用于第二OTA后台，如图10所示，包括：

S1001：生成至少一个车辆的更新刷写任务及其对应的新升级包；

S1002：将所述至少一个车辆所对应的更新刷写任务发送至第二TSP；其中，所述第二TSP用于在确定对所述目标车辆进行升级的情况下，向所述目标车辆发送对应的目标更新刷写任务；所述目标车辆为所述至少一个车辆中之一；其中，所述目标更新刷写任务为所述至少一个车辆对应的更新刷写任务中之一。

另外，所述方法还包括：

将至少一个车辆的升级包发送至CDN；其中，所述CDN用于为所述目标车辆发送对应的新升级包。

所述第二OTA后台根据所述至少一个车辆的ECU所对应的新升级任务，生成所述至少一个车辆的更新刷写任务及其对应的新升级包。

这里，所述运营平台可以理解为用于控制第二OTA后台，或者与远端进行交互的一个前端的用于展示以及内容监控、以及信息输入或定义的设备。通过运营平台可以使得运维人员进行直接的界面化的操作。

关于新升级任务与上述生产环境中的升级任务的不同之处在于，新升级任务若与生产环境的升级任务针对同一个ECU进行定义的时候，版本是不同的，或者新升级任务中的ECU的软件版本高于生产环境的升级任务中的ECU的软件版本。另外，新升级任务中还可能存在一部分车辆刚刚更换的ECU所对应的软件的最新版本。

相应的，第二OTA基于新升级任务生成更新刷写任务以及新升级包的内容，可以与前述生产环境中的刷写任务与升级包的内容以及关系类似这里不再赘述。

所述方法还可以包括：

所述第二OTA后台基于产品质量服务器(QCloud)上传的所述至少一个车辆的变更信息、以及所述至少一个车辆的ECU所对应的新升级任务，生成所述至少一个车辆的更新刷写任务及其对应的新升级包。

车辆变更信息可以是每次车辆出现变更零件比如ECU更换的时候，同步至产品质量服务器中的。和/或，车辆变更信息还可以包括车辆的当前版本的上报和/或备份版本等内容。

另外，第二OTA后台获取到的车辆变更信息可以除了从产品质量服务器获取到之外，还可以是车辆本身通过第二TSP上传给第二OTA后台；或者，还可以通过其他途径传输到第二OTA后台，本实施例不做穷举。

进一步地，第二OTA后台可以及时获取到车辆的变更信息、以及结合预先定义的升级任务，生成针对车辆的更新刷写任务及其对应的新升级包。当然，可能存在部分车辆未上报对应的更新信息，那么第二OTA后台针对这部分车辆就根据新升级任务生成对应的更新刷写任务以及新升级包即可。

相应的，若获取到车辆变更信息，那么第二OTA后台可以根据车辆的当前版本和/或备份版本，确定刷写任务对应了更新后的新升级包之外是否还需要对应针对车辆的更新后的备份版本。基于此，生成针对车辆的刷写任务及其对应的新升级包。

另外，第二OTA后台在进行升级包的生成的时候，所述方法还包括：

接收运营平台发来的针对所述至少一个车辆的目标车辆的第一ECU的N个软件模块的新升级任务；N为大于等于1的整数；其中，所述N个软件模块为同一类软件模块；

基于包含针对所述目标车辆的第一ECU的N个软件模块的新升级任务生成对应的新目标升级包。

所述软件模块包括以下类型中至少一种：系统类软件模块、应用类软件模块、数据类软件模块。

所述方法还包括：

接收所述运营平台发来的针对所述目标车辆的第一ECU以及所述至少一个相关ECU确定新升级任务；其中，所述至少一个相关ECU为与所述第一ECU之间具备软件依赖关系的ECU；

基于包含针对所述目标车辆的第一ECU以及所述至少一个相关ECU的新升级任务生成对应的目标更新刷写任务。

上述目标车辆可以为至少一个车辆中的任意一个车辆。

第一ECU可以为目标车辆中多个ECU中的任意一个，针对每一个ECU都可以采用相同的处理，因此不再一一赘述。

以上处理中，不再将同一个ECU的全部升级在一次执行，可以对同一个ECU的升级任务进行组合，在一次升级任务中仅针对同一类软件模块进行定义，比如，当前可能存在M个系统类软件模块需要升级，在一次升级任务的定义中，可以仅定义升级其中的N个系统类软件模块。

需要指出的，在一次针对一个ECU进行定义的时候，仅能够组合相同类型的软件模块，不会针对其不同类型的软件模块进行组合的定义。

比如，在针对第一ECU的任务定义中，可以包括系统包名、配置信息、本次任务中升级的软件模块名1-n，以及具体的字段的定义，比如可以包括零件信息(partinfo)以及更新信息(updateinfo)两部分内容，其中，更新信息中包含了每一个软件模块的相关信息，比如，包括软件模块的类型、依赖关系等等。

其中，软件模块的类型可以为类型对应的编号，比如，0可以是系统包、1可以是应用包、2可以是数据包；当然，还可以存在其他类型的划分，以及与上述不同的编号对应关系，这里不再穷举。

在针对第一ECU的一次任务定义中，软件模块名1-n应该都是同一个软件模块的类型的，比如软件模块的类型对应的编号可以都是0或都是1等等。

上述依赖关系可以指的是，每一个软件模块依赖的本ECU(也就是第一ECU)的其他软件版本、每一个软件模块依赖的其他ECU的软件版本的关系中至少之一。

也就是一种情况下，第一ECU的某一个软件模块仅定义了与本ECU的其他软件模块之间的依赖关系，那么可以将第一ECU的某一个软件模块与其依赖的软件模块一起升级，需要指出的是，如果其依赖的软件模块与其类型相同，可以在本次一起升级；否则，可以在该软件模块升级之前，需要先升级其依赖的软件模块才可以执行。

进一步地，这种情况中，所述方法还包括：

确定针对所述第一ECU的N个软件模块的新升级包为全量包或差量包，生成针对第一ECU的全量新升级包或差量新升级包。

具体的，在进行升级包的生成的时候，可以判断第一ECU升级为全量升级包还是差分升级包，可以是根据运维人员的设定来确定的，比如，运维人员可以设置，针对目标车辆进行全量升级，那么此时就会生成全量升级包；或者，针对目标车辆的部分ECU进行全量升级，另一部分ECU进行差分升级，此时可以根据第一ECU具体被设置的情况，来确定生成对应的全量或差分升级包。

又或者，可以是根据第一ECU的当前情况来自动确定的，比如，预先可以由目标车辆上传当前的软件版本，第二OTA后台可以根据目标车辆的第一ECU的当前软件版本的情况来确定是否生成全量升级包或差分升级包。比如，第一ECU的软件版本出现问题或存在漏洞，需要进行全量升级，可以为其生成全量升级包；或者，第一ECU的当前软件版本仅需要进行差分升级，那么就为其生成差分升级包。

当然，还可能存在其他确定方式，本实施例不进行穷举。

另一种情况下，第二ECU的某一个软件模块依赖与其他一个或多个ECU，具体的是依赖于其他一个或多个ECU的软件模块的软件版本(或升级后的软件版本)，这种情况，可以将第二ECU与其他一个或多个ECU配置为一起升级。

与其第二OTA后台的处理相对应的，本申请实施例如图11所示，还提供了一种车辆升级控制方法，应用于第二TSP，包括：

S1101：接收第二OTA后台发来的至少一个车辆所对应的更新刷写任务；

S1102：向所述目标车辆发送其标识对应的目标更新刷写任务；所述目标车辆为所述至少一个车辆中之一；所述目标更新刷写任务为所述至少一个车辆对应的更新刷写任务中之一。

关于第二TSP的处理与前述实施例相同，这里不再重复说明。

第六方面，一种车辆升级控制方法，应用于目标车辆，如图12所示，包括：

S1201：处于第二环境的情况下，接收目标更新刷写任务；

S1202：基于所述目标更新刷写任务下载对应的新目标升级包；

S1203：基于所述新目标升级包进行升级。

在目标车辆进行升级包的升级之前，所述方法还包括：

在唤醒模块收到唤醒指令的情况下，向OTA组件发起唤醒请求并向电源管理模块发起持续上电请求。

以及，

唤醒模块向OTA组件发起升级请求；在所述OTA组件确定具备升级条件的情况下，切换至升级模式进行刷写，以及向唤醒模块发送升级请求响应成功的信息；以及向电源管理模块发送持续上电请求；所述唤醒模块接收到送升级请求响应成功的信息后，停止向电源管理模块发送持续上电请求；

或者，唤醒模块向OTA组件发起升级请求，在所述OTA组件确定不具备升级条件的情况下，向所述唤醒模块发送升级请求响应失败的信息；所述唤醒模块接收到所述OTA组件的升级请求响应失败的信息，停止向电源管理模块发送持续上电请求。

也就是说，唤醒模块接收到送升级请求响应成功的信息后，停止向电源管理模块发送持续上电请求；或者，接收到升级请求响应失败的信息，停止向电源管理模块发送持续上电请求。

具体可以结合图13进行说明：目标车辆接收唤醒指令(可以为远程或本地唤醒)；然后唤醒模块确定准备请求升级，对电源管理模块、OTA组件以及主控节点进行网络唤醒。其中，主控节点可以是OTA的主控节点，OTA组件可以是安装在部分ECU上的软件模块。

然后唤醒模块向电源管理模块请求持续上电，此时电源管理模块为唤醒模块、OTA组件所对应的ECU以及主控节点上电。

唤醒模块箱OTA组件发送升级请求，此时OTA组件向主控节点检测是否具备升级条件。

在OTA组件确定具备升级条件的情况下，OTA组件可以开始升级，此时，OTA组件切换至升级模式。比如OTA组件对应的至少一个ECU可以根据预先下载的升级包对ECU进行刷写升级。同样可以在图13中看出，在这种情况下，唤醒模块可以停止持续上电请求，此时向电源管理模块发送持续上电请求具体可以是由OTA组件中的主控节点来执行的。

另外，OTA组件开始升级的时候，可以向唤醒模块发送升级请求响应成功的信息；相应的，唤醒模块可以停止向电源管理模块发送持续上电请求。也就是说，此时唤醒模块可以不再上电或不再进行控制，而是由OTA组件完成刷写。进一步地，在OTA组件完成刷写之后，还可以停止向电源管理模块获取供电维持，此时可以全车下电。当然，也可以根据用户的操作全车上电进行后续的自动驾驶等处理，不再赘述。

另一种情况中，OTA组件在确定不具备升级条件的情况下，向所述唤醒模块发送升级请求响应失败的信息；相应的，唤醒模块可以停止向电源管理模块发送持续上电请求。此时，OTA组件也停止从电源管理模块请求持续上电，也就是无法进行升级，即无法响应本次升级唤醒，OTA组件，可以将响应失败的原因上报至OTA后台(比如第二OTA后台)，然后进行下电，也就是此时可以全车下电。当然，也可以根据用户的操作全车上电进行后续的自动驾驶等处理，不再赘述。

所述方法还包括：

基于第一ECU所对应的新目标升级包对所述N个软件模块进行升级刷写；

或者，

基于第二ECU及至少一个相关ECU分别对应的新目标升级包进行升级刷写；若所述第二ECU以及所述至少一个相关ECU中存在ECU刷写失败，则所述第二ECU以及所述至少一个相关ECU联合回滚。

也就是，针对每一个ECU都采用升级包对相同类型的软件模块进行刷写。

或者，

所述目标车辆基于第二ECU及至少一个相关ECU分别对应的升级包进行升级刷写；若所述第二ECU以及所述至少一个相关ECU中存在ECU刷写失败，则所述第二ECU以及所述至少一个相关ECU联合回滚。

需要指出的是，在车辆进行第二ECU以及其依赖的其他一个或多ECU的升级刷写的过程中，若存在任意一个ECU刷写失败或无法升级，则第二ECU与其他全部ECU均回滚至之前的软件版本。也就是第二ECU与其他ECU共同升级的处理中，若成功，则完成处理，若失败则联合回滚。

第七方面，提供了一种第一OTA后台，如图14所示，包括：

第一处理模块1301，用于生成至少一个车辆所对应的升级包以及刷写任务；

第一传输模块1302，用于将所述至少一个车辆所对应的刷写任务发送至第一TSP；其中，所述第一TSP用于在基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；所述目标车辆为所述至少一个车辆中之一。

所述第一传输模块1302，用于将至少一个车辆的升级包发送至下载服务器；其中，所述下载服务器用于为所述目标车辆发送对应的目标升级包。

本实施例中第一OTA后台的处理与前述实施例相同，不再重复说明。

第八方面，提供了一种第一TSP，如图15所示包括：

第二传输模块1401，用于接收第一OTA后台发来的至少一个车辆所对应的刷写任务；在确定目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；所述目标车辆为所述至少一个车辆中之一。

本实施例中第一TSP的处理与前述实施例相同，不再重复说明。

第九方面，提供了一种目标车辆，如图16所示，包括：

第三传输模块1501，用于处于第一环境的情况下，接收目标刷写任务；

第一下载模块1502，用于基于所述目标刷写任务获取对应的目标升级包；

第一升级控制模块1503，用于基于所述目标升级包进行升级。

本实施例目标车辆的处理与前述实施例生产系统中的目标车辆的处理相同，不再重复说明。

第十方面，提供了一种第二OTA后台，如图17所示，包括：

第二处理模块1601，用于生成至少一个车辆的更新刷写任务及其对应的新升级包；

第四传输模块1602，用于将所述至少一个车辆所对应的更新刷写任务发送至第二TSP；其中，所述第二TSP用于在确定对所述目标车辆进行升级的情况下，向所述目标车辆发送对应的目标更新刷写任务；所述目标车辆为所述至少一个车辆中之一。

第十一方面，提供了一种目标车辆，如图18所示，包括：

第五传输模块1701，用于处于第二环境的情况下，接收目标更新刷写任务；

第二下载模块1702，用于基于所述目标更新刷写任务获取对应的新目标升级包；

第二升级控制模块1703，用于基于所述新目标升级包进行升级。

所述目标车辆还包括：唤醒模块1704、电源管理模块1705；其中，

所述唤醒模块1704，用于收到唤醒指令的情况下，向电源管理模块发起唤醒请求，以及向OTA组件发起唤醒请求；以及从电源管理模块发起持续上电请求；

所述电源管理模块1705，用于基于唤醒模块的请求，为所述唤醒模块、OTA组件进行供电。

所述目标车辆还包括：OTA组件1706；其中，

所述唤醒模块1704，还用于向OTA组件发起升级请求；

所述OTA组件1706，用于根据升级请求检测是否具备升级条件。

所述OTA组件1706，还用于在确定具备升级条件的情况下，切换至升级模式进行刷写，以及向唤醒模块发送升级请求响应成功的信息；以及向电源管理模块发送持续上电请求；或者，在确定不具备升级条件的情况下，向所述唤醒模块发送升级请求响应失败的信息；

相应的，所述唤醒模块1704，用于接收到送升级请求响应成功的信息后，停止向电源管理模块发送持续上电请求；或者，接收到升级请求响应失败的信息，停止向电源管理模块发送持续上电请求。

所述第二升级控制模块1703，用于基于第一ECU所对应的新目标升级包对所述N个软件模块进行升级刷写；

或者，

基于所述第一ECU及至少一个相关ECU分别对应的新目标升级包进行升级刷写；若所述第一ECU以及所述至少一个相关ECU中存在ECU刷写失败，则所述第一ECU以及所述至少一个相关ECU联合回滚。

本实施例中目标车辆的处理与前述实施例相同，不再详细说明。

本实施例还提供一种第二TSP，如图19所示，包括：

第六传输模块1801，用于接收第二OTA后台发来的至少一个车辆所对应的更新刷写任务；以及向所述目标车辆发送其标识对应的目标更新刷写任务；所述目标车辆为所述至少一个车辆中之一；所述目标更新刷写任务为所述至少一个车辆对应的更新刷写任务中之一。

本实施例中第二TSP的处理与前述实施例相同，不再详细说明。

根据本申请的实施例，本申请还提供了一种车辆、第一OTA后台、第二OTA后台和一种可读存储介质。

如图20所示，是根据本申请实施例的车辆、OTA后台(或第一OTA后台或第二OTA后台)的框图。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图20所示，该车辆包括：一个或多个处理器1901、存储器1902，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在车辆内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个车辆，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图20中以一个处理器1901为例。

存储器1902即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的车辆升级控制方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的车辆升级控制方法。

存储器1902作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的车辆升级控制方法对应的程序指令/模块。处理器1901通过运行存储在存储器1902中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的车辆升级控制方法。

存储器1902可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据车辆的使用所创建的数据等。此外，存储器1902可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器1902可选包括相对于处理器1901远程设置的存储器，这些远程存储器可以通过网络连接至车辆。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

车辆还可以包括：输入装置1903和输出装置1904。处理器1901、存储器1902、输入装置1903和输出装置1904可以通过总线或者其他方式连接，图5中以通过总线连接为例。

输入装置1903可接收输入的数字或字符信息，以及产生与车辆的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置1904可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims (21)

1.一种车辆升级控制系统，包括：第一空中下载技术OTA后台、第二OTA后台、下载服务器、内容分发网络CDN以及目标车辆；其中，

所述第一OTA后台，用于生成至少一个车辆所对应的升级包以及刷写任务，以及将所述至少一个车辆所对应的升级包发送至下载服务器；所述刷写任务包括至少一个所述升级包的下载地址；

所述第二OTA后台，用于生成至少一个车辆的更新刷写任务及其对应的新升级包，以及将所述至少一个车辆所对应的所述新升级包发送至所述CDN；所述更新刷写任务包括至少一个所述新升级包的下载地址；

所述下载服务器，用于接收并保存所述第一OTA后台发来的至少一个车辆所对应的所述升级包；以及为所述目标车辆提供目标升级包；

所述CDN，用于接收并保存第二OTA后台发来的至少一个车辆所对应的所述新升级包；以及为所述目标车辆提供新目标升级包；

所述目标车辆，用于处于第一环境的情况下，基于目标刷写任务，从所述下载服务器下载对应的所述目标升级包并进行升级处理；以及处于第二环境的情况下，基于目标更新刷写任务，从所述CDN下载对应的所述新目标升级包并进行升级处理；其中，所述新目标升级包与所述目标升级包中对应ECU的软件版本不同；所述目标刷写任务为所述至少一个车辆对应的刷写任务中之一；所述目标更新刷写任务为所述至少一个车辆对应的更新刷写任务中之一。

2.根据权利要求1所述的系统，其特征在于，所述系统还包括：第一内容服务平台TSP、第二TSP；其中，

所述第一TSP，用于获取至少一个车辆的刷写任务；以及在基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识的情况下，向所述目标车辆发送其标识对应的目标刷写任务；

所述第二TSP，用于向所述目标车辆发送对应的目标更新刷写任务。

3.根据权利要求2所述的系统，其特征在于，所述系统还包括：

下线检测服务器，用于获取至少一个ECU的相关信息，以及确定至少一个车辆的升级任务；其中，所述升级任务中包含车辆的标识、以及至少一个ECU对应的升级包的版本信息；将所述至少一个车辆的升级任务通过所述第一TSP发送至所述第一OTA后台；

所述第一OTA后台，用于根据所述至少一个车辆的升级任务，生成所述至少一个车辆所对应的刷写任务及升级包。

4.根据权利要求3所述的系统，其特征在于，

所述下线检测服务器，还用于在所述目标车辆处于第一环境的情况下，基于目标车辆的至少一个ECU的相关信息确定所述目标车辆的标识，并基于所述目标车辆的标识触发所述第一TSP向所述目标车辆发送目标刷写任务。

5.根据权利要求4所述的系统，其特征在于，所述系统，还包括：

运营平台，用于确定至少一个车辆的ECU所对应的新升级任务，将所述至少一个车辆的ECU所对应的新升级任务推送至第二OTA后台；

所述第二OTA后台，用于根据所述至少一个车辆的ECU所对应的新升级任务，生成所述至少一个车辆的更新刷写任务及其对应的新升级包。

6.根据权利要求5所述的系统，其特征在于，所述系统还包括：

产品质量服务器，用于同步至少一个车辆变更信息至所述第二TSP；其中，所述车辆变更信息用于表征车辆的最新状态信息；

所述第二TSP，用于将至少一个车辆的变更信息发送至所述第二OTA后台；

所述第二OTA后台，用于基于所述至少一个车辆的变更信息、以及所述至少一个车辆的ECU所对应的新升级任务，生成所述至少一个车辆的更新刷写任务及其对应的新升级包。

7.根据权利要求6所述的系统，其特征在于，所述系统，还包括：

诊断仪后台，用于向诊断仪发送诊断序列以及诊断任务；以及获取所述诊断仪反馈的所述目标车辆的诊断结果，将所述诊断结果同步至产品质量服务器；

诊断仪，用于基于所述诊断序列以及诊断序列对目标车辆进行诊断，得到所述目标车辆的诊断结果。

8.根据权利要求7所述的系统，其特征在于，所述系统还包括：

远程诊断仪后台，用于通过所述第二TSP向目标车辆发送诊断序列，并获取到对应的诊断结果，将所述诊断结果同步至所述产品质量服务器。

9.根据权利要求6所述的系统，其特征在于，所述系统，还包括：

终端设备，用于下载所述目标车辆的新目标升级包或目标升级包；在与所述目标车辆建立通信连接的情况下，将所述新目标升级包或目标升级包发送至所述目标车辆；

所述目标车辆，还用于从所述终端设备获取所述新目标升级包或目标升级包。

10.根据权利要求9所述的系统，其特征在于，所述终端设备，还用于对所述目标车辆进行升级控制；其中，所述升级控制包括：对所述目标车辆进行立即升级或预约升级；

相应的，所述目标车辆，还用于根据终端设备的所述升级控制，基于下载的新目标升级包或目标升级包进行升级；或者，基于终端设备的预约升级控制在预约时间进行升级。

11.根据权利要求1-10任一项所述的系统，其特征在于，所述系统还包括：车辆软件平台VSP，用于为所述第一OTA后台以及所述第二OTA后台提供升级包及其版本信息、以及ECU的相关信息。

12.根据权利要求1-10任一项所述的系统，其特征在于，所述系统还包括：用户管理系统USS，用于对运维人员进行账号鉴权处理；以及针对所述运维人员的登录状态进行管理。

13.根据权利要求8所述的系统，其特征在于，

所述第二OTA后台与所述第二TSP之间通过开放应用程序接口API进行连接；

所述远程诊断仪后台与所述第二TSP之间通过开放API进行连接；

所述下线检测服务器与所述第一TSP之间通过开放API进行连接；

所述第一OTA后台与所述第一TSP之间通过开放API进行连接；

所述诊断仪与所述目标车辆之间通过UDS协议进行通信。

14.根据权利要求1-10任一项所述的系统，其特征在于，所述目标车辆，包括：唤醒模块、电源管理模块；其中，

所述唤醒模块，用于收到唤醒指令的情况下，向电源管理模块发起唤醒请求，以及向OTA组件发起唤醒请求；以及从所述电源管理模块发起持续上电请求；

所述电源管理模块，用于基于所述唤醒模块的请求，为至少一个ECU进行供电。

15.根据权利要求14所述的系统，其特征在于，所述目标车辆还包括：OTA组件；其中，

所述唤醒模块，还用于向所述OTA组件发起升级请求；

所述OTA组件，用于根据升级请求检测是否具备升级条件。

16.根据权利要求15所述的系统，其特征在于，

所述OTA组件，还用于在确定具备升级条件的情况下，切换至升级模式进行刷写，以及向所述唤醒模块发送升级请求响应成功的信息；以及向所述电源管理模块发送持续上电请求；或者，在确定不具备升级条件的情况下，向所述唤醒模块发送升级请求响应失败的信息；

相应的，所述唤醒模块，用于接收到送升级请求响应成功的信息后，停止向所述电源管理模块发送持续上电请求；或者，接收到升级请求响应失败的信息，停止向所述电源管理模块发送持续上电请求。

17.根据权利要求5所述的系统，其特征在于，

所述运营平台，用于针对所述目标车辆的第一ECU的N个软件模块确定新升级任务；N为大于等于1的整数；其中，所述N个软件模块为同一类软件模块；

相应的，所述第二OTA后台，用于基于包含针对所述目标车辆的第一ECU的N个软件模块的新升级任务生成对应的新目标升级包。

18.根据权利要求17所述的系统，其特征在于，所述软件模块包括以下类型中至少一种：系统类软件模块、应用类软件模块、数据类软件模块。

19.根据权利要求18所述的系统，其特征在于，

所述第二OTA后台，还用于确定针对所述第一ECU的N个软件模块的新升级包为全量包或差量包，生成针对所述第一ECU的全量新升级包或差量新升级包。

20.根据权利要求18所述的系统，其特征在于，

所述运营平台，还用于在所述目标车辆的第二ECU具备至少一个相关ECU的情况下，针对所述目标车辆的第二ECU以及所述至少一个相关ECU确定新升级任务；其中，所述至少一个相关ECU为与所述第一ECU之间具备软件依赖关系的ECU；

所述第二OTA后台，还用于基于包含针对所述目标车辆的第二ECU以及所述至少一个相关ECU的新升级任务生成对应的更新刷写任务。

21.根据权利要求20所述的系统，其特征在于，

所述目标车辆，还用于基于所述第一ECU所对应的新目标升级包对所述N个软件模块进行升级刷写；

和/或，

所述目标车辆，还用于基于所述第二ECU及至少一个相关ECU分别对应的新目标升级包进行升级刷写；若所述第二ECU以及所述至少一个相关ECU中存在ECU刷写失败，则所述第二ECU以及所述至少一个相关ECU联合回滚。

Images