Unmanned aerial vehicle multi-load distributed cooperative upgrading system and method based on multiple verification

Abstract

The invention belongs to the technical field of unmanned aerial vehicle data processing, and provides an unmanned aerial vehicle multi-load distributed collaborative upgrading system and method based on multiple verification for solving the technical problems that a one-to-many upgrading scene at an unmanned aerial vehicle end is too long in time consumption and an upgrading failure is easily caused by an unstable communication link. Comprising a master device, a plurality of slave devices and an end side data module, and the master device runs and releases internal files after verifying an upgrade package; the method comprises the following steps: firstly upgrading a self program according to a configuration file, then sequentially upgrading an end-side upgrading parent device according to the sequence of upgrading device groups in an upgrading queue, and after upgrading is completed, independently upgrading the rest slave devices in the groups by the end-side upgrading parent device until all upgrading device groups are completely upgraded. The technical problems that in an existing upgrading method, the upgrading reliability is low under the severe electromagnetic environment, and the multi-device upgrading speed is low are solved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of unmanned aerial vehicle data processing. BACKGROUND

[0002] For the unmanned aerial vehicle load device, the data communication between it and the ground device (main device) relies on wireless communication mode to realize. The working distance between the unmanned aerial vehicle end (end side) and the ground device dynamically changes and is often in a long range. The electromagnetic interference sources (such as industrial equipment, other wireless communication equipment) in the surrounding complex environment are easy to cause signal attenuation or distortion, resulting in unstable problems such as frequent jitter and interruption of the wireless communication link.

[0003] At the same time, the various load devices carried by the unmanned aerial vehicle have obvious scene specificity and are quite different from ordinary Internet of Things devices: first, the load type diversity, the firmware version, the upgrading demand and the data format of different types of loads (such as optical detection load, environmental sensing load, communication relay load, etc.) have essential differences, and need to adapt to the differentiated upgrading logic; second, the spatial layout is scattered, and multiple load devices are deployed at different positions of the unmanned aerial vehicle body, resulting in uneven communication link quality of each load and the ground device, and some loads may form a communication blind area due to the shielding of the body; third, the end side resource is limited, and most load devices are based on MCU construction without independent file system support, and cannot buffer complete upgrade files.

[0004] When the end side load device needs to be upgraded, it interacts with the ground device and transmits the upgrade file through the above unstable wireless communication link. The communication bandwidth is low, the delay is large and the anti-interference ability is weak, resulting in easy packet loss and packet error of the upgrade file transmission; the load end using MCU as the main control chip has no file system, and once the communication is interrupted, the transmitted data is invalid, directly causing the upgrade to fail. Especially in the scene of carrying multiple load devices, the ordinary upgrade method uses a general communication protocol to interact with each load one by one and transmit the upgrade file adapted to the type of each load, and the unevenness of the communication link quality of each load, which makes the total upgrade time greatly prolonged, not only reduces the upgrade efficiency, but also further increases the upgrade failure probability due to long-time exposure to the unstable communication risk.

[0005] For example, the Z-Modem protocol is used to establish communication transmission commands, and the main device upgrades each slave device in turn, which needs to initiate the upgrade process to each MCU one by one, resulting in linear growth of the total upgrade time, and the general communication protocol cannot meet the individual needs, the verification method is simple, the reliability is low, and the breakpoint resume transmission is not supported. Even though the Z-Modem protocol has been greatly improved compared with the X-Modem and Y-Modem protocols, it still does not support multiple verifications. SUMMARY

[0006] In view of the technical problems that the upgrading of the unmanned aerial vehicle end one-to-many upgrade scene takes too long time, and the unstable communication link easily leads to upgrade failure, the application provides an unmanned aerial vehicle multi-load distributed cooperative upgrading system and method based on multiple check.

[0007] The unmanned aerial vehicle multi-load distributed cooperative upgrading system based on multiple check comprises at least: A master device works at the ground end, exchanges data with the unmanned aerial vehicle through a wireless communication link, is responsible for analyzing an upgrade package during upgrading, and simultaneously issues upgrade-related files; A plurality of slave devices work at the unmanned aerial vehicle end and serve as load devices of the unmanned aerial vehicle; during upgrading, load slave devices of the same type form an upgrade device group, and a load device in the upgrade device group that first replies to the master device is an end-side upgrade parent device; An end-side data module works at the unmanned aerial vehicle end, provides communication and data processing services for various load devices, communicates with the unmanned aerial vehicle through a wired link, and communicates with the upgrade device group through a soft bus.

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

