CN117873533A - 基于升级包并行刷写的方法和装置 - Google Patents

Abstract

本申请涉及计算机技术领域，提供了一种基于升级包并行刷写的方法和装置。该方法包括：接收升级信号，基于升级信号向云端发送升级请求，接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别；按照各缓存区与ECU之间的对应关系，将升级数据按照升级组别分别缓存至对应的缓存区；响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，将升级数据按照升级组别刷写至对应的ECU，得到写入结果；将写入结果发送至目标终端并显示。本申请提供的基于升级包并行刷写的方法，能够实现分区并行刷写，在同一时间段内刷写效率高，减少刷写时间，同时减少升级数据之间互相干扰、写入过程受到污染的影响。

Description

基于升级包并行刷写的方法和装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种基于升级包并行刷写的方法和装置。

背景技术

现有技术中，空中升级(Over The Air，OTA)技术是指通过远程无线方式对当前车载系统、软件或硬件控制等数据及应用进行远程管理，能够实现智能终端的系统升级、优化等。

然而，随着用户需求及系统更新需求越来越大的增长量，车辆的升级包数据量增大，将OTA升级包下发并安装升级可能存在升级时间长、安装慢等状况，引起用户对OTA升级的不满，用户体验较差。

发明内容

有鉴于此，本申请实施例提供了一种基于升级包并行刷写方法和装置，以解决现有技术中通过OTA进行升级时速度较慢的问题。

本申请实施例的第一方面，提供了一种基于升级包并行刷写的方法，包括：

接收升级信号，基于升级信号向云端发送升级请求，接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别，预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一预设组别在TBOX中对应一个存储升级数据的缓存区，每一ECU对应一个缓存区；

按照各缓存区与ECU之间的对应关系，将升级数据按照升级组别分别缓存至对应的缓存区；

响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，将升级数据按照升级组别刷写至对应的ECU，得到写入结果；

将写入结果发送至目标终端并显示。

本申请实施例的第二方面，提供了一种基于升级包并行刷写的装置，包括：

接收模块，被配置为接收升级信号，基于升级信号向云端发送升级请求，接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别，预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一预设组别在TBOX中对应一个存储升级数据的缓存区，每一ECU对应一个缓存区；

缓存模块，被配置为按照各缓存区与ECU之间的对应关系，将升级数据按照升级组别分别缓存至对应的缓存区；

刷写模块，被配置为响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，将升级数据按照升级组别刷写至对应的ECU，得到写入结果；

显示模块，被配置为将写入结果发送至目标终端并显示。

本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并且可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。

本申请实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例与现有技术相比存在的有益效果是：接收升级信号，根据升级信号向云端发送升级请求，接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别，其中，预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一预设组别在TBOX中对应有一存储升级数据的缓存区，每一ECU对应一个缓存区。将升级数据按照升级组别分别缓存至对应的缓存区，响应于监测到任一缓存区存在有升级数据，调用缓存区对应的升级流程，将升级数据按照升级组别刷写至对应的ECU，得到写入结果，从而实现分区并行刷写，在同一时间段内刷写效率高，减少刷写时间，并且每个缓存区将升级数据写入ECU的过程是相互独立的，减少升级数据之间互相干扰、写入过程受到污染的影响。

附图说明

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

图1是本申请实施例的一种应用场景的场景示意图；

图2是本申请实施例提供的一种基于升级包并行刷写的方法的流程示意图；

图3是本申请实施例提供的一种基于升级包并行刷写的装置示意图；

图4是本申请实施例提供的电子设备的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

下面将结合附图详细说明根据本申请实施例的一种基于升级包并行刷写的方法和装置。

图1是本申请实施例的一种应用场景的场景示意图。该应用场景可以包括第一终端设备101、第二终端设备102和第三终端设备103、服务器104以及网络105。

