Upgrading method of unmanned aerial vehicle relay control system, control station, medium and product

Abstract

The invention discloses an upgrading method of an unmanned aerial vehicle relay control system, a control station, a medium and a product, and relates to the technical field of system upgrading, the method is applied to an unmanned aerial vehicle relay control station deployed with the unmanned aerial vehicle relay control system, and the unmanned aerial vehicle relay control system is set to be an active zone and an inactive zone. The method comprises the steps of obtaining system upgrading data in response to a system upgrading instruction which is sent by a control center and carries unmanned aerial vehicle flight state data, and determining an upgrading time window according to the unmanned aerial vehicle flight state data; updating the system program in the inactive partition based on the system upgrading data; and executing a restarting operation in the upgrading time window, switching the inactive partition after the system program is updated into a new active partition after restarting, and switching the active partition into a new inactive partition. According to the invention, upgrading of the unmanned aerial vehicle relay control system can be realized on the premise of not interrupting the inspection task of the unmanned aerial vehicle.

Description

Technical Field

[0001] This application relates to the field of system upgrade technology, and in particular to an upgrade method, control station, medium and product for an unmanned aerial vehicle (UAV) relay control system. Background Technology

[0002] Currently, drones are widely used in long-distance inspection scenarios such as highways, power lines, and pipelines. Since drones typically have long flight paths, in order to ensure the reliability and real-time requirements of data transmission, it is often necessary to use drone relay control stations deployed along the drone's flight path to support long-distance communication between the drone and the drone control center.

[0003] Currently, the drone relay control systems deployed at these relay control stations generally rely on manual on-site operation for system software upgrades, which is inefficient. During the upgrade process, they may also interfere with or even interrupt ongoing drone inspection tasks, affecting the continuity of the overall inspection tasks.

[0004] In summary, how to upgrade the UAV relay control system without interrupting UAV inspection missions has become a pressing technical problem that needs to be solved in this field.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide an upgrade method, control station, medium, and product for a UAV relay control system, which aims to upgrade the UAV relay control system without interrupting UAV inspection tasks.

[0007] To achieve the above objectives, this application proposes an upgrade method for a UAV relay control system, applied to a UAV relay control station deployed with a UAV relay control system, wherein the UAV relay control system is configured with active and inactive partitions, and the upgrade method for the UAV relay control system includes: In response to a system upgrade command sent by the control center carrying UAV flight status data, the system upgrade data is acquired, and an upgrade time window is determined based on the UAV flight status data. Update the system programs in the inactive partition based on the system upgrade data; Perform a restart operation within the upgrade time window, and after restarting, switch the inactive partition after updating the system program to a new active partition, and then switch the active partition to a new inactive partition.

[0008] In one embodiment, the step of determining the upgrade time window based on the UAV flight status data includes: Determine whether the drone is within the communication coverage area of ​​the drone relay control station based on the drone flight status data; If the drone is within the communication coverage area, the first time point when the drone leaves the communication coverage area and the second time point when the drone enters the communication coverage area again are predicted based on the drone's flight status data. The interval between the first time point and the second time point is determined as the upgrade time window. If the drone is not within the communication coverage area, the third time point at which the drone will enter the communication coverage area is predicted based on the drone's flight status data, and the upgrade time window is determined based on the current time point, the third time point, and a preset upgrade duration threshold.

[0009] In one embodiment, the step of determining the upgrade time window based on the current time point, the third time point, and a preset upgrade duration threshold includes: Calculate the time difference between the current time point and the third time point; If the time difference is greater than the preset upgrade duration threshold, then the interval between the current time point and the third time point is determined as the upgrade time window; If the time difference is less than or equal to the upgrade duration threshold, then based on the UAV flight status data, the fourth time point when the UAV leaves the communication coverage area and the fifth time point when the UAV re-enters the communication coverage area are predicted, and the interval between the fourth time point and the fifth time point is determined as the upgrade time window.

[0010] In one embodiment, the step of obtaining system upgrade data includes: Send an upgrade query request carrying the system identifier and current version information to the preset OTA (Over the Air) server; Receive upgrade package metadata returned by the OTA server based on the upgrade query request; Download system upgrade data based on the upgrade package metadata, and verify the system upgrade data.

[0011] In one embodiment, the step of updating the system program in the inactive partition based on the system upgrade data includes: Write the system upgrade data to the inactive partition; Under the control of the preset bootloader, hash verification is performed on the inactive partition where the system upgrade data has been written; If the hash verification passes, the system program update for the inactive partition is confirmed to be effective.

