CN118331620A - 一种固件更新方法、装置、设备及可读存储介质 - Google Patents

Abstract

本说明书提供一种固件更新方法、装置、设备及可读存储介质，该方法包括：获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作；根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程；根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。通过本说明书的技术方案，根据依赖关系，关闭且仅关闭与需要发生更新的内容关联的进程，以及进一步与这些进程具备依赖关系的进程，其他进程可以在固件更新过程中保持运行，设备无需关机或重启，实现业务不中断固件更新。

Description

一种固件更新方法、装置、设备及可读存储介质

技术领域

本说明书涉及通信技术领域，尤其是涉及一种固件更新方法、装置、设备及可读存储介质。

背景技术

在当今高度信息化的社会背景下，嵌入式系统作为信息技术的重要组成部分，广泛应用于工业自动化、物联网、智能设备、通信网络等诸多领域，其稳定、高效、可靠的运行对于保障相关业务连续性和服务质量具有决定性意义。然而，随着技术发展与市场需求的不断变化，固件升级成为嵌入式系统生命周期管理中不可或缺的一环，旨在引入新功能、修复安全漏洞、优化性能或适应新的业务需求。传统的固件升级过程中，通常包括新固件版本校验、存储介质区刷新、嵌入式CPU重启以及新固件版本生效等步骤。其中，CPU重启环节不可避免地造成业务中断，中断时长因系统复杂度差异而异，一般持续几十秒至几分钟。对于那些对业务连续性有严格要求的应用场景而言，如此长时间的中断显然是无法接受的，尤其是在金融交易、电信运营、医疗监控、能源管理等高可靠性领域，业务中断可能导致经济损失、服务质量下降甚至安全隐患。

现有的嵌入式系统固件升级方法普遍采用全系统重启模式，即在完成新固件写入后，触发系统整体重启以加载并运行新固件。尽管这种方法操作相对简单，但在实际应用中暴露出了显著的局限性。首先，重启过程中，系统必须先停止所有正在进行的业务活动，导致服务暂时不可用，从而产生业务中断。其次，重启过程的时间成本难以精确预测和控制，特别是在复杂的嵌入式环境中，系统启动和初始化所需时间可能会显著增加，进一步延长业务中断时长。最后，对于某些关键任务或实时性要求极高的应用，即使短暂的服务中断也可能引发严重后果，如数据丢失、系统状态紊乱或协议栈故障等。

综上，现有技术至少存在以下技术问题：①业务中断问题，在固件升级过程中，为了加载新版本的固件，必须重启嵌入式系统的CPU，这一步骤会导致系统在启动过程中出现业务中断，中断时长根据系统复杂度不同，可能从几十秒到几分钟不等；②升级风险，由于重启操作的介入，每次固件升级都伴随着一定的风险，包括但不限于数据丢失、系统不稳定、甚至硬件损坏；③维护成本，频繁的重启和业务中断不仅影响用户体验，也增加了系统的维护成本，尤其是在需要现场维护的情况下，成本和风险更是显著增加。

鉴于上述问题，业界对实现业务不中断(In-Service Software Upgrade,ISSU)的固件升级方案的需求日益迫切。

发明内容

有鉴于此，本说明书提供一种固件更新方法、装置及电子设备、可读存储介质，以改善上述难以实现业务不中断固件更新的问题。

具体地技术方案如下：

本说明书提供了一种固件更新方法，应用于应用对象，所述方法包括：获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作；根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程；获取与待处理进程具有依赖的关系的进程，认为与待处理进程具有依赖的关系的进程为新的待处理进程，并循环执行本步骤直至不再获取到新的与待处理进程具有依赖的关系的进程；根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。

作为一种技术方案，所述根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程，包括：根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程。

作为一种技术方案，所述根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程，还包括：记录各待处理进程被关闭的顺序；根据记录的各待处理进程被关闭的顺序，以相逆的顺序依次重新启动各待处理进程。

作为一种技术方案，所述获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作，包括：若所述实际更新内容为用户态应用程序，则执行后续步骤；若所述实际更新内容为内核系统或系统基础库，则终止执行后续步骤。

本说明书同时提供了一种固件更新装置，应用于应用对象，所述装置包括：第一模块，用于获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作；第二模块，用于根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程，获取与待处理进程具有依赖的关系的进程，认为与待处理进程具有依赖的关系的进程为新的待处理进程，并循环执行本步骤直至不再获取到新的与待处理进程具有依赖的关系的进程；第三模块，用于根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。

