Emergency inspection task nest resource scheduling method and system

Abstract

This application provides a method and system for scheduling nest resources for emergency inspection tasks. The method includes: obtaining the target location of the emergency inspection task; retrieving nest resources based on the target location to obtain a candidate nest set; obtaining the status information of each candidate nest in the candidate nest set, the status information indicating whether the nest is in a planned occupancy state; for each candidate nest in the candidate nest set, if the status information indicates that the candidate nest is in a planned occupancy state, obtaining the task attribute of the task to be executed corresponding to the candidate nest; evaluating the releaseability of the candidate nest based on the task attribute to obtain a releaseability score; and determining the target nest from the candidate nest set based on the status information of each candidate nest and all releaseability scores. This method improves scheduling accuracy, enhances emergency response capabilities, optimizes resource utilization, and improves scheduling stability, achieving efficient and precise scheduling of nest resources.

Description

Technical Field

[0001] This application relates to the field of power grid unmanned aerial vehicle (UAV) inspection and scheduling, and in particular to a method and system for scheduling UAV nest resources for emergency inspection tasks. Background Technology

[0002] With the trend towards intelligent and automated power grid operation and maintenance, drone inspections have become a key means of monitoring the condition of power grid equipment and troubleshooting faults due to their high efficiency and precision. Drone housings, as the core infrastructure supporting automated drone operations, provide services such as drone dwelling, charging, takeoff and landing, and data transmission. As the scale of drone inspections by power grid companies continues to expand, the demand for shared housing resources from multiple disciplines such as transmission, substation, and distribution is increasing. Routine inspections, special inspections, and emergency tasks are intertwined, making the usage scenarios of housing resources increasingly complex, and highlighting the need for rational scheduling of housing resources. Especially in response to emergencies such as sudden equipment failures and natural disasters, the high timeliness requirements of emergency inspection tasks make the efficient scheduling of housing resources a crucial link in ensuring the smooth execution of tasks.

[0003] Currently, a series of studies and practices have been carried out to address the scheduling needs of emergency power grid drone inspection tasks. For example, some methods, upon receiving an emergency inspection task, select the target airport for the emergency task from multiple candidate airports based on task priority and the initial inspection work order through a simulated market bidding mechanism. Other methods employ multi-objective particle swarm optimization (PSO) algorithms and improved PSO algorithms to calculate the optimal task allocation scheme and introduce a task preemption mechanism. When a high-priority task is inserted, the drone resources occupied by low-priority tasks are released, and resources are allocated to emergency tasks first.

[0004] However, existing methods still suffer from insufficient dispatching accuracy when facing power grid emergency command scenarios, resulting in low efficiency in emergency inspection tasks. Summary of the Invention

[0005] The method and system for scheduling the machine nest resources for emergency inspection tasks provided in this application are intended to solve the problem that the existing methods still have insufficient scheduling accuracy when facing power grid emergency command scenarios, thereby improving the execution efficiency of emergency inspection tasks.

[0006] In a first aspect, embodiments of this application provide a method for scheduling nest resources for emergency inspection tasks, including:

[0007] Obtain the target location for emergency inspection tasks;

[0008] Based on the target location, retrieve nest resources to obtain a set of candidate nests;

[0009] Obtain the status information of each candidate nest in the candidate nest set. The status information is used to indicate whether the nest is in a planned occupancy state.

[0010] For each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, then obtain the task attribute of the task to be executed corresponding to the candidate nest;

[0011] Based on the mission attributes, the releaseability of candidate hives is evaluated to obtain a releaseability score;

[0012] Based on the state information of each candidate nest and all releaseability scores, the target nest is determined from the set of candidate nests.

[0013] In one possible implementation, the releaseability of candidate nests is evaluated based on task attributes to obtain a releaseability score, including: determining a priority coefficient, a time window tolerance coefficient, and an alternative resource coefficient based on task attributes; and performing a weighted summation of the priority coefficient, the time window tolerance coefficient, and the alternative resource coefficient to obtain the releaseability score; wherein, the priority coefficient is used to indicate the priority feasibility of the task to be executed being preempted, the time window tolerance coefficient is used to indicate the start time flexibility of the task to be executed, and the alternative resource coefficient is used to indicate whether there is an alternative nest to execute the task to be executed.

[0014] In one possible implementation, the method further includes: obtaining the number of cascaded reordering tasks that will result from preempting a candidate nest; determining a penalty term based on the number of cascaded reordering tasks, wherein the penalty term is positively correlated with the number of cascaded reordering tasks; and updating the releasability score based on the penalty term to obtain an updated releasability score.

[0015] In one possible implementation, the target nest is determined from the candidate nest set based on the status information of each candidate nest and all releasability scores. This includes: determining the distance information, real-time status information, health information, and estimated response time of each candidate nest from the target location based on the status information of each candidate nest; for each candidate nest, if the candidate nest is in a planned occupancy state, obtaining the corresponding releasability score; if the candidate nest is not in a planned occupancy state, setting the corresponding releasability score to a preset value; performing a weighted summation of the distance information, real-time status information, health information, estimated response time, and releasability score of the candidate nest to obtain a comprehensive score result; and sorting all the comprehensive score results, determining the candidate nest with the highest ranking as the target nest.

[0016] In one possible implementation, before obtaining the target location of the emergency inspection task, the method further includes: obtaining a task creation instruction, which is triggered by at least one of the following methods: a one-click creation button, input through a dispatch terminal, linkage triggering by an alarm system, and reporting from a mobile terminal; generating an emergency inspection task based on the task creation instruction, and determining the emergency level priority of the emergency inspection task; wherein, the emergency inspection task includes a task type and a target area.

[0017] In one possible implementation, after obtaining the status information of each candidate nest in the candidate nest set, the method further includes: classifying the status of each candidate nest in the candidate nest set according to the status information to obtain the nest status of each candidate nest, where the nest status includes green light status, yellow light status, red light status, or gray light status; wherein, green light status indicates that the nest is in an idle and available state, yellow light status indicates that the nest is in a planned occupancy state, red light status indicates that the nest is in an execution occupancy state, and gray light status indicates that the nest is in a fault offline state; correspondingly, for each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, then the task attribute of the task to be executed corresponding to the candidate nest is obtained, including: for each candidate nest in the candidate nest set, if the nest status of the candidate nest indicates that the candidate nest is in a planned occupancy state, then the task attribute of the task to be executed corresponding to the candidate nest is obtained.

[0018] In one possible implementation, after determining the target nest from the candidate nest set based on the status information of each candidate nest and all releasability scores, the method further includes: updating the status of the target nest to an emergency locked state in response to a locking operation on the target nest; if the target nest was in a planned occupied state before locking, automatically generating an original task rollback record, the original task rollback record including the pending task identifier corresponding to the target nest, the original allocated nest identifier, the reason for preemption, and the time of preemption; updating the status of the pending task corresponding to the original task rollback record to a pending rescheduling state, and writing it into the pending rescheduling pool.

[0019] In one possible implementation, after updating the status of the task to be executed corresponding to the original task rollback record to the pending rescheduling status and writing it into the pending rescheduling pool, the method further includes: triggering the rescheduling engine to automatically schedule the tasks in the pending rescheduling pool. The automatic scheduling process includes: reading the original constraints of the task to be executed, reading the currently available nesting set and the corresponding time window, and generating a new execution plan; when the automatic scheduling is successful, generating a new execution plan and sending a notification; when the automatic scheduling fails, marking the task to be executed as pending manual confirmation and sending a notification.

[0020] In one possible implementation, the method further includes: in response to the completion of the emergency inspection task, releasing the emergency lock status of the target nest and updating the status of the target nest to a green light status, the green light status being used to indicate that the nest is in an idle and available state; generating an emergency dispatch record, the emergency dispatch record including the lock record of the target nest and the original task rollback record.

[0021] Secondly, embodiments of this application provide a nest resource scheduling system for emergency inspection tasks, including:

[0022] The first acquisition module is used to acquire the target location of the emergency inspection task.

[0023] The retrieval module is used to retrieve nest resources based on the target location and obtain a set of candidate nests;

[0024] The second acquisition module is used to acquire the status information of each candidate nest in the candidate nest set. The status information is used to indicate whether the nest is in a planned occupancy state.

[0025] The third acquisition module is used to acquire the task attributes of the task to be executed corresponding to each candidate nest in the candidate nest set if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state.

[0026] The evaluation module is used to evaluate the releasability of candidate hives based on task attributes and obtain a releasability score.

[0027] The determination module is used to determine the target nest from the candidate nest set based on the status information of each candidate nest and all releasability scores.

[0028] The method and system for scheduling nest resources for emergency inspection tasks provided in this application embodiment obtains the target location of the emergency inspection task; retrieves nest resources based on the target location to obtain a set of candidate nests; obtains the status information of each candidate nest in the candidate nest set, the status information indicating whether the nest is in a planned occupancy state; for each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, the task attribute of the task to be executed corresponding to the candidate nest is obtained; the releaseability of the candidate nest is evaluated based on the task attribute to obtain a releaseability score; the means of determining the target nest from the candidate nest set based on the status information of each candidate nest and all releaseability scores can accurately identify the nest status, deeply analyze the task attributes and quantify the releaseability, accurately judge the actual schedulable capacity when the nest is already in planned occupancy, avoid the recommendation bias caused by selecting resources only based on distance, cost or priority, and thus determine the target nest that is more in line with the execution conditions of the emergency task from the candidate nest set, improve scheduling accuracy, enhance emergency response capability, and thus achieve efficient scheduling of nest resources. Attached Figure Description

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

[0030] Figure 1 A flowchart illustrating the nest resource scheduling method for emergency inspection tasks provided in this application. Figure 1 ;

[0031] Figure 2 A flowchart illustrating the nest resource scheduling method for emergency inspection tasks provided in this application. Figure 2 ;

[0032] Figure 3 A schematic diagram illustrating the specific process of the nest resource scheduling method for emergency inspection tasks provided in this application;

[0033] Figure 4 A schematic diagram of the comprehensive sorting of candidate nests provided in this application;

[0034] Figure 5 Schematic diagram of the nest resource scheduling system for emergency inspection tasks provided in this application Figure 1 ;

[0035] Figure 6 The nest state transition diagram provided in this application;

[0036] Figure 7 The original task rollback and rearrangement logic diagram provided for this application;

[0037] Figure 8 Schematic diagram of the nest resource scheduling system for emergency inspection tasks provided in this application Figure 2 ;

[0038] Figure 9 A schematic diagram of the structure of the electronic device provided in this application.

[0039] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0040] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0041] First, let me explain the terms used in this application:

[0042] UAV nest: refers to the infrastructure used for UAVs to automatically stay, charge, take off and land, transmit data back and operate continuously. In this embodiment, it serves as a key resource carrier for UAV inspection tasks in the power grid.

[0043] Emergency inspection missions refer to drone inspection missions that occur in scenarios such as sudden equipment failures, natural disaster investigations, and critical power supply protection, characterized by high timeliness, high priority, and strong insertion.

[0044] Yellow light status: This refers to one of the real-time status classifications of the hive, indicating a planned occupancy status, meaning it is currently reserved by a planned task but has not yet started execution, and has the potential for release assessment. Other status classifications may include green light status, red light status, and gray light status, etc.

[0045] Green light status: Indicates an idle and available state, meaning it is not currently occupied by any task and can directly accept the assignment of new tasks.

[0046] Red light status: Indicates that the task is currently being executed and cannot be interrupted.

[0047] Gray light status: indicates a fault, offline, or disabled state, meaning it is currently unavailable and not involved in emergency dispatch.

[0048] Releaseability score (R score ): refers to the quantitative score calculated for the yellow-light status machine nest based on factors such as the priority of its original planned task, time window tolerance, availability of alternative resources, and cascading effects. The value range is [0,100]. The higher the score, the more suitable it is to be taken over by emergency tasks.

[0049] Releasability threshold (R) threshold ): The preset releasability score threshold value, which is only applied when R score ≥R threshold Only then is the yellow-light status device included in the emergency candidate set for comprehensive ranking.

[0050] Overall score (Score) totalThe candidate nest comprehensive suitability score is calculated based on multiple factors such as distance, status, equipment health, releasability, and response time, and is used to rank the candidate nests.

[0051] One-click locking refers to the operation of resource occupation of the target nest, which includes the synchronous execution of multiple atomic actions such as state rewriting, resource marking, record generation, request blocking, and original task disposal, to ensure the reliability and consistency of the locking process.

[0052] The rescheduling pool is a logical queue used to manage tasks that need to be rescheduled due to emergency insertion, equipment failure, weather changes, etc., and it is automatically linked with the subsequent rescheduling engine.

[0053] Emergency Lockdown Status: This refers to the state of the drone nest after it has been locked by an emergency task with one click. In this state, the drone nest and its associated drone resources cannot be requested by other ordinary tasks.

[0054] Forced preemption: refers to the operation of forcibly interrupting the original planned mission of a target nest that is in a yellow light state and allocating its resources to emergency missions after passing the releaseability assessment.

[0055] Reordering engine: refers to the calculation module that automatically reorders tasks in the reordering pool. It can automatically generate reordering schemes based on task constraints, available resources, and other conditions.

[0056] In the field of power grid drone inspection and dispatch, drones typically rely on drone nests to complete automatic dwelling, charging, takeoff and landing, and data transmission, forming a sustainable inspection system. The dispatch center needs to comprehensively handle various tasks, including periodic routine inspections, temporary dispatches, power supply maintenance inspections, and fault verification. Multiple business departments may also share the same batch of drone nest resources. In emergencies such as wildfires, floods, or equipment alarms, the dispatch platform must quickly identify target resources from nearby drone nests capable of undertaking emergency inspections, even before planned tasks have been completed. At this time, the system not only needs to search for nearby drone nests based on location but also needs to identify different states of the nests, such as idle, planned occupation, or actual execution, and determine whether existing plans can relinquish resources when inserting tasks. In emergency scenarios, the dispatch result must be consistent with the current executable conditions of the drone nests; otherwise, even if a closer drone nest is selected, it may be unable to take off in time due to pre-occupancy by subsequent tasks, affecting the efficiency of disaster relief command and fault handling.

[0057] In existing technologies, nest resource scheduling typically revolves around location proximity, flight cost, task priority, or simple status indicators. A common approach is to first receive information about the target area of ​​the task, then search for candidate nests based on geographical coordinates or flight radius, and finally filter resources that are shown as idle or eligible for scheduling using a status database. These resources are then assigned after being sorted according to rules such as proximity or highest priority. However, if a nest has no currently executing task but has been reserved for a future time slot, its occupancy status is usually broadly categorized as "not idle" or "pending use," and the system lacks the ability to further subdivide and differentiate between such planned resource occupancy. While some solutions allow high-priority tasks to preempt low-priority tasks, the judgment is often based solely on task level, or requires manual review of the original task's start time and alternative possibilities before deciding whether to release the resource.

[0058] The aforementioned working principle dictates that existing scheduling methods primarily rely on static judgments at the "optional" level, lacking an independent evaluation mechanism for issues such as whether planned occupancy can actually be reassigned. This results in significant drawbacks: Firstly, candidate nests retrieved by the system may include resources that are geographically close and appear schedulable, but whose subsequent task windows are extremely tight, cannot be postponed, or lack alternative arrangements, leading to inconsistencies between recommended results and actual schedulability. Secondly, schedulers must additionally verify the attributes of tasks to be executed and manually determine whether release is possible, increasing response time and increasing the risk of misjudgments due to fragmented information and inconsistent judgment criteria. Especially when emergency inspection tasks are inserted, improper handling of planned occupancy status can lead to situations where selected nests cannot be released subsequently, frequent reassignments, and repeated rollbacks of scheduling results, further amplifying resource conflicts, impacting the timeliness of emergency tasks, and causing a lack of stability and continuity in the entire nest scheduling process.

