A self-organizing task offloading disaster pre-rehearsal method and system

Abstract

The present application relates to the technical field of task shunting disaster recovery pre-play scheme design, and specifically relates to a self-organizing task shunting disaster recovery pre-play method and system. The method comprises: setting a pre-play area, a disaster recovery level and a corresponding temporary storage area in a robot control system; in response to an area alarm, automatically identifying related tasks; based on predetermined rules, self-organizing a task processing strategy according to the task type and the disaster recovery level, including path diversion or redistribution to the temporary storage area; executing shunting in a simulation environment and dynamically changing the number of tasks and AGVs to test the system limit; and finally generating pre-play data for evaluating system performance. The corresponding system contains functional modules for implementing the above steps. The present application solves the problem of lack of automatic disaster recovery pre-play capability in the prior art, can expose system bottlenecks in advance, and provides data support for optimizing scheduling strategies and improving system resilience.

Description

Technical Field

[0001] This invention relates to the field of task diversion disaster recovery simulation design technology, specifically to a self-organizing task diversion disaster recovery simulation method and system. Background Technology

[0002] In modern intelligent warehousing and logistics centers, Robotic Control Systems (RCS) are responsible for scheduling and managing a large number of Automated Guided Vehicles (AGVs) to complete material handling tasks. These systems are typically able to efficiently handle path planning, task allocation, and traffic management in daily processes. However, when sudden emergencies occur in specific areas within the factory, such as safety incidents like leaks or spills caused by equipment malfunctions, existing conventional RCS systems reveal significant limitations. Traditional responses often rely on manual intervention, such as operators manually pausing new tasks destined for the affected area or attempting to reassign target points to the affected AGVs. This approach is not only slow to respond but also prone to exacerbating chaos in emergency situations due to human error or panic.

[0003] Existing technologies lack automated, proactive rehearsal and response plans for such emergencies. Specifically, conventional RCS systems do not include rehearsal functions for one-click road closures or one-click task diversion in emergency situations. When an area needs to be urgently closed, the system cannot automatically and promptly intelligently divert tasks already assigned to or passing through that area. For example, for material tasks about to enter a hazardous area, the system cannot automatically guide them to a safe storage area based on the material characteristics; for tasks needing to be transported out of a hazardous area, the system also struggles to quickly adjust their priority and path to prevent AGVs from entering dangerous zones. This lack of capability means that in a real disaster recovery scenario, assigned tasks may continue to be executed and enter hazardous areas, causing property damage or even casualties. Furthermore, task backlogs and path conflicts can trigger wider traffic congestion and system paralysis, severely impacting the overall operational continuity of the factory.

[0004] Furthermore, due to a lack of simulation capabilities, managers are unable to assess the resilience of existing system architecture and processes before actual disaster recovery occurs. They cannot answer critical questions such as, "Can the current buffer capacity withstand a sudden blockade in a specific area?" and "Under what workload will the system reach a critical point of collapse?" This uncertainty renders disaster recovery plan development data-unsupported, relying solely on empirical estimates, making it difficult to optimize resource allocation and emergency procedures, and failing to provide reliable decision-making basis for potential cascading effects. Therefore, there is an urgent need in this field for a pre-simulation scheme capable of self-organizing task allocation and providing quantitative assessment data for disaster recovery response.

[0005] Therefore, existing technologies still need further development. Summary of the Invention

[0006] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide a self-organizing task diversion disaster recovery rehearsal method and system to solve the problems existing in the prior art.

[0007] To achieve the above-mentioned technical objectives, according to a first aspect of the present invention, the present invention provides a self-organizing task offloading disaster recovery pre-drill method, comprising:

[0008] S1. Set up a pre-play area, a disaster recovery level, and allocate corresponding temporary storage areas for different pre-play areas and disaster recovery levels in the robot control system RCS.

[0009] S2. In response to an alarm trigger signal for a pre-rehearsal area, the RCS system automatically identifies tasks in the current task queue that are related to the alarm pre-rehearsal area.

[0010] S3. For the relevant tasks, based on their task type and the disaster recovery level corresponding to the alarm simulation area, a task processing strategy is determined in an autonomous manner according to predetermined rules. The task processing strategy includes rerouting the task path to the periphery or reallocating it to the corresponding temporary storage area.

[0011] S4. Based on the task processing strategy, perform task diversion in the simulation environment and dynamically simulate the changes in the number of tasks and the number of execution devices; Step S5: Based on the simulation execution results, generate pre-simulation data for evaluating the system performance in disaster recovery scenarios.

[0012] Specifically, in step S1, the basis for setting the disaster recovery level includes the characteristics of the material.

[0013] Specifically, in step S1, corresponding temporary storage areas are allocated for different disaster recovery levels, so that materials with different characteristics are guided to different temporary storage areas during disaster recovery simulation.

[0014] Specifically, in step S2, identifying the task related to the alarm rehearsal area includes: determining whether the task is a task sent into the alarm rehearsal area or a task sent out from the alarm rehearsal area.

[0015] Specifically, in step S3, the predetermined rules include: for tasks sent into the alarm rehearsal area, allocating them to the corresponding level of temporary storage area according to the disaster recovery level of their associated materials; for tasks sent out from the alarm rehearsal area, reducing their task priority.

[0016] Specifically, in step S3, for tasks sent from the alarm pre-drill area, the task processing strategy prioritizes recalculating and planning a path for the task that does not pass through the alarm pre-drill area.

