CN116909609B - 车载智能设备的软件升级方法、装置及车载智能设备 - Google Patents

Abstract

本发明公开了一种车载智能设备的软件升级方法、装置及车载智能设备，属于软件升级技术领域。该方法包括：接收升级指令，其中，该升级指令包括第一升级文件，且由车载智能设备的主处理器下发；响应于升级指令，用第一升级文件替换从处理器的片外缓存区的第一历史文件，并对片外缓存区写入的第一升级文件进行完整性校验；在校验失败的情况下，运行从处理器的运行缓存区的第一历史文件；在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区；在更新成功的情况下，生成升级成功消息。如此，能够确保即使升级过程出现异常，也不会影响从处理器的正常运行，不影响用户对车辆的使用，提高了软件升级的可靠性。

Description

车载智能设备的软件升级方法、装置及车载智能设备

技术领域

本发明涉及软件升级技术领域，尤其涉及车载智能的设备的软件升级方法、装置及车载智能设备。

背景技术

随着车联网的发展和普及，车载智能设备的OTA（Over The Air Technology，车载系统在线升级技术）升级功能被主机厂大幅采用，通过远程OTA功能，可以通过云服务平台对车辆的各个ECU（Electronic Control Unit，车载电脑）进行远程升级，这样大大的降低了软件升级的成本，同时给软件带升级来了便捷。

但现有的车载智能设备的软件升级都是单处理器升级，对于双处理器升级的车载智能设备，亟需合适的软件升级方法来提高双处理器的软件升级的可靠性。

发明内容

为此，本发明提出了车载智能设备的软件升级方法，还提出了车载智能设备的软件升级装置、一种车载智能设备、一种计算设备和一种计算机可读存储介质，旨在至少在一定程度上解决相关技术中双处理器的软件升级的可靠性低的技术问题。

为达到上述目的，本发明第一方面实施例提出了一种车载智能设备的软件升级方法，应用于车载智能设备的从处理器，该方法包括：

接收升级指令，其中，升级指令包括第一升级文件，且由车载智能设备的主处理器下发；

响应于升级指令，用第一升级文件替换从处理器的片外缓存区的第一历史文件，并对片外缓存区写入的第一升级文件进行完整性校验；

在校验失败的情况下，运行从处理器的运行缓存区的第一历史文件；

在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区；

在更新成功的情况下，生成升级成功消息。

根据本发明的一个实施例，在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区之后，还包括：

在更新失败的情况下，向主处理器上报更新失败信息；

接收主处理器向运行缓存区写入的第一升级文件；

在写入成功的情况下，生成升级成功消息。

根据本发明的一个实施例，接收主处理器向运行缓存区写入的第一升级文件之后，还包括：

在写入失败的情况下，从主处理器的备份区获取从处理器的第一历史文件；

基于第一历史文件对从处理器进行升级。

根据本发明的一个实施例，基于第一历史文件对从处理器进行升级之后，还包括：

在升级成功的情况下，生成升级成功消息反馈至主处理器，以使主处理器备份第一历史文件并将第一历史文件的版本号上报至云服务平台。

为达到上述目的，本发明第二方面实施例提出了一种车载智能设备的软件升级方法应用于车载智能设备的主处理器，方法包括：

获取升级文件包，并将升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器；

若待升级处理器包括从处理器，向从处理器下发包括第一升级文件的升级指令，以使从处理器采用上述第一方面任一项方法进行升级；

若待升级处理器包括主处理器和从处理器，在接收到从处理器反馈的升级成功消息的情况下，基于第二升级文件对主处理器进行升级。

为达到上述目的，本发明第三方面实施例提出了一种车载智能设备，其特征在于，车载智能设备包括主处理器和从处理器；

主处理器，用于获取升级文件包，并将升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器，若待升级处理器包括从处理器，向从处理器下发包括第一升级文件的升级指令；

从处理器，用于响应于升级指令，采用上述第一方面任一项方法进行升级，并向主处理器反馈升级成功消息；

主处理器，用于在确定待升级处理器包括主处理器和从处理器，且接收到升级成功消息的情况下，基于第二升级文件进行升级。

为达到上述目的，本发明第四方面实施例提出了一种车载智能设备的软件升级装置，应用于车载智能设备的从处理器，装置包括：

接收模块，被配置为接收升级指令，其中，升级指令包括第一升级文件，且由车载智能设备的主处理器下发；

校验模块，被配置为响应于升级指令，用第一升级文件替换从处理器的片外缓存区的第一历史文件，并对片外缓存区写入的第一升级文件进行完整性校验；

运行模块，被配置为在校验失败的情况下，运行从处理器的运行缓存区的第一历史文件；

更新模块，被配置为在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区；

生成模块，被配置为在更新成功的情况下，生成升级成功消息。

为达到上述目的，本发明第五方面实施例提出了一种车载智能设备的软件升级装置，应用于车载智能设备的主处理器，装置包括：

确定模块，被配置为获取升级文件包，并将升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器；

