Multi-unit coordinated action resource scheduling method and device

Abstract

The application discloses a multi-unit cooperative action resource scheduling method and device, relates to the technical field of resource scheduling, and comprises the following steps: receiving an emergency rescue request containing an incident location and an event level, determining an initial task area and required resource types by matching with a scheduling case library; evaluating the health state and task load of available rescue units based on a resource state database, and then acquiring dynamic attributes and spatial position information of the rescue units; decomposing a rescue task in combination with the initial task area and unit information, generating a plurality of rescue sub-tasks which are functionally parallel or serial; assigning appropriate rescue units to each sub-task through a task allocation decision model and forming a task sequence; and finally, distributing the encrypted task sequence to corresponding units in a safe manner to execute rescue. Through the above method, the method realizes quick response, intelligent decomposition and efficient cooperation of the rescue task, and improves the timeliness, accuracy and overall rescue success rate of resource scheduling.

Description

Technical Field

[0001] This application relates to the field of resource scheduling technology, and in particular to a method and apparatus for resource scheduling of multi-unit collaborative actions. Background Technology

[0002] Existing emergency rescue resource dispatching technologies generally suffer from low dispatching efficiency and poor coordination. Traditional dispatching models often rely on manual experience or simple rule matching, making it difficult to quickly respond to the dynamic needs of emergencies. This leads to unreasonable task allocation, a lack of effective coordination between rescue units (such as vehicles, personnel, and equipment), and situations where resources are idle or tasks are clustered together, making it difficult to form a cohesive force and thus seriously affecting the timeliness and success rate of the overall rescue operation.

[0003] Furthermore, due to the failure to fully consider the real-time health status, task load, and accurate geospatial relationships of rescue units, existing solutions cannot achieve refined task decomposition and dynamic optimization allocation. Each rescue unit often operates in an information silo, with poorly coordinated action steps, further exacerbating coordination difficulties and hindering the efficient use of valuable rescue resources, making them particularly inadequate in responding to large-scale or complex emergencies.

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

[0005] The main purpose of this application is to provide a method and apparatus for scheduling resources for multi-unit collaborative action, which aims to solve the technical problems of low efficiency and poor coordination in emergency resource scheduling in the prior art.

[0006] To achieve the above objectives, this application provides a multi-unit collaborative action resource scheduling method, the method comprising: Based on the received emergency rescue request containing the incident location and incident level, the incident location and incident level are matched with the scheduling case library to determine the initial task area and required resource type; Based on the resource status database, the health status and task load of each available rescue unit are determined, and the dynamic attribute information and spatial location information of each available rescue unit under the required resource type are determined based on the health status and task load. The rescue mission is decomposed based on the initial mission area, the dynamic attribute information, and the spatial location information to obtain multiple rescue sub-tasks; A task allocation decision is made for multiple rescue sub-tasks to obtain multiple rescue task sequences; The multiple rescue mission sequences are distributed to each of the available rescue units so that the available rescue units can perform emergency rescue missions.

[0007] In one embodiment, the step of decomposing the rescue task into multiple rescue sub-tasks based on the initial task area, the dynamic attribute information, and the spatial location information includes: The overall target timeframe and success threshold for the rescue mission are determined based on the event level. Based on the overall target timeliness, the success threshold, and the unit capability type and execution efficiency in the dynamic attribute information, the rescue mission is decomposed into sub-targets that are functionally parallel or sequential. Based on the spatial location information and the spatial topology relationship between the initial task area, an execution geographical area and arrival path are defined for each sub-target; Multiple rescue sub-tasks are generated based on the sub-target, the execution geographic area, and the arrival route.

[0008] In one embodiment, the step of decomposing the rescue mission into functionally parallel or sequential sub-goals based on the overall target timeliness, the success threshold, and the unit capability type and execution efficiency in the dynamic attribute information includes: Construct a task decomposition model with the overall target timeliness as a hard constraint and maximizing the overall success probability as the optimization objective, and determine the solution space; Based on the unit capability type and execution efficiency in the dynamic attribute information, the time consumption probability and success probability of rescue units with different capability types executing various sub-tasks are fitted. Using the success threshold as the termination condition, a heuristic exploration is performed in the solution space to generate multiple candidate decomposition schemes; The execution time and estimated success rate of each candidate decomposition scheme are determined, and the candidate decomposition scheme with the estimated success rate greater than the success threshold and the shortest execution time is selected as the target decomposition scheme. The rescue mission is decomposed into sub-goals that are functionally parallel or sequential, according to the target decomposition scheme.

[0009] In one embodiment, the step of defining the execution geographic region and arrival path for each sub-target based on the spatial location information and the spatial topology relationship of the initial task area includes: The initial task area is gridded based on a geographic information system to generate a weighted raster map, where the weights are determined by terrain, obstacles, and access difficulty. Determine the functional requirements for each sub-target, and identify the core operational area corresponding to the functional requirements in the grid map; Centered on the core operation area, and combined with the real-time distribution of available rescue units in the spatial location information, the execution geographical area of ​​each sub-target is dynamically divided. Based on the weight information of the grid map, an arrival path is generated according to the path search algorithm.

[0010] In one embodiment, the step of making task allocation decisions for multiple rescue sub-tasks to obtain multiple rescue task sequences includes: Each rescue subtask is encapsulated to obtain a task announcement; The available rescue units are screened based on their capability type and current health status to determine candidate available rescue units, and the mission announcement is broadcast to the candidate available rescue units. Receive bids returned by each of the candidate available rescue units, the bids including a comprehensive utility value; With the goal of minimizing the global task completion time and maximizing the total utility, and in conjunction with the comprehensive utility value, a target available rescue unit is determined based on an auction algorithm, and the rescue sub-tasks are assigned to the target available rescue unit. Based on the spatiotemporal dependencies between the rescue sub-tasks, the rescue sub-tasks assigned to the same available rescue unit of the target are sorted to obtain a rescue task sequence.

[0011] In one embodiment, the step of determining the target available rescue unit based on an auction algorithm, with the goal of minimizing the global task completion time and maximizing the total utility, and then allocating the rescue sub-task to the target available rescue unit, includes: With the goal of minimizing the overall task completion time and maximizing the total utility, the comprehensive utility value and current bidding status of each candidate available rescue unit are determined, and the bidding results of the candidate available rescue units for the unassigned rescue sub-tasks are obtained. The bidding results are summarized, and the candidate available rescue unit with the largest bid is determined as the temporary target available rescue unit, thus obtaining the allocation result; When the allocation result is that the same temporary target available rescue unit is available for a consecutive preset number of times or the number of iterations reaches a preset number of iterations, the temporary target available rescue unit is determined as the target available rescue unit; The rescue sub-tasks are assigned to the target available rescue units.

[0012] In one embodiment, the step of matching the received emergency rescue request, which includes the location and level of the incident, with a scheduling case library to determine the initial task area and the required resource type includes: Feature extraction is performed on the received emergency rescue requests, which include the location and level of the incident, to obtain key feature vectors; Calculate the feature similarity between the key feature vector and historical cases in the scheduling case library, and determine a preset number of reference cases based on the feature similarity; Based on the analysis of the reference case, the initial task area and the required resource types are determined.