[0017] Specifically, in step S3, if an alternative path cannot be planned for a task sent from the alarm rehearsal area, the task is assigned to a temporary storage area.

[0018] Specifically, in step S4, the changes in the number of tasks and the number of execution devices are dynamically simulated until the simulated system reaches a deadlock state or resource limit; the pre-simulation data generated in step S5 includes the maximum number of tasks that the system can handle before reaching a deadlock state and a list of system adjustment suggestions.

[0019] According to a second aspect of the present invention, a self-organizing task offloading disaster recovery rehearsal system is provided, comprising:

[0020] The configuration module is used to set the pre-rehearsal area, disaster recovery level, and allocate corresponding temporary storage areas for different pre-rehearsal areas and disaster recovery levels.

[0021] The task identification module is used to automatically identify tasks in the current task queue that are related to the alarm pre-rehearsal area in response to an alarm trigger signal for a pre-rehearsal area.

[0022] The decision module is used to determine the task processing strategy for the relevant task based on the task type and the disaster recovery level corresponding to the alarm simulation area, according to predetermined rules. The task processing strategy includes rerouting the task path to the periphery or reallocating it to the corresponding temporary storage area.

[0023] The simulation execution module is used to perform task distribution in a simulation environment based on the task processing strategy, and dynamically simulate changes in the number of tasks and the number of execution devices;

[0024] The data generation module is used to generate pre-simulation data based on the simulation results to evaluate the system's performance in disaster recovery scenarios.

[0025] Specifically, the system is embedded in the RCS system in the form of functional modules.

[0026] Beneficial effects:

[0027] The self-organizing task diversion disaster recovery simulation scheme provided by this invention brings significant benefits in many aspects compared with the existing technology.

[0028] First, the most significant benefit of this invention lies in transforming disaster recovery response from a passive, experience-driven approach to a proactive, data-driven pre-emptive exercise. By implementing this solution within an enterprise, various emergency scenarios can be simulated in a virtual environment before a real disaster occurs, thereby exposing potential bottlenecks in the system under extreme pressure, such as insufficient temporary storage capacity and critical path congestion. This proactive testing allows managers to optimize warehouse layout, adjust temporary storage settings, and improve scheduling strategies, significantly enhancing the resilience and reliability of the entire AGV scheduling system and providing valuable "rehearsal" opportunities and data support for potential real crises.

[0029] Secondly, this invention achieves intelligent and automated disaster recovery response. By introducing a three-in-one configuration system of "pre-simulation area division," "material disaster recovery level division," and "corresponding temporary storage area setting," combined with a clear set of self-organizing decision-making rules, the system can automatically identify, classify, and triage affected tasks without human intervention after a simulated alarm is triggered. This automated processing not only simulates extremely fast emergency response speed, avoiding delays and errors that may be caused by human intervention, but more importantly, it performs differentiated processing based on material characteristics, simulating the key isolation of high-risk materials and the priority protection of important materials, reflecting the refinement and scientific nature of emergency management.

[0030] Finally, the simulation data generated by this invention has extremely high decision support value. The solution dynamically simulates changes in task volume and the number of AGVs until the system reaches its limits, generating a detailed assessment report. This report includes the maximum task volume the system could handle before crashing, identification of key bottlenecks, and a list of specific system adjustment recommendations. This quantitative data provides warehouse managers with intuitive and reliable evidence for strategic decision-making, such as demonstrating the necessity of expanding temporary storage areas, optimizing the AGV fleet size, or revising emergency response procedures. Ultimately, this achieves the core objectives of optimizing resource utilization, reducing potential economic losses in disaster recovery scenarios, and ensuring personnel safety. Attached Figure Description

[0031] Figure 1 This is a flowchart illustrating the self-organizing task diversion disaster recovery rehearsal method provided in a specific embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of the system composition of the self-organizing task diversion disaster recovery simulation system provided in a specific embodiment of the present invention. Detailed Implementation

[0033] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Based on the embodiments in this application, other similar embodiments obtained by those skilled in the art without creative effort should all fall within the scope of protection of this application. Furthermore, directional terms mentioned in the following embodiments, such as "up," "down," "left," and "right," are only for reference to the directions in the accompanying drawings; therefore, the directional terms used are for illustrative purposes and not for limiting the invention.

[0034] The present invention will be further described below with reference to the accompanying drawings and preferred embodiments.

[0035] Please see Figure 1 This invention provides a self-organizing task offloading disaster recovery rehearsal method, comprising:

[0036] S1: Set up the pre-play area, disaster recovery level, and allocate corresponding temporary storage areas for different pre-play areas and disaster recovery levels in the robot control system RCS;

[0037] Further, step S1 is the basic data configuration phase. Implementers use the graphical interface or data configuration interface provided by the RCS system to delineate one or more rehearsal areas on the factory map. These areas typically correspond to physical functional areas in the actual warehouse, such as storage areas, picking areas, or aisles. Disaster recovery levels are set based on the physical or chemical properties of the materials. For example, flammable, explosive, or toxic materials are defined as the highest disaster recovery level (e.g., Level 1), high-value or fragile materials are defined as secondary levels (e.g., Level 2), and ordinary materials are defined as general levels (e.g., Level 3). Subsequently, for each rehearsal area and each potentially triggered disaster recovery level, one or more temporary storage areas are designated on the periphery or in the safe zone of the factory map. These temporary storage areas act as temporary storage points during the rehearsal.

