OTA upgrading method and system for controller and multi-module embedded system

Abstract

The invention discloses a controller and multi-module embedded system OTA upgrading method and system, and relates to the technical field of OTA upgrading. In order to solve the defects of low OTA upgrading efficiency, poor fault tolerance and complex operation of a multi-module system in the prior art, a controller separates an upgrading sub-package according to a received upgrading instruction and a received upgrading package; dividing the data into a plurality of data blocks; the module to be upgraded carries out splicing, verification and storage on the received data blocks, and retransmits abnormal data blocks; the controller preferentially upgrades own firmware and restarts self-inspection; upgrading after the self-inspection is passed; and the controller gathers all signals passing the self-inspection and feeds back an upgrading success signal to the external terminal. The OTA upgrading method and device are mainly used for conducting OTA upgrading on the controller and the module.

Description

Technical Field

[0001] This invention relates to the field of OTA upgrade technology, and in particular to an OTA upgrade method and system for a controller and a multi-module embedded system. Background Technology

[0002] With the continuous improvement of the intelligence of electronic devices, OTA (Over-the-Air Technology) upgrades have become an important means of firmware updates and function iterations. In distributed control systems consisting of a controller and multiple modules, such as a system with one controller and 20 modules, where the controller connects to the external network via an RJ45 interface and the controller communicates with each module via fiber optic cable in a star topology, the need for OTA upgrades in such systems is becoming increasingly urgent.

[0003] Existing OTA upgrade solutions for multi-module systems have several shortcomings: First, they are inefficient, mostly using a module-by-module upgrade approach, which takes too long for a system with 20 modules and cannot meet the needs of batch upgrades. Second, they have poor fault tolerance; if a module experiences communication interruption or unstable power supply during the upgrade process, it is prone to upgrade failure, and there is a lack of effective recovery mechanisms after failure, which may cause module firmware damage or functional abnormalities. Third, they are highly complex to operate, requiring technicians to configure parameters for the controller and each module separately, making the operation process cumbersome and prone to upgrade failures due to human error.

[0004] Therefore, there is a need for a controller and a multi-module system OTA upgrade method and system that can be upgraded in batches, has a fast upgrade speed, high fault tolerance, and is easy to operate. Summary of the Invention

[0005] This invention addresses the shortcomings of existing technologies, such as low efficiency, poor fault tolerance, and complex operation in OTA upgrades of multi-module systems. It provides a controller, OTA upgrade method, and system for multi-module systems that enable batch upgrades, have fast upgrade speeds, high fault tolerance, and are easy to operate.

[0006] The OTA upgrade method for a controller and a multi-module embedded system according to the present invention includes the following steps: S1, Upgrade Preparation Phase; The controller performs integrity verification and parsing on the upgrade instructions and upgrade packages received from external terminals, and separates the upgrade sub-packages; The controller broadcasts a model query command to all modules and filters the list of modules to be upgraded based on the feedback. S2, Batch pre-transmission stage; The controller establishes a parallel communication link with all modules to be upgraded and divides the upgrade sub-packet corresponding to the module to be upgraded into multiple data blocks; The data blocks are then transmitted in batches to each module to be upgraded. The module to be upgraded splices, verifies, and stores the received data blocks, and regenerates upgrade sub-packages and stores them in a temporary storage area. And retransmit the abnormal data blocks; S3, Tiered Upgrade Implementation Phase; The controller prioritizes upgrading its own firmware and then restarts for self-testing. After the controller passes the self-test, the controller sends a synchronous upgrade command to the modules to be upgraded; each module to be upgraded calls the upgrade sub-package in the temporary storage area to perform the upgrade. S4, Fault Tolerance Recovery and Verification Phase; The controller monitors the upgrade status of each module to be upgraded in real time. When an upgrade fails, the controller sends an interrupt command to the current module, rolls the current module back to the original firmware version, and records the reason for the failure. The controller executes a differentiated recovery strategy for the modules that failed the upgrade based on the cause of failure, until all modules pass the self-test; The controller aggregates all signals that pass the self-test and sends a successful upgrade signal to the external terminal.