[0013] In one embodiment, the step of determining the health status and task load of each available rescue unit based on a resource status database, and determining the dynamic attribute information and spatial location information of each available rescue unit under the required resource type based on the health status and task load, includes: Regularly collect real-time status data of each available rescue unit, including equipment operating parameters, energy reserves, and personnel status indicators; The real-time status data is fused and calculated according to a preset set of evaluation rules to obtain a quantitative health status score. The task load is calculated by statistically analyzing the tasks that each available rescue unit has undertaken but not yet completed. By mapping the health status score to the task load, dynamic attribute information and spatial location information of each available rescue unit under the required resource type are obtained.

[0014] In one embodiment, the step of distributing the plurality of rescue mission sequences to each of the available rescue units, so that the available rescue units can perform emergency rescue missions, includes: A temporary session key pair is generated based on an asymmetric encryption algorithm. The public key component in the temporary session key pair is encrypted according to the preset public key of the available rescue unit to obtain the key. The key is then sent to the available rescue unit to establish a secure communication link. The rescue mission sequence is encrypted using the key to obtain encrypted data and a message authentication code, and the encrypted data and the message authentication code are then encapsulated into an encrypted data packet. The encrypted data packet is distributed to the corresponding available rescue unit through the secure communication link, so that the available rescue unit can perform emergency rescue tasks.

[0015] Furthermore, to achieve the above objectives, this application also proposes a multi-unit collaborative action resource scheduling device, which includes: The case matching module is used to match the received emergency rescue request, which includes the location and level of the incident, with the scheduling case library to determine the initial task area and the required resource type. The status assessment module is used to determine the health status and task load of each available rescue unit based on the resource status database, and to determine the dynamic attribute information and spatial location information of each available rescue unit under the required resource type based on the health status and task load. The task decomposition module is used to decompose the rescue task according to the initial task area, the dynamic attribute information and the spatial location information to obtain multiple rescue sub-tasks; The decision generation module is used to make task allocation decisions for multiple rescue sub-tasks to obtain multiple rescue task sequences. The task distribution module is used to distribute multiple rescue task sequences to each of the available rescue units, so that the available rescue units can perform emergency rescue tasks.

[0016] In addition, to achieve the above objectives, this application also proposes a multi-unit collaborative action resource scheduling device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the multi-unit collaborative action resource scheduling method described above.

[0017] In addition, to achieve the above objectives, the present invention also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-unit cooperative action resource scheduling method described above.

[0018] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the multi-unit cooperative action resource scheduling method described above.

[0019] This application provides a multi-unit collaborative action resource scheduling method. It receives emergency rescue requests containing the incident location and event level, and determines the initial task area and required resource types by matching them with a scheduling case library. Based on a resource status database, it assesses the health status and task load of available rescue units, thereby obtaining their dynamic attributes and spatial location information. Combining the initial task area and unit information, the rescue task is decomposed into multiple functionally parallel or sequential rescue sub-tasks. A task allocation decision model assigns appropriate rescue units to each sub-task, forming a task sequence. Finally, the encrypted task sequence is securely distributed to the corresponding units for rescue execution. Through this approach, the method achieves rapid response, intelligent decomposition, and efficient collaboration of rescue tasks, improving the timeliness, accuracy, and overall rescue success rate of resource scheduling. Attached Figure Description

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

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

[0022] Figure 1 This is a flowchart illustrating an embodiment of the multi-unit collaborative action resource scheduling method of this application; Figure 2 This is a flowchart illustrating the rescue sub-task allocation decision and task sequence generation of an embodiment of the multi-unit collaborative action resource scheduling method of this application; Figure 3 This is a schematic diagram of the module structure of the multi-unit collaborative action resource scheduling device according to an embodiment of this application; Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-unit collaborative action resource scheduling method in this application embodiment.

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

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

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

[0026] The main solution of this application embodiment is: based on the received emergency rescue request containing the incident location and the incident level, the incident location and the incident level are matched with the scheduling case library to determine the initial task area and the required resource type; Based on the resource status database, the health status and task load of each available rescue unit are determined, and the dynamic attribute information and spatial location information of each available rescue unit under the required resource type are determined based on the health status and task load. The rescue mission is decomposed based on the initial mission area, the dynamic attribute information, and the spatial location information to obtain multiple rescue sub-tasks; A task allocation decision is made for multiple rescue sub-tasks to obtain multiple rescue task sequences; The multiple rescue mission sequences are distributed to each of the available rescue units so that the available rescue units can perform emergency rescue missions.

[0027] Currently, existing emergency rescue resource dispatching technologies generally suffer from low dispatching efficiency and poor coordination. Traditional dispatching models often rely on manual experience or simple rule matching, making it difficult to quickly respond to the dynamic needs of emergencies. This leads to unreasonable task allocation, a lack of effective coordination between rescue units (such as vehicles, personnel, and equipment), and situations where resources are idle or tasks are clustered together, making it difficult to form a cohesive force and thus seriously affecting the timeliness and success rate of the overall rescue operation.

[0028] Furthermore, due to the failure to fully consider the real-time health status, task load, and accurate geospatial relationships of rescue units, existing solutions cannot achieve refined task decomposition and dynamic optimization allocation. Each rescue unit often operates in an information silo, with poorly coordinated action steps, further exacerbating coordination difficulties and hindering the efficient use of valuable rescue resources, making them particularly inadequate in responding to large-scale or complex emergencies.

[0029] This application provides a solution that receives emergency rescue requests containing the incident location and event level, determines the initial task area and required resource types by matching them with a scheduling case library, assesses the health status and task load of available rescue units based on a resource status database, and then obtains their dynamic attributes and spatial location information, decomposes the rescue task based on the initial task area and unit information, and generates multiple functionally parallel or sequential rescue sub-tasks, assigns appropriate rescue units to each sub-task through a task allocation decision model, and forms a task sequence, and finally securely distributes the encrypted task sequence to the corresponding units for rescue execution. Through the above methods, this approach achieves rapid response, intelligent decomposition, and efficient collaboration of rescue tasks, improving the timeliness, accuracy, and overall success rate of resource scheduling.

[0030] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or multi-unit collaborative action resource scheduling device capable of performing the above functions. This embodiment does not specifically limit it in this regard. The following uses a multi-unit collaborative action resource scheduling device as an example to describe this embodiment and the following embodiments.

[0031] All actions involving the acquisition of signals, information, or data in this application are carried out in accordance with the relevant data protection laws and policies of the country where the application is located, and with the authorization of the owner of the relevant device.

[0032] The core of the multi-unit collaborative action resource scheduling process is software-defined. This means that its logic, strategies, and control capabilities are not fixed in the hardware, but are implemented centrally and flexibly by the upper-level software system. Through programmable means, the software dynamically integrates, schedules, and optimizes various resources (such as computing, communication, and action units), abstracting physical entities into services that can be managed on demand, thereby achieving intelligent, adaptive, and automated execution of complex task processes.