[0038] It should be further explained that, in specific implementation, step S1 is the basic data configuration stage, completed through the management interface of the RCS system. The pre-simulation area is defined using a sequence of polygon vertices in the coordinate system of the factory's two-dimensional or three-dimensional map. For example, a rectangular area can be defined by the coordinates of four vertices (X1, Y1), (X2, Y2), (X3, Y3), and (X4, Y4). The disaster recovery level is preferably set to three levels: Level_1 (high risk), Level_2 (important), and Level_3 (normal). The temporary storage area is also defined by coordinate polygons and is bound to the pre-simulation area and disaster recovery level, forming a series of binding relationship rules, which are stored in the contingency_plan_table in the system database. Its structure can be: plan_id, zone_id, disaster_level, staging_area_id.

[0039] Step S2: In response to an alarm trigger signal for a rehearsal area, the RCS system automatically identifies tasks in the current task queue that are related to the alarm rehearsal area;

[0040] Furthermore, step S2 is the disaster recovery triggering phase. When the operator simulates triggering an alarm in a certain pre-rehearsal area (such as "running, leaking, dripping") through the interface, the RCS system will immediately scan all issued but incomplete tasks. By comparing the coordinates of the task's starting point, waypoints, and ending point with the range of the alarm area, it will quickly identify all "related tasks".

[0041] It should be further explained that in step S2, the alarm trigger signal is a system event containing the unique identifier zone_id of the alarm pre-rehearsal area. Upon receiving this event, the RCS system immediately scans the task queue. The task data model includes fields such as task_id, start_point, end_point, path_waypoints[], and material_id. The system uses computational geometry algorithms (such as ray casting) to determine whether the task's end_point is located within the alarm area; if so, it is "sent in task"; it also determines whether any point in the start_point or path_waypoints is located within the alarm area; if so, it is "sent out task". This judgment process is event-driven, meaning that once an alarm is triggered, the scan is completed within less than 100 milliseconds.

[0042] Step S3: For the relevant tasks, based on their task type and the disaster recovery level corresponding to the alarm simulation area, a task processing strategy is determined in an self-organizing manner according to predetermined rules. The task processing strategy includes rerouting the task path to the periphery or reallocating it to the corresponding temporary storage area.

[0043] It should be further explained that step S3 is the core decision-making stage. The system performs self-organizing decisions based on a preset rule set, without manual intervention. The "preset rules" are a set of IF-THEN rules with clearly defined priorities, executed by the rule engine. For example: RULE_1: IF Task type == "Send In" THEN queries the disaster_level corresponding to material_id and redirects the task target point to the center point of the corresponding staging_area_id in contingency_plan_table. RULE_2: IF Task type == "Send Out" THEN first attempts path replanning; if it fails, RULE_1 is applied.

[0044] Step S4: Based on the task processing strategy, perform task splitting in the simulation environment and dynamically simulate changes in the number of tasks and the number of execution devices;

[0045] It should be further explained that step S4 is the simulation operation phase. This phase runs in a simulator isolated from the real RCS scheduling environment. System behavior is observed by gradually increasing the number of simulated tasks and the number of AGVs (Automated Guided Vehicles) participating in the simulation. The simulation execution in step S4 is carried out in a discrete event simulator. The simulation clock t advances in seconds. Dynamic simulation is achieved by setting a task generator with an adjustable generation rate λ (tasks / minute), preferably initially set to 80% of the system's normal load, then increasing by 10% every 5 minutes of simulation until the system deadlocks. The number of AGVs, N_agv, can also be dynamically adjusted to simulate AGV failure or reinforcement scenarios.

[0046] Step S5: Based on the simulation results, generate pre-simulation data to evaluate the system's performance in disaster recovery scenarios;

[0047] Furthermore, step S5 is the result output stage, where the system records data from the moment an alarm is triggered until the system is unable to process new tasks due to a full temporary storage area or traffic deadlock. Its beneficial effect lies in transforming the disaster recovery response process from passive response to proactive simulation. Through a complete and automated simulation process, the resilience and processing capacity of the AGV scheduling system can be systematically assessed and optimized before an actual disaster occurs, providing crucial data support for management decisions and effectively reducing potential losses.

[0048] It should be further explained that in step S5, the simulation data includes key performance indicators (KPIs). The system records the following for each time point t: number of active tasks N_active(t), staging area occupancy O_staging(t), average AGV utilization U_agv(t), task completion rate, etc. The simulation stops when the system deadlocks (defined as no tasks completing for more than 60 seconds) or O_staging(t) reaches 100%. The final report will identify the critical path points or resource bottlenecks that caused the deadlock.

[0049] Understandably, by using highly specific steps and algorithms, the disaster recovery response process is transformed from a conceptual pre-evolution into a quantifiable and repeatable simulation test, providing an accurate benchmark for evaluating system resilience.

[0050] Specifically, in step S1, the basis for setting the disaster recovery level includes the characteristics of the material.

