Multi-check-based unmanned aerial vehicle multi-load distributed cooperative upgrading system and method

Abstract

The application belongs to the technical field of unmanned aerial vehicle data processing, and aims at the technical problem that the one-to-many upgrading scene of the unmanned aerial vehicle terminal takes too long time, and the unstable communication link easily leads to upgrading failure, and proposes an unmanned aerial vehicle multi-load distributed cooperative upgrading system and method based on multiple check, which comprises a master device, multiple slave devices and an end-side data module, the master device checks and upgrades the package, runs and releases the internal file after passing; according to the configuration file, the program is first upgraded, then the end-side upgrading parent device is upgraded in turn according to the order of the upgrading device group in the upgrading queue, after the upgrading is completed, the end-side upgrading parent device upgrades the remaining slave devices in the group separately, until all the upgrading device groups are completely upgraded, the technical problems of low upgrading reliability in the existing upgrading method and slow multi-device upgrading speed in the harsh electromagnetic environment are solved.

Description

Technical Field

[0001] This invention belongs to the field of unmanned aerial vehicle (UAV) data processing technology. Background Technology

[0002] For drone payloads, data communication between the drone and ground equipment (main equipment) relies on wireless communication. However, the operating distance between the drone (end-side) and the ground equipment varies dynamically and is often quite far. Electromagnetic interference sources in the surrounding complex environment (such as industrial equipment and other wireless communication devices) can easily cause signal attenuation or distortion, leading to frequent instability issues such as jitter and interruption in the wireless communication link.

[0003] Meanwhile, the various payload devices carried by drones exhibit significant scenario-specific characteristics, showing prominent differences compared to ordinary IoT devices: First, the payload types are diverse, with different types of payloads (such as optical detection payloads, environmental sensing payloads, and communication relay payloads) having fundamentally different firmware versions, upgrade requirements, and data formats, requiring adaptation to differentiated upgrade logic; Second, the spatial layout is dispersed, with multiple payload devices deployed at different locations on the drone fuselage, resulting in uneven communication link quality between each payload and ground equipment, and some payloads may form communication blind spots due to fuselage obstruction; Third, edge-side resources are limited, with most payload devices built on MCUs without independent file system support, making it impossible to cache complete upgrade files.

[0004] When end-side load devices need to be upgraded, the unstable wireless communication links used to interact with ground equipment and transmit upgrade files result in low bandwidth, high latency, and weak anti-interference capabilities, making packet loss and errors during upgrade file transmission common. Load devices using MCUs as the main control chip lack a file system; once communication is interrupted, transmitted data becomes invalid, directly causing upgrade failure. Especially in scenarios with multiple load devices, the common upgrade method uses a universal communication protocol, interacting with each load device individually and transmitting upgrade files adapted to their type. Coupled with the uneven quality of communication links across load devices, this significantly extends the total upgrade time, reducing upgrade efficiency and further increasing the probability of upgrade failure due to prolonged exposure to communication instability risks.

[0005] For example, when using the Z-Modem protocol to establish communication transmission commands, the master device needs to upgrade each slave device in turn, and the upgrade process needs to be initiated to each MCU one by one. This results in a linear increase in the total upgrade time. Moreover, the general communication protocol cannot meet personalized needs, the verification method is simple, the reliability is low, and it does not support breakpoint resumption. Even though the Z-Modem protocol has been greatly improved compared to the X-Modem and Y-Modem protocols, it still does not support multiple verifications. Summary of the Invention

[0006] To address the technical problems of excessively long upgrade times and unstable communication links that easily lead to upgrade failures in one-to-many upgrade scenarios on UAVs, this invention proposes a distributed collaborative upgrade system and method for UAVs with multiple loads based on multiple verifications.

[0007] A multi-load distributed collaborative upgrade system for drones based on multiple verification includes at least:

[0008] The main device operates on the ground and interacts with the drone via a wireless communication link. During the upgrade, it is responsible for parsing the upgrade package and distributing upgrade-related documents.

[0009] Multiple slave devices operate at the drone end, serving as payload devices for the drone; during upgrades, slave payload devices of the same type form an upgrade device group, and the first slave payload device in the upgrade device group to respond to the master device is the end-side upgrade parent device;

