Firmware upgrading method and system based on cloud computing

Abstract

The invention relates to the field of firmware upgrading, in particular to a firmware upgrading method and system based on cloud computing. The method comprises the following steps: identifying equipment firmware configuration information based on a cloud, performing module layer version information difference analysis, and generating version difference information of each module layer; performing increment updating range analysis according to the version difference information, and extracting an upgrading increment package of each module; carrying out personalized adaptation customization and firmware operation compatibility verification on the upgrade increment package, and constructing an executable upgrade task package; and carrying out adaptive decomposition and fragmented time period updating processing on the executable upgrading task package. According to the method, accurate, efficient and safe firmware increment upgrading is realized through cloud computing, and the operation stability of equipment is improved.

Description

Technical Field

[0001] This invention relates to the field of firmware upgrades, and more particularly to a firmware upgrade method and system based on cloud computing. Background Technology

[0002] With the rapid development of information technology, computer systems and intelligent devices are playing an increasingly important role in daily life and industrial applications. Firmware, as a crucial bridge between devices and hardware, directly impacts the operational efficiency and reliability of the entire system due to its stability and security. However, traditional firmware may affect device performance or even lead to system failures due to software vulnerabilities, functional defects, or security risks during operation. With the continuous increase in the types and number of devices, the need for firmware upgrades is becoming increasingly urgent, especially driven by emerging technologies such as the Internet of Things, cloud computing, and big data. How to achieve efficient, reliable, and scalable firmware upgrades has become a pressing issue that needs to be addressed.

[0003] Traditional firmware upgrade methods primarily rely on manual operation or local network pushes. The process typically includes downloading the firmware package, verifying its integrity, manual deployment, and local upgrade verification. While these methods can complete basic upgrade tasks in small-scale environments, they have significant limitations in large-scale device scenarios: firstly, the upgrade process is time-consuming and complex, easily leading to delays or failures; secondly, the dispersed nature of devices and complex network environments make unified management and monitoring of the upgrade process difficult, hindering timely detection and handling of upgrade anomalies. Furthermore, traditional methods also present security risks; for example, the firmware package may be tampered with during transmission, or the upgrade process may fail to effectively protect devices from malicious attacks, increasing system security risks. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a firmware upgrade method and system based on cloud computing, thereby resolving at least one of the aforementioned technical issues.

[0005] To achieve the above objectives, the present invention provides a firmware upgrade method based on cloud computing, comprising the following steps: Step S1: Based on the cloud-based identification of device firmware configuration information, perform module-level version information difference analysis and generate version difference information for each module level; Step S2: Analyze the incremental update range based on the version difference information and extract the upgrade incremental package for each module; Step S3: Perform personalized adaptation and firmware operation compatibility verification on the upgrade incremental package to build an executable upgrade task package; Step S4: Adaptively decompose and update the executable upgrade task package in fragmented time periods.

[0006] This specification provides a cloud-based firmware upgrade system for performing the cloud-based firmware upgrade method described above, including: The version difference identification module is used to identify device firmware configuration information based on the cloud, perform version information difference analysis at the module level, and generate version difference information for each module level. The incremental parsing module is used to parse the incremental update range based on the version difference information and extract the upgrade incremental package for each module. The compatibility verification module is used to personalize and customize the upgrade incremental package and verify firmware operation compatibility, and to build an executable upgrade task package. The fragmented update module is used to adaptively decompose executable upgrade task packages and process updates in fragmented time periods.

[0007] The beneficial effects of this invention are specifically as follows: By identifying the firmware configuration information of devices through the cloud, the firmware version and detailed information of each device's constituent modules can be accurately obtained. Version difference analysis clearly reveals the specific differences between the current device and the latest version, not just the overall firmware version, but also the differences at the module level. This provides an accurate basis for subsequent incremental updates, avoiding unnecessary full upgrades and thus improving upgrade efficiency. Module-level difference analysis allows for incremental upgrades only to the changed modules, rather than replacing the entire firmware. This significantly reduces the bandwidth and storage consumption required for firmware upgrades, especially in large-scale device environments, greatly reducing network burden and cloud storage pressure. Incremental update scope analysis accurately identifies which modules need upgrading and extracts the corresponding incremental packages. This method avoids unnecessary resource waste, improving network bandwidth utilization efficiency and reducing time costs during the upgrade process. The incremental update package contains only the differentiated content, significantly shortening transmission and installation time compared to traditional full upgrades. Devices do not need to download the entire firmware file; only the changed parts need to be updated, greatly improving upgrade efficiency, which is particularly important for large-scale device management. Different devices may have different hardware, software environments, and operating conditions, so directly applying generic firmware packages may lead to compatibility and stability issues. Through personalized adaptation and customization, the cloud can generate customized upgrade packages based on the specific environment and needs of each device. This ensures compatibility and stability during the upgrade process, reducing device malfunctions and upgrade failures caused by compatibility issues. Before building an executable upgrade package, a compatibility verification step can effectively avoid upgrade failures due to firmware version incompatibility or hardware incompatibility. This process simulates device operation in the cloud to ensure that the upgrade package can run smoothly on all target devices without causing device malfunctions, performance degradation, or security risks. Since devices may have different firmware upgrade requirements under different network environments and hardware configurations, traditional firmware upgrade methods often struggle to flexibly address these differences. Through adaptive decomposition, the upgrade package can flexibly adjust its content and upgrade method based on device operating conditions, resource availability, and network bandwidth, ensuring efficient execution of the upgrade task on different devices. By using fragmented time-segment update processing, the firmware upgrade process can be broken down into multiple small task segments, with upgrades allocated and scheduled according to demand. This avoids excessive system load caused by prolonged resource occupation during equipment upgrades. Especially for critical equipment systems that need to operate 24 hours a day, fragmented processing can complete upgrade tasks in batches without affecting business operations, thus improving the system's fault tolerance.Fragmented update processing can effectively optimize network resource utilization, avoiding large-scale firmware downloads and installations during peak network bandwidth periods, thus preventing network congestion and upgrade delays. The upgrade process can be performed in multiple time periods and intelligently scheduled based on real-time network conditions and device status. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the steps of a firmware upgrade method based on cloud computing according to the present invention; Figure 2 This is a detailed flowchart illustrating the implementation steps of step S1. Figure 3 This is a flowchart illustrating the detailed implementation steps of step S2. Detailed Implementation

[0009] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0010] This application provides a firmware upgrade method and system based on cloud computing. The execution entities of the cloud-based firmware upgrade method and system include, but are not limited to, mechanical equipment, data processing platforms, cloud server nodes, network upload devices, etc., which can be considered as general computing nodes in this application. The data processing platform includes, but is not limited to, at least one of an audio / image management system, an information management system, and a cloud data management system.

[0011] Please see Figures 1 to 3 This invention provides a firmware upgrade method based on cloud computing, comprising the following steps: Step S1: Based on the cloud-based identification of device firmware configuration information, perform module-level version information difference analysis and generate version difference information for each module level; Step S2: Analyze the incremental update range based on the version difference information and extract the upgrade incremental package for each module; Step S3: Perform personalized adaptation and firmware operation compatibility verification on the upgrade incremental package to build an executable upgrade task package; Step S4: Adaptively decompose and update the executable upgrade task package in fragmented time periods.