第一终端设备101、第二终端设备102和第三终端设备103可以是硬件，也可以是软件。当第一终端设备101、第二终端设备102和第三终端设备103为硬件时，其可以是具有显示屏且支持与服务器104通信的各种电子设备，包括但不限于车载电脑、车载计算机、智能手机、平板电脑、膝上型便携计算机和台式计算机等；当第一终端设备101、第二终端设备102和第三终端设备103为软件时，其可以安装在如上所述的电子设备中。第一终端设备101、第二终端设备102和第三终端设备103可以实现为多个软件或软件模块，也可以实现为单个软件或软件模块，本申请实施例对此不作限制。进一步地，第一终端设备101、第二终端设备102和第三终端设备103上可以安装有各种应用，例如数据处理应用、即时通信工具、社交平台软件、搜索类应用、购物类应用等。

服务器104可以是提供各种服务的服务器，例如，对与其建立通信连接的终端设备发送的请求进行接收的后台服务器，该后台服务器可以对终端设备发送的请求进行接收和分析等处理，并生成处理结果。服务器104可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者还可以是一个云计算服务中心，本申请实施例对此不作限制。

需要说明的是，服务器104可以是硬件，也可以是软件。当服务器104为硬件时，其可以是为第一终端设备101、第二终端设备102和第三终端设备103提供各种服务的各种电子设备。当服务器104为软件时，其可以是为第一终端设备101、第二终端设备102和第三终端设备103提供各种服务的多个软件或软件模块，也可以是为第一终端设备101、第二终端设备102和第三终端设备103提供各种服务的单个软件或软件模块，本申请实施例对此不作限制。

网络105可以是采用同轴电缆、双绞线和光纤连接的有线网络，也可以是无需布线就能实现各种通信设备互联的无线网络，例如，蓝牙(Bluetooth)、近场通信(Near FieldCommunication，NFC)、红外(Infrared)等，本申请实施例对此不作限制。

需要说明的是，第一终端设备101、第二终端设备102和第三终端设备103、服务器104以及网络105的具体类型、数量和组合可以根据应用场景的实际需求进行调整，本申请实施例对此不作限制。

图2是本申请实施例提供的一种基于升级包并行刷写的方法的流程示意图。如图2所示，该基于升级包并行刷写的方法包括以下步骤：

S201，接收升级信号，基于升级信号向云端发送升级请求，接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别；

S202，按照各缓存区与ECU之间的对应关系，将升级数据按照升级组别分别缓存至对应的缓存区；

S203，响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，将升级数据按照升级组别刷写至对应的ECU，得到写入结果；

S204，将写入结果发送至目标终端并显示。

其中，预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一预设组别在TBOX中对应一个存储升级数据的缓存区，每一ECU对应一个缓存区。

图2的基于升级包并行刷写的方法可以由图1的第一终端设备、第二终端设备或第三终端设备执行，其中，第一终端设备、第二终端设备或第三终端设备中包括有ECU及安装包，云端用于将安装包发送至对应的终端设备。

车端接收升级信号，并根据升级信号向云端发送升级请求，其中，升级信号可以是云端发送的升级信号，也可以是用户通过终端设备发送的升级信号。

接收云端根据升级请求发送的升级数据，并分析升级数据，得到本次进行升级的升级数据在预设组别中对应的升级组别，其中，预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一预设组别在TBOX中对应一个存储升级数据的缓存区，每一ECU对应一个缓存区。

其中，电控单元(Electronic Control Unit，ECU)是发动机的综合控制装置，用于根据自身存储的程序对发动机各传感器输入的各种信息进行运算、处理、判断、然后输出指令，控制有关执行器动作，达到快速、准确、自动控制发动机工作的目的。

其中，控制任务包括安全域控制任务、车辆运动域控制任务、智能信息域控制任务、辅助驾驶域控制任务及车身电子域控制任务，资源参数为基于用户自定义组别获取的资源参数。控制任务对应硬件类的升级任务，资源参数对应软件类的升级任务，用户可以根据个人喜好对软件进行分类，形成自定义组别，研发人员也可以对软件和硬件类的应用程序设置默认分组，默认分组可以按照上述方式进行分组，同时为用户开放更改的权限，以能够根据用户自定义组别获取资源参数，按照资源参数确定预设组别。