[0012] In one embodiment, after the steps of switching the inactive partition (after updating the system program) to a new active partition and switching the active partition to a new inactive partition, the method further includes: If the upgrade is successful from the new active partition, an upgrade success message is sent to the control center. In response to the service function test command issued by the control center based on the upgrade success information, the system performs a function test after establishing a communication connection with the UAV and sends the test results to the control center.

[0013] In one embodiment, after the steps of switching the inactive partition (after updating the system program) to a new active partition and switching the active partition to a new inactive partition, the method further includes: If booting from the new active partition fails, the system will boot from the new inactive partition under the control of the bootloader and send an upgrade failure alarm message to the control center.

[0014] In addition, to achieve the above objectives, this application also proposes a drone relay control station, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the drone relay control system upgrade method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the upgrade method for the UAV relay control system described above.

[0016] In addition, to achieve the above objectives, this application also proposes a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the upgrade method for the UAV relay control system described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: In this application, after receiving a system upgrade command carrying UAV flight status data from the control center, the UAV relay control system determines the upgrade time window based on the UAV flight status data. This ensures that the system upgrade operation is limited to the period when the UAV has left the communication coverage area of ​​the relay control system, thereby achieving system upgrade without interrupting the UAV's scheduled inspection task. At the same time, relying on the dual-partition structure of the UAV relay control system, the upgrade data is written to the inactive partition during the upgrade process, and the active partition is switched after restarting. This achieves the effect of upgrading the UAV relay control system without interrupting the UAV inspection task. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the upgrade method for the UAV relay control system of this application. Figure 2 This is a schematic diagram of the system upgrade data acquisition process provided in Embodiment 1 of the upgrade method for the UAV relay control system of this application; Figure 3 This is a schematic diagram illustrating the process of determining the upgrade time window for Embodiment 2 of the upgrade method for the UAV relay control system of this application; Figure 4 This is a schematic diagram of the interaction flow of the upgrade method for the UAV relay control system according to an embodiment of this application; Figure 5 This is a schematic diagram of the equipment structure involved in the UAV relay control station in the embodiments of this application.

[0021] Figures 4 to 5 Explanation of icon numbers:

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] Currently, drones are widely used in long-distance inspection scenarios such as highways, power lines, and pipelines. Since drones typically have long flight paths, in order to ensure the reliability and real-time requirements of data transmission, it is often necessary to use drone relay control stations deployed along the drone's flight path to support long-distance communication between the drone and the drone control center.

[0026] Currently, the drone relay control systems deployed at these relay control stations generally rely on manual on-site operation for system software upgrades, which is inefficient. During the upgrade process, they may also interfere with or even interrupt ongoing drone inspection tasks, affecting the continuity of the overall inspection tasks.

[0027] In summary, how to upgrade the UAV relay control system without interrupting UAV inspection missions has become a pressing technical problem that needs to be solved in this field.

[0028] To address the aforementioned technical problems, this application embodiment enables the UAV relay control system to determine the upgrade time window based on the UAV flight status data after receiving a system upgrade command from the control center. This ensures that the system upgrade operation is limited to the period when the UAV has left the communication coverage area of ​​the relay control system, thereby achieving system upgrades without interrupting the UAV's scheduled inspection tasks. Furthermore, relying on the dual-partition structure of the UAV relay control system, the upgrade process involves writing system upgrade data to the inactive partition and switching to the active partition after a restart, achieving the effect of upgrading the UAV relay control system without interrupting the UAV inspection tasks.

[0029] It should be noted that the execution subject of the upgrade method of the UAV relay control system in this embodiment is the UAV relay control station (hereinafter referred to as the relay control station) that is equipped with the UAV relay control system (hereinafter referred to as the system). The relay control station is arranged in a node-like manner along the UAV inspection route, and can be an embedded device or an industrial control computer with a specific communication interface and reliable computing capabilities.

[0030] The following presents a first embodiment of the upgrade method for the UAV relay control system of this application. (Refer to...) Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the upgrade method for the UAV relay control system of this application.

[0031] In this embodiment, the upgrade method for the UAV relay control system includes steps S10 to S30: Step S10: In response to the system upgrade command sent by the control center carrying UAV flight status data, obtain system upgrade data and determine the upgrade time window based on the UAV flight status data; It should be noted that the UAV relay control system to be upgraded in this embodiment is set to a dual-partition architecture. The active partition in the dual partition refers to the area where the operating system and applications are currently running, which is responsible for maintaining the normal operation and service of the system. The inactive partition refers to the area that is currently in standby mode. Its internal programs are not executed when the system is running normally, and it is specifically used to receive and store new system programs during the upgrade process.