[0010] The edge data module operates on the UAV end and is used to provide communication and data processing services for various payload devices. It communicates with the UAV via a wired link and with the upgrade equipment group via a soft bus.

[0011] The wireless communication link adopts a multi-structure nesting, which is divided into basic frames and nested frames. The basic frame is divided into three parts: a frame header containing key information of the basic frame, a data segment of the corresponding functional data payload in the protocol, and a CRC32 check code as the frame tail; the nested frame is used for the interaction of the upgrade function process.

[0012] The upgrade package is a two-level executable file, consisting of five parts: an upgrade file management program, a master device upgrade file, multiple slave device upgrade files, an upgrade script, and an upgrade file configuration file. The entire file is encrypted using a symmetric encryption algorithm.

[0013] The multi-verification-based distributed collaborative upgrade method for UAVs with multiple loads includes the following steps:

[0014] After the main device verification and upgrade package passes, it runs and releases its internal files.

[0015] The master device first upgrades its own program according to the configuration file, and then upgrades the end-side upgrade parent device in the order of the upgrade device group in the upgrade queue. After the upgrade is completed, the end-side upgrade parent device upgrades the remaining slave devices in the group individually.

[0016] Within an upgrade device group, the end-side upgrade parent device adds the slave devices in the group to the upgrade group. The upgrade of the slave devices in the group adopts a one-to-many approach, sending upgrade data, and after the slave device responds, it sends the next set of data until all upgrade data transmission is completed. If any slave device fails to respond within the specified time, it is removed from the upgrade queue in the group. After the slave devices in the queue have completed their upgrades, the slave devices removed from the upgrade queue will be upgraded.

[0017] The process will continue until all upgraded equipment groups have been upgraded.

[0018] Technical effects:

[0019] This invention addresses the technical problems of low reliability and slow upgrade speed in harsh electromagnetic environments in existing upgrade methods by designing upgrade package structure, optimizing communication protocols, and innovating distributed upgrade processes.

[0020] (1) Enhance adaptability to harsh electromagnetic environments and improve upgrade reliability

[0021] In scenarios with severe electromagnetic interference (such as near industrial plants, high-voltage power transmission areas, and complex outdoor environments), the anti-interference capability of the upgrade process is significantly improved, the upgrade failure rate is greatly reduced, and problems such as equipment downtime and firmware damage caused by upgrade interruption are reduced.

[0022] Traditional upgrade communication often uses a simple frame structure and a single-check mechanism. In harsh electromagnetic environments, the signal is easily interfered with, leading to data transmission errors. Furthermore, there is a lack of error correction mechanisms. Once data packet loss or bit errors occur, the upgrade will fail.

[0023] This invention improves reliability through a specially designed upgrade communication protocol. A multi-verification mechanism replaces the traditional single-verification, employing triple verification—frame header verification, data segment CRC verification, and whole-frame verification—to accurately identify transmitted erroneous data and prevent erroneous data from being written into the device firmware. It also supports breakpoint retransmission, automatically re-requesting the corresponding data based on the recorded node when a transmission anomaly occurs. This eliminates the need to retransmit the complete upgrade package, resuming only the incomplete portion, significantly reducing the probability of upgrade failure due to interference.

[0024] (2) Improve the efficiency of upgrading multiple devices and shorten the overall upgrade time.

[0025] When there are a large number of data acquisition devices in the system (such as 10 or more), the overall upgrade time is significantly shortened compared to traditional methods, and the load on the main device is significantly reduced during the upgrade process, avoiding problems such as main device lag and interruption of other services caused by centralized upgrades.

[0026] This invention's distributed upgrade process fundamentally solves the bottleneck of upgrade speed. The layered upgrade architecture reduces the interaction pressure on the master device. The master device only needs to complete the upgrade of the parent device on the end side, and then the parent device is responsible for upgrading the slave devices within the group. The interaction objects of the master device are simplified from "all slave devices" to "a small number of parent devices," reducing the number of interactions and significantly freeing up the master device's communication and computing resources. Simultaneously, wired communication improves the reliability and speed of upgrades within the group. The end-side upgrade parent device and the slave devices within the group use wired communication, which, compared to wireless communication, is not affected by electromagnetic interference and avoids upgrade interruptions within the group. Multiple parallel upgrades shorten the total time. Multiple data acquisition devices are divided into multiple upgrade groups, and each group upgrades synchronously under the coordination of the parent device. The total time no longer increases linearly with the number of devices, but depends on the upgrade time of a single group, achieving flattening of upgrade time under a large number of devices.