[0012] In the embodiments of the present invention, see Figure 1 The diagram below illustrates the steps of a cloud-based firmware upgrade method according to the present invention. In this example, the steps of the cloud-based firmware upgrade method include: Step S1: Based on the cloud-based identification of device firmware configuration information, perform module-level version information difference analysis and generate version difference information for each module level; In this embodiment, during the cloud initialization phase, the system first establishes a multi-dimensional information collection system for device firmware configuration. Through communication between the cloud and the target device, basic configuration parameters such as the device's firmware identification code, hardware platform identifier, memory configuration specifications, and storage capacity are obtained. The collection process employs a combination of RESTful interface queries and MQTT message subscriptions to ensure the real-time nature and accuracy of the configuration information. Experimental parameter settings show that the average response time for a single configuration information collection is 200 milliseconds, and data integrity reaches 99.8%.

[0013] Subsequently, the system modularly disassembled the collected firmware. Based on the firmware's business logic structure, it was decomposed into three main layers: the driver layer (including hardware drivers and low-level abstraction), the protocol layer (including communication protocols and data format processing), and the application layer (including business functions and user interaction). The disassembly process employed a binary tree structured decomposition algorithm, clearly defining the functional boundaries of each module layer. In the experimental environment, the firmware of a typical IoT device was disassembled, identifying 12 driver layer modules, 8 protocol layer modules, and 15 application layer modules, totaling 35 independent functional modules.

[0014] Next, a systematic index of version information is implemented. A metadata database containing all released firmware versions is maintained in the cloud, recording detailed information for each module in different versions, such as version number, release date, feature list, security patch tags, and performance optimizations. A storage strategy combining SQL queries and key-value pair indexes enables fast retrieval of module version data. In experimental testing, queries on a firmware library containing 500 version iterations achieved an average retrieval time of less than 50 milliseconds.

[0015] Version information difference analysis is the core of this step. The system compares each module of the device's current firmware version with the latest version on the cloud. The specific method employs a three-layer comparison framework: first, a direct comparison at the version number level to identify modules with upgraded version numbers; second, a comparison at the functional feature level, calculating the difference in the functional set using feature extraction algorithms; and third, a comparison at the interface signature level, using hash algorithms to calculate the fingerprint of the module's exported interfaces. Experimental data shows that among the 35 modules, 18 have different version numbers, of which 15 have changed functional features and 12 have changed interface signatures.

[0016] Finally, a version difference information report is generated. The system generates a difference information record for each module containing the following: module identifier, current version number, target version number, version span, feature increment list, performance optimization records, security patch list, and destructive change markers. This information is organized into a structured JSON format for easy automation in subsequent steps. In testing, the complete difference information report file for the 35 modules was approximately 2.3MB in size, containing over 5000 detailed difference description records.

[0017] Step S2: Analyze the incremental update range based on the version difference information and extract the upgrade incremental package for each module; In this embodiment, resolving the incremental update scope is the primary task. The system employs a scope resolution method based on dependency graph theory. First, a dependency graph between modules is established. Through static code analysis and symbol table scanning, the call relationships between driver layer modules, the interface dependencies between the driver layer and the protocol layer, and the functional dependencies between the protocol layer and the application layer are identified. In the experimental environment, the dependency graph constructed for 35 modules contains approximately 180 directed edges, with an average dependency degree of 5.1 per module. Second, the system combines version difference information with the dependency graph to perform propagation-based scope expansion. When a module version changes, the system automatically identifies all modules that depend on it and includes them in the potential upgrade scope. Through experimental calculations, 18 modules with version differences expanded the potential upgrade scope to 28 modules through dependency propagation.

[0018] The necessity of the upgrade was then assessed. The system categorized the 28 potential upgrade modules into three groups: "Mandatory Upgrade Modules," which include security patches, bug fixes, or critical performance improvements in version differences; "Recommended Upgrade Modules," which include feature enhancements and non-critical performance improvements; and "Optional Upgrade Modules," which include modules adding experimental features. In the experimental data, 12 of the 18 version difference modules were classified as "Mandatory Upgrades," 5 as "Recommended Upgrades," and 1 as "Optional Upgrades." Based on this classification, the system ultimately determined that the incremental update required 12 modules and recommended 17 modules.

[0019] Next, the incremental upgrade package is extracted. For each module determined to require an upgrade, the system extracts the incremental portion from the cloud firmware library, showing the difference between the current and target versions. Incremental extraction uses a binary differential algorithm (similar to BSDiff), comparing the binary code of the current and target versions byte-by-byte and extracting only the changed parts. Experimental results show that for the 12 modules that must be upgraded, the total size of the incremental package is 8.6MB, while if a full version replacement method is used, the total size will reach 35.2MB. The incremental extraction method achieves a package size compression rate of approximately 75.6%.

[0020] For each module's incremental package, the system also appends metadata information, including the source version number, target version number, incremental algorithm version, checksum, list of dependent modules, application order, rollback information, etc. This metadata is stored in the header area of ​​the incremental package, occupying approximately 2-5KB of space. Incremental packages are also associated with each other, recording the update sequence requirements between modules. In the experimental environment, the final size of the complete incremental package set (including all metadata and associated tags) stabilized at 9.2MB.

[0021] The system also performs multi-level integrity verification on the generated incremental packets. First, a CRC32 check is performed to verify the integrity of the incremental packet data transmission; second, a version number check is performed to ensure the source version matches the target version information; and third, dependency consistency verification is performed to check whether the dependent modules recorded in the incremental packet match the dependencies. Figure 1 Experimental data shows that the average time for the multi-level verification process is 320 milliseconds, with a verification success rate of 100%.

[0022] Step S3: Perform personalized adaptation and firmware operation compatibility verification on the upgrade incremental package to build an executable upgrade task package; In this embodiment, the first stage of personalized adaptation and customization is an in-depth analysis of the device's operating characteristics. The system collected operational monitoring data from the target device over the past 30 days, including the call frequency of each module, CPU usage, peak memory consumption, I / O operation modes, and fault recovery records. Fifty different models of devices were selected for testing in the experimental environment, generating approximately 50GB of data. Through time-series analysis, the system identified the typical operating modes of each device, including peak operating periods, idle periods, and scheduled maintenance periods.

[0023] Based on these operational characteristics, the system underwent parameterized customization of the upgrade incremental packages. For the driver layer module, the system adjusted the driver's initialization parameters, buffer size, and interrupt handling strategy according to the device's hardware configuration (such as memory size and processor performance). In the experiment, parameter adjustments were made for two types of devices with 512MB and 1GB of memory respectively. The buffer size of the driver layer module was adjusted from a uniform 10MB to 6MB for 512MB devices and 12MB for 1GB devices. For the protocol layer module, the system adjusted the protocol timeout parameters, retransmission strategy, and connection pool size according to the device's network environment (such as signal strength and latency characteristics). For the application layer module, the system adjusted the function activation status, default parameter configuration, and resource contention strategy according to the user's historical behavior preferences.

[0024] The second phase of personalized customization is the pre-verification of functional compatibility. The system employs virtual simulation to establish a digital twin model for each device in the cloud. This model includes information such as the device's hardware configuration, firmware configuration, and historical operational data. Subsequently, the system simulates the execution of customized upgrade incremental packages in the digital twin environment, observing the behavior during the upgrade process. In the experiment, virtual upgrades were performed on the digital twins of 50 devices, detecting three potential compatibility issues: one issue was incompatibility between the new version's protocol layer module and the old version's application layer module interfaces; and two issues were incomplete adaptation of the new version's driver to specific hardware configurations.