[0033] This application provides a multi-unit collaborative action resource scheduling method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-unit collaborative action resource scheduling method of this application.

[0034] In this embodiment, the multi-unit collaborative action resource scheduling method includes steps S10 to S50: Step S10: Based on the received emergency rescue request containing the incident location and incident level, match the incident location and incident level with the scheduling case library to determine the initial task area and required resource type.

[0035] It should be noted that the dispatch case library is a pre-built knowledge base that stores data models of historical emergency response cases. Each case typically includes several key feature dimensions: the location of the historical event (e.g., latitude and longitude coordinates), the event level (e.g., levels I-IV classified according to disaster severity), the initially defined "initial task area" (i.e., the core and surrounding geographical area that the rescue operation needed to cover), and the "required resource types" (e.g., the types and quantities of rescue units such as medical care, fire fighting, and engineering rescue) deployed to successfully handle the event. The essence of this case library is to structurally store past effective dispatching experience as a reference for dispatching decisions in new events.

[0036] Understandably, the system first receives standardized emergency response request messages from the front-end or early warning system via an application programming interface (API). Then, it parses key features such as the incident location and event level from the message and converts them into feature vectors. Next, using a similarity calculation algorithm (such as based on Euclidean distance or cosine similarity, and comprehensively considering geospatial proximity and event level similarity), the system quickly matches and retrieves the feature vector of the new event with historical cases in the case library. Finally, the system selects one or more historical cases with the highest similarity, analyzes the task area and resource type fields of these cases, and intelligently corrects them based on subtle differences in the new event, thereby outputting initial task area suggestions and a resource type list suitable for the current request.

[0037] In one feasible implementation, the step of matching the received emergency rescue request, which includes the location and level of the incident, with a scheduling case library to determine the initial task area and the required resource type includes: Feature extraction is performed on the received emergency rescue requests, which include the location and level of the incident, to obtain key feature vectors; Calculate the feature similarity between the key feature vector and historical cases in the scheduling case library, and determine a preset number of reference cases based on the feature similarity; Based on the analysis of the reference case, the initial task area and the required resource types are determined.

[0038] It should be noted that feature similarity is a numerical value used to measure the degree of proximity or similarity between a newly issued emergency rescue request and a historical case in the case database in terms of key features. Similarity is usually calculated using mathematical algorithms, and the value ranges from 0 to 1, with higher values ​​indicating greater similarity.

[0039] In the specific implementation, the newly received emergency rescue requests are first processed in a structured manner, i.e., "feature extraction". Specifically, the location of the incident (such as latitude and longitude coordinates) is extracted. ) and event level (e.g., defined as a grade) These two key pieces of information are used to construct a feature vector, for example:

[0040] The next step is the core similarity calculation and case retrieval process. The system will calculate the feature vector of the new request. The feature vector of each historical case in the case library Overall similarity between This overall similarity score is typically composed of geographic location similarity. Similarity to event level The result is obtained through weighted calculation. A common calculation formula is as follows:

[0041] in, and These are the weighting coefficients for geographical location and event level, respectively, satisfying... According to business logic, usually The weight is greater than This is because the location of the incident has a more direct impact on the geographical scope of resource allocation. This refers to geographical similarity. It can be calculated using the inverse distance function, for example... Where D is the spherical distance (e.g., Haversine distance) between the new location and the historical case location. The closer the distance, the smaller the value of D. The closer it is to 1. This is event-level similarity. Its calculation can be simplified to... ,in This is the maximum value for the event level. When the levels are completely identical, the similarity is 1.

[0042] After calculating all similarities, the system will proceed according to... The data is sorted from highest to lowest, and a predetermined number (Top-K) of cases are selected as reference cases. Finally, the initial task regions (e.g., the geographical convex hull or centroid buffer region of these task regions) and required resource types (e.g., the union of resource types or the most frequent type) of these reference cases are aggregated and analyzed to generate scheduling suggestions for the current new request.

[0043] Step S20: Based on the resource status database, determine the health status and task load of each available rescue unit, and based on the health status and task load, determine the dynamic attribute information and spatial location information of each available rescue unit under the required resource type.

[0044] It should be noted that dynamic attribute information refers to variable attributes, other than static identification, that reflect the current operational capabilities of a rescue unit in real time. This is typically a set of quantitative indicators including health status scores, current task load rates, and comprehensive availability indices. Spatial location information refers to the geographic coordinates transmitted in real time by the rescue unit through positioning systems such as GPS or BeiDou. This information is the basis for nearby dispatching and route planning.

[0045] In its implementation, the system periodically or through event-triggered queries retrieves real-time data from the resource status database for each rescue unit. The health status may be derived from indicators reported by the equipment self-inspection system, while the task load is calculated by counting the number of rescue tasks currently assigned but not yet completed or the estimated working hours for that unit. The system will determine whether a unit is in an "available" state based on a preset set of rules, such as a health score higher than a threshold and a load rate lower than a threshold. These dynamic attributes, along with real-time latitude and longitude information, are then encapsulated into a data structure that can be used by the scheduling algorithm.

[0046] In one feasible implementation, the step of determining the health status and task load of each available rescue unit based on a resource status database, and determining the dynamic attribute information and spatial location information of each available rescue unit under the required resource type based on the health status and task load, includes: Regularly collect real-time status data of each available rescue unit, including equipment operating parameters, energy reserves, and personnel status indicators; The real-time status data is fused and calculated according to a preset set of evaluation rules to obtain a quantitative health status score. The task load is calculated by statistically analyzing the tasks that each available rescue unit has undertaken but not yet completed. By mapping the health status score to the task load, dynamic attribute information and spatial location information of each available rescue unit under the required resource type are obtained.

[0047] It should be noted that the preset evaluation rule set is used to transform scattered real-time status data into standardized evaluation indicators. Equipment operating parameters refer to the operating condition data reported by rescue vehicles or equipment through sensors, such as engine working hours and fault codes. Energy reserves refer to the remaining amount of key materials such as fuel, electricity or medical oxygen. Personnel status indicators include the continuous working hours and physical and mental fatigue index of rescue personnel or firefighters.

[0048] In practical implementation, the system periodically polls or receives real-time status data proactively reported by rescue units via the IoT data bus. For calculating the health status score, a multi-indicator weighted fusion model is typically used; for example, the formula is set as follows:

[0049] in For the preset weighting coefficients, satisfy ,function These are sub-functions that normalize equipment parameters, energy reserves, and personnel status. For example, g = current fuel level / standard fuel tank capacity, ultimately... Normalized to a value between 0 and 1.

[0050] The calculation of task load is relatively straightforward, and is usually... Alternatively, a weighted sum of working hours can be used for calculation. The system then binds the two key dynamic attributes of health status score and task load with the real-time latitude and longitude information obtained by the unit from the positioning module, together forming a complete resource information object for subsequent optimization and scheduling.