指令下发模块，被配置为若待升级处理器包括从处理器，向从处理器下发包括第一升级文件的升级指令，以使从处理器采用上述第一方面任一项方法进行升级；

第一升级模块，被配置为若待升级处理器包括主处理器和从处理器，在接收到从处理器反馈的升级成功消息的情况下，基于第二升级文件对主处理器进行升级。

为达到上述目的，本发明第六方面实施例提出了一种计算设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时，实现如上述第一方面或第二方面任一项所述的车载智能设备的软件升级方法。

为达到上述目的，本发明第七方面实施例提出了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面或第二方面任一项所述的车载智能设备的软件升级方法。

本发明实施例提供的车载智能设备的软件升级方法，接收升级指令，其中，升级指令包括第一升级文件，且由车载智能设备的主处理器下发；响应于升级指令，用第一升级文件替换从处理器的片外缓存区的第一历史文件，并对片外缓存区写入的第一升级文件进行完整性校验；在校验失败的情况下，运行从处理器的运行缓存区的第一历史文件；在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区；在更新成功的情况下，生成升级成功消息。上述方法将主处理器与从处理器升级联系起来，使得从处理器在接收到主处理器的升级指令后再升级，能够避免主处理器升级失败对从处理器的影响，提高升级成功率，且直接从主处理器处获取第一升级文件，减少了与外部设备的交互，在一定程度上可以提高升级效率；并且，在从处理器上划分了片外缓存区和运行缓存区，将第一升级文件先写入片外缓存区，则后续升级可以直接从片外缓存区获取文件，不需要再与主处理器进行数据通信，提高了升级效率；并且，在写入片外缓存区的升级文件校验失败的情况下，不擦除运行缓存区的文件，确保即使升级过程出现异常，也不会影响从处理器的正常运行，不影响用户对车辆的使用，提高了软件升级的可靠性。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

图1是根据本发明实施例提供的一种软件升级系统的结构框图；

图2是根据本发明实施例提供的一种车载智能设备的软件升级方法的流程图；

图3是根据本发明实施例提供的一种车载智能设备的从处理器进行软件升级的流程图；

图4是根据本发明实施例提供的另一种车载智能设备的软件升级方法的流程图；

图5是根据本发明实施例提供的一种车载智能设备的主处理器下载升级文件包的流程图；

图6是根据本发明实施例提供的一种车载设备的软件升级流程图；

图7是根据本发明实施例提供的一种车载智能设备的结构框图；

图8是根据本发明实施例提供的一种车载智能设备的软件升级装置的结构框图；

图9是根据本发明实施例提供的另一种车载智能设备的软件升级装置的结构框图；

图10是根据本发明实施例提供的一种计算设备的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

下面参考附图描述本发明实施例提出的车载智能设备的软件升级方法、装置及车载智能设备。

图1是根据本发明实施例提供的一种软件升级系统的结构框图。如图所示，该软件升级系统包括云服务平台和车载智能设备，该车载智能设备包括4G（Fourth GenerationCommunications System，第四代移动通信系统）通讯模组、SOC（system on chip，片上系统）处理器和MCU（Microcontroller Unit，微控制器）处理器，该SOC处理器还包括片内存储器（备份区），MCU处理器还包括片外存储器。并且，云服务平台通过4G网络与4G通讯模组通信，4G通信模组通过UART（Universal Asynchronous Receiver/Transmitter，通用异步收发传输器）与SOC处理器通信，MCU处理器通过IIC（Inter-Integrated Circuit，集成电路总线）与片外存储器通信，SOC处理器和MCU处理器通过SPI（Serial Perripheral Interface，串行外围设备接口）进行通信。示例性地，云服务平台可以称为OTA云服务平台，车载智能设备可以称为ECU，片外存储器也可以称为片外缓存区。

图2是根据本发明实施例提供的一种车载智能设备的软件升级方法的流程图。该方法应用于车载智能设备的从处理器，可以包括如下步骤：

步骤201：接收升级指令，其中，升级指令包括第一升级文件，且由车载智能设备的主处理器下发。

在本发明实施例中，车载智能设备支持双处理器的软件刷写，包括主处理器和从处理器，主处理器可以是SOC，从处理器可以是MCU。升级指令可以是主处理器在根据升级文件包确定待升级处理器包括从处理器的情况下下发的，升级文件包是车载智能设备从云服务平台获取的用于对主处理器和/或从处理器进行升级的文件包。

在一些实施例中，车载智能设备的主处理器通过内置的4G无线网络模块从云服务平台下载升级文件包，该升级文件包可以包括对主处理器和/或从处理器进行升级的文件包。主处理器根据升级文件包确定待升级处理器，并在确定从处理器待升级的情况下，通过SPI通信的方式向从处理器下发升级指令，并将用于从处理器升级的第一升级文件携带在升级指令中。

