Batch wireless remote coordination upgrade method, system, and computer readable medium

Abstract

The application discloses a batch wireless remote coordination upgrading method and system and a computer readable medium. The method dynamically generates a directed acyclic graph and issues task information based on the dependency relationship and firmware version information of a target device group through a cloud coordinator; the target device subscribes to a front-end device state topic, and downloads an upgrade package from the cloud in combination with a front-end success message and a dependency counter value; the cloud coordinator continuously listens to device states and updates the directed acyclic graph, and if device upgrade failure or timeout information is received, the graph is immediately locked and a rollback instruction is issued to the front-end device that has been successfully upgraded, so that the front-end device is restored to a state before the upgrade. The application models the dependency relationship through the directed acyclic graph, clearly defines the upgrade sequence, avoids systematic failure, realizes system-level collaborative rollback, solves the problem of mixed new and old, dynamically adapts the upgrade state, reduces fault propagation, improves the orderliness, reliability and system consistency of batch upgrading, and is suitable for large-scale complex embedded device scenarios.

Description

Technical Field

[0001] This invention relates to the field of remote upgrade technology, and in particular to a batch wireless remote coordinated upgrade method, system, and computer-readable medium. Background Technology

[0002] Currently, there are three main typical implementation methods for wireless remote upgrade technology for embedded devices: (1) Batch upgrade solution based on cloud platform Mainstream IoT platforms create batch tasks in the cloud to distribute firmware to device groups concurrently or on a time-based basis. This approach focuses on task distribution and basic status checks, but lacks awareness of dependencies between devices, making the upgrade order uncontrollable.

[0003] (2) Single-point optimization scheme based on differential / breakpoint resume Differential algorithms reduce the amount of data transmitted, and breakpoint resume improves the transmission efficiency of a single device in weak network conditions. However, this type of technology only optimizes the transmission process between the device and the server, and does not involve the coordination between multiple devices.

[0004] (3) Fault tolerance scheme for devices based on A / B partitioning The device is locally configured with dual partitions, which can automatically roll back in case of upgrade failure, ensuring that a single device does not become unusable. However, this mechanism is limited to single-point self-protection and cannot cope with collaborative failures involving multiple devices on the blockchain.

[0005] While the aforementioned existing technologies have addressed the reliability, bandwidth efficiency, and device security issues of OTA upgrades to some extent, the following core limitations still exist in large-scale, complex embedded device scenarios: 1. Lack of inter-device dependency management can easily lead to system failure. Traditional solutions only support concurrent or simple batch upgrades and cannot handle business logic dependencies between devices (such as gateways and sub-devices, master and slave controllers). When the upgrade order is disordered, it can easily lead to systemic failures such as protocol incompatibility and communication interruptions. This is because they lack the ability to explicitly model the device dependency topology and cannot dynamically orchestrate the upgrade order based on dependencies.

[0006] 2. The rollback mechanism is limited to a single device and cannot achieve system-level recovery. Disadvantages: Local device rollback (such as A / B partitions) can only restore itself. When a device in the dependency chain fails to upgrade, the previously upgraded devices cannot be automatically rolled back, resulting in an inconsistent "mixed old and new" state of the system. The reason is that the failure handling strategy is oriented towards a single point rather than the entire upgrade task, lacks global state monitoring and a task graph execution engine, and cannot trigger a coordinated rollback based on dependencies. Summary of the Invention

[0007] This invention addresses the problems of system paralysis caused by ignoring inter-device dependencies and isolated breakpoint resume and rollback mechanisms in existing large-scale wireless remote upgrades of equipment. It provides a batch wireless remote coordinated upgrade method, system, and computer-readable medium. Through directed acyclic graph modeling and global collaborative control design, it achieves the orderliness, reliability, and system consistency of batch equipment upgrades.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: A batch wireless remote coordinated upgrade method includes: The cloud coordinator dynamically generates a directed acyclic graph based on the dependencies and firmware version information of the target device group; The cloud coordinator sends task information to each target device; The target device subscribes to the status topics of all front-end devices and downloads the upgrade package from the cloud firmware repository manager based on the success messages of the front-end devices and the value of the dependency counter. The cloud coordinator continuously monitors the status reported by all target devices and updates the directed acyclic graph accordingly. If the cloud coordinator receives a failure message or fails to respond within a timeout period from a target device, it locks the directed acyclic graph. The cloud coordinator sends rollback commands to the front-end devices that have been successfully upgraded based on the directed acyclic graph, restoring the upgraded front-end devices to their pre-upgrade state.