[0059] It is evident that while existing methods can accomplish basic resource retrieval and task allocation, they still have significant shortcomings in accurately identifying planned resource occupancy, determining schedulability, and adapting to emergency scenarios. This results in insufficient scheduling accuracy in power grid emergency command scenarios, which in turn affects the efficiency of emergency inspection tasks.

[0060] To address the aforementioned issues, this application provides a method and system for scheduling appliance resources for emergency inspection tasks. This method first identifies the target location of the emergency inspection task to narrow down the candidate appliance range, then focuses on appliance status information, particularly delving into the attributes of planned-occupancy appliances to determine their pending tasks. This approach, without altering the emergency task entry point or appliance retrieval process, elevates resource assessment from a rough screening to a releaseability evaluation based on pending task attributes. This makes the determination of target appliances more closely aligned with actual scheduling conditions, improving the accuracy, real-time performance, and reliability of appliance resource selection in emergency inspection scenarios. Furthermore, based on this evaluation and combined with a comprehensive analysis of appliance status and task attributes, a practical task scheduling strategy (i.e., a dynamic decision-making process for determining target appliances) is formulated, enabling the scientific and rational allocation of appliance resources according to emergency task requirements and actual appliance resource conditions. This approach effectively overcomes the shortcomings of existing appliance resource scheduling technologies in areas such as planned-occupancy resource identification, schedulability assessment, and emergency scenario adaptation, improving scheduling accuracy, ensuring efficient execution of emergency inspection tasks, and better meeting the complex and ever-changing needs of power grid emergency command.

[0061] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0062] The execution entity of the emergency inspection task nest resource scheduling method provided in this application embodiment can be a computing device such as a server or server cluster. The server can be a mobile phone, computer, tablet, or other device. This application embodiment does not impose any particular restrictions on the implementation method of the execution entity, as long as the execution entity can obtain the target location of the emergency inspection task; retrieve nest resources based on the target location to obtain a candidate nest set; obtain the status information of each candidate nest in the candidate nest set, the status information indicating whether the nest is in a planned occupancy state; for each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, then obtain the task attribute of the task to be executed corresponding to the candidate nest; perform a releaseability assessment on the candidate nest based on the task attribute to obtain a releaseability score; and determine the target nest from the candidate nest set based on the status information of each candidate nest and all releaseability scores.

[0063] Figure 1 A flowchart illustrating the nest resource scheduling method for emergency inspection tasks provided in this application. Figure 1The execution entity of this method can be a server storing the nest resource scheduling method for emergency inspection tasks or other system servers. For example, it could be a scheduling platform server deployed in a power grid dispatch center, an application server interfacing with the nest management system, an edge computing node, or a comprehensive monitoring master station. This embodiment does not impose any particular limitations. Figure 1 As shown, the method may include:

[0064] S101. Obtain the target location for the emergency inspection mission.

[0065] In this step, the emergency inspection task triggers the entire scheduling process. Essentially, it is an inspection task that requires resource assignment to be completed within a short response time. The target location is used to characterize the inspection target area, fault location, alarm location, or spatial range that needs to be focused on coverage for the emergency inspection task. It serves as the spatial basis for subsequent nest resource retrieval.

[0066] This location can be manually entered by dispatchers on the dispatch system interface, either by inputting the coordinates of the target location or by selecting an area on a map. Alternatively, it can be automatically acquired through data exchange with other monitoring systems. For example, when connected to a power grid equipment monitoring system, the system automatically sends the location of the alarming equipment as the target location to the grid resource dispatch system when an alarm is triggered.

[0067] In some specific implementations, after receiving the creation instruction for an emergency inspection task, the dispatch platform parses the task message, extracts the task identifier, alarm source, task type, initiation time, and location-related fields, and determines the target location from these. The creation instruction can originate from the transmission line monitoring and alarm system, substation equipment status monitoring system, wildfire monitoring platform, meteorological disaster linkage system, manual work order entry terminal, or mobile inspection terminal reporting module. When an external system directly uploads latitude and longitude coordinates, the platform uses these coordinates as the target location; when the external system uploads tower numbers, line section numbers, equipment interval codes, or administrative area information, the platform can further call the geographic information database, equipment ledger database, or line geographic mapping table to convert them into unified coordinate points, coordinate strings, area boundaries, or buffer range data.

[0068] Furthermore, in an exemplary embodiment, the target location can be represented by single-point coordinates, such as the latitude and longitude of the center of the fault point; it can also be represented by a linear range, such as the start and end coordinates of the transmission line section to be inspected; or it can be represented by a polygonal area, such as the area affected by a wildfire, a flood warning area, or an area with concentrated icing.

[0069] To ensure consistency in subsequent retrieval processes, location data from different sources and in different formats can be standardized, including coordinate system transformation, spatial object type unification, missing field completion, and outlier validation. For example, coordinates from BeiDou positioning terminals, electronic map services, and internal geographic information systems can be uniformly converted to a preset coordinate reference system, and data with location accuracy below a threshold can be corrected or marked. When the target location represents only a broad area, a corresponding operation center point and coverage radius can be generated based on the task type. For instance, for a foreign object detection task on a railway line, the nearest point on the line can be used as the center point; for a fire reconnaissance task, the centroid of the heat source area can be used as the center point, along with a risk extension buffer.

[0070] Based on the above analysis, obtaining the target location of an emergency inspection task is not simply a matter of reading the location field. Instead, it involves transforming the spatial information from multiple task entry points into standardized location parameters that can be used for unified scheduling calculations. This process ensures that emergency tasks from different business systems can enter the same scheduling process and avoids deviations in the search range of surrounding equipment locations due to inconsistent location representations. This provides an accurate data foundation for the formation of subsequent candidate equipment location sets. In power grid emergency inspection scenarios, the more accurately the target location is determined, the closer the range of subsequent candidate equipment locations will be to the actual operational needs, thus shortening the resource retrieval path and improving scheduling response efficiency.

[0071] S102. Based on the target location, retrieve nest resources to obtain a set of candidate nests.

[0072] Nest resources refer to the facilities used for UAVs to stay, charge, take off and land, and transmit data back. These can include the nest itself, the accompanying UAV, communication links, power and charging modules, takeoff and landing control modules, and control interfaces connected to the platform. The candidate nest set is a list to be evaluated after preliminary spatial screening of nest resources based on the target location. Its purpose is to limit subsequent status assessments and releaseability analyses to nests relevant to the emergency mission, thereby reducing the involvement of irrelevant resources in the calculations.

[0073] In its implementation, after obtaining the target location, the scheduling platform reads the basic information of all online registered drone nests from the nest resource database. This information may include parameters such as nest number, deployment coordinates, region, service route range, maximum drone range, standard takeoff preparation time, current communication quality, and maintenance availability indicators. It then calculates the spatial relationship between the target location and the geographical locations of each nest. Furthermore, for point-like target locations, it can calculate the spherical distance from the nest to the target point, the planned flight path distance, or the estimated arrival time; for linear or area-like target locations, it can calculate the distance from the nest to the nearest boundary of the target area, coverage arrival cost, or mission area overlap.

[0074] In one possible embodiment, when retrieving nest resources, a preset search radius can be established centered on the target location. The search radius can be set according to the emergency mission level, UAV performance, regional terrain, and weather conditions. For example, a larger search radius can be used in plain power distribution corridor scenarios, while it can be correspondingly reduced in mountainous power transmission corridors or complex weather areas. In addition to the basic radius constraint, a flight coverage constraint can also be introduced simultaneously, requiring the UAV corresponding to the candidate nest to have the ability to reach the target location, complete basic reconnaissance, and then return or transfer under the current battery level, typical cruise speed, and mission payload conditions. If the target location is located in a specific administrative region, power supply station jurisdiction, or power supply control area, administrative boundaries or business affiliation boundaries can be superimposed for filtering to avoid including physically accessible but operationally unschedulable nests in the candidate set.

[0075] In other words, in some examples, when retrieving nest resources, the target location can be used as the center, combined with preset search radius, flight coverage radius, administrative boundary, flight route constraints, and service area constraints, to retrieve surrounding candidate nest resources and form a candidate nest set. The search radius is a configurable parameter and can be dynamically adjusted according to the task type. It should be noted that the search range can be jointly determined by the preset search radius, flight coverage radius, administrative boundary, flight route constraints, and service area constraints. These constraints can be used individually, in combination, or all at once. The search radius is configurable and can be dynamically adjusted according to the task type (such as wildfire reconnaissance, equipment failure, power supply maintenance), rather than being a fixed value.

[0076] In the specific data processing flow, the scheduling platform can first quickly recall surrounding nests using spatial indexing, and then filter them layer by layer according to preset constraints. For example, it can first use R-trees, grid indexes, or geohashing to retrieve nest resources near the target location, then eliminate offline nests, out-of-service nests, nests with hardware failures, nests with communication interruptions, and nests that do not have the corresponding task payload capabilities, ultimately generating a candidate nest set. Each candidate nest in this set can be associated with its distance from the target location, estimated flight time, service range matching degree, and original availability status. To support subsequent scoring and target nest determination, a structured record table can be established for the candidate nest set, with record fields including at least nest identifier, spatial matching result, current status source marker, and subsequent scoring cache field.

[0077] Based on the above analysis, retrieving nest resources from the target location and obtaining a candidate nest set can quickly narrow down the range of schedulable resources after an emergency mission arrives, avoiding the need for subsequent status queries and mission attribute evaluations to be performed on the entire resource database, thereby improving the overall processing efficiency of the system. Furthermore, this step can incorporate spatial proximity, flight reachability, and basic scheduling constraints when retrieving nest resources, resulting in a higher consistency between the candidate nest set and the actual emergency operation conditions. This provides accurate resource input for subsequently identifying whether the planned nest occupancy is truly available for release.

[0078] S103. Obtain the status information of each candidate nest in the candidate nest set. The status information is used to indicate whether the nest is in a planned occupancy state.

[0079] In this step, the status information refers to multi-dimensional data describing the current operational status of the drone nest and its onboard drones. This information can include: the current working status of the drone nest (e.g., idle, planned occupation, active occupation, fault, offline, etc.), the self-check status of the drone nest equipment (e.g., whether the charging module is normal, whether the communication link is unobstructed), the drone's presence status (whether a drone is docked), and the drone's health status (e.g., battery level, motor life, firmware version compatibility). Planned occupation status is a specific value in the status information, indicating that the drone nest has been pre-assigned to other inspection tasks at a future time, but is not currently performing a task.

[0080] The system can obtain status information in several ways. For example, the data center periodically reports heartbeat packets and status snapshots to the cloud scheduling platform via its 4G / 5G communication module. The scheduling platform stores this information in a real-time database, and this step directly reads the latest status from the cache or database. Alternatively, the system can proactively send a status query command to the data center when needed, and the data center responds instantly and returns the current status. The status information can also further include the data center's list of planned tasks, with each task containing information such as task ID, affiliated unit, planned start time, planned end time, and task priority.

[0081] In one possible embodiment, the status information can distinguish between four states: idle, planned occupation, execution occupation, fault unavailability, and maintenance lockout. Idle indicates that the nest is not currently executing a task and has not been pre-occupied by a subsequent task; planned occupation indicates that although the nest is not immediately executing a flight, there are tasks that have been generated but not yet started; execution occupation indicates that the nest has entered the response, takeoff, cruise, return, or recovery process; fault unavailability indicates that there is an anomaly in the nest's hardware, communication, power supply, or control modules; and maintenance lockout indicates that the nest is temporarily prohibited from scheduling due to maintenance, upgrades, or safety policies.

[0082] Furthermore, in some examples, to ensure accurate identification of planned occupancy status, it can be determined during the status aggregation process whether the task to be executed has completed resource binding and whether the binding remains valid within a preset observation time window. For example, the current time to the next two hours can be set as the key observation time window; as long as there is a confirmed task to be executed within this time window, it is marked as planned occupancy.

[0083] In practical implementation, a combination of polling and event subscription can be used to update status information. For core fields with frequent status changes, such as task allocation status, UAV presence status, and door lock status, reports from the nest side can be received in real time via the message bus. For fields with relatively stable changes, such as maintenance plans and no-fly zones, they can be synchronized from the database periodically. Then, status codes or status tags are generated according to unified rules. For example, if the nest currently has no tasks in progress, but there are scheduled and uncancelled inspection tasks, and the task's start time is later than the current time, the nest is marked as planned occupied. If a fault flag also exists, the fault unavailability status takes precedence over the planned occupied status. This prioritization avoids misjudging actually unavailable resources as merely planned occupied ones.

[0084] Understandably, existing technologies typically only classify nesting resources as idle or non-idle, failing to further identify planned but transferable resources. This step, however, introduces dedicated logic for determining planned occupancy status, further subdividing resources previously mixed in with the general unavailable category. This establishes an independent entry point for subsequent acquisition of task attributes and releaseability assessment. This reduces errors caused by static status judgments and improves the consistency between scheduling results and actual execution conditions.

[0085] S104. For each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, then obtain the task attribute of the task to be executed corresponding to the candidate nest.

[0086] The tasks to be executed can refer to inspection tasks that have been assigned or reserved for the rack but have not yet started. Task attributes can refer to key parameters that describe the characteristics of the tasks to be executed, including but not limited to: task priority level (e.g., urgent, important, general, special inspection / power supply guarantee), planned start and end times, maximum allowed delay time, task type (e.g., fault inspection, routine inspection, special inspection for power supply guarantee), unit / specialized team to which the task belongs, whether there are alternative rack resources, and the number of cascading tasks that may be triggered if the rack is preempted.

[0087] It should be noted that, in order to avoid unnecessary data access, this step only performs the task attribute acquisition for candidate nests whose status information explicitly indicates that they are in a planned occupied state. For nests in other states (such as idle, occupied, unavailable due to fault, or maintenance locked state), this type of attribute reading is not performed, or a releaseability score is directly assigned according to preset rules.

[0088] In some examples, based on the nest identifier of a candidate nest, the task scheduling database can be queried for task records that are bound to that nest and have a status of pending execution, scheduled, awaiting takeoff, or awaiting confirmation, and the task item most directly related to the current nest's planned occupancy can be identified. When multiple future tasks exist for the same nest, the target task can be determined according to the principle of the task start time being the most recent, the resource binding strength being the strongest, or the impact on the current observation window being the greatest, or the attributes of multiple tasks can be combined for subsequent comprehensive evaluation.

[0089] In one possible embodiment, task attributes may include task type, task priority, time window, estimated execution duration, and target range. Task type can be categorized as routine patrol, special inspection, power supply guarantee patrol, hidden danger review, post-disaster review, etc., reflecting whether the task has room for extension. Task priority characterizes the importance of the original task and can be represented by numerical levels, classification labels, or weighted mapping. Time window describes the time boundary at which the task is allowed to start or complete, such as the earliest start time, latest start time, and latest completion time. Estimated execution duration reflects the length of time the task will occupy the drone and drone resources once executed. Target range characterizes the spatial distribution of the task to be executed, facilitating subsequent determination of whether the task can be replaced by other nearby drones. In addition, task attributes may also include weather dependence, personnel coordination dependence, whether it is associated with a power outage window, whether it belongs to a regulatory assessment task, whether automatic reassignment is allowed, historical extension count, and the department that initiated the task. It should be noted that although these attributes are not individually limited, as long as they can characterize the ease of task release, they can be used as evaluation inputs in this embodiment.