[0009] The upgrade package is a two-level executable file, which comprises five parts of an upgrade file management program, a master device upgrade file, a plurality of slave device upgrade files, an upgrade script, and an upgrade file configuration file, and the file is integrally encrypted by using a symmetric encryption algorithm.

[0010] The unmanned aerial vehicle multi-load distributed cooperative upgrading method based on multiple check comprises the following steps: The master device runs and releases internal files after verifying the upgrade package; The master device first upgrades its own program according to the configuration file, then upgrades the end-side upgrade parent device in turn according to the order of the upgrade device group in the upgrade queue, and after the upgrade is completed, the end-side upgrade parent device upgrades the remaining slave devices in the group individually.

[0011] For an upgrade device group, the end-side upgrade parent device adds the slave devices in the group to an upgrade group, upgrades the slave devices in the group in a one-to-many manner, sends upgrade data, and after the slave devices reply, sends the next group of data until all upgrade data transmission is completed; if a slave device does not reply within a specified time during the process, the slave device is removed from the upgrade queue in the group, and after the slave devices in the queue are upgraded, the slave device removed from the upgrade queue is upgraded; The process ends until all upgrade device groups are upgraded completely.

[0012] Technical effects: The application solves the problems of low upgrade reliability in a harsh electromagnetic environment and slow multi-device upgrade speed in the prior art upgrade method by upgrading the package structure design, optimizing the communication protocol, and innovating the distributed upgrade process.

[0013] (1) Enhance the adaptability to harsh electromagnetic environment and improve the upgrade reliability In a severe electromagnetic interference scene (such as near an industrial plant, a high-voltage power transmission area, a complex outdoor environment, etc.), the anti-interference ability of the upgrade process is significantly improved, the upgrade failure rate is greatly reduced, and problems such as device downtime and firmware damage caused by upgrade interruption are reduced.

[0014] Traditional upgrade communication mostly uses simple frame structure and single check mechanism. In a harsh electromagnetic environment, signals are easily disturbed, leading to data transmission errors, and there is a lack of error repair mechanism. Once there is data packet loss or error code, the upgrade fails.

[0015] The application realizes reliability improvement through a specially designed upgrade communication protocol. Multiple check mechanisms replace traditional single check. Through triple verification of frame header check, data segment CRC check, and whole frame check, transmission error data can be accurately identified to avoid writing error data into device firmware. The breakpoint retransmission function is supported. When transmission is abnormal, the corresponding part of data is automatically requested according to the recorded node, without retransmitting the complete upgrade package. Only the unfinished part is continued, greatly reducing the upgrade failure probability caused by interference. (2) Improve multi-device upgrade efficiency and shorten overall upgrade time When the number of data acquisition devices in the system is large (such as 10 or more), the overall upgrade time is greatly shortened compared to the traditional method, and the load of the master device is significantly reduced during the upgrade process, avoiding problems such as master device lag, other business interruption, and other problems caused by centralized upgrade.

[0016] The distributed upgrade process of the application fundamentally solves the bottleneck of upgrade speed. The hierarchical upgrade architecture reduces the interaction pressure of the master device. The master device only needs to complete the upgrade of the end-side upgrade parent device, and then the parent device is responsible for the upgrade of the slave devices in the group. The interaction object of the master device is simplified from "all slave devices" to "a small number of parent devices", the interaction times are reduced, and the communication and computing resources of the master device are greatly released. At the same time, wired communication improves the reliability and speed of group upgrade. The end-side upgrade parent device and the slave devices in the group use wired communication, which is not affected by the electromagnetic environment compared to wireless communication, avoiding interruption of group upgrade. Multi-group parallel upgrade shortens the total time. The 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 single-group upgrade time, achieving upgrade time flattening for multiple devices.

[0017] Meanwhile, the application improves the overall security, avoids the risk of firmware program disclosure, effectively prevents malicious analysis of the upgrade package, avoids core firmware program disclosure, ensures the technical confidentiality and operation safety of the device, and reduces the security risks such as device cracking and data tampering caused by firmware disclosure. The core defect of the existing upgrade method is that the upgrade package structure is simple, lacks an encryption protection mechanism, and an attacker can extract the firmware program in the package through a conventional analysis tool, and then obtain the system core technical parameters.

