CN115309429A - 一种软件更新方法及装置 - Google Patents

Abstract

本申请提供一种软件更新方法及装置，该软件更新方法包括：当接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作；下载目标软件的软件更新数据；根据软件更新数据将新的目标软件更新至预先配置的软件备份区；判断是否更新成功；如果更新成功，则将软件备份区中的新的目标软件复制到预先配置的软件执行区中；如果更新失败，软件执行区的目标软件未受影响，可以保证控制器正常工作。可见，该方法能够自动实现软件恢复，解决了远程更新车辆控制器软件失败情况下，控制器无法正常工作，需要人工恢复的问题。

Description

一种软件更新方法及装置

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种软件更新方法及装置。

背景技术

目前，随着汽车电子技术的不断发展，现在车辆的上的控制器也越来越多，可通过更新控制器软件实现功能优化。传统的软件更新方法，是采用人工重新刷写的方式实现软件更新然而，传统方式工作量大，重复性高，软件更新效率低下；因此远程更新技术孕育而出，但使用该技术的控制器，在更新失败情况下，无法正常工作，依然需要人工恢复的问题。

发明内容

本申请实施例的目的在于提供一种软件更新方法及装置，能够自动实现软件恢复，解决了远程更新车辆控制器软件的问题，以及解决了更新失败情况下，无法正常工作，且需要人工恢复的问题。

本申请实施例第一方面提供了一种软件更新方法，包括：

当接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作；

下载所述目标软件的软件更新数据；

根据所述软件更新数据将新的目标软件更新至预先配置的软件备份区；

判断是否更新成功；

如果更新成功，则将所述软件备份区中的所述新的目标软件复制到预先配置的软件执行区中。

在上述实现过程中，该方法能够在接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作；并下载目标软件的软件更新数据；然后，根据软件更新数据将新的目标软件更新至预先配置的软件备份区；再判断是否更新成功；并在更新成功时，将软件备份区中的新的目标软件复制到预先配置的软件执行区中。

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

当判断出更新失败时，则重启汽车电子控制单元，并继续运行预先配置的软件执行区中的所述目标软件。

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

在将所述新的目标软件复制到所述软件执行区时，判断是否复制成功；

如果复制成功，则输出所述目标软件更新成功的提示信息。

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

当判断出未复制成功时，则确定复制未成功的异常原因；

根据所述异常原因确定异常处理方案；

根据所述异常处理方案对所述目标软件进行更新处理。

进一步地，所述异常原因包括汽车电子控制单元异常或者汽车电子控制单元掉电异常。

本申请实施例第二方面提供了一种软件更新装置，所述软件更新装置包括：

启动单元，用于当接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作；

下载单元，用于下载所述目标软件的软件更新数据；

更新单元，用于根据所述软件更新数据将新的目标软件更新至预先配置的软件备份区；

判断单元，用于判断是否更新成功；

复制单元，用于当判断出更新成功时，则将所述软件备份区中的所述新的目标软件复制到预先配置的软件执行区中。

进一步地，所述软件更新装置还包括：

重启单元，用于当判断出更新失败时，则重启汽车电子控制单元，并继续运行预先配置的软件执行区中的所述目标软件。

进一步地，所述软件更新装置还包括：

所述判断单元，还用于在将所述新的目标软件复制到所述软件执行区时，判断是否复制成功；

输出单元，用于当判断出复制成功时，则输出所述目标软件更新成功的提示信息。

进一步地，所述软件更新装置还包括：

确定单元，用于当判断出未复制成功时，则确定复制未成功的异常原因；

所述确定单元，还用于根据所述异常原因确定异常处理方案；

所述更新单元，还用于根据所述异常处理方案对所述目标软件进行更新处理。

进一步地，所述异常原因包括汽车电子控制单元异常或者汽车电子控制单元掉电异常。

本申请实施例第三方面提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请实施例第一方面中任一项所述的软件更新方法。

本申请实施例第四方面提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例第一方面中任一项所述的软件更新方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种软件更新方法的流程示意图；

图2为本申请实施例提供的一种软件更新装置的结构示意图；

图3为本申请实施例提供的一种支持OTA的软件更新方案图；

图4为本申请实施例提供的一种断点续传方案图；

图5为本申请实施例提供的一种软件更新方法的举例示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

实施例1

请参看图1，图1为本申请实施例提供了一种软件更新方法的流程示意图。其中，该软件更新方法包括：

S101、当接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作。

S102、下载目标软件的软件更新数据。

S103、根据软件更新数据将新的目标软件更新至预先配置的软件备份区。

本实施例中，该方法启动软件更新，新软件开始更新至软件备份区，更新过程支持断点续传功能。

