An unmanned aerial vehicle task scheduling method and system supporting abnormal self-healing and hierarchical breakpoint continuation

Abstract

The application discloses a kind of unmanned aerial vehicle task scheduling method and system supporting abnormal self-healing and hierarchical breakpoint continuation, belong to unmanned aerial vehicle task scheduling technical field.To solve the reliability problem of task scheduling under unmanned aerial vehicle automatic airport or unmanned aerial vehicle normalizing inspection scene.The application obtains the unmanned aerial vehicle task to be dispatched and corresponding task rule, obtains the task that can be automatically dispatched;Task dispatching preemption is executed using database update statement based on version number or original state condition, and the task that has been dispatched is obtained;Task details are created, a deduplication key is generated, and a task queue is created;The head node of the queue is selected, and the scheduler applies a distributed lock with the device identifier of the unmanned aerial vehicle as the granularity to obtain the unmanned aerial vehicle with the distributed lock;It is checked whether the unmanned aerial vehicle has an executed task, if there is, the current distributed lock is released and the queue record is recorded as waiting, if not, the next step is entered;Safety check before take-off is carried out, and the scheduling action is output, and the unmanned aerial vehicle task scheduling is arranged based on different scheduling actions.

Description

Technical Field

[0001] This invention belongs to the field of UAV mission scheduling technology, specifically relating to a UAV mission scheduling method and system that supports anomaly self-healing and hierarchical breakpoint resumption. Background Technology

[0002] The existing drone dispatching system has the following problems:

[0003] 1. Lack of unified lifecycle management for multi-source task entry points. Scheduled tasks, manual emergency tasks, and third-party collaborative tasks are usually triggered from different entry points. Without a unified dispatch, deduplication, priority, and queuing mechanism, it is easy to cause duplicate order creation, duplicate distribution, or multiple tasks simultaneously occupying the same device.

[0004] 2. Insufficient granularity of concurrent equipment control. Existing scheduling schemes focus more on the task and route itself, and do not adequately handle the concurrent execution of multiple service nodes, network latency, and exclusive control of the same UAV or nest when the scheduler is repeatedly woken up. This can easily lead to the problem of the same device executing multiple takeoff commands at the same time.

[0005] 3. The pre-flight anomaly handling lacks a tiered compensation mechanism. For recoverable anomalies such as excessive wind speed, insufficient power, and non-idle nests, direct failure would reduce the automated airport operation rate; while infinite retries would consume queue resources and cause task backlog.

[0006] 4. The follow-up flight missions after flight interruption lack an auditable hierarchical link. Traditional breakpoint recovery may cover the original mission or simply regenerate the mission, making it difficult to record the sequential relationship of multiple interruptions and multiple compensation executions, and also difficult to prevent repeated generation when existing follow-up flight sub-missions have not yet been completed.

[0007] 5. Lack of closed-loop linkage between scheduling, security checks, delays, and flight resumption. Existing solutions often treat scheduling, route planning, fault handling, and flight resumption as separate functions, failing to form an automatic closed loop that can be driven by a state machine. Summary of the Invention

[0008] This invention aims to solve the problem of mission scheduling reliability in scenarios such as unmanned aerial vehicle (UAV) automated airports or routine UAV inspections, and proposes a UAV mission scheduling method and system that supports anomaly self-healing and hierarchical breakpoint resumption.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A method for scheduling unmanned aerial vehicle (UAV) missions that supports anomaly self-healing and hierarchical breakpoint resumption includes the following steps:

[0011] S1. Obtain the drone missions to be dispatched and the corresponding mission rules to obtain missions that can be automatically scheduled;

[0012] S2. For the automatically schedulable tasks obtained in step S1, use a database update statement based on the version number or the original state condition to perform dispatch preemption and obtain the dispatched tasks.

[0013] S3. For the dispatched tasks obtained in step S2, create task details, generate deduplication keys, and create a task queue;

[0014] S4. Based on the task queue obtained in step S3, the scheduler selects the head node of the queue, and then the scheduler requests a distributed lock at the granularity of the UAV's device identifier to obtain a UAV with a distributed lock;

[0015] S5. For the drone with the distributed lock obtained in step S4, check whether the drone has executed a task. If it has, release the current distributed lock and record this queue as waiting. If it does not have, proceed to the next step.

