Embedded device multi-module parallel OTA upgrading method and system
By constructing a directed acyclic graph and a parallel upgrade queue, the problems of long time, dependency conflicts and insufficient security in the OTA upgrade of multiple modules of embedded devices are solved, and an efficient and secure multi-module upgrade process is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG ARTAPLAY INTELLIGENT TECH CO LTD
- Filing Date
- 2025-11-21
- Publication Date
- 2026-04-21
AI Technical Summary
The existing multi-module OTA upgrades for embedded devices suffer from problems such as long upgrade times, frequent dependency conflicts, weak fault tolerance, and insufficient security. In particular, when there are hardware resource conflicts between modules and insufficient security verification, the devices become less available and more expensive to maintain.
By constructing a directed acyclic graph to identify dependent modules, a parallel upgrade queue is adopted, independent storage buffers and hardware resources are allocated, module-level verification is performed, and fine-grained fault tolerance processing is carried out after device restart, including module-level verification and partial rollback operations.
It shortens the overall OTA upgrade time for multi-module devices, avoids dependency conflicts caused by manual configuration errors, improves the robustness and security of the upgrade process, and reduces operation and maintenance costs.
Smart Images
Figure CN121900778A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of remote upgrade technology for embedded systems, specifically to a method and system for parallel OTA upgrade of multiple modules of embedded devices. Background Technology
[0002] As embedded devices become increasingly complex, a single device often integrates multiple functional modules such as main control, communication, sensors, and drivers, and each module needs to be iterated or repaired through OTA upgrades.
[0003] Current technologies generally employ a serial upgrade approach, which involves downloading, writing, verifying, and restarting each module one by one. This approach has significant drawbacks: First, the total upgrade time increases linearly with the number of modules, severely impacting device availability; second, when there are dependencies between modules, the manually configured serial order is prone to errors, leading to upgrade failure; third, the system lacks fine-grained fault tolerance, and the failure of any module upgrade can paralyze the entire machine, requiring on-site manual intervention and incurring high maintenance costs.
[0004] In addition, the few existing parallel upgrade solutions also have shortcomings: they fail to effectively resolve conflicts in hardware resources (such as Flash read / write and bus bandwidth) between modules, which can easily lead to data corruption; in terms of security, they only perform overall verification of the upgrade package and lack verification of the legitimacy of individual module firmware and its compatibility with device hardware and other module versions, which poses security and compatibility risks. Summary of the Invention
[0005] To address the aforementioned issues, this invention provides a method and system for parallel OTA upgrades of multiple modules in embedded devices, thereby resolving the problems of low efficiency, frequent dependency conflicts, weak fault tolerance, and insufficient security associated with traditional serial upgrades.
[0006] In a first aspect, the present invention provides a method for parallel OTA upgrade of multiple modules in an embedded device, comprising: Download the OTA upgrade package and perform an overall security check. After the check passes, parse the dependencies of the modules in the OTA upgrade package. A directed acyclic graph is constructed based on the aforementioned dependencies, modules without dependencies are identified, and modules without dependencies are added to the parallel upgrade queue according to a preset priority. Allocate independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue; The system controls each module in the parallel upgrade queue to synchronously extract its own firmware from the OTA upgrade package, write it into its corresponding storage buffer, and complete module-level verification. After the device restarts, verify the upgrade results of all modules; if a module upgrade fails, only trigger a rollback operation on the failed module and its dependent modules.
[0007] By constructing a directed acyclic graph to identify independent modules and performing parallel upgrades, the overall OTA upgrade time for multi-module devices is shortened. Determining the upgrade order based on dependency resolution fundamentally avoids module dependency conflicts caused by manual configuration errors. Through module-level verification and partial rollback mechanisms, refined fault tolerance is achieved, preventing the failure of a single module from paralyzing the entire system and improving the robustness of the upgrade process.
[0008] As a preferred embodiment of the technical solution of this invention, the steps of downloading the OTA upgrade package and performing an overall security verification, and then resolving the dependencies of modules in the OTA upgrade package after the verification passes, include: The device's communication module downloads the OTA upgrade package from the cloud server to the shared upgrade package storage area of the partitioned storage module; Perform an overall verification on the OTA upgrade package. The overall verification includes calculating the hash value of the OTA upgrade package using the SHA-256 algorithm and comparing it with the verification value provided by the cloud. After successful verification, the module list within the OTA package is parsed. The module list includes the firmware file of each module, a dependency table describing the dependencies between modules, and the version information of each module.
[0009] OTA packages are downloaded to the shared upgrade package storage area of the partitioned storage module to avoid management chaos caused by scattered package storage; SHA-256 hash verification is used to ensure the integrity of OTA packages transmitted from the cloud to the device, completely preventing tampered packages from entering the upgrade process. By parsing the firmware files, dependency tables, and version information in the module manifest, complete data support is provided for subsequent dependency analysis and parallel grouping, avoiding parallel strategy errors caused by missing information.
[0010] As a preferred embodiment of the technical solution of the present invention, the dependency table is in XML format, and the dependency table defines the following fields for each module: Module ID, used to identify a module to be upgraded; The dependency module ID list is used to list the IDs of one or more other modules that the module identified by the module ID depends on; Minimum compatible version, used to specify the minimum version number that each module in the dependency module ID list must meet.
[0011] The dependency table in XML format, combined with the minimum compatible version field, can not only describe whether there are dependencies between modules, but also precisely constrain the minimum required version, effectively preventing compatibility failures after upgrades due to version mismatch.
[0012] As a preferred embodiment of the technical solution of the present invention, the steps of constructing a directed acyclic graph based on the dependency relationship, identifying modules without dependency relationships, and adding modules without dependency relationships to the parallel upgrade queue according to a preset priority include: Construct a directed acyclic graph based on the parsed dependency table, where nodes in the graph represent modules to be upgraded and edges represent the dependency directions between modules; Identify the modules represented by nodes with an in-degree of zero in the directed acyclic graph as parallel upgradeable modules without dependencies. Based on the functional importance of the modules, the parallel upgradeable modules are divided into three priority groups: high, medium, and low. Modules within the same priority group that have no dependencies on each other will be included in the same parallel upgrade queue.
[0013] Dependencies are transformed into directed acyclic graphs, visually representing constraints between modules. This allows for the rapid identification of modules with zero in-degree and no dependencies, avoiding omissions and misjudgments during manual dependency analysis. Modules are divided into high, medium, and low priority groups to ensure high-priority modules receive resources first, preventing low-priority modules from consuming resources and causing delays in core module upgrades, thus ensuring rapid restoration of core device functionality. Only modules with the same priority and no dependencies are included in the same queue, preventing the forced parallel processing of modules with implicit dependencies and further reducing the risk of conflicts during parallel upgrades.
[0014] As a preferred embodiment of the technical solution of the present invention, the parallel upgradeable modules are divided into three priority groups—high, medium, and low—based on their functional importance, specifically including: Divide the main control module into a high-priority group; The communication modules are divided into medium priority groups; The sensor module and the driver module are divided into a low-priority group.
[0015] Prioritize modules based on their functional importance to ensure that core modules are upgraded first, providing a stable foundation for modules that depend on them and optimizing the systematic nature of the upgrade process.
[0016] As a preferred embodiment of the technical solution of the present invention, the step of allocating independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue includes: For each module in the parallel upgrade queue, allocate an independent buffer in the partitioned storage module; A time-slicing mechanism is used to allocate write time windows for Flash memory to each module in order to avoid conflicts caused by multiple modules performing write operations on Flash simultaneously. The token bucket algorithm is used to allocate bus bandwidth to each module. High-priority modules are allocated higher token quotas, and the upgrade progress of each module in the parallel upgrade queue is monitored. When the upgrade progress of a low-priority module is found to be lagging behind a preset planned threshold, the bus bandwidth quota of the low-priority module is temporarily increased.
[0017] By employing a time-slicing mechanism and a token bucket algorithm, shared hardware resources such as Flash writing and bus bandwidth are effectively managed, thus resolving resource contention issues during parallel upgrades.
[0018] By introducing a dynamic resource adjustment mechanism, the resource quota of lagging modules can be temporarily increased according to the real-time progress, ensuring that all modules can complete the upgrade within the predetermined time window, thereby improving the fairness and overall efficiency of parallel scheduling.
[0019] As a preferred embodiment of the technical solution of the present invention, the steps of controlling each module in the parallel upgrade queue to synchronously extract its own firmware from the OTA upgrade package, write it into its corresponding storage buffer, and complete module-level verification include: Send upgrade instructions to each module in the parallel upgrade queue; In response to the upgrade command, each firmware file is read from the shared upgrade package storage area and written to the independent buffer allocated to each module in the partitioned storage module; After the firmware is written to an independent buffer, the firmware is verified, including checking the matching between the firmware's digital signature and the device hardware ID. After verification, the firmware is written from its respective independent buffer to the running area, and the upgrade completion status is reported.
[0020] The OTA coordination module sends upgrade commands centrally, avoiding the disorder caused by multiple modules starting upgrades independently and ensuring that parallel upgrades are executed according to a preset strategy. Firmware is first written to an independent buffer and verified before being written to the runtime area, preventing firmware corruption in the runtime area due to verification failures when writing directly, thus improving upgrade security. After a module completes its upgrade, it sends a status code. The OTA coordination module can monitor the progress of each module in real time, promptly identifying modules that have not provided status feedback for extended periods, preventing upgrade timeouts or missed failures due to unclear progress, and improving process controllability.
[0021] As a preferred embodiment of the technical solution of the present invention, after the firmware is written to an independent buffer, the firmware is verified. The verification includes the step of verifying the matching between the digital signature of the firmware and the device hardware ID, including: Extract the digital signature certificate attached to the firmware file to be verified; The digital signature certificate is decrypted and verified using a public key pre-installed in the device's secure storage area to confirm the legitimacy of the firmware's origin. After the certificate verification is successful, the list of device hardware IDs authorized by the firmware is parsed from the digital signature certificate; Verify whether the hardware ID of the current device is within the authorized list of device hardware IDs.
[0022] First, the digital signature is decrypted and verified using the public key to confirm the firmware's origin from the authorized party, preventing malicious third parties from forging the firmware. Then, the device hardware ID is verified to ensure it's on the authorized list, preventing the firmware from being illegally used on non-target devices. The public key is pre-stored in the device's secure storage area to prevent signature verification failure due to public key tampering, ensuring the verification mechanism itself cannot be bypassed and enhancing security. Hardware ID verification ensures precise matching between the firmware and the device hardware model, preventing serious problems such as module burnout and functional failure due to firmware incompatibility.
[0023] As a preferred embodiment of the technical solution of the present invention, after the device is restarted, the upgrade results of all modules are verified; when a module upgrade fails, the step of triggering a rollback operation only on the failed module and its dependent modules includes: After the device restarts, it enters verification mode, where each module performs self-diagnostic operations and reports the results. The self-diagnostic operations include functional testing and version matching checks. Receive the self-diagnostic results of all modules and identify modules that failed to upgrade; When an upgrade fails, a partial rollback operation is performed, including: Based on the constructed directed acyclic graph, determine all associated modules that depend on the upgrade failure module; Control the upgrade failure module and all associated modules to restore the firmware of the previous version from the backup area of the partition storage module and report the failure log to the cloud.
[0024] After the device restarts, each module performs self-diagnostics to verify whether the firmware is running normally and to confirm version compatibility between modules, avoiding hidden faults such as successful upgrades but unusable functionality. Based on the constructed directed acyclic graph, all related dependent modules of the failed module are quickly identified, avoiding rollback scope that is too large or too small, and balancing rollback efficiency with system stability.
[0025] Report failure logs to the cloud, including information such as the failed module, the reason for failure, and the rollback operation, so that operation and maintenance personnel can analyze the root cause of the failure and reduce the cost of subsequent troubleshooting.
[0026] Secondly, the present invention also provides an embedded device multi-module parallel OTA upgrade system, comprising: The communication module is used to download OTA upgrade packages from the cloud server; The partitioned storage module includes a shared upgrade package storage area, multiple independent buffers, and a backup area. Each independent buffer corresponds to a functional module to be upgraded. The security verification module is used to perform overall security verification on the OTA upgrade package and to perform module-level verification on the firmware of each module. The OTA coordination module, which is communicatively connected to the communication module, partition storage module, and security verification module, is used to parse the module dependencies in the OTA upgrade package; construct a directed acyclic graph based on the dependencies, identify modules without dependencies, and add them to the parallel upgrade queue according to a preset priority; allocate independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue; and control each module to synchronously perform firmware writing and verification. Multiple functional modules to be upgraded, each module including an upgrade agent unit, used to respond to the instructions of the OTA coordination module to perform firmware extraction, writing, verification and status reporting; The rollback and recovery module is used to verify the upgrade results of each module after the device restarts, and to trigger a rollback operation only for the failed module and its dependent modules when a module upgrade fails.
[0027] As a preferred embodiment of the technical solution of the present invention, the OTA coordination module includes: The dependency resolution unit is used to parse the dependency table and construct a directed acyclic graph; Priority sorting unit, used to divide modules into three priority groups: high, medium, and low, based on the importance of their functions; The resource scheduling unit is used to allocate independent buffers for modules in the parallel upgrade queue, allocate Flash write windows using a time-slicing mechanism, and allocate bus bandwidth using a token bucket algorithm; the resource scheduling unit is also used to perform dynamic resource adjustments. Monitor the upgrade progress of each module in the parallel upgrade queue, and when it is identified that the upgrade progress of a low-priority group module lags behind the preset planned threshold, temporarily increase the bus bandwidth quota of that module. The status monitoring unit is used to receive the upgrade progress and self-diagnosis results of each module.
[0028] As a preferred embodiment of the technical solution of the present invention, the security verification module includes: The overall verification unit is used to perform SHA-256 hash verification on OTA upgrade packages; The module verification unit is used to verify the matching between the digital signature of each module firmware and the device hardware ID; The compatibility verification unit is used to check the compatibility of the new firmware of the module with the device hardware and other module versions.
[0029] As a preferred embodiment of the technical solution of the present invention, the rollback and recovery module supports a partial rollback mechanism, which is used to determine all associated modules that depend on the failed module according to the directed acyclic graph; and to control the failed module and all associated modules to be restored from the backup area to the firmware version before the upgrade.
[0030] As can be seen from the above technical solutions, this application has the following advantages: by constructing a directed acyclic graph to identify modules without dependencies, and including them in a parallel upgrade queue for synchronous upgrade, the serial waiting of starting the next module after the upgrade of a single module is completed is avoided, thus shortening the total time of multi-module upgrade.
[0031] By constructing a directed acyclic graph based on dependencies, the system can automatically identify the constraints on the order of module upgrades, eliminating the need for manual configuration of the upgrade order. This solves the dependency conflict problem caused by manual configuration errors in the traditional serial approach and reduces the upgrade failure rate.
[0032] Allocate independent storage buffers and dedicated hardware read / write resources to parallel modules to avoid resource conflicts when multiple modules access Flash and bus simultaneously, and ensure data integrity during the upgrade process.
[0033] Through a dual-layer protection system of overall security verification and module-level verification, it not only prevents tampering during OTA packet transmission, but also ensures that the firmware of each module is from a legitimate source and matches the device hardware, thus avoiding device failures caused by malicious firmware injection or incompatible firmware.
[0034] Rollback is performed only on the failed module and its dependent modules, without affecting the upgrade results of independent modules. This avoids the problem of a single module failure causing the entire machine to crash in traditional solutions and reduces rollback time. Attached Figure Description
[0035] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0036] Figure 1 This is a flowchart illustrating the method provided in an embodiment of the present invention.
[0037] Figure 2 A block diagram of a system provided in an embodiment of the present invention. Detailed Implementation
[0038] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0039] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this application and in the specification of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.
[0040] like Figure 1 As shown, this embodiment of the invention provides a multi-module parallel OTA upgrade method for embedded devices, characterized by comprising: S1. Download the OTA upgrade package and perform an overall security check. After the check passes, parse the dependencies of the modules in the OTA upgrade package. S2. Construct a directed acyclic graph based on the dependency relationship, identify modules without dependency relationships, and add modules without dependency relationships to the parallel upgrade queue according to a preset priority. S3. Allocate independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue; S4. Control each module in the parallel upgrade queue to synchronously extract its own firmware from the OTA upgrade package, write it into its corresponding storage buffer, and complete module-level verification. S5. After the device restarts, verify the upgrade results of all modules; if a module upgrade fails, only trigger the rollback operation for the failed module and its dependent modules.
[0041] First, the smart home control device downloads an OTA upgrade package containing firmware for multiple modules from the cloud via its WiFi module. Next, the device's internal security chip performs an SHA-256 hash check on the upgrade package to ensure its integrity. After successful check, the system parses a manifest file named "dependencies.xml" within the package to obtain the dependencies between modules.
[0042] The system then constructs a directed acyclic graph (DAG) based on these dependencies. For example, it identifies the main control module (MCU) as the root node, the WiFi module as dependent on the MCU, and the sensor and ZigBee modules as independent of each other. The system groups the independent sensor and ZigBee modules into the same priority group and adds them to a parallel upgrade queue.
[0043] The resource manager allocates independent Flash buffers and bus bandwidth time slices to each of the two modules. Subsequently, the system controls both modules to simultaneously read their respective firmware from the shared storage area, write it to the buffer, and verify its digital signature. Once the signature verification is successful, the firmware is written to their respective runtime areas.
[0044] Finally, the device restarts. All modules perform self-checks. If the WiFi module fails to start due to version incompatibility, the system automatically triggers the rollback mechanism. Based on the previously constructed DAG, the rollback mechanism determines that only the WiFi module needs to be rolled back (assuming no other modules depend on it). Therefore, only the WiFi module's firmware is restored from the backup area, while the sensor and ZigBee modules are successfully retained in the new version.
[0045] In some embodiments, the steps of downloading the OTA upgrade package and performing an overall security verification, followed by resolving the dependencies of modules in the OTA upgrade package after the verification passes, include: S11. Download the OTA upgrade package from the cloud server to the shared upgrade package storage area of the partitioned storage module through the device's communication module; S12. Perform an overall verification on the OTA upgrade package. The overall verification includes calculating the hash value of the OTA upgrade package using the SHA-256 algorithm and comparing it with the verification value provided by the cloud. S13. After successful verification, parse the module list within the OTA package. The module list includes the firmware files for each module, a dependency table describing the dependencies between modules, and version information for each module. The dependency table is in XML format, and for each module, the dependency table defines the following fields: Module ID, used to identify a module to be upgraded; The dependency module ID list is used to list the IDs of one or more other modules that the module identified by the module ID depends on; Minimum compatible version, used to specify the minimum version number that each module in the dependency module ID list must meet.
[0046] Specifically, the communication module (such as the 4G Cat.1 module) downloads a 500MB OTA upgrade package from the cloud server via HTTPS and securely writes it to a pre-allocated 32GB shared upgrade package storage area in the partitioned storage module. Next, the security verification module calls the built-in Hardware Security Module (HSM) to calculate the SHA-256 hash value of the entire OTA package and compares it with the checksum issued by the cloud upgrade service; if they match, the upgrade passes. Subsequently, the OTA coordination module decompresses the upgrade package and reads the "manifest.json" file (a module manifest) within it. This file lists the firmware filenames of all modules to be upgraded, an XML fragment defining dependencies, and the old and new version numbers of each module.
[0047] In some embodiments, the steps of constructing a directed acyclic graph based on the dependencies, identifying modules without dependencies, and adding modules without dependencies to the parallel upgrade queue according to a preset priority include: S21. Construct a directed acyclic graph based on the parsed dependency table, where the nodes in the graph represent modules to be upgraded and the edges represent the dependency directions between modules; S22. Identify the modules represented by nodes with an in-degree of zero in the directed acyclic graph as parallel upgradeable modules without dependencies. S23. Based on the functional importance of the modules, the parallel upgradeable modules are divided into three priority groups: high, medium, and low; specifically including: Divide the main control module into a high-priority group; The communication modules are divided into medium priority groups; The sensor module and the driver module are divided into a low-priority group.
[0048] S24. Incorporate modules within the same priority group that have no dependencies on each other into the same parallel upgrade queue.
[0049] The dependency resolution unit in the OTA coordination module reads the entire dependency table and constructs a Directed Acyclic Graph (DAG) in memory. In this graph, each module is a node, and if module A depends on module B, there is an edge from B to A. The algorithm then traverses all nodes, finding all nodes with an in-degree (i.e., the number of edges pointing to that node). These nodes represent modules (such as the main control MCU) that are either immediately upgradable or have no dependencies. Next, the priority sorting unit divides these dependency-free modules into high, medium, and low priority groups according to predefined rules (such as the impact of module failure on the system). Finally, modules belonging to the same priority group and having no direct or indirect dependencies in the graph model (such as two different sensor drivers) are grouped into the same parallel upgrade queue.
[0050] When prioritizing tasks, the system follows a pre-defined mapping table. For example, the main control module responsible for system scheduling and basic operation (such as an ARM Cortex-M series MCU) is assigned to the high-priority group; communication modules related to device networking capabilities (such as 4G / 5G modules and Wi-Fi chips) are assigned to the medium-priority group; and various sensor modules (such as temperature and humidity sensors and light sensors) and actuator drive modules (such as motor drives) are assigned to the low-priority group. This grouping strategy ensures that core system functions are updated first, laying the foundation for stable device operation.
[0051] In some embodiments, the step of allocating independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue includes: S31. Allocate an independent buffer in the partitioned storage module for each module in the parallel upgrade queue; S32. A time-slicing mechanism is used to allocate a write time window for the Flash memory to each module in order to avoid conflicts caused by multiple modules performing write operations on the Flash memory at the same time. S33. The token bucket algorithm is used to allocate bus bandwidth to each module. High-priority modules are allocated higher token quotas, and the upgrade progress of each module in the parallel upgrade queue is monitored. When it is found that the upgrade progress of a low-priority module is lagging behind the preset planned threshold, the bus bandwidth quota of the low-priority module is temporarily increased.
[0052] The resource scheduling unit first creates and allocates an independent buffer for each module (such as Sensor_A and Sensor_B) in the parallel queue within the partitioned storage module. The buffer's size is typically 1.5 times the module's firmware size to ensure smooth write operations. For Flash memory write operations, a time-slicing mechanism is used, specifying that Sensor_A writes within a 0ms to 50ms time slice, while Sensor_B writes within a 50ms to 100ms time slice, thus avoiding simultaneous programming operations on the same Flash physical unit. For bus bandwidth, a token bucket algorithm is used for allocation, with the initial total token generation rate for high-priority groups set to 1.5 times that of medium-priority groups. During the upgrade process, the status monitoring unit reports the progress of each module in real time. If a low-priority sensor module lags behind schedule by 30%, the resource scheduling unit temporarily increases its token generation rate by 50% to ensure it catches up with the overall progress and avoids becoming a bottleneck.
[0053] In some embodiments, the steps of controlling each module in the parallel upgrade queue to synchronously extract its own firmware from the OTA upgrade package, write it to its corresponding storage buffer, and complete module-level verification include: Send upgrade instructions to each module in the parallel upgrade queue; In response to the upgrade command, each firmware file is read from the shared upgrade package storage area and written to the independent buffer allocated to each module in the partitioned storage module; After the firmware is written to an independent buffer, it is verified. This verification includes checking the match between the firmware's digital signature and the device hardware ID. Specifically, this involves: extracting the digital signature certificate attached to the firmware file to be verified; decrypting and verifying the digital signature certificate using a public key pre-installed in the device's secure storage area to confirm the firmware's legitimacy; after successful certificate verification, parsing the list of device hardware IDs authorized by the firmware from the digital signature certificate; and verifying whether the current device's hardware ID is within the list of authorized device hardware IDs. Specifically, the module verification unit first extracts the attached X.509 format digital signature certificate from the firmware file's header information. Then, it uses a public key pre-installed and securely stored in eFuse at the device's factory to decrypt and verify the certificate, confirming that it was issued by a trusted firmware issuing authority. After successful certificate verification, the verification unit parses a list named "AuthorizedHWIDs" from the certificate's extended fields. This list contains the hardware IDs of all target devices authorized to install this firmware. Finally, the verification unit reads the device's unique hardware ID (e.g., from the chip's unique identifier register) and checks if the ID exists in the parsed "AuthorizedHWIDs" list. Only if it is in the list is the matching verification considered successful.
[0054] After verification, the firmware is written from its respective independent buffer to the running area, and the upgrade completion status is reported.
[0055] The OTA coordination module broadcasts upgrade commands to the upgrade agent units of modules in a parallel queue (such as Display and Audio modules) via the device's internal bus (e.g., CAN or SPI). Upon receiving the command, each upgrade agent unit efficiently reads its own firmware binary file from the shared upgrade package storage area using DMA (Direct Memory Access) and writes it to a pre-allocated independent buffer. After writing, the module verification unit of the security verification module is invoked to verify the firmware in the buffer, specifically checking whether its attached digital signature is bound to the device's unique hardware ID. Only firmware that passes verification is officially burned from the buffer to the module's running Flash area by the upgrade agent unit, and finally sends a "0xAA" (success) status code to the OTA coordination module.
[0056] In some embodiments, after the device restarts, the upgrade results of all modules are verified; when a module upgrade fails, the step of triggering a rollback operation only for the failed module and its dependent modules includes: S41. After the device restarts, it enters the verification mode. Each module performs self-diagnosis operations and reports the self-diagnosis results. The self-diagnosis operations include functional testing and version matching checks. S42. Receive the self-diagnostic results of all modules and identify the modules that failed to upgrade; S43. When an upgrade fails, perform a partial rollback operation, including: S44. Based on the constructed directed acyclic graph, determine all associated modules that depend on the upgrade failure module; S45. Control the upgrade failure module and all associated modules to restore the firmware of the previous version from the backup area of the partition storage module and report the failure log to the cloud.
[0057] After a cold reboot, the device first enters a dedicated verification mode instead of directly running user programs. In this mode, each module's upgrade agent unit performs a series of self-diagnostic operations. For example, the communication module attempts to connect to a preset server, the sensor module performs baseline calibration and reading checks, and all modules verify the compatibility of their own versions with those of other related modules. These self-diagnostic results are aggregated and reported to the OTA coordination module. If the power management module (PMIC) reports a boot failure, the OTA coordination module marks it as an upgrade failure module. Subsequently, the rollback and recovery module is activated. It queries the previously constructed DAG and finds that the display module depends on the PMIC's power management protocol version. Therefore, the rollback module controls the PMIC and display modules to reload their pre-upgrade firmware versions from the backup area. Key logs throughout the rollback process (such as the failed module ID, rollback reason, and list of related modules) are recorded and uploaded to the cloud-based operations and maintenance platform via the communication module.
[0058] like Figure 2 As shown, this embodiment of the invention also provides an embedded device multi-module parallel OTA upgrade system, including: The communication module is used to download OTA upgrade packages from the cloud server; The partitioned storage module includes a shared upgrade package storage area, multiple independent buffers, and a backup area. Each independent buffer corresponds to a functional module to be upgraded. The security verification module is used to perform overall security verification on the OTA upgrade package and to perform module-level verification on the firmware of each module. The OTA coordination module, which is communicatively connected to the communication module, partition storage module, and security verification module, is used to parse the module dependencies in the OTA upgrade package; construct a directed acyclic graph based on the dependencies, identify modules without dependencies, and add them to the parallel upgrade queue according to a preset priority; allocate independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue; and control each module to synchronously perform firmware writing and verification. Multiple functional modules to be upgraded, each module including an upgrade agent unit, used to respond to the instructions of the OTA coordination module to perform firmware extraction, writing, verification and status reporting; The rollback and recovery module is used to verify the upgrade results of each module after the device restarts, and to trigger a rollback operation only for the failed module and its dependent modules when a module upgrade fails.
[0059] This system is deployed in an industrial IoT gateway. The communication module adopts a dual-mode design (Ethernet and 5G) and is responsible for downloading OTA upgrade packages from the cloud platform. The partitioned storage module consists of a 128GB eMMC block, divided into a shared area, five independent buffers, and a backup area. The security verification module integrates a national cryptographic algorithm chip and is responsible for performing verification at all levels. The OTA coordination module runs on the gateway's main application processor, and its various software units work together to achieve dependency resolution, priority sorting, resource scheduling, and status monitoring. Multiple upgradeable functional modules include the main control processor, 5G communication module, edge AI computing unit, IO acquisition module, and real-time clock module, each with its own built-in upgrade agent program. The rollback and recovery module runs as an independent daemon process, monitoring the upgrade results and performing precise partial rollbacks in case of failure.
[0060] In some embodiments, the OTA coordination module includes: The dependency resolution unit is used to parse the dependency table and construct a directed acyclic graph; Priority sorting unit, used to divide modules into three priority groups: high, medium, and low, based on the importance of their functions; The resource scheduling unit is used to allocate independent buffers for modules in the parallel upgrade queue, allocate Flash write windows using a time-slicing mechanism, and allocate bus bandwidth using a token bucket algorithm; the resource scheduling unit is also used to perform dynamic resource adjustments. Monitor the upgrade progress of each module in the parallel upgrade queue, and when it is identified that the upgrade progress of a low-priority group module lags behind the preset planned threshold, temporarily increase the bus bandwidth quota of that module. The status monitoring unit is used to receive the upgrade progress and self-diagnosis results of each module.
[0061] The four units of the OTA coordination module are implemented as follows: The dependency resolution unit is a software library used to parse XML dependency tables and call graph algorithm libraries (such as the Boost Graph Library) to construct and manipulate DAGs. The priority sorting unit maintains a configurable priority rule database. The resource scheduling unit directly interacts with the chip's Memory Management Unit (MMU) and DMA controller, implementing time slicing and token bucket scheduling; its dynamic resource adjustment function is implemented through a background monitoring thread, which periodically checks progress reports and dynamically adjusts bandwidth quotas by calling the resource allocation interface when lag is detected. The status monitoring unit collects the progress and diagnostic results of each module by subscribing to status messages on the device bus.
[0062] In some embodiments, the security verification module includes: The overall verification unit is used to perform SHA-256 hash verification on OTA upgrade packages; The module verification unit is used to verify the matching between the digital signature of each module firmware and the device hardware ID; The compatibility verification unit is used to check the compatibility of the new firmware of the module with the device hardware and other module versions.
[0063] The three units of the security verification module operate under the support of a hardware root of trust. The overall verification unit calculates the hash value of the entire OTA packet immediately after the communication module completes data download. The module verification unit performs certificate and hardware ID matching verification after each module's firmware is written to its independent buffer. The compatibility verification unit is invoked during the parallel policy generation phase. It reads the version information from the parsed module list and, based on the lowest compatible version field in the dependency table, verifies whether the new firmware version is compatible with the current versions of other hardware or software modules on the device. For example, it checks whether the new AI unit firmware V3.0 requires the main control module to be at least version V2.5.
[0064] In some embodiments, the rollback and recovery module supports a partial rollback mechanism, used to determine all associated modules that depend on the failed module based on the directed acyclic graph; and to control the failed module and all associated modules to be restored from the backup area to the firmware version before the upgrade.
[0065] Upon detecting an upgrade failure event, the rollback and recovery module immediately queries the dependency resolution unit of the OTA coordination module to retrieve the pre-built DAG. It uses a graph traversal algorithm (such as Breadth-First Search - BFS) to find all downstream nodes (i.e., associated modules) that directly or indirectly depend on the failed module node. Then, it sends rollback commands to the upgrade agent units of these target modules (the failed module and its associated modules) via the device management bus. Upon receiving the command, the upgrade agent unit reads and verifies the firmware backup before the upgrade from the backup area of the partitioned storage module, and then flashes it back to the runtime area, completing a precise partial rollback.
[0066] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the 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 disclosed herein.
Claims
1. A method for parallel OTA upgrade of multiple modules in an embedded device, characterized in that, include: Download the OTA upgrade package and perform an overall security check. After the check passes, parse the dependencies of the modules in the OTA upgrade package. A directed acyclic graph is constructed based on the aforementioned dependencies, modules without dependencies are identified, and modules without dependencies are added to the parallel upgrade queue according to a preset priority. Allocate independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue; The system controls each module in the parallel upgrade queue to synchronously extract its own firmware from the OTA upgrade package, write it into its corresponding storage buffer, and complete module-level verification. After the device restarts, verify the upgrade results of all modules; if a module upgrade fails, only trigger a rollback operation on the failed module and its dependent modules.
2. The multi-module parallel OTA upgrade method for embedded devices according to claim 1, characterized in that, After downloading the OTA upgrade package and performing a comprehensive security verification, and once the verification passes, the steps for resolving the dependencies of the modules in the OTA upgrade package include: The device's communication module downloads the OTA upgrade package from the cloud server to the shared upgrade package storage area of the partitioned storage module; Perform an overall verification on the OTA upgrade package. The overall verification includes calculating the hash value of the OTA upgrade package using the SHA-256 algorithm and comparing it with the verification value provided by the cloud. After successful verification, the module list within the OTA package is parsed. The module list includes the firmware file of each module, a dependency table describing the dependencies between modules, and the version information of each module.
3. The multi-module parallel OTA upgrade method for embedded devices according to claim 2, characterized in that, The dependency table is in XML format, and for each module, the dependency table defines the following fields: Module ID, used to identify a module to be upgraded; The dependency module ID list is used to list the IDs of one or more other modules that the module identified by the module ID depends on; Minimum compatible version, used to specify the minimum version number that each module in the dependency module ID list must meet.
4. The multi-module parallel OTA upgrade method for embedded devices according to claim 3, characterized in that, The steps of constructing a directed acyclic graph based on the dependencies, identifying modules without dependencies, and adding modules without dependencies to the parallel upgrade queue according to a preset priority include: Construct a directed acyclic graph based on the parsed dependency table, where nodes in the graph represent modules to be upgraded and edges represent the dependency directions between modules; Identify the modules represented by nodes with an in-degree of zero in the directed acyclic graph as parallel upgradeable modules without dependencies. Based on the functional importance of the modules, the parallel upgradeable modules are divided into three priority groups: high, medium, and low. Modules within the same priority group that have no dependencies on each other will be included in the same parallel upgrade queue.
5. The multi-module parallel OTA upgrade method for embedded devices according to claim 4, characterized in that, Based on their functional importance, the parallel upgradeable modules are divided into three priority groups: high, medium, and low, specifically including: Divide the main control module into a high-priority group; The communication modules are divided into medium priority groups; The sensor module and the driver module are divided into a low-priority group.
6. The multi-module parallel OTA upgrade method for embedded devices according to claim 5, characterized in that, The steps of allocating independent storage buffers and hardware read / write resources to each module in the parallel upgrade queue include: For each module in the parallel upgrade queue, allocate an independent buffer in the partitioned storage module; A time-slicing mechanism is used to allocate write time windows for Flash memory to each module in order to avoid conflicts caused by multiple modules performing write operations on Flash simultaneously. The token bucket algorithm is used to allocate bus bandwidth to each module, where high-priority modules are allocated higher token quotas. An independent buffer is allocated in the partitioned storage module for each module in the parallel upgrade queue. A time-slicing mechanism is used to allocate write time windows for Flash memory to each module in order to avoid conflicts caused by multiple modules performing write operations on Flash simultaneously. The token bucket algorithm is used to allocate bus bandwidth to each module. High-priority modules are allocated higher token quotas, and the upgrade progress of each module in the parallel upgrade queue is monitored. When the upgrade progress of a low-priority module is found to be lagging behind a preset planned threshold, the bus bandwidth quota of the low-priority module is temporarily increased.
7. The multi-module parallel OTA upgrade method for embedded devices according to claim 6, characterized in that, The steps of controlling each module in the parallel upgrade queue to synchronously extract its own firmware from the OTA upgrade package, write it into its corresponding storage buffer, and complete module-level verification include: Send upgrade instructions to each module in the parallel upgrade queue; In response to the upgrade command, each firmware file is read from the shared upgrade package storage area and written to the independent buffer allocated to each module in the partitioned storage module; After the firmware is written to an independent buffer, the firmware is verified, including checking the matching between the firmware's digital signature and the device hardware ID. After verification, the firmware is written from its respective independent buffer to the running area, and the upgrade completion status is reported.
8. The multi-module parallel OTA upgrade method for embedded devices according to claim 7, characterized in that, After the firmware is written to an independent buffer, the firmware is verified. The verification includes the step of checking the matching between the firmware's digital signature and the device hardware ID. Extract the digital signature certificate attached to the firmware file to be verified; The digital signature certificate is decrypted and verified using a public key pre-installed in the device's secure storage area to confirm the legitimacy of the firmware's origin. After the certificate verification is successful, the list of device hardware IDs authorized by the firmware is parsed from the digital signature certificate; Verify whether the hardware ID of the current device is within the authorized list of device hardware IDs.
9. The multi-module parallel OTA upgrade method for embedded devices according to claim 8, characterized in that, After the device restarts, verify the upgrade results of all modules; when a module upgrade fails, trigger a rollback operation only for the failed module and its dependent modules, including the following steps: After the device restarts, it enters verification mode, where each module performs self-diagnostic operations and reports the results. The self-diagnostic operations include functional testing and version matching checks. Receive the self-diagnostic results of all modules and identify modules that failed to upgrade; When an upgrade fails, a partial rollback operation is performed, including: Based on the constructed directed acyclic graph, determine all associated modules that depend on the upgrade failure module; Control the upgrade failure module and all associated modules to restore the firmware of the previous version from the backup area of the partition storage module and report the failure log to the cloud.
10. A multi-module parallel OTA upgrade system for embedded devices, characterized in that, include: The communication module is used to download OTA upgrade packages from the cloud server; The partitioned storage module includes a shared upgrade package storage area, multiple independent buffers, and a backup area. Each independent buffer corresponds to a functional module to be upgraded. The security verification module is used to perform overall security verification on the OTA upgrade package and to perform module-level verification on the firmware of each module. The OTA coordination module is communicatively connected to the communication module, partition storage module, and security verification module, and is used to parse the module dependencies in the OTA upgrade package. A directed acyclic graph is constructed based on the dependencies; modules without dependencies are identified and added to the parallel upgrade queue according to a preset priority; independent storage buffers and hardware read / write resources are allocated to each module in the parallel upgrade queue; and each module is controlled to synchronously perform firmware writing and verification. Multiple functional modules to be upgraded, each module including an upgrade agent unit, used to respond to the instructions of the OTA coordination module to perform firmware extraction, writing, verification and status reporting; The rollback and recovery module is used to verify the upgrade results of each module after the device restarts, and to trigger a rollback operation only for the failed module and its dependent modules when a module upgrade fails.