本实施例中，该断点续传功能可以参照图4所示的断点续传方案图，并通过以下步骤加以实现：

①诊断设备请求更新备份区；

②由于断点标志位并未置位，ECU擦除备份区原有数据；

③通过诊断仪将新软件下载至备份区中；

④若下载过程因为通讯问题而中断，ECU记录断点地址，并置位断点标志位；

⑤通信恢复后，诊断仪再次请求更新备份区，ECU上传断点标志位与断点地址，诊断仪从断点地址开始下发软件数据，ECU便可以从断点处开始更新软件；

⑥期间若多次因通信故障导致更新失败，ECU重复上述操作，直至更新完毕，设置备份区有效标志位。

S104、判断是否更新成功，若是，则执行步骤S106～S107；若否，则执行步骤S105。

S105、重启汽车电子控制单元，并继续运行预先配置的软件执行区中的目标软件，并结束本流程。

本实施例中，若新软件更新失败，ECU重启，继续运行执行区的旧软件，更新流程结束。

S106、将软件备份区中的新的目标软件复制到预先配置的软件执行区中。

本实施例中，若新软件更新成功，则开始将备份区的新软件复制到执行区中。

S107、在将新的目标软件复制到软件执行区时，判断是否复制成功，若是，则执行步骤S108；若否，则执行步骤S109～S111。

S108、输出目标软件更新成功的提示信息，并结束本流程。

本实施例中，若复制成功，则软件更新成功，更新流程结束。

S109、确定复制未成功的异常原因。

本实施例中，异常原因包括汽车电子控制单元异常或者汽车电子控制单元掉电异常。

S110、根据异常原因确定异常处理方案。

S111、根据异常处理方案对目标软件进行更新处理。

本实施例中，若复制因MCU异常而失败，可连续3次尝试复制PF1，超过3次后上报MCU故障，ECU停留在Boot状态下，更新流程结束。

在本实施例中，若复制因掉电而失败，ECU再次上电后，自动检测执行区和备份区的软件有效性，由于执行区无效，而备份区有效，故执行回滚操作，恢复执行区软件。

请参阅图3，图3描述了一种支持OTA的软件更新方案图，该方法可以基于该图示出的内容实现软件更新方法。

本实施例中，在更新备份区软件期间，MCU需要从CAN总线上下载新软件，然后烧录到备份区中，期间极易受通信质量的影响，并且通讯时长占据更新时长的80％，是软件更新的最大不稳定因素，绝大部分的更新失败都是因为通信不稳定造成的。然而，本方法能够在通信期间更新备份区软件，从而能够避免通信故障导致的更新失败，同时也能够避免引起回滚操作；如果想要重新运行执行区软件，该方法可以通过简单的复位加以实现。

本实施例中，该方法在通信期间更新备份区软件，因此通信故障导致的更新失败，并不会引起回滚操作，只需要简单的复位便可以恢复并重新运行执行区软件；同时还可以通过断点续传功能，在通信质量恢复后，从断点处继续更新软件。同时，在更新执行区软件期间，MCU只需在内部进行复制操作，期间通讯故障对复制操作没有影响，且MCU内部复制操作耗时短，发生故障概率极低，一旦发生故障，通常为MCU损坏引起的，以为此类故障难以通过软件手段修复，所以可以在软件层面上忽略该问题，从而使得该方法具有最优的适应性。

本实施例中，在更新执行区软件期间，若不明原因导致MCU重启(如外部电源故障)，也会导致刷写失败，此时PF0无效而PF1有效，将触发回滚操作，修复PF0软件；由于执行区更新时间短，且导致MCU重启的概率也极低，因此回滚操作被触发的概率也极低。

参照图5所示，该方法举例流程如下：

①MCU第一步先检查是烧录标志有效位，有效则表明诊断设备发送了刷写请求，开始进入备份区刷写；

②备份区软件升级前，需要检查有无断点信息，若有断点信息，则根据断点信息，从断点开始更新备份区软件；若没有断点信息，则需要完全擦除备份区，从头更新备份区软件，断点信息包括断点地址和断点标志位；

③备份区更新完毕后，进入到执行区刷写流程，执行区软件更新最多可尝试3次，超过3次仍未更新成功，则视为MCU故障；

④若MCU第一步未检测到烧录标志有效位，MCU通过判断PF0和PF1是否有效，决定是否进行回滚操作，只有当PF0无效，PF1有效时才进行回滚，期间ECU处于静默状态。

本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。