作为一种技术方案，所述根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程，包括：根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程。

作为一种技术方案，所述根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程，还包括：记录各待处理进程被关闭的顺序；根据记录的各待处理进程被关闭的顺序，以相逆的顺序依次重新启动各待处理进程。

作为一种技术方案，所述获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作，包括：若所述实际更新内容为用户态应用程序，则调用第二模块执行后续步骤；若所述实际更新内容为内核系统或系统基础库，则终止调用第二模块。

本说明书同时提供了一种电子设备，包括处理器和可读存储介质，所述可读存储介质存储有能够被所述处理器执行的机器可执行指令，处理器执行所述机器可执行指令以实现前述的固件更新方法。

本说明书同时提供了一种可读存储介质，所述可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现前述的固件更新方法。

本说明书提供的上述技术方案至少带来了以下有益效果：

根据依赖关系，关闭且仅关闭与需要发生更新的内容关联的进程，以及进一步与这些进程具备依赖关系的进程，其他进程可以在固件更新过程中保持运行，设备无需关机或重启，实现业务不中断固件更新。

附图说明

为了更加清楚地说明本说明书实施方式或者现有技术中的技术方案，下面将对本说明书实施方式或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施方式，对于本领域普通技术人员来讲，还可以根据本说明书实施方式的这些附图获得其他的附图。

图1是本说明书一种实施方式中的固件更新方法的流程图；

图2是本说明书一种实施方式中的架构图；

图3是本说明书一种实施方式中的进程关系示意图；

图4是本说明书一种实施方式中的进程关系示意图；

图5是本说明书一种实施方式中的固件更新装置的结构图；

图6是本说明书一种实施方式中的电子设备的硬件结构图。

附图标记：第一模块21，第二模块22，第三模块23。

具体实施方式

在本说明书实施方式使用的术语仅仅是出于描述特定实施方式的目的，而非限制本说明书。本说明书和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。还应当理解，本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书实施方式可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

业界对实现业务不中断(In-Service Software Upgrade,ISSU)的固件升级方案的需求日益迫切。ISSU旨在通过精心设计的升级策略和技术手段，允许在系统运行状态下进行固件更新，同时确保主业务的连续性和稳定性，尽可能降低升级过程对系统及业务的影响。目前，尽管市场上已存在多种固件升级技术，但针对在保证嵌入式CPU不重启、主体业务不受影响的情况下，实现特定业务模块的动态更新这一具体需求，尚未发现成熟的、针对性强的解决方案。因此，开发一种能够在嵌入式系统固件升级过程中实现业务不中断的技术方案，成为提升系统运维效率、增强业务可用性、满足高可靠场景需求的关键所在。

特别值得关注的是，嵌入式系统尤其是基于Linux内核的操作系统，其内部结构通常包含内核态、系统调用库函数、Shell以及用户程序等多个层次。在后期维护阶段，内核系统和系统基础库因涉及系统核心功能，其稳定性要求极高，故通常极少发生变更，固件升级主要聚焦于用户态应用程序，如用户进程Daemon、Lib库和XML等插件。这些用户程序是业务逻辑的具体实现载体，与实际业务紧密关联，且由于业务需求的快速迭代，其变更较为频繁。因此，针对此类用户程序的ISSU固件升级策略，应充分考虑其间的依赖关系，以确保升级过程中不影响整体系统架构及主业务的稳定运行。

综上所述，尽管现有的嵌入式系统固件升级技术能够完成固件更新，但其全系统重启的升级方式无法满足高可靠业务场景对业务连续性的严苛要求。在实际应用中，亟需一种创新的、能够实现在嵌入式CPU不重启、主体业务不受影响的前提下，对特定用户态业务进行动态升级的技术方案，以克服现有技术中因重启导致的业务中断问题，提高系统升级过程中的业务可用性，满足现代社会对嵌入式系统高效、稳定运行的期待。这样的技术方案不仅有助于提升系统运维效率，减少因升级造成的业务损失，而且对于保障关键基础设施、提升服务质量具有重大意义。

有鉴于此，本说明书提供一种固件更新方法、装置及电子设备、可读存储介质，以至少改善上述技术问题之一。

具体地技术方案如后述。

