嵌入式设备固件更新方法、嵌入式设备、开发端设备

技术领域

本申请涉及嵌入式技术领域，尤其涉及一种嵌入式设备固件更新方法、嵌入式设备、开发端设备以及嵌入式设备固件更新系统。

背景技术

在物联网技术快速发展的时代，FOTA(Firmware Over the Air)远程固件更新功能正在成为物联网设备的必备功能之一。通过使用FOTA功能，物联网设备不仅可以改进功能，消除系统的漏洞，还可以向不同用户提供差异化服务，使得产品在市场上更受欢迎。

传统的嵌入式设备，例如PC或者手机，其内部也集成了FOTA功能。一般情况下，PC或手机拥有强大计算能力的CPU，以及较为充足的内存资源以及物理存储空间。而物联网设备的CPU往往计算能力有限，内存资源以及物理存储空间也受到较多限制。另外，PC或者手机使用FOTA的频率并不高，通常几周更新一次。而物联网设备执行FOTA的频率则较高，以共享单车为例，其平均每周就至少更新一次。这对固件更新的流量消耗和时间消耗也提出了更高的要求，过高的流量消耗将会对运营商造成庞大的费用开销；较长的时间消耗也会影响用户的使用体验。

另外，物联网设备种类多、功能多样，不同型号的设备可用资源不一样，即便是相同型号的设备，由于软件定义的功能不一致，导致用于FOTA的软硬件资源也不一样，导致了采用统一的方案以同时满足多种物联网设备实现FOTA功能的困难。

鉴于此，提供一种能够节省流量和时间，可以部署在软硬件资源受限的设备，且能够适用多种使用场景、功能各异的物联网设备的通用固件更新方案，是本领域技术人员亟待解决的技术问题之一。

应理解，上述所列举的技术问题仅作为示例而非对本发明的限制，本发明并不限于同时解决上述所有技术问题的技术方案。本发明的技术方案可以实施为解决上述或其他技术问题中的一个或多个。

发明内容

为解决上述和其他问题，本申请提供了一种嵌入式设备固件更新方法，应用于所述嵌入式设备，所述嵌入式设备包括引导加载程序，以及固件更新获取程序；所述引导加载程序存储在引导加载分区中，所述固件更新获取程序存储在对应的固件分区中，其中所述固件更新获取程序包括更新触发模块以及数据接收模块，所述引导加载程序包括数据处理模块，所述方法包括：

所述更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件；

所述数据接收模块从源设备获取传输数据，所述传输数据至少包括供所述嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息；将所述更新数据写入到存储传输数据的分区；及

所述数据处理模块依据所述更新方式信息，对接收到的所述更新数据进行处理，得到新固件数据，以便在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据。

可选地，所述更新方式信息标识本次固件所采用的更新方式为差分更新时，所述更新数据为补丁数据。

可选地，所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据包括：

将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据；

在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：

所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以便在运行引导加载程序期间从所述待引导分区中应用所述新固件数据。

可选地，在所述数据处理模块将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据之前还包括：

所述数据处理模块从所述传输数据中获取旧固件数据的版本校验信息或摘要校验信息；依据所述版本校验信息或摘要校验信息判断所述补丁数据与所述旧固件数据是否匹配；

如果是，则执行所述将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据的操作。

可选地，所述更新方式信息标识本次固件所采用的更新方式为压缩更新时，所述更新数据为压缩后的数据。

可选地，所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据包括：

对所述压缩后的数据进行解压处理，得到新固件数据；

在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：

所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以便在运行引导加载程序期间从所述待引导分区中应用所述新固件数据。

可选地，在所述更新方式信息标识本次固件所采用的更新方式为全量更新时，所述更新数据为新固件数据，所述存储传输数据的分区为所述存储新固件数据的分区。

可选地，所述更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件包括：

所述更新触发模块接收到所述源设备发送的固件的版本存在更新的推送信息；

所述更新触发模块向所述源设备发送固件的版本是否存在更新的查询请求，并接收到所述源设备发送的版本存在更新的回复信息。

可选地，在所述数据接收模块从源设备获取传输数据之后还包括：

所述数据接收模块判断接收到的传输数据是否为经过封装的数据；如果是，则从所述传输数据中获取更新方式信息，确定本次固件所采用的更新方式。