[0032] The system receives a system upgrade command from the control center. This command encapsulates the UAV's flight status data, which may include, but is not limited to, the UAV's real-time geographic coordinates, flight speed, heading angle, and pre-planned flight path and time points. Upon receiving the command, the system first parses the UAV's status data. Then, based on the parsed flight status data, through internal calculations and logical judgments, it autonomously determines a suitable upgrade time window for performing the upgrade operation. This upgrade time window is essentially a safe period of time during which the system determines it will not engage in business communication with the UAV and will not interfere with the inspection task.

[0033] It's worth noting that the system employs a dual-partition architecture, allowing upgrade processes such as downloading upgrade packages and performing verifications to be completed during normal system operation without interfering with existing drone communication services. However, after the upgrade package is written to the inactive partition, a system restart and partition switching are necessary to complete the final system update. This process temporarily puts the system offline, preventing normal interaction with the drones. Therefore, restarting and partition switching operations must be strictly limited to the upgrade time window to ensure they do not conflict with the drone's inspection tasks.

[0034] Step S20: Update the system programs in the inactive partition based on the system upgrade data; After determining the upgrade time window, the system obtains system upgrade data from a remote OTA server. This data is usually in the form of an encrypted and signed upgrade package, which contains the new version of the system image file. After obtaining the complete upgrade data and completing the necessary security verification, the system updates this data to the inactive partition, that is, overwrites or writes the partition with the new version of the system program.

[0035] Step S30: Perform a restart operation within the upgrade time window, and after restarting, switch the inactive partition after updating the system program to the new active partition, and switch the active partition to the new inactive partition.

[0036] Within the pre-determined upgrade time window, the system performs a reboot. The reboot process is handled by the system's underlying bootloader. After completing hardware initialization, the bootloader, based on preset priority configurations, switches the inactive partition that has been updated and is ready to become the new active partition, and loads and starts the new system from it. At the same time, the original active partition is marked as an inactive partition, to be used as the receiving partition for the next upgrade or as a backup for emergency rollback.

[0037] In this embodiment, by deeply integrating the rhythm of the drone inspection operation with the system upgrade process, the timing of system upgrades is no longer randomly selected or simply triggered at set times, but intelligently driven by the actual working status of the drones. This fundamentally ensures that the upgrade operation always occurs during periods when the system has no service tasks, thus achieving zero interruption of the drone inspection task. Simultaneously, combined with a dual-partition switching mechanism, the entire upgrade and switching process is seamless for running services, improving the automation and reliability of system maintenance. This effectively solves the problems of low efficiency, high cost, and potential interruption of critical services caused by manual on-site upgrades of distributed relay systems.

[0038] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, in a feasible embodiment, such as... Figure 2 As shown, the step of "obtaining system upgrade data" in step S10 may include steps a10 to a30: Step a10: Send an upgrade query request carrying the system identifier and current version information to the preset OTA server; It should be noted that the OTA server (hereinafter referred to as the server) is a dedicated server deployed in a remote network environment for storing, managing, and distributing system upgrade packages. The control center uploads the upgrade packages (full packages / differential packages) to the server via a web backend or FTP tool. The system sends an upgrade query request to the server, carrying the system identifier and current version information. The system identifier is the system's unique serial number or MAC address, used by the server to identify a specific system. The current version information is the version number of the system software currently running within the system, used by the server to determine whether the system needs an upgrade and what type of upgrade package is required.

[0039] Step a20: Receive the upgrade package metadata returned by the OTA server based on the upgrade query request; After receiving a query request, the server will perform system legitimacy authentication and compare its version information with the latest version on the server. If an available update is found, the server will return upgrade package metadata. This metadata is not the upgrade package itself, but includes descriptive information such as the target version number, upgrade package size, download link address, digital signature information, and hash values ​​(such as MD5 or SHA256) used for integrity verification.

[0040] Step a30: Download system upgrade data based on upgrade package metadata and verify the system upgrade data.