在一种实施方式中，本说明书提供了一种固件更新方法，应用于应用对象，所述方法包括：获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作；根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程；获取与待处理进程具有依赖的关系的进程，认为与待处理进程具有依赖的关系的进程为新的待处理进程，并循环执行本步骤直至不再获取到新的与待处理进程具有依赖的关系的进程；根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。

具体地，如图1，包括以下步骤：

步骤S11，获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作。

在本步骤中，系统首先需要获取待更新的目标固件文件。这通常涉及到从版本控制系统、固件仓库或远程服务器上下载或接收新固件的完整文件。获取到目标固件文件后，系统将执行一个关键操作：比对目标固件文件与当前正在使用的固件文件之间的差异。系统执行固件更新操作，这可能包括替换文件系统上的文件、更新配置参数或重新加载系统服务。

举例来说，假设当前系统中运行的固件版本为V1.0，而新的目标固件版本为V1.1。系统会使用文件比对工具(如diff工具)来分析V1.1与V1.0之间的差异。这些差异可能包括新增的文件、被修改的文件以及被删除的文件。比对完成后，系统将记录下所有差异，形成一份更新内容列表。

步骤S12，根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程。

接下来，系统需要根据步骤S11中获取的实际更新内容，识别出与之具有依赖关系的进程。在嵌入式系统中，许多用户态的进程可能依赖于特定的库文件或系统服务。因此，当这些库文件或服务被更新时，依赖它们的进程也需要被更新或重启以适应新版本。

例如，如果更新内容列表中包含了对网络通信库的修改，那么所有使用该网络通信库的进程都需要被识别为待处理进程。系统可以通过分析进程的配置文件、启动脚本或直接查询进程的依赖关系数据库来识别这些待处理进程。

步骤S13，获取与待处理进程具有依赖的关系的进程，认为与待处理进程具有依赖的关系的进程为新的待处理进程，并循环执行本步骤直至不再获取到新的与待处理进程具有依赖的关系的进程。

在识别出直接依赖于更新内容的进程后，系统还需要进一步识别这些待处理进程的间接依赖。这些间接依赖可能不会直接影响固件的升级，但如果不妥善处理，它们可能会导致系统的不稳定或业务的中断。

系统将通过递归查询或遍历依赖关系图来识别所有与待处理进程有依赖关系的进程。这个过程可能会涉及到复杂的依赖关系解析，需要系统具备对进程依赖关系深入理解的能力。一旦识别出新的待处理进程，系统将把它们加入到待处理进程集中，并继续执行本步骤，直到不再有新的进程被识别出来。

步骤S14，根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。

在待处理进程集确定之后，系统将根据这些进程之间的依赖关系，制定一个安全的关闭和启动顺序。这个顺序通常是由依赖树的底部向上部进行，即从依赖关系最远的进程开始关闭，逐步向依赖关系更近的进程推进。

举例来说，如果进程C依赖于进程B，而进程B又依赖于进程A，那么在更新过程中，应该首先关闭进程C，然后是进程B，最后是进程A。在所有待处理进程都被安全关闭后，系统将按照与关闭顺序相反的顺序，即从依赖树的顶部向底部，逐步启动各进程。这样，每个进程在启动时，其依赖的进程已经可用，从而确保了系统的稳定性和业务的连续性。。

通过上述步骤，本说明书的技术方案能够实现在不重启整个嵌入式系统的前提下，对固件进行平滑、安全的升级，显著提高了系统的可靠性和维护的便捷性。

需要说明的是，在本说明书的技术方案中，执行固件更新操作与关闭待处理进程的操作，不强制具备先后关系，由于固件更新是更新存储于非易失性存储器的固件文件，而待处理进程是依赖于内存中已加载的文件运行，故固件更新不影响运行中的进程，关闭待处理进程以确保待处理进程，响应于业务需求或主动发起重启，根据更新后的固件文件运行。

以某身份卡验证设备为例，当收到厂商推送的新版固件包(目标固件文件)，系统首先执行步骤S11。管理员通过安全可靠的渠道下载该固件包至本地服务器，并通过专用工具或脚本将其解压至指定目录。随后，系统启动比对引擎，将新固件包中的用户态应用程序(如用户进程Daemon、Lib库和XML插件等)与正在使用的当前固件版本进行深度内容比对。比对内容不仅包括文件名、大小等基本信息，更深入到二进制层面，确保识别出代码、配置、资源等所有实质性的变化。