可选地，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之前还包括：

所述数据接收模块判断所述更新数据是否执行过加密处理；如果是，则依据所述传输数据中的加密类型信息，对所述更新数据进行解密处理。

可选地，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之前还包括：

所述数据接收模块依据所述传输数据中的完整性校验参数信息，对接收到的更新数据是否完整进行校验。

可选地，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之后还包括：

所述数据接收模块将所述存储传输数据的分区设置为待引导分区，以使所述数据处理模块从所述存储传输数据的分区中获取所述传输数据。

可选地，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之前还包括：

所述数据处理模块从所述传输数据中获取文件头信息，对所述文件头信息进行校验。

可选地，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之前还包括：

所述数据处理模块从所述传输数据中获取更新数据的签名信息，对所述签名信息进行校验。

可选地，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之后还包括：

所述数据处理模块从所述传输数据中获取完整性校验参数信息，对写入到所述存储新固件数据的分区的数据是否完整进行校验。

可选地，所述更新方式信息识别本次固件所采用的更新方式为差分更新或压缩更新时，在所述数据处理模块从所述传输数据中获取完整性校验参数，对写入到所述存储新固件数据的分区的数据是否完整进行校验之后还包括：

若完整性校验通过，则所述数据处理模块执行将所述存储新固件数据的分区设置为待引导分区的操作；若完整性校验未通过，则所述数据处理模块不执行将所述存储新固件数据的分区设置为待引导分区的操作。

本申请还提供了一种嵌入式设备，包括：第一存储器以及第一处理器，所述第一存储器用于存储计算机程序，所述第一处理器用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

本申请还提供了一种嵌入式设备固件更新方法，应用于开发端设备，所述方法包括：

确定固件更新所采用的更新方式，生成更新方式信息；

依据所述更新方式信息，生成对应的更新数据；

基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据。

可选地，所述依据所述更新方式信息，生成对应的更新数据包括：

所述更新方式信息为差分更新时，生成的更新数据为补丁数据；

所述更新方式信息为压缩更新时，生成的更新数据为压缩后的数据；

所述更新方式信息为全量更新时，生成的更新数据为新固件数据。

可选地，所述传输数据进一步包括以下信息的任意一种或任意组合：

文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息。

可选地，在所述基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据之后还包括：

将所述传输数据发送至源设备进行存储。

本申请还提供了一种开发端设备，包括：第二存储器以及第二处理器，所述第二存储器用于存储计算机程序，所述第二处理器用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

本申请还提供了一种嵌入式设备固件更新系统，包括上述所述的嵌入式设备以及源设备；所述源设备存储有供所述嵌入式设备固件更新的传输数据。

可选地，所述源设备为开发端设备或云端设备。

本申请所提供的嵌入式设备固件更新方法，该嵌入式设备包括引导加载程序以及固件更新获取程序；引导加载程序包括数据处理模块，固件更新获取程序包括更新触发模块以及数据接收模块。在更新触发模块检测到对嵌入式设备的固件进行更新的触发事件时，数据接收模块从源设备获取传输数据，将传输数据中供嵌入式设备进行固件更新的更新数据写入到存储传输数据的分区。数据处理模块根据传输数据中的更新方式信息，对接收到的更新数据进行处理，得到新固件数据，以便在运行引导加载程序期间从存储新固件数据的分区中应用该新固件数据，以完成固件的更新。

本申请中数据处理模块以优化的方式在引导加载程序中执行，而由于引导加载程序不需要加载很多操作系统的功能，也不需要有网络通信的协议栈，使得引导加载程序可用内存多，可以给数据处理模块提供更多的可用内存空间。对于采用压缩更新、差分更新而言，更多的可用内存空间意味着可以使用更高级别的压缩算法来执行压缩，从而能够获得更小的压缩包或者补丁文件，避免过多的流量消耗和时间消耗，可以部署在软硬件资源受限的设备上，提升固件更新的效率。此外，与现有方案仅能支持一种固件更新方式相比，本申请具备更好的兼容性，能够采用不同的更新方式适用不同的使用场景和功能各异的物联网设备，满足不同的固件更新需求。此外，本申请还提供了一种具有上述技术优点的嵌入式设备、开发端设备以及嵌入式设备固件更新系统。