进一步地，主处理器在向从处理器下发升级指令之前，可以先向从处理器下发待升级指令，以告知从处理器需要升级。从处理接收到待升级指令后，进入boot升级模式，根据其与主处理器之间的通信协议判断该待升级指令是否是OTA模式的指令，若是，则进入升级流程（即OTA重编译流程），通过SPI通信的方式从主处理器下载第一升级文件。在该种情况下，由从处理器主动从主处理器下载第一升级文件。

需要说明的是，第一升级文件可以是主处理器在确定从处理待升级的情况下主动发送至从处理器的，也可以是从处理器在接收到待升级指令后主动从主处理器处下载的，本实施例对此不做限定。

步骤202：响应于升级指令，用第一升级文件替换从处理器的片外缓存区的第一历史文件，并对片外缓存区写入的第一升级文件进行完整性校验。

在本发明实施例中，片外缓存区可以理解为从处理器中的备份区，其中存储有上一次升级使用的第一历史文件，从处理器接收到第一升级文件后，可以擦除片外缓存区中的第一历史文件，再将第一升级文件存储至片外缓存区，以便后续升级时可以从片外缓存区直接获取升级文件，无需再与主处理器通信。

在一些实施例中，由于在数据传输过程中可能会存在数据丢失，因此，将第一升级文件写入片外缓存区后，可以校验写入片外缓存区的第一升级文件是否完整。示例性地，可以采用哈希值校验的方式对第一升级文件进行完整性校验。

步骤203：在校验失败的情况下，运行从处理器的运行缓存区的第一历史文件。

具体实现中，若校验失败，说明第一升级文件在数据传输的过程中出现了丢失，则将失败消息反馈至主处理器，主处理器接收到失败消息后，会二次向从处理器的片外缓存区写入第一升级文件，如果连续失败超过3次以上，则主处理器停止写入文件，将失败消息上报至云服务平台。此时，由于升级失败，仅擦除了片外缓存区的第一历史文件，运行缓存区内的文件并未修改，因此，从处理器可以继续运行运行缓存区的第一历史文件，即继续运行当前APP程序，保证从处理器的正常运行。

在本发明实施例中，若将第一升级文件从主处理器写入从处理器的过程中，从处理器接收到的第一升级文件不完整，则升级失败，由于从处理器设置了片外缓存区和运行缓存区，且第一升级文件先写入片外缓存区进行备份，运行缓存区的文件并未改变，因此在升级失败的情况下，从处理器还可以继续运行运行缓存区的文件，如此保证了升级过程中出现异常，也能使车载智能设备正常运行，不影响用户对车辆的使用，提高了软件升级的可靠性。

步骤204：在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区。

具体实现中，若校验成功，说明从处理器已经接收到完整的第一升级文件，可以继续进行后续升级步骤，则将运行缓存区原有的文件擦除，然后将片外缓存区的第一升级文件更新到运行缓存区，以便实现对从处理中软件的更新。

在一些实施例中，如果校验成功，boot运行的程序将当前APP运行区（运行缓存区）进行擦除，然后将从处理器片外flash（缓存区）下载的最新程序（第一升级文件）更新到APP运行区。

步骤205：在更新成功的情况下，生成升级成功消息。

在本发明实施例中，将片外缓存区的第一升级文件更新至运行缓存区之后，需要判断是否更新成功，以确定从处理器是否升级成功。

在一种可能的实现方式中，将第一升级文件更新至运行缓存区后，可以对运行缓存区的第一升级文件进行完整性校验，若校验成功，则可以认为更新成功，即此次升级成功；若校验失败，则可以认为更新失败，即此次升级失败。

在另一种可能的实现方式中，将第一升级文件更新至运行缓存区后，可以对运行缓存区的第一升级文件进行完整性校验，在校验成功的情况下，重启从处理器，并监控从处理器的运行状态。若运行正常则确定更新成功，若运行失败则确定更新失败。

具体实现中，可以采用哈希值校验的方式对运行缓存区写入的第一升级文件进行完整性校验，若确定第一升级文件是完整的，则可以重启从处理器，由从处理器运行运行缓存区的第一升级文件，并且监控从处理器的运行状态。若运行状态是正常则可以认为更新成功，即此次升级成功；若运行状态是异常则可以认为更新失败，即此次升级失败。

在该种情况下，根据完整性校验结果和运行状态监控结果确定是否升级成功，能够提高升级结果判断的准确性。

根据本发明的一个实施例，若更新成功，说明从处理器升级成功，由于在本方案中主从处理器均需要升级的情况下，为了提高升级成功率，需要先升级从处理器，因此，从处理器可以生成升级成功消息反馈至主处理器。进一步地，主处理器可以备份第一升级文件，便于后续升级时对接收到的升级文件进行判断，并且，主处理器还可以将升级成功消息反馈至云服务平台，并在升级成功消息中携带第一升级文件的版本号，则云服务平台能够确定从处理器当前的软件版本，便于云服务平台后续对从处理器的升级。

根据本发明的另一个实施例，在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区之后，还包括：在更新失败的情况下，向主处理器上报更新失败信息，接收主处理器向运行缓存区写入的第一升级文件；在写入成功的情况下，生成升级成功消息。