[0016] S6. Conduct pre-flight safety checks, output scheduling actions, and arrange UAV mission scheduling based on different scheduling actions.

[0017] Furthermore, in step S1, business tasks with a status of pending dispatch are read from the task application table drone_tasks periodically, and the task rule configuration table, device binding table, and route template table are read in conjunction to obtain basic scheduling parameters including task source, trigger mode, task level, target device identifier, planned execution time, route type, and whether interruption resume flight is allowed; among them, manually triggered tasks are only registered as pending manual confirmation and are not entered into the execution queue for the time being.

[0018] Furthermore, the specific implementation method of step S3 includes the following steps:

[0019] S3.1. Create a task detail record, patrol_task_detail, and write the task type, device identifier, parent task identifier, flight continuation sequence number, planned start time, task status, and breakpoint flight continuation configuration. Among them, the task type and planned time come from the task application table, the device identifier comes from the device binding relationship, and the parent task identifier and flight continuation sequence number are initialized to 0 or null in normal task scenarios, and are inherited or generated by the parent task chain in flight continuation scenarios.

[0020] S3.2. Generate a deduplication key K_i based on the task details record, and write the task into the scheduling queue list drone_task_queue. At the same time, write the commit mode level p_i, business priority q_i, executable time a_i, and queue status u_i. If the task is an emergency task, send an immediate wake-up event to the scheduler after the database transaction is committed. If it is a normal task, wait for the scheduler to poll periodically.

[0021] Furthermore, the expression for selecting the queue head node in step S4 is:

[0022] R_i=(p_i,q_i,a_i,r_i)

[0023] Where R_i is the queue head node of task i; p_i is the submission mode level of task i; q_i is the business priority value of task i; a_i is the executable timestamp of task i; r_i is the stable sort number of task i; and then the scheduler selects the queue head node from the candidate set according to the lexicographical order of R_i.

[0024] Furthermore, in step S4, the scheduler requests a distributed lock at the granularity of the drone's device identifier by executing the atomic locking instruction SET NX PX using the Redis key lock:drone:{deviceId}, where lock:drone: is the prefix string of the lock value and deviceId is the device ID.

[0025] 1. A UAV task scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption according to claim 5, characterized in that, in step S5, the method for verifying whether the UAV has executed a task is to query the task details table to see if the same device already has an executing task with the status of IN_PROGRESS or has been claimed and is waiting to be executed.

[0026] Furthermore, the specific implementation method of step S6 includes the following steps:

[0027] S6.1. During the pre-flight safety check, read the online status, battery level B_i, and flight status from the UAV OSD telemetry interface; read the hatch, charging, and occupancy status from the nest status interface; read the current wind speed W_i from the meteorological service; read the permission validity period from the authorization or certificate service; and read the minimum battery level threshold B_min and the maximum allowable wind speed threshold W_max from the task configuration table. Then, determine the takeoff conditions and output three types of scheduling actions: EXECUTE (executable), DELAY (delayed), and FAIL (takeoff conditions not met).

[0028] The formula for determining takeoff conditions is:

[0029]

[0030] in, Let i be the distributed lock acquisition state corresponding to task i. To determine whether the drone corresponding to task i is currently executing a task, Let $\frac{i}{i}$ be the current battery level of the drone corresponding to task $i$. The minimum battery level required for takeoff. The current wind speed at the time of takeoff for mission i. Ei represents the idle state of the nest corresponding to task i, and Ei represents the takeoff condition determination result corresponding to task i.

[0031] S6.2. For scheduling actions of EXECUTE, issue regular route instructions, task assignment instructions, or flight continuation instructions according to the task type, and update the queue status and task details status to "in execution".

[0032] If the scheduling action is DELAY, the system determines e_i based on the exception type, selects the corresponding delay time, calculates the new executable time, and returns the queue to the waiting state.

[0033] The formula for selecting the delay time corresponding to task i is:

[0034]

[0035] Where f is the decision function. This refers to recoverable anomaly types output by security checks. This is the delay time when the nest is not idle. This is the delay time when the battery is low. This refers to the delay time when the wind speed exceeds the limit;

[0036] The formula for calculating the new executable time is:

[0037]

[0038] Among them, t now Used as the base time;