[0051] Furthermore, this invention imposes important limitations on the criteria for setting disaster recovery levels. In specific implementation, the characteristics of materials are the core indicator for classifying disaster recovery levels. For example, a material characteristic database can be established, which includes attributes such as the material's hazardous classification (e.g., according to the Globally Harmonized System of Classification and Labelling of Chemicals, GHS), value, and sensitivity to temperature and humidity. The system automatically or manually assigns a disaster recovery level to each type of material based on these attributes. A preferred implementation is to set the disaster recovery levels to three levels: Level 1 corresponds to high-risk materials (such as flammable materials and oxidizers), Level 2 corresponds to important materials (such as precision electronic components and high-value goods), and Level 3 corresponds to ordinary materials (such as packaging materials and ordinary parts). The beneficial effect of this classification is that it achieves differentiated and refined disaster recovery management. It ensures that the most appropriate handling strategy is adopted for materials with different characteristics during the simulation, avoiding the secondary risk simulation that may be caused by the mixing of high-risk materials and ordinary materials during simulated evacuation or temporary storage. At the same time, it also ensures that high-value materials are given priority and properly handled in the simulation, thereby making the simulation results closer to the needs of real scenarios and improving the effectiveness and guiding significance of the simulation.

[0052] It should be further explained that, in specific implementation, a MaterialProperty Matrix needs to be established to quantify the abstract "characteristics" into computable attributes. The rows of this matrix are material IDs, and the columns are characteristic dimensions. A preferred implementation includes the following characteristic dimensions and their quantification methods:

[0053] ① Flammability: Classified into values ​​1-5 based on flash point, where 1 is non-flammable and 5 is extremely flammable.

[0054] ②Toxicity: Classified into values ​​1-5 based on LD50 dose.

[0055] ③ Value density: The value of a unit volume of material (yuan / cubic meter), normalized to a scale of 1-10.

[0056] ④ Environmental sensitivity: The degree of sensitivity to temperature / humidity, 1 is insensitive and 5 is highly sensitive.

[0057] Then, a weighted scoring algorithm is used to calculate the overall disaster recovery score S_d for each material:

[0058]

[0059] Wherein, P_flammable represents the flammability score of the material, P_toxic represents the toxicity score of the material, P_value represents the value density score of the material, and P_sensitivity represents the environmental sensitivity score of the material. w_1, w_2, w_3, and w_4 are weighting coefficients, satisfying w_1 + w_2 + w_3 + w_4 = 1. Preferably, the weights are w_1 = 0.4, w_2 = 0.3, w_3 = 0.2, and w_4 = 0.1 to prioritize safety risks. The rationale for selecting these weights is the safety-first principle, placing characteristics related to personnel and environmental safety in a more important position.

[0060] Finally, disaster recovery levels are determined based on the score range of S_d: S_d∈[0,3) is Level_3, [3,7) is Level_2, and [7,10] is Level_1. The rationale for this optimal range is to ensure that the number of tasks for the three levels roughly follows a normal distribution, preventing a level from having too few tasks and thus losing the significance of the rehearsal. Understandably, the beneficial effects of this scheme include transforming disaster recovery level classification from subjective judgment to objective, traceable, data-driven decision-making, greatly improving the scientific rigor and consistency of the rehearsal.

[0061] Specifically, in step S1, corresponding temporary storage areas are allocated for different disaster recovery levels, so that materials with different characteristics are guided to different temporary storage areas during disaster recovery simulation.

[0062] Furthermore, this invention further refines the allocation principles of temporary storage areas. In specific implementation, for different disaster recovery levels classified in step S1, physically isolated dedicated temporary storage areas need to be configured for them. For example, the temporary storage area allocated for Level 1 disaster recovery level (high-risk materials) should be located at the edge of the factory, in a well-ventilated location, and far away from other important facilities; the temporary storage area allocated for Level 2 disaster recovery level (important materials) should have better safety monitoring and environmental control conditions (such as constant temperature and humidity); the temporary storage area for Level 3 disaster recovery level (ordinary materials) can be relatively ordinary. In the map configuration of the simulation system, these temporary storage areas are marked as accepting tasks only for specific disaster recovery levels. Its beneficial effect is to achieve risk isolation and targeted protection. By physically isolating materials of different levels, the risk of dangerous goods diffusion can be simulated in the simulation, and the storage safety of important materials can be ensured. This design allows the simulation not only to test traffic flow but also to evaluate the effectiveness of warehouse safety management strategies in emergency situations, providing a more comprehensive data foundation for developing realistic disaster recovery plans.

[0063] It should be further noted that, in specific implementation, the selection of temporary storage areas must meet the physical requirements of a specific disaster recovery level. The system maintains a Staging Area Table, which includes fields such as area_id, location, safety_level, and environment_control. Safety_level is a comprehensive indicator calculated based on the distance of the area from densely populated areas, exits, and fire-fighting facilities, with a value ranging from 1 to 5, where 5 is the safest. Environment_control is a Boolean value indicating whether temperature and humidity control is in place.

[0064] Furthermore, the allocation algorithm follows the best-match principle. When selecting a temporary storage region A for disaster recovery level L, a matching score function MatchScore(L, A) is defined:

[0065]

[0066] in, It is an indicator function; its value is 1 when the disaster recovery level L is 1, and 0 otherwise. This represents the security level of temporary storage area A; It is an indicator function; its value is 1 when the disaster recovery level L is 2, and 0 otherwise. This represents the environmental control level of temporary storage area A (1 for control, 0 for no control). It is an indicator function; its value is 1 when the disaster recovery level L is 3, and 0 otherwise. This represents the normalized distance from temporary storage area A to the alarm area (the farther the distance, the higher the score).

[0067] For each (zone_id, disaster_level) combination, the system selects the available temporary storage area with the highest MatchScore for binding. Understandably, the benefits of this approach include intelligent resource allocation, ensuring that high-risk materials are always guided to the safest areas, and important materials are guided to areas where their quality can be guaranteed, thereby maximizing the simulation and minimizing secondary risks and asset losses during rehearsals.