响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，将升级数据按照升级组别刷写至对应的ECU，得到写入结果，写入结果包括写入成功和写入失败，也可以包括写入路径，例如：车身控制域已写入成功。

将写入结果发送至目标终端并显示，以使车端用户了解写入结果。

根据本申请实施例提供的技术方案，将升级数据分别缓存至对应的升级组别，按照各升级组别对应的缓存区分别将升级数据写入对应的ECU，实现分区并行刷写，由不同的缓存区将升级数据分别写入对应ECU能够提高同一时间段内刷写效率，减少刷写时间，并且每个缓存区将升级数据写入ECU的过程是相互独立的，减少升级数据之间互相干扰、写入过程受到污染的影响。

在一些实施例中，接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别，包括：

接收升级数据，对升级数据进行解压及分析，得到升级数据中的组别关键字；

基于组别关键字，确定升级数据对应的升级组别。

接收升级数据，并对升级数据进行解压及分析，提取出升级数据中的组别关键字，组别关键字用于确定升级数据在预设组别中的升级组别，根据组别关键字，确定升级数据对应的升级组别。其中，也可以对不同类别采取不同的处理方式，例如，可以将升级数据按照重要性、安全性、优先级等参数进行分类，从而确保升级过程的顺利进行，并提高系统的整体性能和稳定性。

根据本申请实施例提供的技术方案，能够在缓存升级数据时将升级数据按照预设组别进行分组缓存，便于将升级数据刷写至对应的ECU时能够快速、准确的进行刷写，且将升级数据按照预设组别缓存，能够使升级数据相互独立，减少升级数据之间相互污染的可能性，若是某升级组别缓存的升级数据出现错误，将该升级组别缓存的升级数据进行处理即可，减少处理错误的升级数据的处理量，提升处理效率。

在一些实施例中，按照各缓存区与ECU之间的对应关系，将升级数据按照升级组别分别缓存至对应的缓存区，包括：

按照升级组别创建各升级组别对应的缓存子进程；

基于各缓存子进程，将升级数据分别缓存至对应的缓存区。

在各升级组别将缓存的升级数据写入对应ECU时，通过对升级数据的分析确定升级数据对应的升级组别，根据已确定的升级组别，创建各升级组别对应的缓存子进程，升级包中的升级数据根据各缓存子进程，将升级数据分别缓存至对应的缓存区。其中，缓存子进程的数量与升级组别的数量一致，每个通过升级数据确定的升级组别均对应有一缓存子进程，缓存区可以是内存、硬盘或其他存储设备，其具体形式可以根据实际需要进行选择。

根据本申请实施例提供的技术方案，能够在升级数据对应多个升级组别时，通过按照升级组别创建的缓存子进程将升级数据分别缓存至对应的缓存区，缓存子进程的数量与升级组别的数量一致，每个缓存子进程都对应有一个升级组别，从而能够将升级数据按照升级组别分类存储，使得在后续处理升级数据时更加高效和准确，同时，在升级数据对应有多个升级组别时能够将升级数据通过不同的缓存子进程同时缓存至对应的缓存区，可以实现对升级过程的并行处理，提高升级的整体性能和效率。

在一些实施例中，升级流程包括多个升级配置文件及升级进程，每一升级配置文件与每一ECU之间相互关联，升级进程基于写入队列将升级数据写入对应的ECU，写入队列包括环形队列。

升级流程包括多个升级配置文件和升级进程，其中，升级配置文件用于满足将升级数据刷写至对应的ECU所需的环境，使得升级数据能够与通过ECU运行的数据更加适配等。升级进程能够根据写入队列将升级数据写入对应的ECU，写入队列包括环形队列，也可以是其他队列，例如disruptor队列。