具体实现中，若更新失败，可以向主处理器上报更新失败信息，由主处理器直接将第一升级文件写入从处理器的运行缓存区，并对写入的第一升级文件进行完整性校验，在校验成功的情况下确定写入成功，进而确定升级成功，生成升级成功消息。并且，还可以将升级成功消息上报至云服务平台。

在本发明实施例中，若将片外缓存区的第一升级文件写入运行缓存区失败，则由主处理器尝试直接向运行缓存区写入第一升级文件，即在从处理器内部无法升级成功的情况下才从主处理器直接获取第一升级文件做升级，减少了主处理器与从处理器之间的数据交互，提高了升级效率。

在一些实施例中，在第一次写入失败的情况下，可以向主处理器发送更新失败信息，主处理器会继续尝试直接向运行缓存区写入第一升级文件，如果连续失败超过3次，则确定写入失败，停止写入第一升级文件，采用回滚升级的方式再次尝试。

也即是，在写入失败的情况下，从主处理器的备份区获取从处理器的第一历史文件；基于第一历史文件对从处理器进行升级。

具体实现中，在主处理器尝试直接将第一升级文件更新到运行缓存区失败后，可以将从主处理器的备份区获取从处理器的第一历史文件，将第一历史文件先写入片外缓存区，若写入成功，则将片外缓存区的第一历史文件更新至运行缓存区，若更新成功，则确定升级成功；若更新失败，则确定升级失败。

需要说明的是，主处理器向从处理器写入第一历史文件后，从处理器根据第一历史文件进行升级的实现过程与根据第一升级文件进行升级的实现过程类似，具体实现可以参见上述相关描述，本实施例在此不再赘述。

在本发明实施例中，若主处理器无法直接对运行缓存区的文件进行更新，则从主处理器的备份区获取上一版本的文件进行回滚版本升级，以确保从处理器的正常运行。

进一步地，基于第一历史文件对从处理器进行升级之后，还包括：在升级成功的情况下，生成升级成功消息反馈至主处理器，以使主处理器备份第一历史文件并将第一历史文件的版本号上报至云服务平台。

也就是说，在基于第一历史文件对从处理器升级成功后，可以生成升级成功消息反馈至主处理器，该升级成功消息可以携带第一历史文件的版本号，则主处理器对该第一历史文件进行备份，并将第一历史文件的版本号上报至云服务平台，以便云服务平台可以获知此次升级结果，为后续升级提供参考。

作为一种示例，若基于第一历史文件对从处理器升级依然失败，则生成升级失败信息发送至主处理器，由主处理器上报至云服务平台。

接下来以主处理器是SOC，从处理器是MCU为例，结合图3对从处理器进行软件升级的完整过程进行说明，图3是根据本发明实施例提供的一种车载智能设备的从处理器进行软件升级的流程图，可以包括如下步骤。

步骤301：MCU接收到SOC发送的待升级指令，进入boot升级模式，在判断待升级指令是OTA模式的指令后，执行OTA重编译流程。

步骤302：MCU向SOC请求第一升级文件，并接收到SOC通过SPI通信的方式下发的携带第一升级文件的升级指令。

步骤303：MCU响应于该升级指令，将片外flash区原有的文件擦除，并将第一升级文件写入片外flash区。

步骤304：MCU判断写入到片外flash区的第一升级文件是否完整，若是则执行步骤305，若否则执行步骤312。

步骤305：MCU将片外flash区的第一升级文件更新到片内APP运行区，若更新成功则执行步骤306，若更新失败则执行步骤307。

步骤306：重启MCU，boot引导APP程序正常运行（运行运行缓存区的第一升级文件）。

步骤307：继续尝试将片外flash区的第一升级文件更新到片内APP运行区，若失败超过3次，则从SOC直接下载第一升级文件至运行缓存区进行升级，若升级成功则执行步骤308，若升级失败则执行步骤309。

步骤308：生成升级成功消息反馈至SOC，由SOC将第一升级文件的版本号携带在升级成功消息中反馈至OTA升级管理平台（云服务平台）。

步骤309：继续尝试从SOC直接下载第一升级文件至运行缓存区进行升级，若失败超过3次，则从SOC的备份区下载第一历史文件进行升级，若升级成功则执行步骤310，若升级失败则执行步骤311。

步骤310：生成升级成功消息反馈至SOC，由SOC将第一历史文件的版本号携带在升级成功消息中反馈至OTA升级管理平台（云服务平台）。

步骤311：继续尝试从SOC的备份区下载第一历史文件进行升级，若失败超过3次，生成升级失败消息反馈至SOC，由SOC反馈至OTA升级管理平台。

步骤312：继续尝试将SOC的第一升级文件写入片外flash区，若校验3次不完整，则运行运行缓存区的第一历史文件，保证MCU的正常运行。