[0009] As a further improvement of the present invention, the task information includes: the upgrade package address of the target device itself, a segmented verification list, and a list of front-end devices to be monitored, wherein the list of front-end devices includes all incoming edge nodes of the node corresponding to the target device in the directed acyclic graph.

[0010] As a further improvement of the present invention, the step of the target device subscribing to the status topics of all front-end devices and downloading the upgrade package from the cloud firmware repository manager based on the success messages of the front-end devices and the value of the dependency counter includes: The target device subscribes to the status topics of all front-end devices via MQTT; The dependency counter is decremented by one each time a success message is received from a front-end device. When the dependency counter reaches zero, the target device wakes up automatically and downloads the upgrade package from the cloud firmware repository manager.

[0011] As a further improvement of the present invention, the step of the target device downloading the upgrade package from the cloud firmware repository manager includes: The upgrade package is divided into fixed-size data blocks. For each data block downloaded, the hash value of the data block is calculated and compared with the segment verification list in the cloud firmware repository manager. If it passes the comparison, the next data block is requested to be downloaded. After all data blocks pass the verification by the target device, the target device assembles all data blocks to generate new firmware; The target device writes the new firmware to the backup partition and reboots; The target device reports a success message to the cloud coordinator via MQTT.

[0012] As a further improvement of the present invention, if the verification fails, the target device reports the failure information to the cloud coordinator.

[0013] As a further improvement of the present invention, if the cloud coordinator detects that all the preceding devices of a target device have successfully completed their dependencies, but the target device has not reported starting to download the upgrade package within a set time while continuously monitoring the status reported by all target devices, the cloud coordinator sends a trigger signal to the target device to execute the upgrade process.

[0014] As a further improvement of the present invention, the step of restoring the successfully upgraded front-end device to its state before the upgrade includes: The front-end device performs a rollback using a locally stored partition or backup firmware and reports the rollback status to the cloud coordinator.

[0015] As a further improvement of the present invention, after the step of restoring the successfully upgraded front-end device to its pre-upgrade state, the method further includes: The entire directed acyclic graph task has been marked as failed - rolled back.

[0016] This invention also provides a batch wireless remote coordination upgrade system for implementing the above-mentioned batch wireless remote coordination upgrade method, comprising: The cloud coordinator is used to dynamically generate directed acyclic graphs, and during the upgrade process, it performs global monitoring of the target device group and makes rollback decisions. Cloud-based firmware repository manager, used to generate upgrade packages and create segmented verification lists; A cloud-based device information database is used to store dependency relationships and firmware version information; The MTQQ server, the cloud firmware repository manager, and the cloud coordinator communicate with the target device through the MTQQ server; The device upgrade agent, set on the target device, is used to download upgrade packages from the cloud firmware repository manager and report the status to the cloud coordinator.

[0017] The present invention also provides one or more computer-readable media having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the above-described batch wireless remote coordinated upgrade method.

[0018] The beneficial effects of this invention are as follows: By dynamically modeling the dependency relationships and firmware version information of target device groups using a directed acyclic graph, the sequential logic of device upgrades is clarified, fundamentally solving the problem of uncontrollable upgrade order in traditional solutions. For scenarios with business / physical dependencies, such as between gateways and sub-devices, or between master and slave controllers, it ensures that downstream devices in the dependency chain only initiate upgrades after the upstream devices have been successfully upgraded, effectively avoiding systemic failures such as protocol incompatibility and communication interruptions, and adapting to the upgrade needs of large-scale, complex embedded device scenarios.