[0039] S6.3. For scheduling actions that are FAIL, set the queue and task details to FAILED and scan the top-level parent tasks that are in a failed state and allow breakpoint resume. If there are no unfinished resume subtasks, determine the resume generation conditions and generate a new resume subtask, write it back into the scheduling queue, and identify it as a resume task based on the non-zero parent task identifier during subsequent scheduling and issue a breakpoint resume command.

[0040] The formula for determining the conditions for continued flight is:

[0041]

[0042] in, To determine whether task i is in a failed state, G i To determine whether task i is allowed to resume flight from a breakpoint, P i The identifier of the parent task of task i. Let x be the set of follow-up subtasks of task i, j be the follow-up subtasks, and x be the set of follow-up subtasks. j To continue the execution status of sub-task j;

[0043] This is a set of states where continued flight has not yet been completed.

[0044] The formula for generating a new follow-up flight subtask is:

[0045]

[0046] in, This is the newly calculated subtask number. This is the set of existing index values ​​for all subtask sets. Let be the set of nodes adjacent to task i, and max be the maximum value function.

[0047] A system for a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed, it implements the steps of the UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption.

[0048] The beneficial effects of this invention are:

[0049] This invention provides a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption, forming a complete scheduling closed loop from mission application to anomaly recovery. This invention unifies task assignment, queue registration, device locking, security checks, execution, delays, failures, and resumption within the same lifecycle, avoiding the fragmented nature of scheduling, route execution, and fault recovery in existing solutions.

[0050] This invention provides a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption, reducing concurrent conflicts under multi-source missions and multi-instance deployments. Through multi-level protection including optimistic locking preemption, deduplication queuing, device-level distributed locks, and in-execution state mutual exclusion verification, this invention can prevent duplicate dispatching, duplicate queuing, and concurrent flight initiation from the same device when multiple scheduler instances and multiple task entry points coexist.

[0051] This invention provides a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption, enhancing the self-healing capability of unattended operations. For transient anomalies such as non-idle drone nests, insufficient power, or excessive wind speed, this invention does not directly fail; instead, it calculates the delay time based on the anomaly type and automatically reschedules the mission, allowing it to continue scheduling after conditions recover, thus improving the continuous operation capability of automated airports.

[0052] This invention provides a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption, improving the auditability and controllability of breakpoint resumption. This invention establishes a hierarchical resumption chain through a parent task identifier and an incrementing resumption sequence number, ensuring that each interruption and each resumption has an independent task record; simultaneously, it avoids the repeated generation of resumption subtasks by using an incomplete subtask status scanning valve.

[0053] The present invention provides a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint continuation, compatible with regular missions, emergency missions, and continuation missions. After the continuation sub-task is generated, it re-enters the unified scheduling queue and is processed by the same sorting, locking, security check, and execution framework. There is no need to build a separate isolated scheduling link for continuation, which facilitates system maintenance and expansion.

[0054] The UAV mission scheduling method described in this invention, which supports anomaly self-healing and hierarchical breakpoint resumption, is easy to implement in engineering and can be parameterized. The scanning cycle, delay time, battery threshold, wind speed threshold, priority mapping, and deduplication key in this invention are all parameterizable, making it adaptable to different UAV models, airports, and business scenarios. Attached Figure Description

[0055] Figure 1 This is a flowchart of a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption, as described in this invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only for explaining the invention and are not intended to limit the invention; that is, the described specific embodiments are merely a part of the embodiments of the invention, and not all of them. The components of the specific embodiments of the invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations, and the invention may also have other embodiments.

[0057] Therefore, the following detailed description of specific embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected specific embodiments of the invention. All other specific embodiments obtained by those skilled in the art based on these specific embodiments without inventive effort are within the scope of protection of this invention.

[0058] To further understand the invention's content, features, and effects, the following specific embodiments are provided, along with accompanying drawings. Figure 1 Detailed explanation is as follows:

[0059] Example 1:

[0060] A method for scheduling unmanned aerial vehicle (UAV) missions that supports anomaly self-healing and hierarchical breakpoint resumption includes the following steps:

[0061] S1. Obtain the drone missions to be dispatched and the corresponding mission rules to obtain missions that can be automatically scheduled;