其中，通过环形队列将缓存区的缓存数据刷写至对应的ECU可以是将环形队列本身作为缓存区，通过槽位对环形队列进行区分，可以将升级数据作为生产者，各ECU作为消费者，缓存区与ECU相对应，利用环形队列本身的特性，在生产者写入缓存的升级数据的同时消费者消费缓存数据，实现并行刷写，同时也可以避免锁竞争和线程之间的冲突，高效的将云端下发的升级数据刷写至对应的ECU中。也可以是将各缓存区作为生产者，对应的ECU作为消费者，通过环形队列将缓存区缓存的升级数据写入对应的ECU中，能够实现较高的数据吞吐量，尤其在升级数据的数据量较大的情况下，环形队列的高吞吐量、低延迟及可扩展性能够快速处理升级数据，从而使得升级数据的刷写速度更快，提升用户体验。

在一些实施例中，响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，包括：

响应于监测到任一缓存区存在有新增的升级数据，将存在有升级数据的缓存区确定为新增缓存区，确定新增缓存区的缓存区数量；

若缓存区数量为单个，通过新增缓存区对应的CAN总线进程执行升级流程；

若缓存区数量为多个，通过分别对应各新增缓存区对应的多个CAN总线进程执行升级流程，以实现并行刷写。

响应于监测到任一缓存区存在有新增的升级数据，将存在有升级数据的缓存区确定为新增缓存区，并确定新增缓存区的缓存区数量，通过新增缓存区对应的CAN总线进程执行升级流程，其中，升级流程可以是刷写升级数据、校验升级数据等操作，具体取决的升级包中包括的升级需求及指令。

判断新增缓存区的数量是否为单个，若是，通过新增缓存区对应的CAN总线进程执行升级流程，

若否，通过分别对应各新增缓存区对应的多个CAN总线进程执行升级流程，多个CAN总线升级进程之间的运行是相互独立的。

根据本申请实施例提供的技术方案，能够在升级数据对应多个升级组别时通过不同的CAN总线进程实现并行刷写，可以提高升级效率，缩短升级时间，并且对各个缓存区进行监测，当监测到缓存区存在有未刷写完成的升级数据，通过对应的CAN总线进程执行对应的升级流程，以确保升级过程的顺利进行。

本申请提供的实施例还可以对升级结果进行校验和处理，以确保升级数据的准确性和完整性。

在一些实施例中，接收并分析升级请求对应的升级数据之前，还包括：

获取当前车辆状态对应的当前车辆状态数据，基于车辆状态数据判断当前车辆状态是否满足升级条件；

车辆状态数据包括：车辆电量、车辆的充电状态及车辆的工作状态；

若是，执行接收并分析升级请求对应的升级数据的步骤；

若否，停止接收升级数据，并将当前车辆状态发送至云端。

在接收并分级升级请求对应的升级数据之前，根据当前车辆状态数据确定当前车辆状态，以判断是否能够安全的接收升级数据并进行升级。

当前车辆状态数据是通过车辆中各传感器获取得到，以确定当前车辆状态，根据车辆状态数据判断当前车辆状态是否满足升级条件，若满足，则执行接收并分析升级请求对应的升级数据的步骤，从而开始对车辆系统进行升级，若不满足，停止接收升级数据，并将当前车辆状态发送至云端，以使云端根据当前车辆状态停止发送升级数据，并确定停止发送升级数据的原因，若出现异常数据，还可以根据当前车辆状态数据处理异常。

其中，当前车辆状态数据包括车辆电量、车辆的充电状态及车辆的工作状态。

根据本申请实施例提供的技术方案，能够根据当前车辆状态判断是否满足升级条件，这种处理方式可以确保在车辆系统的升级是在合适的时机进行的，避免了因升级过程中车辆状态不佳或无法提供足够的升级资源导致升级失败或数据损坏，同时，将当前车辆状态发送至云端也可以使云端远程监控和管理车辆状态和运行情况，及时发现和解决问题。

本申请提供的实施例中，还可以包括回滚流程，回滚流程用于在ECU刷写升级数据出现异常时被调用，其中，在将升级数据刷写到对应ECU时出现异常数据，ECU发送异常信号，车端系统响应于异常信号调用回滚流程，异常信号中记录了刷写断点，回滚流程周期性向异常ECU发送询问消息，以判断ECU是否从异常状态更新为正常状态，即可继续执行升级流程的状态，若是，调用升级流程且从记录的刷写断点开始刷写对应的缓存区中剩余的升级数据。