[0019] When a target device fails to upgrade or times out and does not respond, the limitations of traditional single-device local rollback are overcome by locking the directed acyclic graph and triggering a collaborative rollback of the front-end devices. Front-end devices that have been successfully upgraded can be restored to their pre-upgrade state, completely resolving the inconsistency problem of "mixed old and new" systems, ensuring the coordinated and unified operation of the entire device group, and significantly improving the system recovery capability after upgrade failure.

[0020] The cloud-based coordinator continuously monitors the status reports from all devices and updates the directed acyclic graph in real time. Combined with the device's subscription mechanism for prerequisite states and dependency counter management, it enables dynamic adaptation of the upgrade process. Devices only download upgrade packages when prerequisite conditions are met, avoiding invalid upgrade attempts. At the same time, global status monitoring promptly detects anomalies and terminates subsequent upgrades, reducing the spread of faults and improving the overall reliability of batch upgrades. Attached Figure Description

[0021] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0022] Figure 1 This is a flowchart of the batch wireless remote coordination upgrade method described in this invention; Figure 2 This is another flowchart of the batch wireless remote coordination upgrade method described in this invention; Figure 3 This is a schematic diagram of the structure of the batch wireless remote coordinated upgrade described in this invention. Detailed Implementation

[0023] To make the technical problems solved by the present invention, the technical solutions adopted, and the technical effects achieved clearer, the technical solutions of the embodiments of the present invention will be further described in detail below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] This invention provides a batch wireless remote coordinated upgrade method, such as... Figure 1 and Figure 2 As shown, it includes: S1. The cloud coordinator dynamically generates a directed acyclic graph (DAG) based on the dependencies and firmware version information of the target device group. Dependencies include physical dependencies and business dependencies, such as device B depending on device A. In the DAG, each node represents a device to be upgraded and its upgrade package information, and each directed edge represents the upgrade dependency order. The upgrade package information includes: a differential package URL and a segmented verification list.

[0025] S2. The cloud coordinator sends task information to each target device. This task information includes: the target device's own upgrade package address, segment verification list address, and a list of preceding devices to be monitored. The preceding device list includes all incoming edge nodes of the node corresponding to the target device in the directed acyclic graph. Upon receiving the task information, the target device's upgrade agent enters a listening and waiting state and maintains a dependency counter in its local storage.

[0026] S3. The target device subscribes to the status topics of all front-end devices and downloads the segmented verification list and upgrade package from the cloud firmware repository manager based on the success messages of the front-end devices and the values ​​of the dependency counters.

[0027] Specifically, the target device subscribes to the status topics of all front-end devices via MQTT; whenever it receives a success message from a front-end device, it decrements the dependency counter by one; when the dependency counter reaches zero, the target device wakes up autonomously, first downloading the segmented verification manifest from the firmware repository manager via the segmented verification manifest address, then dividing the upgrade package into fixed-size data blocks according to the block information in the segmented verification manifest, initiating a segmented download request to the upgrade package address, downloading the upgrade package data block by block, and verifying it in real time: for each data block downloaded, its hash value is calculated and compared with the manifest, and if it passes, the next block is requested; after all blocks pass verification, the new firmware is assembled, written to the backup partition and restarted, and finally a success message is reported.

[0029] In existing technologies, transmission optimization (resuming interrupted transmission) is separated from data integrity verification, which is often performed only after the differential packet has been fully downloaded. If a data block is corrupted during transmission, the entire differential packet must be retransmitted, resulting in low efficiency. The reason for this is the lack of a segmented verification mechanism for the differential upgrade packet, which makes it impossible to perform atomic verification on each data block during the resuming process, leading to a disconnect between transmission and verification.

[0030] To address the aforementioned shortcomings, in one embodiment of the present invention, a breakpoint download and segmented verification mechanism is employed during the download of the upgrade package from the cloud firmware repository manager.

[0031] Specifically, after the target device wakes up autonomously, it first downloads the segmented verification list from the firmware repository manager via the segmented verification list address. Then, it divides the upgrade package into fixed-size data blocks according to the list. For each data block downloaded, it calculates the hash value of the data block and compares it with the segmented verification list in the cloud firmware repository manager. If the comparison is successful, it requests to download the next data block. After all data blocks have been verified by the target device, the target device assembles all data blocks to generate new firmware. The target device writes the new firmware to the backup partition and reboots. The target device then reports a success message to the cloud coordinator via MQTT.