[0090] In one example, during processing, the scheduling platform can standardize and structure the acquired task attributes. For instance, it can map text-based task types to category codes, task priorities to numerical ranges, break down time windows into remaining delay time, the difference from the latest start time, and tolerable offsets, and uniformly convert the target scope into GIS (Geographic Information System) objects. Furthermore, if certain attributes are missing, they can be reasonably supplemented based on task templates, historical statistics of similar tasks, or business rules. For example, if the expected execution time is not explicitly stored, a default value can be generated based on the historical median duration of similar tasks; if a reassignment flag is not stored, a default policy can be inferred based on the task's originating department and task category. Through the above processing, it can be ensured that the input data used for subsequent releasability assessments has a unified dimension and comparability.

[0091] In this step, task attributes are retrieved only for candidate nests in the planned occupancy state. This reduces redundant queries across all candidate resources, lowers database access overhead, and focuses the analysis on resources with genuine release decision requirements, thereby improving the targeting of the scheduling process. Since task attributes directly reflect the ease with which the original task can be postponed, replaced, or reassigned, this step provides a data foundation for establishing a releaseability score, enabling the system to move beyond simple state judgments to a more refined assessment oriented towards transferability.

[0092] S105. Based on the mission attributes, evaluate the releasability of candidate hives and obtain a releasability score.

[0093] The releasability assessment quantifies whether candidate nests are suitable for being seized or transferred by emergency inspection tasks when needed, given their planned occupancy status. The releasability score is a quantitative representation of the releasability assessment results, reflecting the feasibility of transferring candidate nests to emergency tasks without significantly disrupting the stability of the original schedule. A higher score indicates that the nest is easier to release for emergency inspection tasks.

[0094] In practice, releasability assessment can be based on a pre-built weighted rule model. For example, after receiving the task attributes compiled by S104, different attributes can be mapped to a set of scoring factors, and then a unified releasability score can be formed through preset calculation rules.

[0095] Furthermore, in one possible embodiment, a scoring model can be constructed that includes a priority coefficient, a time window tolerance coefficient, and an alternative resource coefficient. The priority coefficient reflects the importance of the original task to be executed; the lower the priority of the original task, the higher the coefficient. The time window tolerance coefficient reflects the space for delaying the original task; the more remaining adjustable time, the higher the coefficient. The alternative resource coefficient reflects whether the original task can be taken over by other nearby nests; the higher the likelihood of substitution, the higher the coefficient. For example, the releasability score can be expressed as:

[0096] R score =(W pri ×S pri )+(W time ×S time )+(W alt ×S alt )+W penalty .

[0097] Among them, R score For releasability scoring, S pri S is the priority coefficient. time S represents the time window tolerance coefficient. alt To replace the resource coefficient, W penalty As a penalty item, W pri W time and W alt These represent the weight parameters of each factor, and each weight can be pre-configured according to the power grid business scenario and meet the requirements of sum normalization.

[0098] The weighting parameters allow the system to adapt to different power grid business priorities. For example, in disaster emergency scenarios, the impact of time window tolerance and alternative resource coefficients can be increased, while during regulatory assessment cycles, the impact of priority coefficients and constraint penalty coefficients can be appropriately increased. Standardizing the parameter range helps compare attributes from different sources on the same scoring scale, preventing a single indicator from excessively dominating the results due to differences in dimensionality.

[0099] Penalty terms are used to reflect certain constraints that reduce the likelihood of release, such as a task being associated with a power outage plan, the task being part of a project with a rigid regulatory deadline, the task having been delayed multiple times, or the task requiring a dedicated payload that cannot be replaced by other nesting systems. When such strong constraints exist, introducing penalty terms can make the scoring more consistent with actual scheduling patterns.

[0100] For ease of comparison, different coefficients can be standardized to a uniform numerical range, such as 0-100 or 0-1. Taking the time window tolerance coefficient as an example, it can be calculated based on the difference between the latest start time of the mission and the current time. The larger the difference, the more buffer there is for delay. Taking the alternative resource coefficient as an example, it can be obtained by combining the number of nearby alternative nests, the matching degree between the alternative nests and the original mission target range, and the flight cost after reassignment.

[0101] Furthermore, in some possible embodiments, a corresponding releaseability score can be generated for candidate nests in an unplanned occupied state, so as to compare all candidate resources within a unified framework. For example, idle nests can be directly assigned a higher baseline score, occupied nests can be assigned a lower or zero score, and nests in a fault-unavailable state or a maintenance-locked state can be assigned an unselectable marker or an extremely low score. In this way, when the final target nest is determined, it is not necessary to separate planned occupied nests from nests in other states; instead, a unified score comparison method can be used for selection. Further, to improve the stability of the evaluation, an initial score can be generated based on task attributes, and then corrected by incorporating real-time constraints. For example, if the planned occupied nest's current power recovery is slow, the wind speed is close to the flight threshold, or the communication link is unstable, points can be deducted from the original score, making the result closer to the actual execution conditions.

[0102] This step establishes a mapping from "planned occupancy" to "releaseability" by transforming the multidimensional attributes of the original tasks to be executed into quantitative scores. Compared to schemes that simply preempt tasks based on priority, this assessment considers the importance of the original task, deferral space, alternative possibilities, and strong constraints simultaneously. Therefore, it can more accurately distinguish between nests that are "occupied but easily transferable" and nests that are "similar in appearance but difficult to release in reality." Based on this, this approach elevates resource schedulability assessment to a quantifiable, sortable, and interpretable evaluation process, thereby improving the consistency between nest selection results and actual scheduling feasibility.

[0103] S106. Based on the status information of each candidate nest and all releaseability scores, determine the target nest from the candidate nest set.

[0104] Among them, the target nest can refer to the nest resources that are ultimately selected to perform emergency inspection tasks. It is mainly determined by comprehensively comparing the status information and releaseability scores of each nest in the candidate nest set, but it does not exclude the possibility of making decisions by combining spatial matching degree or other auxiliary factors when necessary.

[0105] In some examples, the status information of candidate nests includes categories such as idle, planned occupation, execution occupation, fault unavailable, and maintenance locked, while the releasability score is a further quantitative evaluation of nests in the planned occupation state. Combining the two, the following three cases can be handled: For idle nests, their status information indicates that they can be directly occupied, and the releasability score can be regarded as the default full score; for nests in the planned occupation state, their status information and releasability score need to be combined; for nests in the execution occupation, fault unavailable, and maintenance locked states, their status information indicates that they are unavailable and should be excluded.

[0106] In this step, in practice, one approach is to first assign a releaseability score to the nests corresponding to unplanned occupancy based on their status information. Then, after obtaining the releaseability scores for all candidate nests, the scores are sorted, and the candidate nests whose scores meet preset conditions are selected as the target nests. The preset conditions can be the highest score, or a secondary selection based on distance to the target location, estimated takeoff preparation time, estimated arrival time, or historical success rate after the score reaches a threshold. For example, when multiple candidate nests have a high release probability, the nest with the shortest estimated arrival time can be prioritized to meet the rapid response requirements of emergency missions.

[0107] Furthermore, in some possible embodiments, the target nest determination rule can be set as follows: first, candidate nests with scores below the minimum schedulable threshold are eliminated; then, the nest with the highest releaseability score is selected from the remaining candidate nests; when scores are the same or the difference is less than a preset tolerance, the spatial proximity between the nest and the target location, the remaining available power of the UAV, the nest communication quality, and the historical emergency mission response success rate are compared to select the optimal resource. In addition, to improve scheduling stability, a final availability check can be performed on several top-ranked candidate nests before determining the target nest. For example, this checks whether their status information has changed after the score calculation, confirms whether the original task to be executed has been adjusted by other systems, and confirms whether the weather and no-fly conditions are still met. If the check finds that the preferred nest is no longer available, it automatically reverts to the next scored nest, avoiding repeated rollbacks of the scheduling results.

[0108] Optionally, the top N (e.g., top 3) candidate nests can be output as target nests, forming a recommendation list, which is then manually confirmed by the scheduler as the final target nest.

[0109] In some examples, the specific output, once the target nest is determined, can generate a scheduling result record containing the target nest number, the corresponding emergency task number, a summary of the scoring criteria, the original planned task processing suggestions, and the scheduling effective time, and write this record to the task management database. If the target nest was originally in a planned occupied state, the reassignment, postponement, or rescheduling process of the original pending task can also be triggered simultaneously to maintain the consistency of the task system. For example, when the original pending task of the target nest has alternative resources, it can be automatically reassigned to the alternative nest; when it can only be postponed and cannot be reassigned, its start time is adjusted and the task reminder is recalculated. If there is no nest in the candidate nest set that meets the threshold conditions, the platform can also output a scheduling failure flag and trigger manual confirmation, expansion of the search scope, or cross-regional borrowing process.

[0110] Based on the above analysis, determining the target nest from the candidate nest set based on all releasability scores ensures that the scheduling result no longer relies solely on apparent proximity or static availability, but rather on actual releasability and executableness as the core criteria for resource selection. Since the scoring results already consider the possibility of releasing planned occupied resources, the final selected target nest better matches the actual execution conditions when emergency tasks are inserted, reducing subsequent reassignment, rollback, and duplicate judgments caused by nests failing to release on schedule. This not only improves the response speed of emergency inspection tasks but also enhances the continuity and stability of the entire nest resource scheduling process.

[0111] The nest resource scheduling method for emergency inspection tasks provided in this application integrates emergency task location retrieval, candidate nest status identification, planned occupied task attribute extraction, and releaseability quantitative assessment into a continuous scheduling process. This elevates the existing coarse static screening of planned occupied resources to a refined release judgment based on the characteristics of the task to be executed. This method does not require changing the original nest retrieval entry point, enabling more accurate differentiation between transferable and difficult-to-release planned occupied nest resources, improving scheduling accuracy and avoiding unreasonable resource recommendations. When an emergency inspection task is inserted, this method can quickly and accurately determine the target nest, reducing uncertainty in the scheduling process, allocating suitable nest resources to the emergency task in a timely manner, and improving emergency response speed. Simultaneously, determining the target nest based on releaseability scoring fully considers the arrangement and needs of the original planned tasks, minimizing their impact while meeting the emergency task requirements, achieving reasonable resource allocation and optimized utilization. Furthermore, this method avoids problems such as the inability to release selected nests due to improper handling of planned occupied status, making the entire nest scheduling process more stable and reliable, thus ensuring the execution efficiency of emergency inspection tasks.

[0112] Therefore, in various emergency inspection scenarios of the power grid (such as power grid wildfires, floods, ice accumulation, equipment alarms, and power supply inspections), this method can ensure a higher consistency between the target grid and the actual executable conditions, reduce the burden of manual verification, shorten the dispatch response time, and reduce resource conflicts, repeated reassignments, and result rollbacks caused by incorrect plan allocation of grids, thereby improving the accuracy, real-time performance, and reliability of grid resource selection in emergency inspection scenarios.

[0113] Based on the above embodiments, the releaseability of candidate nests is evaluated according to task attributes to obtain a releaseability score, including: determining a priority coefficient, a time window tolerance coefficient, and an alternative resource coefficient according to task attributes; and performing a weighted summation of the priority coefficient, the time window tolerance coefficient, and the alternative resource coefficient to obtain a releaseability score; wherein, the priority coefficient is used to indicate the priority feasibility of the task to be executed being preempted, the time window tolerance coefficient is used to indicate the start time flexibility of the task to be executed, and the alternative resource coefficient is used to indicate whether there is an alternative nest to execute the task to be executed.

[0114] In this embodiment, the priority coefficient can refer to a quantitative score determined based on the priority level of the task to be executed, used to indicate the feasibility of the task being preempted. Specifically, the priority coefficient reflects "whether the task is suitable to be interrupted by an emergency task from the perspective of task importance". Task priority levels are usually preset by the power grid operation and maintenance unit according to the importance, urgency and business type of the task. For example, in the scenario of power grid drone inspection, task priority levels can include multiple levels such as general (routine inspection, regular inspection), important (post-fault inspection, special inspection), special inspection / power supply guarantee (power supply guarantee for major events, preventive inspection before disaster emergency).

[0115] Specifically, tasks with a priority level of "general" have a high probability of being preempted and can be assigned a high priority coefficient; tasks with a priority level of "important" have a medium probability of being preempted and can be assigned a medium priority coefficient; tasks with a priority level of "special inspection / power supply protection" are usually marked as non-preemptible and can be directly assigned a priority coefficient of 0, indicating that the task should not be preempted. Furthermore, when the priority of the task to be executed is a preset non-preemptible type, in addition to assigning a priority coefficient of 0, the releaseability score can also be determined as a value indicating that it cannot be released.

[0116] In some embodiments, the priority coefficient can be determined using a discrete value mapping method. For example, when the original task priority is "normal", the priority coefficient S... pri =100; When the original task priority is "important", the priority coefficient S pri=50; When the original task priority is "Special Patrol / Power Supply" (i.e., the preset non-preemptible type), the priority coefficient S pri =0, and the system can directly determine that the nest is not releaseable without further calculation of other coefficients.

[0117] In other embodiments, the priority coefficients can take the form of finer-grained continuous values ​​or more discrete levels. For example, the priority can be divided into five levels: Level 1 (lowest, corresponding to S...). pri =100), Level 2 (lower, corresponding to S) pri =80), Level 3 (Medium, corresponding to S) pri =60), Level 4 (higher, corresponding to S) pri =30), Level 5 (highest / unclaimed, corresponding to S pri =0). This fine-grained partitioning method is suitable for power grid dispatching systems with complex business scenarios and multiple levels of task priority, and can more accurately distinguish the preemptibility of tasks of different importance.

[0118] In another example, the priority coefficient can be dynamically adjusted based on the task type, rather than being fixed to the priority level. For instance, for tasks of the same "important" level, the "post-fault inspection" type may be more preemptible than the "power supply guarantee special inspection" type. The system can add a task type correction factor to the priority coefficient, making the determination of the priority coefficient more closely match the actual business needs.

[0119] The time window tolerance coefficient is used to characterize the time margin that a task can delay takeoff. It can be calculated based on the task's planned start time, the allowed delay duration, and the task's pre-delay dependencies. When there is a large delay space for the task, the coefficient value is higher, while when the task requires on-time takeoff and the delay will affect subsequent linkages, the coefficient value is lower.

