First-aid repair task allocation method and device based on greedy strategy, medium and equipment
By using a greedy strategy-based emergency repair task allocation method, the task allocation is dynamically optimized, solving the problems of insufficient resource utilization and low scheduling efficiency in traditional emergency repairs, and achieving high efficiency and rapid response in task execution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-18
- Publication Date
- 2026-03-17
AI Technical Summary
Traditional emergency repair models rely on human experience and simple rules, making it difficult to fully utilize task attributes and real-time resource status. This results in insufficient resource utilization, low scheduling efficiency, and a lack of timely rescheduling capabilities when tasks and resources are strongly coupled and dynamically changing.
A greedy strategy-based emergency repair task allocation method is adopted. By ranking the utility values of emergency repair tasks and combining team information and travel time models, the task allocation is dynamically optimized to ensure that teams execute tasks at the fastest speed. Road traffic factors are considered to improve the reliability of distance calculation.
It improved the efficiency and timeliness of emergency repair tasks, enhanced the speed of task execution and the quality of decision-making, and improved the efficiency of resource utilization and scheduling.
Smart Images
Figure CN121684518A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing, and in particular to a method, apparatus, medium and equipment for emergency repair task allocation based on a greedy strategy. Background Technology
[0002] Emergency repairs in industries such as power, communications, and transportation often involve multiple concurrent tasks, high timeliness, and high uncertainty. Traditional methods rely on human experience and simple rules, making it difficult to fully utilize task attributes and real-time resource status. At the same time, emergency repairs involve the coordination of multiple elements such as personnel, vehicles, and materials. Delays in any link can amplify social impact and economic losses, leading to underutilization of resources, low scheduling efficiency, and a lack of timely rescheduling capabilities when tasks and resources are strongly coupled and dynamically changing. Summary of the Invention
[0003] This application provides a method, apparatus, medium, and electronic device for emergency repair task allocation based on a greedy strategy, which can dynamically optimize task allocation online and improve the response speed and decision-making quality for tasks.
[0004] Firstly, this application provides a method for allocating emergency repair tasks based on a greedy strategy, including: Obtain the emergency repair tasks and the utility value of each emergency repair task. Sort all emergency repair tasks from high to low according to the utility value to obtain the task scheduling queue. Obtain team information, including the geographical location of the repair team and the team's movement speed; Following the order of the task scheduling queue, each emergency repair task i is traversed sequentially, and the team k closest to emergency repair task i is obtained from the idle teams according to the greedy strategy. The distance between the emergency repair task i and the team k is determined by a travel time model, which is as follows:
[0005] in, Let be the geographical distance between the i-th repair task and the k-th team. Let be the average movement speed of the k-th team; For road traffic factors; Assign the emergency repair task i to team k and update the availability and geographical location of team k in real time; Iterate through the task scheduling queue until all emergency repair tasks in the queue have been assigned or there are no available free queues.
[0006] In the method provided in this embodiment, emergency repair tasks are sorted by their utility value, and teams are assigned to the top-ranked tasks based on distance. This allows teams to start executing tasks as quickly as possible, improving task execution efficiency and enhancing repair effectiveness. The distance calculation considers not only geographical distance but also the impact of road traffic, enhancing the reliability of distance calculation and thus improving task execution speed and timeliness.
[0007] Secondly, this application provides a repair task allocation device based on a greedy strategy, comprising: The queue acquisition module is used to acquire emergency repair tasks and the utility value of each emergency repair task, and sort all emergency repair tasks from high to low according to the utility value to obtain the task scheduling queue. The team acquisition module is used to acquire team information, including the geographical location of the repair team and the team's movement speed. The task matching module is used to traverse each emergency repair task i in the order of the task scheduling queue, and obtain the team k that is closest to emergency repair task i from the idle teams according to the greedy strategy. The distance between the emergency repair task i and the team k is determined by a travel time model, which is as follows:
[0008] in, Let be the geographical distance between the i-th repair task and the k-th team. Let be the average movement speed of the k-th team; For road traffic factors; The task allocation module is used to assign emergency repair task i to team k and update the availability status and geographical location of team k in real time. The traversal module is used to iterate through the task scheduling queue until all emergency repair tasks in the task scheduling queue have been assigned or there are no available idle queues.
[0009] In one exemplary embodiment, the emergency repair task allocation device 200 based on a greedy strategy further includes a queue adjustment module, which is used to clear the task scheduling queue when a user adds a new emergency repair task via the command line; redetermine the utility value of all emergency repair tasks; and allocate tasks according to the greedy strategy. In one exemplary embodiment, the task matching module 203 is further configured to: determine the time required to perform the emergency repair task and the execution capability of the team; determine a comprehensive objective function based on the utility value of the emergency repair task, the time required, and the execution capability of the team; extract candidate teams from the idle teams according to the comprehensive objective function; and obtain the team k that is closest to the emergency repair task i from the candidate teams.
[0010] In one exemplary implementation, the synthesis objective function is:
[0011] in, =1 indicates that repair task i is assigned to team j for execution. =0 indicates no allocation; Let i be the utility value of the emergency repair task. The time required to execute repair task i. The execution capability of team i; These are the weighting coefficients.
[0012] In one exemplary implementation, the utility value of the emergency repair task is:
[0013] in, For time-sensitive utility, Priority utility For risk utility, These are the weighting coefficients; The risk utility quantifies the risk of the emergency repair task, the priority utility represents the priority of the emergency repair task, and the timeliness utility is determined by the time required for the emergency repair task.
[0014] In one exemplary embodiment, the task matching module 203 is further configured to: determine the matching degree between the emergency repair task and the team; determine the comprehensive matching score of the emergency repair task team based on the matching degree and distance; and obtain the team k with the highest comprehensive matching score with emergency repair task i from the idle teams according to a greedy strategy.
[0015] In one exemplary embodiment, the repair task allocation device 200 based on a greedy strategy further includes a road factor update module, which is used to acquire real-time traffic data and determine road traffic factors based on the real-time traffic data.
[0016] Thirdly, this application provides an electronic device including a memory and one or more processors. The memory stores one or more computer programs, each including instructions. When executed by the processor, the instructions cause the electronic device to perform the greedy strategy-based emergency repair task allocation method as described in the first aspect.
[0017] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the greedy strategy-based emergency repair task allocation method as described in the first aspect.
[0018] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the emergency repair task allocation method based on a greedy strategy as described in the first aspect.
[0019] Understandably, the beneficial effects that the above-mentioned greedy strategy-based emergency repair task allocation device, electronic device, computer-readable storage medium, and computer program product can achieve can be referred to the beneficial effects in the first aspect, and will not be repeated here. Attached Figure Description
[0020] Figure 1 A flowchart illustrating the greedy strategy-based emergency repair task allocation method provided in this application embodiment; Figure 2 A schematic diagram of the structure of the emergency repair task allocation device based on a greedy strategy provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0021] To facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. For example, "first chip" and "second chip" are only used to distinguish different chips and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" do not necessarily imply that they are different. It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner. In the embodiments of this application, "at least one" means one or more, and "more than one" means two or more.
[0022] It should be noted that "at the time of..." in the embodiments of this application can be either at the instant when a certain situation occurs, or for a period of time after the occurrence of a certain situation. The embodiments of this application do not make specific limitations on this.
[0023] The implementation of this embodiment will now be described in detail with reference to the accompanying drawings.
[0024] This embodiment provides a method for allocating emergency repair tasks based on a greedy strategy. For example, this method can be applied to various electronic devices such as computers (PCs), tablets, virtual reality / augmented reality devices, wearable devices, industrial computers, and vehicle-mounted systems; it can also be applied to servers, cloud computing, server clusters, etc. This embodiment does not impose any special limitations on it.
[0025] Figure 1 A flowchart illustrating the emergency repair task allocation method based on a greedy strategy provided in an embodiment of this application is shown.
[0026] like Figure 1 As shown, the repair task allocation method based on a greedy strategy may include the following steps: Step 101: Obtain the emergency repair tasks and the utility value of each emergency repair task. Sort all emergency repair tasks from high to low according to the utility value to obtain the task scheduling queue.
[0027] The attributes of emergency repair tasks are quantitatively described, and each emergency repair task can be represented by an attribute vector. express:
[0028] in, Indicates the geographical location of the task. This is the importance weight of the task, used to measure the priority of the task in the overall power grid restoration process; The estimated operation time to complete this task does not include the travel time required for the team to arrive. This is a resource demand vector, describing the quantity of various resources required to complete the task. This indicates the risk level of the task, reflecting the potential security threats encountered during its execution; while This indicates the minimum skill requirements for the task.
[0029] Given the dynamic nature of post-disaster information, task attributes often change over time. Constantly changing, for example, the estimated time of the task. The update may be delayed due to traffic disruptions or environmental degradation. A smooth, iterative update method can be used as follows:
[0030] in, Indicates a certain task attribute (such as or ), For new observations, This is the smoothing coefficient. This formula can dynamically incorporate new information while maintaining the continuity of task attributes, improving the model's adaptability to sudden changes.
[0031] The utility value of an emergency repair task is calculated using the following formula:
[0032] in, For time-sensitive utility, Priority utility For risk utility, These are the weighting coefficients.
[0033] Risk utility is used to quantify the risks of emergency repair tasks. The specific quantification process is as follows: The risk utility of the i-th emergency repair task is:
[0034] in, For risk sensitivity coefficient, >0, Let be the risk quantification index for the i-th emergency repair task. The risk quantification index is obtained by evaluating the emergency repair task, for example, by inputting the emergency repair task into a pre-built neural network model to predict the risk quantification index.
[0035] Priority utility represents the priority of an emergency repair task. The priority utility of the i-th emergency repair task is: 0
[0036] in, These are the weight parameters.
[0037] The timeliness utility is determined by the time required for the emergency repair task, and the specific process is as follows: The timeliness utility of the i-th emergency repair task is represented as:
[0038] in, To adjust the parameters, , This is the estimated completion time for the emergency repair task. This is the latest allowed time to complete the emergency repair task.
[0039] After determining the utility value of each emergency repair task, sort them from high to low utility value to form a task scheduling queue, and assign each task according to the order of the queue.
[0040] Step 102: Obtain team information, which includes the geographical location of the repair team and the team's movement speed.
[0041] Similar to task modeling, each repair team can use attribute vectors. express:
[0042] in, For the team's current geographical location, Indicates the number of people in the team. Skill vectors characterize the different types of skills a team possesses and their levels. The average movement speed of the team. The vector of the supplies it carries. This indicates the team's ability to perform parallel operations.
[0043] This implementation also includes: real-time collection of data on changes in task status, team resources, and environmental conditions; updating the system information set J(t) using a state transition model J(t+Δt)=f(J(t),ΔT,ΔS,ΔE), where ΔT is the change in task status, ΔS is the change in team status, and ΔE is the change in environment status. Based on the updated system information set J(t), the utility value of the emergency repair task is updated within each time window [t, t+Δt].
[0044] The task status includes task information such as task type, task location, and task allocation and execution status. Team resources include team information, team size, and team geographical location. Environmental conditions include disaster type, disaster location, and geographical environment information (such as rainfall, wind speed, and road conditions).
[0045] The system information set is updated once every Δt time period. In this embodiment, the utility value of the emergency repair task is updated once every Δt time period.
[0046] Post-disaster information is characterized by dynamic updates, and task attributes often change over time. Constantly changing, for example, the estimated time of the task. The update may be delayed due to traffic disruptions or environmental degradation. A smooth, iterative update method can be used as follows:
[0047] in, Indicates a certain task attribute (such as or ), For new observations, This is the smoothing coefficient. This formula can dynamically incorporate new information while maintaining the continuity of task attributes, improving the model's adaptability to sudden changes.
[0048] Step 103: Following the order of the task scheduling queue, iterate through each emergency repair task i sequentially, and use a greedy strategy to select the team k closest to emergency repair task i from the available teams. The distance between emergency repair task i and team k is determined by a travel time model, which is as follows:
[0049] in, Let be the geographical distance between the i-th repair task and the k-th team. Let be the average movement speed of the k-th team; This refers to road traffic factors.
[0050] The process of determining road access factors involves: acquiring real-time traffic data and determining the road access factors based on this data. Real-time traffic data includes real-time traffic conditions, real-time weather, disaster types, and travel time statistics. The normal distribution or interval estimate of travel time is determined using the real-time traffic data, and then the expected travel time is calculated as the road access factor. Alternatively, future road access factors can be predicted using real-time weather and traffic conditions, allowing the road access factors to be dynamically adjusted according to actual conditions, thus improving the accuracy of the travel time model.
[0051] Calculate the distances between the repair tasks and the teams based on their information. For the i-th repair task, calculate its distance to each team. Extract The smallest team is team k, which is matched with team i for emergency repair task i.
[0052] Step 104: Assign the emergency repair task i to team k, and update the availability status and geographical location of team k in real time.
[0053] After assigning team k to task i, the availability status of team k is updated to "assigned". The geographical location of team k is also obtained in real time for location updates, so that after team k completes task i, its location can be used for subsequent task assignments.
[0054] In one implementation, when a user adds a new emergency repair task via command line, the task scheduling queue is cleared; the utility value of all emergency repair tasks is reassessed, and tasks are allocated according to a greedy strategy.
[0055] This implementation also includes: determining the time required to perform the emergency repair task and the team's execution capability; determining a comprehensive objective function based on the utility value of the emergency repair task, the required time, and the team's execution capability; extracting candidate teams from the idle teams according to the comprehensive objective function; and obtaining the team k that is closest to the emergency repair task i from the candidate teams.
[0056] The time required for emergency repairs is calculated using the following formula:
[0057] in, For the team Arrive at the mission The travel time was calculated using the time model described above. This is the estimated operation time.
[0058] Various unforeseen events may occur during actual emergency repair operations, such as equipment loss, severe weather, personnel injury, or secondary disasters. (Task assignment) The homework time is The actual working time can then be expressed as:
[0059] in This is a delayed random variable used to characterize the additional time caused by sudden events. For example, suppose... It follows a Poisson distribution or an exponential distribution, such as:
[0060] in This is a parameter representing the occurrence rate of events, reflecting the frequency and intensity of emergencies. If the disaster environment is extremely harsh, then... A larger value indicates a higher risk of delay.
[0061] In this embodiment, the estimated working time is determined by the actual working time. The time required to carry out the emergency repair task is calculated by making corrections and then accumulating and calculating the actual working time and travel time.
[0062] The team's execution capability can This refers to the team's ability to work in parallel.
[0063] The overall objective function is:
[0064] in, =1 indicates that repair task i is assigned to team j for execution. =0 indicates no allocation; Let i be the utility value of the emergency repair task. The time required to execute repair task i. The execution capability of team i; These are the weighting coefficients.
[0065] A subset of candidate teams is selected by using a comprehensive objective function, and then the team closest to the candidate team is chosen.
[0066] This embodiment can also determine the team k of the emergency repair task i in the following way, specifically including: determining the matching degree between the emergency repair task and the team; determining the comprehensive matching score of the emergency repair task team based on the matching degree and distance; and obtaining the team k with the highest comprehensive matching score with emergency repair task i from the idle teams according to a greedy strategy.
[0067]
[0068] in, The overall matching score for repair task i and team k. The degree of matching between emergency repair task i and team k is represented by a and b, which are weighting coefficients.
[0069] Construct task requirement vectors and team skill vectors (e.g., team execution capabilities) based on the emergency repair task and team information. Then, the distance between the two vectors (e.g., cosine similarity) is calculated as the matching degree.
[0070] Step 105: Iterate through the task scheduling queue until all emergency repair tasks in the task scheduling queue have been assigned or there are no available teams to assign tasks.
[0071] The greedy strategy is an algorithmic approach that adopts the optimal choice at each step, i.e., a locally optimal solution, and eventually approximates the global optimum through a series of locally optimal solutions. At each decision point, i.e., for each emergency rescue task to be assigned, the team with the highest potential benefit (i.e., closest distance) is selected from the available available teams for assignment, without backtracking or modifying previous choices. This implementation uses a greedy strategy to assign tasks, ensuring that the assigned team is the optimal one for the current task, thereby increasing the speed of task execution and achieving the goal of initiating emergency repairs.
[0072] Furthermore, this embodiment also provides a repair task allocation device based on a greedy strategy, which can be used to execute the above-described repair task allocation method based on a greedy strategy.
[0073] like Figure 2As shown, the greedy strategy-based emergency repair task allocation device 200 specifically includes: a queue acquisition module 201, used to acquire emergency repair tasks and the utility value of each emergency repair task, and sort all emergency repair tasks from high to low according to the utility value to obtain a task scheduling queue; a team acquisition module 202, used to acquire team information, including the geographical location of the emergency repair team and the team's movement speed; and a task matching module 203, used to traverse each emergency repair task i sequentially according to the order of the task scheduling queue, and acquire the team k closest to emergency repair task i from the idle teams according to the greedy strategy; the distance between emergency repair task i and team k is determined by a travel time model, which is:
[0074] in, Let be the geographical distance between the i-th repair task and the k-th team. Let be the average movement speed of the k-th team; The road access factor is used; the task allocation module 204 is used to assign the emergency repair task i to team k and update the availability status and geographical location of team k in real time; the traversal module 205 is used to traverse the task scheduling queue in a loop until all emergency repair tasks in the task scheduling queue have been assigned or there are no available teams to be assigned.
[0075] In one exemplary embodiment, the emergency repair task allocation device 200 based on a greedy strategy further includes a queue adjustment module, which is used to clear the task scheduling queue when a user adds a new emergency repair task via the command line; redetermine the utility value of all emergency repair tasks; and allocate tasks according to the greedy strategy. In one exemplary embodiment, the task matching module 203 is further configured to: determine the time required to perform the emergency repair task and the execution capability of the team; determine a comprehensive objective function based on the utility value of the emergency repair task, the time required, and the execution capability of the team; extract candidate teams from the idle teams according to the comprehensive objective function; and obtain the team k that is closest to the emergency repair task i from the candidate teams.
[0076] In one exemplary implementation, the synthesis objective function is:
[0077] in, =1 indicates that repair task i is assigned to team j for execution. =0 indicates no allocation; Let i be the utility value of the emergency repair task. The time required to execute repair task i. The execution capability of team i; These are the weighting coefficients.
[0078] In one exemplary implementation, the utility value of the emergency repair task is:
[0079] in, For time-sensitive utility, Priority utility For risk utility, These are the weighting coefficients; The risk utility quantifies the risk of the emergency repair task, the priority utility represents the priority of the emergency repair task, and the timeliness utility is determined by the time required for the emergency repair task.
[0080] In one exemplary embodiment, the task matching module 203 is further configured to: determine the matching degree between the emergency repair task and the team; determine the comprehensive matching score of the emergency repair task team based on the matching degree and distance; and obtain the team k with the highest comprehensive matching score with emergency repair task i from the idle teams according to a greedy strategy.
[0081] In one exemplary embodiment, the repair task allocation device 200 based on a greedy strategy further includes a road factor update module, which is used to acquire real-time traffic data and determine road traffic factors based on the real-time traffic data.
[0082] The specific details of each module or unit in the above-mentioned greedy strategy-based emergency repair task allocation device have been described in detail in the corresponding greedy strategy-based emergency repair task allocation method, so they will not be repeated here.
[0083] This application also provides an electronic device. Figure 3 A schematic diagram of the structure of an electronic device suitable for implementing embodiments of the present disclosure is shown. Figure 3 The electronic device 600 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.
[0084] like Figure 3 As shown, the electronic device 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 602 or a program loaded from a storage section 608 into a random access memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.
[0085] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.
[0086] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage 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 communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined in the embodiments of this application.
[0087] For example, when this computer program is executed by the central processing unit (CPU) 601, it can perform the following: obtain emergency repair tasks and the utility value of each emergency repair task; sort all emergency repair tasks from high to low according to the utility value to obtain a task scheduling queue; obtain team information, including the geographical location and movement speed of the emergency repair teams; traverse each emergency repair task i sequentially according to the order of the task scheduling queue, and obtain the team k closest to emergency repair task i from the idle teams according to a greedy strategy; the distance between emergency repair task i and team k is determined by a travel time model, which is:
[0088] in, Let be the geographical distance between the i-th repair task and the k-th team. Let be the average movement speed of the k-th team; The road access factor is used; the emergency repair task i is assigned to team k, and the availability status and geographical location of team k are updated in real time; the task scheduling queue is traversed in a loop until all emergency repair tasks in the task scheduling queue are assigned or there are no available teams to be assigned.
[0089] It should be noted that the computer-readable medium disclosed herein may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a 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, apparatus, or device. In this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0090] 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 disclosure. 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0091] The units described in the embodiments of this disclosure can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the unit itself.
[0092] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which include instructions that, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.
[0093] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.
[0094] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope 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.
Claims
1. A method for allocating repair tasks based on a greedy strategy, characterized in that, The method comprises the following steps: obtaining repair tasks and utility values of each repair task, and sorting all repair tasks from high to low according to the utility values to obtain a task scheduling queue; obtaining team information, wherein the team information comprises geographical positions of repair teams and moving speeds of the teams; sequentially traversing each repair task i in the order of the task scheduling queue, and obtaining a team k closest to the repair task i from idle teams according to a greedy strategy; a distance between the repair task i and the team k is determined by a driving time model, wherein the driving time model is: wherein, is the geographic distance between the ith repair task and the kth team, is the average moving speed of the kth team; is the road traffic factor; allocating the repair task i to the team k, and updating an available state and a geographical position of the team k in real time; cyclically traversing the task scheduling queue until all repair tasks in the task scheduling queue are allocated or there is no idle team available for allocation.
2. The method of claim 1, wherein, The method further comprises the following steps: when a user adds a new repair task through a command line, emptying the task scheduling queue; redetermining utility values of all repair tasks, and allocating tasks according to a greedy strategy.
3. The method of claim 1, wherein, The method further comprises the following steps: determining a time required for executing a repair task and an execution capability of a team; determining a comprehensive target function based on utility values of repair tasks, a time required for executing a repair task and an execution capability of a team, and extracting a candidate team from idle teams according to the comprehensive target function; obtaining a team k closest to the repair task i from the candidate team.
4. The method of claim 3, wherein, The comprehensive target function is: wherein, = 1, indicates that repair task i is assigned to team j for execution, = 0 indicates no assignment; is the utility value of repair task i, is the time required for the execution of repair task i, is the execution capability of team i; is a weight coefficient.
5. The method of claim 1, wherein, The utility value of the repair task is: wherein, is an age utility, is a priority utility, is a risk utility, is a weight coefficient; The risk utility quantifies a risk of the repair task, the priority utility represents a priority of the repair task, and the timeliness utility is determined by a time required for the repair task.
6. The method of claim 4, wherein, The method of obtaining the team k closest to the repair task i from the idle teams according to the greedy strategy comprises the following steps: determining a matching degree of the repair task and the team; determining a comprehensive matching score of the repair task and the team based on the matching degree and the distance; obtaining the team k with the highest comprehensive matching score of the repair task from the idle teams according to the greedy strategy.
7. The method of claim 1, wherein the method further comprises: The method further comprises the following steps: obtaining real-time traffic data, and determining a road traffic factor based on the real-time traffic data.
8. A device for allocating a repair task based on a greedy strategy, characterized by, The method comprises the following steps: a queue obtaining module is configured to obtain repair tasks and utility values of each repair task, and sort all repair tasks from high to low according to the utility values to obtain a task scheduling queue; a team obtaining module is configured to obtain team information, wherein the team information comprises geographical positions of repair teams and moving speeds of the teams; a task matching module is configured to sequentially traverse each repair task i in the order of the task scheduling queue, and obtain a team k closest to the repair task i from idle teams according to a greedy strategy; a distance between the repair task i and the team k is determined by a driving time model, wherein the driving time model is: wherein, is the geographic distance between the ith repair task and the kth team, is the average moving speed of the kth team; is the road traffic factor; a task allocation module is configured to allocate the repair task i to the team k, and update an available state and a geographical position of the team k in real time; a traversal module is configured to cyclically traverse the task scheduling queue until all repair tasks in the task scheduling queue are allocated or there is no idle team available for allocation. The method further comprises the following steps: when a user adds a new repair task through a command line, emptying the task scheduling queue; redetermining utility values of all repair tasks, and allocating tasks according to a greedy strategy. The method further comprises the following steps: determining a time required for executing a repair task and an execution capability of a team; determining a comprehensive target function based on utility values of repair tasks, a time required for executing a repair task and an execution capability of a team, and extracting a candidate team from idle teams according to the comprehensive target function; obtaining a team k closest to the repair task i from the candidate team. 9.A computer readable storage medium storing a computer program, wherein the computer program, when executed by a processor, causes the processor to perform the method of claim 1 to 7.
10. An electronic device, comprising: An electronic device comprising a processor and a memory, the memory storing one or more computer programs comprising instructions that, when executed by the electronic device, cause the electronic device to perform the method of claim 1 to 7.