[0032] The above steps deeply couple resuming interrupted downloads with the integrity verification of the differential upgrade package. The firmware repository manager pre-generates a segmented verification list for the differential upgrade package (offset, length, and hash value of each data block). During the download process, the device immediately calculates the hash value of each data block after it is received and compares it with the list. Only after the current block passes verification can the next block be requested. The download process can be interrupted at any time and resumed at the breakpoint, and each resumed data block must pass an atomicity check.

[0033] If the verification fails, the target device reports the failure information to the cloud coordinator. It should be noted that verification failure is only one of the reasons for reporting failure information. Other reasons for reporting failure information may include: HTTP download timeout during the download phase, network interruption exceeding the threshold, etc.; Flash write errors, partition switching failure, new firmware startup timeout, etc. during the upgrade process.

[0034] S4, the cloud coordinator continuously listens to the status reported by all target devices and updates the directed acyclic graph.

[0035] While continuously monitoring the status reports from all target devices, the cloud coordinator detects that all dependencies of a target device have been successfully completed, but the target device fails to report starting the download of the upgrade package within the set time. The reason for this failure might be due to missed network messages. In this case, the cloud coordinator sends a trigger signal to the target device to execute the upgrade process, ensuring the upgrade process does not stall. This step does not interfere with the target device's autonomous wake-up path and is only used for error recovery. The set time can be configured by the cloud coordinator, for example, it can be configured to 30 minutes.

[0036] The cloud coordinator continuously monitors the status reported by all target devices, including: downloading, downloaded, upgrading, and successful / failed upgrade. If the cloud coordinator does not detect a "downloading" status on a target device within a set time, it infers that the target device has not reported starting to download the upgrade package.

[0037] S5. If the cloud coordinator receives a failure message from a target device or fails to respond within a timeout period, it locks the directed acyclic graph and suspends subsequent node scheduling.

[0038] S6, the cloud coordinator sends rollback commands to the front-end devices that have been successfully upgraded based on the directed acyclic graph, and the front-end devices that have been successfully upgraded are restored to their state before the upgrade.

[0039] Through steps S5 and S6 above, this invention establishes a closed-loop global state monitoring and feedback control system. The cloud coordinator continuously monitors the upgrade status of all devices. When it detects that an upgrade failure has occurred at a node in the directed acyclic graph (DAG), it immediately suspends the execution of the entire DAG. The system does not simply record the failure; instead, it proactively backtracks dependencies, calculates the smallest affected rollback subgraph, and issues atomic rollback commands to all successfully upgraded devices in that subgraph. Upon receiving the command, the device executes the rollback operation using its local A / B partition or backup firmware and reports the result.

[0040] Specifically, the cloud coordinator traces back the affected dependency chains based on the directed acyclic graph and issues rollback instructions to the front-end devices that have already been successfully upgraded. The front-end devices use the partitions or backup firmware stored locally to perform the rollback and report the rollback status to the cloud coordinator, ultimately restoring the entire target device group to a consistent state before the upgrade.

[0041] S7. Mark the entire Directed Acyclic Graph task as failed - rolled back.

[0042] The invention will now be described in conjunction with specific application scenarios, as follows: The scenario is as follows: An automated production line in a smart factory contains three types of key equipment: one main control PLC (equipment A), two vision sensors (equipment B1 and equipment B2), and one robotic arm controller (equipment C). There are strict upgrade dependencies between them. The vision sensors (device B1 and device B2) rely on the new version of the communication protocol of the main control PLC (device A), so they must wait for device A to be successfully upgraded before they can be upgraded.

[0043] The robotic arm controller (device C) relies on the recognition result data format of the vision sensors (devices B1 and B2), so it must wait for both B1 and B2 to be successfully upgraded before it can be upgraded.

[0044] A directed acyclic graph is: device A → device B1, device B2 → device C.