[0041] Upon receiving the metadata, the system immediately downloads the system upgrade data based on the upgrade package metadata. Specifically, the system parses the download link in the metadata and downloads the complete upgrade package file from the OTA server to its local cache via secure protocols such as HTTPS (Hypertext Transfer Protocol). After downloading, integrity verification and secure signature verification are performed. Integrity verification involves the system calculating the hash value of the downloaded upgrade package and comparing it with the hash value provided in the metadata to ensure that the file has not been corrupted or tampered with during transmission. Secure signature verification uses the server's public key pre-installed in the system to decrypt and verify the digital signature attached to the upgrade package, confirming that the upgrade package indeed originates from a legitimate server and is not from a malicious third party. Only system upgrade data that passes all verifications is considered valid and allowed for subsequent partition update operations.

[0042] This ensures that the source of system upgrade data is reliable, the transmission is complete, and it has not been tampered with, preventing system startup failures, functional abnormalities, and even security vulnerabilities caused by upgrade data problems.

[0043] like Figure 3 As shown, the step S10, "determining the upgrade time window based on UAV flight status data," may include steps S101 to S103: Step S101: Determine whether the UAV is within the communication coverage range of the UAV relay control station based on the UAV flight status data; Taking any relay control station as an example, its communication coverage area refers to the effective spatial area in which the wireless communication link established by the current system can stably exchange data with the UAV. Its range is determined by the relay control station's transmission power, antenna gain, environmental factors, etc. The judgment can be made by parsing the UAV's real-time coordinates in the flight status data and calculating whether the distance between the UAV and the coordinates of this relay control station is less than the communication radius.

[0044] Step S102: If the drone is within the communication coverage area, predict the first time point when the drone leaves the communication coverage area and the second time point when the drone enters the communication coverage area again based on the drone's flight status data, and determine the interval between the first time point and the second time point as the upgrade time window. If the drone is within the communication coverage area, it means the relay control station is currently providing data relay services to the drone and is in a busy state, during which upgrades are not permitted. Therefore, the system needs to predict, based on flight status data, the first point in time when the drone is expected to fly out of the relay control station's communication coverage area, and the second point in time when the drone is expected to re-enter the relay control station's communication coverage area after completing its subsequent flight segment. The interval between these two points in time is the period during which the relay control station is in a deterministically idle state, and thus can be determined as the upgrade time window.

[0045] Specifically, the calculation steps for the first time point (the predicted time when the UAV leaves the communication coverage area of ​​the current relay control station) are as follows: When the UAV is within the communication coverage area of ​​this relay control station, based on the real-time geographical coordinates in the UAV's flight status data and the communication coverage geographical model preset by this relay control station (usually simplified to a spherical or cylindrical area centered on the station site with the maximum reliable communication distance as the radius), calculate the shortest spatial distance from the UAV's current position to the boundary of the model. Next, obtain the UAV's current flight speed from the flight status data, divide the calculated distance from the UAV to the boundary of the communication coverage area by its current radial speed away from the relay control station to obtain the expected flight time interval, and add the current system timestamp to this flight time interval to obtain the predicted first time point.

[0046] The calculation steps for the second time point (the time when the UAV will next enter the communication coverage area) are as follows: When the UAV is within the communication coverage area of ​​the relay control station, a preset flight plan is invoked. This plan contains a series of waypoints and their coordinates arranged in chronological order. The plan is traversed to find the first waypoint that is later than the first time point and whose geographical location falls within the communication coverage area of ​​this relay control station. If a waypoint that meets the conditions is found, the planned arrival time of that waypoint is determined as the second time point. If the coverage area boundary is located on the flight segment between two waypoints, the system calculates the spatial intersection of the UAV trajectory and the communication area boundary using a linear interpolation algorithm based on the coordinates of these two waypoints, the planned time, and the average cruise speed of the UAV. The system then calculates the precise time of arrival at the intersection point based on the speed. This time is the second time point.

[0047] Step S103: If the drone is not within the communication coverage area, predict the third time point when the drone will enter the communication coverage area based on the drone's flight status data, and determine the upgrade time window based on the current time point, the third time point, and the preset upgrade duration threshold.

[0048] If the drone is not within the communication coverage area, it indicates that the drone may be within the communication coverage area of ​​another relay control station, and this relay control station is in an idle period, thus possessing potential upgrade conditions. In this case, the system also predicts the third time point at which the drone will next enter the communication coverage area of ​​this relay control station based on flight status data. Then, combining the current time point, the predicted third time point, and a pre-set upgrade duration threshold, the system upgrade window is finally determined. The upgrade duration threshold is an empirical or calculated value representing the shortest safe time required to complete the entire upgrade process from downloading and verification to writing.