[0027] Meanwhile, this invention comprehensively improves upgrade security and avoids the risk of firmware program leakage. It effectively prevents malicious parsing of the upgrade package, avoids leakage of core firmware programs, protects the technical confidentiality and operational security of the device, and reduces security risks such as device hacking and data tampering caused by firmware leaks. The core flaw of existing upgrade methods lies in the simple structure of the upgrade package and the lack of encryption protection mechanisms. Attackers can extract the firmware program from the package using conventional parsing tools, thereby obtaining core system technical parameters.

[0028] This invention addresses this problem through two key design features: First, it employs file encryption technology to encrypt the entire upgrade package, requiring a key for decryption. This prevents unauthorized entities from accessing the original firmware data within the package, blocking the possibility of data leakage at the source. Second, it combines this with a file verification mechanism, adding a data integrity verification layer on top of encryption. This not only identifies damage during upgrade package transmission or storage but also prevents attackers from implanting malicious programs by tampering with the upgrade package, forming a dual security protection of "encryption + verification." Simultaneously, the upgrade package's "runnable + self-release" design ensures that the firmware program is only temporarily released during the local device upgrade process and automatically clears temporary files after the upgrade is complete, preventing the firmware program from leaving extractable traces in device storage and further enhancing security. Attached Figure Description

[0029] Figure 1 This is a diagram of the overall communication link architecture of the system of the present invention.

[0030] Figure 2 This is a flowchart illustrating the interaction logic between the main equipment and the upgrade equipment group.

[0031] Figure 3 This is a schematic diagram of the internal partitioning of the MCU's Flash memory.

[0032] Figure 4 This is a flowchart of an example of upgrading a device.

[0033] Figure 5 Flowchart of the MCU Bootloader upgrade process. Detailed Implementation

[0034] Key terms and technical abbreviations:

[0035] SOC: A highly integrated integrated circuit that integrates all the key components (CPU, GPU, memory, communication modules, etc.) of a complete computer system or electronic system onto a single silicon chip.

[0036] MCU: Microcontroller Unit.

[0037] Bootloader: The first piece of code executed after a device is powered on or reset, responsible for initializing the hardware and boots the operating system or application.

[0038] This embodiment is specifically adapted to the multi-load upgrade scenario of drones from both hardware and software perspectives.

[0039] On the hardware side, an end-side data module is introduced. This module operates on the UAV end, connecting to each load device via a CAN bus. A software-based soft bus is constructed to achieve bidirectional reliable communication between load devices, resolving communication instability issues caused by the spatially dispersed layout of load devices. On the software side, an upgrade package structure and usage method are designed to ensure the security of the upgrade package. A dedicated communication protocol is designed to implement multi-verification and breakpoint resume functions, resolving communication transmission failures caused by unstable wireless communication between ground equipment and load devices. A distributed collaborative upgrade approach is adopted at the load end, classifying and scheduling loads according to type and priority. Simultaneously, similar loads are aggregated into upgrade device groups, with each group upgrading only one load. Remaining loads within the group are upgraded using already upgraded loads, reducing the frequency of wireless communication interactions. This method solves the problems of difficult adaptation to diverse UAV load types, upgrade failures due to communication instability, and low efficiency in multi-load upgrades, achieving a more reliable and efficient upgrade method.

[0040] This embodiment provides a multi-verification, multi-load, distributed, collaborative upgrade system for unmanned aerial vehicles (UAVs), such as... Figure 1 As shown, it includes the main equipment, which operates on the ground and interacts with the UAV via a wireless communication link, including a data processing terminal and a UAV ground station;

[0041] Multiple slave devices, operating on the drone end as payload equipment of the drone, include data acquisition modules such as multispectral cameras, ambient light sensors, position and attitude sensors, and barometric pressure sensors;

[0042] During the upgrade, load devices of the same type are grouped into an upgrade device group, and the first load device in the upgrade device group to respond to the master device is the end-side upgrade parent device.

[0043] The end-side data module operates on the UAV end and is used to provide communication and data processing services for various payload devices. It communicates with the UAV via wired links such as USB and CAN bus, and communicates with the upgrade device group via a soft bus such as CAN bus.