[0051] Step S30: Decompose the rescue task according to the initial task area, the dynamic attribute information and the spatial location information to obtain multiple rescue sub-tasks.

[0052] It should be noted that a rescue subtask is the smallest independent and parallel or sequential operational unit that breaks down a complex comprehensive rescue mission based on factors such as geographical location, resource capabilities, or mission phase. Each subtask is clearly defined to a specific operational area, the type of professional resources required, and the expected outcome.

[0053] It should be understood that the system typically divides the space based on the geometric boundaries and internal geographical features (such as the distribution of roads and buildings) of the initial task area, for example by using gridding or administrative / functional zoning. At the same time, it combines the spatial location information and dynamic attributes (such as special equipment capabilities and current load) of available rescue units to decompose the overall task objective into specific action instructions covering different sub-areas and handled by different professional units, forming a series of logically related but independently executed sub-task queues.

[0054] In one feasible implementation, the step of decomposing the rescue task into multiple rescue sub-tasks based on the initial task area, the dynamic attribute information, and the spatial location information includes: The overall target timeframe and success threshold for the rescue mission are determined based on the event level. Based on the overall target timeliness, the success threshold, and the unit capability type and execution efficiency in the dynamic attribute information, the rescue mission is decomposed into sub-targets that are functionally parallel or sequential. Based on the spatial location information and the spatial topology relationship between the initial task area, an execution geographical area and arrival path are defined for each sub-target; Multiple rescue sub-tasks are generated based on the sub-target, the execution geographic area, and the arrival route.

[0055] It should be noted that the overall target timeframe refers to the maximum time window allowed from the start of a rescue mission to its defined end; the success threshold refers to the minimum quantitative standard for measuring whether a rescue mission has achieved its expected results, such as successfully evacuating a specific proportion of the population or controlling a specific area of ​​the disaster; unit capability type and execution efficiency refer to the professional classification of rescue units and their average efficiency in completing a specific type of work per unit time; and spatial topology refers to the spatial connection and accessibility characteristics between the initial mission area and the locations of each rescue unit, such as distance, path accessibility, and obstacle distribution.

[0056] In its implementation, the system matches the preset total target timeframe from the contingency plan library based on the event level (e.g., levels I-IV). and success threshold The core of task decomposition is to base the overall goal (such as "in...") on the type of unit capability and execution efficiency. The objective of "covering the entire region" is broken down into sub-objectives. This typically involves an optimization model that aims to maximize the overall success rate, with constraints including total timeliness and resource capacity. For example, a sub-objective could be defined as "within time..." Inside, by those with the ability The unit in the region Completed workload Its execution efficiency constraint can be formalized as:

[0057] in It is capable unit The execution efficiency is such that the summation is performed on all units allocated to the sub-target.

[0058] Next, the system utilizes a geographic information system to analyze spatial topology, defining the execution geographic area and planning the arrival path for each sub-objective. This can be achieved through spatial query and path planning algorithms. For example, based on road network data, the shortest path time from the unit location to each sub-region within the initial task area is calculated, ensuring that the regional division of sub-objectives meets the constraints of the overall target timeliness; that is, the execution area of ​​the sub-objectives must satisfy the following:

[0059] in It is a unit The estimated time of arrival in its assigned sub-region. Ultimately, the system encapsulates the sub-target, its corresponding execution geographic area, and the planned arrival route into individual rescue sub-task objects containing specific action instructions.

[0060] In one feasible implementation, the step of decomposing the rescue mission into functionally parallel or sequential sub-goals based on the overall target timeliness, the success threshold, and the unit capability type and execution efficiency in the dynamic attribute information includes: Construct a task decomposition model with the overall target timeliness as a hard constraint and maximizing the overall success probability as the optimization objective, and determine the solution space; Based on the unit capability type and execution efficiency in the dynamic attribute information, the time consumption probability and success probability of rescue units with different capability types executing various sub-tasks are fitted. Using the success threshold as the termination condition, a heuristic exploration is performed in the solution space to generate multiple candidate decomposition schemes; The execution time and estimated success rate of each candidate decomposition scheme are determined, and the candidate decomposition scheme with the estimated success rate greater than the success threshold and the shortest execution time is selected as the target decomposition scheme. The rescue mission is decomposed into sub-goals that are functionally parallel or sequential, according to the target decomposition scheme.

[0061] It should be noted that the task decomposition model is a mathematical programming or algorithmic framework that transforms macro-level rescue tasks into specific action plans. Its solution space includes all potential task partitioning and resource matching methods that conform to basic logical constraints. The time consumption probability refers to the uncertainty distribution of the time required for a rescue unit of a specific capability type to complete a certain type of sub-task. The success probability is the expected quality of the corresponding task completion.

[0062] In practical implementation, the task decomposition model can be formalized as a constrained optimization problem with the objective function being: The constraints are:

[0063] in, It represents the success probability of the entire task. This is the estimated total execution time. This refers to the overall target timeframe and the overall success probability. It is usually determined by the combined results of the execution of each subtask. If the subtasks are relatively independent, it can be modeled as follows:

[0064] in This represents the success probability of the i-th subtask. The system assigns a probability to each capability type based on historical data or expert knowledge. Execute various sub-tasks Fit the time consumption distribution (such as normal distribution) and basic success probability .

[0065] In heuristic exploration, a genetic algorithm can be used to encode a decomposition scheme as a chromosome. Genes represent the units and order of subtask partitioning and allocation. The algorithm iteratively evolves the population through selection, crossover, and mutation operations. For each candidate scheme, its... (Sum of time spent on each parallel path) and The algorithm uses a fitness function (such as...) The evaluation schemes were assessed to determine their merits, and ultimately, those that met the criteria were selected from the last generation of the population. and The shortest solution is used as the target decomposition scheme, thereby determining the set of sub-targets.

[0066] In one feasible implementation, the step of defining the execution geographic area and arrival path for each sub-target based on the spatial location information and the spatial topology relationship of the initial task area includes: The initial task area is gridded based on a geographic information system to generate a weighted raster map, where the weights are determined by terrain, obstacles, and access difficulty. Determine the functional requirements for each sub-target, and identify the core operational area corresponding to the functional requirements in the grid map; Centered on the core operation area, and combined with the real-time distribution of available rescue units in the spatial location information, the execution geographical area of ​​each sub-target is dynamically divided. Based on the weight information of the grid map, an arrival path is generated according to the path search algorithm.

[0067] It should be noted that a raster map is a two-dimensional grid data model that discretizes continuous geographic space into regular units (grids). Each grid unit contains one or more attribute values. Weighting information is a numerical value assigned to each grid to quantify the cost of traversing the actual geographic unit represented by that grid, such as time, energy consumption, or risk. The core operational area refers to the key geographic area where critical actions must be performed to achieve a specific sub-objective. Its definition depends on the functional requirements of the sub-objective; for example, the core area of ​​a firefighting sub-objective might be the fire's center point and its direction of spread.

[0068] In the specific implementation, the initial task area is first divided into grids using GIS to generate a raster map, with each grid cell... Assigned a passage cost weight This weight takes into account factors such as terrain slope, surface type, and obstacle density, and can be calculated through a weighted linear combination:

[0069] in , , These are the normalized values ​​for terrain complexity, obstacle impact, and hazard level, respectively. These are the weighting coefficients for each factor. The functional requirements of a sub-objective (such as "search and rescue covering a radius of 100 meters") are used to identify its core operational area C in a raster map, which is typically a subset of raster cells.

[0070] The execution geographical area is divided around the core area C, while also considering the location distribution of available rescue units. The goal is to rationally allocate the mission area to the nearest or most suitable unit, while balancing the workload of each unit. This can be modeled as a spatial optimization problem, for example, using Voronoi diagrams or clustering algorithms (such as K-means), with unit locations as seed points and travel cost as the distance metric, to dynamically generate the execution area for each sub-objective. Subsequently, for each unit and its assigned execution area, a path search algorithm (such as A* or Dijkstra's algorithm) is used to calculate the optimal arrival path on a weighted raster map. The algorithm evaluates the total path cost to ensure that the path is practically feasible and efficient.

[0071] Step S40: Make a task allocation decision for the multiple rescue sub-tasks to obtain multiple rescue task sequences.

[0072] It should be noted that task allocation decision refers to the process of assigning multiple rescue sub-tasks generated after decomposition to one or more rescue units according to certain optimization objectives and constraints. A rescue task sequence refers to a set of sub-tasks assigned to a single rescue unit, arranged in a specific time or logical order, which clarifies the unit's execution route and action order.

[0073] Understandably, when making task allocation decisions, it is usually modeled as a multi-objective optimization problem, such as the vehicle routing problem with time windows or its extended models. The decision variables include the allocation relationship between tasks and units and the task execution order of each unit. The optimization objectives are usually to minimize the total completion time, the total distance traveled, or to maximize the task coverage, and must satisfy constraints such as subtask temporal dependencies, unit capability matching, and total resources. Metaheuristic algorithms such as genetic algorithms and ant colony algorithms are often used to solve the problem, and finally, an ordered list of tasks is output for each unit.

[0074] In one feasible implementation, the step of making task allocation decisions on multiple rescue sub-tasks to obtain multiple rescue task sequences includes: Each rescue subtask is encapsulated to obtain a task announcement; The available rescue units are screened based on their capability type and current health status to determine candidate available rescue units, and the mission announcement is broadcast to the candidate available rescue units. Receive bids returned by each of the candidate available rescue units, the bids including a comprehensive utility value; With the goal of minimizing the global task completion time and maximizing the total utility, and in conjunction with the comprehensive utility value, a target available rescue unit is determined based on an auction algorithm, and the rescue sub-tasks are assigned to the target available rescue unit. Based on the spatiotemporal dependencies between the rescue sub-tasks, the rescue sub-tasks assigned to the same available rescue unit of the target are sorted to obtain a rescue task sequence.

[0075] It should be noted that the mission announcement is a standardized description of a rescue sub-task, including attributes such as mission location, required capabilities, estimated time, and deadline, used to issue a request to rescue units. The tender document is a candidate rescue unit's response to the mission announcement, containing the unit's commitment to perform the task, such as estimated arrival time and probability of success. The overall utility value reflects the efficiency, cost, and expected results of a rescue unit performing a specific task.

[0076] It should be understood that, with reference Figure 2 , Figure 2A flowchart for the decision-making process and task sequence generation for assigning rescue subtasks is provided. Auction algorithms are a distributed coordination mechanism that simulates the auction process in economics, allocating tasks to units that provide the best utility through bidding. Spatiotemporal dependencies refer to the sequential constraints or geographical proximity requirements between subtasks; for example, task B can only begin after task A is completed, or two tasks located close to each other can be combined to reduce travel time.

[0077] In its implementation, the system handles each rescue subtask. A mission announcement is generated and broadcast; candidate rescue units that receive the announcement... It calculates the bid based on its own status (such as current location, remaining energy, and unique skills), with the key component being the comprehensive utility value. This value can be calculated as:

[0078] in, It is a unit Expected completion of the task Total time required (including travel and operation time). It is the estimated probability of success. It is a unit Current health status score These are weighting coefficients, reflecting the degree of importance attached to different factors.

[0079] Subsequently, the system employs an auction algorithm for allocation, the core of which is global optimization, and the objective function can be expressed as: and This is typically transformed into a single-objective problem for solution. The algorithm iterates, and in each round, a comprehensive utility value for the bid is selected for each unassigned task. The highest-priority unit is designated as the temporary winner, and its bid price is recorded. If a unit is contested by multiple tasks, the final allocation is determined through conflict resolution rules (such as directly assigning it to the highest-priority task) or a second round of bidding. After all tasks are assigned, for tasks assigned to the same unit... Given a set of subtasks, the system constructs a dependency graph based on their spatiotemporal dependencies and employs topological sorting or a variation of the traveling salesman problem that considers movement costs to... Generate a rescue mission sequence with the shortest total execution time or the optimal path.

[0080] In one feasible implementation, the step of determining the target available rescue unit based on an auction algorithm, with the goal of minimizing the global task completion time and maximizing the total utility, and then allocating the rescue sub-task to the target available rescue unit, includes: With the goal of minimizing the overall task completion time and maximizing the total utility, the comprehensive utility value and current bidding status of each candidate available rescue unit are determined, and the bidding results of the candidate available rescue units for the unassigned rescue sub-tasks are obtained. The bidding results are summarized, and the candidate available rescue unit with the largest bid is determined as the temporary target available rescue unit, thus obtaining the allocation result; When the allocation result is that the same temporary target available rescue unit is available for a consecutive preset number of times or the number of iterations reaches a preset number of iterations, the temporary target available rescue unit is determined as the target available rescue unit; The rescue sub-tasks are assigned to the target available rescue units.

[0081] It should be noted that the bidding status describes the participation of candidate rescue units in the current auction round, such as whether they have been temporarily assigned a task or are currently bidding for a task. The bidding result is the quantified value proposition calculated and submitted by a candidate rescue unit for a specific rescue subtask based on its own capabilities and status, usually expressed numerically. The temporarily available rescue unit is the unit with the best overall utility temporarily determined based on all bidding results in the current round for a specific rescue subtask during the auction algorithm iteration process; however, this allocation result is not finalized before the algorithm converges.

[0082] In practice, auction algorithms typically initialize an empty allocation set and set a maximum number of iterations. And convergence conditions (such as unchanged allocation results for K consecutive iterations), in each iteration, each unassigned subtask It will receive data from all qualified candidate units. bid This bid It is usually directly related to or equal to the comprehensive utility value mentioned above. This reflects the unit Execute the task The "will" or "value" for each task The algorithm aggregates these bids and temporarily allocates them to the unit with the highest bid, i.e.: .

[0083] The temporary allocation result is recorded. The algorithm checks whether the allocation scheme of the current iteration is consistent with the schemes of the previous iterations. If the temporary allocation results of all tasks have not changed in K consecutive iterations, the auction is considered to have converged, the system has reached a stable state, and the corresponding allocation scheme is determined as the final scheme. Alternatively, if the number of iterations reaches a preset upper limit... Even if it does not fully converge, the iteration is terminated and the current optimal solution is adopted. After convergence, all temporary target available rescue units are officially confirmed as target available rescue units. The algorithm outputs the final task allocation mapping relationship and assigns each rescue subtask to its corresponding target available rescue unit.

[0084] Step S50: Distribute the multiple rescue mission sequences to each of the available rescue units so that the available rescue units can perform emergency rescue missions.

[0085] It should be noted that distribution refers to the process of reliably transmitting the customized rescue mission sequence generated by the central decision-making system for each available rescue unit to the corresponding unit through the communication network.

[0086] In practical implementation, data transmission typically relies on wireless communication networks (such as 4G / 5G, dedicated wireless networks, or satellite communication). The communication protocol must ensure the reliability and real-time performance of the instructions. Before distribution, the task sequence data may be encrypted and compressed. The sequence information includes task coordinates, action instructions, precautions, etc. After receiving the data, the unit needs to provide confirmation feedback. The system can be configured with a monitoring mechanism to track the task execution status and trigger retransmission or replanning when deviations or communication interruptions occur.

[0087] In one feasible implementation, the step of distributing the plurality of rescue mission sequences to each of the available rescue units, so that the available rescue units can perform emergency rescue missions, includes: A temporary session key pair is generated based on an asymmetric encryption algorithm. The public key component in the temporary session key pair is encrypted according to the preset public key of the available rescue unit to obtain the key. The key is then sent to the available rescue unit to establish a secure communication link. The rescue mission sequence is encrypted using the key to obtain encrypted data and a message authentication code, and the encrypted data and the message authentication code are then encapsulated into an encrypted data packet. The encrypted data packet is distributed to the corresponding available rescue unit through the secure communication link, so that the available rescue unit can perform emergency rescue tasks.

[0088] It should be noted that asymmetric encryption algorithms are cryptographic systems that use a mathematically linked pair of keys (public and private keys) for encryption and decryption. The public key can be publicly used for encryption, while the private key must be kept secret for decryption. Temporary session key pairs are short-lived asymmetric key pairs generated temporarily for a single or short-term communication session, designed to achieve forward security. Pre-defined public keys are long-term public keys that have been securely distributed beforehand and stored in the rescue unit, either generated by the unit itself or issued by a certificate authority.

[0089] It should be understood that the public key component is the publicly shared portion of an asymmetric key pair. A secure communication link is a logical communication channel established using cryptographic techniques to ensure the confidentiality, integrity, and authenticity of data transmission. A message authentication code is a short data block associated with a key and message content, used to verify that the message has not been tampered with during transmission and originates from a legitimate sender.

[0090] In the specific implementation, a temporary asymmetric key pair is first generated for this distribution session. ),in The temporary private key is secretly stored by the system. Use a temporary public key to ensure Safely delivered to specific rescue units The system uses the long-term public key preset by this unit. right Encryption is performed, and the encryption process can be represented as follows: ,in Represents asymmetric encryption functions (such as RSA-OAEP), generating This is the "key". Send to the rescue unit , Use its corresponding long-term private key Decryption : After that, both sides can utilize (and This allows for subsequent secure communication negotiations, thereby establishing a secure communication link.

[0091] After the secure link is established, the system uses an efficient symmetric encryption algorithm (such as AES) to encrypt the actual rescue mission sequence data M, first using a temporarily negotiated symmetric session key. (This key can be accessed via...) / The key negotiation protocol, such as ECDH, is obtained, or directly used. Encrypt a randomly generated Passed to Encrypt M: Meanwhile, to ensure data integrity and verify the sender's identity, the system uses another key. (can be combined with) Calculate the message authentication code for message M (related or identical): HMAC is a keyed hash message authentication code function. Finally, the ciphertext and MAC are encapsulated into a data packet and sent to the target rescue unit through the established secure communication link. , Upon receipt, first verify that the MAC address is correct. If it is correct, then use... Decrypt the Ciphertext to obtain the plaintext task sequence M, and then execute the task.

[0092] This embodiment provides a multi-unit collaborative action resource scheduling method. It receives emergency rescue requests containing the incident location and event level, and determines the initial task area and required resource types by matching them with a scheduling case library. Based on a resource status database, it assesses the health status and task load of available rescue units, thereby obtaining their dynamic attributes and spatial location information. Combining the initial task area and unit information, the rescue task is decomposed into multiple functionally parallel or sequential rescue sub-tasks. A task allocation decision model assigns appropriate rescue units to each sub-task, forming a task sequence. Finally, the encrypted task sequence is securely distributed to the corresponding units for rescue execution. Through this approach, the method achieves rapid response, intelligent decomposition, and efficient collaboration of rescue tasks, improving the timeliness, accuracy, and overall rescue success rate of resource scheduling.

[0093] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-unit collaborative action resource scheduling method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0094] This application also provides a multi-unit collaborative action resource scheduling device, please refer to... Figure 3 The multi-unit collaborative action resource scheduling device includes: The case matching module 10 is used to match the received emergency rescue request, which includes the location of the incident and the level of the incident, with the scheduling case library to determine the initial task area and the required resource type. The status assessment module 20 is used to determine the health status and task load of each available rescue unit based on the resource status database, and to determine the dynamic attribute information and spatial location information of each available rescue unit under the required resource type based on the health status and the task load. The task decomposition module 30 is used to decompose the rescue task according to the initial task area, the dynamic attribute information and the spatial location information to obtain multiple rescue sub-tasks; Decision generation module 40 is used to make task allocation decisions for multiple rescue sub-tasks to obtain multiple rescue task sequences; The task distribution module 50 is used to distribute multiple rescue task sequences to each of the available rescue units, so that the available rescue units can perform emergency rescue tasks.