[0049] Specifically, the calculation steps for the third time point (the predicted time when the UAV will enter the communication coverage area next when it is not currently within the communication coverage area of ​​the relay control station) are as follows: Starting from the current moment, search for the first waypoint in the flight plan where the UAV coordinates fall into the communication coverage area. If such a waypoint exists, its planned arrival time is the third time point.

[0050] Therefore, the upgrade time window of the system in each relay control station is determined according to the real-time or predicted working status of the UAV, ensuring that the system upgrade will not affect the UAV inspection mission and guaranteeing the reliability of the system operation.

[0051] In one feasible embodiment, the step of "determining the upgrade time window based on the current time point, the third time point, and the preset upgrade duration threshold" in step S103 may include steps S1031 to S1033: Step S1031: Calculate the time difference between the current time point and the third time point; Calculate the time difference between the current time point and the predicted third time point when the drone will next enter the communication coverage area of ​​this relay control station. This difference represents the continuous idle time that this relay control station has before the arrival of the drone.

[0052] Step S1032: If the time difference is greater than the preset upgrade duration threshold, then the interval between the current time point and the third time point is determined as the upgrade time window. The determined time difference is compared with a preset upgrade duration threshold. If the time difference is greater than the preset upgrade duration threshold, it means that the current system has sufficient idle time to ensure that the entire upgrade process is completed before the drone arrives. Therefore, the system directly determines the interval between the current time point and the third time point as the upgrade time window, meaning that the system upgrade can start immediately, making full use of the current idle period.

[0053] Step S1033: If the time difference is less than or equal to the upgrade duration threshold, then predict the fourth time point when the drone leaves the communication coverage area and the fifth time point when the drone re-enters the communication coverage area based on the drone flight status data, and determine the interval between the fourth time point and the fifth time point as the upgrade time window.

[0054] If the time difference is less than or equal to the upgrade duration threshold, it indicates that the current idle period is too short to safely complete the upgrade. If the upgrade is forced, the drone may enter the area before the upgrade is completed, causing the upgrade process to be interrupted or affecting the upcoming inspection task. In this case, the system will abandon the current short idle period and perform the upgrade during the next idle period. Specifically, the system predicts the fourth time point when the drone will leave the communication coverage area after entering it this time, based on flight status data. The fourth time point is the time when the drone leaves the communication coverage area in the next inspection cycle. The system also predicts the fifth time point when the drone will re-enter the communication coverage area during subsequent flights. The fifth time point is the time when the drone will next enter the communication coverage area of ​​the relay control station after the fourth time point. The calculation of the fourth and fifth time points can refer to the calculation principles of the first and second time points mentioned above, which will not be repeated in this embodiment. The interval between the fourth and fifth time points is the next longer, deterministic business idle window. The system determines this interval as the upgrade time window, thereby safely postponing the upgrade operation to the next appropriate time.

[0055] Therefore, by introducing a comparison decision with the upgrade duration threshold, the system not only knows when it is idle, but also can determine whether the idle period is sufficient to safely complete the upgrade, avoiding the risks of hastily starting the upgrade when time is tight, and enhancing the stability of the entire upgrade process.

[0056] In one feasible embodiment, step S20 may include steps S201 to S203: Step S201: Write the system upgrade data to the inactive partition; Step S202: Under the control of the preset bootloader, perform hash verification on the inactive partition where system upgrade data has been written; The complete system upgrade data, which has passed security verification, is written to the inactive partition via a system call. After the write is complete, the system does not immediately perform a partition switch. Instead, the bootloader controls the hash verification of the inactive partition containing the system upgrade data. The bootloader is a piece of low-level code stored in the system that runs first after the system is powered on, responsible for initializing the hardware and loading the operating system. Here, the bootloader is configured to perform hash verification on the data within a partition before allowing booting from that partition.

[0057] Specifically, the bootloader reads all or critical system data that was just written to the inactive partition, recalculates its hash value using the same hash algorithm (such as SHA256) as on the server side, and compares the result with the expected hash value pre-stored in the upgrade package metadata or generated before writing to the partition. The purpose of hash verification is to ensure that the data has been written to the inactive partition completely and without error, eliminating data corruption caused by bit flips, bad blocks on the storage medium, or other reasons during the write process.

[0058] Step S203: If the hash verification passes, the system program update for the inactive partition is confirmed to be effective.

[0059] If the hash verification passes, it indicates that the data in the inactive partition is intact and completely consistent with expectations. At this point, it can be determined that the system program update in the inactive partition has taken effect. It can be marked as verified or pending activation by the system bootloader, which means that the new system program in the partition is ready and can be used for the next boot.