[0025] In response to the detected compatibility issues, the system made corresponding adjustments. For interface incompatibility issues, a compatibility adaptation layer was introduced to facilitate interface conversion between the old and new modules. For hardware compatibility issues, the system adjusted the driver initialization sequence and register configuration parameters. The adjusted customized upgrade package underwent a virtual upgrade, and all 50 digital twin devices passed verification.

[0026] The stability verification phase employed a long-term runtime testing method. The system ran a 36-hour continuous load simulation in the digital twin of each device, simulating various scenarios including normal business operations, peak load scenarios, and boundary condition triggers. In the experiment, 50 devices ran for a total of 1800 hours after the virtual upgrade without any abnormal crashes or functional failures. Furthermore, the system's key performance indicators before and after the upgrade were compared and analyzed, including response time, throughput, memory usage, and CPU usage. Experimental data showed that the average response time improved from 245ms before the upgrade to 198ms after the upgrade, representing a performance improvement of approximately 19.2%.

[0027] The final stage of compatibility verification is a step-by-step check of functional integrity. Based on the functional list of each module, the system verifies the complete implementation of all functions in the new version module. For the 12 modules that must be upgraded, the system designed a total of 385 functional test cases. These test cases were executed in a virtual environment, achieving a 100% pass rate. The system also performed end-to-end verification of the integration functions between modules, including checks on the correctness of data flow and control flow between cross-layer modules.