假设比对结果显示，新固件包中用户进程“Transaction”有代码更新，Lib库“CardReaderDriver”有版本升级，而XML配置文件“AccountValidationRules.xml”有规则调整。系统据此精确识别出实际更新内容：待更新用户进程“Transaction”，待更新Lib库“CardReaderDriver”，以及待更新XML配置文件“AccountValidationRules.xml”。

系统开始执行固件更新操作。按照实际更新内容，将新版本的“Transaction”交付件替换旧版本，更新“CardReaderDriver”库文件至最新版本，并替换“AccountValidationRules.xml”配置文件。在更新过程中，系统确保文件权限、链接等属性正确无误，以防止升级后出现运行问题。

系统接着进入步骤S12，利用预先构建的交付件信息矩阵，查询实际更新内容(“Transaction”、“CardReaderDriver”和“AccountValidationRules.xml”)的依赖关系。在这个例子中，发现“Transaction”进程直接依赖“CardReaderDriver”库，而“AccountValidationRules.xml”被“Transaction”和另一个名为“AccountVerification”的进程共同引用。因此，系统识别出与实际更新内容具有依赖关系的待处理进程为“Transaction”和“AccountVerification”。

接下来，系统开始执行步骤S13，递归分析待处理进程的依赖链。首先，检查“Transaction”和“AccountVerification”进程是否有其他进程依赖它们。在交付件信息矩阵中查询发现，“AccountVerification”被“BalanceInquiry”进程依赖，而“Transaction”没有额外的依赖进程。因此，系统将“BalanceInquiry”添加为新的待处理进程，并再次检查其是否存在其他依赖关系。经过一轮遍历，未发现更多与当前待处理进程相关的依赖进程，循环结束。

至此，待处理进程集合包括：“Transaction”、“AccountVerification”和“BalanceInquiry”。这些进程构成了本次固件升级影响的全部业务链，系统将依据它们之间的依赖关系，有序进行后续升级操作。

最后，系统进入步骤S14，遵循“先停依赖，后停被依赖”的原则，按照依赖树的结构，依次关闭待处理进程。首先，停止“BalanceInquiry”进程，因其直接依赖“AccountVerification”，但不依赖其他待处理进程，因此它是依赖树的最末端。接着，关闭“AccountVerification”进程，此时“Transaction”成为最后一个待处理且正在运行的进程。最后，停止“Transaction”进程。

完成固件更新后，系统按照依赖关系的逆序，重新启动各待处理进程。首先启动“Transaction”，确保其能够正确加载更新后的“CardReaderDriver”库和新的“AccountValidationRules.xml”配置。接着启动“AccountVerification”，最后启动“BalanceInquiry”。每个进程在启动时，系统都会进行健康检查，确保其成功加载更新后的资源并正常运行。

通过上述步骤S11至S14的执行，嵌入式系统在不重启CPU、保持主体业务稳定运行的前提下，成功完成了特定业务的ISSU固件升级。升级过程中，所有涉及的业务进程均被有序关闭和重启，且依赖关系得到妥善处理，确保了升级后系统的整体一致性与业务的无缝衔接。这种精细化的升级策略，显著提升了嵌入式系统的运维效率和业务连续性，为高可靠性应用场景提供了强有力的支持。

在一种实施方式中，所述根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程，包括：根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程。

在一种实施方式中，所述根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程，还包括：记录各待处理进程被关闭的顺序；根据记录的各待处理进程被关闭的顺序，以相逆的顺序依次重新启动各待处理进程。

在一种实施方式中，所述获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作，包括：若所述实际更新内容为用户态应用程序，则执行后续步骤；若所述实际更新内容为内核系统或系统基础库，则终止执行后续步骤。

在一种实施方式中，针对当前的嵌入式系统固件升级，根据系统交付件的特点，进行策略处理，在维持嵌入式CPU不重启，保留主体业务不变的前提下，完成特定业务的更新。

如图2为本实施方式中嵌入式系统(如通用的Linux系统)的层次结构，各个层次编译出的交付件对应有分类和特点，内核系统软件维护后期，基本无变更，系统基础库，无需变更，用户应用程序，包括Lib库和xml等插件，涉及用户业务，变更比较频繁。

因为用户程序的所有进程是有依赖关系的，其中一个进程重启升级，会造成依赖其的所有进程异常，因此需要在更新重启待升级进程的时候，也要考虑到其依赖关联的相关进程。