[0060] If verification fails, it indicates a problem with the write process, and the data in the inactive partition is unreliable. This usually triggers an error handling process, such as undoing the write operation and restoring the original system program on that partition.

[0061] Therefore, after the system upgrade data writing operation, the system bootloader verifies the data integrity to ensure that the system image to be switched and started is absolutely complete, thereby reducing the risk of system failure due to upgrade data writing errors and ensuring the upgrade success rate.

[0062] In one feasible embodiment, steps S40 to S50 may be included after step S30: Step S40: If the startup from the new active partition is successful, send an upgrade success message to the control center; After the system successfully restarts and boots from the new active partition (i.e., the inactive partition that has just been upgraded), the system will send an upgrade success message to the control center to inform the remote control center that the upgrade operation has been successfully completed and the new system is online.

[0063] In step S50, in response to the business function test instruction issued by the control center based on the upgrade success information, the system performs a function test after establishing a communication connection with the UAV and sends the test results to the control center.

[0064] A successful upgrade message only means that the system can start normally, and does not completely equate to the fact that the drone data relay it undertakes is completely normal. Therefore, after receiving the upgrade success message, the control center can proactively issue a business function test command to initiate a round of targeted functional verification.

[0065] In response to the business function test command, the system begins executing functional tests. The core of the test is establishing a real communication connection with the drone, because the fundamental value of the relay control system lies in serving drones. The test content may include, but is not limited to, establishing a communication link with the drone, testing the data forwarding rate and stability, or retrieving video streams from the drone's camera to check image transmission quality. After executing these tests, the system sends the test results (such as whether the connection was successfully established, the forwarding rate value, and whether the video stream is smooth and without lag) back to the control center.

[0066] This ensures that the relay control station is immediately put back into inspection mode after the upgrade, avoiding the risk of undetected service anomalies caused by some hidden compatibility issues or configuration errors, and improving the reliability of system upgrade and maintenance.

[0067] In one possible embodiment, step S30 may be followed by step S60: In step S60, if booting from the new active partition fails, the system boots from the new inactive partition under the control of the bootloader and sends an upgrade failure alarm message to the control center.

[0068] If booting from the new active partition fails, the system will boot from the new inactive partition under the control of the bootloader, and send an upgrade failure alarm message to the control center. Boot failure can manifest in various ways, such as the system getting stuck during startup, repeated restarts, or core services crashing and failing to load. These will be detected by the system's underlying monitoring mechanisms or the bootloader. Once a boot failure is detected, the bootloader executes a rollback strategy, i.e., booting from the new inactive partition. This new inactive partition was the partition that ran the old version of the system as the active partition before this upgrade. After the switch, it is marked as inactive, but the intact old system image within it still exists. The bootloader modifies the boot configuration, re-assigning priority to this partition containing the old system, and loads and boots the system from it. Simultaneously, the system sends an upgrade failure alarm message to the control center, containing necessary error codes or a brief description, so that remote maintenance personnel are promptly informed that the upgrade failed and understand the stage of the failure.

[0069] Therefore, during the system upgrade process, the system can either successfully switch to the new version or completely revert to the original stable version, ensuring that the system can always provide at least one usable version for external services. This ensures that even if an unexpected situation occurs during the upgrade, the drone relay control system can automatically restore services in a very short time, minimizing the potential risk of business interruption.

[0070] For example, to help understand the implementation process of the upgrade method for the UAV relay control system obtained by combining this embodiment with the above embodiment one, please refer to... Figure 4 , Figure 4 A schematic diagram illustrating the interaction logic between a drone, a drone relay control system, a control center, and an OTA server is provided, specifically: The UAV relay control system 201 is deployed in UAV relay control stations 20, which are nodally deployed along the flight path of UAV 10. The UAV relay control station 20 also includes a wireless range extender module 202 and a network communication module 203. The UAV relay control system 201 includes a system control module 2011 and an OTA module 2012. The wireless range extender module 202 communicates wirelessly with UAV 10, and the network communication module 203 communicates with the control center 30 and the OTA server 40 via fiber optic Ethernet.