在本发明实施例中，从处理器接收来自主处理器的升级指令，用升级指令中的第一升级文件替换片外缓存区的第一历史文件，并对写入的第一升级文件进行完整性校验，在校验失败的情况下运行运行缓存区的第一历史文件，确保即使升级失败也不会影响从处理器的正常运行；在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区，若更新成功则升级成功；若更新失败则由主处理器直接向运行缓存区写入第一升级文件，若写入失败，则从主处理器的备份区获取第一历史文件，根据第一历史文件对从处理器进行回滚版本的升级，以确保从处理器的正常运行，不影响用户对车辆的使用，提高升级的可靠性。

图4是根据本发明实施例提供的另一种车载智能设备的软件升级方法的流程图，应用于车载智能设备的主处理器，该方法可以包括如下步骤：

步骤401：获取升级文件包，并将升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器。

在本发明实施例中，车载智能设备的主处理器可以通过内置的4G无线网络模块从云服务平台下载升级文件包，在完整性校验成功后，对升级文件包进行解包处理，通过将升级文件包的版本号与备份区的主处理器当前文件的版本号、从处理器当前文件的版本号进行比对，确定需要升级的待升级处理器。

示例性地，参见图5，图5是根据本发明实施例提供的一种车载智能设备的主处理器下载升级文件包的流程图。在图5中，车载智能设备可以周期性地判断云服务平台是否有升级任务，若是则从云服务平台下载升级文件包，再对该升级文件包进行完整性校验。若校验失败，则返回执行从云服务平台下载升级文件包的步骤，在失败次数超过3次的情况下，删除此次升级任务，并返回执行周期性判断云服务平台是否有升级任务的步骤；若校验成功则对升级文件包进行解压处理，至此，主处理器完成了OTA升级文件包的解压任务。

在一些实施例中，主处理器的备份区备份着主处理器当前版本使用的文件（主处理器当前文件）和从处理器当前版本使用的文件（从处理器当前文件）。若升级文件包包括从处理器升级所需的第一升级文件，则将第一升级文件的版本与从处理器当前文件的版本进行比对，若第一升级文件的版本高于从处理器当前文件的版本，说明从处理器需要升级，否则取消从处理器升级任务；若升级文件包包括主处理器升级所需的第二升级文件，则将第二升级文件的版本与主处理器当前文件的版本进行比对，若第二升级文件的版本高于主处理器当前文件的版本，说明主处理器需要升级，否则取消主处理器升级任务。并且，在取消升级任务后，可以将结果上报至云服务平台。

步骤402：若待升级处理器包括从处理器，向从处理器下发包括第一升级文件的升级指令，以使从处理器采用上述应用于从处理器的车载智能设备的软件升级方法进行升级。

在本发明实施例中，无论两个处理器都需要升级还是只有一个处理器需要升级，都先对从处理器进行升级，能够避免主处理器升级失败对从处理器升级的影响，提高软件升级的成功率和可靠性。

具体实现中，在需要升级从处理器的情况下，主处理器执行升级从处理器的线程，通过SPI通信的方式，将下载的第一升级文件发送至从处理器，使从处理器根据上述实施例的方式进行升级，其具体实现过程可以参见上述实施例的相关描述，本实施例在此不再赘述。

步骤403：若待升级处理器包括主处理器和从处理器，在接收到从处理器反馈的升级成功消息的情况下，基于第二升级文件对主处理器进行升级。

在本发明实施例中，若主处理器和从处理器都需要升级，则先对从处理器进行升级，在接收到从处理器的升级成功消息后，对自身进行升级，再重启主处理器，完成双处理器的软件升级，最后将主处理器和从处理器的升级文件备份至主处理器的备份区。

在一些实施例中，主处理器当前文件包括内核当前文件和应用当前文件，第二升级文件包括内核升级文件和应用升级文件，基于第二升级文件对主处理器进行升级的具体实现可以包括：确定内核升级文件与内核当前文件的差异部分，基于差异部分对内核当前文件进行更新，基于应用升级文件对应用当前文件进行更新，实现对主处理器的软件升级。

具体实现中，主处理器的软件升级包括差分升级和全量升级两种方式，且由于内核文件的数据量比较大，应用文件的数据量较小，因此，内核文件采用差分升级的升级方式，应用文件采用全量升级的升级方式。将内核升级文件与内核当前文件进行比对，若存在差异，则确定差异部分，并用内核升级文件的差异部分替换内核当前文件中的差异部分；将应用升级文件与应用当前文件进行比对，若存在差异，则直接用应用升级文件替换应用当前文件，

作为一种示例，主处理器的文件包括Linux内核文件和应用APP文件，内核升级采用差分方式进行升级，只升级差异部分，如果应用APP文件有更新，采用全量升级，降低下载文件的大小，减少网络流量开销，降低成本。

进一步地，基于第二升级文件对主处理器进行升级之后，还包括：

重启主处理器，并监控主处理器的运行状态；在运行正常的情况下，在备份区备份第二升级文件。