[0044] To meet the needs of multi-device scenarios, a "software-defined bus" is implemented on the basis of CAN bus hardware through upper-layer software encapsulation. It has enhanced functions such as service registration, dynamic ID allocation and scheduling, and protocol customization. The core is to make up for the inherent defects of the hardware bus through software logic. The software bus solves the problem of bidirectional reliable communication between multiple slave devices.

[0045] Simultaneously, during the UAV ground station upgrade, an upgrade package is distributed. Based on this package, the main device and multiple slave devices are upgraded. The upgrade package mainly consists of five parts: an upgrade file management program, the main device upgrade file, the slave device upgrade files (including upgrade files for multiple slave devices), the upgrade script, and the upgrade file configuration file. A symmetric encryption algorithm is used to encrypt the entire file. This embodiment uses the AES-256 symmetric encryption algorithm, but AES-128, ChaCha20, and other symmetric encryption algorithms can also be used, as long as the encrypted upgrade package cannot be parsed by unauthorized parties. After encryption, it is packaged into a binary file with the .bin extension.

[0046] Packaging into a binary file serves two main purposes: ① It can be run directly as an executable program during the main device upgrade; ② Binary files cannot be directly parsed, and when combined with symmetric encryption algorithms, the files inside the upgrade package cannot be accessed, thus improving the security of the upgrade package and preventing attackers from maliciously parsing and tampering with the files inside the upgrade package and implanting malicious programs.

[0047] Furthermore, the wireless communication link between the main device and the drone is a specially designed upgraded communication protocol, featuring multiple verifications, support for variable-length transmission, and support for resuming interrupted transmissions.

[0048] The wireless communication link adopts a multi-structure nesting, mainly divided into basic frames and nested frames, and separate frame structures are set for different scenarios.

[0049] The main structure of the basic frame is shown in Table 1. The entire frame structure is divided into three parts: frame header, data segment, and frame tail.

[0050] Table 1 Basic Frame Structure of Wireless Communication Link

[0051]

[0052] The frame header is located at the beginning of the entire base frame and contains key information about the base frame. The SOF field is an identification flag used to identify the start of data during protocol parsing. The LEN field indicates the total data length of the protocol frame, including the frame header, data segments, and frame trailer. The SEQ segment is the frame sequence code, used for data reliability verification during communication. Each time the master and slave devices send one frame of data, the frame sequence code value increments by 1, cycling between 0 and 255. Parsing the protocol frame allows determining whether a frame has been repeatedly sent. The FrameType field indicates the frame type, used to identify whether the base frame was sent by the master or slave device. The DeviceType field is the device type identifier, used to identify the type of device sending the base frame. The DeviceID field is the device ID identifier, used to confirm the identity of the device sending the base frame. The CommandID field is the command function ID. All functions in the protocol are identified by their command IDs. The command IDs and data segment information are strictly correlated. For example, a command ID of 0xC0 indicates an upgrade function switch, and the data segment represents the relevant configuration for the upgrade function switch; a command ID of 0xC1 indicates an upgrade process interaction command, and the data segment represents the data required for interaction during the upgrade process.

[0053] The CRC16 field is the CRC checksum of the frame header. The checksum is calculated from the frame header content minus the CRC16 field. Adding a checksum to the frame header allows for initial identification of the frame header via SOF during frame data reception and parsing, and performs a CRC16 check on the header. If the check passes, the information in the frame header is confirmed to be correct, and the information can be used directly. Because the frame header data is relatively small, the verification speed is fast, avoiding the problem of verifying the entire frame data before using its information. If errors are encountered within the frame data, the entire frame becomes unusable, leading to invalid CRC32 calculations. Using the CRC16 checksum in the frame header allows for early identification, improving the speed of frame data parsing.

[0054] The main content of the data segment area is the detailed data payload of the corresponding function in the protocol, which needs to be used in conjunction with the command ID. The protocol supports 256 different functions, with a total of 256 command IDs. The content of the data segment is the content data corresponding to each command ID. Different commands can be combined to achieve more complex functions and meet various needs during the upgrade process. The upgrade process uses two command IDs, as shown in Table 2. 0xC0 enables the upgrade function. When an upgrade is required, the master device sends the 0xC0 command to the slave device to enable the upgrade mode. The slave device replies to the master device with the status of enabling the upgrade mode, device type, and device ID information. Based on the slave device's reply, the master device establishes an upgrade device queue, plans the upgrade strategy, and executes the upgrade process through the 0xC1 command, thereby completing the software upgrade.