[0071] For each UAV relay control station 20, when an upgrade task is initiated, the control center 30 sends a system upgrade command to the UAV relay control station 20 via fiber optic Ethernet through the network communication module 203 of the UAV relay control station 20. This command includes the upgrade order and UAV flight status data. After receiving the command, the system control module 2011 of the UAV relay control system 201 calculates the available upgrade time window based on the flight status data in the command. Then, the system control module 2011 notifies the OTA module 2012 to start working. The OTA module 2012 then initiates a secure HTTPS query request to the remote OTA server 40 via fiber optic Ethernet through the network communication module 203. The request carries the unique identifier of the UAV relay control station 20 and the current software version. After verifying the request, the OTA server 40 returns the corresponding upgrade package metadata to the OTA module 2012. The OTA module 2012 downloads the complete upgrade package from the OTA server 40 based on the metadata. After the download is completed, the upgrade package is verified for integrity and digital signature to ensure that the data source is reliable and has not been tampered with. After successful verification, the system control module 2011 will temporarily suspend non-core background tasks. Subsequently, with the support of the underlying bootloader, the OTA module 2012 will write the upgrade package data to the currently inactive partition. After the writing is completed, the bootloader will immediately perform a hash check on the partition data. If the check passes, the partition will be marked as pending activation.

[0072] Throughout the entire initial download, verification, and writing process, if the UAV 10 is within the communication coverage area of ​​the UAV relay control station 20, the UAV relay control station 20 maintains a normal communication connection with the UAV 10 through the wireless range extender module 202, forwarding control commands and image / remote sensing data. The upgrade preprocessing has no impact on the inspection business.

[0073] When the upgrade window arrives, the system control module 2011 triggers a system restart. After the bootloader starts, it reads the marker indicating that the inactive partition is awaiting activation, switches it to the new active partition, and loads the new system from it. The original active partition is then marked as inactive. If the new system starts successfully, the system control module 2011 sends an upgrade success message to the control center 30 via the network communication module 203. Afterward, the control center 30 can issue service function test commands. Upon receiving the command, the system control module 2011 re-establishes a connection with the UAV 10 via the wireless range extender module 202, performs a brief communication self-test or data forwarding test, and feeds the test results back to the control center 30, thus completing the final verification at the service level.

[0074] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the upgrade method of the UAV relay control system of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0075] This application also provides a drone relay control station, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the drone relay control system upgrade method described in the above embodiments.

[0076] Specifically, the UAV relay control station is a physical device deployed along the UAV inspection route (such as along high-voltage power lines, oil and gas pipelines, or highways), serving as a communication relay node between the UAV and the remote control center, and possessing the ability to perform autonomous system upgrades using the upgrade method of the UAV relay control system described above.

[0077] The following is for reference. Figure 5 It shows a schematic diagram of a drone relay control station 20 suitable for implementing embodiments of this application. Figure 5 The drone relay control station 20 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0078] like Figure 5 As shown, the UAV relay control station 20 mainly consists of two parts: a hardware platform and a software system running on it. The hardware platform constitutes the physical entity of the control station and provides the operating foundation for the software system. Its core typically includes: Processor 204: For example, an embedded processor 204 based on ARM or x86 architecture or an industrial-grade single-board computer, serving as the computing and control center 30 of the entire control station.

[0079] Memory 205: Includes non-volatile memory 205 (such as eMMC, solid-state drive), and is physically or logically divided into at least two system partitions, namely an active partition and an inactive partition, for storing operating system, application and upgrade data.

[0080] Wireless range extender module 202: Typically a high-power, high-sensitivity wireless transceiver operating in a specific frequency band (such as 2.4GHz or 5.8GHz), equipped with a directional or omnidirectional antenna. This module is specifically responsible for establishing a long-distance wireless link with the UAV 10 flight platform in flight, enabling uplink transmission of control commands and downlink reception of images and telemetry data from the UAV 10.

[0081] Network communication module 203: Typically a fiber optic Ethernet interface or cellular network module (such as 5G / 4G CPE), used to establish a stable and high-speed data connection with the remote control center 30 and OTA server 40 via wired fiber optic or wireless public network.

[0082] Power and Management Module 206: Provides stable power to all components and may include backup batteries or solar charging systems to ensure continuous operation in field environments.

[0083] The software system, namely the UAV relay control system 201 mentioned above, is integrated and runs on the processor 204 of the aforementioned hardware platform. This system software is not a standalone application, but rather is deeply integrated into the hardware as device firmware or a core backend service.

[0084] Although the diagram shows a UAV relay control station with various modules, it should be understood that implementation or possession of all the modules shown is not required. More or fewer modules may be implemented alternatively.

[0085] In particular, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from memory, and when executed by a processor, performs the functions defined in the methods of the embodiments disclosed in this application.