[0068] Specifically, in step S2, identifying the task related to the alarm rehearsal area includes: determining whether the task is a task sent into the alarm rehearsal area or a task sent out from the alarm rehearsal area.

[0069] Furthermore, this invention clarifies the specific scope of "related tasks." When an alarm is triggered, the RCS system traverses the task queue and performs the following judgments on each task: First, it checks whether the preset target point coordinates of the task are within the geometric range of the alarm pre-rehearsal area. If so, the task is determined to be an "incoming task." Second, it checks whether the starting point or current execution position of the task is within the alarm pre-rehearsal area. If so, the task is determined to be an "outgoing task." In addition, for tasks that need to pass through (cross) the alarm area in the path planning, the system will also identify them as related tasks because their original path is no longer available.

[0070] It should be further explained that, in the specific implementation, the judgment logic is implemented through a function called TaskClassifier. The pseudocode of this function is as follows:

[0071] "FUNCTION TaskClassifier(task T, alarm_zone Z):

[0072] / / Determine if it is an incoming task

[0073] IF IsPointInsidePolygon(T.end_point, Z.polygon) == TRUE:

[0074] T.type = "INBOUND"

[0075] RETURN T

[0076] / / Determine if it is a delivery task

[0077] IF IsPointInsidePolygon(T.start_point, Z.polygon) == TRUE:

[0078] T.type = "OUTBOUND"

[0079] RETURN T

[0080] / / Determine if the path point passes through the alarm area

[0081] FOR waypoint IN T.path_waypoints:

[0082] IF IsPointInsidePolygon(waypoint, Z.polygon) == TRUE:

[0083] T.type = "OUTBOUND" / / Passing tasks are treated as outgoing tasks

[0084] RETURN T

[0085] / / If none of the above applies, then the task is unrelated to the alarm.

[0086] T.type = "UNAFFECTED"

[0087] RETURN T

[0088] END FUNCTION.

[0089] The IsPointInsidePolygon function is implemented using the classic ray casting method, with a time complexity of O(n), where n is the number of sides of the polygon, which is sufficient to meet real-time requirements. Understandably, the beneficial effects of the above scheme include providing clear and unambiguous task classification criteria, laying a precise data foundation for subsequent task allocation decisions, and ensuring the rigor of the pre-draft logic.

[0090] Specifically, in step S3, the predetermined rules include: for tasks sent into the alarm rehearsal area, allocating them to the corresponding level of temporary storage area according to the disaster recovery level of their associated materials; for tasks sent out from the alarm rehearsal area, reducing their task priority.

[0091] Furthermore, this invention defines core decision-making rules. In specific implementation, the predetermined rules are logic codes pre-written in the RCS simulation module. For "inbound tasks," the system queries the disaster recovery level of the materials transported by the task and then directly modifies the target point of the task from the address within the original alarm area to an idle storage location within the pre-configured temporary storage area for that disaster recovery level. For "outbound tasks," the system accesses the task scheduling queue and lowers the priority value of the task, for example, by changing its priority flag from a higher value (such as "high" or "5") to a lower value (such as "low" or "1"). This means that in subsequent AGV scheduling, these tasks will be arranged to be executed after new tasks or high-priority tasks in non-disaster recovery areas. Its beneficial effect is that it realizes rapid and automated emergency response simulation. Through rule-based processing, the system can instantly replan a large number of affected tasks, simulating emergency principles such as "no entry" and "internal task postponement." This prioritizes the normal operation of unaffected areas, simulates how to maintain the continuity of overall operations to the greatest extent, and provides a clear way out for tasks in dangerous areas.

[0092] It should be further explained that, in practice, the application of these rules involves specific data operations. For the "send task," the system performs the following operations:

[0093] 1. Extract material_id from task T.

[0094] 2. Query the material database to obtain the disaster_level.

[0095] 3. Query the contingency_plan_table to find the staging_area_id that is bound to the alarm area and this disaster recovery level.

[0096] 4. Modify the end_point of task T to the entry coordinates (x_s, y_s) of this temporary storage area. At the same time, set a flag T.is_rerouted=True in the task data.

[0097] For "send-out tasks," priority reduction is achieved by modifying the task's priority value P. The system initially assigns a base priority P_base to each task (e.g., 1-10, with 10 being the highest). The algorithm for reducing priority is as follows:

[0098]

[0099] Where P_new represents the new priority of the task, P_base represents the original priority of the task, and ΔP is the magnitude of the priority reduction. Preferably, ΔP is 3. The reason for choosing this value is that it is sufficient to reduce high-priority tasks (e.g., P=10) to medium priority (P=7), allowing them to give way to urgent tasks in other areas, but it does not drop them directly to the lowest priority (P=1) and completely halt their progress, thus balancing response speed and task completion requirements. The system also records the original priority of the task to assess the impact during pre-analysis.

[0100] Understandably, the beneficial effects of the above approach include translating strategies into precise, executable instructions, ensuring the consistency and predictability of the system's self-organizing behavior.

[0101] Specifically, in step S3, for tasks sent from the alarm pre-drill area, the task processing strategy prioritizes recalculating and planning a path for the task that does not pass through the alarm pre-drill area.