[0055] Table 2. Description of Protocol Upgrade Command IDs

[0056]

[0057] The frame tail section contains a CRC32 checksum. The CRC32 checksum is calculated for all data in the frame header and data segments. When the protocol is packaged, the CRC32 checksum needs to be calculated and written to the frame tail. When parsing the base frame, the CRC32 checksum needs to be calculated and compared with the CRC32 checksum at the frame tail. If the checksums match, the entire base frame data is correct.

[0058] Nested frames are used for interaction during the upgrade process. They need to be used in conjunction with a command ID. When the command ID is 0xC1, the data in the data segment must use nested frames. Nested frames are divided into a master part and a slave part, and the protocol structures of the two parts are different. The master part's nested protocol includes key frames and data frames. Key frames are used by the master device to transmit key information about the upgrade file to the slave device, including frame type, frame number, frame length, total number of packets transmitted, CRC checksum of the upgrade file, upgrade file size, and upgrade file name. See Table 3 for details. The master part's data frames are mainly used to transmit upgrade file data to the slave device, including frame type, frame number, frame length, and upgrade file data. See Table 4 for details. The slave part's nested protocol only includes data frames, including frame type, frame number, frame length, and additional data. See Table 5 for details.

[0059] Table 3. Description of Keyframes for Nested Frame Protocol Hosts

[0060]

[0061] Table 4. Description of Nested Frame Protocol Host Data Frames

[0062]

[0063] Table 5. Description of Slave Data Frames in Nested Frame Protocol

[0064]

[0065] On the other hand, this embodiment proposes a multi-verification, multi-load, distributed, collaborative upgrade method for UAVs, such as... Figures 2 to 3As shown, after the master device software upgrade is completed, the slave device software upgrade begins. The data upgrade process for the slave device is master device -> drone -> edge data module -> slave device. The master device and drone communicate via a wireless link, the drone communicates with the edge data module via a wired link, and the edge data module communicates with the slave device via a soft bus. The drone and edge data module act as communication relay devices, ultimately enabling data communication between the master and slave devices. The drone and edge data module will not be described separately below; the communication between the master and slave devices will be briefly outlined. The specific upgrade process is as follows:

[0066] After the main device enables the upgrade function, it first uses a file integrity verification algorithm to verify the integrity of the upgrade package to ensure that the upgrade package is not damaged or tampered with. This embodiment mainly uses the BLAKE3 algorithm. In addition, SHA-256, SHA-3, MD5, etc. can also be used. After verifying that the upgrade package file is fine, the main device directly runs the upgrade package file. When running, it is necessary to input the running parameters. The parameter content is a security password. After the password is correct, the upgrade package file automatically executes the file release function, releasing the script files, upgrade files, configuration files, etc. inside the upgrade package to the file temporary storage area in the main device.

[0067] After the files are released, the released script file will be executed automatically. The script will compare the major version number of the upgrade package with the software version number in the main device. If they do not match, the upgrade process will be executed and the next step will be taken. If they match, no upgrade is needed and the script will automatically clear the upgrade-related files in the temporary storage area.

[0068] After entering the upgrade process, the script first upgrades the software of the master device. The master device upgrade mainly involves copying relevant files and updating configuration information. After the master device upgrade is complete, the script then upgrades the slave devices. The master device identifies the slave devices that need upgrading based on the configuration files in the upgrade package, and then broadcasts an upgrade request to the slave devices via the upgrade protocol.

[0069] After receiving a broadcast message, the slave device compares the version number in the message with its own software version number. If they match, no upgrade is needed, and the slave device does not need to respond to the message. If the version numbers do not match, the slave device needs to respond to the message, including its device ID and device type. Upon receiving the response, the master device establishes an upgrade queue based on the slave device's identification ID. The queue groups devices of different types. Devices of the same type have the same firmware, and the master device groups slave devices of the same type into the same upgrade device group. Each type of slave device has its own corresponding upgrade device group, which can contain one or more slave devices. The slave device that responds first in the group is designated as the end-side upgrade parent device. The master device upgrades the end-side upgrade parent devices sequentially according to the order of the upgrade device groups in the upgrade queue. After the upgrade is complete, the end-side upgrade parent device upgrades the remaining devices in the group individually.