[0018] The application solves the problem through two key designs: the file encryption technology is used to perform overall encryption processing on the upgrade package, and the original firmware data in the package cannot be obtained by an unauthorized subject without a turning key, so as to block the possibility of analysis and disclosure from the source; in combination with the file verification mechanism, a data integrity verification layer is added on the basis of encryption, which can not only identify damage in the transmission or storage process of the upgrade package, but also prevent attackers from implanting malicious programs by tampering with the upgrade package, forming a double security protection of "encryption + verification". Meanwhile, the "executable + self-release" design of the upgrade package makes the firmware program only temporarily released in the local upgrade process of the device, and the temporary file is automatically cleared after the upgrade is completed, so that the firmware program is prevented from leaving extractable traces in the device storage, and the security is further strengthened. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 It is a system overall communication link architecture diagram.

[0020] Figure 2 It is a master device and upgrade device group upgrade interaction logic block diagram.

[0021] Figure 3 It is an internal partition diagram of the Flash memory of the MCU.

[0022] Figure 4 It is a flowchart of the first embodiment of the slave device upgrade.

[0023] Figure 5 It is a flowchart of the MCU Bootloader upgrade process. DETAILED DESCRIPTION

[0024] Key term explanation and technical abbreviation: SOC: A highly integrated integrated circuit that integrates all key components (CPU, GPU, memory, communication module, etc.) of a complete computer system or electronic system on a single silicon chip.

[0025] MCU: Microcontroller Unit, microcontroller.

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

[0027] The embodiment is adapted to the multi-load upgrading scene of the unmanned aerial vehicle from the aspects of hardware and software.

[0028] In the hardware aspect, an end-side data module is introduced, which works at the unmanned aerial vehicle end, is connected with each load device through a CAN bus, and realizes bidirectional reliable communication between the load devices by constructing a software bus through a software method, thereby solving the problem of unstable communication caused by the dispersed space layout of the load devices. In the software aspect, the structure and use method of the upgrading package are designed to ensure the safety of the upgrading package, a special communication protocol is designed to realize multiple verifications and breakpoint resume transmission functions, thereby solving the problem of communication transmission failure caused by unstable wireless communication between the ground device and the load device, and a distributed collaborative upgrading method of the load end is adopted to classify and schedule the load types and priorities, simultaneously aggregate the same load to form an upgrading device group, upgrade only one load in each device group, and upgrade the remaining loads in the group by the upgraded load, so as to reduce the frequency of wireless communication interaction. The method solves the problems of difficult adaptation of the unmanned aerial vehicle to multiple load types, upgrading failure caused by unstable communication, and low efficiency of multi-load upgrading, and realizes a more reliable and efficient upgrading method.

[0029] The embodiment provides a multi-load distributed collaborative upgrading system of an unmanned aerial vehicle with multiple verifications, as shown in Figure 1 The system includes a master device working at the ground end, performing data interaction with the unmanned aerial vehicle through a wireless communication link, and including a data processing terminal and a ground station of the unmanned aerial vehicle. A plurality of slave devices work at the unmanned aerial vehicle end and serve as load devices of the unmanned aerial vehicle, and include data acquisition modules such as a multispectral camera, an ambient light sensor, a position and attitude sensor, and an air pressure sensor. The load slave devices of the same type form an upgrading device group during upgrading, and the first load device in the upgrading device group that responds to the master device is an end-side upgrading parent device. An end-side data module works at the unmanned aerial vehicle end, provides communication and data processing services for various load devices, communicates with the unmanned aerial vehicle through a wired link such as a USB and a CAN bus, and communicates with the upgrading device group through a software bus such as a CAN bus.

[0030] In order to meet the needs of the multi-device scene, a "software-defined bus" is realized through upper-layer software encapsulation on the basis of the CAN bus hardware, has enhanced functions such as service registration, dynamic ID allocation and scheduling, and protocol customization, and the core is to compensate 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.

[0031] Meanwhile, the unmanned aerial vehicle ground station upgrades and issues an upgrade package, and the main device and multiple slave devices are upgraded according to the upgrade package. The upgrade package mainly consists of five parts, including an upgrade file management program, a main device upgrade file, a slave device upgrade file (including multiple slave device upgrade files), an upgrade script, and an upgrade file configuration file. Meanwhile, the files are encrypted as a whole by using a symmetric encryption algorithm. In this embodiment, the AES-256 symmetric encryption algorithm is used for encryption. In addition to this, the 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, the binary file is packaged, and the extension is.bin.

