A landslide emergency work order incremental updating and resource rescheduling method and system

Abstract

The application discloses a landslide emergency work order incremental updating and resource rescheduling method and system, and belongs to the technical field of geological disaster emergency disposal, task work order management and resource scheduling. The method comprises the following steps: acquiring a system snapshot and a working copy before updating; comparing corresponding objects in the update input and the snapshot to generate a structured change event; keeping the system snapshot unchanged before updating, and writing the change content in the working copy; determining direct influence and propagation influence and extracting affected work orders; dividing all work orders in the working copy after updating into three categories of frozen, allowed rearrangement and manual confirmation; registering resource occupation of frozen tasks, manual confirmation tasks and potential resource conflict adjacent tasks; performing local rescheduling according to a preset task sequence and updating team and equipment occupation item by item; outputting local scheduling or failure reason; merging and checking and generating a new version.

Description

Technical Field

[0001] This invention belongs to the field of geological disaster emergency response, task order management and resource scheduling technology, specifically involving a method and system for incremental updating of landslide emergency work orders and resource rescheduling. Background Technology

[0002] Landslide emergency response typically begins with a risk assessment and work order based on imagery or monitoring information. An initial schedule is then generated based on available rescue teams, equipment, roads, and time constraints. During the response process, changes may occur, such as new observations, landslide expansion, road closures, and team unavailability. The real challenge then becomes identifying which tasks in the old schedule must be adjusted, which should remain unchanged, and how to reassign necessary tasks without disrupting the existing stability plan.

[0003] Current emergency dispatching processes typically focus on disaster risk calculation, rescue resource allocation, or re-evaluating the overall dispatching plan under new road network and resource conditions. While this approach can provide risk assessments or new schedules, it doesn't necessarily create a closed loop of "current change – affected tasks – local adjustments." Especially when existing tasks are already completed, in progress, or have a stable schedule, overall re-optimization may alter teams and timelines that wouldn't otherwise require change.

[0004] This invention addresses landslide emergency response processes where disaster monitoring, road conditions, or rescue resources continue to change after initial work orders and schedules have been created. The core of this invention is not to create a new global schedule, but to determine the minimum scope of tasks that are actually affected by the changes, retain the original arrangements for the remaining tasks, and only reschedule resources for tasks that must be adjusted. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention aims to provide a method and system for incremental updating of landslide emergency work orders and resource rescheduling. It adopts a continuous processing chain of "old state preservation - change structuring - minimum impact identification - task three-classification - frozen occupancy registration - local rescheduling - merge verification - version tracking" to convert changes in risk or resource status into executable and traceable local scheduling actions. This solves the problems of existing processes being prone to recalculating all tasks, irrelevant tasks being modified without cause, and the difficulty in verifying the reasons for adjustments.

[0006] To achieve the above objectives, the present invention may adopt the following specific technical solutions: On the one hand, this invention provides a method for incremental updating of landslide emergency work orders and resource rescheduling, including the following steps: S1. Obtain a snapshot of the system before the update and a working copy; S2. Compare the update input with the corresponding objects in the snapshot to generate structured change events; S3. Keep the system snapshot before the update read in step S1 unchanged, and write the changes generated in step S2 into the working copy. S4. Identify the directly affected objects based on the type of the change event and the target object; S5. Propagate the impact along the dependencies between observations, risk results, and emergency work orders, identify the set of affected work orders, and determine the potential resource conflict neighboring tasks that do not intersect with the set of affected work orders based on the candidate resource range of the affected work orders and the updated pre-schedule. S6. Based on the set of affected work orders, the task execution status in the work copy, and the type of security event, all work orders in the updated work copy are mutually exclusively divided into frozen tasks, tasks that can be rescheduled, and tasks that require manual confirmation. S7. Read the pre-update schedule of frozen tasks, manually confirmed tasks, and adjacent tasks with potential resource conflicts, register the original occupation time of their teams and equipment as unoccupiable intervals, and register the reachability status and passable time of the original routes as route constraints. S8. Perform partial rescheduling on the tasks that can be rescheduled in the preset task order, and use the resource occupation of frozen tasks, manually confirmed tasks and adjacent tasks with potential resource conflicts as read-only constraints. After determining the partial schedule of each work order, update the occupation range of the corresponding teams and equipment, and determine whether a feasible partial schedule result is obtained. S9. If no feasible local scheduling result is obtained, output the unscheduled list, conflict reasons, and manual confirmation request. S10. When a feasible local scheduling result is obtained, merge and verify it and generate a new version.

[0007] Furthermore, in step S1, the snapshot includes at least observations, risk results, work orders, teams, equipment, road status, and schedules, and records the snapshot number, save time, status version, and schedule version; the system snapshot read is used as the sole comparison benchmark for this incremental update, and subsequent processing is performed on the working copy.

[0008] Furthermore, in step S2, a change event is generated that includes event type, target number, occurrence time, old field value, new value, and reason; it supports adding observations, updating observations, expanding the scope, road closures, changes in travel time, team unavailability, and equipment unavailability.

[0009] Furthermore, in step S3, when an observation changes, the observation status and revision number are updated, and the risk results and emergency work orders associated with the observation are also updated; when a road changes, road accessibility or travel time is updated; when a team or equipment changes, the availability status of the corresponding resources is updated. This step outputs an updated working copy, which serves as the data basis for subsequent impact analysis.

[0010] Furthermore, in step S4, when observations are added, updated, or the landslide area expands, the corresponding observations and their associated risk results are listed as directly affected objects; when roads are closed or traffic hours change, schedules using that road or located in the relevant area are listed as directly affected objects; when a team is unavailable, work orders originally assigned to that team but not yet completed are listed as directly affected objects; when equipment is unavailable, work orders requiring that equipment but not yet completed are listed as directly affected objects; the directly affected set D is output. e And for each of these objects, record the direct cause of the impact.