也就是说，在对主处理器升级完成后，可以重启主处理器，并监控主处理器运行第二升级文件时的运行状态，在运行状态是正常的情况下，说明主处理器升级完成，将主处理器的备份区中的第一历史文件（旧版本文件）替换为该第二升级文件（新版本文件），并生成升级完成消息反馈至云服务平台，以此完成主处理器的软件升级。

在本发明实施例中，SOC（主处理器）对升级文件包进行解压后，获取升级文件包中的SOC最新版本号和MCU（从处理器）最新版本号，分别判断下载的升级文件包中的SOC最新版本号和MCU最新版本号与主处理器备份的SOC当前版本号和MCU当前版本号进行比较，如果SOC最新版本号高于SOC当前版本号，则SOC需要软件升级即更新固件，否则SOC不需要升级，将此信息反馈至OTA云服务管理平台；如果MCU最新版本号高于MCU当前版本号，则MCU需要软件升级即更新固件，否则MCU不需要升级，同时将此信息反馈至OTA云服务管理平台。当SOC检测到SOC和MCU都需要软件升级时，则先对MCU进行软件升级，然后将MCU重启，再对SOC进行软件升级，最后将最新版本号备份到SOC的备份区，并将MCU和SOC的升级结果反馈至OTA升级管理平台。如此提高了双处理器的升级成功率，同时保证即使升级过程中出现异常，也能使车载智能设备正常运行，不影响车辆的正常使用，提高了升级可靠性。

接下来，以主处理器是SOC、从处理器是MCU为例，参见图6对车载设备的软件升级过程进行说明，图6是根据本发明实施例提供的一种车载设备的软件升级流程图。

步骤601：车载智能设备的SOC从云服务平台下载升级文件包，该升级文件包包括SOC升级文件和MCU升级文件。

步骤602：将SOC升级文件与备份的SOC旧版本文件进行比对。

步骤603：若SOC升级文件的版本高于备份的SOC旧版本文件的版本，说明SOC待升级。

步骤604：将MCU升级文件与备份的MCU旧版本文件进行比对，若SOC升级文件的版本高于备份的MCU旧版本文件的版本，说明MCU待升级。

步骤605：在SOC和MCU均需要升级的情况下，SOC将携带MCU升级文件的升级指令发送至MCU。

步骤606：MCU将片外缓存区擦除，并将MCU升级文件写入片外缓存区。

步骤607：MCU对写入片外缓存区的MCU升级文件进行完整性校验，若完整则执行步骤608，若不完整则执行步骤618。

步骤608：MCU将片外flash区的第一升级文件更新到片内APP运行区，若更新成功则执行步骤609，若更新失败则执行步骤610。

步骤609：重启MCU，boot引导APP程序正常运行（运行运行缓存区的第一升级文件），并向SOC发送升级成功消息。

步骤610：判断更新失败的次数是否大于3次，若是，执行步骤611，若否，返回执行步骤608。

步骤611：从SOC直接下载第一升级文件至运行缓存区进行升级，若升级成功则执行步骤612，若升级失败则执行步骤613。

步骤612：生成升级成功消息反馈至SOC，由SOC将第一升级文件的版本号携带再升级成功消息中反馈至OTA升级管理平台。

步骤613：判断升级失败次数是否大于3次，若是，执行步骤614，若否，返回执行步骤611。

步骤614：从SOC的备份区下载第一历史文件进行升级，若升级成功则执行步骤615，若升级失败则执行步骤616。

步骤615：生成升级成功消息反馈至SOC，由SOC将第一历史文件的版本号携带再升级成功消息中反馈至OTA升级管理平台。

步骤616：判断升级失败次数是否大于3次，若是，执行步骤617，若否，返回执行步骤614。

步骤617：生成升级失败消息反馈至SOC，由SOC反馈至OTA升级管理平台。

步骤618：判断写入失败次数是否大于3次，若是，执行步骤619，若否，返回执行步骤606。

步骤619：MCU运行运行缓存区的第一历史文件，保证MCU的正常运行，并向SOC发送升级失败消息。

步骤620：SOC在确定MCU升级完成后，获取内核文件的差异部分，采用差分方式对内核文件进行升级，并用获取的应用升级文件替换应用当前文件，实现对SOC的升级。

步骤621：SOC将SOC升级后的版本号和MCU升级后的版本号上报至OTA升级管理平台。

本方案实现了车载智能设备中双处理的升级，提高了双处理器的升级成功率，同时保证即使升级过程中出现异常，也能使车载智能设备正常运行，不影响车辆的正常使用，提高了升级可靠性。

图7是根据本发明实施例提供的一种车载智能设备的结构框图，该车载智能设备包括车载智能设备包括主处理器701和从处理器702；

主处理器701，用于获取升级文件包，并将升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器，若待升级处理器包括从处理器702，向从处理器702下发包括第一升级文件的升级指令；

从处理器702，用于响应于升级指令，采用应用于从处理器的车载智能设备的软件升级方法进行升级，并向主处理器701反馈升级成功消息；