[0045] Current firmware versions: Device A v1.0, Device B1 v2.0, Device B2 v2.0, Device C v3.0. All devices need to be upgraded to the new version (Device A v1.1, Device B1 v2.1, Device B2 v2.1, C v3.1). The upgrade packages for Devices B1 and B2 are differential packages (10MB in size) based on v2.0 to v2.1.

[0046] Example of normal process: Initialization Phase: Operations personnel select these four devices on the cloud coordinator interface and click "Create Dependency Upgrade Task". The cloud coordinator reads the preset dependency relationships from the cloud device information database and generates a directed acyclic graph. The cloud firmware repository manager generates upgrade packages for devices B1 and B2 and creates a segmented verification list (e.g., dividing a 10MB differential packet into 160 64KB data blocks, each with an accompanying SHA256 value).

[0047] Task distribution phase: The cloud coordinator distributes the trimmed task information to each device A, device B1, device B2, and device C via MQTT.

[0048] Execution phase: Device A: Since there are no dependencies, it immediately begins downloading the full firmware, upgrades and restarts after successful verification. It then publishes its status via MQTT: / ota / status / upstream / deviceA→{"result":"success"}.

[0049] Device B1: Continuously subscribes to and listens to the ` / ota / status / upstream / deviceA` topic. Upon receiving a success message from Device A, its upgrade agent is awakened and begins requesting the download of the differential package from the cloud firmware repository manager. The download uses a resume-from-break and segmented verification method: Requesting the first 64KB data block, after downloading, calculating the SHA256, and comparing it with the segmented verification list in the cloud firmware repository manager; continuing to request the second block... Assuming the network is interrupted when downloading the 50th block, after recovery, Device B1 resumes downloading from the 50th block, without starting from the beginning. After all 160 blocks are downloaded and verified, Device B1 combines the local old firmware v2.0 to generate the new firmware v2.1, writes it to the spare partition, verifies it, switches the partition, and reboots. Upon completion, the release status is: ` / ota / status / upstream / deviceB1 → {"result":"success"}`.

[0050] Device B2: Performs the same process in parallel with Device B1, and publishes its status upon success.

[0051] Device C: Continuously monitors the status topics of Device B1 and Device B2. Upon receiving a message that both Device B1 and Device B2 have succeeded (confirmed via locally maintained dependency counters), it initiates its own upgrade process.

[0052] Completion Phase: After device C successfully upgrades, it publishes its status. Upon receiving this, the coordinator marks the entire directed acyclic graph task as "completed." It displays "4 / 4 nodes succeeded."

[0053] Example of fault recovery process: In the above process, suppose that device B1 fails to pass the verification of the 100th block of the differential packet multiple times (for example, due to data corruption caused by network interruption) and cannot pass the verification of the block.

[0054] Failure reporting: After the retry mechanism of device B1 is exhausted, the upgrade is determined to have failed. The status is published via MQTT: / ota / status / upstream / deviceB1→{"result":"fail", "reason":"chunk_100_checksum_error"}.

[0055] Cloud coordinator monitoring and decision-making: When the cloud coordinator detects a failure message for device B1, it immediately marks the device B1 node in the directed acyclic graph as "failed". At this time, device C, which depends on device B1, has not yet started its upgrade and is still in the listening state, while device A, the predecessor of device B1, has already been successfully upgraded.

[0056] Triggering Rollback: Based on the preset strategy of rolling back the entire failed subgraph, the cloud coordinator decides to include the successfully upgraded device A in the rollback scope to ensure system consistency (because the new protocol of device A may not be compatible with the older version of the un-upgraded B1). The cloud coordinator sends a rollback command to device A via MQTT: / ota / command / deviceA→{"command":"rollback", "targetVersion":"v1.0"}.

[0057] Device rollback execution: After receiving the instruction, the upgrade agent of device A uses the local A / B partition mechanism (the old version v1.0 is still on another partition) to immediately switch back to the old partition and reboot. After completion, device A releases the status: / ota / status / upstream / deviceA→{"result":"rollback_success", "version":"v1.0"}.