[0011] Furthermore, in step S5, the direct changes are propagated downstream along the dependency relationship of "observation—risk outcome—emergency work order—required skills and equipment—allocated teams—scheduled time," forming a propagation impact set P. e Let W - For the previous work order set, W + This is a collection of work orders updated from the work copy. For adding a new set of work orders, This means finding the work orders involved in this change from the object set X, including existing work orders and work orders found based on observations, risk results, schedules, and the correspondence between resources and work orders; Affected work order collection Based on the candidate resource scope of the affected work orders and the pre-update schedule, select those work orders from the pre-update work order set that do not belong to A. e Within the work order, determine the potential resource conflict neighbor set N e ,in, and N e Tasks in the queue are not treated as tasks to be reordered; their original resource usage is only used as a read-only constraint for local scheduling. Tasks currently being executed that are directly affected by security incidents are included in A as associated work orders. e ,satisfy .

[0012] Furthermore, in step S6, all work orders in the updated work copy are used as the classification scope. Completed tasks, canceled tasks, unaffected pending tasks, and ongoing tasks not directly affected by security incidents are classified into the frozen set; affected pending tasks and newly added pending tasks are classified into the allowed reordering set; and ongoing tasks that are directly affected by road inaccessibility, loss of contact with the original team, or similar security incidents are classified into the manual confirmation set. The frozen tasks, reordered tasks, and manually confirmed tasks are mutually exclusive and cover all work orders in the updated work copy. Each work order must and can only be classified into one of these categories.

[0013] Further, in step S7, the team and equipment occupancy time of frozen tasks, manually confirmed tasks, and tasks adjacent to potential resource conflicts are registered as unoccupiable intervals, and the route reachability status and passable time periods are registered as route constraints; in step S8, allowed rescheduling tasks are processed in order of priority from high to low, completion deadline from early to late, and work order number from small to large. Candidate teams that violate hard constraints of team availability, skill matching, equipment availability, or road reachability are first screened out, and then the earliest departure time, start time, and completion time of the team and equipment occupancy intervals that do not conflict with the route passable time periods are calculated; after determining the local schedule of a work order, the occupancy intervals of the corresponding teams and equipment are updated, and then the next work order is processed; when all allowed rescheduling tasks have obtained feasible candidate solutions, it is determined that a feasible local schedule result has been obtained; otherwise, it is determined that a feasible local schedule result has not been obtained.

[0014] Further, after completing the partial rescheduling in step S8, it is determined whether a feasible partial scheduling result has been obtained. If not, step S9 is executed, and work orders without feasible candidate solutions are written into the unscheduled list. The specific reasons for team unavailability, insufficient skills, missing equipment, unreachable roads, team time slot conflicts, or equipment time slot conflicts are output. The original schedule must not be kept unchanged to replace the result of the partial rescheduling failure, nor should it automatically enter the full rescheduling. If a result is obtained, step S10 is executed, and the partial schedule is merged with the frozen schedule and the manually confirmed task schedule. It is checked whether the team, equipment, route, departure time, start time, and completion time of the frozen task and the manually confirmed task remain unchanged. The merged schedule is then checked for unique allocation, non-overlapping team and equipment times, skill and equipment matching, route reachability, frozen status, and task integrity. After successful verification, a new system snapshot and incremental update results are saved. If verification fails, the reason for the conflict and a manual confirmation request are output. A full reordering is not performed automatically. Only after receiving user confirmation is a separate full reordering process allowed.

[0015] On the other hand, the present invention provides a landslide emergency work order incremental update and resource rescheduling system for executing the above-mentioned landslide emergency work order incremental update and resource rescheduling method, including: The status snapshot module is used to input observations, risks, work orders, teams, equipment, roads, and schedules since the initial run or the last update, and generate a system snapshot with a unique number, save time, and version number. The Change Events module is used to input the object before and after the update, compare them field by field, and generate structured change events. The impact analysis module is used to input change events, dependencies, and pre-update schedules, extract related work orders from direct and propagated impacts, merge new work orders to form a set of affected work orders, and identify potential resource conflict neighboring tasks as read-only constraints. The task classification module is used to input the set of affected work orders, the task status in the work copy, and the security event flags. It mutually excludes all work orders in the updated work copy into three categories: frozen, allowed to be reordered, and manually confirmed, and outputs the classification reason. The frozen resource registration module is used to input the original schedule of frozen tasks, manually confirmed tasks, and tasks adjacent to potential resource conflicts. It registers the time occupied by teams and equipment as unoccupiable intervals, registers the route reachability status and passable time periods as route constraints, and provides read-only constraints to the local scheduler. The local rescheduling module is used to input allowed rescheduling tasks, adjacent tasks with potential resource conflicts, current time, resource status, road status, and frozen occupancy. It performs hard constraint filtering, candidate time slot calculation, lexicographical selection, and resource occupancy update according to the preset task order, and determines whether a feasible local scheduling result is obtained. If a feasible local scheduling result is obtained, it outputs the local schedule to the scheduling merging and verification module. If a local schedule is not obtained, it outputs the unscheduled list, conflict reasons, and manual confirmation request. The scheduling merging and verification module takes frozen schedules, manually confirmed task schedules, and partial schedules as inputs, and performs unique allocation, team and equipment time non-overlapping, skill and equipment matching, route reachability, frozen status, and task integrity verification; it prevents automatic full rescheduling when it fails. The version and result output module takes the merged schedule after input validation, generates a new snapshot of the incremental version, the update result number, and the differences before and after the update, for web page display and subsequent updates.