[0032] The binary file has two main functions: ① It can be used as an executable program to directly run the main device upgrade, and ② The binary file cannot be directly parsed, and after being combined with the symmetric encryption algorithm, the files inside the upgrade package cannot be obtained, thereby improving the security of the upgrade package and preventing attackers from maliciously parsing, tampering with, and implanting malicious programs in the files in the upgrade package.

[0033] Further, the wireless communication link between the main device and the unmanned aerial vehicle is a specially designed upgrade communication protocol, which has multiple verification, supports variable length transmission, supports breakpoint resume, and other characteristics.

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

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

[0036] Table 1: Basic frame structure of the wireless communication link

[0037] The frame header is located at the head of the entire base frame, which contains the key information of the base frame. The SOF field is an identification mark used to identify the start position of the data when the protocol is parsed. The LEN field is the data length of the entire protocol frame, including the frame header, data segment, and frame tail. The SEQ segment is the frame sequence code, which is used for data reliability verification during communication. The master and slave devices send 1 frame of data each time, and the frame sequence code value is incremented by 1, circulating between 0 and 255. When parsing the protocol frame, the frame sequence code can be used to determine whether the protocol frame is repeatedly sent. The FrameType field is the frame type, which is used to identify whether the base frame is sent by the host or the slave. The DeviceType field is the device type identifier, which is used to identify the type of device that sent the base frame. The DeviceID field is the device ID identifier, which is used to confirm the identity information of the device that sent the base frame. The CommandID field is the command function ID, which is used to identify all functions in the protocol. The command ID and the data segment information are strictly corresponding. For example, the command ID 0xC0 represents the upgrade function switch, and the data in the data segment represents the related configuration of the upgrade function switch. The command ID 0xC1 represents the upgrade process interaction command, and the data in the data segment represents the data required for interaction during the upgrade process.

[0038] The CRC16 field is the CRC check code of the frame header, and the calculation range of the check code is the frame header content excluding the CRC16 field. The frame header adds the check code to ensure that the frame data is received and parsed. The frame header is identified by SOF, and CRC16 is checked for the frame header. If the check is passed, it is confirmed that the information in the frame header is correct, and the information in the frame header can be used directly. Since the frame header data is small, the verification speed is fast, and the problem of invalid CRC32 calculation caused by the frame data being scrapped if the data in the frame data is incorrect can be avoided. Using the CRC16 check method of the frame header can identify it in advance and improve the speed of parsing the frame data.

[0039] 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 together 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 use, thereby realizing more complex functions and meeting various needs during the upgrade process. The upgrade process uses two command IDs, as shown in Table 2. 0xC0 is to open the upgrade function. When upgrading is needed, the master device sends the 0xC0 command to the slave device to open the upgrade mode. The slave device replies to the master device with the status of opening the upgrade mode, device type, and device ID information. The master device establishes an upgrade device queue based on the reply information from the slave device, plans the upgrade strategy, and executes the upgrade process through the 0xC1 command, thereby completing the software upgrade.

[0040] Table 2 Protocol upgrade command ID description

[0041] The frame tail part is a CRC32 check code, the calculation range of the CRC32 is the whole data of the frame header and the data segment, and the protocol needs to calculate the CRC32 check code and write it into the frame tail when being packaged, and the CRC32 check code needs to be calculated when the basic frame is analyzed, and then compared with the CRC32 check code of the frame tail, if the check codes are consistent, the whole basic frame data is correct.

[0042] The nested frame is used for upgrading function process interaction, and needs to be used together with the command ID, when the command ID is 0xC1, the data in the data segment needs to use the nested frame. The nested frame is divided into a host part and a slave part, and the protocol structures of the two parts are different. The nested protocol of the host part includes a key frame and a data frame, wherein the key frame is used for the master device to transmit key information of the upgrading file to the slave device, including frame type, frame number, frame length, total packet number of packet transmission, CRC check code of the upgrading file, upgrading file size, and upgrading file name, for details, see Table 3. The data frame of the host part is mainly used for transmitting the upgrading file data to the slave, mainly including frame type, frame number, frame length, and upgrading file data, for details, see Table 4. The nested protocol of the slave part only has a data frame, mainly including frame type, frame number, frame length, and additional data, for details, see Table 5.