[0007] Further: In S1, the specific process of the integrity verification is as follows: The MD5 algorithm is used to calculate the checksum of the upgrade package and compare it with the checksum sent by the external terminal. If they match, the checksum passes. After the checksum passes, the upgrade package is parsed, the controller upgrade sub-package and the module upgrade sub-package are separated, and the corresponding adaptation version number of the module upgrade sub-package is extracted. The controller broadcasts a model query command to all modules, and each module sends its own version information back to the controller. The controller then filters and determines the list of modules to be upgraded based on the feedback.

[0008] Furthermore: In S2, the segmentation of the upgrade sub-package specifically includes: The upgrade sub-packet is divided into multiple data blocks, and a sequence number and a checksum are added to each data block. The controller transmits the data blocks in batches to the modules to be upgraded through a parallel communication link. After receiving the data blocks, each module to be upgraded concatenates the data blocks according to the sequence number, verifies the integrity through the checksum, stores them in a temporary storage area after successful verification, and feeds back the receiving status information of each module to be upgraded to the controller.

[0009] Furthermore, in S2, the specific process of retransmitting the abnormal data block includes: When a module to be upgraded fails to receive data, the controller queries for missing or failed data blocks and retransmits the missing or failed data blocks to the current module until all modules to be upgraded report successful reception of the module upgrade sub-packet.

[0010] Furthermore: In S3, priorities are set for the controller upgrade subpackage and the module upgrade subpackage, so that the priority of the controller upgrade subpackage is higher than that of the module upgrade subpackage, thereby prioritizing the execution of the controller's own upgrade process, calling the controller upgrade subpackage to upgrade its own firmware, restarting and performing a self-test after the upgrade is completed, and sending a signal that the controller upgrade is complete to the external terminal after the self-test passes. After the controller passes the self-test, it sends a synchronous upgrade command to all modules in the list of modules to be upgraded. After receiving the command, each module to be upgraded calls the module upgrade sub-package in the temporary storage area to perform firmware upgrade. During the upgrade process, each module reports the upgrade progress and status information to the controller in real time.

[0011] Furthermore: In S4, the differentiated recovery strategy specifically includes: The reasons for upgrade failure include communication interruption, data verification failure, and firmware compatibility issues. The controller executes different recovery strategies based on different failure reasons. If the failure is due to communication interruption, monitor the communication status and retransmit the module upgrade sub-packet after communication is restored. If the failure is due to data verification failure, the corresponding abnormal data block will be retransmitted. If the failure is due to firmware incompatibility, the compatibility issue will be reported to the external terminal and the module upgrade will be terminated.

[0012] Furthermore: when the controller receives a pause command from an external terminal, the controller and each module pause the upgrade process and save the current upgrade progress; when the controller receives a resume command from an external terminal, the controller and each module continue to execute the upgrade process from the paused progress.

[0013] The upgrade system described in this invention for implementing the OTA upgrade method for a controller and a multi-module embedded system includes a controller and N modules, wherein N ≥ 2. The controller is used to receive control commands from external terminals and to send status information back to the external terminals. The controller is equipped with a control system for enabling OTA upgrades of the controller and the module to be upgraded. The module is equipped with an upgrade system, which is used to upgrade itself according to the upgrade instructions of the controller and feed back the status information to the controller.

[0014] Furthermore, the control system includes an upgrade package processing module, a communication management module, an upgrade control module, a fault-tolerant recovery module, and a verification module; The upgrade package processing module is used to receive upgrade packages and perform integrity verification and parsing, and separate controller upgrade sub-packages and module upgrade sub-packages. The communication management module is used to communicate with external terminals and establish parallel communication links with each module to realize data transmission and status feedback. The upgrade control module is used to control its own firmware upgrade process, send upgrade commands to each module and synchronize upgrade signals, and monitor the upgrade progress. The fault-tolerant recovery module is used to detect whether there is an upgrade anomaly in the module, and to control the firmware rollback of the module that fails to upgrade, and to execute a differentiated recovery strategy according to the reason for failure. The verification module is used to send verification instructions to each module after the upgrade is completed, summarize the verification results and feed them back to the external terminal.