[0016] Compared with the prior art, the present invention has the following advantages: (1) Use the saved old schedule as the comparison benchmark, rather than regenerating a schedule based solely on the new risk or resource status, so that the objects, reasons and versions before and after the update can correspond.

[0017] (2) Extract affected work orders and merge new work orders by direct influence and propagation influence, while treating adjacent tasks with potential resource conflicts as read-only constraints, and clearly distinguishing between adjustable work orders and adjacent tasks that only provide resource occupation.

[0018] (3) By freezing all work orders after the update, allowing reordering and manual confirmation, and registering team and equipment occupancy, new work orders can be included in the reordering scope, and completed, ongoing and unaffected tasks will not be arbitrarily adjusted.

[0019] (4) The scheduling object is strictly limited to the set that is allowed to be rearranged. The adjacent tasks with potential resource conflicts are only used as read-only occupancy constraints, which is different from the repeated global or rolling optimization of all tasks after each change.

[0020] (5) By fixing the task processing order, hard constraint filtering, candidate time slot calculation and lexicographical comparison, the same input can produce repeatable results and avoid multiple rearranged work orders occupying the same team or equipment time slot repeatedly.

[0021] (6) Local update boundary is proved by merging verification and manual confirmation of gate; if local is not feasible, it is not silently downgraded to full rearrangement.

[0022] These distinctions together form a continuous technology chain, with each link serving the goal of "updating only the affected parts and keeping the rest of the arrangements stable," rather than simply listing risk assessment, resource allocation, or general dynamic scheduling side by side. Attached Figure Description

[0023] Figure 1 This is a flowchart of the incremental update and resource rescheduling method of the present invention; Figure 2 This is the initial full process before the update of this invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0025] The essential difference between the technical solution of this application and existing technologies lies in the following: First, a structured change event is formed using the snapshot before the update as a comparison benchmark; then, affected work orders are extracted from direct and propagated impacts and newly added work orders are merged, while identifying potential conflicting adjacent tasks that only provide resource occupancy; subsequently, all work orders in the updated working copy are classified into three categories; the local scheduler only adjusts tasks that are allowed to be reordered, and finally, the tasks are merged and verified. Therefore, whether to proceed with reordering and which tasks to reorder are not directly determined by global rolling optimization or natural language judgment.

[0026] Example 1

[0027] like Figure 1 As shown in the figure, this embodiment provides a method for incremental updating of landslide emergency work orders and resource rescheduling. Details are as follows: (a) S1. Get the state before the update.

[0028] like Figure 2 As shown, this is the process of generating risk results and emergency work orders from landslide observations during the first run, reading rescue resources and generating an initial schedule, and then saving a snapshot before the update.

[0029] Landslide monitoring records include observation number, time, area, hazard type, confidence level, range, status, and revision number; risk results record the source observation and level; emergency work orders record the source observation, status, priority, completion deadline, operation duration, and skill and equipment requirements; rescue teams record status, skills, equipment, location, and earliest available time; scheduling items record the task, team, route, departure, start and finish times, freeze marker, and scheduling version.

[0030] Update event logs by including event number, event type, target object, occurrence time, old and new values ​​of changed fields, and reasons; save system snapshots of observations, risks, work orders, teams, equipment, roads, and schedules for a single run; save impact analysis results by including direct impact, propagation impact, conflict proximity impact, unaffected tasks, and reasons for each item; save incremental results by including changed tasks, frozen tasks, manually confirmed tasks, unscheduled tasks, verification results, and new versions.

[0031] Read the saved system snapshot. The snapshot must contain at least observations, risk results, work orders, teams, equipment, road status, and schedules, and record the snapshot number, save time, status version, and schedule version. The same work orders and schedules can be restored from JSON after closing the program. This step uses the read system snapshot as the sole comparison benchmark for this incremental update. Subsequent processing is performed on the working copy, without modifying the snapshot before the update, to ensure that objects, statuses, and schedules before and after the update can be compared item by item. The output is the system snapshot before the update and its working copy.

[0032] (ii) S2. Compare the update input with the corresponding objects in the snapshot and generate structured change events.

[0033] The system generates change events that include event type, target number, occurrence time, old field value, new value, and reason. It supports adding observations, updating observations, expanding the scope, road closures, changes in travel time, team unavailability, and equipment unavailability.

[0034] (iii) S3, Update working copy.

[0035] Keeping the pre-update system snapshot read in step S1 unchanged, write the changes generated in step S2 into the working copy. When an observation changes, update the observation status and revision number, and update the risk results and emergency work orders associated with that observation; when roads change, update road accessibility or travel time; when teams or equipment change, update the availability status of the corresponding resources. This step outputs the updated system working copy, which serves as the data basis for subsequent impact analysis.

[0036] (iv) S4. Determine the directly affected objects based on the type of the change event and the target object.

[0037] When new observations are added, observations are updated, or the landslide area expands, the corresponding observations and their associated risk results are listed as directly affected objects; when roads are closed or access times change, schedules using that road or located in the relevant area are listed as directly affected objects; when teams are unavailable, work orders originally assigned to that team but not yet completed are listed as directly affected objects; when equipment is unavailable, work orders requiring that equipment but not yet completed are listed as directly affected objects, and the direct impact reason is recorded for each of these objects. Let e ​​be the event of this change, and D... e The set of objects directly determined by this change event.

[0038] (v) S5, Propagate the impact and identify resource conflict proximity tasks.

[0039] Following the dependency relationship of "observation—risk outcome—emergency work order—required skills and equipment—allocated teams—scheduled time," the direct changes propagate to downstream objects, forming a propagation impact set P. e Based on the skills and equipment requirements of the affected work orders, determine the range of candidate resources, and include those work orders from the previous set that do not belong to A. e However, tasks occupying the same candidate team or candidate equipment are added to the potential resource conflict neighbor set N. e N e satisfy and N e The tasks in the list are not treated as tasks to be reordered, and their original resource usage is only used as a read-only constraint for local scheduling.