[0043] Table 3 Explanation of Key Frame of Nested Frame Protocol of Host

[0044] Table 4 Explanation of Data Frame of Nested Frame Protocol of Host

[0045] Table 5 Explanation of Data Frame of Nested Frame Protocol of Slave

[0046] On the other hand, the embodiment proposes a multi-check unmanned aerial vehicle multi-load distributed cooperative upgrading method, as shown in Figures 2 to 3 After the software upgrading of the master device is completed, the software upgrading of the slave device is started, and the flow of the slave device upgrading data is master device->unmanned aerial vehicle->end side data module->slave device, the master device and the unmanned aerial vehicle communicate through a wireless link, the unmanned aerial vehicle and the end side data module communicate through a wired link, and the end side data module communicates with the slave device through a soft bus, wherein the unmanned aerial vehicle and the end side data module are communication transfer devices, and finally realize the data communication between the master device and the slave device. In the following, the unmanned aerial vehicle and the end side data module are not described separately, and the communication between the master device and the slave device is briefly described, and the specific upgrading flow is as follows: After the master device opens the upgrade function, the file integrity verification algorithm is used to verify the integrity of the upgrade package first to ensure that the upgrade package is not damaged or tampered with. In this embodiment, the BLAKE3 algorithm is mainly used. In addition, SHA-256, SHA-3, MD5, etc. can also be used. After verifying that the upgrade package file is correct, the master device directly runs the upgrade package file. The running parameter needs to be input, which is the security password. After the password is correct, the upgrade package file automatically executes the file release function to release the script file, upgrade file, configuration file, etc. in the upgrade package to the file temporary storage area in the master device.

[0047] After the file release is completed, the released script file is automatically executed. The script compares whether the major version number of the upgrade package and the software version number in the master device are consistent. If they are not consistent, the upgrade process is executed and the next step is entered. If they are consistent, the upgrade is not needed and the script automatically clears the upgrade related files in the temporary storage area.

[0048] After entering the upgrade process, the script first upgrades the software of the master device. The upgrade of the master device mainly includes copying related files and updating configuration information. After the upgrade of the master device is completed, the slave device is upgraded. The master device confirms the slave device to be upgraded according to the configuration file in the upgrade package, and then broadcasts the upgrade request to the slave device through the upgrade protocol.

[0049] After receiving the broadcast information, the slave device compares whether the version number in the information and the software version number of itself are consistent. If they are consistent, the slave device does not need to upgrade and does not need to answer the information. If the version numbers are not consistent, the slave device needs to answer the information. The answer information includes the device ID, device type, etc. After receiving the answer information, the master device establishes an upgrade queue according to the identity identification ID of the slave device. The queue groups different types of devices. The firmware program of the devices of the same type is the same. The master device divides the slave devices of the same type into the same upgrade device group. Each type of slave device has its own corresponding upgrade device group. There can be one or more slave devices in the group. The first answering slave device in the group is set as the end-side upgrade parent device. The master device upgrades the end-side upgrade parent device in turn according to 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 devices in the group individually.

[0050] For an upgrade device group, the number of slave devices is 1~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 uses a one-to-many way to upgrade the remaining slave devices. After sending a package of data, the master device needs to wait for the answer of all devices in the group and synchronously upgrades all devices in the group by using the upgrade queue and the state tracking mechanism. The firmware data is transmitted packet by packet until the upgrade of all devices in the group is completed. In this way, multiple device groups can be upgraded in parallel, the number of wireless communication interactions is reduced, and the upgrade speed is greatly improved.

[0051] 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.

[0052] Upgrade processing mechanism from the device side 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: 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: 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.