[0062] Furthermore, in step S1, business tasks with a status of pending dispatch are read from the task application table drone_tasks periodically, and the task rule configuration table, device binding table, and route template table are read in conjunction to obtain basic scheduling parameters including task source, trigger mode, task level, target device identifier, planned execution time, route type, and whether interruption resume flight is allowed; among them, manually triggered tasks are only registered as pending manual confirmation and are not entered into the execution queue for the time being.

[0063] S2. For the automatically schedulable tasks obtained in step S1, use a database update statement based on the version number or the original state condition to perform dispatch preemption and obtain the dispatched tasks.

[0064] Furthermore, for example, if the update condition is "task ID + current status + version field", a successful update means that the current scheduling instance has obtained the right to dispatch the task, while a failed update means that the task has been processed by other instances and will not be dispatched again in this round.

[0065] S3. For the dispatched tasks obtained in step S2, create task details, generate deduplication keys, and create a task queue;

[0066] Furthermore, the specific implementation method of step S3 includes the following steps:

[0067] S3.1. Create a task detail record, patrol_task_detail, and write the task type, device identifier, parent task identifier, flight continuation sequence number, planned start time, task status, and breakpoint flight continuation configuration. Among them, the task type and planned time come from the task application table, the device identifier comes from the device binding relationship, and the parent task identifier and flight continuation sequence number are initialized to 0 or null in normal task scenarios, and are inherited or generated by the parent task chain in flight continuation scenarios.

[0068] S3.2. Generate a deduplication key K_i based on the task details record, and write the task into the scheduling queue list drone_task_queue. At the same time, write the commit mode level p_i, business priority q_i, executable time a_i, and queue status u_i. If the task is an emergency task, send an immediate wake-up event to the scheduler after the database transaction is committed. If it is a normal task, wait for the scheduler to poll periodically.

[0069] S4. Based on the task queue obtained in step S3, the scheduler selects the head node of the queue, and then the scheduler requests a distributed lock at the granularity of the UAV's device identifier to obtain a UAV with a distributed lock;

[0070] Furthermore, the expression for selecting the queue head node in step S4 is:

[0071] R_i=(p_i,q_i,a_i,r_i)

[0072] Where R_i is the queue head node of task i; p_i is the submission mode level of task i; q_i is the business priority value of task i; a_i is the executable timestamp of task i; r_i is the stable sort number of task i; and then the scheduler selects the queue head node from the candidate set according to the lexicographical order of R_i.

[0073] Furthermore, in step S4, the scheduler requests a distributed lock at the granularity of the drone's device identifier by executing the atomic locking instruction SET NX PX using the Redis key lock:drone:{deviceId}, where lock:drone: is the prefix string of the lock value and deviceId is the device ID.

[0074] S5. For the drone with the distributed lock obtained in step S4, check whether the drone has executed a task. If it has, release the current distributed lock and record this queue as waiting. If it does not have, proceed to the next step.

[0075] Furthermore, in step S5, the method for verifying whether the drone has executed a task is to query the task details table to see if the same device already has an executing task with the status of IN_PROGRESS or has been claimed and is pending execution.

[0076] S6. Conduct pre-flight safety checks, output scheduling actions, and arrange UAV mission scheduling based on different scheduling actions.

[0077] Furthermore, the specific implementation method of step S6 includes the following steps:

[0078] S6.1. During the pre-flight safety check, read the online status, battery level B_i, and flight status from the UAV OSD telemetry interface; read the hatch, charging, and occupancy status from the nest status interface; read the current wind speed W_i from the meteorological service; read the permission validity period from the authorization or certificate service; and read the minimum battery level threshold B_min and the maximum allowable wind speed threshold W_max from the task configuration table. Then, determine the takeoff conditions and output three types of scheduling actions: EXECUTE (executable), DELAY (delayed), and FAIL (takeoff conditions not met).

[0079] The formula for determining takeoff conditions is:

[0080]

[0081] in, Let i be the distributed lock acquisition state corresponding to task i. To determine whether the drone corresponding to task i is currently executing a task, Let $\frac{i}{i}$ be the current battery level of the drone corresponding to task $i$. The minimum battery level required for takeoff. The current wind speed at the time of takeoff for mission i. Ei represents the idle state of the nest corresponding to task i, and Ei represents the takeoff condition determination result corresponding to task i.