[0070] For an upgrade device group, the number of slave devices is 1 to N. The master device first upgrades the end-side upgrade parent device in the group. After the upgrade is completed, the end-side upgrade parent device upgrades the remaining slave devices in a one-to-many manner. After sending each data packet, it needs to wait for the response from all devices in the group and use the upgrade queue and status tracking mechanism to upgrade all devices in the group synchronously, transmitting firmware data packet by packet until all devices in the group have been upgraded. In this way, multiple device groups can be upgraded in parallel, reducing the number of wireless communication interactions and greatly improving the upgrade speed.

[0071] Within an upgrade device group, any slave device that fails to respond within the specified time during the upgrade process will be removed from the upgrade queue to ensure that other devices can be upgraded normally. Devices that cause broadcast upgrade failures will be upgraded individually until all devices have been upgraded.

[0072] Upgrade processing mechanism from the device side

[0073] The main control chip of the device is an MCU. Since the MCU does not have a file system, the upgrade process differs significantly from traditional SOC upgrades where data is directly copied. The MCU's Flash memory is divided into four partitions, such as... Figure 3 As shown, these are the Bootloader partition, configuration parameter partition, application main partition, and application secondary partition, respectively. To improve the reliability of upgrades, two main methods are used in the MCU-side upgrade mechanism:

[0074] Example 1 of device upgrade implementation: Optimizing the interaction method during MCU upgrade, such as... Figure 4 As shown, the specific interaction steps are as follows:

[0075] S1. The devices involved in the upgrade process include the upgrade initiator and the upgrade receiver. The upgrade initiator includes the master device and the end-side upgrade parent device, while the upgrade receiver is mainly the slave device that needs to be upgraded. The upgrade initiator initiates the upgrade process and sends upgrade commands to the slave devices.

[0076] S2. After receiving the start upgrade command sent by the upgrade initiator, the upgrade receiver requests the host keyframe from the upgrade initiator and waits for its reply. If no reply is received within 3 seconds, the host keyframe is requested again. If the number of re-requests is greater than 10, the upgrade process is exited and the upgrade fails.

[0077] S3. After the upgrade receiver receives the host keyframe data, it verifies the data. If the verification fails, it jumps to step 2. If the verification is successful, it parses the data in the host keyframe, including the upgrade file name, size, check code, and the total number N of upgrade file packets.

[0078] S4. The upgrade receiver requests upgrade file data from the upgrade initiator sequentially, starting from the first data packet, based on the total number N packets in the host keyframe. If no response is received within 3 seconds, the request for the corresponding packet data is restarted. If the number of re-requests exceeds 10, the upgrade process is exited and the upgrade fails.

[0079] S5. After receiving the upgrade file data returned by the upgrade initiator, the upgrade receiver verifies the data. If the verification passes, the data is written to the idle program partition of the MCU Flash memory. If the verification fails, the receiver returns to step 4 to request the data of the corresponding packet again. If the number of re-requests is greater than 10, the upgrade process is exited and the upgrade fails.

[0080] S6. Repeat steps 4 and 5 until all upgrade file data has been received and written to Flash.

[0081] S7, such as Figure 5 As shown, the configuration parameter partition of the Flash memory is read, and the first flag bit of the configuration parameter partition is modified by setting it. The first flag bit indicates whether the MCU is in upgrade state. The second flag bit is modified by incrementing its value by one. If the second flag bit is odd, the MCU runs the firmware program of the main application partition. If it is even, the MCU runs the firmware program of the secondary application partition. This flag bit is mainly used to switch the firmware running partition.

[0082] S8. The software restarts the upgrade receiver. First, it executes the Bootloader program, reads the first flag bit of the parameter configuration partition, and confirms that the current state is upgrade. Then, it modifies the value of the third flag bit by incrementing it by one. The default value of the third flag bit is 0. Then, according to the value of the second flag bit, it executes the firmware program of the corresponding application partition.