附图说明

在下文中，将基于实施例参考附图进一步解释本申请。

图1示出全量更新流程示意图；

图2示出压缩更新流程图示意图；

图3示出差分更新流程示意图；

图4示意性地示出本申请所提供的嵌入式设备固件更新方法的一种具体实施方式的流程图；

图5示意性地示出本申请所提供的嵌入式设备固件更新方法在开发端设备执行的具体流程图；

图6示意性地示出本申请所提供的嵌入式设备固件更新方法中数据接收模块的具体实施方式的流程图；

图7示意性地示出本申请所提供的方案引导加载程序运行的实施方式流程图；

图8示出启用三种更新方式时嵌入式设备的存储空间划分情况示意图；

图9示出仅启用全量更新和压缩更新时嵌入式设备的存储空间划分情况示意图；

图10示意性地示出了本申请所提供的嵌入式设备的结构框图；

图11示意性地示出了本申请所提供的开发端设备的结构框图；

图12示意性地示出了本申请所提供的嵌入式设备固件更新系统的结构框图。

具体实施方式

以下将结合附图和具体的实施方式，对本申请的方法、设备和系统进行详细说明。应理解，附图所示以及下文所述的实施例仅仅是说明性的，而不作为对本申请的限制。

按照固件更新中对传输数据的处理，可以将固件更新方法分为三种：全量更新、压缩更新和差分更新，其中差分更新也可以称为增量更新。

如图1全量更新流程示意图所示，全量更新即将完整的新固件数据传输至嵌入式设备，以完成固件的更新。

如图2压缩更新流程图示意图所示，在开发端设备将新固件数据进行压缩，嵌入式设备接收到压缩后的数据后执行解压操作，然后应用解压后的新固件数据，以完成固件的更新。

如图3差分更新流程示意图所示，在开发端设备对新固件数据以及旧固件数据进行差分处理，生成补丁数据，并将补丁数据传输至嵌入式设备；嵌入式设备结合接收到的旧固件数据以及补丁数据，进行差分解码操作恢复出新固件数据，以完成固件的更新。

本申请所提供的嵌入式设备固件更新方法的一种具体实施方式的流程图如图4所示，参照图4，本方法应用于嵌入式设备，该嵌入式设备包括引导加载程序以及固件更新获取程序。引导加载程序存储在引导加载分区中，固件更新获取程序存储在对应的固件分区中。其中，固件更新获取程序包括更新触发模块以及数据接收模块，引导加载程序包括数据处理模块。

支持FOTA的设备上通常具有两种程序：引导加载程序(bootloader程序)以及固件程序(app程序)。在执行FOTA功能时，引导加载程序主要完成读取系统参数，并依据系统参数加载指定的固件更新获取程序的功能。固件程序负责设备的正常功能，其中集成有固件更新获取程序。本申请中，数据处理模块可以设置在引导加载程序中执行。而包括更新触发模块以及数据接收模块可以设置在固件更新获取程序中执行，主要负责接收更新数据，改写系统参数的功能。

该方法具体包括以下步骤：

S101：更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件。

检测到对嵌入式设备的固件进行更新的触发事件可以具体为：更新触发模块在接收到所述源设备发送的固件的版本存在更新的推送信息；或者更新触发模块向所述源设备发送固件的版本是否存在更新的查询请求，并接收到所述源设备发送的版本存在更新的回复信息。

S102：数据接收模块从源设备获取传输数据，所述传输数据至少包括供所述嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息；将所述更新数据写入到存储传输数据的分区。

其中，传输数据至少包括供嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息。可以理解的是，传输数据还可以进一步包括其他数据，例如，可以包括以下信息的任意一种或任意组合：文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息，这均不影响本申请的实现。

具体地，更新方式信息标识本次固件所采用的更新方式为差分更新时，所述更新数据为补丁数据；更新方式信息标识本次固件所采用的更新方式为压缩更新时，所述更新数据为压缩后的数据。更新方式信息标识本次固件所采用的更新方式为全量更新时，所述更新数据为新固件数据。

数据接收模块获取到传输数据之后，将更新数据写入到存储传输数据的分区中。