[0028] After completing all verifications, the system generates a personalized, executable upgrade task package for each device. This task package not only includes the optimized incremental package but also complete information such as the execution plan, parameter configuration, verification checklist, and contingency plan for that device. The total size of the task package averages 9.8MB (an increase of 0.6MB in customized information compared to the original incremental package's 9.2MB).

[0029] Step S4: Adaptively decompose and update the executable upgrade task package in fragmented time periods.

[0030] In this embodiment, the first step of adaptive decomposition is an in-depth analysis of the device load curve. The system collected load data from the target device over the past 7 days, recording indicators such as CPU utilization, memory usage, and I / O operation frequency at a granularity of 1 minute. Based on this data, the system used the Hodrick-Prescott filtering algorithm to separate the trend component, periodic component, and random component of the load. Experimental data shows that among 50 test devices, there are an average of 8-12 distinct low-load periods within a 24-hour cycle, with each period lasting between 30 and 120 minutes.

[0031] Based on the load curve, the system identified available idle windows for each device. The criteria for defining an idle window are: a continuous period of time during which CPU utilization is below 20%, memory utilization is below 40%, and I / O operation frequency is below 10 ops / s. Based on this criterion, the system identified an average of 10.2 available idle windows over a typical 24-hour period across 50 devices, with a total available idle time of 328 minutes. The longest continuous idle window was 145 minutes, and the shortest was 28 minutes.

[0032] The task decomposition strategy employs dynamic programming. The system treats the 12 module upgrade operations in the executable upgrade task package as a task sequence, which needs to be allocated within the available free window set. Considering the dependency constraints between modules, the system uses a constraint satisfaction problem-solving framework to calculate the optimal task allocation scheme. In the experiment, for a complete task package of 9.8MB, the system adaptively decomposes it into 48 microtasks, each with an average size of 204KB. These microtasks are allocated to 10 free windows, making full use of available idle time while avoiding dependency conflicts.

[0033] Each decomposed microtask carries detailed execution constraints, including: mandatory prerequisite tasks, a list of conflicts that cannot be executed concurrently with other tasks, expected execution time, required computational resources, and reliability requirements. Experimental data shows that the accuracy of microtask execution time prediction reaches 94.3%, with an average error of 3-8 seconds.

[0034] The progressive updates across fragmented time periods employ a phased submission approach. The system divides microtasks into multiple phases (typically multiple phases within a single day) according to chronological order, with the total number of microtasks within each phase not exceeding 70% of the available idle time for that phase, to preserve buffer space. In the experiment, 48 microtasks were divided into 6 execution phases: Phase 1 contained 8 microtasks, and Phases 2-6 each contained 8 microtasks. The total size of the tasks in each phase ranged from 1.6MB to 2.0MB.

[0035] During execution, the system adopted a transactional execution model. Each microtask's execution process comprises four phases: commit phase (sending the task to the device), execution phase (the device performs the update operation), verification phase (verifying the success of the update), and confirmation phase (recording the execution result). If any phase fails, the system automatically triggers a rollback mechanism. In the experiment, the overall success rate of the 48 microtasks was 99.8%, with only one microtask failing on its first execution but successfully completing after retrying.

[0036] The merging of microtasks is the final and crucial step in this process. The system employs an incremental merging strategy, caching the results of each successfully executed microtask. Once all microtasks have been completed, the system merges these scattered, incremental update results to generate the final, complete new firmware version. In the experiment, from the execution of the first microtask in Phase 1 to the completion of the last microtask in Phase 6, the entire time-sharing update process spanned 5 days and 6 hours. The final merging verification showed that the upgrade effect executed through time-sharing decomposition was completely consistent with that of a single complete upgrade; all 50 test devices were successfully upgraded to the target version without any functional defects or performance regressions.

[0037] Throughout the entire process, the system maintained business continuity for the devices. During the execution of 48 micro-tasks, the total business interruption time was less than 5 minutes, achieving over 90% improvement in business continuity compared to the traditional "downtime update" method (which typically takes 30-60 minutes). The system also provides users with a visual upgrade progress tracking interface, displaying information such as the current upgrade stage, the number of completed micro-tasks, and the estimated completion time. The experimental user satisfaction rating reached 8.7 / 10.

[0038] In this embodiment, see Figure 2 The diagram below illustrates the detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include: Based on cloud-based identification of device firmware configuration information; The device firmware configuration information is functionally modularized and the version information of different module layers of the firmware is extracted. The firmware includes different module layers such as the driver layer, protocol layer, and application layer; it identifies the latest firmware version information database in the cloud. Based on the latest firmware version information database in the cloud, the version information is analyzed for differences at each module level to generate version difference information for each module level.

[0039] In this embodiment, after connecting to the network, the device proactively sends a firmware configuration data packet to the cloud management system. This data includes key parameters such as device model, serial number, firmware version, hardware identifier, driver information, and protocol identifier. Upon receiving the data, the cloud first performs authentication and data integrity verification via an encrypted channel (e.g., HTTPS or MQTT communication based on TLS 1.3). After successful authentication, the cloud invokes the configuration parsing module to perform structured parsing of the uploaded data. This module employs a configuration template matching mechanism, using predefined configuration feature templates to perform layered identification of key fields in the firmware file, and utilizes hash verification algorithms (SHA256 or MD5) to ensure the uniqueness and authenticity of the data file. The parsed information is converted into a unified format (e.g., JSON or XML) and stored in the firmware configuration database, forming a standardized firmware configuration information structure. This process improves identification efficiency through multi-threaded concurrent processing, ensuring that the device can complete configuration identification and cloud registration upon going online, providing reliable input data for subsequent modular disassembly and version analysis. After cloud identification is completed, the firmware configuration file is modularly disassembled to extract version information for modules such as the driver layer, protocol layer, and application layer. The disassembly process is based on logical segmentation analysis of the firmware's binary image file and its associated symbol mapping table. First, module boundaries are identified using memory offset address ranges and function naming characteristics. For example, the driver layer often contains low-level hardware interface functions, the protocol layer contains communication protocol stacks and data encapsulation logic, and the application layer contains business logic and user interaction interfaces. The cloud-based disassembly engine executes a module partitioning algorithm based on these characteristics, scanning the header area of ​​each module to extract version number, module identifier, compilation timestamp, and checksum information. To ensure data accuracy, an independent hash signature (such as CRC32 or SHA1) is generated for each module and compared with the standard module signature stored in the database. After disassembly, a module-level version information table is formed, which records in detail the name, version number, dependencies, and integrity status of each module. This structured information provides a clear data hierarchy for subsequent version comparison and upgrade judgment, transforming the firmware's logical structure from a general configuration into independently analyzable functional units.

[0040] The latest firmware version information database corresponding to the device type is obtained from the cloud-based firmware management platform to establish a comparison benchmark. The cloud-based version information database adopts a distributed database architecture design, internally recording metadata such as firmware module version, release time, feature update description, and security signature for each device model. During the firmware upgrade detection phase, matching version records are automatically retrieved based on the device's uploaded model identifier and serial number. The retrieval process is implemented through an index query mechanism, using a primary key index (device model) and a secondary index (module type) to quickly locate the corresponding latest module information. The cloud also simultaneously checks the firmware version dependency table to determine whether there are strong dependencies or compatibility restrictions between modules. For example, some protocol layer versions may only be compatible with specific driver layer versions; dependency matching rules ensure the reasonableness of the comparison results. All version records are digitally signed and timestamped when written, ensuring that the version metadata cannot be tampered with during transmission and storage. After identification, the cloud maps this latest version information database to the corresponding firmware version structure of the device, providing an authoritative benchmark for subsequent version difference analysis.

[0041] The module-level version information uploaded by the device is compared one-to-one with the latest version in the cloud repository to generate a detailed version difference report. The difference analysis employs a module-level semantic version comparison algorithm, comparing the major version, minor version, and revision number fields in the version number to determine if a module has undergone functional updates or security patches. Simultaneously, the module signature hash value is compared to confirm the integrity differences in the firmware file. If the version number is the same but the signature is different, it indicates that the module may have been recompiled or internally modified. To further improve the accuracy of the analysis, the cloud reads the corresponding module's update documentation, comparing updates such as interface changes, vulnerability fixes, and performance optimizations to generate a module change summary at the functional level. The analysis results are output in structured data format, with one difference record for each module, including the old version number, new version number, difference category, description of functional changes, and upgrade necessity level. If any module version lags behind the cloud record, it is marked as "upgradeable," and this difference information is passed to the subsequent firmware upgrade decision module. This process ensures that firmware upgrades are targeted and secure, achieving precise version control at the module level.

[0042] In this embodiment, see Figure 3 The diagram below illustrates the detailed implementation steps of step S2. In this embodiment, the detailed implementation steps of step S2 include: Based on the version difference information, the incremental update range is parsed to generate an incremental update boundary list; Perform inter-module dependency analysis on the module layer to extract the inter-module dependencies; Dependency conflict analysis is performed on the incremental update boundary list based on the inter-module dependencies to obtain the dependency conflict results. Conflict optimization is performed based on the dependency conflict results, and feasibility is verified to obtain the scope of incremental update optimization. The incremental update optimization scope is analyzed module by module to extract the upgrade incremental package for each module.

[0043] In this embodiment, the version number, signature hash value, and function change records of each module are compared to identify the differences. For each module with differences, the modified logical segments or code intervals in the binary file are extracted. To achieve precise location, the parsing engine calculates the byte-level differences between the old and new firmware files based on the Binary Diff Algorithm. During the difference calculation process, sliding window technology and hash matching mechanism are used to determine the start and end positions of changes in code segments, resource files, and configuration areas, thereby defining the update boundaries. The generated boundary information includes not only file offset addresses but also module identifiers, difference types, data lengths, and dependency tags. The cloud summarizes the difference ranges of all modules to form an incremental update boundary list, which is stored in structured data format for easy subsequent dependency analysis and conflict detection. In this way, firmware updates can achieve efficient incremental upgrades while minimizing data transfer volume, providing a precise update range basis for subsequent dependency optimization and incremental package extraction. Further, the dependency relationships between the firmware modules are parsed. The core of dependency analysis is to identify the call relationships, resource sharing, and function interlocking between modules, thereby establishing a complete module dependency graph. During the analysis, the cloud-based parser first reads the metadata descriptor file of each module. This file records the module's import function table, export function table, and interface dependency information with other modules. By parsing these symbol table contents, a module call matrix is ​​constructed to express the strength and direction of dependencies between modules in matrix form. Subsequently, a dependency graph is generated using a directed graph algorithm (DGraph Dependency Analysis) to perform topological sorting of the dependency paths between modules, thereby identifying critical dependency chains and potential circular dependencies.

[0044] Dependency extraction encompasses not only logical interface dependencies but also data structure, configuration parameter, and protocol version dependencies. For example, certain function interfaces at the protocol layer may depend on hardware abstraction functions provided by the driver layer, and some logic at the application layer may depend on a specific protocol stack version. A dual mechanism of static analysis and symbol matching ensures the completeness and accuracy of dependency information. Ultimately, a dependency list between modules is generated, recording the module name, dependency target, dependency type, constraints, and version compatibility identifier, providing foundational data for subsequent conflict detection and update optimization.

[0045] Ensure that incremental updates to each module do not disrupt existing dependency stability. Perform joint analysis based on the dependency list extracted in the previous step and the incremental update boundary list to detect issues such as version mismatches, missing interfaces, or functional incompatibility between the updating module and its dependent modules. During the analysis, a DependencyConsistency Verification Model is used to compare the interface definitions and calling constraints between modules.

[0046] The specific implementation is as follows: First, all modules that need to be updated are marked as "change nodes." Then, all modules that depend on this node are traced upwards along the dependency graph to check whether the version numbers and definitions of their dependent interfaces are still valid. Simultaneously, the lower-level modules that this module depends on are traced downwards to verify whether their required resources and interfaces are still supported in the new version. If version number conflicts, interface changes, or data structure mismatches are found, dependency conflict records are automatically generated. Conflict results include conflicting module pairs, conflict types (such as interface incompatibility, version dependency errors, configuration conflicts), and the level of impact. All conflict information is summarized to form a dependency conflict result set, with priority and severity indicated to guide subsequent conflict optimization and incremental update adjustments, thereby ensuring the consistency and reliability of update operations.

[0047] Once dependency conflicts are generated, the conflict optimization phase begins, resolving dependency contradictions through logical adjustments or strategy modifications. The optimization process first categorizes conflicts by type: for interface incompatibility conflicts, a transitional interface or compatibility layer code is generated by calling a compatible adaptation module to maintain normal communication between modules; for version dependency conflicts, depending on the dependency chain, related modules are either updated synchronously or reverted to a compatible version; for configuration conflicts, parameter merging and priority adjustment strategies are used for correction. After conflict optimization is complete, a feasibility verification process is initiated, using simulated loading and dependency verification mechanisms to check the feasibility of the modified dependency structure.

[0048] The verification phase employs a static simulation loading method, simulating the loading order and call paths of modules during runtime. Interface dependencies for each module are reconstructed and verified, and a consistency check algorithm ensures that all modules can achieve interoperability after optimization. If the verification passes, an optimized incremental update scope is generated, eliminating conflicting modules or adjusting their update order to optimize the update path and stabilize dependencies. This optimized incremental update scope will serve as the final basis for the actual upgrade execution, ensuring that the firmware upgrade covers differences without disrupting the dependency structure.

[0049] Based on the optimized module update scope, an independent upgrade incremental package is generated for each module. The cloud-based incremental parsing engine performs differential calculations on the old and new binary files of each module to be updated, using a block-based differential algorithm to extract the changed data. According to the previously defined update boundaries, the differing parts are segmented, and metadata descriptions are generated for each segment, including data offset, compression ratio, target write address, and verification information.

[0050] To ensure reliable transmission and updates, incremental packets undergo compression and encryption. The compression algorithm can be LZ4 or Zstd to balance data size and decompression speed; encryption uses AES-256 symmetric encryption to ensure transmission security. After generation, each incremental packet is appended with a digital signature and integrity checksum for device verification. Each module's incremental packet is independently stored in a cloud update repository and pushed to the device sequentially during the upgrade scheduling phase. This mechanism enables precise module-level incremental updates, effectively reducing bandwidth consumption, improving upgrade efficiency, and ensuring the security and controllability of the firmware upgrade process.

[0051] In this embodiment, step S3 includes the following steps: Acquire firmware operation monitoring records from the device; perform multi-dimensional operation trajectory tracking on the firmware operation monitoring records and extract the multi-dimensional operation trajectory; The multi-dimensional operation trajectory includes module loading time, function call frequency, resource consumption hotspots, and fault recovery logs. Deeply mine the operational patterns of multi-dimensional operational trajectories to generate firmware operational pattern evolution characteristics; Based on the firmware operation monitoring records, user preferences, operation time distribution, and function call patterns are identified to establish user behavior profiles. Based on user behavior profiles and firmware operation pattern evolution characteristics, the upgrade incremental package is personalized and customized to generate an adaptive incremental package; Firmware compatibility verification is performed on the adaptive incremental package, and an executable upgrade task package is built.

[0052] In this embodiment, the firmware operation process of the device is continuously monitored and recorded. A monitoring module embedded within the firmware captures real-time operational status information, including multi-dimensional data such as CPU utilization, memory usage, I / O response time, task scheduling latency, module loading order, function call logs, and abnormal event records. The monitoring module employs an event-driven monitoring framework, using hook functions and call interception to collect data, ensuring minimal impact on firmware performance during recording. The collected monitoring data is periodically cached in a local circular buffer and uploaded to a cloud-based monitoring data center via lightweight communication protocols (such as MQTT or CoAP). The cloud platform uses a time-series database (such as InfluxDB or TimescaleDB) to store and index the operational records, supporting rapid queries based on time windows, module identifiers, and event types. Monitoring records also include a unique device identifier, firmware version number, and operational cycle number, ensuring data traceability. This process provides high-precision foundational data support for subsequent operational trajectory extraction and behavior modeling.

[0053] The time-series features and behavioral patterns of the equipment operation process are extracted from the raw monitoring records. The cloud-based data analysis engine first standardizes and denoises the collected monitoring logs, removing outliers and invalid data. Then, a time alignment algorithm is used to synchronize the operation logs from different modules according to a unified time baseline to construct a complete operation timeline.

[0054] Based on this, four key operational trajectory information categories are extracted from the data: module loading time, function call frequency, resource consumption hotspots, and fault recovery logs. The module loading time trajectory is obtained by calculating the start and end time difference of each module's initialization, used to analyze startup efficiency; the function call frequency trajectory is generated by statistically analyzing the number of calls and time intervals, used to measure module activity; resource consumption hotspots are formed by aggregating CPU and memory usage to create a multidimensional heat map distribution; and the fault recovery log records the fault triggering, automatic recovery, and stabilization times, used for stability assessment. The multidimensional operational trajectories are ultimately stored in multidimensional vector form, with each dimension corresponding to an operational dimension indicator, forming a high-dimensional operational trajectory dataset, providing computable behavioral samples for subsequent pattern mining.

[0055] By deeply analyzing multi-dimensional operational trajectories, the regular characteristics and evolutionary trends of firmware during long-term operation are extracted. In the cloud, a combination of deep learning and time-series analysis is used to model and extract features from the trajectory data. First, clustering analysis algorithms (such as K-Means or DBSCAN) are used to aggregate and classify the operational trajectories to identify different operational state modes, such as "high-load operation state," "stable low-power state," and "frequent reboot state." Then, time-series modeling algorithms (such as LSTM or ARIMA models) are used to predict and extract patterns in the evolutionary trend of each mode, analyzing the characteristics of firmware performance changes and abnormal fluctuations over time.

[0056] Furthermore, feature reduction (Principal Component Analysis) was performed on the trajectory data to extract principal components representing the core operational characteristics of the firmware, such as the average response latency change rate, peak call density distribution, and resource utilization cycle volatility. The generated firmware operational evolution features are stored in the form of numerical vectors and labels, describing the performance evolution trends and stability characteristics of the firmware under different versions and different operating cycles. This result provides data support for intelligent upgrade strategies, enabling subsequent incremental package optimization to be customized based on the actual operational characteristics of the firmware.

[0057] Further analysis of user operation habits and usage preferences from operational monitoring records is used to construct user behavior profiles. The cloud-based behavior recognition module first analyzes user behavior characteristics during device interaction based on call logs and operation event records, including data such as function call frequency distribution, function combination usage patterns, operation time periods, and continuous operation duration. Through statistical analysis and pattern recognition technology, user behavior is transformed into quantitative indicators, such as "percentage of high-frequency operation modules," "percentage of nighttime usage," and "function combination call sequence." Subsequently, clustering algorithms are used to group the behavioral patterns of different users, forming behavioral feature templates.

[0058] User behavior profiles encompass not only basic operational dimensions but also device usage environment information (such as location and network connection stability) and preference characteristics (such as feature usage tendencies and update acceptance frequency). Profile data is stored in vectorized form, with each dimension representing a user's characteristic value on a specific behavioral indicator. This process creates a mapping between users and device operating states in the cloud, providing a basis for personalized upgrade strategies. The establishment of user behavior profiles enables firmware upgrades to be precisely matched to user habits and usage patterns, achieving differentiated feature optimizations and update pushes.

[0059] The user profile vectors are matched with firmware operation patterns, and the content of incremental packages is selectively adjusted based on user function usage preferences, operational intensity, and operating environment. For example, for users who frequently use specific functional modules, optimization patches and performance improvement code for those modules are prioritized in the incremental package; for resource-constrained devices, a lightweight version is adopted to reduce the amount of updates to non-critical modules.

[0060] The customization process is based on an adaptive incremental update algorithm, comprehensively considering the size of the difference package, module dependencies, and user scenario adaptability to generate the optimal update combination scheme. Simultaneously, the incremental package undergoes content trimming, data rearrangement, and difference compression to ensure that while meeting personalized needs, transmission bandwidth and installation latency are controlled. The generated adaptive incremental package includes detailed module update instructions, dependency verification information, and version indexes for efficient execution on the device side. Through this mechanism, firmware updates are no longer pushed uniformly but are dynamically customized based on user and device characteristics, achieving an intelligent and precise firmware upgrade method.

[0061] Firmware compatibility verification is performed to ensure stable integration of the updated content with the existing environment. The cloud-based verification module simulates the loading and execution of the incremental package using a virtual firmware sandbox, reproducing the device's operational logic. Verification includes module interface compatibility, dependency integrity, memory allocation conflict detection, and anomaly recovery capability analysis. An interface consistency checking algorithm is used to verify whether the calling protocols between the old and new modules remain consistent, and dynamic linking tests ensure that the updated function interfaces in the incremental package can be correctly parsed and loaded.

[0062] In addition, compatibility verification includes performance impact assessment, which quantitatively compares key indicators such as module initialization time, memory consumption, and response latency to ensure no significant performance degradation after the update. After successful verification, the incremental package is packaged into a complete executable upgrade task package, including the execution script, rollback strategy, and security signature information. This task package is stored in a standard format in the cloud task scheduling center and automatically pushed and executed during idle periods on the device. Through this verification and packaging process, the upgrade task package possesses high reliability and controllability, ensuring stable, secure, and consistent firmware operation after the update.

[0063] In this embodiment, step S4 includes the following steps: Based on the firmware operation monitoring records, the load distribution within the period is predicted, and a load distribution time axis is generated. Firmware load idle analysis is performed based on the load distribution time axis, and global idle computing resource information is calculated. Based on global idle computing resource information, the executable upgrade task package is adaptively decomposed to generate multiple minimized upgrade task packages; Perform task dependency logic analysis on multiple minimal upgrade task packages, and perform priority serialization processing to generate a task package sequence; Updates are performed in fragmented time periods based on task package sequences and stored locally, while aggregating global update packages. Perform a firmware upgrade based on the global update package.

[0064] In this embodiment, it is necessary to predict and analyze the periodic characteristics of the device's operating load to determine the appropriate upgrade execution time period. A load time series model is constructed using indicators such as CPU utilization, memory usage, I / O operation frequency, communication bandwidth utilization, and task scheduling queue length collected from firmware operation monitoring records. The cloud-based load prediction module employs a hybrid modeling method based on time series analysis and machine learning, inputting the monitoring data into a regression prediction model (such as an LSTM time series network or an ARIMA prediction model) to predict the load change trend within future operating cycles.

[0065] During model training, the data undergoes sliding window segmentation and feature normalization to ensure the prediction results are highly adaptable to periodic fluctuations and sudden load spikes. The prediction output consists of load estimates for each time period, combined with confidence intervals to determine stable load intervals. The prediction results are then transformed into a visualized load distribution timeline, with time on the horizontal axis and overall load on the vertical axis, marking high-load, low-load, and idle intervals. This load distribution timeline serves as a crucial reference for subsequent upgrade task scheduling, identifying the optimal upgrade execution window and minimizing the impact of firmware updates on device operations.

[0066] The computing device's globally available computing resources across different time periods are analyzed. The analysis module first reads the load timeline data, extracts the time segments corresponding to low load and idle periods, and performs resource mapping by combining this with hardware resource usage information (CPU core utilization, available memory capacity, I / O throughput, and cache utilization) from monitoring records. By calculating the inverse function of resource utilization, the amount of available computing resources in different time periods can be obtained.

[0067] The cloud-based resource analysis module further calculates global idle computing resource information based on a multi-dimensional resource aggregation algorithm, quantifying the results into a resource index. This index reflects the comprehensive capacity available for executing upgrade tasks. During the analysis, the competitive impact of task execution on resources is considered, and the allocation weights of communication bandwidth, data caching, and task threads are dynamically adjusted to obtain more accurate estimates of available resources. The final generated global idle computing resource information includes a resource time distribution table, a computing load threshold table, and resource availability curves, which guide the dynamic decomposition and scheduling of upgrade tasks, ensuring that upgrade tasks are executed efficiently and safely during idle periods.

[0068] The executable firmware upgrade task package is adaptively decomposed to generate multiple minimal upgrade task packages, enabling parallel and fragmented execution of tasks. The adaptive decomposition engine first parses the module structure, dependencies, and data size information within the executable upgrade task package, dividing the package into several logical units, such as driver update units, protocol update units, and application patch units. Subsequently, the granularity of task division is dynamically adjusted based on the available resource index and the task package complexity parameter.

[0069] The partitioning process employs an Adaptive Task Decomposition Algorithm, which decomposes tasks into layers by calculating task execution overhead, data transfer volume, and CPU time allocation ratios. Each minimal upgrade task package contains independent data blocks, verification information, and execution instructions, and can be executed independently without depending on other task modules. After decomposition, each task package is assigned an execution identifier and resource tag to ensure that the execution order can be flexibly selected based on resource status during subsequent scheduling. This process optimizes task granularity, enabling the upgrade process to automatically adapt and adjust according to real-time resource conditions, improving cloud scheduling efficiency and device-side execution flexibility, and providing structured support for fragmented execution.

[0070] The logical relationships and execution order between tasks are analyzed and optimized to form a serializable execution plan. The dependency logic analysis module constructs a task dependency graph by parsing the dependency metadata within the task package, where nodes represent task packages and edges represent the dependency directions between tasks. A topological sorting algorithm is used to traverse and analyze the dependency graph, identifying tasks that can be executed in parallel and those that must be executed sequentially.

[0071] Building upon this foundation, a Priority Evaluation Model is introduced to calculate priority scores based on task importance, data size, dependency depth, and resource consumption. High-priority tasks typically involve updating underlying drivers or critical protocol modules, while low-priority tasks are for user interfaces or non-core functional modules. All task packages are arranged according to priority and dependency order, forming a task package sequence. Each task package in the sequence includes execution conditions, resource requirements, and rollback policy identifiers. This priority serialization process ensures that tasks satisfy logical correctness during execution while fully utilizing resources, achieving optimal task scheduling timing and minimizing risk, and providing a clear execution path for updates in fragmented time periods.

[0072] Fragmented time-segment updates are performed based on idle periods in the load timeline. The scheduling module monitors the device's operating status and automatically initiates the update operation of the corresponding task package when a low-load period is detected. Each update involves a small amount of data and lasts for a short time, ensuring that real-time business processing is not affected. The update process employs breakpoint resumption and differential writing technologies to ensure that updates can resume from the last execution position after a task is interrupted, improving stability.

[0073] The results of completed task packages are temporarily stored in the device's local storage area, along with verification information and execution logs. After all task packages have been completed, the update fragments in local storage are aggregated and reassembled to generate a complete global update package. The aggregation process uses data splicing and hash verification mechanisms to ensure the integrity and accuracy of the update data. This fragmented execution and aggregation mechanism effectively utilizes idle time slices to achieve gradual firmware updates, avoiding blockages or failures caused by large-scale one-time writes, thus achieving a highly reliable and low-impact intelligent firmware upgrade mode.

[0074] After all fragmented update tasks are completed and a global update package is generated, the formal firmware upgrade phase begins. The upgrade execution module first performs an integrity check on the global update package, verifying that the data has not been tampered with through hash comparison and digital signature verification. Then, the upgrade loading process begins, writing the update package into the firmware image area according to the module loading order, employing a secure overwrite strategy to prevent critical areas from being incorrectly overwritten.

[0075] During the upgrade process, the execution status of each module is monitored in real time, and rollback points are set. When a write anomaly or verification failure is detected, the system can immediately roll back to the previous version to ensure stability. After the upgrade is complete, a secondary verification is performed to compare the target version number with the expected version number. The device is then restarted to enter verification mode to confirm that the upgraded firmware is functioning correctly.

[0076] The entire upgrade process is executed under the full monitoring of the cloud-based scheduling center. Upgrade results and logs are synchronously transmitted back to the cloud platform to update the device status database. This step achieves a complete closed loop from load prediction to dynamic decomposition, and finally to integration and upgrade execution, making the firmware upgrade process adaptive, reliable, and secure, providing technical support for cloud-based intelligent firmware management.

[0077] In this embodiment, the specific steps for predicting the load distribution within a period based on the firmware operation monitoring records and generating a load distribution time axis are as follows: Based on the firmware operation monitoring records, the device's CPU utilization, memory usage, I / O operation frequency, and network bandwidth usage are calculated to generate real-time load characteristics; Based on the real-time load characteristics, a discrete fitting of time-series changes is performed to generate a time-series load change curve; Extract the task processing list based on the firmware operation monitoring records; The processing volume of the task processing list is analyzed, and the priority distribution is identified to generate features of incomplete tasks. Estimate the resource usage of incomplete tasks based on their characteristics, and generate the resource usage for task processing. Based on the resource consumption and time-series load change curve of task processing, the load distribution within the period is predicted, and a load distribution time axis is generated.

[0078] In this embodiment, real-time load analysis is performed on the current operating status of the device to determine the available resources for upgrade execution. A monitoring module embedded in the firmware continuously collects data on metrics such as CPU utilization, memory usage, I / O operation frequency, and network bandwidth usage. CPU utilization is calculated by recording the ratio of active to idle cycles for each processing core per unit time; memory usage is obtained by reading the ratio of allocated memory to total available memory from the operating memory manager; I / O operation frequency is calculated by statistically analyzing the number of storage and peripheral accesses and the operation interval; and network bandwidth usage is obtained by collecting the number of data packets sent and received and calculating the throughput per unit time. The cloud-based load analysis engine summarizes, normalizes, and updates these metrics in real time, forming a multi-dimensional load feature vector to describe the overall operating pressure of the device at a specific moment. Load features are snapshotted at fixed time intervals (e.g., every 5 seconds or every 10 seconds) as input data for subsequent time-series analysis and load prediction. Through high-frequency sampling and data integration, the resource usage of the device during operation can be dynamically reflected, providing real-time reference for intelligent scheduling and upgrade strategies. The discrete loading process involves arranging continuously collected load feature vectors in chronological order to form a multidimensional time series. Then, discrete loading algorithms (such as piecewise linear fitting, spline interpolation, or polynomial fitting) are used to model each resource indicator, generating a smooth time-series load change curve. CPU, memory, I / O, and network bandwidth indicators are modeled separately and can be weighted and fused to generate a comprehensive load curve, describing the overall load trend of the device over various time periods. The loading process also calculates the fluctuation amplitude and standard deviation for each time period to identify periodic peaks, troughs, and short-term load bursts. The generated time-series load change curve not only provides a visual reference but also labels each load level on a time axis, providing a basis for subsequent task scheduling, idle time identification, and determination of upgrade task execution windows. This curve dynamically reflects the gradual trend and short-term fluctuation characteristics of the load, achieving accurate modeling of load behavior within a period.

[0079] To perform upgrade load scheduling, a list of tasks currently being processed by the device needs to be extracted from monitoring records. The task processing list extraction module identifies the unique identifier, task type, execution priority, resource requirements, and status information of all active and pending tasks by parsing firmware operation logs and task scheduler information. Each task includes CPU cycle requirements, memory usage, I / O operation volume, and dependent external modules or data resources. Using event timestamps and task scheduling queue information, the task list is initially sorted by creation order and priority, and task execution status is appended, such as "executing," "waiting," or "blocked." The task processing list extraction process employs a streaming processing mechanism, enabling continuous parsing of real-time monitoring logs to ensure the capture of the latest task information in a dynamic environment. The list data structure is uniformly formatted, supporting subsequent task volume analysis, resource usage calculation, and periodic load prediction analysis.

[0080] Each task undergoes processing volume analysis and priority distribution identification to generate incomplete task characteristics. Processing volume analysis quantifies the resource consumption of each task by calculating its remaining CPU time, memory usage, I / O operations, and network communication load. Priority distribution identification categorizes tasks based on their assigned priorities, dependencies, and urgency levels, and dynamically assesses their importance by combining historical execution time and resource usage patterns. By integrating processing volume and priority information, an incomplete task characteristic table is generated, including task ID, resource requirement vector, priority level, estimated execution time, and dependencies on other tasks. This characteristic table accurately describes the potential impact of incomplete tasks on the load in future execution cycles, providing a quantitative basis for load prediction and escalation of task scheduling.

[0081] After identifying the characteristics of incomplete tasks, the resource consumption of each task is quantitatively estimated, forming resource consumption information for task processing. The resource consumption estimation module maps CPU cycles, memory usage, I / O frequency, and network bandwidth requirements from the incomplete task characteristic table to device resource capacity indicators, calculating the resource consumption ratio of each task at different time periods. During the estimation process, task parallelism and resource conflicts are considered, and the consumption of each task is adjusted through a multi-dimensional resource constraint model to avoid resource overload or bottlenecks. The final generated task processing resource consumption table includes the distribution of resource requirements over time, which can be used for load distribution prediction and idle time slice identification in subsequent periods. Through accurate estimation, the pressure of incomplete tasks on the overall device resources can be quantified, providing reliable data support for intelligent upgrade scheduling.

[0082] After obtaining the resource consumption data for task processing, it is combined with the time-series load change curve generated in the previous step to predict the device load in future periods. The prediction module uses a fusion modeling method, inputting historical load curves, real-time resource consumption data, and task priority distribution into a time-series prediction model (such as an LSTM or ARIMA+weighted regression hybrid model) to generate load change trends in future periods. The model output is a load distribution time axis, indicating the time periods and resource capacity levels of high load, low load, and idle periods. During the prediction process, task execution priorities and resource consumption are dynamically adjusted to ensure that the load time axis reflects the comprehensive pressure under different task load combinations. The generated load distribution time axis provides a basis for firmware upgrade scheduling, task package decomposition, and fragmented execution, realizing periodic load optimization and safe scheduling of upgrade tasks.

[0083] In this embodiment, the specific steps for performing firmware load idle analysis based on the load distribution time axis and calculating global idle computing resource information are as follows: Firmware load idle analysis is performed based on the load distribution time axis, and multiple spatial-temporal windows are extracted. Calculate the available computing resources for the multiple spatial-temporal windows; Based on the available computing resources, the distribution is identified and statistically summarized to generate global idle computing resource information.

[0084] In this embodiment, idle periods within the device's future operating cycle are identified to facilitate the execution of upgrade tasks during these idle times. By analyzing the load distribution timeline, the entire operating cycle is divided into continuous time slices. Each time slice includes multi-dimensional load metrics such as CPU utilization, memory usage, I / O operation frequency, and network bandwidth usage. The idle load analysis module identifies periods of low load or idle state by setting threshold rules and a sliding window mechanism. For example, when CPU utilization is below 30%, memory usage is below 40%, and I / O load is below a specified threshold, this time period is marked as an idle window.

[0085] Further spatial-temporal window extraction is performed on the load time axis, merging adjacent low-load time slices into continuous windows. Each window records its start and end times, duration, and resource metric vector. During window extraction, task priority, task dependencies, and historical load fluctuation patterns are also considered to exclude short-term abnormal low-load segments, ensuring the stability and executability of the extracted windows. The resulting multiple spatial-temporal windows form a preliminary set of candidate upgrade times, providing reliable temporal and spatial constraints for upgrade task decomposition and scheduling.

[0086] The available computing resources for upgrade tasks within each window are quantified. The available computing resource calculation module compares various load indicators within the time window with the total resource capacity of the device, calculating CPU idle cycles, available memory capacity, I / O throughput margin, and available network bandwidth. A multi-dimensional resource weighting model is used in the calculation process, weighting different resource types according to their sensitivity to the upgrade task to generate a comprehensive resource availability index.

[0087] Furthermore, the computation module considers task parallelism and resource conflicts, simulating and estimating potential resource contention within the window. For example, if high-priority tasks and low-priority user tasks coexist, the resource allocation ratio is dynamically adjusted to ensure that the upgrade task does not consume resources exceeding a safe threshold. Each spatial-temporal window ultimately generates a complete resource vector, including the number of available CPU cycles, available memory size, available I / O throughput, and network bandwidth capacity, along with window duration information. This calculation provides a quantitative basis for subsequent global resource identification and upgrade task optimization, ensuring the safety and executability of task allocation.

[0088] After quantifying the available computing resources for each spatial-temporal window, a comprehensive analysis of the resource distribution across all windows will be conducted to generate global idle computing resource information. The distribution identification module aggregates and statistically analyzes the resource vectors of all windows to calculate the distribution of each resource indicator throughout the entire period, including parameters such as mean, variance, minimum, maximum, and idle time percentage. Simultaneously, the distribution trends of CPU, memory, I / O, and network resources are visualized and analyzed to identify periodic idle peaks and low-load areas.

[0089] The statistical aggregation process employs weighted statistics and normalization to quantify the idle resources of different resource types into a comprehensive resource index. This index facilitates priority ranking and dynamic matching of upgrade tasks during scheduling. The resulting global idle computing resource information includes the availability of each resource type across different time windows, resource distribution curves, and idle time distribution tables. This provides a reliable basis for adaptive decomposition, fragmented execution, and load balancing of upgrade tasks. This global perspective enables efficient utilization of idle resources while ensuring normal device operation, achieving a safe and low-impact firmware upgrade strategy.

[0090] In this embodiment, a cloud-based firmware upgrade system is provided for performing the cloud-based firmware upgrade method described above, including: The version difference identification module is used to identify device firmware configuration information based on the cloud, perform version information difference analysis at the module level, and generate version difference information for each module level. The incremental parsing module is used to parse the incremental update range based on the version difference information and extract the upgrade incremental package for each module. The compatibility verification module is used to personalize and customize the upgrade incremental package and verify firmware operation compatibility, and to build an executable upgrade task package. The fragmented update module is used to adaptively decompose executable upgrade task packages and process updates in fragmented time periods.

[0091] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0092] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein are implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A firmware upgrade method based on cloud computing, characterized in that, Includes the following steps: Step S1: Based on the cloud-based identification of device firmware configuration information, perform module-level version information difference analysis and generate version difference information for each module level; Step S2: Analyze the incremental update range based on the version difference information and extract the upgrade incremental package for each module; Step S3: Perform personalized adaptation and firmware operation compatibility verification on the upgrade incremental package to build an executable upgrade task package; Step S4: Adaptively decompose and update the executable upgrade task package in fragmented time periods.