首先要理清用户业务程序的依赖关系，用树状的数据结构表示其依赖关系。如图3，业务进程之间存在依赖关系，如果业务进程E需要更新并重启，由于进程G依赖进程E，因此固件更新需要如下的步骤，更新进程E交付件，关闭进程G，关闭进程E，重启进程E，重启进程G。

即根据依赖关系，将待升级进程的交付件替换为新交付件，依赖待升级进程的所有进程需要从依赖树的末端到升级进程本身，逐个按序关闭停止进程，按照依赖关系，从近及远重启前面停止的进程，待升级进程完成了更新，依赖其的所有进程也正常恢复业务。

Lib库及XML等插件是用户进程的运行必备，其可能被多个用户进程引用，因此当其需要升级更新的时候，需要将关联进程进行重启。

如图4，如果LibA或者插件A’发生了升级更新，替换交付件后，根据依赖关系，需要重启进程A、B、C、D。根据依赖关系，更新LibA或者插件A’的交付件，依序关闭所有关联的业务进程，如进程A、B、C、D，按照依赖关系，从近及远重启前面停止的进程。

经过对进程、插件、lib等交付件的逐一定义描述，每次固件版本发布中都会携带一个版本交付件信息矩阵列表，前后两个固件版本的该矩阵列表进行对比，就能明确升级更新内容和升级策略。

在一种实施方式中，针对嵌入式系统，特别是基于通用Linux系统的固件升级过程，提出了一种兼顾业务连续性和升级效率的ISSU(In-Service Software Upgrade)策略。系统层次结构分为内核、系统调用库函数Shell以及用户程序三个层次。其中，内核系统作为软件维护后期的核心组件，其稳定性至关重要，因此在升级过程中基本无变更需求；系统基础库作为系统调用接口的固定交付件，由于其底层基础性质，通常无需进行变更。而用户应用程序，如Lib库、XML插件等，因其直接涉及用户业务逻辑，应对市场变化和业务需求调整，变更较为频繁，成为固件升级的主要关注对象。

在用户程序层面，各业务进程间存在复杂的依赖关系。进程间的依赖关系以树状结构清晰展现。当某一业务进程(如进程E)需要进行固件更新并重启时，其直接影响到依赖于该进程的其他进程(如进程G)。为确保升级过程的平稳过渡，需采取如下步骤：

更新进程E交付件：首先，将待升级进程E的最新固件版本文件替换当前运行的旧版本文件。

依依赖关系关闭相关进程：根据依赖关系树状图，从依赖关系最远端(即依赖树的末端)开始，逐个按序关闭依赖于进程E的所有进程。此处以进程G为例，先关闭进程G，再关闭进程E。

依依赖关系重启进程：关闭所有相关进程后，按照依赖关系的相反顺序，即从近及远，依次重启之前关闭的进程。首先启动进程E，确保其成功加载新固件并正常运行，然后启动依赖于进程E的进程G。至此，待升级进程E已完成更新，与其相关的所有进程亦恢复正常业务运行。

对于Lib库和XML等插件的升级，因其可能被多个用户进程共享引用，更新时需要更为谨慎。若LibA或插件A'发生升级更新，替换交付件后，需要根据依赖关系重启所有关联进程(如进程A、B、C、D)。具体步骤如下：

更新LibA或插件A'交付件：将新的LibA或插件A'文件替换旧版本。

依依赖关系关闭关联进程：按照依赖关系，从最远端开始，依次关闭所有依赖于LibA或插件A'的进程，即进程A、B、C、D，确保在更新过程中不会因旧版本资源被占用而导致问题。

依依赖关系重启进程：更新完成后，按照与关闭进程相反的依赖顺序，从最近依赖者开始，逐个重启之前关闭的进程A、B、C、D，确保所有进程能够顺利加载并运行在更新后的LibA或插件A'之上。

为了系统化地管理固件升级过程中的依赖关系和版本变更，本实施方式引入了版本交付件信息矩阵列表的概念。每当发布新固件版本时，都会生成一个详细的版本交付件信息矩阵，该矩阵记录了各交付件(包括进程、插件、Lib库等)的依赖关系和版本演进信息。通过对前后两个固件版本的矩阵列表进行对比分析，可以快速明确本次升级所需的更新内容以及相应的升级策略，指导整个升级过程的有序进行。