S103：数据处理模块依据所述更新方式信息，对接收到的所述更新数据进行处理，得到新固件数据，以便在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据。

具体地，更新方式信息标识本次固件所采用的更新方式为差分更新时，数据处理模块将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据。并在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以在运行引导加载程序期间从所述待引导分区应用新固件数据。

作为一种具体实施方式，在所述数据处理模块将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据之前还包括：数据处理模块从所述传输数据中获取旧固件数据的版本校验信息或摘要校验信息；依据所述版本校验信息或摘要校验信息判断所述补丁数据与所述旧固件数据是否匹配；如果是，则执行所述将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据的操作。

在实际更新过程中，可能会出现将版本3和版本2的固件差分生成的补丁数据发送到正在运行的版本1的嵌入式设备上的情况，导致补丁数据和版本1进行差分解码，生成错误的版本3。因此，采用上述具体实施方式对补丁数据和旧固件数据进行匹配，能够保证补丁数据以及旧固件数据在成功匹配条件下才能恢复出新固件数据，从而避免了生成错误版本的新固件数据的概率，提高了固件更新过程的可靠性。

更新方式信息标识本次固件所采用的更新方式为压缩更新时，数据处理模块对所述压缩后的数据进行解压处理，得到新固件数据。在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以在运行引导加载程序期间从所述待引导分区应用新固件数据。

更新方式信息标识本次固件所采用的更新方式为全量更新时，更新数据即为新固件数据，存储传输数据的分区即为存储新固件数据的分区。

现有的很多方案中，将更新触发模块、数据接收模块以及数据处理模块均统一设置在固件程序中，因此导致固件程序的体积较为臃肿。而本申请提供的方案中，将数据处理模块设置在引导加载程序中。以嵌入式设备中包括一个引导加载程序和两个固件程序(app_0、app_1)为例，表1示出了现有方案与本申请提供的方案最终FOTA功能需要占用的内存空间比较。

表1

由表1可以看出，与现有的方案相比，本申请提供的方案将数据处理模块存储在引导加载程序中，能够使得整个FOTA功能需要占用的存储空间更少。

此外，每个模块在运行时均会占用一定的内存，导致实施解压、解码的数据处理模块的可用内存较少。以一款网络摄像头为例，其RAM大小为400KB，在引导加载程序、固件程序中可用内存如表2所示。

表2

可见，本申请中数据处理模块在引导加载程序中执行，而由于引导加载程序不需要加载很多操作系统的功能，也不需要有网络通信的协议栈，使得引导加载程序可用内存多，可以给数据处理模块提供更多的可用内存空间。对于采用压缩更新、差分更新而言，更多的可用内存空间意味着可以使用更高级别的压缩算法来执行压缩，从而能够获得更小的压缩包或者补丁文件，避免过多的流量消耗和时间消耗，可以部署在软硬件资源受限的设备上，提升固件更新的效率。此外，与现有方案往能支持一种固件更新方式相比，本申请具备更好的兼容性，能够采用不同的更新方式适用不同的使用场景和功能各异的物联网设备，满足不同的固件更新需求。

本申请所提供的嵌入式设备固件更新方法，可以在开发端设备生成传输数据。生成的传输数据可以直接发送至嵌入式设备，进行固件更新。也可以发送至其他源设备进行存储，嵌入式设备从该源设备中获取到传输数据，进行固件更新。

作为一种具体实施方式，传输数据的文件格式可以如表3所示。

表3

在表3中，序号0～9为开发端设备生成的传输数据的文件头部分。序号10对应的部分为更新数据。更新方式信息为差分更新时，生成的更新数据为补丁数据；更新方式信息为压缩更新时，生成的更新数据为压缩后的数据；更新方式信息为全量更新时，生成的更新数据为新固件数据。

在开发端设备端，可以通过配置项生成指定的传输数据。具体地，参照图5，本申请所提供的嵌入式设备固件更新方法在开发端设备执行的具体过程包括：

S201：确定固件更新所采用的更新方式，生成更新方式信息。

本步骤中，可以由开发人员结合本次更新的情况，选择本次更新所采用的更新方式。具体地，开发人员可以先在本地验证三种更新方式要传输的数据量，确定出设备完成固件更新所需的时间，对比后选择出最适合的固件更新方式。