[0040] Let W - For the previous work order set, W + This is a collection of work orders updated from the work copy. This is a collection of newly added work orders; This indicates identifying the work orders affected by this change from the object set X, including existing work orders and those found based on observations, risk results, scheduling, and the correspondence between resources and work orders. The affected work order set is formed according to equation (1). : (1) Output direct impact, propagation impact, affected work orders, potential resource conflicts in adjacent tasks, unaffected objects, and the reasons for each impact.

[0041] (vi) S6. Classify the work orders in the work copy into three categories.

[0042] Based on the affected work order set A e The task execution status and security event type in the working copy will mutually exclude all work orders in the updated working copy into frozen tasks, tasks that can be rescheduled, and tasks that require manual confirmation.

[0043] Completed tasks, cancelled tasks, unaffected pending tasks, and ongoing tasks not directly affected by security incidents are placed in the frozen set; affected pending tasks and newly added pending tasks are placed in the allowed reordering set; ongoing tasks directly affected by road inaccessibility, loss of contact with the original team, or similar security incidents are placed in the manual confirmation set.

[0044] The three types of tasks are determined according to equations (2) to (5) and cover all work orders in the updated work copy. Each work order must belong to one and only one of the three types, and the reason for the classification is recorded.

[0045] Output frozen set F e The set R that allows rearrangement e and the set of manual confirmations M e Potential resource conflict neighborhood set N e Not classified as a fourth type of task, which does not belong to category A. e The tasks should maintain their original categories and schedules.

[0046] Let W + This is the collection of all work orders in the updated work copy. , , and These are sets of work orders: pending, in progress, completed, and cancelled. Each set is pairwise disjoint and their union is W. + ; This represents the set of work orders currently in execution that are directly affected by the security incident. These work orders are included as associated work orders in steps S4 and S5. ,satisfy ; i represents a work order.

[0047] Allowed reordering of sets and manual confirmation set Determine according to equations (2) and (3) respectively: (2) (3) Frozen Collection This includes tasks that are completed, cancelled, or have not yet received manual confirmation, as well as pending tasks that have not yet been included in the set allowed for reordering: (4) Here, "\" represents the set difference operation. Based on the above mutual exclusion of state sets... The conditions are that the three types of tasks are mutually exclusive and cover W. + : (5)

[0048] (vii) S7. Register and freeze resource occupation.

[0049] Read the pre-update schedules of frozen tasks, manually confirmed tasks, and tasks adjacent to potential resource conflicts, register the original occupancy time of their teams and equipment as unoccupiable intervals, and register the reachability status and passable time periods of the original routes as route constraints. The original teams, equipment, routes, departure times, start times, and completion times of frozen tasks and manually confirmed tasks cannot be modified by the local scheduler; tasks adjacent to potential resource conflicts maintain their original schedules, and their original resource occupancy is only used as read-only constraints. This step forms the team occupancy set and equipment occupancy set used in formula (7).

[0050] Taking the slope treatment task in a road closure scenario as an example, the event occurs at time t. e The time limit is 0.5 hours. After classification in step S6, slope treatment tasks are placed into the allowable rearrangement set, while other unaffected tasks and completed tasks are placed into the frozen set.

[0051] The system reads the pre-update schedule of frozen tasks and adjacent tasks with potential resource conflicts and retains their team and equipment occupancy. The occupancy ranges of the candidate debris flow disposal teams and their required equipment do not conflict with the time slots to be arranged for the slope disposal tasks, and the corresponding routes are passable during the journey. Therefore, this candidate scheme can be included in the subsequent time slot calculation.

[0052] (viii) S8, Perform local rescheduling.

[0053] The local scheduler only generates new schedules for work orders in the set that are allowed to be rescheduled; the original resource occupancy of frozen tasks, manually confirmed tasks, and adjacent tasks with potential resource conflicts is entered in read-only constraint mode and is not considered as objects to be rescheduled.

[0054] For each work order to be rescheduled, the candidate teams are first checked according to Equation (6) to see if they meet the static hard constraints such as team availability, skill matching, availability of required equipment, and road accessibility. Only candidate teams with zero violations of hard constraints are included in the candidate time slot calculation.

[0055] Tasks can be reordered in descending order of priority, from earliest to latest completion deadline, and from smallest to largest work order number. The earliest departure time, start time, and completion time that simultaneously satisfy the time constraints of the team, equipment, and route are calculated according to equations (7) and (8); the weighted delay is calculated according to equation (9); and lexicographical selection is performed according to equations (10) and (11). After the scheduling of a work order is determined, its occupied interval is immediately added to the occupied set of the corresponding team and equipment before processing the next work order.