[0053] 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, 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. S6. Repeat steps 4 and 5 until all upgrade file data has been received and written to Flash. S7, such asFigure 5 As shown, the configuration parameter partition of the Flash memory is read, the first flag bit of the configuration parameter partition is modified and set, the first flag bit indicates whether the MCU is in the upgrading state; the second flag bit is modified and the value is increased by one, if the second flag bit is odd, the MCU runs the firmware program of the main application program partition, if the second flag bit is even, the MCU runs the firmware program of the auxiliary application program partition, the flag bit is mainly used for switching the running partition of the firmware; S8, the software restarts the upgrading receiving end, first executes the Bootloader program, reads the first flag bit of the parameter configuration partition, confirms the current upgrading state, then modifies the value of the third flag bit and increases the value by one, the default value of the third flag bit is 0, then according to the value of the second flag bit, executes the corresponding firmware program of the application program partition; S9, if the firmware program can run 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 upgrading is completed. If the firmware program does not run normally, the watchdog resets the MCU and re-runs the Bootloader program, the Bootloader program re-executes step 8 and increases the value of the third flag bit by one. If the firmware program does not run normally repeatedly three times, the value of the third flag bit is 3, the Bootloader program resets the first flag bit, sets the value of the third flag bit to 0, and decreases the value of the second flag bit by one, at this time, the upgrading initiator is fed back that the upgrading fails.

[0054] In the second device upgrading embodiment, when the MCU program runs normally, the running program is one of the main / auxiliary application program partitions, which is determined by the variable in the configuration parameter partition. In the upgrading process, the firmware program judges whether the running program is in the main partition or the auxiliary partition, then writes the received upgrading file packet into the other idle program partition, after the upgrading file transmission and verification are completed, the parameter is reconfigured and the address of the executed application program is pointed to the previously idle program partition.

[0055] After the MCU is restarted, the Bootloader upgrading program is first run, that is, steps 7~9 are executed, after the Bootloader upgrading program is run, the configuration parameter is read, then the new program partition is jumped to according to the parameter, and the newly upgraded firmware program is executed. If the newly upgraded program is abnormal, the configuration parameter is modified and the previous program is restored, this embodiment can simultaneously retain the new and old versions of the firmware program, which is used for the firmware recovery after the fault occurs, provides the reliability of the upgrading, cancels the backup partition used in the traditional method, reduces the occupation of the Flash memory, and provides the utilization rate of the Flash.

[0056] The above-described embodiments are merely specific embodiments of the present application, which are used to illustrate the technical solutions of the present application, but not to limit the present application. The protection scope of the present application is not limited to this. Although the present application is 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 think of changes to the technical solutions recorded in the foregoing embodiments, or make equivalent replacements to some technical features therein, within the technical range disclosed by the present application. The modifications, changes or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be covered within the protection scope of the present application.

Claims

1. A multi-load distributed cooperative upgrade system for unmanned aerial vehicles based on multiple checks, characterized by, At least comprising: The main device works at the ground end, interacts with the unmanned aerial vehicle through the wireless communication link, and is responsible for parsing the upgrade package and issuing the upgrade related files when upgrading; A plurality of slave devices work at the unmanned aerial vehicle end and serve as load devices of the unmanned aerial vehicle; when upgrading, the load slave devices of the same type form an upgrade device group, and the first load device in the upgrade device group to respond to the main device is the end side upgrade parent device; The end side data module works at the unmanned aerial vehicle end and provides communication and data processing services for the load device, communicates with the unmanned aerial vehicle through a wired link, and communicates with the upgrade device group through a soft bus.

2. The multiple-check-based UAV multi-load distributed cooperative upgrade system according to claim 1, wherein, The wireless communication link adopts a multi-structure nesting and is divided into a basic frame and a nested frame; the basic frame is divided into three parts: a frame header containing key information of the basic frame, a data segment corresponding to a function data payload in the protocol, and a CRC32 check code as a frame tail; the nested frame is used for upgrade function process interaction, and the nested frame is divided into a host part and a slave part; the nested frame of the host part includes a key frame and a data frame, wherein the key frame is used for the main device to transmit key information of the upgrade file to the slave device, and the data frame is used for transmitting upgrade file data to the slave; The nested frame of the slave part only has a data frame.

3. The multi-check based UAV multi-load distributed cooperative upgrade system according to claim 2, wherein, The key frame of the nested frame of the host part includes frame type, frame number, frame length, total package number of package transmission, CRC check code of the upgrade file, upgrade file size, and upgrade file name; the data frame of the nested frame of the host part includes frame type, frame number, frame length, and upgrade file data; and the data frame of the nested frame of the slave part includes frame type, frame number, frame length, and additional data.

4. The multi-check based UAV multi-load distributed cooperative upgrade system according to claim 1, wherein, The upgrade package is a two-level executable file, which is composed of five parts: an upgrade file management program, a main device upgrade file, a plurality of slave device upgrade files, an upgrade script, and an upgrade file configuration file; and the file is overall encrypted using a symmetric encryption algorithm.