[0102] Furthermore, this invention optimizes the processing strategy for "sending out tasks." In specific implementation, when the system identifies a "sending out task," it does not directly lower its priority and wait, but first initiates a path replanning algorithm. This algorithm takes the task's current position as the starting point and the original destination as the ending point, and sets the alarm pre-simulation area as the path search algorithm (e.g., A). The algorithm (or Dijkstra's algorithm) identifies obstacles. The system attempts to find a feasible path around the obstacle. If such a path is found, the task's objective remains unchanged, but its path is updated, and the task priority can remain the same or be slightly reduced. Its beneficial effect lies in simulating minimizing the disruption to task execution caused by disaster recovery events. By prioritizing rerouting attempts, materials that could otherwise be transported from the hazardous area can continue their journey instead of being indefinitely delayed. This simulates strategies for completing tasks and minimizing the loss of materials en route in actual disaster recovery, improving the economic evaluation value of the simulation plan and making the simulation results more reflective of the optimal emergency dispatch level.

[0103] It should be further explained that, in specific implementation, path replanning adopts an improved A... Algorithm. First, the polygon of the alarm area Z is expanded outward by a certain safety distance d_safe (preferably 1.5 meters, based on the physical size of the AGV and safety margin), generating an expanded obstacle polygon Z_obstacle. Then, in the path planning map (usually a grid map or navigation grid), all nodes within Z_obstacle are marked as impassable.

[0104] The replanning algorithm starts at the current position (current_pos) of the task and ends at the original destination (old_end_point), performing an A search. In the evaluation function of the A search algorithm, f(n) = g(n) + h(n), g(n) represents the actual cost from the starting point to node n, and h(n) represents the estimated cost from node n to the destination (usually using Manhattan distance or Euclidean distance). Once a path avoiding the Z-obstacle is found, the path is smoothed using the Floyd algorithm or simple spline interpolation to reduce sharp turns during AGV operation.

[0105] If A If the algorithm fails to find a path within a reasonable timeframe (e.g., when the number of search nodes exceeds 10,000), it is deemed "unable to plan an alternative path." Understandably, the beneficial effects of the above approach include simulating the most economical contingency strategy with minimal operational impact—that is, maintaining the original task objective while only changing the path—providing better solution data for simulations.

[0106] Specifically, in step S3, if an alternative path cannot be planned for a task sent from the alarm rehearsal area, the task is assigned to a temporary storage area.

[0107] Furthermore, a backup plan is specified when the rerouting strategy fails. In practice, the path replanning algorithm may fail to find a feasible alternative path due to factory layout constraints (such as the alarm area being located on a single passage). In this case, the system will execute a degradation strategy: treating this "sent-out task" as an "incoming task." That is, the system will allocate a temporary storage area for the task (preferably selecting a temporary storage area corresponding to its material disaster recovery level, or selecting a public emergency temporary storage area), and modify the task's target point to this temporary storage area. Simultaneously, the task's priority will be significantly reduced. Its beneficial effect is ensuring the completeness and robustness of the simulation system. It simulates the worst-case scenario (complete road blockage), namely "on-site storage" or "transfer to a safe area." This ensures that all affected tasks receive a clear and executable solution during the simulation, avoiding task "hanging" or logical errors during the simulation process, allowing the simulation to proceed to the end, thereby assessing the system capacity and bottlenecks under extreme conditions.

[0108] It should be further explained that, in practice, the logic of this downgrade strategy is as follows:

[0109] IF TaskClassifier(T, Z) == "OUTBOUND" THEN

[0110] IF PathReplanning(T, Z) == SUCCESS:

[0111] / / Keep the task objective point and update the path

[0112] T.path = new_path

[0113] ELSE: / / Path replanning failed

[0114] / / Temporarily convert this outgoing task to an incoming task, with the destination being the temporary storage area.

[0115] T.type = "INBOUND_FALLBACK"

[0116] / / Select a temporary storage area: Prioritize the area that matches the material disaster recovery level; otherwise, select the default temporary storage area.

[0117] target_staging_area = SelectStagingArea(Z, T.disaster_level) ORdefault_staging_area

[0118] T.end_point = target_staging_area.entry_point

[0119] / / At the same time, its priority is significantly reduced, and ΔP can be set to 5 to distinguish it.

[0120] T.priority = max(1, T.priority - 5)

[0121] END IF

[0122] END IF

[0123] Understandably, the beneficial effects of the above scheme include ensuring that the system has a definite response strategy in any extreme scenario, guaranteeing the integrity and robustness of the simulation process, and being able to test the system's performance under the most unfavorable conditions.

[0124] Specifically, in step S4, the changes in the number of tasks and the number of execution devices are dynamically simulated until the simulated system reaches a deadlock state or resource limit; the pre-simulation data generated in step S5 includes the maximum number of tasks that the system can handle before reaching a deadlock state and a list of system adjustment suggestions.

[0125] Furthermore, step S4 is a progressive stress test. After the initial alarms and task diversion stabilize, the system continuously injects new tasks into the simulation system (these new tasks may be partially affected by the alarm areas), and the number of AGVs participating in the simulation can be dynamically adjusted. The simulation continues until the system deadlocks (e.g., AGVs are blocked from moving) or critical resources are exhausted (e.g., all temporary storage areas are full). In step S5, the system generates a detailed pre-simulation report, whose core data includes: the time window from alarm triggering to system failure, the total number of tasks successfully processed during this period, the number and type of tasks that failed to be completed, the peak utilization rate of the temporary storage areas, and the distribution of traffic congestion points. Based on this data, the system can further generate a list of adjustment suggestions, such as: "It is recommended to increase the temporary storage capacity of area B by 20%" or "Adding a traffic control point at intersection X can alleviate congestion." Its beneficial effect is that it elevates the pre-simulation from qualitative analysis to quantitative decision support. It directly answers key questions such as "How long can my system last?" and "Where are the bottlenecks?", providing extremely specific, data-driven evidence for factories to optimize their layout, resource allocation, and disaster recovery plans, greatly enhancing the practical value of this invention.