S202：依据所述更新方式信息，生成对应的更新数据。

其中，所述更新方式信息为差分更新时，生成的更新数据为补丁数据；所述更新方式信息为压缩更新时，生成的更新数据为压缩后的数据；所述更新方式信息为全量更新时，生成的更新数据为新固件数据。

S203：基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据。

结合更新数据以及更新方式信息，生成供嵌入式设备进行固件更新的传输数据。传输数据进一步可以包括以下信息的任意一种或任意组合：文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息。

具体地，可以在生成的更新数据补充文件头部分。作为一种具体实施方式，文件头部分可以包括表3中序号0～9所列出的信息。进一步地，若要使用签名信息，则可以在更新数据后添加对该更新数据的签名信息。若要使用加密功能，则可以对更新数据执行加密处理。

在所述基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据之后还包括：将所述传输数据发送至源设备进行存储。嵌入式设备可以与该源设备通信，获取源设备发送的传输数据，以进行固件的更新。

图6示出了本申请所提供的嵌入式设备固件更新方法中数据接收模块的具体实施方式的流程图。该方法应用于嵌入式设备，图6示出了嵌入式设备接收更新数据的具体过程，其具体包括：

S301：更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件。

S302：数据接收模块从源设备获取传输数据。

传输数据除包括供所述嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息之外，还可以进一步包括以下信息：文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息。

传输数据可以由开发端设备生成，数据接收模块直接从该开发端设备获取传输数据。也可以由开发端设备生成后发送到其他源设备，例如云端设备。数据接收模块从该源设备处获取传输数据，这均不影响本申请的实现。

S303：数据接收模块判断接收到的传输数据是否为经过封装的数据；如果是，则从所述传输数据中获取更新方式信息，确定本次固件所采用的更新方式。

具体地，数据接收模块依据传输数据中的信息，例如表3中的Magic num信息，判断接收到的传输数据是否为经过封装的数据。如果是，则从传输数据中获取更新方式信息，确定本次固件所采用的更新方式。

S304：数据接收模块判定所述更新数据执行过加密处理，则依据所述传输数据中的加密类型信息，对所述更新数据进行解密处理。

具体地，数据接收模块可以判断更新数据是否执行过加密处理。在执行过加密处理的情况下，依据传输数据中的加密类型信息，对更新数据进行相应的解密处理。

可以理解的是，本申请所提供的方案在启动加解密功能时，其解密过程是在固件程序中执行，而固件程序是多任务环境，因此可以实现边解密边执行其他任务。与将解密功能放在引导加载程序中执行的方案相比，由于引导加载程序为单任务环境，无法实现边解密边执行其他任务，采用该种实施方式可以提升固件更新的效率。

解密过程具体可以为边下载边执行解密，例如接收100KB的更新数据，即对接收到的该100KB的更新数据进行解密。当然，也可以在接收到全部的更新数据后再执行解密操作，这均不影响本申请的实现。

S305：数据接收模块将所述更新数据写入到存储传输数据的分区。

数据接收模块依据更新方式信息，将更新数据写入到存储传输数据的分区中。作为一种具体实施方式，若更新方式信息为全量更新，则将更新数据写入到固件分区中；若更新方式为压缩更新，则将更新数据写入到固件分区或预先划分的压缩分区中；若更新方式为差分更新，则将更新数据写入到预先划分的补丁分区中。

S306：数据接收模块依据所述传输数据中的完整性校验参数信息，对接收到的更新数据是否完整进行校验。

在S305更新数据接收完毕后，根据传输数据中的完整性校验参数信息，例如表3中序号8和9，对接收到的更新数据是否完整进行校验。例如，将接收到的更新数据中的文件头校验和与嵌入式设备端计算出的校验和进行比较，若一致则表示数据完整。如果校验通过则进入下一步，如果校验不通过，则产生错误信息并上报。

S307：数据接收模块将所述存储传输数据的分区设置为待引导分区，以使所述数据处理模块从所述存储传输数据的分区中获取所述传输数据。