[0015] Furthermore: the upgrade system includes a communication receiving module, a data storage module, an upgrade execution module, and a self-testing module; The communication receiving module is used to communicate with the controller, receive the controller's upgrade instructions, upgrade data blocks and control instructions, and provide feedback on its own model, receiving status, upgrade progress and results. The data storage module includes a temporary storage area for storing received upgrade sub-packet data blocks and firmware backups before the upgrade. The upgrade execution module is used to execute the firmware upgrade process according to the upgrade instruction, and to execute firmware rollback after receiving an interrupt instruction. The self-test module is used to perform a self-test on the integrity and functionality of the firmware after the upgrade is completed, and to report the self-test results to the controller.

[0016] The beneficial effects of this invention are: The OTA upgrade method and system disclosed in this invention is a system consisting of a controller and multiple modules, and is suitable for scenarios in which the controller and modules are connected in a fiber optic star topology.

[0017] Compared with the prior art, the present invention has the following advantages: Batch rapid upgrade: The controller uses Fibre Channel to establish parallel communication links with each module, realizing batch transmission of upgrade sub-packets. The time to upgrade one module is the same as the time to upgrade multiple modules. Compared with the traditional method of upgrading one by one, the upgrade efficiency is improved by more than N times (N is the number of modules). At the same time, a data block segmentation and verification retransmission mechanism is adopted to retransmit only abnormal data blocks, avoiding the retransmission of the entire packet, further improving the upgrade speed.

[0018] High fault tolerance: A robust fault recovery mechanism is in place, which can automatically roll back to the original firmware version when the upgrade fails, avoiding module damage; differentiated recovery strategies are formulated for different reasons for failure, such as retransmission after communication interruption and precise retransmission after data error, which greatly reduces the upgrade failure rate; at the same time, upgrade pause and resume are supported to improve upgrade reliability in complex environments.

[0019] Simple to operate: Only one upgrade command and upgrade package need to be sent to the controller through an external terminal. The controller automatically completes the upgrade package parsing, module matching, batch transmission and upgrade control processes. There is no need to operate each module individually, which simplifies the operation steps and reduces the risk of human error.

[0020] High system availability: The system adopts a tiered upgrade strategy that prioritizes controller upgrades and then synchronizes module upgrades. The controller is upgraded and restarted before the module upgrades are initiated, thus avoiding system-wide paralysis during the upgrade process. The module upgrade process provides real-time status feedback, facilitating real-time monitoring and intervention by operators. Attached Figure Description

[0021] Figure 1 It is a system architecture diagram; Figure 2 This is a flowchart of the controller upgrade process; Figure 3 This is a flowchart of the module upgrade process. Detailed Implementation

[0022] The following are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. The embodiments described below are only for explaining the present invention and should not be construed as limiting the present invention. The scope of protection of the present invention should be determined by the scope of the claims. The embodiments of the present invention are described in detail below. In order to facilitate the description of the present invention and simplify the description, the technical terms used in the specification of the present invention should be interpreted broadly, including but not limited to conventional alternatives not mentioned in this application, and including both direct and indirect implementation methods.

[0023] Example 1 Combination Figure 1 and Figure 2 This embodiment describes an OTA upgrade method for a controller and a multi-module system. The system includes one controller and N modules, where N ≥ 2. The controller has an Ethernet RJ45 interface, and the controller and each module are connected in a star topology via optical fiber. The system structure diagram is as follows: The method includes the following steps: 1. Upgrade preparation phase: The external terminal establishes a communication connection with the controller via the RJ45 interface and sends upgrade commands and upgrade packages to the controller. After receiving the upgrade commands and upgrade packages, the controller performs integrity verification on the upgrade packages. If the verification passes, it parses the upgrade packages to obtain the controller upgrade sub-package and module upgrade sub-package, and extracts the corresponding adapter module model information for the module upgrade sub-package. The controller broadcasts a model query command to all modules through a fiber optic star network. After receiving the command, each module sends its own model information back to the controller. The controller matches the returned module models according to the adapter module model information, filters out the modules to be upgraded, establishes a list of modules to be upgraded, and sends it back to the external terminal, completing the upgrade preparation.