综上所述，本实施方式通过理清并运用用户业务程序的依赖关系，结合树状数据结构表示和管理，实现了在升级特定业务进程、Lib库或插件时，有序关闭、重启相关进程，确保升级过程中业务连续性不受影响。同时，借助版本交付件信息矩阵列表的对比，有效地规划和执行固件升级策略，提高了升级操作的精准度和效率，为嵌入式系统的ISSU固件升级提供了有力的技术支撑。

在一种实施方式中，在新的固件版本上传并解压缩后，将新旧版本的交付件信息矩阵进行扫描对比，明确更新的交付件，并确定待更新交付件关联的进程。将更新的交付件，拷贝覆盖当前版本生效的旧交付件文件。(后面进程重启就会使用生效目录的新交付件)。所有待更新的进程和依赖关联的进程进行梳理相互关系，从依赖树的边缘节点开始关闭停止进程，逐步由边缘到内部方向停止进程，直至所有涉及进程都被关闭停止。再根据依赖关系，从内及外(最外是依赖树的边缘节点)开始重启进程，直至把所有停止进程全部启动恢复。

上述实施方式，业务连续性显著增强，方案摒弃了全系统重启的传统升级模式，通过精细处理用户进程及其依赖关系，以及Lib库和相关插件的更新策略，确保了固件升级过程中主业务的不间断运行。这种业务不中断(ISSU)的升级方式极大降低了业务中断的风险，满足了金融、电信、医疗、能源等高可靠性应用场景对连续服务的严格要求，避免了因升级导致的经济损失、服务质量下降和潜在的安全隐患。

并实现了精准、有序的进程管理，方案对用户进程间的依赖关系进行了清晰梳理，并用树状数据结构进行表示，使得升级过程能够准确把握各进程间的依赖关系，确保升级操作的有序进行。当某个业务进程需要更新时，系统会根据依赖关系，先停止依赖于待升级进程的所有进程，再替换待升级进程的交付件，然后按照依赖顺序依次重启已停止的进程，确保所有依赖关系得以正确恢复，有效防止了因单一进程升级引发的连锁反应，保证了系统整体稳定。

具备智能的Lib库和插件更新策略，针对Lib库和XML等插件的升级，方案设计了专门的处理机制。当这些运行必备组件需要更新时，系统会识别所有关联的用户进程，并按照依赖关系有序地停止和重启相关进程，确保升级后的Lib或插件能够被正确加载并被所有依赖它们的进程顺利使用。这一策略确保了关键运行库的更新不会引发系统混乱，同时保证了依赖这些库的业务进程能够平滑过渡到新版本。

并含有高效的交付件信息矩阵，方案构建了交付件信息矩阵，将每个交付件的依赖关系和版本演进关系以数据结构的形式记录下来。这一创新设计使得固件升级过程能够快速识别待更新交付件及其关联进程，极大地简化了升级前的准备和升级过程中的决策，提高了升级操作的精准度和效率。通过版本交付件信息矩阵列表的对比，系统可以迅速明确升级内容和升级路径，避免了人工分析可能带来的遗漏和错误。

可实现风险可控的升级过程，方案强调在版本后期维护阶段进行ISSU升级，适用于版本更新较少且改动仅涉及依赖较少的枝叶业务进程的情况。这样可以限制升级范围，降低升级复杂度，避免大规模的进程重启，从而有效控制升级风险。此外，通过对依赖关系的精确把控，方案确保了升级过程中核心业务不受影响，符合预期的业务不中断升级目标。

从而实现客户体验提升，得益于以上技术效果，采用该方案进行固件升级就如同在运行状态下打补丁一样，用户几乎察觉不到升级过程，极大提升了客户应用的友好度。业务连续性、升级过程的智能化和精细化管理，使得系统升级如同日常运维操作一般自然流畅，减少了对用户业务的影响，增强了用户对系统的信赖感。

综上所述，该嵌入式系统ISSU固件升级方案通过创新的设计思路和技术手段，显著改善了固件升级过程中的业务连续性，实现了精准、有序的进程管理和Lib库插件更新，构建了高效的交付件信息矩阵，确保了升级过程风险可控，最终提升了客户应用体验，为嵌入式系统的高效、稳定运行提供了有力支持。

在一种实施方式中，如图5，本说明书同时提供了一种固件更新装置，应用于应用对象，所述装置包括：第一模块，用于获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作；第二模块，用于根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程，获取与待处理进程具有依赖的关系的进程，认为与待处理进程具有依赖的关系的进程为新的待处理进程，并循环执行本步骤直至不再获取到新的与待处理进程具有依赖的关系的进程；第三模块，用于根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。