[0082] S6.2. For scheduling actions of EXECUTE, issue regular route instructions, task assignment instructions, or flight continuation instructions according to the task type, and update the queue status and task details status to "in execution".

[0083] If the scheduling action is DELAY, the system determines e_i based on the exception type, selects the corresponding delay time, calculates the new executable time, and returns the queue to the waiting state.

[0084] The formula for selecting the delay time corresponding to task i is:

[0085]

[0086] Where f is the decision function. This refers to recoverable anomaly types output by security checks. This is the delay time when the nest is not idle. This is the delay time when the battery is low. This refers to the delay time when the wind speed exceeds the limit;

[0087] The formula for calculating the new executable time is:

[0088]

[0089] Among them, t now Used as the base time;

[0090] S6.3. For scheduling actions that are FAIL, set the queue and task details to FAILED and scan the top-level parent tasks that are in a failed state and allow breakpoint resume. If there are no unfinished resume subtasks, determine the resume generation conditions and generate a new resume subtask, write it back into the scheduling queue, and identify it as a resume task based on the non-zero parent task identifier during subsequent scheduling and issue a breakpoint resume command.

[0091] The formula for determining the conditions for continued flight is:

[0092]

[0093] in, To determine whether task i is in a failed state, G i To determine whether task i is allowed to resume flight from a breakpoint, P i The identifier of the parent task of task i. Let x be the set of follow-up subtasks of task i, j be the follow-up subtasks, and x be the set of follow-up subtasks. j To continue the execution status of sub-task j;

[0094] This is a set of states where continued flight has not yet been completed.

[0095] The formula for generating a new follow-up flight subtask is:

[0096]

[0097] in, This is the newly calculated subtask number. This is the set of existing index values ​​for all subtask sets. Let be the set of nodes adjacent to task i, and max be the maximum value function.

[0098] Example 2:

[0099] A system for a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed, it implements the steps of the UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption as described in Embodiment 1.

[0100] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0101] Although this application has been described above with reference to specific embodiments, various modifications can be made and components can be replaced with equivalents without departing from the scope of this application. In particular, as long as there is no structural conflict, the features in the specific embodiments disclosed in this application can be combined with each other in any way. The lack of an exhaustive description of these combinations in this specification is merely for the sake of brevity and resource conservation. Therefore, this application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A UAV mission scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption, characterized in that, Includes the following steps: S1. Obtain the drone missions to be dispatched and the corresponding mission rules to obtain missions that can be automatically scheduled; S2. For the automatically schedulable tasks obtained in step S1, use a database update statement based on the version number or the original state condition to perform dispatch preemption and obtain the dispatched tasks. S3. For the dispatched tasks obtained in step S2, create task details, generate deduplication keys, and create a task queue; S4. Based on the task queue obtained in step S3, the scheduler selects the head node of the queue, and then the scheduler requests a distributed lock at the granularity of the UAV's device identifier to obtain a UAV with a distributed lock; S5. For the drone with the distributed lock obtained in step S4, check whether the drone has executed a task. If it has, release the current distributed lock and record this queue as waiting. If it does not have, proceed to the next step. S6. Conduct pre-flight safety checks, output scheduling actions, and arrange UAV mission scheduling based on different scheduling actions.

2. The UAV mission scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption as described in claim 1, characterized in that, In step S1, business tasks with a status of pending dispatch are read from the task application table drone_tasks periodically, and the task rule configuration table, device binding table, and route template table are read in conjunction to obtain basic scheduling parameters including task source, trigger mode, task level, target device identifier, planned execution time, route type, and whether interruption resume flight is allowed; among them, manually triggered tasks are only registered as pending manual confirmation and are not entered into the execution queue for the time being.

3. A UAV mission scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption as described in claim 1 or 2, characterized in that, The specific implementation method of step S3 includes the following steps: S3.

1. Create a task detail record, patrol_task_detail, and write the task type, device identifier, parent task identifier, flight continuation sequence number, planned start time, task status, and breakpoint flight continuation configuration. Among them, the task type and planned time come from the task application table, the device identifier comes from the device binding relationship, and the parent task identifier and flight continuation sequence number are initialized to 0 or null in normal task scenarios, and are inherited or generated by the parent task chain in flight continuation scenarios. S3.