[0058] System Consistency Restoration: After receiving the rollback success message from device A, the coordinator marks the entire directed acyclic graph task as "Failed - Rolled Back". At this point, all devices on the production line (device A, device B1, device B2, device C) are restored to their stable versions before the upgrade (v1.0, v2.0, v2.0, v3.0), maintaining normal functionality and avoiding the risk of production line paralysis due to a single point of failure in device B1. Maintenance personnel can view the specific failure and rollback logs on the monitoring interface for further investigation.

[0059] The core concept of this invention's batch wireless remote coordinated upgrade method lies in: constructing a directed acyclic graph (DAG) in the cloud to describe the upgrade dependencies between devices, transforming batch upgrade tasks from concurrent commands into a graph-like workflow; during the upgrade process, the upgrade status of each target device is monitored in real time through the long-connection characteristics of the MQTT protocol, and a breakpoint resumption mechanism based on segmented verification is introduced; the cloud-based upgrade coordinator acts as the decision-making core, dynamically driving subsequent tasks based on the state changes of nodes in the DAG, and automatically triggering a rollback of the reverse dependency on related upgraded devices when a critical node in the dependency chain fails. This invention achieves system-level correctness and consistency for wireless remote upgrades in large-scale complex device scenarios by integrating dependency topology graphs, state monitoring, and atomicity verification.

[0060] This invention also provides a batch wireless remote coordination upgrade system for implementing the above-described batch wireless remote coordination upgrade method, such as... Figure 3 As shown, it includes: a cloud coordination layer, a network transmission layer, and a device execution layer, wherein the cloud coordination layer is deployed in the cloud, and the device execution layer is deployed on the device.

[0061] The cloud coordination layer includes: cloud coordinator, cloud firmware repository manager, and cloud device information database; the network transport layer includes: MQTT server; and the device execution layer includes: device upgrade agent and local storage.

[0062] The cloud coordinator dynamically generates a directed acyclic graph (DAG). During the upgrade process, it globally monitors the target device group and makes rollback decisions. The cloud coordinator interacts with the cloud firmware repository manager, the cloud device information database, and the device upgrade agent via MQTT. The cloud firmware repository manager generates upgrade packages, creates segmented verification lists, and stores and distributes firmware. It responds to download requests from target devices and provides metadata to the cloud firmware repository manager. The cloud device information database stores dependencies, firmware version information, and online status, providing data support for the cloud coordinator to dynamically generate the DAG. The cloud firmware repository manager and the cloud coordinator communicate with the target devices through the MTQQ server. The device upgrade agent is located on the target device and downloads upgrade packages from the cloud firmware repository manager to perform local upgrades, including dependency monitoring, segmented download verification, and rollback. It also reports its status to the cloud coordinator via MQTT. Local storage manages firmware partitions and maintains breakpoint information for the target device upgrade agent to read and write.

[0063] This solution has low requirements for the hardware platform and focuses mainly on the software implementation, thus having good compatibility.

[0064] Basic capabilities: The device needs network connectivity (supporting the TCP / IP protocol stack to run MQTT and HTTP clients) and sufficient non-volatile storage (Flash) to support dual-partition (A / B) or backup partition mechanisms to store the currently running firmware and newly downloaded firmware, which is the foundation for local rollback. Storage space requirements depend on the firmware size, and typically need to accommodate at least two full firmware versions (if differential upgrades are used, the temporary space requirement for each download can be reduced).

[0065] Compatibility: This solution is fully compatible with existing mass-produced devices, provided that these devices already possess the aforementioned basic hardware capabilities (such as most IoT devices that support wireless remote upgrades). If the existing device has only one firmware partition and no backup space, it cannot support hardware-level local fast rollback. However, the dependency scheduling, breakpoint resume, and segmented verification functions in this solution will still be effective. Rollback may require re-downloading the old firmware (which takes longer).

[0066] Device-side modifications: The core modification to this solution lies in the device-side software, requiring the integration or development of a device upgrade agent module. This module is responsible for MQTT communication, directed acyclic graph task parsing, dependency monitoring, segmented download and verification, local upgrade triggering, and rollback execution. This functionality can be pre-deployed on existing devices via firmware upgrades. In other words, the device can first obtain this agent module through a regular wireless remote upgrade, and then participate in the dependency upgrades described in this invention.