[0024] The controller performs integrity verification on the upgrade package by using the MD5 encryption algorithm to calculate the verification value of the upgrade package and comparing it with the verification value of the upgrade package sent by the external terminal. If they match, the verification passes.

[0025] Batch pre-transmission phase: The controller uses a fiber optic channel to establish a parallel communication link with all modules to be upgraded. The controller divides the module upgrade sub-packet into multiple data blocks, adding a sequence number and a checksum to each data block. The controller transmits the data blocks of the module upgrade sub-packet in batches to each module to be upgraded through the parallel communication link. After receiving the data blocks, each module to be upgraded concatenates them according to the sequence number and verifies the integrity of the data blocks through the checksum. After successful verification, the data blocks are stored in a temporary storage area, and the controller is notified of the reception status. If the controller receives feedback indicating that a data block is lost or corrupted, it retransmits only the abnormal data block until all modules to be upgraded have received the module upgrade sub-packet completely.

[0026] The fiber optic interface of the fiber channel is connected one-to-one to the module. In the logic control of the controller, multiple parallel processes are established, and each process controls each module to be upgraded, which can realize multi-channel parallel data transmission.

[0027] Tiered upgrade implementation phase: The controller prioritizes its own upgrade process, calling the controller upgrade subpackage to upgrade its own firmware. After the upgrade is completed, it restarts and performs a self-test. After the self-test passes, it sends a controller upgrade completion signal to the external terminal. After the controller passes the self-test, it sends a synchronous upgrade command to all modules in the list of modules to be upgraded. After receiving the command, each module to be upgraded calls the module upgrade subpackage in the temporary storage area to upgrade its firmware. During the upgrade process, each module provides real-time feedback on the upgrade progress and status information to the controller.

[0028] Fault recovery and verification phase: The controller monitors the upgrade status of each module in real time. If an upgrade failure is detected, an interrupt command is immediately sent to that module to roll back to the firmware version before the upgrade, and the reason for the failure is recorded. For modules that fail to upgrade, the controller automatically selects to retransmit the upgrade sub-packet or adjust the communication parameters and re-execute the upgrade process based on the reason for the failure. After all modules have been upgraded, the controller sends a verification command to each module. Each module performs integrity and functionality verification on the upgraded firmware. After passing the verification, it sends a verification pass signal to the controller. The controller summarizes the verification results of all modules. If all modules pass, it sends an upgrade success signal to the external terminal. If there are any unqualified modules, it provides feedback on the unqualified module information and the reason for the failure.

[0029] The reasons for upgrade failure include communication interruption, data verification failure, and firmware compatibility anomaly. The controller executes different recovery strategies according to different reasons for failure: if it is a communication interruption, the module upgrade sub-packet is retransmitted after communication is restored; if it is a data verification failure, the corresponding abnormal data block is retransmitted; if it is a firmware compatibility anomaly, the compatibility problem is reported to the external terminal and the module upgrade is terminated.

[0030] In addition, it also includes upgrade pause and resume functions: the external terminal can send a pause command to all modules to be upgraded through the controller, the controller and each module pause the upgrade process and save the current upgrade progress; when it is necessary to resume the upgrade, the external terminal sends a resume command, and the controller and each module continue to execute the upgrade process from the paused progress.

[0031] Example 2 This embodiment, described in conjunction with Example 1, discloses an OTA upgrade system for a controller and multi-module system, used to implement the above-described upgrade method. The system includes an external terminal, a controller, and N modules, where N ≥ 2. External terminal: Used to send upgrade commands, upgrade packages, and control commands such as pause and resume to the controller, and to receive information such as upgrade preparation status, upgrade progress, and upgrade results from the controller; Controller: It is equipped with an RJ45 interface and N fiber optic interfaces. The RJ45 interface is used for communication with external terminals, and the N fiber optic interfaces are connected to N modules through optical fibers to form a star topology. The controller internally includes an upgrade package processing module, a communication management module, an upgrade control module, a fault tolerance and recovery module, and a verification module. Upgrade package processing module: Used to receive upgrade packages and perform integrity verification and parsing, separating controller upgrade sub-packages and module upgrade sub-packages; Communication management module: Used to communicate with external terminals via RJ45 interface, and establishes parallel communication links with each module using fiber optic channel to realize data transmission and status feedback; Upgrade control module: Used to control its own firmware upgrade process, send upgrade commands to each module, synchronize upgrade signals, and monitor upgrade progress; Fault-tolerant recovery module: Used to detect upgrade anomalies, control the firmware rollback of modules that fail to upgrade, and execute recovery strategies based on the cause of failure; Verification module: Used to send verification commands to each module after the upgrade is completed, summarize the verification results and feed them back to the external terminal.