在一种实施方式中，所述根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程，包括：根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程。

在一种实施方式中，所述根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程，还包括：记录各待处理进程被关闭的顺序；根据记录的各待处理进程被关闭的顺序，以相逆的顺序依次重新启动各待处理进程。

在一种实施方式中，所述获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作，包括：若所述实际更新内容为用户态应用程序，则调用第二模块执行后续步骤；若所述实际更新内容为内核系统或系统基础库，则终止调用第二模块。

装置实施方式与对应的方法实施方式相同或相似，在此不再赘述。

在一种实施方式中，本说明书提供了一种电子设备，包括处理器和可读存储介质，所述可读存储介质存储有能够被所述处理器执行的机器可执行指令，处理器执行所述机器可执行指令以实现前述的固件更新方法，从硬件层面而言，硬件架构示意图可以参见图6所示。

在一种实施方式中，本说明书提供了一种可读存储介质，所述可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现前述的固件更新方法。

这里，可读存储介质可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，可读存储介质可以是：RAM(Radom AccessMemory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。

上述实施方式阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书的实施方式可提供为方法、系统、或计算机程序产品。因此，本说明书可采用完全硬件实施方式、完全软件实施方式、或结合软件和硬件方面的实施方式的形式。而且，本说明书实施方式可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施方式的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可以由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

而且，这些计算机程序指令也可以存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或者多个流程和/或方框图一个方框或者多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或者其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本领域技术人员应明白，本说明书的实施方式可提供为方法、系统或计算机程序产品。因此，本说明书可以采用完全硬件实施方式、完全软件实施方式、或者结合软件和硬件方面的实施方式的形式。而且，本说明书可以采用在一个或者多个其中包含有计算机可用程序代码的计算机可用存储介质(可以包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本说明书的实施方式而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。

Claims (10)

1.一种固件更新方法，其特征在于，应用于应用对象，所述方法包括：

获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作；

根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程；

获取与待处理进程具有依赖的关系的进程，认为与待处理进程具有依赖的关系的进程为新的待处理进程，并循环执行本步骤直至不再获取到新的与待处理进程具有依赖的关系的进程；

根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。

2.根据权利要求1所述的方法，其特征在于，所述根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程，包括：

根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程。

3.根据权利要求2所述的方法，其特征在于，所述根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程，还包括：

记录各待处理进程被关闭的顺序；

根据记录的各待处理进程被关闭的顺序，以相逆的顺序依次重新启动各待处理进程。

4.根据权利要求1所述的方法，其特征在于，所述获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作，包括：

若所述实际更新内容为用户态应用程序，则执行后续步骤；

若所述实际更新内容为内核系统或系统基础库，则终止执行后续步骤。

5.一种固件更新装置，其特征在于，应用于应用对象，所述装置包括：

第一模块，用于获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作；

第二模块，用于根据实际更新内容，获取与实际更新内容具有依赖关系的进程，认为与实际更新内容具有依赖关系的进程为待处理进程，获取与待处理进程具有依赖的关系的进程，认为与待处理进程具有依赖的关系的进程为新的待处理进程，并循环执行本步骤直至不再获取到新的与待处理进程具有依赖的关系的进程；

第三模块，用于根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程。

6.根据权利要求5所述的装置，其特征在于，所述根据各待处理进程间存在的依赖关系，关闭各待处理进程，并重启各待处理进程，包括：

根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程。

7.根据权利要求6所述的装置，其特征在于，所述根据各待处理进程间存在的依赖关系，关闭当前不存在被依赖的待处理进程，然后循环执行本步骤，直至所有待处理进程被关闭后，重启各待处理进程，还包括：

记录各待处理进程被关闭的顺序；

根据记录的各待处理进程被关闭的顺序，以相逆的顺序依次重新启动各待处理进程。

8.根据权利要求5所述的装置，其特征在于，所述获取待更新的目标固件文件，比对使用中的当前固件文件与目标固件文件的区别，根据比对结果，获取实际更新内容，执行固件更新操作，包括：

若所述实际更新内容为用户态应用程序，则调用第二模块执行后续步骤；

若所述实际更新内容为内核系统或系统基础库，则终止调用第二模块。

9.一种电子设备，其特征在于，包括：处理器和可读存储介质，所述可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令，以实现权利要求1-4任一所述的方法。

10.一种可读存储介质，其特征在于，所述可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现权利要求1-4任一所述的方法。