其中，回滚流程包括回滚进程及多个回滚配置文件，每一ECU至少对应关联一个回滚配置文件，从而能够在ECU根据升级流程写入升级数据出现异常情况时，通过回滚流程解决异常情况，若回滚流程未能解决异常情况，则通过云端寻求帮助，回滚流程能够提高升级数据刷写的成功率。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图3是本申请实施例提供的一种基于升级包并行刷写的装置示意图。如图3所示，该基于升级包并行刷写的装置包括：

接收模块301，被配置为接收升级信号，基于升级信号向云端发送升级请求，接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别，预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一预设组别在TBOX中对应一个存储升级数据的缓存区，每一ECU对应一个缓存区；

缓存模块302，被配置为按照各缓存区与ECU之间的对应关系，将升级数据按照升级组别分别缓存至对应的缓存区；

刷写模块303，被配置为响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，将升级数据按照升级组别刷写至对应的ECU，得到写入结果；

显示模块304，被配置为将写入结果发送至目标终端并显示。

在一些实施例中，接收模块301被配置为接收并分析升级请求对应的升级数据，得到升级数据在预设组别中对应的升级组别，用于：

接收升级数据，对升级数据进行解压及分析，得到升级数据中的组别关键字；

基于组别关键字，确定升级数据对应的升级组别。

在一些实施例中，缓存模块302被配置为按照各缓存区与ECU之间的对应关系，将升级数据按照升级组别分别缓存至对应的缓存区，用于：

按照升级组别创建各升级组别对应的缓存子进程；

基于各缓存子进程，将升级数据分别缓存至对应的缓存区。

在一些实施例中，升级流程包括多个升级配置文件及升级进程，每一升级配置文件与每一ECU之间相互关联，升级进程基于写入队列将升级数据写入对应的ECU，写入队列包括环形队列。

在一些实施例中，刷写模块303被配置为响应于监测到任一缓存区存在升级数据，调用缓存区对应的升级流程，用于：

响应于监测到任一缓存区存在有新增的升级数据，将存在有升级数据的缓存区确定为新增缓存区，确定新增缓存区的缓存区数量；

若缓存区数量为单个，通过新增缓存区对应的CAN总线进程执行升级流程；

若缓存区数量为多个，通过分别对应各新增缓存区对应的多个CAN总线进程执行升级流程，以实现并行刷写。

在一些实施例中，接收模块301被配置为接收并分析升级请求对应的升级数据之前，还用于：

获取当前车辆状态对应的当前车辆状态数据，基于车辆状态数据判断当前车辆状态是否满足升级条件；

车辆状态数据包括：车辆电量、车辆的充电状态及车辆的工作状态；

若是，执行接收并分析升级请求对应的升级数据的步骤；

若否，停止接收升级数据，并将当前车辆状态发送至云端。

在一些实施例中，控制任务包括安全域控制任务、车辆运动域控制任务、智能信息域控制任务、辅助驾驶域控制任务及车身电子域控制任务，资源参数为基于用户自定义组别获取的资源参数。

图4是本申请实施例提供的电子设备4的示意图。如图4所示，该实施例的电子设备4包括：处理器401、存储器402以及存储在该存储器402中并且可在处理器401上运行的计算机程序403。处理器401执行计算机程序403时实现上述各个方法实施例中的步骤。或者，处理器401执行计算机程序403时实现上述各装置实施例中各模块/单元的功能。

电子设备4可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备4可以包括但不仅限于处理器401和存储器402。本领域技术人员可以理解，图4仅仅是电子设备4的示例，并不构成对电子设备4的限定，可以包括比图示更多或更少的部件，或者不同的部件。

处理器401可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

存储器402可以是电子设备4的内部存储单元，例如，电子设备4的硬盘或内存。存储器402也可以是电子设备4的外部存储设备，例如，电子设备4上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器402还可以既包括电子设备4的内部存储单元也包括外部存储设备。存储器402用于存储计算机程序以及电子设备所需的其它程序和数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读存储介质(例如计算机可读存储介质)中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读存储介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random AccessMemory，RAM)、电载波信号、电信信号以及软件分发介质等。

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