通过改写FOTA升级的系统参数，将存储传输数据的分区设置为待引导分区。可以理解的是，若当前使用的更新方式为压缩更新，则在系统参数中指定存放解压数据的分区；若当前使用的更新方式为差分更新，则在系统参数中指定存储旧固件数据所在的分区，以及存储新固件数据的分区。

在上述示例中，嵌入式设备具有两个固件分区app_0、app_1，在当前运行app_0时，只能将更新数据写入到另一个空闲的分区app_1中。

嵌入式设备还可以具有两个以上固件分区的情况，以具有三个固件分区：app_0\app_1\app_2为例。在有多个固件分区的情况下，假设压缩固件下载到了app_2(一般将序号最大的固件分区设置为存放压缩固件的分区)，则可以将压缩固件解压到app_0或者app_1，这时需要在系统参数中进行指定，告知bootloader程序将解压的数据写到哪个分区中。

对于嵌入式设备是双系统的情况，例如，app_0中用于存放A系统，app_1用于存放B系统，则其压缩固件都可以存到app_2，然后依靠bootloader程序解压app_2里的数据，分别更新app_0的固件，或者app_1的固件。

S308：调用系统接口，重启设备，以便设备进入引导加载程序应用更新后的固件。

下面对引导加载程序运行时执行的具体操作进行进一步详细介绍。如图7本申请所提供的方案引导加载程序运行的实施方式流程图所示，该过程具体包括：

S401：嵌入式设备重启后进入到引导加载程序中。

S402：数据处理模块从传输数据中获取文件头信息，对所述文件头信息进行校验。

具体地，数据处理模块可以对文件头信息进行校验。

S403：数据处理模块从所述传输数据中获取更新数据的签名信息，对所述签名信息进行校验。

可选地，若启用了数字签名的功能，bootloader程序还会校验更新数据的签名信息，来避免使用未经授权的数据，提高系统的安全性。

S404：数据处理模块判断更新方式是否为全量更新，如果是，则进入S411；如果否，则进入S405；

S405：数据处理模块判断更新方式是否为压缩更新，如果是，则进入S407；如果否，则进入S406；

S406：数据处理模块确定更新方式为差分更新，进入S409；

S407：数据处理模块对压缩后的数据进行解压，生成解压后的数据，并将解压后的数据写入到存储新固件数据的分区中，进入S408；

在更新方式后为压缩更新时，通过读取系统参数，获取存储压缩数据的压缩分区的信息，并且初始化对应的解压算法，对压缩后的数据进行解压，并将解压后的数据写入到指定的存储解压后的数据的分区中。

S408：改写系统标识，将存储解压后的数据的分区设置为待引导分区；进入S411；

S409：数据处理模块依据旧固件数据以及补丁数据，进行差分解码处理，生成新固件数据，并将新固件数据写入到存储新固件数据的分区中，进入S410；

在更新方式后为差分更新时，通过读取系统参数，获取存储旧固件数据的分区的信息，以及存储新固件数据的分区的信息，并初始化对应的差分更新算法。读取旧固件数据以及补丁数据，运行差分更新算法，生成新固件数据。将得到的新固件数据写入到存储新固件数据的分区中。

S410：改写系统标识，将存储新固件数据的分区设置为待引导分区；进入S411；

S411：读取系统标识，应用新固件数据，以完成固件的更新。

本实施例中，在更新方式信息识别本次固件所采用的更新方式为差分更新或压缩更新时，还可以由数据处理模块从所述传输数据中获取完整性校验参数，对写入到所述存储新固件数据的分区的数据是否完整进行校验。若完整性校验通过，则所述数据处理模块执行将所述存储新固件数据的分区设置为待引导分区的操作；若完整性校验未通过，则所述数据处理模块不执行将所述存储新固件数据的分区设置为待引导分区的操作。通过这样的设置，当数据处理模块出现错误、设备断电的情况下，旧固件数据和系统参数不会被破坏，下次会继续尝试执行解压、解码，确保接收到的新固件数据是完整的数据，避免加载不完整的新固件导致设备启动异常，从而提高了系统的可靠性。此外，当采用的更新方式为压缩更新时，在执行完解压或者搬运等操作后，本申请并不会擦除数据，只会在成功解压后改写系统标识，避免了擦除操作增加bootloader的运行时间，从而使本申请的启动时间更快，也避免了重启失败时设备因无可运行的app而只能恢复出厂设置的风险。