[0095] In one feasible implementation, the task decomposition module 30 is further configured to determine the overall target timeliness and success threshold of the rescue mission based on the event level. Based on the overall target timeliness, the success threshold, and the unit capability type and execution efficiency in the dynamic attribute information, the rescue mission is decomposed into sub-targets that are functionally parallel or sequential. Based on the spatial location information and the spatial topology relationship between the initial task area, an execution geographical area and arrival path are defined for each sub-target; Multiple rescue sub-tasks are generated based on the sub-target, the execution geographic area, and the arrival route.

[0096] In one feasible implementation, the task decomposition module 30 is further configured to construct a task decomposition model with the total target timeliness as a hard constraint and the optimization objective of maximizing the overall success probability, and to determine the solution space. Based on the unit capability type and execution efficiency in the dynamic attribute information, the time consumption probability and success probability of rescue units with different capability types executing various sub-tasks are fitted. Using the success threshold as the termination condition, a heuristic exploration is performed in the solution space to generate multiple candidate decomposition schemes; The execution time and estimated success rate of each candidate decomposition scheme are determined, and the candidate decomposition scheme with the estimated success rate greater than the success threshold and the shortest execution time is selected as the target decomposition scheme. The rescue mission is decomposed into sub-goals that are functionally parallel or sequential, according to the target decomposition scheme.