[0083] S9. If the firmware program runs normally, it resets the first flag bit in the parameter configuration partition and modifies the value of the third flag bit to 0, completing the MCU upgrade. If the firmware program malfunctions, the watchdog timer resets the MCU and reruns the bootloader program. The bootloader program re-executes step 8 and increments the third flag bit. If the firmware program fails to run normally three times, the value of the third flag bit will be 3. The bootloader program will then reset the first flag bit, set the value of the third flag bit to 0, and decrement the second flag bit, indicating an upgrade failure at the upgrade initiator.

[0084] In the second example of device upgrade, during normal MCU program operation, the running program is one of the main or secondary application partitions, determined by variables in the configuration parameter partition. During the upgrade process, the firmware program determines whether the currently running program is in the main or secondary partition, then packages the received upgrade file and writes it to another free program partition. After the upgrade file is transferred and verified, the parameters are reconfigured to point the executed application address to the previously free program partition.

[0085] After restarting the MCU, the Bootloader upgrade program is run first (steps 7-9 above). After running, the Bootloader upgrade program reads the configuration parameters and then jumps to the new program partition to execute the newly upgraded firmware. If the newly upgraded program encounters an error, the configuration parameters will be modified to restore the previous program. This embodiment can simultaneously retain both the old and new firmware versions for firmware recovery after a failure, improving upgrade reliability. It also eliminates the backup partition used in traditional methods, reducing Flash memory usage and improving Flash utilization.

[0086] The above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and are not intended to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention.

Claims

1. A distributed collaborative upgrade system for UAVs with multiple loads based on multi-verification, characterized in that, At least including: The main device operates on the ground and interacts with the drone via a wireless communication link. During the upgrade, it is responsible for parsing the upgrade package and distributing upgrade-related documents. Multiple slave devices operate at the drone end, serving as payload devices for the drone; during upgrades, slave payload devices of the same type form an upgrade device group, and the first slave payload device in the upgrade device group to respond to the master device is the end-side upgrade parent device; The end-side data module operates on the UAV end and is used to provide communication and data processing services for the payload equipment. It communicates with the UAV via a wired link and with the upgrade equipment group via a soft bus. After the main device verification and upgrade package passes, it runs and releases its internal files. The master device first upgrades its own program according to the configuration file, and then upgrades the end-side upgrade parent device in the order of the upgrade device group in the upgrade queue. After the upgrade is completed, the end-side upgrade parent device upgrades the remaining slave devices in the group individually. Within an upgrade device group, the end-side upgrade parent device adds the slave devices in the group to an upgrade group. Upgrades to slave devices in the group are performed in a one-to-many manner. Upgrade data is sent, and after the slave device responds, the next set of data is sent until all upgrade data transmissions are completed. If a slave device fails to respond within the specified time, it will be removed from the upgrade queue of the group. The upgrade will be carried out on the slave device removed from the upgrade queue only after the slave devices in the queue have completed their upgrades. The upgrade process will continue until all upgraded equipment groups have been completed. The wireless communication link adopts a multi-structure nesting, which is divided into basic frames and nested frames. The basic frame is divided into three parts: a frame header containing key information of the basic frame, a data segment of the corresponding functional data payload in the protocol, and a CRC32 check code as the frame tail. The nested frames are used for the upgrade function process interaction. The nested frames are divided into a master part and a slave part. The nested frames of the master part include key frames and data frames. The key frames are used by the master device to transmit key information of the upgrade file to the slave device, and the data frames are used to transmit upgrade file data to the slave device. The nested frames in the slave section consist only of data frames.

2. The UAV multi-load distributed collaborative upgrade system based on multiple verification as described in claim 1, characterized in that, The key frames of the host-part nested frames include frame type, frame number, frame length, total number of packets transmitted in subpackets, CRC checksum of the upgrade file, upgrade file size, and upgrade file name; the data frames of the host-part nested frames include frame type, frame number, frame length, and upgrade file data; the data frames of the slave-part nested frames include frame type, frame number, frame length, and additional data.

3. The UAV multi-load distributed collaborative upgrade system based on multiple verification as described in claim 1, characterized in that, The upgrade package is a two-level executable file, consisting of five parts: an upgrade file management program, a master device upgrade file, multiple slave device upgrade files, an upgrade script, and an upgrade file configuration file. The entire file is encrypted using a symmetric encryption algorithm.