[0056] Let I represent the constraint indicator, which takes the value 0 or 1. The indicator is set to 1 when a candidate team is unavailable, skills do not match, required equipment is unavailable, or the road is unreachable; otherwise, it is set to 0. The number of static hard constraint violations when work order i is assigned to team k is: (6) Where i represents the work order number and k represents the candidate team number; This represents the number of static hard constraints that are not satisfied when work order i is assigned to team k. This indicates that a queue is unavailable; it is set to 1 if queue k is unavailable, and 0 otherwise. This indicates a skill mismatch with the instruction quantity. The value is 1 if the skill of team k does not meet the requirements of work order i, and 0 otherwise. This indicates a missing equipment indication; a value of 1 is used when the equipment required to execute work order i is missing, and a value of 0 is used otherwise. This indicates the road is unreachable. It is set to 1 if team k cannot reach the work location of work order i by passing through the road, and 0 otherwise. This indicates that all four conditions above are met. Only H... ik Candidate time slots are only calculated when the value is 0. Let... The time when the event occurred. For the earliest available time for the team, For travel time, For the duration of the assignment; For the area occupied by teams and equipment, This refers to the route's travel section; and Let each be a registered occupied set for team k and device g, respectively. For the required equipment set, For the route Given the set of passable times, the earliest departure time is: (7) (8) Among them, s ik and f ik Let b be the start and finish times, respectively. i For the completion deadline, q i For priority weights that are not less than 1 and whose larger values ​​indicate higher priority, the weighted deferral is: (9) set up and The candidate comparison vector is defined as follows: (This is the original team and the original start time, respectively.) (10) For new work orders, the candidate comparison vector includes items representing team changes. The term representing the offset from the start time. All values ​​are set to 0 directly, without using the original team and original start time in the calculation; all other items are still calculated according to the original definition.

[0057] definition To meet Furthermore, equation (7) has a finite set of candidate teams. The vectors are compared lexicographically from left to right; the next index is compared only if the previous index is the same. If empty, then add work order i to the unscheduled list: (11) In the aforementioned road closure scenario, the original disaster relief team was unable to access the area due to road inaccessibility. The on-site inspection team was hampered by insufficient skills and equipment. Only mudslide response teams The earliest available time for debris flow response teams is a k 0 hours, local trip The duration is 0.25 hours, and the operation time is p. i It takes 2 hours.

[0058] Since the time zone occupied by the team and the required equipment does not conflict with the planned time period, and the corresponding route is passable during the trip, the earliest departure time is 0.5 hours according to equation (7), and the start time is 0.75 hours and the completion time is 2.75 hours according to equation (8). Completion deadline b i 8 hours, priority weight q i The weighted delay L is 60, and from equation (9) we obtain L. ik It is 0.

[0059] After comparing Equations (10) and (11), the debris flow disposal team was selected as the local rearrangement result for the slope disposal task. The system outputs the team, corresponding equipment and route, and records the earliest departure time of 0.5 hours, start time of 0.75 hours, completion time of 2.75 hours and the reason for reassignment; at the same time, it records the reasons for removal such as the original geological disaster comprehensive team being unable to reach the road or the field inspection team not meeting the skill and equipment requirements.

[0060] After completing the above processing, the system determines whether a feasible local scheduling result has been obtained. If all allowed rescheduling tasks have feasible candidate solutions, step S10 is executed; if at least one allowed rescheduling task has no feasible candidate solution, step S9 is executed.

[0061] (ix) S9. Output the unscheduled list, conflict reasons and manual confirmation requests.

[0062] When step S8 determines that no feasible local scheduling result has been obtained, for work orders that do not have candidate solutions that meet the hard constraints, they are added to the unscheduled list, and specific reasons such as team unavailability, insufficient skills, missing equipment, inaccessible roads, or conflicting time periods are output. At the same time, a manual confirmation request is generated. This step must not replace the result of local rescheduling failure with "keeping the original schedule unchanged", nor should it automatically switch to full rescheduling.

[0063] (x) S10. Merge and verify and generate a new version.

[0064] The local schedule is merged with the frozen schedule and the manually confirmed task schedule according to formula (12), and the teams, equipment, routes, departure times, start times and completion times of the frozen tasks and manually confirmed tasks are checked according to formula (13) to ensure they remain unchanged. The merged schedule is checked for unique allocation, non-overlapping team and equipment times, skill and equipment matching, route reachability, frozen status, and task integrity. The schedule version is incremented according to formula (14). After the check passes, a new system snapshot and incremental update results are saved. If the check fails, the cause of the conflict and the manual confirmation request are output, and a full rescheduling is not performed automatically.

[0065] Let r represent the scheduling version. The merging of partial scheduling, frozen scheduling, and manually confirmed task scheduling, as well as the invariant constraints of frozen tasks and manually confirmed tasks, are as follows: (12) Where r represents the previous schedule version number. This indicates the updated schedule version number. The value in the superscript parentheses represents the version, not the exponentiation. This indicates the updated merged schedule; This indicates that the task schedule was frozen in the previous version. This indicates the schedule for manual confirmation tasks in the previous version. This indicates that the schedule formed by this partial rescheduling of tasks is allowed to be rearranged.

[0066] (13) Where i represents the work order number and e represents the current change event; Indicates the set of frozen tasks. This represents the set of tasks requiring manual confirmation. For work order i, Indicates the assigned team. Represents the set of devices to be allocated. Indicates the execution route. Indicates the departure time. Indicates the start time of the operation. Indicates the time when the task is completed. The superscript 'r' for each symbol and... These represent the corresponding content before and after the update, respectively. This formula indicates that the teams, equipment, routes, and schedules for frozen tasks and manually confirmed tasks remain unchanged in this automatic partial rescheduling.

[0067] (14) in, This indicates the previous schedule version number. This indicates the schedule version number after a successful update. After the merged schedule passes verification and is saved, the version number is increased by 1 from the original version number.

[0068] Example 2

[0069] This embodiment provides a landslide emergency work order incremental update and resource rescheduling system for executing the landslide emergency work order incremental update and resource rescheduling method of Embodiment 1. The system includes: a status snapshot module, a change event module, an impact analysis module, a task classification module, a frozen resource registration module, a local rescheduling module, a schedule merging and verification module, and a version and result output module.

[0070] The status snapshot module is used to input the observations, risks, work orders, teams, equipment, roads, and schedules after the initial run or the last update, generate a system snapshot with a unique number, save time, and version number, and restore the status after the program restarts; corresponding to steps S1 and S10 of Embodiment 1.