可见，实施本实施例所描述的软件更新方法，能够最大程度降低了由于回滚操作而导致ECU静默的可能性，保证车辆更新失败后也可以立刻行驶；还能够复用备份区，从而实现断点续传功能，避免占用额外的Flash资源，进而降低了MCU选型门槛。

实施例2

请参看图2，图2为本申请实施例提供的一种软件更新装置的结构示意图。如图2所示，该软件更新装置包括：

启动单元210，用于当接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作；

下载单元220，用于下载目标软件的软件更新数据；

更新单元230，用于根据软件更新数据将新的目标软件更新至预先配置的软件备份区；

判断单元240，用于判断是否更新成功；

复制单元250，用于当判断出更新成功时，则将软件备份区中的新的目标软件复制到预先配置的软件执行区中。

作为一种可选的实施方式，软件更新装置还包括：

重启单元260，用于当判断出更新失败时，则重启汽车电子控制单元，并继续运行预先配置的软件执行区中的目标软件。

作为一种可选的实施方式，软件更新装置还包括：

判断单元240，还用于在将新的目标软件复制到软件执行区时，判断是否复制成功；

输出单元270，用于当判断出复制成功时，则输出目标软件更新成功的提示信息。

作为一种可选的实施方式，软件更新装置还包括：

确定单元280，用于当判断出未复制成功时，则确定复制未成功的异常原因；

确定单元280，还用于根据异常原因确定异常处理方案；

更新单元230，还用于根据异常处理方案对目标软件进行更新处理。

本实施例中，异常原因包括汽车电子控制单元异常或者汽车电子控制单元掉电异常。

本实施例中，对于软件更新装置的解释说明可以参照实施例1中的描述，对此本实施例中不再多加赘述。

可见，实施本实施例所描述的软件更新装置，能够最大程度降低了由于回滚操作而导致ECU静默的可能性，保证车辆更新失败后也可以立刻行驶；还能够复用备份区，从而实现断点续传功能，避免占用额外的Flash资源，进而降低了MCU选型门槛。

本申请实施例提供了一种电子设备，包括存储器以及处理器，存储器用于存储计算机程序，处理器运行计算机程序以使电子设备执行本申请实施例1中的软件更新方法。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序指令，计算机程序指令被一处理器读取并运行时，执行本申请实施例1中的软件更新方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种软件更新方法，其特征在于，包括：

当接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作；

下载所述目标软件的软件更新数据；

根据所述软件更新数据将新的目标软件更新至预先配置的软件备份区；

判断是否更新成功；

如果更新成功，则将所述软件备份区中的所述新的目标软件复制到预先配置的软件执行区中。

2.根据权利要求1所述的软件更新方法，其特征在于，所述方法还包括：

当判断出更新失败时，则重启汽车电子控制单元，并继续运行预先配置的软件执行区中的所述目标软件。

3.根据权利要求1所述的软件更新方法，其特征在于，所述方法还包括：

在将所述新的目标软件复制到所述软件执行区时，判断是否复制成功；

如果复制成功，则输出所述目标软件更新成功的提示信息。

4.根据权利要求3所述的软件更新方法，其特征在于，所述方法还包括：

当判断出未复制成功时，则确定复制未成功的异常原因；

根据所述异常原因确定异常处理方案；

根据所述异常处理方案对所述目标软件进行更新处理。

5.根据权利要求4所述的软件更新方法，其特征在于，所述异常原因包括汽车电子控制单元异常或者汽车电子控制单元掉电异常。

6.一种软件更新装置，其特征在于，所述软件更新装置包括：

启动单元，用于当接收到诊断设备发送的刷写请求时，根据刷写请求启动目标软件的更新操作；

下载单元，用于下载所述目标软件的软件更新数据；

更新单元，用于根据所述软件更新数据将新的目标软件更新至预先配置的软件备份区；

判断单元，用于判断是否更新成功；

复制单元，用于当判断出更新成功时，则将所述软件备份区中的所述新的目标软件复制到预先配置的软件执行区中。

7.根据权利要求6所述的软件更新装置，其特征在于，所述软件更新装置还包括：

重启单元，用于当判断出更新失败时，则重启汽车电子控制单元，并继续运行预先配置的软件执行区中的所述目标软件。

8.根据权利要求6所述的软件更新装置，其特征在于，所述判断单元，还用于在将所述新的目标软件复制到所述软件执行区时，判断是否复制成功；

所述软件更新装置还包括：

输出单元，用于当判断出复制成功时，则输出所述目标软件更新成功的提示信息。

9.一种电子设备，其特征在于，所述电子设备包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行权利要求1至5中任一项所述的软件更新方法。

10.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行权利要求1至5任一项所述的软件更新方法。

Images