[0097] In one feasible implementation, the task decomposition module 30 is further configured to perform gridding processing on the initial task area based on a geographic information system to generate a weighted raster map, wherein the weights are determined by terrain, obstacles, and access difficulty. Determine the functional requirements for each sub-target, and identify the core operational area corresponding to the functional requirements in the grid map; Centered on the core operation area, and combined with the real-time distribution of available rescue units in the spatial location information, the execution geographical area of ​​each sub-target is dynamically divided. Based on the weight information of the grid map, an arrival path is generated according to the path search algorithm.

[0098] In one feasible implementation, the decision generation module 40 is further configured to encapsulate each rescue subtask to obtain a task announcement; The available rescue units are screened based on their capability type and current health status to determine candidate available rescue units, and the mission announcement is broadcast to the candidate available rescue units. Receive bids returned by each of the candidate available rescue units, the bids including a comprehensive utility value; With the goal of minimizing the global task completion time and maximizing the total utility, and in conjunction with the comprehensive utility value, a target available rescue unit is determined based on an auction algorithm, and the rescue sub-tasks are assigned to the target available rescue unit. Based on the spatiotemporal dependencies between the rescue sub-tasks, the rescue sub-tasks assigned to the same available rescue unit of the target are sorted to obtain a rescue task sequence.

[0099] In one feasible implementation, the decision generation module 40 is further configured to determine the comprehensive utility value and current bidding status of each candidate available rescue unit with the goal of minimizing the global task completion time and maximizing the total utility, and to obtain the bidding results of the candidate available rescue units for the unassigned rescue sub-tasks. The bidding results are summarized, and the candidate available rescue unit with the largest bid is determined as the temporary target available rescue unit, thus obtaining the allocation result; When the allocation result is that the same temporary target available rescue unit is available for a consecutive preset number of times or the number of iterations reaches a preset number of iterations, the temporary target available rescue unit is determined as the target available rescue unit; The rescue sub-tasks are assigned to the target available rescue units.

[0100] In one feasible implementation, the case matching module 10 is further used to extract features from the received emergency rescue request containing the location and level of the incident to obtain a key feature vector. Calculate the feature similarity between the key feature vector and historical cases in the scheduling case library, and determine a preset number of reference cases based on the feature similarity; Based on the analysis of the reference case, the initial task area and the required resource types are determined.

[0101] In one feasible implementation, the status assessment module 20 is also used to periodically collect real-time status data of each available rescue unit, the real-time status data including equipment operating parameters, energy reserves and personnel status indicators. The real-time status data is fused and calculated according to a preset set of evaluation rules to obtain a quantitative health status score. The task load is calculated by statistically analyzing the tasks that each available rescue unit has undertaken but not yet completed. By mapping the health status score to the task load, dynamic attribute information and spatial location information of each available rescue unit under the required resource type are obtained.

[0102] In one feasible implementation, the task distribution module 50 is further configured to generate a temporary session key pair based on an asymmetric encryption algorithm, encrypt the public key component in the temporary session key pair according to the preset public key of the available rescue unit to obtain a key, and send the key to the available rescue unit to establish a secure communication link; The rescue mission sequence is encrypted using the key to obtain encrypted data and a message authentication code, and the encrypted data and the message authentication code are then encapsulated into an encrypted data packet. The encrypted data packet is distributed to the corresponding available rescue unit through the secure communication link, so that the available rescue unit can perform emergency rescue tasks.

[0103] The multi-unit collaborative action resource scheduling device provided in this application, employing the multi-unit collaborative action resource scheduling method described in the above embodiments, can solve the technical problems of low efficiency and poor coordination in emergency resource scheduling. Compared with the prior art, the beneficial effects of the multi-unit collaborative action resource scheduling device provided in this application are the same as those of the multi-unit collaborative action resource scheduling method described in the above embodiments, and other technical features in the multi-unit collaborative action resource scheduling device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0104] This application provides a multi-unit collaborative action resource scheduling device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the multi-unit collaborative action resource scheduling method in the above embodiment 1.

[0105] The following is for reference. Figure 4 This document illustrates a structural schematic diagram of a multi-unit cooperative action resource scheduling device suitable for implementing embodiments of this application. The multi-unit cooperative action resource scheduling device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 4The multi-unit collaborative action resource scheduling device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0106] like Figure 4 As shown, the multi-unit cooperative resource scheduling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the multi-unit cooperative resource scheduling device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the multi-unit collaborative resource scheduling device to communicate wirelessly or wiredly with other devices to exchange data. Although a multi-unit collaborative resource scheduling device with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0107] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0108] The multi-unit collaborative action resource scheduling device provided in this application, employing the multi-unit collaborative action resource scheduling method described in the above embodiments, can solve the technical problem of multi-unit collaborative action resource scheduling. Compared with the prior art, the beneficial effects of the multi-unit collaborative action resource scheduling device provided in this application are the same as those of the multi-unit collaborative action resource scheduling method described in the above embodiments, and other technical features of this multi-unit collaborative action resource scheduling device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0111] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the multi-unit cooperative action resource scheduling method in the above embodiments.

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

[0113] The aforementioned computer-readable storage medium may be included in a multi-unit collaborative action resource scheduling device; or it may exist independently and not be assembled into a multi-unit collaborative action resource scheduling device.

[0114] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the multi-unit collaborative action resource scheduling device, the multi-unit collaborative action resource scheduling device: according to the received emergency rescue request containing the incident location and the incident level, matches the incident location and the incident level with the scheduling case library to determine the initial task area and the required resource type; Based on the resource status database, the health status and task load of each available rescue unit are determined, and the dynamic attribute information and spatial location information of each available rescue unit under the required resource type are determined based on the health status and task load. The rescue mission is decomposed based on the initial mission area, the dynamic attribute information, and the spatial location information to obtain multiple rescue sub-tasks; A task allocation decision is made for multiple rescue sub-tasks to obtain multiple rescue task sequences; The multiple rescue mission sequences are distributed to each of the available rescue units so that the available rescue units can perform emergency rescue missions.

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

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

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

[0118] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multi-unit cooperative action resource scheduling method, and is able to solve the technical problem of multi-unit cooperative action resource scheduling. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the multi-unit cooperative action resource scheduling method provided in the above embodiments, and will not be repeated here.

[0119] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-unit cooperative action resource scheduling method described above.

[0120] The computer program product provided in this application can solve the technical problems of low efficiency and poor coordination in emergency resource scheduling. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the multi-unit collaborative action resource scheduling method provided in the above embodiments, and will not be repeated here.

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

Claims