[0126] It should be further noted that this invention clearly defines the boundaries and output content of the simulation. In specific implementation, the deadlock detection algorithm runs periodically (e.g., every 10 seconds). A deadlock state is defined as follows: within K consecutive detection cycles, the number of completed global tasks, C_completed, is zero, and all AGVs are in the "waiting" or "blocked" state. The preferred value of K is 6 (i.e., 60 seconds), which is sufficient to exclude brief traffic interruptions.

[0127] Furthermore, the system records the total number of tasks successfully completed between the alarm trigger time t_alarm and the deadlock time t_deadlock, denoted as Max Tasks Processed. This is a key indicator for evaluating system resilience.

[0128] Furthermore, the list of adjustment recommendations is generated based on bottleneck analysis during the rehearsal process. For example:

[0129] ① Staging area bottleneck: If the occupancy rate of a certain staging area reaches 100% first, it is recommended to "increase the capacity of staging_area_id to 120% of the current capacity".

[0130] ② Traffic bottleneck: If the system detects that the average speed of the AGV on a certain path P is consistently lower than the threshold V_congestion (preferred value is 0.2 m / s), it is recommended to "add a one-way traffic rule or optimize the scheduling algorithm at node N of path P".

[0131] Understandably, the beneficial effects of the above solution include elevating the output of the simulation from simple performance metrics to actionable intelligence, directly guiding the factory to make targeted infrastructure or software strategy improvements, and greatly enhancing the practical value of the present invention.

[0132] Please see Figure 2 The present invention provides another embodiment, which provides a self-organizing task diversion disaster recovery rehearsal system, the self-organizing task diversion disaster recovery rehearsal system comprising:

[0133] The configuration module 100 is used to set the pre-rehearsal area, disaster recovery level, and allocate corresponding temporary storage areas for different pre-rehearsal areas and disaster recovery levels.

[0134] Further explanation is needed regarding configuration module 100: it provides a RESTful API, such as POST / api / zones for creating rehearsal zones, and PUT / api / contingency-plans for binding disaster recovery levels and temporary storage zones. The front-end interface is built using the Vue.js framework and synchronizes map status with the back-end in real time via WebSocket.

[0135] Task identification module 200 is used to automatically identify tasks in the current task queue that are related to the alarm pre-rehearsal area in response to an alarm trigger signal for a pre-rehearsal area;

[0136] It should be further explained that the task identification module 200, as an event-driven service, subscribes to task status change events and alarm events in the RCS core. It uses an in-memory database (such as Redis) to cache task and region data to achieve millisecond-level event response and task classification.

[0137] The decision module 300 is used to determine the task processing strategy for the relevant task based on the task type and the disaster recovery level corresponding to the alarm simulation area, according to a predetermined rule. The task processing strategy includes rerouting the task path to the periphery or reallocating it to the corresponding temporary storage area.

[0138] It should be further explained that the decision module 300 embeds a lightweight rule engine, such as Drools, to execute the rules defined in this invention. This module receives classification results from the task identification module via a message queue (such as RabbitMQ) and outputs decision instructions.

[0139] The simulation execution module 400 is used to perform task splitting in a simulation environment based on the task processing strategy, and dynamically simulate changes in the number of tasks and the number of execution devices.

[0140] It should be further explained that the simulation execution module 400 is built based on existing discrete event simulation libraries (such as SimPy) or a self-developed simulation kernel. It receives decision instructions and advances the AGV's movement and task execution on a virtual timeline, while injecting simulated loads.

[0141] The data generation module 500 is used to generate pre-simulation data for evaluating the system's performance in disaster recovery scenarios based on the simulation execution results.

[0142] It should be further explained that regarding the data generation module 500: it connects to a time series database (such as Influx DB) to efficiently store simulation process data and uses Jupyter Notebook or a self-developed reporting engine to generate HTML format pre-simulation reports containing charts and KPIs.

[0143] Furthermore, service discovery and load balancing between modules are achieved through an API gateway. This provides a high-performance, highly available, and easily scalable system implementation solution, ensuring the stable operation of the simulation function in large-scale scenarios.

[0144] Specifically, the system is embedded in the RCS system in the form of functional modules.

[0145] It should be further noted that this invention defines the system deployment method. In specific implementation, "embedded" means deep integration. This is manifested in:

[0146] 1. Data layer embedding: The database of the simulation system is shared with the RCS main database, or a read-only copy and two-way data synchronization mechanism are established to ensure that the basic data such as simulation area and material attributes are completely consistent with the production environment.

[0147] 2. Interface Layer Embedding: The pre-drill system directly calls the SDKs of the PathPlanning Service, Map Service, and Task Service encapsulated within the RCS system, rather than through potentially limited external APIs. This ensures that the algorithms and logic used in the pre-drill are highly consistent with the real scheduling system.

[0148] 3. Presentation Layer Embedding: The user interface of the pre-launch system is developed as a single-page application (SPA) and then integrated into the unified portal of the RCS main management platform through iframes or Web Components technology to achieve single sign-on and a unified user experience.