[0032] Module: Internally includes a communication receiving module, a data storage module, an upgrade execution module, and a self-test module; Communication receiving module: Used to communicate with the controller via optical fiber, receive upgrade instructions, upgrade data blocks and control instructions, and provide feedback on its own model, receiving status, upgrade progress and results; Data storage module: It has a temporary storage area for storing received upgrade sub-packet data blocks and firmware backups before the upgrade; Upgrade execution module: Used to execute the firmware upgrade process according to the upgrade instructions, and to perform firmware rollback after receiving an interrupt command; If a pause command is received, the system will not roll back and will wait for a resume command. A delay parameter will be set to check if the delay exceeds the preset time. If so, the system will roll back to the original state. The time parameter matches the time parameter of the external terminal to prevent automatic rollback during the upgrade process. Self-test module: Used to perform self-tests on firmware integrity and functionality after the upgrade is completed, and to report the self-test results to the controller.

[0033] Example 3 This embodiment is described in conjunction with Embodiments 1 and 2. In this embodiment, the controller and multi-module system includes one controller and 20 modules. The controller has one RJ45 interface and 20 fiber optic interfaces. Each fiber optic interface is connected to one module through an optical fiber to form a star topology. The external terminal adopts a cloud platform server, and the upgrade package is transmitted in an encrypted and compressed format.

[0034] An OTA upgrade method for a controller and a multi-module system, comprising the following steps: 1. Upgrade Preparation Phase: The operator starts the upgrade software on the cloud platform server, enters the upgrade command, selects the encrypted upgrade package, and sends it to the controller. After receiving the upgrade command and upgrade package through the RJ45 interface, the upgrade package processing module uses the MD5 algorithm to calculate the checksum of the upgrade package and compares it with the checksum sent by the cloud platform server. If the checksum passes, the upgrade package is parsed, separating the controller upgrade sub-package and the module upgrade sub-package, and extracting the corresponding adaptation version number of the module upgrade sub-package. The controller broadcasts the model query command to 20 modules through the communication management module. After receiving the command through the communication receiving module, each module sends its own version information back to the controller.

[0035] 2. Batch Pre-transmission Phase: The controller's upgrade package processing module divides the module upgrade sub-packet into 100 data blocks, adding a sequence number 1-100 and a CRC-16 checksum to each data block. The controller transmits the 100 data blocks in batches to 20 modules via a parallel communication link. After each module receives the data blocks through its communication receiving module, it concatenates the data blocks according to the sequence number, verifies the integrity using the CRC-16 checksum, and stores the data blocks in a temporary storage area after successful verification. It then sends a "successful reception + sequence number" status message back to the controller. Upon receiving the feedback, the controller finds that module #3 is missing data block with sequence number 56, and data block with sequence number 88 in module #15 failed verification. The controller then retransmits data block with sequence number 56 to module #3 and data block with sequence number 88 to module #15, until all 20 modules have reported complete reception of the module upgrade sub-packet.

[0036] 3. Tiered Upgrade Execution Phase: The controller's upgrade control module calls the controller upgrade sub-package to upgrade its own firmware. After the upgrade is completed, it automatically restarts. The self-test module performs self-tests on the controller's interface communication, data processing, and other functions. After passing the self-test, it sends a "controller upgrade complete" signal to the cloud platform server. The controller sends synchronous upgrade instructions to 20 modules. The upgrade execution module of each module calls the module upgrade sub-package in the temporary storage area to start the upgrade. During the upgrade process, every 10% of the progress is completed, progress information is fed back to the controller. The controller summarizes the information and feeds it back to the cloud platform server.