[0067] Cloud-based modifications: This requires adding or enhancing the cloud-based upgrade coordinator service on top of the existing IoT platform, including modules such as a directed acyclic graph engine, state machine management, and rollback decision logic. This falls under the category of cloud server-side software development and deployment, and does not involve hardware changes.

[0068] Protocol standards: All communication is based on the standard MQTT 3.1.1 or 5.0 protocol and HTTP / HTTPS protocol, without the need for customized hardware communication modules, ensuring the universality and portability of the solution.

[0069] This invention primarily focuses on software upgrades, while its hardware requirements are standard for mainstream IoT devices in the industry (dual-partition Flash + network connectivity). Therefore, it is feasible to smoothly deploy and promote it on existing mass-produced devices. For devices with extremely limited hardware resources and no backup partitions, most of the core functions of this solution can be adapted through downgrade support (such as disabling hardware rollback).

[0070] In summary, this invention differs from traditional batch upgrades that employ concurrent or simple polling strategies. Its core lies in introducing a Directed Acyclic Graph (DAG) to explicitly model the upgrade dependencies between devices. During the upgrade task initialization phase, the cloud coordinator dynamically generates the DAG based on the devices' physical network relationships or business logic dependencies. During the upgrade process, the coordinator strictly adheres to the topological order of the DAG, allowing a device to initiate its upgrade process only after all its preceding dependent devices have been successfully upgraded. The device side monitors the status of dependent devices in real time via an MQTT subscription mechanism, achieving decentralized conditional triggering.

[0071] This invention fundamentally solves the problem of system-level functional paralysis caused by disordered upgrade sequence in large-scale complex systems. By transforming disordered concurrent upgrades into an ordered graph-like workflow, it ensures the logical consistency and functional continuity of the entire system during the upgrade process. For example, in industrial control scenarios, it guarantees that the controller is always upgraded only after the sensor upgrade is completed, avoiding communication interruptions caused by protocol incompatibility.

[0072] The system-level accuracy of the upgrade process in this invention has been improved from an uncontrollable state dependent on manual intervention to 100% adherence to preset business logic, completely eliminating the risk of production stoppages caused by sequence errors. This achieves a shift from "manual sequencing" to "automatic system scheduling," reducing the operational complexity of large-scale equipment upgrades.

[0073] This invention integrates three major mechanisms—directed acyclic graph dependency scheduling, segmented atomic transmission, and global cooperative rollback—to bring significant overall technological advancements to the wireless remote upgrade of large-scale embedded devices. (1) Leap in system robustness: It fundamentally eliminates the risk of systemic failure caused by disordered upgrade order, and realizes a qualitative change from batch operation to systematic collaboration.

[0074] (2) Sharp reduction in operation and maintenance costs: Full-process automated orchestration and self-healing reduce the manpower input in large-scale upgrade scenarios to a fraction of the traditional solution, while eliminating the risk of human error.

[0075] (3) Efficient use of resources: Differential transmission combined with segmented breakpoint resume significantly reduces invalid data transmission in weak network environments, greatly improves the upgrade success rate, and has low memory usage to adapt to resource-constrained devices.

[0076] (4) Flexible and agile deployment: Supports dynamic construction of dependency graphs, providing a secure and reliable technical foundation for the iteration of IoT applications.

[0077] The present invention also provides one or more computer-readable media having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the batch wireless remote coordinated upgrade method as described above.

[0078] Optionally, the computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), solid-state drive (SSD), or optical disc, etc.

[0079] Random access memory can include resistive random access memory (ReRAM) and dynamic random access memory (DRAM).

[0080] In this description, references to terms such as "an embodiment," "example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example.

[0081] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style of the specification is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

[0082] The technical principles of the present invention have been described above with reference to specific embodiments. These descriptions are merely for explaining the principles of the invention and should not be construed as limiting the scope of protection of the invention in any way. Based on this explanation, those skilled in the art can readily conceive of other specific embodiments of the invention without inventive effort, and these embodiments will all fall within the scope of protection of the present invention.