2. The firmware upgrade method based on cloud computing according to claim 1, characterized in that, The specific steps of step S1 are as follows: Based on cloud-based identification of device firmware configuration information; The device firmware configuration information is functionally modularized and the version information of different module layers of the firmware is extracted. The firmware includes different module layers, including the driver layer, protocol layer, and application layer; Identify the latest firmware version information in the cloud database; Based on the latest firmware version information database in the cloud, the version information is analyzed for differences at each module level to generate version difference information for each module level.

3. The firmware upgrade method based on cloud computing according to claim 1, characterized in that, The specific steps of step S2 are as follows: Based on the version difference information, the incremental update range is parsed to generate an incremental update boundary list; Perform inter-module dependency analysis on the module layer to extract the inter-module dependencies; Dependency conflict analysis is performed on the incremental update boundary list based on the inter-module dependencies to obtain the dependency conflict results. Conflict optimization is performed based on the dependency conflict results, and feasibility is verified to obtain the scope of incremental update optimization. The incremental update optimization scope is analyzed module by module to extract the upgrade incremental package for each module.

4. The firmware upgrade method based on cloud computing according to claim 1, characterized in that, Step S3 is as follows: Acquire firmware operation monitoring records from the device; perform multi-dimensional operation trajectory tracking on the firmware operation monitoring records and extract the multi-dimensional operation trajectory; The multi-dimensional operation trajectory includes module loading time, function call frequency, resource consumption hotspots, and fault recovery logs. Deeply mine the operational patterns of multi-dimensional operational trajectories to generate firmware operational pattern evolution characteristics; Based on the firmware operation monitoring records, user preferences, operation time distribution, and function call patterns are identified to establish user behavior profiles. Based on user behavior profiles and firmware operation pattern evolution characteristics, the upgrade incremental package is personalized and customized to generate an adaptive incremental package; Firmware compatibility verification is performed on the adaptive incremental package, and an executable upgrade task package is built.