1. A resource scheduling method for multi-unit collaborative action, characterized in that, The multi-unit collaborative action resource scheduling method includes: Based on the received emergency rescue request containing the incident location and incident level, the incident location and incident level are matched with the scheduling case library to determine the initial task area and required resource type; Based on the resource status database, the health status and task load of each available rescue unit are determined, and the dynamic attribute information and spatial location information of each available rescue unit under the required resource type are determined based on the health status and task load. The rescue mission is decomposed based on the initial mission area, the dynamic attribute information, and the spatial location information to obtain multiple rescue sub-tasks; A task allocation decision is made for multiple rescue sub-tasks to obtain multiple rescue task sequences; The multiple rescue mission sequences are distributed to each of the available rescue units so that the available rescue units can perform emergency rescue missions.

2. The method as described in claim 1, characterized in that, The step of decomposing the rescue task into multiple rescue sub-tasks based on the initial task area, the dynamic attribute information, and the spatial location information includes: The overall target timeframe and success threshold for the rescue mission are determined based on the event level. Based on the overall target timeliness, the success threshold, and the unit capability type and execution efficiency in the dynamic attribute information, the rescue mission is decomposed into sub-targets that are functionally parallel or sequential. Based on the spatial location information and the spatial topology relationship between the initial task area, an execution geographical area and arrival path are defined for each sub-target; Multiple rescue sub-tasks are generated based on the sub-target, the execution geographic area, and the arrival path.

3. The method as described in claim 2, characterized in that, The step of decomposing the rescue mission into functionally parallel or sequential sub-goals based on the overall target timeliness, the success threshold, and the unit capability type and execution efficiency in the dynamic attribute information includes: Construct a task decomposition model with the overall target timeliness as a hard constraint and maximizing the overall success probability as the optimization objective, and determine the solution space; Based on the unit capability type and execution efficiency in the dynamic attribute information, the time consumption probability and success probability of rescue units with different capability types executing various sub-tasks are fitted. Using the success threshold as the termination condition, a heuristic exploration is performed in the solution space to generate multiple candidate decomposition schemes; The execution time and estimated success rate of each candidate decomposition scheme are determined, and the candidate decomposition scheme with the estimated success rate greater than the success threshold and the shortest execution time is selected as the target decomposition scheme. The rescue mission is decomposed into sub-goals that are functionally parallel or sequential, according to the target decomposition scheme.

4. The method as described in claim 2, characterized in that, The step of defining the execution geographic region and arrival path for each sub-target based on the spatial location information and the spatial topology relationship of the initial task area includes: The initial task area is gridded based on a geographic information system to generate a weighted raster map, where the weights are determined by terrain, obstacles, and access difficulty. Determine the functional requirements for each sub-target, and identify the core operational area corresponding to the functional requirements in the grid map; Centered on the core operation area, and combined with the real-time distribution of available rescue units in the spatial location information, the execution geographical area of ​​each sub-target is dynamically divided. Based on the weight information of the grid map, an arrival path is generated according to the path search algorithm.

5. The method as described in claim 1, characterized in that, The step of making task allocation decisions for multiple rescue sub-tasks to obtain multiple rescue task sequences includes: Each rescue subtask is encapsulated to obtain a task announcement; The available rescue units are screened based on their capability type and current health status to determine candidate available rescue units, and the mission announcement is broadcast to the candidate available rescue units. Receive bids returned by each of the candidate available rescue units, the bids including a comprehensive utility value; With the goal of minimizing the global task completion time and maximizing the total utility, and in conjunction with the comprehensive utility value, a target available rescue unit is determined based on an auction algorithm, and the rescue sub-tasks are assigned to the target available rescue unit. Based on the spatiotemporal dependencies between the rescue sub-tasks, the rescue sub-tasks assigned to the same available rescue unit of the target are sorted to obtain a rescue task sequence.

6. The method as described in claim 5, characterized in that, The step of determining target available rescue units based on an auction algorithm, with the goal of minimizing global task completion time and maximizing total utility, and combining the comprehensive utility value, and then allocating the rescue sub-tasks to the target available rescue units includes: With the goal of minimizing the overall task completion time and maximizing the total utility, the comprehensive utility value and current bidding status of each candidate available rescue unit are determined, and the bidding results of the candidate available rescue units for the unassigned rescue sub-tasks are obtained. The bidding results are summarized, and the candidate available rescue unit with the largest bid is determined as the temporary target available rescue unit, thus obtaining the allocation result; When the allocation result is that the same temporary target available rescue unit is available for a consecutive preset number of times or the number of iterations reaches a preset number of iterations, the temporary target available rescue unit is determined as the target available rescue unit; The rescue sub-tasks are assigned to the target available rescue units.

7. The method as described in claim 1, characterized in that, The step of matching the received emergency rescue request, which includes the location and level of the incident, with a scheduling case library to determine the initial task area and the required resource type includes: Feature extraction is performed on the received emergency rescue requests, which include the location and level of the incident, to obtain key feature vectors; Calculate the feature similarity between the key feature vector and historical cases in the scheduling case library, and determine a preset number of reference cases based on the feature similarity; Based on the analysis of the reference case, the initial task area and the required resource types are determined.

8. The method as described in claim 1, characterized in that, The steps of determining the health status and task load of each available rescue unit based on the resource status database, and determining the dynamic attribute information and spatial location information of each available rescue unit under the required resource type based on the health status and task load, include: Regularly collect real-time status data of each available rescue unit, including equipment operating parameters, energy reserves, and personnel status indicators; The real-time status data is fused and calculated according to a preset set of evaluation rules to obtain a quantitative health status score. The task load is calculated by statistically analyzing the tasks that each available rescue unit has undertaken but not yet completed. By mapping the health status score to the task load, dynamic attribute information and spatial location information of each available rescue unit under the required resource type are obtained.

9. The method as described in claim 1, characterized in that, The step of distributing the multiple rescue mission sequences to each of the available rescue units, so that the available rescue units can perform emergency rescue missions, includes: A temporary session key pair is generated based on an asymmetric encryption algorithm. The public key component in the temporary session key pair is encrypted according to the preset public key of the available rescue unit to obtain the key. The key is then sent to the available rescue unit to establish a secure communication link. The rescue mission sequence is encrypted using the key to obtain encrypted data and a message authentication code, and the encrypted data and the message authentication code are then encapsulated into an encrypted data packet. The encrypted data packet is distributed to the corresponding available rescue unit through the secure communication link, so that the available rescue unit can perform emergency rescue tasks.

10. A multi-unit collaborative action resource scheduling device, characterized in that, The multi-unit collaborative action resource scheduling device includes: The case matching module is used to match the received emergency rescue request, which includes the location and level of the incident, with the scheduling case library to determine the initial task area and the required resource type. The status assessment module is used to determine the health status and task load of each available rescue unit based on the resource status database, and to determine the dynamic attribute information and spatial location information of each available rescue unit under the required resource type based on the health status and task load. The task decomposition module is used to decompose the rescue task according to the initial task area, the dynamic attribute information and the spatial location information to obtain multiple rescue sub-tasks; The decision generation module is used to make task allocation decisions for multiple rescue sub-tasks to obtain multiple rescue task sequences. The task distribution module is used to distribute multiple rescue task sequences to each of the available rescue units, so that the available rescue units can perform emergency rescue tasks.

Images