可以理解的是，在更新方式为全量更新时，在当前分区的数据即为新固件数据，因此在bootloader程序执行时不需要再将数据搬运到存储新固件数据的分区中，即当前正常引导的分区即为存储新固件数据的分区。因此，该步骤中不需要改写系统标识。在使用乒乓升级时，新固件数据写到存储新固件数据的分区，重启后直接运行该分区的新固件数据，而不用将该分区的数据搬移到另一个存储分区中，重启速度更快，并减少了对存储分区的擦除操作引起的损耗，延长了存储设备的使用寿命。

现有方案往往仅支持一种固件更新方式，兼容性较差，无法适用不同的使用场景，无法满足功能各异的物联网设备更新的需求。本申请所提供的固件更新方法，兼容差分更新、压缩更新、全量更新三种更新方式，可以满足不同设备的固件更新的需求。并且，可以解决差分更新的补丁数据、压缩更新的压缩数据大小不稳定的问题。在补丁分区过大，即本次更新涉及的内容较多时，导致补丁数据的实际大小超出预先划分的补丁分区或压缩分区时，可以通过压缩更新来实现节省流量的目的。此外，本申请采用了一套通用的文件格式，涉及对数据进行加密、完整性校验以及签名校验等多重校验操作，使得固件更新的过程更加安全可靠。

作为一种具体实施方式，开发人员可以在产品设计阶段决定采用哪种固件更新方式。一种同时启用三种更新方式的嵌入式设备的存储空间划分情况可如图8所示，该存储空间可以包括系统参数分区、bootloader分区、app_0分区、app_1分区以及补丁分区。其中，系统参数分区用于存储系统的配置、网络连接信息、系统引导参数等信息。bootloader分区用于存储bootloader程序，加载app_0以及app_1。app_0分区、app_1分区分别用于存储app_0、app_1，以实现相同或不同的固件功能。补丁分区用于在进行差分更新时存储补丁数据。使用本申请所提供的固件更新方法可以按下述场景进行选择：

当新固件数据、旧固件数据的差异小时，此时补丁分区足够存放补丁数据，因此此时可以选择使用差分更新来执行本次更新。若当前运行的app存储在app_0分区，接收补丁数据，然后设置补丁分区为引导分区。重启后，bootloader程序检测到补丁分区里的补丁数据，执行对app_0与补丁数据进行差分解码的操作，将得到新固件数据写入app_1。这样就不会破坏app_0里的可用固件，否则如遇突发情况可能导致设备降级，最后设置app_1为待引导分区，应用app_1里的新固件数据。类似地，当前若运行的是app1，就在app1里接收补丁数据，然后执行app1与补丁数据的差分解码操作。

可以理解的是，当前大部分差分更新算法如vcdiff、bsdiff、xdelta都不支持在软硬件资源受限的嵌入式设备上实现本地更新，因此需要划分一块单独的补丁分区来存储补丁数据。本申请所采用的差分更新算法可以是上述差分更新算法及其变体算法，这均不影响本申请的实现。

当新固件数据、旧固件数据的差异较大时，此时补丁分区可能无法存储补丁数据，以往的方案选择采用多次差分更新，每次只更新一部分来最终完成全部的更新，但在较大的更改的场景下(如购买的设备一直没有升级，需要从版本1升级到版本10)会影响客户使用体验。此时，可以选择使用压缩更新，若当前运行的app存储在app_0分区，则将压缩文件下载到app_1分区，然后设置app_1为待引导分区，重启后，bootloader程序能够立即找到压缩数据所在的分区，然后发现有一个压缩更新待完成。然后在bootloader程序中将app_1分区的压缩固件解压到app_0分区，解压完成后改写引导分区为app_0，并应用app_0分区的新固件数据。

虽然差分更新、压缩更新可以节省传输流量，降低下发更新数据的源设备端的并行压力，并节省传输更新数据的时间消耗。但其都需要在bootloader程序中进行解压或者解码处理，这会影响bootloader程序的快速启动，对于需要快速启动(如违章抓拍摄像头)，或者使用局域网更新(流量不计费)的设备而言，则可以选择使用全量更新的方式进行更新。