5. The method for multi-load distributed cooperative upgrading of UAVs based on multiple checks, using the system for multi-load distributed cooperative upgrading of UAVs based on multiple checks according to any one of claims 1-4, characterized in that, The method comprises the following steps: The main device checks the upgrade package and runs and releases internal files after passing the check; The main device upgrades its own program according to the configuration file first, and then upgrades the end side upgrade parent device in turn according to 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; For an upgrade device group, the end side upgrade parent device adds the slave devices in the group to an upgrade group, and upgrades the slave devices in the group in a one-to-many manner; the end side upgrade parent device sends upgrade data, and the slave devices respond and send the next group of data until all the upgrade data are transmitted; If a slave device does not respond within a specified time during the upgrade, the slave device is removed from the upgrade queue in the group; after the slave devices in the queue are upgraded, the slave device removed from the upgrade queue is upgraded; The method ends after all the upgrade device groups are upgraded.

6. The multi-check based UAV multi-load distributed cooperative upgrade method according to claim 5, characterized in that, The main control chip of the slave device is an MCU, and the Flash memory of the MCU is divided into four partitions, namely a Bootloader partition, a configuration parameter partition, a main application program partition, and a secondary application program partition.

7. The multi-check based UAV multi-load distributed cooperative upgrade method according to claim 6, characterized in that, When the slave device is upgraded, the interaction mode of the MCU during the upgrade is optimized, and the specific interaction steps are as follows: S1, the device involved in the upgrading process includes an upgrade initiator and an upgrade receiver, the upgrade initiator includes a master device and an end-side upgrade parent device, and the upgrade receiver is mainly a slave device that needs to be upgraded; the upgrade initiator initiates the upgrading process and sends an upgrading instruction to the slave device; S2, after the upgrade receiver receives the start-upgrading instruction sent by the upgrade initiator, the upgrade receiver requests the master key frame from the upgrade initiator and waits for a reply; if no reply is received within 3 seconds, the master key frame is requested again; if the number of re-requests exceeds 10, the upgrading process is exited and the upgrading fails; S3, after the upgrade receiver receives the master key frame data, the data is verified; if the verification fails, the process jumps to step 2; if the verification succeeds, the data in the master key frame is parsed, including the upgrade file name, size, verification code, and total number N of upgrade file packets; S4, the upgrade receiver requests the upgrade file data from the upgrade initiator according to the total number N of packets in the master key frame, starting from the first packet; if no reply is received within 3 seconds, the corresponding packet data is requested again; if the number of re-requests exceeds 10, the upgrading process is exited and the upgrading fails; S5, after the upgrade receiver receives the upgrade file data returned by the upgrade initiator, the data is verified; if the verification passes, the data is written into the idle program partition of the MCU Flash memory; if the verification fails, the corresponding packet data is requested again in step S4; if the number of re-requests exceeds 10, the upgrading process is exited and the upgrading fails; S6, steps S4 and S5 are repeated until all the upgrade file data is received and written into the Flash; S7, the configuration parameter partition of the Flash memory is read, the first flag bit of the configuration parameter partition is modified and set, the first flag bit indicates whether the MCU is in an upgrading state; the second flag bit is modified and its value is incremented by one; if the second flag bit is odd, the MCU runs the firmware program of the application program main partition; if the second flag bit is even, the MCU runs the firmware program of the application program secondary partition; this flag bit is used to switch the firmware running partition; S8, the software restarts the upgrade receiver, first executes the Bootloader program, reads the first flag bit of the parameter configuration partition, and confirms the current upgrading state; then the value of the third flag bit is modified and incremented by one; the default value of the third flag bit is 0; then, according to the value of the second flag bit, the firmware program of the corresponding application program partition is executed; S9, if the firmware program can run normally, the first flag bit in the parameter configuration partition is reset and the value of the third flag bit is set to 0, and the MCU upgrading is completed; if the firmware program does not run normally, the watchdog resets the MCU and the Bootloader program is run again; the Bootloader program re-executes S8 and increments the third flag bit by one; if the firmware program does not run normally for three times, the value of the third flag bit is 3, the Bootloader program resets the first flag bit, sets the value of the third flag bit to 0, and decrements the second flag bit by one; at this time, the upgrade initiator is fed back that the upgrading fails. ​

Images