4. The UAV multi-load distributed collaborative upgrade system based on multiple verification according to any one of claims 1 to 3, proposes a UAV multi-load distributed collaborative upgrade method based on multiple verification, characterized in that... Includes the following steps: After the main device verification and upgrade package passes, it runs and releases its internal files. The master device first upgrades its own program according to the configuration file, and then upgrades the end-side upgrade parent device in the order of the upgrade device group in the upgrade queue. After the upgrade is completed, the end-side upgrade parent device upgrades the remaining slave devices in the group individually. Within an upgrade device group, the end-side upgrade parent device adds the slave devices in the group to an upgrade group. Upgrades to slave devices in the group are performed in a one-to-many manner. Upgrade data is sent, and after the slave device responds, the next set of data is sent until all upgrade data transmissions are completed. If a slave device fails to respond within the specified time, it will be removed from the upgrade queue of the group. The upgrade will be carried out on the slave device removed from the upgrade queue only after the slave devices in the queue have completed their upgrades. The process will continue until all upgraded equipment groups have been upgraded.

5. The UAV multi-load distributed collaborative upgrade method based on multiple verification as described in claim 4, characterized in that, The slave device's master control chip is an MCU, and the MCU's Flash memory is divided into four partitions: Bootloader partition, configuration parameter partition, application main partition, and application secondary partition.

6. The UAV multi-load distributed collaborative upgrade method based on multiple verification as described in claim 5, characterized in that, When upgrading from a device, the interaction method during MCU upgrade is optimized, and the specific interaction steps are as follows: S1. The devices involved in the upgrade process include the upgrade initiator and the upgrade receiver. The upgrade initiator includes the master device and the end-side upgrade parent device, while the upgrade receiver is mainly the slave device that needs to be upgraded. The upgrade initiator initiates the upgrade process and sends upgrade instructions to the slave device. S2. After receiving the start upgrade command sent by the upgrade initiator, the upgrade receiver requests the host keyframe from the upgrade initiator and waits for its reply. If no reply is received within 3 seconds, the host keyframe is requested again. If the number of re-requests is greater than 10, the upgrade process is exited and the upgrade fails. S3. After the upgrade receiver receives the host keyframe data, it verifies the data. If the verification fails, it jumps to step 2. If the verification is successful, it parses the data in the host keyframe, including the upgrade file name, size, check code, and the total number N of upgrade file packets. S4. The upgrade receiver requests upgrade file data from the upgrade initiator sequentially, starting from the first data packet, based on the total number N packets in the host keyframe. If no response is received within 3 seconds, the request for the corresponding packet data is restarted. If the number of re-requests exceeds 10, the upgrade process is exited and the upgrade fails. S5. After receiving the upgrade file data returned by the upgrade initiator, the upgrade receiver verifies the data. If the verification passes, the data is written to the idle program partition of the MCU Flash memory. If the verification fails, return to S4 to re-request the data of the corresponding package. If the number of re-requests exceeds 10, exit the upgrade process and the upgrade fails. S6. Repeat S4 and S5 until all upgrade file data has been received and written to Flash. S7. Read the configuration parameter partition of the Flash memory, modify the first flag bit of the configuration parameter partition, and set it. The first flag bit indicates whether the MCU is in upgrade state. Modify the second flag bit by incrementing its value by one. If the second flag bit is odd, the MCU runs the firmware program of the main application partition; if it is even, the MCU runs the firmware program of the secondary application partition. This flag bit is used to switch the firmware running partition. S8. The software restarts the upgrade receiver. First, it executes the Bootloader program, reads the first flag bit of the parameter configuration partition, and confirms that the current state is upgrade. Then, the value of the third flag is modified by incrementing it by one. The default value of the third flag is 0. Then, based on the value of the second flag, the firmware program of the corresponding application partition is executed. S9. If the firmware program runs normally, the first flag bit in the parameter configuration partition is reset, and the value of the third flag bit is modified to 0. The MCU upgrade is complete. If the firmware program does not run normally, the watchdog will reset the MCU and rerun the bootloader program. The bootloader program will re-execute S8 and increment the third flag bit. If the firmware program fails to run normally three times, the value of the third flag bit will be 3. The bootloader program will then reset the first flag bit, set the value of the third flag bit to 0, and decrement the second flag bit. At this point, the upgrade initiator will be notified that the upgrade failed.

Images