现有方案很难给出合理的存储空间划分情况，当划分的用于存储压缩数据或者存储补丁数据的存储空间较小时，会因为没有足够的物理存储空间而无法完成固件的更新。本申请可以在无法使用差分更新的情况下，例如旧固件数据与新固件数据差异较大，导致生成的补丁数据较大，这时可以选择采用压缩更新或者全量更新，从而更大限度地利用设备的资源，提升用户的使用体验。

作为一种具体实施方式，开发人员也可在产品设计阶段仅启用全量更新和压缩更新。此时嵌入式设备的存储空间划分情况可如图9所示，该存储空间可以包括系统参数分区、bootloader分区、app_0分区、app_1分区。其中，系统参数分区用于存储系统的配置、网络连接信息、系统引导参数等信息。bootloader分区用于存储bootloader程序，加载app_0以及app_1。app_0分区、app_1分区分别用于存储app_0、app_1，以实现相同或不同的固件功能。这种场景下，用本本申请所提供的方案可以按下述场景进行选择：

当需要节省流量，或者节省传输更新数据的时间消耗时，本次更新可以选择压缩更新。若当前正在运行的是app_0分区，则将压缩的固件下载到app_1分区；在bootloader程序中执行解压，并将解压得到的新固件数据写到app_0分区，然后引导app_0分区的新固件数据运行。

当需要快速启动，或者网络环境好，不需要节省流量时，本次更新使用全量更新。

以当前比较流行的xz压缩算法、以及bsdiff差分更新算法为例，其不同压缩率下的设备端处理数据需要的内存消耗如表4所示。越大的压缩率，代表要传输的数据越小，嵌入式设备端需要的内存越大。

其中，压缩率＝(原始数据大小-补丁或者压缩后的数据的大小)/原始数据大小。

表4

本申请中数据处理模块在引导加载程序中执行，而由于引导加载程序不需要加载很多操作系统的功能，也不需要有网络通信的协议栈，使得引导加载程序可用内存多，可以给数据处理模块提供更多的可用内存空间。对于采用压缩更新、差分更新而言，更多的可用内存空间意味着可以使用更高级别的压缩算法来执行压缩，从而能够获得更小的压缩包或者补丁文件，避免过多的流量消耗和时间消耗，提升了固件更新的效率。

此外，本申请还提供了一种嵌入式设备11，如图10本申请所提供的嵌入式设备的结构框图所示，该嵌入式设备11具体包括：第一存储器111以及第一处理器112，所述第一存储器111用于存储计算机程序，所述第一处理器112用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

可以理解的是，该嵌入式设备执行固件更新的过程与上述应用于嵌入式设备的固件更新方法相对应，可参照上述内容，在此不再赘述。

此外，本申请还提供了一种开发端设备12，如图11本申请所提供的开发端设备的结构框图所示，该开发端设备12包括：第二存储器121以及第二处理器122，所述第二存储器121用于存储计算机程序，所述第二处理器122用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

可以理解的是，该开发端设备可以与上述应用于开发端设备的固件更新方法相对应，可参照上述内容，在此不再赘述。

此外，本申请还提供了一种嵌入式设备固件更新系统1，如图12本申请所提供的嵌入式设备固件更新系统的结构框图所示，包括嵌入式设备11以及源设备13；所述源设备13存储有供所述嵌入式设备固件更新的传输数据。

其中，嵌入式设备11与源设备13之间可以通过多种通信协议进行数据传输。所述源设备13可以为开发端设备或云端设备。其中，嵌入式设备11可以采用本申请所记载的嵌入式设备固件更新方法进行固件更新，具体实施方式可参照方法内容的记载，在此不再赘述。

虽然出于本公开的目的已经描述了本申请各方面的各种实施例，但是不应理解为将本公开的教导限制于这些实施例。在一个具体实施例中公开的特征并不限于该实施例，而是可以和不同实施例中公开的特征进行组合。例如，在一个实施例中描述的根据本申请的方法的一个或多个特征和/或操作，亦可单独地、组合地或整体地应用在另一实施例中。本领域技术人员应理解，还存在可能的更多可选实施方式和变型，可以对上述系统进行各种改变和修改，而不脱离由本申请权利要求所限定的范围。