[0086] Compared with the prior art, the beneficial effects of the UAV relay control station provided in this application embodiment are the same as the beneficial effects of the UAV relay control system upgrade method provided in the above embodiment, and other technical features in the UAV relay control station are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0087] It should be understood that the various parts disclosed in the embodiments of this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0088] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0089] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the upgrade method of the UAV relay control system in the above embodiments.

[0090] The computer-readable storage medium provided in this application embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0091] The aforementioned computer-readable storage medium may be included in the system or may exist independently and not assembled into the system.

[0092] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by a system, cause the system to perform the functions defined in the methods of the embodiments disclosed in this application.

[0093] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0095] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0096] The readable storage medium provided in this application embodiment is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for executing the upgrade method of the above-described UAV relay control system. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application embodiment are the same as the beneficial effects of the upgrade method of the UAV relay control system provided in the above-described embodiment, and will not be repeated here.

[0097] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the status indication method described above. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the status indication method provided in the above embodiments, and will not be repeated here.

[0098] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An upgrade method for an unmanned aerial vehicle (UAV) relay control system, characterized in that, An upgrade method for a UAV relay control station deployed with an UAV relay control system, wherein the UAV relay control system is configured with active and inactive zones, includes: In response to a system upgrade command sent by the control center carrying UAV flight status data, the system upgrade data is acquired, and an upgrade time window is determined based on the UAV flight status data. Update the system programs in the inactive partition based on the system upgrade data; Perform a restart operation within the upgrade time window, and after restarting, switch the inactive partition after updating the system program to a new active partition, and then switch the active partition to a new inactive partition.

2. The upgrade method for the UAV relay control system as described in claim 1, characterized in that, The step of determining the upgrade time window based on the UAV flight status data includes: Determine whether the drone is within the communication coverage area of ​​the drone relay control station based on the drone flight status data; If the drone is within the communication coverage area, the first time point when the drone leaves the communication coverage area and the second time point when the drone enters the communication coverage area again are predicted based on the drone's flight status data. The interval between the first time point and the second time point is determined as the upgrade time window. If the drone is not within the communication coverage area, the third time point at which the drone will enter the communication coverage area is predicted based on the drone's flight status data, and the upgrade time window is determined based on the current time point, the third time point, and a preset upgrade duration threshold.

3. The upgrade method for the UAV relay control system as described in claim 2, characterized in that, The step of determining the upgrade time window based on the current time point, the third time point, and the preset upgrade duration threshold includes: Calculate the time difference between the current time point and the third time point; If the time difference is greater than the preset upgrade duration threshold, then the interval between the current time point and the third time point is determined as the upgrade time window; If the time difference is less than or equal to the upgrade duration threshold, then based on the UAV flight status data, the fourth time point when the UAV leaves the communication coverage area and the fifth time point when the UAV re-enters the communication coverage area are predicted, and the interval between the fourth time point and the fifth time point is determined as the upgrade time window.

4. The upgrade method for the UAV relay control system as described in claim 1, characterized in that, The steps for obtaining system upgrade data include: Send an upgrade query request carrying the system identifier and current version information to the preset OTA server; Receive upgrade package metadata returned by the OTA server based on the upgrade query request; Download system upgrade data based on the upgrade package metadata, and verify the system upgrade data.

5. The upgrade method for the UAV relay control system as described in claim 1, characterized in that, The step of updating the system program in the inactive partition based on the system upgrade data includes: Write the system upgrade data to the inactive partition; Under the control of the preset bootloader, hash verification is performed on the inactive partition where the system upgrade data has been written; If the hash verification passes, the system program update for the inactive partition is confirmed to be effective.

6. The upgrade method for the UAV relay control system as described in claim 1, characterized in that, After the steps of switching the inactive partition (after updating the system program) to a new active partition and switching the active partition to a new inactive partition, the method further includes: If the upgrade is successful from the new active partition, an upgrade success message is sent to the control center. In response to the service function test command issued by the control center based on the upgrade success information, the system performs a function test after establishing a communication connection with the UAV and sends the test results to the control center.

7. The upgrade method for the UAV relay control system as described in claim 1, characterized in that, After the steps of switching the inactive partition (after updating the system program) to a new active partition and switching the active partition to a new inactive partition, the method further includes: If booting from the new active partition fails, the system will boot from the new inactive partition under the control of the bootloader and send an upgrade failure alarm message to the control center.

8. A UAV relay control station, characterized in that, The UAV relay control station includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the upgrade method for the UAV relay control system as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the upgrade method of the UAV relay control system as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the upgrade method for the unmanned aerial vehicle relay control system as described in any one of claims 1 to 7.

Images