[0120] In some embodiments, the formula for calculating the time window tolerance coefficient can be: S time =min(100,(T interval / T tolerance ()×100). Among them, T interval T represents the interval (in minutes) between the current time and the original task's estimated start time. tolerance This represents the maximum allowed extension time (in minutes) for the original task. The formula means that the "allowed extension time" is used as a benchmark to measure the relative sufficiency of the "current remaining time." When the remaining time is greater than or equal to the allowed extension time, the ratio is 1 or higher, with a maximum score of 100, indicating very ample time and a full extension is possible. When the remaining time is less than the allowed extension time, the ratio is less than 1, and the score decreases linearly proportionally.

[0121] In other embodiments, the time window tolerance coefficient can also consider the absolute time constraints of the task. For example, some inspection tasks are affected by lighting conditions (e.g., can only be performed during the day) or limited by weather windows (e.g., needing to wait for a specific time after rain). In this case, a correction term can be added to the above formula: if the delay would exceed the effective execution window (e.g., sunset time), then S time Additional points will be deducted or the score will be set to 0. This correction method can prevent preemption from causing the original task to completely fail due to its inability to meet environmental constraints.

[0122] The alternative resource coefficient is used to characterize the feasibility of the task to be performed being taken over by other nests. It can be determined based on the number of available nests in the same area, the range coverage of alternative nests, the refueling status, and the load matching relationship. When there are nests in the vicinity that meet the endurance and load conditions, the coefficient takes a higher value, and when only a single nest can perform the task, the coefficient takes a lower value.

[0123] In some embodiments, the alternative resource coefficient can be determined in a binary manner: if an available alternative nest exists, then S alt =100; if there is no alternative resource, then S alt =0. This binarization method is simple, clear, and computationally efficient, making it suitable for emergency dispatch scenarios with high real-time requirements.

[0124] Among these requirements, a usable replacement drone nest must meet several conditions: First, it must be able to cover the target location of the original mission in space (i.e., the distance from the replacement drone nest to the target location of the original mission is within its service radius); second, it must have an available time window to accommodate the original mission (i.e., there is an overlap between the available time period of the replacement drone nest and the expected execution time period of the original mission); and third, it must be compatible in terms of equipment capabilities (e.g., the model of the drone carried by the replacement drone nest and the type of equipment mounted meet the inspection requirements of the original mission).

[0125] In other embodiments, the alternative resource coefficient may take the form of a continuous value or more discrete levels to reflect the sufficiency of alternative resources. For example, it may be defined as: S = (S_n) when multiple available alternative nests exist. alt =100, S = when there is a usable alternative nest. alt =70, when there is a limited alternative nest (e.g., a long waiting time is required) S alt =40, S when there is no alternative nest alt =0. This finer-grained division can more accurately reflect the sufficiency of alternative resources, which helps to make more reasonable decisions in subsequent comprehensive ranking.

[0126] In practical implementation, after determining the priority coefficient, time window tolerance coefficient, and alternative resource coefficient, a weighted sum of these three coefficients yields the releaseability score. Weighted summation involves assigning a weight value to each coefficient, multiplying each coefficient by its corresponding weight, and then summing the results to obtain a comprehensive score. The weight values ​​reflect the degree of importance placed on each of the three factors—priority, time flexibility, and alternative resources—in actual scheduling decisions.

[0127] In some embodiments, the releasability score is calculated using the formula: R score =(W pri ×S pri )+(W time ×S time )+(W alt ×S alt Among them, W pri W time and W alt The preset weights are given, and W satisfies the following conditions. pri +W time +W alt =1. R score The value range is usually [0, 100]. A higher score means that the nest is more suitable for emergency missions to seize (i.e., the lower the cost of seizing it and the smaller the negative impact); a lower score means that the cost of seizing the nest is higher.

[0128] In some implementations, the weight W pri W time and W alt The value of W can be dynamically adjusted based on the characteristics of the power grid area, seasonal factors, and task type. For example, in mountainous power grid areas, where generator nest resources are relatively scarce, the availability of alternative resources is more important, which can improve W. alt The weight of W; in plains areas, where nest resources are dense, time flexibility may be more critical, which can improve W time The weight of W. For example, during peak summer demand periods, when grid load is high, the priority of inspection tasks is generally increased, which can improve W. pri The weight of W can be appropriately reduced during non-power supply guarantee periods, as routine inspection tasks are more readily available. pri The weight.

[0129] Optionally, the system can set a releasability threshold R. threshold (e.g., 60 points), R score <R threshold The planned occupied state nest is considered a "non-preemptible resource" and will be directly removed or downgraded in subsequent comprehensive ranking. Only R score ≥R thresholdOnly nests in the planned occupancy status are included in the final emergency candidate set for comprehensive sorting. This threshold filtering mechanism reduces the computational load of subsequent comprehensive sorting while avoiding including nests with excessively high preemption costs in the candidate list, thus improving the efficiency and rationality of scheduling decisions.

[0130] By adopting this implementation method, the releaseability judgment is changed from a single state screening to a comprehensive evaluation based on task attributes. This can improve the accuracy of the release judgment of planned occupied nests, identify transferable resources without relying on manual review, avoid misselecting nests that are difficult to release as target nests, reduce the number of reassignments and rollbacks after emergency inspection tasks are inserted, and improve the consistency between scheduling results and actual executable conditions, thereby enhancing the accuracy of nest resource scheduling and emergency response efficiency.

[0131] In one possible implementation, the method may further include: obtaining the number of cascaded reordering tasks that will result from preempting a candidate nest; determining a penalty term based on the number of cascaded reordering tasks, wherein the penalty term is positively correlated with the number of cascaded reordering tasks; and updating the releaseability score based on the penalty term to obtain the updated releaseability score.

[0132] The number of cascaded rescheduled tasks refers to the number of subsequent tasks that need to be rescheduled after the current candidate nest is preempted for an emergency task, due to the postponement or cancellation of the original planned task. The core meaning of the number of cascaded rescheduled tasks is that the original planned task is not only an isolated task, but it may also have time dependencies, resource dependencies, or logical dependencies with other tasks in the system. When a task is preempted, this dependency will propagate like dominoes to downstream tasks, triggering a series of rescheduling requirements.

[0133] In some embodiments, the number of cascaded reordering tasks can be determined based on task dependency graph analysis. A task dependency graph is a directed graph structure where nodes represent tasks and directed edges represent dependencies between tasks. For example, task B can only begin after task A is completed (time dependency), or tasks A and B share the same nesting resource and are temporally adjacent (resource dependency). When task A is preempted, task B and its subsequent dependent tasks may need to be rescheduled. The system traverses the task dependency graph and counts the number of all affected subsequent tasks as the number of cascaded reordering tasks.

[0134] In other embodiments, the number of cascaded tasks can also consider indirect dependencies. For example, although task B does not directly depend on task A, a certain type of drone battery required by task B can only be released after task A is completed (resource release dependency). This indirect dependency will also trigger cascaded reordering, and the system can identify such dependencies through resource usage timeline analysis.

[0135] The penalty item refers to the deduction value determined based on the number of cascaded tasks, used to reflect the chain reaction cost caused by the preemption operation to the original task system. The penalty item is positively correlated with the number of cascaded tasks; that is, the more cascaded tasks there are, the larger the penalty item value (the more deductions), indicating that the cost of preempting the nest is higher.

[0136] In some embodiments, the formula for calculating the penalty term can be: W penalty =C×N cascade Among them, N cascade C represents the number of cascaded reordering tasks, and C is the deduction coefficient for each task (e.g., deducting 10 or 5 points per task). The specific value of the deduction coefficient can be configured according to the importance of the business scenario. For example, during power supply guarantee periods, the deduction coefficient can be increased so that even a small number of cascaded tasks will significantly reduce the releaseability score, thereby reducing the possibility of preempting regular tasks during high-value periods. For example, using a deduction coefficient C=10, the number of cascaded reordering tasks N in a certain yellow-light server nest is... cascade =2, then the penalty term W penalty =10×2=20 points.

[0137] In other embodiments, the penalty term can be calculated non-linearly. For example, when the number of cascading rearrangement tasks is small (e.g., 1-2), the penalty for each task is small; when the number of cascading rearrangement tasks is large (e.g., more than 5), the penalty for each task increases progressively to reflect the high cost of a large-scale chain reaction. This approach can be implemented using a piecewise function: N cascade When ≤2, C=5; 3≤N cascade When ≤5, C=10; N cascade When the value is ≥6, C=15. This nonlinear penalty can more accurately reflect the system scheduling pressure brought about by large-scale cascading rearrangements.

[0138] In other embodiments, the penalty term may also consider the priority weights of the cascaded tasks. For example, if the cascaded tasks include high-priority tasks (such as critical power supply tasks), a higher penalty should be applied even if the number is small. In this case, the penalty term calculation formula can be: W penalty =Σ(C i ×w i ), where C i Deduct points based on the base score, w i This represents the priority weighting coefficient for cascaded tasks.

[0139] The releaseability score is updated based on the penalty factor, resulting in an updated releaseability score. This update means deducting the penalty factor from the original releaseability score to reflect the overall cost of the preemption operation. The updated releaseability score can more comprehensively and accurately assess the actual feasibility of the "preemption of the nest" operation.

[0140] In some embodiments, the updated releasability score calculation formula is: R score_updated =R score +W penalty Among them, R score W is the original releasability score calculated in the above embodiments. penalty This is a penalty term. The updated score range is usually still limited to the [0, 100] interval. If R score_updated If it is less than 0, then take 0.

[0141] Optionally, the updated releaseability score can directly replace the original releaseability score and participate in subsequent comprehensive ranking. This substitution method ensures that cascading effects are fully incorporated into the scheduling decision.

[0142] In other embodiments, the releasability score can also be updated in a multiplicative manner. For example, R score_updated =R score ×(1-λ×N cascade / (N cascade +K)), where λ and K are adjustment parameters. The multiplicative update method can more smoothly reflect the non-linear impact of the number of cascaded tasks on the score, while avoiding negative scores.

[0143] Optionally, the system can display the original releaseability score, penalty details (including the number of cascading tasks and deduction details) and the updated releaseability score in the score display interface, so that the scheduler can clearly understand the composition of the preemption cost and assist in manual confirmation of decision-making.

[0144] This implementation expands the criteria for releasability scoring from a single task attribute to a joint assessment of task attributes and the impact of cascading rearrangements. This reduces the probability of misselecting highly disruptive nests, minimizes subsequent reassignment and rollback, improves the accuracy, real-time performance, and continuity of nest resource scheduling, and enhances the overall scheduling reliability in scenarios where emergency inspection tasks are inserted.

[0145] Based on the above embodiments, the target nest is determined from the candidate nest set based on the status information of each candidate nest and all releasability scores. This includes: determining the distance information, real-time status information, health information, and estimated response time of each candidate nest from the target location based on the status information of each candidate nest; for each candidate nest, if the candidate nest is in a planned occupancy state, obtaining the corresponding releasability score; if the candidate nest is not in a planned occupancy state, setting the corresponding releasability score to a preset value; performing a weighted summation of the distance information, real-time status information, health information, estimated response time, and releasability score of the candidate nest to obtain a comprehensive score result; and sorting all the comprehensive score results, determining the candidate nest with the highest ranking as the target nest.

[0146] The distance information refers to the spatial distance between the candidate drone nest's geographical location and the target location of the emergency inspection mission, usually measured in kilometers (km). This distance determines the flight time and power consumption required for the drone to take off from the nest and reach the target area, making it one of the most intuitive and important considerations in emergency dispatch. The closer the distance, the less endurance pressure the drone faces, the shorter the arrival time, and the higher the emergency response efficiency. In actual calculations, the distance information can be Euclidean distance (straight-line distance) or great-circle distance (spherical distance). Considering that the drone needs to avoid obstacles and no-fly zones during actual flight, the actual flight path distance calculated based on the flight path planning algorithm can also be used. For implementations using the actual flight path distance, the system needs to call the path planning engine, combine terrain data, no-fly zone data, and flight path constraints to generate the optimal flight path from the nest to the target location and calculate its length.

[0147] Real-time status information refers to a quantitative representation of the current operational status of a candidate hive, indicating whether the hive is ready or about to be deployed for emergency mission execution. While related to the aforementioned status information, real-time status information places greater emphasis on its computability in the overall scoring process. The operational status of a hive can be categorized as: green light (idle and available), yellow light (planned occupancy), red light (occupancy in progress), and gray light (faulty / offline / disabled).

[0148] To facilitate weighted summation, these states need to be numerically mapped. In some embodiments, the quantification rules for real-time state information are as follows: green light state is assigned a value of 1.0 (fully available); yellow light state, when the release condition is met, is assigned a value of 0.7 (conditionally available, but preemption operation is required); red light state or yellow light state, but not available for release, is assigned a value of 0 (unavailable); gray light state is assigned a value of -1 (unavailable and lowest priority, the actual effect is equivalent to elimination). This numerical mapping allows real-time state information to directly participate in the weighted summation calculation and distinguishes the superiority or inferiority relationship between different state levels. In other embodiments, finer-grained quantification rules can be used, such as green light state 1.0, yellow light high releaseability 0.8, yellow light medium releaseability 0.6, yellow light low releaseability 0.4, red light 0, gray light -1, to achieve more refined state differentiation.

[0149] Health information refers to a quantitative assessment of the health status of candidate drone nests and their onboard drones. The value range is typically [0,1], with higher values ​​indicating more reliable equipment. Health information is dynamically generated based on self-test data reported by the drone nests and can include a comprehensive weighted average of sub-items such as charging module status, battery health, communication quality, and motor status.

[0150] The estimated response time refers to the time required from the current moment until the drone in the nest can actually take off and perform its mission. It is usually measured in minutes and includes the total time for communication connection, self-test, push-out, positioning, and loading of the flight path. For nests in the yellow light status, the estimated response time should also include the additional operation time for canceling / freezing the original mission.

[0151] For each candidate nest, if the nest is in a planned occupancy state (i.e., yellow light state), the releaseability score (original score or updated score) calculated in the above embodiments is obtained as a releaseability factor participating in the comprehensive score; if the nest is not in a planned occupancy state (i.e., green light state), there are no tasks to be executed and no concept of release, and the system sets its releaseability score to a preset value. In some embodiments, the preset value can be set to a full score (e.g., 100 points), indicating that the nest can be directly occupied without any release operation, achieving optimal releaseability. In other embodiments, the preset value can be set to a fixed value higher than the highest possible score of any yellow light nest (e.g., 110 points) to ensure that green light nests are absolutely superior to all yellow light nests that need to be preempted in terms of releaseability.

[0152] The five factors mentioned above are weighted and summed to obtain a comprehensive score. The weight values ​​reflect the degree of importance given to different factors in emergency dispatch decision-making. In some embodiments, the comprehensive score is calculated using the following formula: Score total=α × Distance Score + β × Real-time Status Score + γ × Health Score + δ × Normalized Releaseability Score + ε × Response Timeliness Score, where α, β, γ, δ, and ε are configurable weight coefficients that satisfy α + β + γ + δ + ε = 1. The values ​​of each weight coefficient are dynamically adjusted based on the task type of the emergency inspection mission or the characteristics of the power grid area. The power grid area characteristics specifically include at least one of the following: terrain type (e.g., mountainous and plain areas), airspace restrictions, and seasonal characteristics.

[0153] Furthermore, in this embodiment, the distance score needs to be normalized from the original distance, for example, by using distance score = D. max / D i D i D represents the actual flight distance from the candidate nest to the target location. max The score is determined by the maximum acceptable flight distance; the closer the distance, the higher the score, which directly relates to the drone's endurance and emergency arrival time. Real-time status scores are directly calculated using the aforementioned quantified values ​​(green light 1.0, yellow light releaseable 0.7, yellow light but not releaseable, or red light = 0, gray light = -1). Health scores are directly calculated using health information (range [0,1]), which can be dynamically generated based on self-check data reported by the drone's nest (such as charging module integrity, communication latency, etc.). Normalized releaseability score: For green-light drones, the releaseability score is preset to 100 points, normalized to 1.0; for yellow-light drones, the releaseability score is divided by 100 to obtain a normalized value in the [0,1] range. Response timeliness scores can be expressed as a reciprocal, such as response timeliness score = 1 / T. response_i The faster the response, the higher the score.

[0154] Furthermore, the formula for calculating the overall score can be: Score total =α×(D max / D i )+β×State i +γ×Health i +δ×(R score_i / 100)+ε×(1 / T response_i ), where D max / D i For distance score, State i Health is a real-time status score. i R scores the health level. score_i / 100 is the normalized value of the releasability score, 1 / T response_i The score is based on response timeliness.

[0155] The comprehensive scores of each candidate nest are sorted in descending order, and the highest-ranked candidate nest is determined as the final target nest. Optionally, the system can output the top N candidate nests as a recommendation list for manual confirmation by the scheduler; or an automatic confirmation threshold can be set, automatically locking the nest when the score of the top-ranked nest is significantly higher. If the comprehensive scores of all candidate nests are lower than the preset threshold, the system determines that there are no usable resources, and either switches to manual handling or prompts the system to expand the search scope.

[0156] This approach moves beyond relying solely on distance for nest selection. Instead, it incorporates task response speed, equipment health status, current availability, and the release capability of planned resources into the evaluation system, making the ranking results closer to real-world scheduling conditions. Because the comprehensive scoring considers multi-dimensional constraints, the system can automatically filter out target nests that balance reachability and feasibility from multiple candidate nests. This reduces scheduling rollbacks caused by resources appearing available but actually difficult to release, improving the accuracy and real-time performance of emergency inspection task allocation.

[0157] In one possible implementation, before obtaining the target location of the emergency inspection task, the method may further include: obtaining a task creation instruction, which is triggered by at least one of the following methods: a one-click creation button, input through a dispatch terminal, linkage triggering by an alarm system, and reporting from a mobile terminal; generating an emergency inspection task based on the task creation instruction, and determining the emergency level priority of the emergency inspection task; wherein, the emergency inspection task includes a task type and a target area.

[0158] The task creation instruction can refer to the control signal or data packet used to trigger the generation of an emergency inspection task. This instruction carries basic information about the emergency task, such as the task source identifier, trigger time, target description (target site, area, tower number, or fault coordinates), and task type. Obtaining the task creation instruction is the starting point of the emergency dispatch process, determining the task's response time and subsequent processing path.

[0159] The one-click creation button refers to a shortcut control provided on the main interface of the dispatch and command system. After receiving an emergency notification, the dispatcher can click this button to quickly enter the task creation process. The system automatically fills in basic information such as the current time and default task type (e.g., "emergency reconnaissance"), and waits for the dispatcher to add necessary fields such as the target location. The core advantage of this triggering method is its ease of operation, making it suitable for scenarios requiring rapid response.

[0160] Dispatch terminal input refers to the method by which dispatchers manually fill out task forms using professional dispatch terminals (such as command center workstations or portable dispatch tablets). Compared to "one-click creation," this method allows dispatchers to input more detailed task information, such as lists of multiple target points, special operational requirements, and information on collaborating units, making it suitable for complex emergency scenarios.

[0161] Alarm system linkage triggering refers to the automatic sending of a task creation command containing alarm information to the dispatch system after an anomaly is detected by the power grid online monitoring system (such as wildfire monitoring, tower tilt monitoring, conductor icing monitoring, fault location system, etc.). For example, after the wildfire monitoring system detects a hotspot, it automatically generates a task creation command containing information such as the fire point coordinates and fire intensity level, which the dispatch system then automatically files upon receiving. This triggering method achieves a fully automated closed loop from "anomaly detection" to "inspection task creation" without manual intervention.

[0162] Mobile reporting refers to emergency task requests submitted by on-site inspection or repair personnel via mobile devices such as smartphone apps and handheld terminals. Mobile reporting typically includes on-site photos, videos, text descriptions, and automatically acquired GPS coordinates from the equipment. This triggering method leverages the location and perception advantages of frontline personnel to shorten the response chain from on-site discovery to task dispatch.

[0163] The four triggering methods described above can be used individually or in combination. For example, after the alarm system triggers automatic task creation, the dispatcher can supplement or correct the task information through the dispatch terminal; or after a report is submitted via mobile device, the system simultaneously pushes a notification to the dispatch terminal, allowing the dispatcher to supplement and confirm the information via a one-click creation button. The coexistence of multiple triggering methods allows this approach to adapt to different levels of emergency response needs, covering everything from fully automated alarm linkage to manually-led dispatcher input.

[0164] Based on the task creation command, an emergency inspection task is generated and its emergency priority is determined. This means that the system creates a complete emergency task record based on the information carried in the command. This record includes at least: a unique task identifier (such as a task ID), a task type (such as wildfire investigation, fault inspection, power supply protection special inspection, disaster assessment, etc.), a target area (which can be point coordinates, a polygonal area, a list of towers, or a line section), a task creation timestamp, the task initiating unit (such as a maintenance team), the task source (such as an alarm system), and the emergency priority.

[0165] Emergency priority refers to the highest priority level automatically assigned by the system to emergency inspection tasks. Emergency priority is higher than the priority of regular inspection tasks (such as "normal" or "important") to ensure that emergency tasks receive the highest processing authority in subsequent resource preemption, scheduling decisions, and reordering. In some embodiments, the priority system can be set as: Emergency (highest), Important (medium), and Normal (lowest). In resource contention scenarios, emergency priority tasks can preempt resources occupied by important or normal priority tasks. The specific value of emergency priority can be a fixed value preset by the system (e.g., priority value = 0 represents the highest) or a dynamically calculated value (e.g., determined comprehensively based on task type and alarm level).

[0166] Task type can be used to indicate the specific operational purpose of emergency inspections, such as: wildfire reconnaissance (locating fire points and assessing the risk of fire spread), equipment failure inspection (finding fault points and assessing the extent of equipment damage), special power supply inspection (special inspections of important lines or substations), disaster assessment (comprehensive inspections after typhoons, floods, and earthquakes), etc. The determination of the task type will affect subsequent resource retrieval strategies. For example, wildfire reconnaissance may require drones equipped with infrared thermal imaging equipment, while equipment failure inspection may require high-resolution visible light cameras.

[0167] The target area can refer to the geographical area that needs to be surveyed for an emergency inspection mission. The target area can be represented as: single-point coordinates (e.g., the location of a faulty tower), a list of multi-point coordinates (e.g., multiple fault points), a polygonal region (e.g., a wildfire-affected area), a list of tower numbers (e.g., a continuous section of towers on a certain line), or a line segment (e.g., from tower 1 to tower 3). The accuracy of the target area directly affects the accuracy of subsequent candidate nest space retrieval. In some embodiments, the system can automatically convert the target area into target location coordinates based on the task type (e.g., calculating the center point of the polygonal region as the search center).

[0168] Optionally, after a task is created, the system automatically sends a task creation notification to the relevant dispatcher, on-duty personnel, or task approver, informing them that the emergency task has been filed and is awaiting processing.

[0169] This implementation method allows the system to integrate emergency inspection tasks from multiple triggering points into a standardized creation process, and simultaneously determine the emergency priority during task generation. This improves the timeliness and consistency of task initiation and enhances operational efficiency in scenarios requiring manual intervention. Because the task object includes both task type and target area, the subsequent scheduling process can more accurately match resources with regional needs, reducing manual input errors and response waiting time, thereby improving the processing efficiency and scheduling reliability of power grid emergency inspection tasks.

[0170] Based on the above embodiments, after obtaining the status information of each candidate nest in the candidate nest set, the method further includes: classifying the status of each candidate nest in the candidate nest set according to the status information to obtain the nest status of each candidate nest, where the nest status includes green light status, yellow light status, red light status, or gray light status; wherein, green light status indicates that the nest is in an idle and available state, yellow light status indicates that the nest is in a planned occupancy state, red light status indicates that the nest is in an execution occupancy state, and gray light status indicates that the nest is in a fault offline state; correspondingly, for each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, then the task attribute of the task to be executed corresponding to the candidate nest is obtained, including: for each candidate nest in the candidate nest set, if the nest status of the candidate nest indicates that the candidate nest is in a planned occupancy state, then the task attribute of the task to be executed corresponding to the candidate nest is obtained.

[0171] State classification refers to the process of mapping the raw state information of candidate nests to preset nest state categories. The raw state information may include various fine-grained data (such as nest working mode, current task ID, task start and end time, device self-test code, communication status, etc.). State classification summarizes this information into a limited number of state categories, which facilitates subsequent differentiated processing logic.

[0172] A green light indicates that a nest is idle and available, meaning it has no current tasks, no future plans to occupy it, and the equipment is functioning normally. The system can directly occupy it without requiring a releaseability assessment. A yellow light indicates that a nest is in a planned-occupancy state, meaning it is currently idle but has already been pre-assigned to other tasks. For nests in the yellow light state, the system needs to obtain the task attributes of the tasks to be executed and perform a releaseability assessment to determine whether it is suitable to be preempted by an emergency task. A red light indicates that a nest is in an execution-occupancy state, meaning it is currently executing an inspection task. Forcibly preempting it would interrupt the currently executing task, which has high costs and risks. Therefore, nests in the red light state can be marked as unavailable and not included in subsequent sorting. A gray light indicates that a nest is in a faulty or offline state, including equipment failure, communication interruption, or being disabled by the administrator, and it is directly removed from the candidate set.

[0173] In some embodiments, status classification can employ a priority-based logic: first, check if the server is faulty or offline; if so, classify it as a gray light. Second, check if there are any tasks currently being executed; if so, classify it as a red light. Third, check if there are any scheduled tasks waiting to be executed; if so, classify it as a yellow light. If none of the above conditions are met, classify it as a green light. This classification order ensures the mutual exclusivity and completeness of the status definitions. In other embodiments, finer-grained classification can also be used, such as subdividing yellow light into short-term / long-term occupation, and gray light into fault / offline / disabled.

[0174] After status classification, the system executes differentiated processing strategies based on the classification results: for green-light status nests, they directly enter the comprehensive sorting stage; for yellow-light status nests, the system triggers the process of obtaining the task attributes of the task to be executed and the subsequent releaseability assessment; for red-light and gray-light status nests, they are removed from the candidate set or assigned a very low score in the subsequent comprehensive sorting (weight reduction). This differentiated processing strategy is the basis for subsequently determining the target nest. For example, in an emergency dispatch, the candidate nest set contains 4 nests: nest A is classified as green, nest B as yellow, nest C as red, and nest D as gray. The system directly retains nests A and B for subsequent processing; nest A does not require releaseability assessment, and nest B triggers the task attribute acquisition process; nests C and D are removed and do not participate in the comprehensive sorting.

[0175] It should be noted that the nest status (green / yellow / red / gray) defined in this embodiment has a clear correspondence with the real-time status information in the above embodiments. Specifically: the green light status corresponds to a quantized value of 1.0 for real-time status information, indicating full availability; the yellow light status needs to be further divided into two sub-cases: "releaseable" and "non-releaseable," where a releaseable yellow light nest corresponds to a quantized value of 0.7, and a non-releaseable yellow light nest corresponds to a quantized value of 0 (treated the same as the red light); the red light status (execution occupancy) corresponds to a quantized value of 0; and the gray light status (fault / offline) corresponds to a quantized value of -1. This correspondence ensures that the status classification results can be directly used as input to the "real-time status information" factor in the comprehensive scoring model of the above embodiments, achieving a seamless connection from status classification to quantized scoring.

[0176] The above processing enables the system to perform state hierarchical analysis after retrieving candidate nests, and then further analyze the attributes of planned occupied resources, thereby avoiding the inclusion of resources that are currently occupied or offline due to failure in subsequent evaluations. For nests in a planned occupied state, after obtaining the attributes of the tasks to be executed, the scheduling system can determine whether they have available space and provide input for subsequent releaseability scoring. Using this approach, the system can more accurately distinguish between idle resources, preemptible resources, and unavailable resources, reducing the probability of incorrect nest selection, improving the scheduling accuracy and real-time performance when inserting emergency inspection tasks, and reducing the time loss caused by manual verification and repeated reassignments.

[0177] Based on the above embodiments, after determining the target nest from the candidate nest set based on the status information of each candidate nest and all releasability scores, the method may further include: in response to the locking operation on the target nest, updating the status of the target nest to an emergency locking status; if the target nest was in a planned occupied state before locking, automatically generating an original task rollback record, the original task rollback record including the pending task identifier corresponding to the target nest, the original allocated nest identifier, the reason for preemption, and the time of preemption; updating the status of the pending task corresponding to the original task rollback record to a pending rescheduling state, and writing it into the pending rescheduling pool.

[0178] The locking operation refers to a one-time resource occupation action performed by the dispatcher or the system on a target nest. This operation can be triggered by the dispatcher selecting a target nest from the recommended list and clicking the "One-Click Lock" button, or it can be automatically triggered by the system in automatic confirmation mode (such as when the nest ranked first has a significantly higher overall score). The essence of the locking operation is to transform the decision result into actual resource occupation behavior, which is a key turning point in the emergency dispatch process from "selection" to "execution".

[0179] Emergency lockout status refers to a special occupancy state where a target drone nest is marked as exclusively for the current emergency mission. A nest in emergency lockout status is subject to the following constraints: preventing other regular missions (non-emergency missions) from applying for or occupying the nest; during the lockout period, the nest and associated drones will not participate in regular mission scheduling; the system records the lockout time, reason for lockout, and initiator information, forming a traceable operation log. The core difference between emergency lockout status and yellow light status (planned occupancy) is that yellow light status is a "pre-announcement" pre-occupancy, which can be negotiated and preempted by higher-priority emergency missions; while emergency lockout status is a "forced" lockout, which, once set, cannot be broken by other missions. The difference from red light status (execution occupancy) is that red light status indicates the nest is currently executing a mission, while emergency lockout status indicates the nest has been reserved but has not yet started executing an emergency mission.

[0180] The original task rollback record refers to a structured record automatically generated by the system when a target nest was originally bound to a planned task (i.e., in a yellow light state). It describes the complete information about the original task being preempted. The generation of the original task rollback record is automatic and requires no manual intervention. This record must contain at least the following: the task identifier (the unique ID of the original task, such as "T-20231015-001"), used to uniquely identify the preempted task in the system; the original nest identifier (the nest ID originally planned to be used by the original task), used to trace the resource allocation history; the reason for preemption (a fixed value or dynamic description, such as "preempted by emergency task [task ID]"), used to explain the reason for the task status change; and the preemption time (system timestamp), used to record the time of the preemption operation for subsequent auditing and analysis.

[0181] In some embodiments, the original task rollback record may also include extended information, such as: the planned start and end times of the original task (used to record the original plan before being preempted), the priority level of the original task (used for reference during subsequent rescheduling), the ID of the emergency task (used to establish preemption association), and the identifier of the scheduler or system module that initiated the preemption.

[0182] The "Pending Rescheduling" state refers to the intermediate state of a task after it has been preempted, indicating that the task needs to be rescheduled. This state differs from the "Pending Execution" state (normally queuing for execution) and the "Cancelled" state (the task has been permanently terminated). The core meaning of the "Pending Rescheduling" state is that the task itself is still valid (not cancelled), but the original resource allocation has been revoked, and the system needs to find an available host and time window for it.

[0183] The rescheduling pool can refer to a unified data structure (which can be an in-memory task queue, database table, or message queue) that manages all tasks that need to be rescheduled. The rescheduling pool is used to temporarily store tasks that need to be rescheduled due to emergency insertions, equipment failures, weather changes, resource preemption, etc. Tasks in the rescheduling pool will be processed one by one or in batches by the rescheduling engine according to certain strategies (such as sorting by priority, time window constraints, etc.). The operation of writing tasks to be executed into the rescheduling pool typically includes: inserting the task record into the rescheduling pool data table, setting the task status to "pending rescheduling," recording the timestamp of entry into the pool, and triggering the rescheduling engine's scanning or notification mechanism.

[0184] In some embodiments, if the target nest is in a green light state before locking (i.e., no originally planned task), there is no need to generate an original task rollback record or write it to the rescheduling pool. The system directly updates the nest from the green light state to the emergency lock state and then executes the emergency task. For example, the system determines that the target nest is nest B. Nest B is in a yellow light state before locking, and its task to be executed is "T-10086" (routine inspection of tower 2). After the system executes one-click locking: the status of nest B is updated from "yellow light" to "emergency lock"; an original task rollback record is automatically generated, including the task ID "T-10086", the originally assigned nest "nest B", the reason for being preempted "preempted by emergency task EM-001", and the time of preemption "2025-01-15 14:30:22"; the status of task "T-10086" is updated from "pending execution" to "pending rescheduling", and it is written to the rescheduling pool. Subsequently, the reordering engine detects a new task in the reordering pool and automatically triggers reordering processing.

[0185] Optionally, after generating the original task rollback record, the system can immediately send a preemption notification to the original task's unit or responsible person, informing them that the task has been preempted by an emergency task and will enter the automatic rescheduling process. This notification can be sent via system message, SMS, social media, or email.

[0186] This processing method enables the target nest to immediately enter emergency exclusive control after being selected. Furthermore, if it was originally in a planned occupied state, the system can automatically roll back the original task and re-allocate it to the pool, avoiding delays and omissions caused by manual intervention. Because the rollback record fully preserves the task source, resource ownership, and preemption time, it can be used for both task recovery and scheduling auditing, thereby improving the continuity, traceability, and resource scheduling stability when inserting emergency inspection tasks.

[0187] In one possible implementation, after updating the status of the task to be executed corresponding to the original task rollback record to the pending rescheduling status and writing it into the pending rescheduling pool, the method may further include: triggering the rescheduling engine to automatically schedule the tasks in the pending rescheduling pool. The automatic scheduling process includes: reading the original constraints of the task to be executed, reading the currently available nesting set and the corresponding time window, and generating a new execution plan; when the automatic scheduling is successful, generating a new execution plan and sending a notification; when the automatic scheduling fails, marking the task to be executed as pending manual confirmation and sending a notification.

[0188] The reordering engine can continuously monitor or periodically scan the reordering pool, automatically triggering the scheduling process when a new task is detected. Triggering the reordering engine means actively calling its interface or sending a trigger signal. Triggering opportunities include, but are not limited to: triggering immediately after a task is written to the reordering pool (synchronous triggering), triggering by the asynchronous notification mechanism of the reordering pool (such as message queue consumption), or triggering by a timed polling mechanism when the reordering pool is detected to be non-empty. Synchronous triggering minimizes the waiting time after a task is preempted.

[0189] Automated scheduling refers to a series of automated scheduling operations performed by the rescheduling engine. Specific steps may include: reading the original constraints of the task to be executed (i.e., various restrictions that the task must meet during execution, such as time constraints, equipment constraints, route constraints, dependency constraints, etc.); reading the currently available nest set (i.e., at the current time, the set of idle nest resources available for reallocation, excluding resources already locked by emergency operations or occupied by other tasks, excluding resources already locked by emergency operations or occupied by other tasks) and the corresponding time window (the time interval within which each nest can accept new tasks); and generating a new execution plan through a scheduling algorithm (such as a greedy algorithm or heuristic search). The new plan must include at least: the newly allocated nest identifier, the suggested start and end times, and the updated route plan (if the nest change causes a change in the takeoff point). If multiple feasible plans exist, the rescheduling engine can select the optimal plan (e.g., earliest time, shortest distance, or lowest overall cost).

[0190] When automatic scheduling is successful, meaning the rescheduling engine has found at least one feasible alternative, the system will: associate the new solution with the task to be executed, update the task status to "rescheduled" (or "pending execution"), and send a notification to relevant parties to inform them of the specific information of the new solution.

[0191] When automatic scheduling fails, meaning the rescheduling engine cannot find a feasible solution that satisfies all constraints within the preset search range, the system updates the task status to "awaiting manual confirmation" and sends a notification requesting manual intervention. Manual intervention may include manually allocating task nests, relaxing time constraints, and adjusting task priorities. In some embodiments, when automatic scheduling fails, the system may also execute alternative processing logic: automatically postpone the task to the next available time window and try scheduling again; automatically transfer the task to another professional team; or generate a task cancellation suggestion and submit it for approval.

[0192] In some embodiments, notifications may be sent via various channels such as system push notifications, SMS, email, social media, or telephone voice calls to ensure that relevant parties receive notifications in a timely manner.

[0193] For example, after task T-10086 is preempted, it is written to the rescheduling pool. The rescheduling engine is triggered: read constraints (must be completed before 18:00 today, requires a visible light camera); read available nests (nest C is idle, nest D is idle) and time windows (nest C, available from 14:00 to 18:00); generate a new scheme (nest C, 15:00 to 16:00). Upon success, the task status is updated to "rescheduled" and a notification is sent. If no nests are available, the scheduling fails, the task status is updated to "awaiting manual confirmation," and an alarm notification is sent.

[0194] By adopting the above method, tasks awaiting rescheduling can be automatically rescheduled by the system after rollback, improving task recovery efficiency and scheduling closed-loop capability. Since the rescheduling process considers the original constraints, the current available nesting set, and the time window simultaneously, the newly generated execution plan is more consistent with the actual resource status, reducing invalid scheduling and duplicate reassignments. When automatic scheduling fails, the system promptly switches to a state awaiting manual confirmation and sends a notification, thus providing a clear fallback mechanism for abnormal scenarios and improving overall scheduling stability and controllability.

[0195] Based on the above embodiments, the method may further include: in response to the completion of the emergency inspection task, releasing the emergency lock state on the target nest and updating the state of the target nest to a green light state, the green light state being used to indicate that the nest is in an idle and available state; generating an emergency dispatch record, the emergency dispatch record including the lock record of the target nest and the original task rollback record.

[0196] In this embodiment, the completion of an emergency inspection task can refer to the completion of the emergency task, the safe return of the UAV to its nest, and the marking of the task status as "completed" or "terminated". The determination of task completion can be based on various methods, such as confirmation of UAV return, nest detection of UAV repositioning, reporting of task execution results, or manual confirmation by the dispatcher. In some embodiments, the system supports both automatic detection (e.g., nest reporting that the UAV has entered the nest) and manual confirmation (dispatcher clicking the "task completed" button), allowing for flexible selection based on the urgency of the emergency scenario and management requirements.

[0197] Releasing an emergency lockout refers to removing the "preemptive" lock mark on a target nest, freeing it from exclusive use by the current emergency task. After the release operation is executed, the nest can be normally requested and occupied by other tasks (including regular tasks and subsequent emergency tasks). The release operation can be triggered automatically by the system upon detecting the completion of a task, or manually by the scheduler upon confirming the completion of a task. Automatic release can shorten resource idle time and improve nest utilization; manual release, on the other hand, allows for on-site inspection or equipment maintenance after the task is completed before releasing resources.

[0198] Updating the target nest's status to green light means restoring the nest's status from "emergency locked" to "green light" (idle and available) after releasing the emergency lock. The definition of green light status is consistent with the above embodiments: the nest is idle and available, with no tasks currently executing, no planned tasks pending execution (or, although planned, have been reallocated through the rescheduling process described above), and the device self-check is normal. After being updated to green light status, the nest can re-participate in the scheduling and re-arranging of subsequent tasks. In some embodiments, the system may trigger a nest self-check before updating the status to ensure the device status is normal before marking it as green light, avoiding prematurely releasing potentially problematic devices back to the resource pool.

[0199] Emergency dispatch records refer to structured archives of the entire process of an emergency task dispatch, used for post-event auditing, tracing, and analysis. Emergency dispatch records must include at least lockout records and original task rollback records.

[0200] The lock record refers to the operation log generated during the lock operation in the above embodiments, which records the occupation information of the target nest by the emergency task. The lock record may include: emergency task identifier (e.g., EM-001), target nest identifier (e.g., nest B), lock time (e.g., 2025-01-15 14:30:22), lock reason (e.g., "emergency reconnaissance"), initiator information (e.g., dispatcher ID or system module identifier), etc. The lock record is the core data for tracing the resource allocation decision and execution process.

[0201] The original task rollback record can refer to the structured data generated in the above embodiments that records the information of the original task that was preempted, including the task identifier to be executed, the original allocation nest identifier, the reason for preemption, and the time of preemption. This record is associated with the locking record and together describes the two aspects of "resources being occupied" and "the original task being affected" in an emergency dispatch.

[0202] In some embodiments, emergency dispatch records may also include extended information: the creation time and method of the emergency task (e.g., alarm linkage triggering), target location coordinates, candidate nest set and comprehensive ranking results, reordering records (new allocation schemes for the original tasks or records marked as awaiting manual confirmation), notification sending records (recipient, sending time, sending channel), task completion time, etc. This extended information can be used for subsequent dispatch effect evaluation, system performance optimization, and emergency response review.

[0203] For example, emergency mission EM-001 is completed, and the UAV returns to its home base. The system automatically detects mission completion and performs a release operation: updating the status of nest B from "emergency lock" to "green light". Simultaneously, the system generates a complete record of this emergency dispatch, including the lock record (mission EM-001, nest B, lock time 14:30:22) and the original mission rollback record (mission T-10086, originally assigned nest B, reason for preemption "preempted by EM-001"), all stored in the dispatch log database for later query and analysis.

[0204] Optionally, the system can also generate an emergency response report, which summarizes the key information of this emergency dispatch in the form of a structured document, including task creation time, resource search results, final locked resources, preempted objects, reordering results, notification records, and execution completion status, supporting post-event review and management assessment.

[0205] After adopting this method, the target nest can be released in a timely manner and restored to a reschedulable state after the emergency mission ends, reducing resource idleness caused by long-term nest occupation; at the same time, the emergency scheduling record retains the complete locking record and the original mission rollback record, which can improve the transparency and traceability of the scheduling process, and facilitate subsequent analysis of mission conflicts, resource transfer and rescheduling results, thereby improving the stability and management efficiency of nest resource scheduling.

[0206] Based on the above embodiments, the drone nest resource scheduling method for emergency inspection tasks provided in this application can be applied to emergency command scenarios for power grid drone inspections, specifically including emergency repairs of equipment failures, natural disaster reconnaissance (such as wildfires and floods), and critical power supply protection. Drone nests deployed in the power grid (supporting automatic dwelling, charging, takeoff and landing, and data transmission) serve as core resources and need to dynamically respond to high-priority emergency tasks in a multi-disciplinary shared context. Nest status is categorized as green (idle), yellow (planned occupation), red (execution occupation), and gray (fault / offline). Emergency tasks must lock available resources within millisecond-level response time, while ensuring that preempted tasks are automatically rolled back and reordered. This addresses the problems of existing systems lacking quantitative assessment of resource releaseability, having a single resource sorting dimension, and non-atomic locking operations, improving scheduling accuracy and emergency task execution efficiency, and preventing scheduling chain interruptions.

[0207] Figure 2 A flowchart illustrating the nest resource scheduling method for emergency inspection tasks provided in this application. Figure 2 ,like Figure 2 As shown, the method may include:

[0208] S201, responds to the command to create an emergency inspection task and assigns the emergency inspection task an emergency-level priority.

[0209] S202. Perform spatial retrieval centered on the mission target location to obtain a candidate set containing at least one candidate hive.

[0210] S203. Obtain the real-time status information of each candidate nest in the candidate set, and classify the candidate nests by status, including at least the yellow light status, i.e., the planned occupancy status.

[0211] S204. For candidate nests in the yellow light state, perform a releaseability assessment based on the attributes of the task to be executed, and generate a releaseability score.

[0212] S205. Based on the distance between the candidate nests and the mission target location, real-time status information, releaseability score, and expected response time, the nests in the candidate set are comprehensively scored and ranked.

[0213] S206. Determine the target nest based on the sorting results and perform a one-click locking operation.

[0214] S207. If the target nest is in a planned occupied state before the locking is executed, the system automatically generates the original task rollback record, automatically updates the status of the preempted task to be rescheduled, and writes it into the rescheduling pool.

[0215] S208. Trigger the rescheduling engine to automatically schedule tasks in the rescheduling pool and send status change notifications.

[0216] S209. After the emergency task is completed, the system automatically or manually releases the emergency lock, restores the resource to the available state, and updates the entire task process record.

[0217] The nest resource scheduling method for emergency inspection tasks provided in this application embodiment involves the following steps: After an emergency task is quickly documented, the system searches for candidate nests centered on the target location and performs a quantitative assessment of the releaseability of nests in the planned occupation (yellow light) state. Only resources with a quantitative score reaching a threshold are considered "actually preemptible." Subsequently, the optimal target nest is selected from five dimensions—distance, status, health, releaseability, and response time—using a multi-factor comprehensive ranking model. Then, resource occupation and freezing of the original task are completed through an atomic one-click locking operation. Finally, the preempted original task is automatically written into the reordering pool, triggering the reordering engine for automatic continuation processing, and the scheduling loop is completed through an automatic notification mechanism.

[0218] Figure 3 A schematic diagram illustrating the specific process of the nest resource scheduling method for emergency inspection tasks provided in this application is shown below. Figure 3 As shown, in this embodiment... Figure 1 , Figure 2 Based on the embodiments, a detailed description of the nest resource scheduling method for emergency inspection tasks is provided. This method may include:

[0219] (1) Emergency task triggering and rapid filing.

[0220] In this step, an emergency task creation instruction is received. This instruction can originate from the "One-Click Create" button on the main interface, input via the dispatch terminal, triggering through a warning system linkage, or reporting via a mobile device. The system automatically generates an emergency task identifier, recording information such as task type, target site or area, task creation time, timeliness level, and task initiating unit, and automatically assigns the task the highest priority or a preset emergency level priority. Preferably, the emergency task creation interface is a simplified interface, requiring only the minimum necessary fields to reduce the number of steps required by the dispatcher.

[0221] It should be noted that emergency task creation instructions can originate from various triggering methods, including but not limited to the "One-Click Create" button on the main interface, input via the dispatch terminal, linkage triggering with the early warning / alarm system, or reporting via mobile devices. These triggering methods can be used individually or in combination, and all can complete the access and documentation of emergency tasks; there is no limitation to any single specific triggering method.

[0222] (2) Target location analysis and spatial search.

[0223] The process involves resolving the target location coordinates based on information entered during emergency missions, including target sites, areas, power line towers, fault coordinates, or disaster areas. Then, using the target location as the center, and considering preset search radius, flight coverage radius, administrative boundaries, flight route constraints, and service area constraints, surrounding candidate aircraft nest resources are retrieved to form a candidate aircraft nest set. Preferably, the search radius is a configurable parameter and can be dynamically adjusted according to the mission type.

[0224] It should be noted that the search range is jointly determined by the preset search radius, flight coverage radius, administrative boundaries, route constraints, and service area constraints. These constraints can be used individually, in combination, or all at once. The search radius is configurable and can be dynamically adjusted based on the task type (e.g., wildfire reconnaissance, equipment failure, power supply maintenance), rather than being a fixed value. All these alternatives can achieve effective retrieval of candidate aircraft nests.

[0225] (3) Candidate resource status identification and pre-filtering.

[0226] In this step, the current status, planned occupancy status, device status, drone status, and corresponding task information of each candidate nest are read, and the candidate nests are classified according to their status. Preferably, the nest status includes at least: green light, yellow light, red light, and gray light. Green light indicates idle and available status, yellow light indicates planned occupancy status, red light indicates active occupancy status, and gray light indicates fault, offline, or disabled status. The system prioritizes retaining nests in the green light status; further checks the releaseability of nests in the yellow light status; and removes or downgrades nests in the red light and gray light status.

[0227] It should be noted that, in addition to the preferred four-color light classification of green / yellow / red / gray used in this method, the following alternative classification granularities can also be used for nest status classification: First, a coarser granularity can be used, distinguishing only the binary status of "available / unavailable"; Second, a finer granularity can be used, further subdividing the yellow light into "short-term occupied / long-term occupied" and the gray light into three independent statuses: "faulty / offline / disabled"; Third, status identification can be automatically detected by the system or manually labeled by the scheduler as a supplement.

[0228] (4) Releasability assessment.

[0229] For the yellow light state machine nest, the system further calculates the releaseability score (denoted as R) of the originally planned task. score Releaseability is not simply a matter of "whether there is a plan," but rather a quantitative assessment of whether the plan can be rolled back and rearranged after being preempted. The calculation model for the releaseability score is as follows:

[0230] R score =(W pri ×S pri )+(W time ×S time )+(W alt ×S alt )+W penalty ;

[0231] The system uses a weighted rule model to calculate R. score The value ranges from [0, 100], and a higher score indicates that it is more suitable to be taken over by emergency tasks. pri This is a priority coefficient, determined based on the original task priority level; S time The time window tolerance coefficient is determined based on the time interval between the original estimated start time of the task and the current time, as well as the allowable delay duration; S alt The substitution resource coefficient is determined based on the existence of available alternative nests; W penaltyAs a penalty item, the number of subsequent tasks that will be cascaded and rearranged due to seizing the resource is determined; if seizing the resource will cause more than a preset threshold of subsequent tasks to be cascaded and rearranged, the corresponding score will be deducted.

[0232] It should be noted that the releaseability assessment can also be implemented by other equivalent methods: First, it can be replaced by a rule-based decision tree, judging layer by layer according to "original task priority → time window → alternative resource", and outputting a binary conclusion of "releaseable / non-releaseable"; Second, it can be replaced by a machine learning classification model, training a classifier based on historical successful / failed preemption cases, and outputting the releaseability probability as input to the original task attributes; Third, the weight W of the weighted term... pri W time and W alt It is not fixed and can be dynamically adjusted according to the power grid area (e.g., mountainous / plain), season, and professional category; fourth, the priority coefficient S pri The value (100 / 50 / 0) can be adjusted to other discrete or continuous values ​​according to actual business needs.

[0233] (5) Comprehensive ranking.

[0234] The system performs a comprehensive scoring and ranking of candidate hives. Preferably, the comprehensive scoring model includes at least the following factors: distance factor, state factor, health factor, releasability factor, and response timeliness factor. The system uses a multi-factor weighted scoring model to rank candidate hives to quantify their overall suitability for the current emergency mission. In one example, the calculation model for the comprehensive scoring and ranking is as follows:

[0235] Score total =α×(D max / D i )+β×State i +γ×Health i +δ×(R score_i / 100)+ε×(1 / T response_i );

[0236] It should be noted that the comprehensive ranking model in this step can be implemented using the following alternatives: First, the number of factors can be increased or decreased, such as adding "weather adaptability factor" and "airspace permit factor", or only retaining the three factors of distance, status, and releasability; Second, the weight coefficients α, β, γ, δ, and ε can be configured, and the weight combination can be dynamically switched for different power grid regions (such as emphasizing distance in mountainous areas and emphasizing timeliness in plains); Third, the ranking method can be replaced by a descending cumulative scoring method or a multi-objective optimization algorithm (such as Pareto front screening) or a multi-objective decision-making method such as the analytic hierarchy process (AHP).

[0237] The system is based on the score totalThe candidate nests are sorted in descending order, and the top N nests are recommended.

[0238] Furthermore, in some examples, Figure 4 The schematic diagram of the integrated sequencing of candidate nests provided in this application is as follows: Figure 4 As shown, the comprehensive ranking of candidate nests can be performed in different functional areas, such as the candidate input area, factor evaluation area, comprehensive scoring area, and ranking output area. In the candidate input area, the candidate nest set includes nests A, B, C, and D.

[0239] Furthermore, the factor evaluation area includes multi-dimensional evaluation factors: distance factor (spatial distance from candidate nest to target location, the closer the distance, the higher the score), status factor (green light takes precedence over yellow light, red / gray light are not included in the ranking, green light scores higher, yellow light needs to be further evaluated in conjunction with releaseability), health factor (operating health status of nest, drone, battery, communication link, etc., the better the health status, the higher the score), releaseability factor (for yellow light nests, assess the degree of reversibility after the original task is preempted, the higher the releaseability, the higher the score, used to assess whether yellow light resources can be preempted by emergency tasks), and response time factor (estimated time from the current moment to the moment when resources can be deployed, the faster the response, the higher the score).

[0240] In the comprehensive scoring area, the comprehensive scoring model standardizes each evaluation factor and generates a comprehensive score for the candidate nest by weighting them according to preset weights. Standardization process explanation: Due to the different dimensions of each factor, a unified scoring range must be applied before weighted aggregation. Score = a × Distance Score + b × Status Score + c × Health Score + d × Releaseability Score + e × Response Timeliness Score, where a, b, c, d, and e are configurable weight parameters. Weight configuration explanation: The weights of each factor can be configured and adjusted according to the task type, emergency level, and operational strategy.

[0241] In the sorting output area, the candidate nests are sorted as follows: 1. Nest B; 2. Nest A; 3. Nest D; 4. Nest C. They are sorted from highest to lowest based on their overall score. Recommended target nests: The top-ranked candidate nest or the top N candidate nests are output for the target nest scheduler to choose from. The recommendation criteria and score composition are also displayed. The recommendation results can include explanations of the scoring criteria and factors. Example score breakdown: Nest B: High distance score, green light, high health, fast response, highest total score; Nest A: Slightly closer distance, but yellow light and average releaseability, second highest total score; Nest C: Low health, reduced weight; Nest D: Slow response time, reduced weight.

[0242] (6) One-click locking and forced preemption.

[0243] In this step, after the dispatcher selects the target drone nest, the system performs a one-click locking operation. One-click locking includes at least the following actions: updating the target drone nest status to "emergency lock"; synchronously marking the corresponding drone resource as "emergency occupied"; generating a locking record, writing the task ID, resource ID, locking time, locking reason, and initiator information; preventing other ordinary tasks from continuing to apply for the resource; and freezing, canceling pre-occupancy, or migrating the status of the original task that was preempted. In a preferred embodiment, if the target drone nest was originally in a yellow light state, the system performs forced preemption; if the target drone nest was in a green light state, the system directly completes the occupancy lock without a preemption process.

[0244] (7) Original task rollback and generation of the waiting rearrangement pool.

[0245] When a target nest was previously bound to a scheduled task, the system automatically generates a rollback record for the original task. The rollback record includes at least: the original task identifier, the original assigned nest identifier, the original scheduled start and end times, the reason for preemption, the time of preemption, and the new status identifier of the original task. Preferably, the system changes the original task status from "pending execution" to "pending rescheduling" and automatically writes it to the rescheduling pool. The rescheduling pool is used to uniformly manage tasks that need to be rescheduled due to emergency insertion, equipment failure, weather changes, etc.

[0246] (8) Automatic rearrangement and notification triggering.

[0247] After the original task enters the reordering pool, the system automatically triggers the reordering process. The reordering process typically includes: reading the original constraints of the task to be reordered; reading the currently available nest set and its time window; regenerating candidate solutions based on priority, professional constraints, time window constraints, and the availability of alternative resources; outputting new recommended nests, recommended time periods, or recommended dates; and marking tasks that cannot be automatically reordered as "awaiting manual confirmation." Simultaneously, the system automatically sends notifications to the original task's unit, scheduler, relevant approvers, or on-duty personnel.

[0248] Furthermore, it should be noted that in addition to "automatically writing to the rescheduling pool + triggering the automatic rescheduling engine," the handling process for preempted tasks can also be implemented using the following alternatives: First, it can be replaced by a manual approval mode. After the preempted task automatically generates a rollback record, it is first pushed to the scheduler for approval, and then manually confirmed before entering the rescheduling pool. Second, when automatic rescheduling fails, in addition to "marking it as pending manual confirmation," it can also be replaced by automatically postponing it to the next available time window or automatically transferring it to other professional teams. Third, the notification triggering method can be replaced by multiple channels such as SMS, email, social software, and telephone voice, rather than being limited to system message push.

[0249] (9) Release and tracing after the emergency mission ends.

[0250] Upon completion of an emergency task, the system automatically or with manual confirmation releases the emergency lock, restores the resource's availability, and updates the entire task log. Preferably, the system generates an emergency response report, recording the emergency task creation time, resource search results, final locked resources, target resource, reordering results, notification records, and execution completion status to support post-event review.

[0251] Based on the above embodiments, Figure 5 Schematic diagram of the nest resource scheduling system for emergency inspection tasks provided in this application Figure 1 ,like Figure 5 As shown, the nest resource scheduling system for this emergency inspection task may include:

[0252] The emergency task creation module is used to receive emergency task creation instructions, obtain the location of the task target, and assign emergency-level priority. This module supports multiple triggering methods, including one-click creation by dispatchers, linkage triggering by alarm / monitoring systems, and temporary reporting from mobile devices / on-site.

[0253] The spatial search module, connected to the emergency mission creation module, is used to search for surrounding candidate nest resources based on the mission target location, according to preset search radius, flight coverage radius, administrative boundary, route constraints, and service range constraints.

[0254] The status recognition module, connected to the space search module, is used to identify the red, yellow, green, and gray light status of candidate nests; the green light status indicates that the nest is idle and available, the yellow light status indicates that the nest is planned to be occupied, the red light status indicates that the nest is being occupied, and the gray light status indicates that the nest is faulty, offline, or disabled.

[0255] The releaseability assessment module, connected to the state recognition module, is used to assess whether the original task of the yellow light state machine nest is releaseable.

[0256] The comprehensive sorting module, connected to the releaseability assessment module, is used to sort candidate nests based on distance, status, health, releaseability, and response time.

[0257] The one-click locking module, connected to the integrated sorting module, is used to perform forced preemption and locking operations on the target nest, update the nest and drone resource status, generate a locking record, and block other ordinary task applications.

[0258] The task rollback module, connected to the one-click lock module, is used to generate the original task rollback record when the target nest was originally in a planned occupied state, update the status of the preempted task to pending rescheduling, and write it into the pending rescheduling pool.

[0259] The automatic rescheduling module, connected to the task rollback module, is used to read the tasks and their constraints in the rescheduling pool and regenerate the scheduling scheme based on the currently available resources.

[0260] The notification module, connected to the automatic reordering module, is used to push resource change and reordering information to affected units.

[0261] Optionally, the system may also include a traceability and recording module for recording the entire emergency dispatch process logs and status changes. Some functional modules are connected to a data and rules support layer, which includes a machine nest ledger database, a real-time status database, a task plan database, an equipment health status database, and a rule parameter database.

[0262] Figure 6 The nest state transition diagram provided in this application is as follows: Figure 6 The diagram illustrates the state transition logic of a hive under different scenarios. In a normal scheduling scenario, the hive initially enters a green light state. When the system assigns a planned task to the hive, its state transitions to a yellow light state. If the task is canceled, released, or the plan fails, the hive state can revert to the green light state; if the task begins execution, the hive state further transitions to a red light state. After the task is completed or the resources are released, the hive state returns to the green light state. If the hive experiences a fault or communication interruption, it enters a gray light state, returning to the green light state after the fault is resolved.

[0263] In emergency preemption scenarios, when an emergency task is triggered, the system evaluates candidate nests. If a nest is in a green light state, it is directly moved to the emergency locked state after confirmation by the scheduler. If a nest is in a yellow light state, after passing a releaseability assessment, a forced preemption operation is performed: the original task is rolled back to the rescheduling pool, and the nest state is moved to the emergency locked state. If a nest is in a red light or gray light state, it does not participate in emergency preemption because it lacks releaseability. Furthermore, if a nest in a red light state experiences an in-process failure, abnormal interruption, or is forcibly deactivated, it will also directly enter the emergency locked state. After the emergency task is completed, the nest is released from the emergency locked state, returns to the green light state, and re-enters the available resource pool.

[0264] Figure 7 The original task rollback and rearrangement logic diagram provided for this application is as follows: Figure 7 The diagram illustrates the post-processing flow of the original task after a preempted task. Regarding the rollback process, when the target nest is preempted by an emergency task, the original task first enters the rollback record generation stage. This record includes the original task ID, the original assigned nest ID, the original planned time window, the reason for preemption, and the time of the preemption. Subsequently, the task status is updated, changing the original task status from "pending execution" to "pending rescheduling." Then, the original task is written to the rescheduling pool and added to the unified management queue.

[0265] In terms of the rescheduling process, the rescheduling engine reads tasks from the rescheduling pool. First, it reads the original task constraints, including task priority, professional category, and original planned time window. Then, it reads the currently available server nests and time windows to obtain the latest resource status. Next, it regenerates candidate solutions and outputs rescheduling suggestions. Based on the matching results, it enters a branch judgment: determining whether the automatic confirmation execution conditions are met (based on task priority, delay range, rule constraints, approval requirements, etc., to determine whether the system can directly take effect). If the conditions are met, automatic rescheduling is executed, outputting new server nests and time suggestions, and entering the automatic confirmation execution process, reallocating the task to the new server nest and time period. If the conditions are not met, it is marked as awaiting manual confirmation, with an explanation of why automatic rescheduling cannot be performed (such as weather restrictions, airspace restrictions, insufficient resources, etc.), and enters the manual fallback processing process. The manual processing results are divided into three categories: confirmed rescheduling, delayed, and canceled. Optionally, regardless of whether automatic rescheduling is successful or manual confirmation is initiated, the system sends a status change notification, pushing the processing result to the original task's unit, scheduler, and relevant personnel. In addition, regardless of whether the automatic reordering is successful or the manual processing is completed, the system performs closed-loop record archiving. The record includes the original plan information, the reason for the preemption, the reordering process, the notification recipients, and the final disposal result, thus completing the entire processing flow.

[0266] In addition, to better illustrate the implementation of the nest resource scheduling method for emergency inspection tasks, three typical application scenarios are provided below.

[0267] Scenario 1: The planned nest is taken over by an emergency mission.

[0268] At 14:05 one day, the system received an emergency task for "wildfire risk reconnaissance," with the target area being the coordinates of wildfire point A. The system automatically marked this task as an emergency task and assigned it the highest priority. Centered on wildfire point A, the system searched for candidate drone nests within a 10-kilometer radius, obtaining three candidate resources: M1, M2, and M3. M1 was in a green light status, 9.2 kilometers away; M2 was in a yellow light status, 5.4 kilometers away, and its original task was a routine patrol later that day, expected to begin in one hour, providing ample time, and alternative drone nests existed; M3 was in a red light status and was currently performing its task.

[0269] The system filters and scores the three nests: M3 is removed because it is in a red-light state; M1 and M2 continue to participate in the ranking. A releaseability assessment is performed on M2: the original task was of general priority, S... pri =100; the time interval is relatively long and allows for delays, S time =85; There is an alternative nest, S alt =100; No cascading penalty. Let the weight W be... pri =0.3、W time=0.4, W alt =0.3, then R score =0.3×100+0.4×85+0.3×100=94, which is higher than the releaseability threshold, so it is determined to be releaseable.

[0270] In the comprehensive ranking phase: Although M2 is not idle, its comprehensive score is higher than M1 due to its closer proximity (higher distance factor score), normal equipment health status, and high releaseability score. Therefore, the system lists M2 as the first recommended candidate. After the dispatcher confirms the selection of M2, the system performs a one-click lock: changing M2's status to "emergency lock," updating its associated drone status to "emergency occupancy," and changing the original daily patrol task status from "pending execution" to "pending rescheduling," while generating a rollback record. The system then calls the automatic rescheduling module, finds that the drone nest M4 is available later that day, and automatically generates a rescheduling suggestion of "reassign to M4, reschedule to later that day," pushing a notification message to the original task's unit and the on-duty dispatcher. In this scenario, the emergency task is executed quickly, the original task is not lost, but enters the subsequent rescheduling chain, achieving a complete closed loop.

[0271] Scenario 2: Prioritize selecting idle nests.

[0272] After an emergency response to a equipment failure occurred, the system detected two equipment nests near the target site: N1 was in a green light state, 6 kilometers away; N2 was in a yellow light state, 4 kilometers away. However, the original mission was a special patrol and maintenance mission, and extensions were not allowed. During the releaseability calculation phase, the system determined N2 to be non-releaseable (S... pri Since N2's weight is 0, it is either downweighted or removed. Ultimately, the system recommends N1 and completes the locking process. This scenario illustrates that this method does not mechanically use closest distance as the sole criterion, but rather comprehensively considers actual availability.

[0273] Scenario 3: Manual backup when automatic rearrangement is not possible.

[0274] After a yellow-light aircraft nest is preempted, the original task becomes unavailable due to weather restrictions, airspace restrictions, and other resources for the day. During the rescheduling phase, the system fails to find an alternative solution that satisfies all constraints. At this point, the system marks the original task status as "awaiting manual confirmation" and sends a notification to the original unit, along with an explanation of why automatic rescheduling is not possible. This scenario demonstrates that this method not only supports automatic rescheduling but also automatically identifies rescheduling failures and initiates a manual fallback process, ensuring system robustness.

[0275] Based on the above embodiments, it can be seen that the nest resource scheduling method for emergency inspection tasks provided in this application has the following beneficial effects:

[0276] (1) Achieve millisecond-level locking and automated handling of emergency resources. This method shortens the traditional manual step-by-step confirmation process (which usually takes several minutes to tens of minutes) to a millisecond-level response completed automatically by the system through a chain process of "rapid creation - spatial search - comprehensive sorting - one-click locking". This method transforms the preempted task handling process, which originally relied on manual post-event coordination, into automatic system takeover through releaseability assessment and a waiting rearrangement pool mechanism, avoiding interruption of the scheduling process and improving the computer system's automated handling capability and resource allocation efficiency in complex emergency scenarios.

[0277] (2) Improve the feasibility of emergency dispatch through a releaseability assessment mechanism. This method introduces a releaseability assessment mechanism for emergency preemption scenarios. For nests in the planned occupancy state, quantitative scoring is performed based on the original task priority, time window tolerance, etc. Only when the score reaches a preset threshold is the resource allowed to enter the emergency candidate set. This can further identify "actually preemptible" resources from "seemingly available" candidate resources, avoiding scheduling failure due to the original task not being releaseable after selection, and effectively improving the implementation rate and feasibility of emergency solutions.

[0278] (3) Avoid the loss of control of preempted tasks through the original task rollback and the waiting-to-rescheduling pool mechanism. After the emergency task locks the resources, this method automatically identifies the preempted original planned tasks, generates a complete rollback record, and changes the status of the original task from "pending execution" to "pending rescheduling", and writes it into the waiting-to-rescheduling pool. This ensures that the preempted tasks will not be forgotten or lost due to emergency insertion, and realizes the closed-loop connection between emergency execution and original plan recovery.

[0279] (4) Achieve automatic rescheduling in conjunction with subsequent scheduling engines to reduce manual intervention. The rescheduling pool in this method does not exist in isolation, but is linked with the subsequent automatic rescheduling engine. When rescheduling is successful, the task automatically enters the new execution plan; when rescheduling fails, the system automatically marks it as "awaiting manual confirmation" with an explanation of the reason, thus automating the handling of the original task continuation, reducing the workload of schedulers, and ensuring that the machine nest resources remain controllable and orderly in emergency scenarios. This guarantees the robustness of the system under complex constraints and improves the overall resource utilization efficiency.

[0280] Figure 8 Schematic diagram of the nest resource scheduling system for emergency inspection tasks provided in this application Figure 2 ,like Figure 8 As shown, the emergency inspection task nest resource scheduling system 80 provided in this embodiment includes:

[0281] The first acquisition module 801 is used to acquire the target location of the emergency inspection task;

[0282] The retrieval module 802 is used to retrieve nest resources based on the target location and obtain a set of candidate nests;

[0283] The second acquisition module 803 is used to acquire the status information of each candidate nest in the candidate nest set. The status information is used to indicate whether the nest is in a planned occupancy state.

[0284] The third acquisition module 804 is used to acquire the task attributes of the task to be executed corresponding to each candidate nest in the candidate nest set if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state.

[0285] Evaluation module 805 is used to evaluate the releasability of candidate hives based on task attributes and obtain a releasability score;

[0286] The determination module 806 is used to determine the target nest from the candidate nest set based on the status information of each candidate nest and all releasability scores.

[0287] In one possible implementation, the evaluation module 805 can also be used to: determine the priority coefficient, time window tolerance coefficient, and alternative resource coefficient based on the task attributes; perform a weighted summation of the priority coefficient, time window tolerance coefficient, and alternative resource coefficient to obtain a releaseability score; wherein, the priority coefficient is used to indicate the priority feasibility of the task to be executed being preempted, the time window tolerance coefficient is used to indicate the start time flexibility of the task to be executed, and the alternative resource coefficient is used to indicate whether there is an alternative nest to execute the task to be executed.

[0288] In one possible implementation, the evaluation module 805 can also be used to: obtain the number of cascaded reordering tasks that will result from preempting the candidate nest; determine a penalty term based on the number of cascaded reordering tasks, wherein the penalty term is positively correlated with the number of cascaded reordering tasks; and update the releaseability score based on the penalty term to obtain the updated releaseability score.

[0289] In one possible implementation, the determining module 806 can also be used to: determine the distance information, real-time status information, health information, and estimated response time of each candidate nest based on the status information of each candidate nest; for each candidate nest, if the candidate nest is in a planned occupancy state, obtain the corresponding releaseability score; if the candidate nest is not in a planned occupancy state, set the corresponding releaseability score to a preset value; perform a weighted summation of the distance information, real-time status information, health information, estimated response time, and releaseability score of the candidate nest to obtain a comprehensive score result; sort all the comprehensive score results and determine the candidate nest with the highest ranking as the target nest.

[0290] In one possible implementation, the first acquisition module 801 can also be used to: acquire a task creation instruction, which is triggered by at least one of the following methods: one-click creation button, dispatch terminal input, alarm system linkage triggering, and mobile terminal reporting; based on the task creation instruction, generate an emergency inspection task and determine the emergency level priority of the emergency inspection task; wherein, the emergency inspection task includes a task type and a target area.

[0291] In one possible implementation, the second acquisition module 803 can also be used to: classify the status of each candidate nest in the candidate nest set according to the status information, and obtain the nest status of each candidate nest. The nest status includes green light status, yellow light status, red light status or gray light status; wherein, the green light status is used to indicate that the nest is in an idle and available state, the yellow light status is used to indicate that the nest is in a planned occupation state, the red light status is used to indicate that the nest is in an execution occupation state, and the gray light status is used to indicate that the nest is in a fault offline state.

[0292] In one possible implementation, the determining module 806 can also be used to: update the state of the target nest to an emergency locked state in response to the locking operation on the target nest; if the target nest was in a planned occupied state before locking, automatically generate an original task rollback record, which includes the pending task identifier corresponding to the target nest, the original allocated nest identifier, the reason for preemption, and the time of preemption; update the state of the pending task corresponding to the original task rollback record to a pending rescheduling state, and write it to the pending rescheduling pool.

[0293] In one possible implementation, the determination module 806 can also be used to: trigger the rescheduling engine to automatically schedule tasks in the rescheduling pool. The automatic scheduling process includes: reading the original constraints of the tasks to be executed, reading the currently available nest set and the corresponding time window, and generating a new execution plan; when the automatic scheduling is successful, generating a new execution plan and sending a notification; when the automatic scheduling fails, marking the tasks to be executed as pending manual confirmation and sending a notification.

[0294] In one possible implementation, the determining module 806 can also be used to: release the emergency lock state on the target nest in response to the completion of the emergency inspection task, and update the state of the target nest to a green light state, which indicates that the nest is in an idle and available state; generate an emergency dispatch record, which includes the lock record of the target nest and the original task rollback record.

[0295] The emergency inspection task nest resource scheduling system provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0296] Figure 9A schematic diagram of the structure of the electronic device provided in this application. Figure 9 As shown, the electronic device 90 provided in this embodiment includes at least one processor 901 and a memory 902. Optionally, the device 90 further includes a communication component 903. The processor 901, memory 902, and communication component 903 are connected via a bus 904.

[0297] In a specific implementation, at least one processor 901 executes computer execution instructions stored in memory 902, causing at least one processor 901 to perform the above-described method.

[0298] The specific implementation process of processor 901 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0299] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0300] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0301] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0302] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0303] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0304] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0305] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0306] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0307] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0308] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0309] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0310] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0311] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for scheduling nest resources for emergency inspection tasks, characterized in that, include: Obtain the target location for emergency inspection tasks; Based on the target location, retrieve nest resources to obtain a set of candidate nests; Obtain the status information of each candidate nest in the candidate nest set, the status information being used to indicate whether the nest is in a planned occupancy state; For each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, then the task attribute of the task to be executed corresponding to the candidate nest is obtained; Based on the task attributes, the releasability of the candidate hives is evaluated to obtain a releasability score; Based on the status information of each candidate nest and all releasability scores, the target nest is determined from the set of candidate nests.