[0071] The change event module is used to input the object before and after the update, compare each field, and generate structured change events; corresponding to steps S2 and S3 in Embodiment 1.

[0072] The impact analysis module is used to input change events, dependencies, and pre-update schedules, extract affected work orders from direct and propagated impacts, and identify potential resource conflict neighboring tasks that do not intersect with the set of affected work orders and only provide read-only resource occupancy; corresponding to steps S4 and S5 of Implementation Example 1.

[0073] The task classification module is used to input the set of influences, task status, and security event markers, and to classify tasks into three mutually exclusive categories: frozen, allowed to be rearranged, and manually confirmed, and output the classification reason; corresponding to step S6 of embodiment 1.

[0074] The frozen resource registration module is used to input the original schedule of frozen tasks, manually confirmed tasks, and tasks adjacent to potential resource conflicts, register the time occupied by teams and equipment as unoccupiable intervals, register the route reachability status and passable time periods as route constraints, and provide read-only constraints to the local scheduler; corresponding to step S7 of embodiment 1.

[0075] The local rescheduling module is used to input allowed rescheduling tasks, adjacent tasks with potential resource conflicts, current time, resource status, road status, and read-only occupancy. It performs hard constraint filtering, candidate time slot calculation, lexicographical order selection, and resource occupancy update according to the preset task order, and determines whether a feasible local scheduling result is obtained. If a feasible local scheduling result is obtained, it outputs the local schedule to the scheduling merging and verification module. If a local schedule is not obtained, it outputs the unscheduled list, conflict reasons, and manual confirmation request. This corresponds to steps S8 and S9 in Embodiment 1.

[0076] The scheduling merging and verification module is used to input frozen schedules, manually confirmed task schedules, and partial schedules, and to perform unique allocation, team and equipment time non-overlap, skill and equipment matching, route reachability, frozen status, and task integrity verification; it prevents automatic full rescheduling when it fails; corresponding to step S10 of embodiment 1.

[0077] The version and result output module is used to input the merged schedule after verification, generate a new snapshot of the incremental version, update result number and differences before and after the update, for web page display and subsequent updates; corresponding to step S10 of embodiment 1.

[0078] The local rescheduling in this application uses the allowed rescheduling set as the adjustment boundary and the resource usage of frozen tasks, manually confirmed tasks, and adjacent tasks with potential resource conflicts as read-only constraints. If changes cause large-scale road unreachability, insufficient available resources, or local results that fail consistency checks, the system only outputs unscheduled tasks, conflict reasons, and manual confirmation requests, without disguising the full rescheduling results as incremental results.

[0079] Example 3

[0080] This embodiment addresses local rescheduling triggered by road closures and is based on Embodiments 1 and 2.

[0081] This embodiment fully corresponds to steps S1 to S10, focusing on the impact identification, task classification, frozen resource registration, candidate team screening, local rescheduling, and merging verification processes in steps S4 to S10. The relevant numerical calculations are explained in steps S7 and S8 of Embodiment 1.

[0082] The previous status included slope treatment tasks, patrol tasks, completed treatment tasks, and special equipment tasks, as well as the geological disaster comprehensive team, debris flow treatment team, and on-site patrol team. Road AB between Area A and Area B was originally open. Slope treatment tasks were carried out by the geological disaster comprehensive team via road AB to Area B; other tasks did not use this road. The system saves the above observations, work orders, teams, roads, and the first version of the schedule as a snapshot.

[0083] A road closure event occurred 0.5 hours relative to the baseline. The impact analysis module only lists slope treatment tasks that use the road but have not yet been executed as directly affected tasks; patrol tasks and dedicated equipment tasks that do not use the road, as well as completed treatment tasks, are not included in the reordering set. After classification, slope treatment tasks can be reordered, while the other three are frozen. The local scheduler retains the frozen resource occupancy, excludes the original teams that are inaccessible by the road and the on-site patrol teams whose skills and equipment do not meet the requirements, and reassigns the tasks to debris flow treatment teams located in area B that meet the constraints.

[0084] Table 1: Comparison of Task Scheduling and Handling Results Before and After Road Closure Events

[0085] As shown in Table 1 above, the merged verification confirmed that only the slope treatment task changed, while the teams and times for the other tasks remained unchanged; there were no duplicate assignments, overlapping team times, skill and equipment mismatches, or modifications to frozen tasks. The scheduling version was increased from version 1 to version 2, and the system did not perform a full rescheduling.

[0086] Example 4

[0087] This embodiment is for situations where rescue teams are unavailable and is implemented based on Embodiments 1 and 2.

[0088] This embodiment fully corresponds to steps S1 to S10, with a focus on step S2 generating a team unavailable event, step S3 updating the team status, step S4 determining the original work order, step S5 judging adjacent tasks with resource conflicts, step S6 completing task classification, and steps S7 to S10 completing freezing, reassignment, failure handling, and merging verification.

[0089] When a team becomes unavailable, the system searches for work orders originally assigned to that team that have not yet been completed. Unexecuted work orders are added to the set allowed for rescheduling; work orders currently being executed and directly affected by the security incident are added to the set requiring manual confirmation and are not automatically modified by the local scheduler. The system identifies potential resource-conflicting tasks in proximity to candidate teams and equipment based on their original resource occupancy, and treats their original resource occupancy as read-only constraints. Completed tasks and unaffected tasks retain their original schedules. For work orders allowed for rescheduling, if a feasible alternative exists, the rescheduling result is output; if no feasible alternative exists, it is added to the unscheduled list along with the reason for the conflict. Maintaining the original schedule does not guarantee a successful rescheduling.

[0090] Example 5

[0091] This embodiment is designed for new observations or expansion of landslide areas and is based on Embodiments 1 and 2.