5. The firmware upgrade method based on cloud computing according to claim 1, characterized in that, The specific steps of step S4 are as follows: Based on the firmware operation monitoring records, the load distribution within the period is predicted, and a load distribution time axis is generated. Firmware load idle analysis is performed based on the load distribution time axis, and global idle computing resource information is calculated. Based on global idle computing resource information, the executable upgrade task package is adaptively decomposed to generate multiple minimized upgrade task packages; Perform task dependency logic analysis on multiple minimal upgrade task packages, and perform priority serialization processing to generate a task package sequence; Updates are performed in fragmented time periods based on task package sequences and stored locally, while aggregating global update packages. Perform a firmware upgrade based on the global update package.

6. The firmware upgrade method based on cloud computing according to claim 5, characterized in that, The specific steps for predicting the load distribution within a period based on the firmware operation monitoring records and generating a load distribution time axis are as follows: Based on the firmware operation monitoring records, the device's CPU utilization, memory usage, I / O operation frequency, and network bandwidth usage are calculated to generate real-time load characteristics; Based on the real-time load characteristics, a discrete fitting of time-series changes is performed to generate a time-series load change curve; Extract the task processing list based on the firmware operation monitoring records; The processing volume of the task processing list is analyzed, and the priority distribution is identified to generate features of incomplete tasks. Estimate the resource usage of incomplete tasks based on their characteristics, and generate the resource usage for task processing. Based on the resource consumption and time-series load change curve of task processing, the load distribution within the period is predicted, and a load distribution time axis is generated.

7. The firmware upgrade method based on cloud computing according to claim 5, characterized in that, The specific steps for performing firmware load idle analysis based on the load distribution time axis and calculating global idle computing resource information are as follows: Firmware load idle analysis is performed based on the load distribution time axis, and multiple spatial-temporal windows are extracted. Calculate the available computing resources for the multiple spatial-temporal windows; Based on the available computing resources, the distribution is identified and statistically summarized to generate global idle computing resource information.

8. A firmware upgrade system based on cloud computing, characterized in that, The method for performing the cloud-based firmware upgrade method as described in claim 1 includes: The version difference identification module is used to identify device firmware configuration information based on the cloud, perform version information difference analysis at the module level, and generate version difference information for each module level. The incremental parsing module is used to parse the incremental update range based on the version difference information and extract the upgrade incremental package for each module. The compatibility verification module is used to personalize and customize the upgrade incremental package and verify firmware operation compatibility, and to build an executable upgrade task package. The fragmented update module is used to adaptively decompose executable upgrade task packages and process updates in fragmented time periods.

Images