[0037] 4. Fault Tolerance Recovery and Verification Phase: When the upgrade reaches 60%, the controller detects a communication interruption caused by a loose fiber optic cable in module #8 and immediately sends an interrupt command to module #8. The upgrade execution module of module #8 calls the original firmware backed up in the data storage area and performs a rollback operation. After the operator checks and reconnects the fiber optic cable, the controller's fault tolerance recovery module detects that communication has been restored and sends a resume command to module #8. Module #8 continues the upgrade from the 60% progress point. When the upgrade reaches 90%, the controller detects that the firmware verification of module #12 has failed, which is determined to be a data transmission anomaly. The controller retransmits the module upgrade sub-packet to module #12, and module #12 re-executes the upgrade process. After all 20 modules have been upgraded, the controller's verification module sends verification commands to each module. The self-test module of each module performs self-tests on the integrity of the firmware, communication functions, and control functions. After passing the self-test, it sends a "verification qualified" signal. After summarizing all signals, the controller sends an "upgrade successful" signal to the cloud platform server.

[0038] In this embodiment, the total upgrade time for 20 modules is less than 1 minute. Operators only need to perform simple operations to complete the entire upgrade process, which greatly improves upgrade efficiency and reliability.

[0039] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any obvious modifications, substitutions or alterations without departing from the concept of the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for OTA upgrade of a controller and a multi-module embedded system, characterized in that, Includes the following steps: S1, Upgrade Preparation Phase; The controller performs integrity verification and parsing on the upgrade instructions and upgrade packages received from external terminals, and separates the upgrade sub-packages; The controller broadcasts a model query command to all modules and filters the list of modules to be upgraded based on the feedback. S2, Batch pre-transmission stage; The controller establishes a parallel communication link with all modules to be upgraded and divides the upgrade sub-packet corresponding to the module to be upgraded into multiple data blocks; The data blocks are then transmitted in batches to each module to be upgraded. The module to be upgraded splices, verifies, and stores the received data blocks, and regenerates upgrade sub-packages and stores them in a temporary storage area. And retransmit the abnormal data blocks; S3, Tiered Upgrade Implementation Phase; The controller prioritizes upgrading its own firmware and then restarts for self-testing. After the controller passes the self-test, the controller sends a synchronous upgrade command to the modules to be upgraded; each module to be upgraded calls the upgrade sub-package in the temporary storage area to perform the upgrade. S4, Fault Tolerance Recovery and Verification Phase; The controller monitors the upgrade status of each module to be upgraded in real time. When an upgrade fails, the controller sends an interrupt command to the current module, rolls the current module back to the original firmware version, and records the reason for the failure. The controller executes a differentiated recovery strategy for the modules that failed the upgrade based on the cause of failure, until all modules pass the self-test; The controller aggregates all signals that pass the self-test and sends a successful upgrade signal to the external terminal.

2. The OTA upgrade method for a controller and a multi-module embedded system according to claim 1, characterized in that, In S1, the specific process of the integrity verification is as follows: The MD5 algorithm is used to calculate the checksum of the upgrade package and compare it with the checksum sent by the external terminal. If they match, the checksum passes. After the checksum passes, the upgrade package is parsed, the controller upgrade sub-package and the module upgrade sub-package are separated, and the corresponding adaptation version number of the module upgrade sub-package is extracted. The controller broadcasts a model query command to all modules, and each module sends its own version information back to the controller. The controller then filters and determines the list of modules to be upgraded based on the feedback.

3. The OTA upgrade method for a controller and a multi-module embedded system according to claim 2, characterized in that, In S2, the segmentation of the upgrade sub-package specifically includes: The upgrade sub-packet is divided into multiple data blocks, and a sequence number and a checksum are added to each data block. The controller transmits the data blocks in batches to the modules to be upgraded through a parallel communication link. After receiving the data blocks, each module to be upgraded concatenates the data blocks according to the sequence number, verifies the integrity through the checksum, stores them in a temporary storage area after successful verification, and feeds back the receiving status information of each module to be upgraded to the controller.