2. The method according to claim 1, characterized in that, The step of evaluating the releasability of the candidate hives based on the task attributes to obtain a releasability score includes: Based on the task attributes, determine the priority coefficient, time window tolerance coefficient, and alternative resource coefficient; The releaseability score is obtained by weighted summation of the priority coefficient, the time window tolerance coefficient, and the alternative resource coefficient. The priority coefficient is used to indicate the priority feasibility of the task to be preempted, the time window tolerance coefficient is used to indicate the start time flexibility of the task to be executed, and the alternative resource coefficient is used to indicate whether there is an alternative nest to execute the task to be executed.

3. The method according to claim 2, characterized in that, The method further includes: Obtain the number of cascaded rearrangement tasks that will result from preempting the candidate nest; A penalty term is determined based on the number of cascaded rearrangement tasks, wherein the penalty term is positively correlated with the number of cascaded rearrangement tasks; Based on the penalty term, the releasability score is updated to obtain the updated releasability score.

4. The method according to claim 1, characterized in that, The process of determining the target nest from the candidate nest set based on the state information of each candidate nest and all releasability scores includes: Based on the status information of each candidate nest, the distance information, real-time status information, health information and estimated response time of each candidate nest from the target location are determined; For each candidate nest, if the candidate nest is in a planned occupied state, the corresponding releaseability score is obtained; if the candidate nest is not in a planned occupied state, the corresponding releaseability score is set to a preset value. The distance information, real-time status information, health information, estimated response time, and releaseability score of the candidate nests are weighted and summed to obtain a comprehensive score result. All comprehensive scores are sorted, and the candidate nest with the highest ranking is determined as the target nest.