[0149] 4. Deployment and Embedding: The various microservices of the pre-drill system are packaged together with other services of the RCS system using Docker containerization technology, and orchestrated and managed through a unified Kubernetes cluster, sharing monitoring, logs and network policies.

[0150] Understandably, it achieves seamless integration with the RCS system, avoiding the problem of "two separate systems". This ensures the accuracy of the pre-test and reduces the complexity of operation and maintenance, making this function a standard and reliable feature of the RCS system that users can use.

[0151] In a preferred embodiment, this application also provides an electronic device, the electronic device comprising:

[0152] The computer device includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, implement the self-organizing task offloading disaster recovery rehearsal method. The computer device can be broadly categorized as a server, terminal, or any other electronic device with the necessary computing and / or processing capabilities. In one embodiment, the computer device may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the computer device can be used to provide the necessary computing, processing, and / or control capabilities. The memory of the computer device may include non-volatile storage media and internal memory. The non-volatile storage media may store an operating system, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface and communication interface of the computer device can be used to connect and communicate with external devices via a network. When the computer program is executed by the processor, it performs the steps of the method of the present invention.

[0153] This invention can be implemented as a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the steps of the methods of embodiments of the invention to be performed. In one embodiment, the computer program is distributed across multiple network-coupled computer devices or processors, such that the computer program is stored, accessed, and executed in a distributed manner by one or more computer devices or processors. A single method step / operation, or two or more method steps / operations, may be executed by a single computer device or processor or by two or more computer devices or processors. One or more method steps / operations may be executed by one or more computer devices or processors, and one or more other method steps / operations may be executed by one or more other computer devices or processors. One or more computer devices or processors may execute a single method step / operation, or execute two or more method steps / operations.

[0154] Those skilled in the art will understand that the method steps of this invention can be performed by a computer program instructing related hardware, such as a computer device or processor, to perform the steps of this invention when executed. Depending on the context, any references herein to memory, storage, databases, or other media may include non-volatile and / or volatile memory. Examples of non-volatile memory include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, etc. Examples of volatile memory include random access memory (RAM), external cache memory, etc.

[0155] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0156] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A self-organizing task offloading disaster pre-play method, characterized in that, The method comprises the following steps: S1, setting a rehearsal area, a disaster recovery level and assigning corresponding temporary storage areas for different rehearsal areas and disaster recovery levels in a robot control system RCS; S2, in response to an alarm trigger signal for a rehearsal area, the RCS system automatically identifies tasks related to the alarm rehearsal area in the current task queue; S3, for the related tasks, according to the task type and the disaster recovery level corresponding to the alarm rehearsal area, a task processing strategy is determined based on predetermined rules, which includes diverting the task path to the periphery or reassigning it to the corresponding temporary storage area; S4, based on the task processing strategy, task shunting is performed in a simulated environment, and the changes in the number of tasks and the number of execution devices are dynamically simulated; S5, according to the simulation execution result, rehearsal data for evaluating the performance of the system under disaster recovery scenarios is generated; In step S1, the basis for setting the disaster recovery level includes the characteristics of the materials; In step S1, different temporary storage areas are assigned for different disaster recovery levels, so that materials of different characteristics are guided to different temporary storage areas during disaster recovery rehearsal; In step S2, identifying tasks related to the alarm rehearsal area includes determining whether the task is a task sent to the alarm rehearsal area or a task sent from the alarm rehearsal area; In step S3, the predetermined rules include: for tasks sent to the alarm rehearsal area, they are assigned to the corresponding level of temporary storage area according to the disaster recovery level of the associated materials; for tasks sent from the alarm rehearsal area, their task priority is reduced.

2. The self-organizing task offloading disaster pre-play method of claim 1, wherein, In step S3, for tasks sent from the alarm rehearsal area, the task processing strategy first tries to recalculate and plan a path that does not pass through the alarm rehearsal area.

3. The self-organizing task offloading disaster-prep method of claim 2, wherein, In step S3, if an alternative path cannot be planned for tasks sent from the alarm rehearsal area, the task is assigned to a temporary storage area.

4. The self-organizing task offloading drill-preparation method of claim 1, wherein, In step S4, the changes in the number of tasks and the number of execution devices are dynamically simulated until the simulation system reaches a deadlock state or a resource limit; the rehearsal data generated in step S5 includes the maximum number of tasks that the system can handle before reaching a deadlock state and a list of system adjustment suggestions.

5. A self-organizing task offloading disaster pre-play system applied to a robot control system (RCS), characterized in that, The self-organizing task shunting disaster recovery rehearsal method of any one of claims 1-4, the system comprises: A configuration module for setting a rehearsal area, a disaster recovery level and assigning corresponding temporary storage areas for different rehearsal areas and disaster recovery levels; A task identification module for automatically identifying tasks related to the alarm rehearsal area in the current task queue in response to an alarm trigger signal for a rehearsal area; A decision module for determining a task processing strategy based on predetermined rules for the related tasks according to their task type and the disaster recovery level corresponding to the alarm rehearsal area, which includes diverting the task path to the periphery or reassigning it to the corresponding temporary storage area; An analog execution module for performing task shunting in a simulated environment based on the task processing strategy and dynamically simulating changes in the number of tasks and the number of execution devices; A data generation module is configured to generate pre-play data for evaluating performance of the system under the disaster scenario according to the simulation execution result.

6. The self-organizing task offloading disaster recovery walk-through system of claim 5, wherein, The system is embedded in the RCS system in the form of a functional module.

Images