[0092] This embodiment fully corresponds to steps S1 to S10, with a focus on step S2 generating new observations or expanded scope events, step S3 updating observations and associated risks and work orders, steps S4 and S5 propagating the impact along dependencies, step S6 determining whether task rescheduling is allowed, and steps S8 to S10 completing new work order arrangements or partial adjustments to associated work orders.

[0093] When a new high-risk observation is added, the system creates a new observation, associates the risk result, and creates a new work order in the working copy. This new work order belongs to W. new And enter the affected work order set A through equation (1). e Since its state is pending execution, it enters the allowed rearrangement set R according to equation (2). e Other areas that do not belong to A e Work orders remain frozen; adjacent tasks with potential resource conflicts maintain their original schedules, providing only the original resource occupancy as a read-only constraint. When the landslide area expands, the system updates the range and revision number of the same observation and recalculates the associated risk results; the associated work orders then enter A. e The priorities and completion deadlines in the original schedule are used as the benchmark for comparison.

[0094] Example 6

[0095] This embodiment focuses on webpage operations and repeatable verification, and is based on Embodiments 1 and 2.

[0096] This embodiment corresponds to the overall implementation of steps S1 to S10 in the system. The web interface sequentially completes the following steps: reading the snapshot before the update, submitting change events, impact analysis, task classification, partial rescheduling, and displaying the results before and after the update. The backend completes frozen resource registration, partial scheduling, merge verification, and saving the new version. This embodiment demonstrates that the above steps can be executed continuously by the system without adding additional independent scheduling rules.

[0097] The web interface first performs an initial analysis on the input images, generating work orders and an initial schedule, and then creates a snapshot by "saving and locking the above results as the original schedule." Next, a change type is selected and an update is performed. The page displays affected tasks, tasks with the original schedule maintained, unscheduled tasks, and the teams and approximate completion times before and after the adjustment. Rescheduling always uses the same initial result that was just locked, without mixing in other images or historical snapshots.

[0098] The prototype uses a fixed JSON input to cover four scenarios: newly added high-risk observations, expanded scope, road closures, and team unavailability. It verifies change detection, impact propagation, three-class classification, local scheduling, merged verification, and state recovery. This verification demonstrates that the process can be repeated; it does not claim any accuracy in identification, scheduling efficiency, or actual rescue effectiveness that has not been verified with real engineering data.

[0099] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for incremental updating and resource rescheduling of landslide emergency work orders, characterized in that, Includes the following steps: S1. Obtain a snapshot of the system before the update and a working copy; S2. Compare the update input with the corresponding objects in the snapshot to generate structured change events; S3. Keep the system snapshot before the update read in step S1 unchanged, and write the changes generated in step S2 into the working copy. S4. Identify the directly affected objects based on the type of the change event and the target object; S5. Propagate the impact along the dependencies between observations, risk results, and emergency work orders, identify the set of affected work orders, and determine the potential resource conflict neighboring tasks that do not intersect with the set of affected work orders based on the candidate resource range of the affected work orders and the updated pre-schedule. S6. Based on the set of affected work orders, the task execution status in the work copy, and the type of security event, all work orders in the updated work copy are mutually exclusively divided into frozen tasks, tasks that can be rescheduled, and tasks that require manual confirmation. S7. Read the pre-update schedule of frozen tasks, manually confirmed tasks, and adjacent tasks with potential resource conflicts, register the original occupation time of teams and equipment as unoccupiable intervals, and register the reachability status and passable time of the original routes as route constraints. S8. Perform partial rescheduling on the tasks that can be rescheduled in the preset task order, and use the resource occupation of frozen tasks, manually confirmed tasks and adjacent tasks with potential resource conflicts as read-only constraints. After determining the partial schedule of each work order, update the occupation range of the corresponding teams and equipment, and determine whether a feasible partial schedule result is obtained. S9. If no feasible local scheduling result is obtained, output the unscheduled list, conflict reasons, and manual confirmation request. S10. When a feasible local scheduling result is obtained, merge and verify it and generate a new version.

2. The landslide emergency work order incremental update and resource rescheduling method according to claim 1, characterized in that, In step S1, the snapshot includes at least observations, risk results, work orders, teams, equipment, road status, and schedules, and records the snapshot number, save time, status version, and schedule version; the system snapshot read is used as the sole comparison benchmark for this incremental update, and all subsequent processing is performed on the working copy.

3. The landslide emergency work order incremental update and resource rescheduling method according to claim 1, characterized in that, In step S2, a change event is generated that includes event type, target number, occurrence time, old field value, new value, and reason; it supports adding observations, updating observations, expanding the scope, road closure, change of passage time, team unavailability, and equipment unavailability.

4. The landslide emergency work order incremental update and resource rescheduling method according to claim 1, characterized in that, In step S3, when an observation changes, the observation status and revision number are updated, and the risk results and emergency work orders associated with the observation are updated; when a road changes, road accessibility or travel time is updated; when a team or equipment changes, the availability status of the corresponding resources is updated; this step outputs an updated working copy as the data basis for subsequent impact analysis.

5. The landslide emergency work order incremental update and resource rescheduling method according to claim 1, characterized in that, In step S4, when new observations are added, observations are updated, or the landslide area expands, the corresponding observations and their associated risk results are listed as directly affected objects; when roads are closed or traffic hours change, schedules using that road or located in the relevant area are listed as directly affected objects; when a team is unavailable, work orders originally assigned to that team but not yet completed are listed as directly affected objects; when equipment is unavailable, work orders requiring that equipment but not yet completed are listed as directly affected objects; the directly affected set D is output. e And for each of these objects, record the direct cause of the impact.