2. Generate a deduplication key K_i based on the task details record, and write the task into the scheduling queue list drone_task_queue. At the same time, write the commit mode level p_i, business priority q_i, executable time a_i, and queue status u_i. If the task is an emergency task, send an immediate wake-up event to the scheduler after the database transaction is committed. If it is a normal task, wait for the scheduler to poll periodically.

4. The UAV mission scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption as described in claim 3, characterized in that, The expression for selecting the head node of the queue in step S4 is: R_i=(p_i,q_i,a_i,r_i) Where R_i is the queue head node of task i; p_i is the submission mode level of task i; q_i is the business priority value of task i; a_i is the executable timestamp of task i; r_i is the stable sort number of task i; and then the scheduler selects the queue head node from the candidate set according to the lexicographical order of R_i.

5. The UAV mission scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption according to claim 4, characterized in that, In step S4, the scheduler requests a distributed lock at the granularity of the drone's device identifier by using the Redis key lock:drone:{deviceId} to execute the atomic locking instruction SET NX PX, where lock:drone: is the prefix string of the lock value and deviceId is the device ID.

6. The UAV mission scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption according to claim 5, characterized in that, In step S5, the method for verifying whether the drone has executed a task is to query the task details table to see if the same device already has an executing task with the status of IN_PROGRESS or has been claimed and is pending execution.

7. The UAV mission scheduling method supporting anomaly self-healing and hierarchical breakpoint resumption as described in claim 6, characterized in that, The specific implementation method of step S6 includes the following steps: S6.

1. During the pre-flight safety check, read the online status, battery level B_i, and flight status from the UAV OSD telemetry interface; read the hatch, charging, and occupancy status from the nest status interface; read the current wind speed W_i from the meteorological service; read the permission validity period from the authorization or certificate service; and read the minimum battery level threshold B_min and the maximum allowable wind speed threshold W_max from the task configuration table. Then, determine the takeoff conditions and output three types of scheduling actions: EXECUTE (executable), DELAY (delayed), and FAIL (takeoff conditions not met). The formula for determining takeoff conditions is: in, Let i be the distributed lock acquisition state corresponding to task i. To determine whether the drone corresponding to task i is currently executing a task, Let $\frac{i}{i}$ be the current battery level of the drone corresponding to task $i$. The minimum battery level required for takeoff. The current wind speed at the time of takeoff for mission i. Ei represents the idle state of the nest corresponding to task i, and Ei represents the takeoff condition determination result corresponding to task i. S6.

2. For scheduling actions of EXECUTE, issue regular route instructions, task assignment instructions, or flight continuation instructions according to the task type, and update the queue status and task details status to "in execution". If the scheduling action is DELAY, the system determines e_i based on the exception type, selects the corresponding delay time, calculates the new executable time, and returns the queue to the waiting state. The formula for selecting the delay time corresponding to task i is: Where f is the decision function. This refers to recoverable anomaly types output by security checks. This refers to the delay time when the nest is not idle. This is the delay time when the battery is low. This refers to the delay time when wind speed exceeds the limit. The formula for calculating the new executable time is: Among them, t now Used as the base time; S6.

3. For scheduling actions that are FAIL, set the queue and task details to FAILED and scan the top-level parent tasks that are in a failed state and allow breakpoint resume. If there are no unfinished resume subtasks, determine the resume generation conditions and generate a new resume subtask, write it back into the scheduling queue, and identify it as a resume task based on the non-zero parent task identifier during subsequent scheduling and issue a breakpoint resume command. The formula for determining the conditions for continued flight is: in, To determine whether task i is in a failed state, G i To determine whether task i is allowed to resume flight from a breakpoint, P i The identifier of the parent task of task i. Let x be the set of follow-up subtasks of task i, j be the follow-up subtasks, and x be the set of follow-up subtasks. j To continue the execution status of sub-task j; This is a set of states where continued flight has not yet been completed. The formula for generating a new follow-up flight subtask is: in, This is the newly calculated subtask number. This is the set of existing index values ​​for all subtask sets. Let be the set of nodes adjacent to task i, and max be the maximum value function. A system for scheduling UAV missions that supports anomaly self-healing and hierarchical breakpoint resumption is characterized by, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed, it implements the steps of a UAV mission scheduling method that supports anomaly self-healing and hierarchical breakpoint resumption as described in any one of claims 1-7.

Images