Claims (10)

1.一种基于升级包并行刷写的方法，其特征在于，包括：

接收升级信号，基于所述升级信号向云端发送升级请求，接收并分析所述升级请求对应的升级数据，得到所述升级数据在预设组别中对应的升级组别，所述预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一所述预设组别在TBOX中对应一个存储升级数据的缓存区，每一ECU对应一个所述缓存区；

按照各所述缓存区与所述ECU之间的对应关系，将所述升级数据按照所述升级组别分别缓存至对应的所述缓存区；

响应于监测到任一所述缓存区存在所述升级数据，调用所述缓存区对应的升级流程，将所述升级数据按照所述升级组别刷写至对应的所述ECU，得到写入结果；

将所述写入结果发送至目标终端并显示。

2.根据权利要求1所述的方法，其特征在于，接收并分析所述升级请求对应的升级数据，得到所述升级数据在预设组别中对应的升级组别，包括：

接收所述升级数据，对所述升级数据进行解压及分析，得到所述升级数据中的组别关键字；

基于所述组别关键字，确定所述升级数据对应的所述升级组别。

3.根据权利要求1所述的方法，其特征在于，按照各所述缓存区与所述ECU之间的对应关系，将所述升级数据按照所述升级组别分别缓存至对应的所述缓存区，包括：

按照所述升级组别创建各所述升级组别对应的缓存子进程；

基于各所述缓存子进程，将所述升级数据分别缓存至对应的所述缓存区。

4.根据权利要求1所述的方法，其特征在于，所述升级流程包括多个升级配置文件及升级进程，每一所述升级配置文件与每一所述ECU之间相互关联，所述升级进程基于写入队列将所述升级数据写入对应的所述ECU，所述写入队列包括环形队列。

5.根据权利要求1所述的方法，其特征在于，响应于监测到任一所述缓存区存在所述升级数据，调用所述缓存区对应的升级流程，包括：

响应于监测到任一所述缓存区存在有新增的所述升级数据，将存在有所述升级数据的所述缓存区确定为新增缓存区，确定所述新增缓存区的缓存区数量；

若所述缓存区数量为单个，通过所述新增缓存区对应的CAN总线进程执行所述升级流程；

若所述缓存区数量为多个，通过分别对应各所述新增缓存区对应的多个CAN总线进程执行所述升级流程，以实现并行刷写。

6.根据权利要求1所述的方法，其特征在于，接收并分析所述升级请求对应的升级数据之前，还包括：

获取当前车辆状态对应的当前车辆状态数据，基于所述车辆状态数据判断当前所述车辆状态是否满足升级条件；

所述车辆状态数据包括：车辆电量、车辆的充电状态及所述车辆的工作状态；

若是，执行所述接收并分析所述升级请求对应的升级数据的步骤；

若否，停止接收所述升级数据，并将当前所述车辆状态发送至云端。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述控制任务包括安全域控制任务、车辆运动域控制任务、智能信息域控制任务、辅助驾驶域控制任务及车身电子域控制任务，所述资源参数为基于用户自定义组别获取的资源参数。

8.一种基于升级包并行刷写的装置，其特征在于，包括：

接收模块，被配置为接收升级信号，基于所述升级信号向云端发送升级请求，接收并分析所述升级请求对应的升级数据，得到所述升级数据在预设组别中对应的升级组别，所述预设组别为按照不同控制任务或不同资源参数进行分类得到的组别，每一所述预设组别在TBOX中对应一个存储升级数据的缓存区，每一ECU对应一个所述缓存区；

缓存模块，被配置为按照各所述缓存区与所述ECU之间的对应关系，将所述升级数据按照所述升级组别分别缓存至对应的所述缓存区；

刷写模块，被配置为响应于监测到任一所述缓存区存在所述升级数据，调用所述缓存区对应的升级流程，将所述升级数据按照所述升级组别刷写至对应的所述ECU，得到写入结果；

显示模块，被配置为将所述写入结果发送至目标终端并显示。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并且可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述方法的步骤。