主处理器701，用于在确定待升级处理器包括主处理器和从处理器702，且接收到升级成功消息的情况下，基于第二升级文件进行升级。

根据本发明的一个实施例，主处理器701，还用于：

在更新失败的情况下，向主处理器上报更新失败信息；

接收主处理器向运行缓存区写入的第一升级文件；

在写入成功的情况下，生成升级成功消息。

根据本发明的一个实施例，主处理器701，还用于：

在写入失败的情况下，从主处理器的备份区获取从处理器的第一历史文件；

基于第一历史文件对从处理器进行升级。

根据本发明的一个实施例，主处理器701，还用于：

在升级成功的情况下，生成升级成功消息反馈至主处理器，以使主处理器备份第一历史文件并将第一历史文件的版本号上报至云服务平台。

需要说明的是，车载智能设备包括的主处理器和从处理器实现软件升级的具体实现可以参见上述实施例的相关描述，本实施例对此不再赘述。

本发明实施例提供的车载智能设备包括主处理器和从处理器，应用本发明实施例提供的车载智能设备的软件升级方法，实现了双处理器的升级，提高了双处理器的升级成功率，同时保证即使升级过程中出现异常，也能使车载智能设备正常运行，不影响车辆的正常使用，提高了软件升级的可靠性。

图8是根据本发明实施例提供的一种车载智能设备的软件升级装置的结构框图，该装置包括：

接收模块801，被配置为接收升级指令，其中，升级指令包括第一升级文件，且由车载智能设备的主处理器下发；

校验模块802，被配置为响应于升级指令，用第一升级文件替换从处理器的片外缓存区的第一历史文件，并对片外缓存区写入的第一升级文件进行完整性校验；

运行模块803，被配置为在校验失败的情况下，运行从处理器的运行缓存区的第一历史文件；

更新模块804，被配置为在校验成功的情况下，将片外缓存区的第一升级文件更新至运行缓存区；

生成模块805，被配置为在更新成功的情况下，生成升级成功消息。

根据本发明的一个实施例，该装置还包括第二升级模块，被配置为：

在更新失败的情况下，向主处理器上报更新失败信息；

接收主处理器向运行缓存区写入的第一升级文件；

在写入成功的情况下，生成升级成功消息。

根据本发明的一个实施例，该装置还包括第三升级模块，被配置为：

在写入失败的情况下，从主处理器的备份区获取从处理器的第一历史文件；

基于第一历史文件对从处理器进行升级。

根据本发明的一个实施例，该装置还包括上报模块，被配置为：

在升级成功的情况下，生成升级成功消息反馈至主处理器，以使主处理器备份第一历史文件并将第一历史文件的版本号上报至云服务平台。

应用本发明实施例提供的车载智能设备的软件升级方法，实现了双处理器的升级，提高了双处理器的升级成功率，同时保证即使升级过程中出现异常，也能使车载智能设备正常运行，不影响车辆的正常使用，提高了软件升级的可靠性。

上述为本发明实施例的一种应用于从处理器的车载智能设备的软件升级装置的示意性方案。需要说明的是，该应用于从处理器的车载智能设备的软件升级装置的技术方案与上述应用于从处理器的车载智能设备的软件升级方法的技术方案属于同一构思，应用于从处理器的车载智能设备的软件升级装置的技术方案未详细描述的细节内容，均可以参见上述应用于从处理器的车载智能设备的软件升级方法的技术方案的描述。

图9是根据本发明实施例提供的另一种车载智能设备的软件升级装置的结构框图，该装置包括：

确定模块901，被配置为获取升级文件包，并将升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器；

指令下发模块902，被配置为若待升级处理器包括从处理器，向从处理器下发包括第一升级文件的升级指令，以使从处理器采用权利要求1-4任一项的方法进行升级；

第一升级模块903，被配置为若待升级处理器包括主处理器和从处理器，在接收到从处理器反馈的升级成功消息的情况下，基于第二升级文件对主处理器进行升级。

应用本发明实施例提供的车载智能设备的软件升级方法，实现了双处理器的升级，提高了双处理器的升级成功率，同时保证即使升级过程中出现异常，也能使车载智能设备正常运行，不影响车辆的正常使用，提高了软件升级的可靠性。

上述为本发明实施例的一种应用于主处理器的车载智能设备的软件升级装置的示意性方案。需要说明的是，该应用于主处理器的车载智能设备的软件升级装置的技术方案与上述应用于主处理器的车载智能设备的软件升级方法的技术方案属于同一构思，应用于主处理器的车载智能设备的软件升级装置的技术方案未详细描述的细节内容，均可以参见上述应用于主处理器的车载智能设备的软件升级方法的技术方案的描述。

图10是根据本发明实施例提供的一种计算设备的结构示意图。该计算设备1000包括：存储器1001、处理器1002及存储在存储器1001上并可在处理器1002上运行的计算机程序，所述处理器1002执行所述计算机程序时，实现如上述任一实施例提出的车载智能设备的软件升级方法。

本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述任一实施例提出的车载智能设备的软件升级方法。