4. The OTA upgrade method for a controller and a multi-module embedded system according to claim 2, characterized in that, In S2, the specific process of retransmitting the abnormal data block includes: When a module to be upgraded fails to receive data, the controller queries for missing or failed data blocks and retransmits the missing or failed data blocks to the current module until all modules to be upgraded report successful reception of the module upgrade sub-packet.

5. The OTA upgrade method for a controller and a multi-module embedded system according to claim 2, characterized in that, In S3, the controller upgrade subpackage and the module upgrade subpackage are prioritized, so that the priority of the controller upgrade subpackage is higher than that of the module upgrade subpackage, thereby prioritizing the execution of the controller's own upgrade process, calling the controller upgrade subpackage to upgrade its own firmware, restarting and performing a self-test after the upgrade is completed, and sending a signal that the controller upgrade is complete to the external terminal after the self-test is passed. After the controller passes the self-test, it sends a synchronous upgrade command to all modules in the list of modules to be upgraded. After receiving the command, each module to be upgraded calls the module upgrade sub-package in the temporary storage area to perform firmware upgrade. During the upgrade process, each module reports the upgrade progress and status information to the controller in real time.

6. The OTA upgrade method for a controller and a multi-module embedded system according to claim 2, characterized in that, In S4, the differentiated recovery strategy specifically includes: The reasons for upgrade failure include communication interruption, data verification failure, and firmware compatibility issues. The controller executes different recovery strategies based on different failure reasons. If the failure is due to communication interruption, monitor the communication status and retransmit the module upgrade sub-packet after communication is restored. If the failure is due to data verification failure, the corresponding abnormal data block will be retransmitted. If the failure is due to firmware incompatibility, the compatibility issue will be reported to the external terminal and the module upgrade will be terminated.

7. The OTA upgrade method for a controller and a multi-module embedded system according to claim 1, characterized in that, When the controller receives a pause command from an external terminal, the controller and each module pause the upgrade process and save the current upgrade progress; when the controller receives a resume command from an external terminal, the controller and each module resume the upgrade process from the paused progress point.

8. An upgrade system for implementing the OTA upgrade method for a controller and a multi-module embedded system as described in any one of claims 1-7, characterized in that, Includes a controller and N modules, where N ≥ 2: The controller is used to receive control commands from external terminals and to send status information back to the external terminals. The controller is equipped with a control system for enabling OTA upgrades of the controller and the module to be upgraded. The module is equipped with an upgrade system, which is used to upgrade itself according to the upgrade instructions of the controller and feed back the status information to the controller.

9. The upgrade system of the controller and multi-module embedded system OTA upgrade method according to claim 8, characterized in that, The control system includes an upgrade package processing module, a communication management module, an upgrade control module, a fault tolerance and recovery module, and a verification module. The upgrade package processing module is used to receive upgrade packages and perform integrity verification and parsing, and separate controller upgrade sub-packages and module upgrade sub-packages. The communication management module is used to communicate with external terminals and establish parallel communication links with each module to realize data transmission and status feedback. The upgrade control module is used to control its own firmware upgrade process, send upgrade commands to each module and synchronize upgrade signals, and monitor the upgrade progress. The fault-tolerant recovery module is used to detect whether there is an upgrade anomaly in the module, and to control the firmware rollback of the module that fails to upgrade, and to execute a differentiated recovery strategy according to the reason for failure. The verification module is used to send verification instructions to each module after the upgrade is completed, summarize the verification results and feed them back to the external terminal.

10. The upgrade system for the OTA upgrade method of a controller and a multi-module embedded system according to claim 8, characterized in that, The upgrade system includes a communication receiving module, a data storage module, an upgrade execution module, and a self-testing module; The communication receiving module is used to communicate with the controller, receive the controller's upgrade instructions, upgrade data blocks and control instructions, and provide feedback on its own model, receiving status, upgrade progress and results. The data storage module includes a temporary storage area for storing received upgrade sub-packet data blocks and firmware backups before the upgrade. The upgrade execution module is used to execute the firmware upgrade process according to the upgrade instruction, and to execute firmware rollback after receiving an interrupt instruction. The self-test module is used to perform a self-test on the integrity and functionality of the firmware after the upgrade is completed, and to report the self-test results to the controller.

Images