6. The landslide emergency work order incremental update and resource rescheduling method according to claim 1, characterized in that, In step S5, the direct changes are propagated downstream along the dependency relationship of "observation—risk outcome—emergency work order—required skills and equipment—allocated teams—scheduled time," forming a propagation impact set P. e Let W - For the previous work order set, W + This is a collection of work orders updated from the work copy. For adding a new set of work orders, This means finding the work orders involved in this change from the object set X, including existing work orders and work orders found based on observations, risk results, schedules, and the correspondence between resources and work orders; Affected work order collection Based on the candidate resource scope of the affected work orders and the pre-update schedule, select those work orders from the pre-update work order set that do not belong to A. e Within the work order, determine the potential resource conflict neighbor set N e ,in, and N e Tasks in the queue are not treated as tasks to be reordered; their original resource usage is only used as a read-only constraint for local scheduling. Tasks currently being executed that are directly affected by security incidents are included in A as associated work orders. e ,satisfy .

7. The landslide emergency work order incremental update and resource rescheduling method according to claim 1, characterized in that, In step S6, all work orders in the updated work copy are used as the classification scope. Completed tasks, canceled tasks, unaffected pending tasks, and tasks in execution that are not directly affected by security events are classified into the frozen set; affected and pending tasks and newly added pending tasks are classified into the allowed reordering set. Tasks that are currently being performed and are directly affected by road inaccessibility, loss of contact with the original team, or similar safety incidents are categorized into the manual confirmation set. The frozen tasks, reordered tasks, and manually confirmed tasks are mutually exclusive and cover all work orders in the updated work copy. Each work order must and can only be classified into one of these categories.

8. The landslide emergency work order incremental update and resource rescheduling method according to claim 1, characterized in that, In step S7, the team and equipment occupancy time of frozen tasks, manually confirmed tasks, and tasks adjacent to potential resource conflicts are registered as unoccupiable intervals, and the route reachability status and passable time periods are registered as route constraints. In step S8, tasks that can be rescheduled are processed in order of priority from high to low, completion deadline from early to late, and work order number from small to large. Candidate teams that violate hard constraints of team availability, skill matching, equipment availability, or road reachability are first screened out. Then, the earliest departure time, start time, and completion time of the team and equipment that do not conflict with the team and equipment occupancy intervals and meet the route passable time periods are calculated. After determining the local schedule of a work order, the occupancy intervals of the corresponding teams and equipment are updated, and then the next work order is processed. When all tasks that can be rescheduled have obtained feasible candidate solutions, it is determined that a feasible local schedule result has been obtained; otherwise, it is determined that a feasible local schedule result has not been obtained.

9. The landslide emergency work order incremental update and resource rescheduling method according to claim 8, characterized in that, After completing the partial rescheduling in step S8, determine whether a feasible partial scheduling result has been obtained. If not, proceed to step S9, write the work orders for which no feasible candidate solutions exist into the unscheduled list, and output the specific reasons for team unavailability, insufficient skills, missing equipment, unreachable roads, team time slot conflicts, or equipment time slot conflicts. The original schedule must not be kept unchanged to replace the result of the partial rescheduling failure, nor should it automatically enter a full rescheduling. If a result has been obtained, proceed to step S10, merge the partial schedule with the frozen schedule and the manually confirmed task schedule, check whether the team, equipment, route, departure time, start time, and completion time of the frozen task and the manually confirmed task remain unchanged, and perform unique allocation, team and equipment time non-overlap, skill and equipment matching, route reachability, frozen unchanged, and task integrity verification on the merged schedule. After successful verification, a new system snapshot and incremental update results are saved. If verification fails, the reason for the conflict and a manual confirmation request are output. A full reordering is not performed automatically. Only after receiving user confirmation is a separate full reordering process allowed.

10. A landslide emergency work order incremental update and resource rescheduling system, used to execute the method described in any one of claims 1-9, characterized in that, include: The status snapshot module is used to input observations, risks, work orders, teams, equipment, roads, and schedules since the initial run or the last update, and generate a system snapshot with a unique number, save time, and version number. The Change Events module is used to input the object before and after the update, compare them field by field, and generate structured change events. The impact analysis module is used to input change events, dependencies, and pre-update schedules, extract related work orders from direct and propagated impacts, merge new work orders to form a set of affected work orders, and identify potential resource conflict neighboring tasks as read-only constraints. The task classification module is used to input the set of affected work orders, the task status in the work copy, and the security event flags. It mutually excludes all work orders in the updated work copy into three categories: frozen, allowed to be reordered, and manually confirmed, and outputs the classification reason. The frozen resource registration module is used to input the original schedule of frozen tasks, manually confirmed tasks, and tasks adjacent to potential resource conflicts. It registers the time occupied by teams and equipment as unoccupiable intervals, registers the route reachability status and passable time periods as route constraints, and provides read-only constraints to the local scheduler. The local rescheduling module is used to input allowed rescheduling tasks, adjacent tasks with potential resource conflicts, current time, resource status, road status, and frozen occupancy. It performs hard constraint filtering, candidate time slot calculation, lexicographical order selection, and resource occupancy update according to the preset task order, and determines whether a feasible local scheduling result is obtained. If a feasible local scheduling result is obtained, it outputs the local schedule to the scheduling merging and verification module. If a local schedule is not obtained, it outputs the unscheduled list, conflict reasons, and manual confirmation request. The scheduling merging and verification module takes frozen schedules, manually confirmed task schedules, and partial schedules as inputs, and performs unique allocation, team and equipment time non-overlapping, skill and equipment matching, route reachability, frozen status, and task integrity verification; it prevents automatic full rescheduling when it fails. The version and result output module takes the merged schedule after input verification, generates a new snapshot of the incremental version, the update result number, and the differences before and after the update, for web page display and subsequent updates.

Images