需要说明的是，在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备（如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统）使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例（非穷尽性列表）包括以下：具有一个或多个布线的电连接部（电子装置），便携式计算机盘盒（磁装置），随机存取存储器（RAM，Random Access Memory），只读存储器（ROM，Read-Only Memory），可擦除可编辑只读存储器（EPROM，Erasable Programmable Read-Only Memory或闪速存储器），光纤装置，以及便携式光盘只读存储器（CDROM，Compact Disk Read Only Memory）。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列（PGA，Programmable Gate Array），现场可编程门阵列（FPGA，Field Programmable Gate Array）等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (8)

1.一种车载智能设备的软件升级方法，其特征在于，应用于车载智能设备的从处理器，所述方法包括：

接收升级指令，其中，所述升级指令包括第一升级文件，且由所述车载智能设备的主处理器下发；

响应于所述升级指令，用所述第一升级文件替换所述从处理器的片外缓存区的第一历史文件，并对所述片外缓存区写入的第一升级文件进行完整性校验；

在校验失败的情况下，运行所述从处理器的运行缓存区的第一历史文件；

在校验成功的情况下，将所述片外缓存区的第一升级文件更新至所述运行缓存区；

在更新成功的情况下，生成升级成功消息；

在更新失败的情况下，向所述主处理器上报更新失败信息；接收所述主处理器向所述运行缓存区写入的所述第一升级文件；

在写入成功的情况下，生成升级成功消息；

在写入失败的情况下，从所述主处理器的备份区获取所述从处理器的第一历史文件；基于所述第一历史文件对所述从处理器进行升级。

2.根据权利要求1所述的车载智能设备的软件升级方法，其特征在于，所述基于所述第一历史文件对所述从处理器进行升级之后，还包括：

在升级成功的情况下，生成升级成功消息反馈至所述主处理器，以使所述主处理器备份所述第一历史文件并将所述第一历史文件的版本号上报至云服务平台。

3.一种车载智能设备的软件升级方法，其特征在于，应用于车载智能设备的主处理器，所述方法包括：

获取升级文件包，并将所述升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器；

若所述待升级处理器包括从处理器，向所述从处理器下发包括第一升级文件的升级指令，以使所述从处理器采用权利要求1-2任一项所述的方法进行升级；

若所述待升级处理器包括主处理器和从处理器，在接收到所述从处理器反馈的升级成功消息的情况下，基于第二升级文件对所述主处理器进行升级。

4.一种车载智能设备，其特征在于，所述车载智能设备包括主处理器和从处理器；

所述主处理器，用于获取升级文件包，并将所述升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器，若所述待升级处理器包括从处理器，向所述从处理器下发包括第一升级文件的升级指令；

所述从处理器，用于响应于所述升级指令，采用权利要求1-2任一项所述的方法进行升级，并向所述主处理器反馈升级成功消息；

所述主处理器，用于在确定所述待升级处理器包括所述主处理器和所述从处理器，且接收到所述升级成功消息的情况下，基于第二升级文件进行升级。

5.一种车载智能设备的软件升级装置，其特征在于，应用于车载智能设备的从处理器，所述装置包括：

接收模块，被配置为接收升级指令，其中，所述升级指令包括第一升级文件，且由所述车载智能设备的主处理器下发；

校验模块，被配置为响应于所述升级指令，用所述第一升级文件替换所述从处理器的片外缓存区的第一历史文件，并对所述片外缓存区写入的第一升级文件进行完整性校验；

运行模块，被配置为在校验失败的情况下，运行所述从处理器的运行缓存区的第一历史文件；

更新模块，被配置为在校验成功的情况下，将所述片外缓存区的第一升级文件更新至所述运行缓存区；

生成模块，被配置为在更新成功的情况下，生成升级成功消息；

第二升级模块，被配置为在更新失败的情况下，向主处理器上报更新失败信息；接收主处理器向运行缓存区写入的第一升级文件；在写入成功的情况下，生成升级成功消息；

第三升级模块，被配置为在写入失败的情况下，从主处理器的备份区获取从处理器的第一历史文件；基于第一历史文件对从处理器进行升级。

6.一种车载智能设备的软件升级装置，其特征在于，应用于车载智能设备的主处理器，所述装置包括：

确定模块，被配置为获取升级文件包，并将所述升级文件包与备份区的主处理器当前文件、从处理器当前文件进行比对，确定待升级处理器；

指令下发模块，被配置为若所述待升级处理器包括从处理器，向所述从处理器下发包括第一升级文件的升级指令，以使所述从处理器采用权利要求1-2任一项所述的方法进行升级；

第一升级模块，被配置为若所述待升级处理器包括主处理器和从处理器，在接收到所述从处理器反馈的升级成功消息的情况下，基于第二升级文件对所述主处理器进行升级。

7.一种计算设备，其特征在于，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现如权利要求1-2任一项或权利要求3所述的车载智能设备的软件升级方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-2任一项或权利要求3所述的车载智能设备的软件升级方法。