5. The method according to claim 1, characterized in that, Before obtaining the target location of the emergency inspection task, the method further includes: Obtain a task creation instruction, which is triggered by at least one of the following methods: one-click creation button, scheduling terminal input, alarm system linkage triggering, and mobile terminal reporting. Based on the task creation instruction, the emergency inspection task is generated, and the emergency level priority of the emergency inspection task is determined; wherein, the emergency inspection task includes task type and target area.

6. The method according to claim 1, characterized in that, After obtaining the status information of each candidate nest in the candidate nest set, the method further includes: Based on the status information, each candidate nest in the candidate nest set is classified into different statuses to obtain the nest status of each candidate nest. The nest status includes green light status, yellow light status, red light status, or gray light status. The green light indicates that the server nest is in an idle and available state; the yellow light indicates that the server nest is in a planned occupancy state; the red light indicates that the server nest is in an active occupancy state; and the gray light indicates that the server nest is in a fault offline state. Accordingly, for each candidate nest in the candidate nest set, if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state, then the task attributes of the task to be executed corresponding to the candidate nest are obtained, including: For each candidate nest in the candidate nest set, if the nest status of the candidate nest indicates that the candidate nest is in a planned occupancy state, then the task attribute of the task to be executed corresponding to the candidate nest is obtained.