Claims

1. A batch wireless remote coordination upgrade method, characterized in that, include: The cloud coordinator dynamically generates a directed acyclic graph based on the dependencies and firmware version information of the target device group; The cloud coordinator sends task information to each target device; The target device subscribes to the status topics of all front-end devices and downloads the upgrade package from the cloud firmware repository manager based on the success messages of the front-end devices and the value of the dependency counter. The cloud coordinator continuously monitors the status reported by all target devices and updates the directed acyclic graph accordingly. If the cloud coordinator receives a failure message or fails to respond within a timeout period from a target device, it locks the directed acyclic graph. The cloud coordinator sends rollback commands to the front-end devices that have been successfully upgraded based on the directed acyclic graph, restoring the upgraded front-end devices to their pre-upgrade state.

2. The batch wireless remote coordination upgrade method according to claim 1, characterized in that, The task information includes: the target device's own upgrade package address, a segmented verification list, and a list of front-end devices to be monitored. The front-end device list includes all incoming edge nodes of the node corresponding to the target device in the directed acyclic graph.

3. The batch wireless remote coordination upgrade method according to claim 1, characterized in that, The steps for the target device to subscribe to the status topics of all front-end devices and download the upgrade package from the cloud firmware repository manager based on the success messages and dependency counter values ​​of the front-end devices include: The target device subscribes to the status topics of all front-end devices via MQTT; The dependency counter is decremented by one each time a success message is received from a front-end device. When the dependency counter reaches zero, the target device wakes up automatically and downloads the upgrade package from the cloud firmware repository manager.

4. The batch wireless remote coordination upgrade method according to claim 2 or 3, characterized in that, The steps for the target device to download the upgrade package from the cloud firmware repository manager include: The upgrade package is divided into fixed-size data blocks. For each data block downloaded, the hash value of the data block is calculated and compared with the segment verification list in the cloud firmware repository manager. If it passes the comparison, the next data block is requested to be downloaded. After all data blocks pass the verification by the target device, the target device assembles all data blocks to generate new firmware; The target device writes the new firmware to the backup partition and reboots; The target device reports a success message to the cloud coordinator via MQTT.

5. The batch wireless remote coordination upgrade method according to claim 4, characterized in that, If the verification fails, the target device reports the failure information to the cloud coordinator.

6. The batch wireless remote coordination upgrade method according to claim 1, characterized in that, While continuously monitoring the status reported by all target devices, if the cloud coordinator detects that all the dependencies of the preceding devices in front of a target device have been successfully completed, but the target device has not reported to start downloading the upgrade package within the set time, the cloud coordinator sends a trigger signal to the target device to execute the upgrade process.

7. The batch wireless remote coordination upgrade method according to claim 1, characterized in that, The steps for restoring the successfully upgraded front-end device to its pre-upgrade state include: The front-end device performs a rollback using a locally stored partition or backup firmware and reports the rollback status to the cloud coordinator.

8. The batch wireless remote coordination upgrade method according to claim 1, characterized in that, After the step of restoring the successfully upgraded front-end device to its pre-upgrade state, the following is also included: The entire directed acyclic graph task has been marked as failed - rolled back.

9. A batch wireless remote coordination and upgrade system, characterized in that, A method for implementing the batch wireless remote coordinated upgrade method as described in any one of claims 1 to 8, comprising: The cloud coordinator is used to dynamically generate directed acyclic graphs, and during the upgrade process, it performs global monitoring of the target device group and makes rollback decisions. Cloud-based firmware repository manager, used to generate upgrade packages and create segmented verification lists; A cloud-based device information database is used to store dependency relationships and firmware version information; The MTQQ server, the cloud firmware repository manager, and the cloud coordinator communicate with the target device through the MTQQ server; The device upgrade agent, set on the target device, is used to download upgrade packages from the cloud firmware repository manager and report the status to the cloud coordinator.

10. One or more computer-readable media, characterized in that, It stores instructions that, when executed by one or more processors, cause the processors to perform the bulk wireless remote coordinated upgrade method as described in any one of claims 1-8.

Images