7. The method according to any one of claims 1-6, characterized in that, After determining the target nest from the candidate nest set based on the state information of each candidate nest and all releasability scores, the method further includes: In response to the locking operation on the target nest, the status of the target nest is updated to an emergency locking status; If the target nest was in the planned occupied state before being locked, an original task rollback record is automatically generated. The original task rollback record includes the pending task identifier corresponding to the target nest, the original allocated nest identifier, the reason for preemption, and the time of preemption. The status of the pending task corresponding to the original task rollback record is updated to the pending rescheduling status and written to the pending rescheduling pool.

8. The method according to claim 7, characterized in that, After updating the status of the pending task corresponding to the original task rollback record to a pending rescheduling status and writing it into the rescheduling pool, the method further includes: The rescheduling engine is triggered to automatically schedule tasks in the rescheduling pool. The automatic scheduling process includes: reading the original constraints of the tasks to be executed, reading the currently available nest set and the corresponding time window, and generating a new execution plan. When automatic scheduling is successful, a new execution plan is generated and a notification is sent. When automatic scheduling fails, the task to be executed is marked as pending manual confirmation and a notification is sent.

9. The method according to claim 7, characterized in that, The method further includes: In response to the completion of the emergency inspection task, the emergency lock status on the target nest is released, and the status of the target nest is updated to green light status, which indicates that the nest is in an idle and available state; An emergency dispatch record is generated, which includes the target nest locking record and the original mission rollback record.

10. A nest resource scheduling system for emergency inspection tasks, characterized in that, include: The first acquisition module is used to acquire the target location of the emergency inspection task. The retrieval module is used to retrieve nest resources based on the target location and obtain a set of candidate nests; The second acquisition module is used to acquire the status information of each candidate nest in the candidate nest set, and the status information is used to indicate whether the nest is in a planned occupancy state. The third acquisition module is used to acquire the task attribute of the task to be executed corresponding to each candidate nest in the candidate nest set if the status information of the candidate nest indicates that the candidate nest is in a planned occupancy state. An evaluation module is used to evaluate the releasability of the candidate hives based on the task attributes and obtain a releasability score. The determination module is used to determine the target nest from the set of candidate nests based on the status information of each candidate nest and all releasability scores.

Images