Rail transit emergency task multi-event fusion scheduling method

Abstract

This invention relates to the field of electronic digital data processing technology and discloses a multi-event fusion scheduling method for rail transit emergency tasks. The method includes: for multiple simultaneous rail emergency events, instantiating them into corresponding task branches using event templates, merging all task nodes and dependencies to form an initial candidate graph; performing feasibility predicate judgment on task nodes based on real-time collected context information of the rail system, removing infeasible nodes and their associated dependency edges to obtain a feasible task graph; identifying similar task nodes in different task branches using normalized keys, executing merging operators to eliminate redundancy, updating task nodes and dependencies; discovering cross-branch conflicts and coupling constraints, generating constraint relationships in the form of a hypergraph, outputting a minimum fully fused subgraph, and generating scheduling instructions based on this subgraph, which are then issued to the rail scheduling system as the optimal schedule. This method solves the problems of insufficient conflict detection and low scheduling efficiency, achieving the goals of task minimization and intelligent scheduling.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a multi-event fusion scheduling method for emergency tasks in rail transit. Background Technology

[0002] In emergency response for rail transit operations, multiple events (such as equipment failures, passenger accidents, and sudden environmental incidents) may occur simultaneously or close together, triggering multiple emergency response task chains. These task chains may encounter problems such as duplicate tasks, resource contention, execution order conflicts, and safety interlocks. Executing each event's task branch sequentially leads to: increased emergency response time due to task redundancy and conflicts; low resource allocation efficiency, even leading to scheduling deadlocks; and the inability to guarantee a globally optimal execution order across events. In rail transit operations, emergency dispatch systems often operate in an "event → task chain → dispatch execution" manner. When multiple events occur simultaneously, each task chain is generated independently, easily leading to duplication, conflicts, and uneven resource allocation during task execution. Traditional systems lack the ability to integrate tasks across events, resulting in decreased response efficiency.

[0003] Most existing emergency dispatch technologies are based on the following model: generating a task list (or task graph) independently for each event; sorting tasks and allocating resources within a single event; and relying mainly on manual scheduling or simple priority queue merging for cross-event coordination. Some studies have proposed using task graph models and graph algorithms in path planning and resource scheduling, but these focus on single-event optimization and lack systematic algorithms for task merging and conflict detection across multiple events. The shortcomings of existing technologies are: lack of cross-event task fusion, where similar tasks (such as shutting down a device) may appear repeatedly in different event task chains, resulting in redundant execution; insufficient conflict detection, failing to automatically identify cross-event resource exclusion, execution conflicts, and security interlocking relationships; lack of graph-level optimization, as existing solutions are mostly based on linear task lists and cannot be pruned and optimized at the graph structure level; and weak context adaptability, lacking a mechanism for dynamically pruning tasks based on real-time status.

[0004] For example, Chinese patent CN109358957B discloses a task-driven multi-source information fusion method, providing the following technical solutions: First, based on multi-platform task planning, a multi-objective decision-making method is used to realize the transformation and mapping of different application tasks to situational information requirements; then, based on multi-source comprehensive verification and comparison, the quality of real-time sensor detection data is evaluated; and based on the configuration of sensor network computing and communication resources and the situational generation quality evaluation results, the information fusion capability under the current state is estimated; finally, a multi-task dynamic scheduling method is used to generate optimized information fusion threads under multiple constraints, and the corresponding fusion threads can be automatically matched and adjusted under dynamic and changing task conditions. This method can support the generation of reasonable and applicable situational information for multiple application platforms under diverse task backgrounds. However, the above-mentioned task-driven multi-source information fusion method cannot effectively handle task redundancy, resource competition, and cross-event dependencies, and is prone to redundant execution and insufficient conflict resolution in rail transit scheduling. Summary of the Invention

[0005] This invention addresses the problems of cross-event task redundancy, insufficient conflict detection, weak graph structure optimization, and low scheduling efficiency in existing technologies. It proposes a multi-event fusion scheduling method for rail transit emergency tasks, achieving the goals of global consistency, task minimization, and intelligent scheduling.

[0006] Furthermore, the purpose of this invention is to provide a multi-event emergency dispatching method for rail transit. By integrating multiple task branches, dynamically pruning infeasible tasks, identifying and merging similar operation instructions for the same or related physical equipment, and automatically detecting safety constraints such as equipment mutual exclusion and resource competition, a unified dispatching instruction diagram is finally generated. This diagram is then directly input into automated intelligent agents such as station control, onboard, and inspection systems to generate dispatching instructions, thereby replacing manual dispatching decisions. This solves technical problems such as response delays, resource conflicts, and unreliability of manual dispatching when multiple events occur concurrently, and improves the efficiency and safety of collaborative control of the rail transit system.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A multi-event fusion scheduling method for rail transit emergency tasks includes: For multiple orbital emergency events occurring simultaneously, event templates are instantiated into corresponding task branches, and all task nodes and dependencies are merged to form an initial candidate graph; Based on the real-time collected context information of the orbital system, feasibility predicate judgment is performed on the task nodes, infeasible nodes and their associated dependency edges are removed, and a feasibility task graph is obtained. By identifying similar task nodes in different task branches using the canonical key, the merge operator is executed to eliminate redundancy, and the task nodes and dependencies are updated. Discover cross-branch conflicts and coupling constraints, generate constraint relationships in the form of a hypergraph, output the minimum fully fused subgraph and generate scheduling instructions based on it, and issue them to the track scheduling system as the optimal schedule.

[0008] The algorithm ensures its systematicity and operability. Through step-by-step processing, it can automatically integrate multiple event task branches, reduce manual intervention, and improve response speed. At the same time, the fusion subgraph directly supports subsequent scheduling algorithms, improving the efficiency and reliability of overall emergency response.

[0009] Preferably, the instantiation of the event template into the corresponding task branch includes: using the event template library to instantiate each event into a set of task nodes and a set of dependency edges; the template instantiation function matches a predefined task chain template from the template library according to the event type, and dynamically generates candidate task nodes and dependencies in combination with the real-time context; and finally, the task node sets and dependency edge sets of all event branches are combined to form an initial candidate graph.

[0010] Instantiation using an event template library enables the algorithm to quickly adapt to different event types. Predefined templates reduce computational overhead and improve the accuracy and consistency of generated task branches. Dynamically combining real-time context ensures that the task chain matches the actual scenario, enhancing the algorithm's adaptability and real-time performance, and laying a solid foundation for subsequent fusion steps.

[0011] Preferably, the feasibility predicate judgment for task nodes includes: defining a feasibility predicate, which takes the value 0 or 1. When it is 1, it means that the task is executable in the current context, and when it is 0, it means that it is not executable; after feasibility pruning, remove all task nodes with a value of 0 and their associated dependency edges, and update the dependency edge set to retain only the edges where both ends of the nodes are feasible, to obtain a feasibility task graph. The dependency edges represent the temporal relationship, conditional triggering relationship, and mutual exclusion relationship between control actions; and dynamically determine the target device identifier, control action, action parameters, and execution area of ​​the task node by combining event description information and context information.

[0012] The feasibility predicate judgment mechanism effectively filters out infeasible tasks, avoiding ineffective scheduling and resource waste, and ensuring that the task graph contains only executable nodes. This dynamic pruning, based on real-time status such as device status or resource availability, improves the practicality and security of the scheduling plan and reduces potential errors in emergency response.

[0013] Preferably, the method of identifying similar task nodes in different task branches using a standard key includes: defining a standard key for each task node, which is a triple consisting of a device identifier, an action type, and a region identifier; during the identification process, all task nodes in the feasibility task diagram are grouped according to the standard key, and each group contains task nodes with the same standard key. The nodes come from different event branches but correspond to the same device, the same action, and the same region; the standard key consists of the device identifier of the target rail transit equipment, the action type of the control action to be performed, and the region identifier where the equipment is located or the action involves.

[0014] The use of canonical keys enables the system to accurately identify repetitive tasks across branches, ensuring matching accuracy through device, action, and region triples. This grouping mechanism simplifies the merging process, avoids redundant operations, improves the simplicity and execution efficiency of the task graph, and provides a clear foundation for subsequent conflict detection.

[0015] Preferably, the execution of the merging operator to eliminate redundancy includes: applying a merging operator to each canonical key group, the operator merging multiple similar task nodes within the group into a representative task node; the merging rules include attribute merging, dependency merging, and context merging, wherein attribute merging takes the most stringent parameters in the original task node, including the earliest deadline or the highest risk level, dependency merging maps all the pre- and post-dependent edges of the original task to the representative task node, and context merging retains the source event information of the task; after merging, a merged task node set is generated and the dependency edge set is updated.

[0016] The merge operator effectively eliminates task redundancy by merging attributes, dependencies, and context, while preserving critical information and constraints. Using the most stringent parameters ensures safety, dependency mapping maintains the integrity of the graph structure, and context tracing supports auditing and optimization. This step significantly reduces the number of nodes and improves scheduling efficiency.

[0017] Preferably, the discovery of cross-branch conflict and coupling constraints includes: constructing a conflict and cooperation constraint hypergraph, which contains mutually exclusive hyperedges, resource contention capacity constraints and security interlocking hyperedges, and cooperative batch processing hyperedges; wherein, mutually exclusive hyperedges include control actions executed by the same device that are mutually exclusive in terms of physical or safety rules, resource contention hyperedges include the real-time occupancy and concurrency limits of signal system resources and personnel skill resources, security interlocking hyperedges are generated by electrical safety rules or spatial safety rules, and cooperative hyperedges are generated by a set of parallelizable tasks; the hypergraph is encoded as newly added constraint edges on the graph and added to the task graph.

[0018] Hypergraph modeling can capture high-order constraints, such as mutual exclusion and cooperation, and automatically discover implicit dependencies across branches. This mechanism improves the comprehensiveness of conflict detection, avoids resource contention or security risks, and ensures the feasibility and optimality of scheduling plans in complex scenarios.

[0019] Preferably, the constraints in the generated hypergraph form include: based on the merged task node set and real-time context, detecting device mutual exclusion, resource contention, security interlocking, and collaborative opportunities through setting functions; wherein, device mutual exclusion detects conflicting operations on the same device, resource contention detects concurrent limitations of skills or human resources, security interlocking detects mutual exclusion relationships, and collaborative batch processing detects task groups that can be merged and executed; after the hypergraph is constructed, hyperedges are converted into ordinary edges or hyperedge forms through setting functions and integrated into the task graph structure.

[0020] By systematically detecting issues such as device mutual exclusion and resource contention, the hypergraph generation process ensures the accurate integration of constraints. Transforming hyperedges into a graph structure enhances tractability, allowing the task graph to be directly used in scheduling algorithms, thus improving the algorithm's practicality and automation level.

[0021] Preferably, the output minimum fully fused subgraph includes: combining the task node set obtained by merging similar tasks across branches with the newly added constraint edge set identified during the cross-branch conflict and coupling relationship discovery process to generate the final fused subgraph; wherein, the task node set of the fused subgraph is directly taken from the merged task node set, and the edge set is composed of the merged updated dependency edge set and the newly added constraint edge set.

[0022] The output subgraph is minimal and sufficient, avoiding redundancy while retaining all necessary constraints, providing high-quality input for multi-agent scheduling. This combination ensures the integrity and schedulability of the subgraph, supporting efficient and secure emergency response execution.

[0023] Preferably, the event template library is expanded according to different rail transit scenarios, adding new event types and task templates; the real-time context includes equipment status, passenger flow and resource online status, as well as regulatory information, dynamically adapting to changing conditions; in the merging operator, the context merging rules retain the source event identifier of the original task node, so that each task in the fused subgraph can be traced back to the triggering event.

[0024] The extensibility of the template library and context enhances the algorithm's adaptability, enabling it to handle a wide variety of rail transit scenarios. Meanwhile, retaining source event information supports traceability, facilitates auditing and optimization, and improves system reliability and maintainability.

[0025] Preferably, the event is defined as a structured object containing an identifier, severity, and parameters, wherein the identifier includes type, location, and time of occurrence.

[0026] The structured definition of events ensures data standardization and consistency, facilitating template matching and instantiation. It includes identifiers such as type, location, and time, supporting precise event processing and priority determination, thus improving the accuracy and response speed of the algorithm.

[0027] Compared with the prior art, the beneficial effects of the present invention are as follows.

[0028] 1. This invention achieves global consistency and conflict resolution through a multi-event subgraph fusion algorithm, effectively solving the redundancy and conflict problems caused by multiple concurrent events in rail transit emergency dispatching. The algorithm automatically integrates multiple task branches, avoiding duplicate execution and resource contention, and ensuring the consistency and reliability of the dispatching plan. Through cross-branch conflict detection and processing, manual intervention is reduced, and the emergency response speed is improved. At the same time, the fused subgraph directly supports subsequent multi-agent dispatching, enhancing the overall handling efficiency.

[0029] 2. The task minimization mechanism of this invention significantly eliminates redundant tasks and ensures executability through feasibility predicate judgment and canonical key merging. Dynamically pruning infeasible nodes avoids ineffective scheduling and resource waste, while merging similar tasks reduces the number of nodes and improves the simplicity of the graph structure. This minimum sufficient subgraph output ensures efficient execution of the scheduling plan, reduces response time, and improves the system's usability and security.

[0030] 3. The intelligent scheduling objective of this invention is achieved through hypergraph modeling and implicit dependency discovery, automatically capturing high-order constraints across branches. The algorithm can identify complex scenarios such as device mutual exclusion, resource contention, and security interlocks, and transform them into a processable task graph structure. This automated optimization improves the intelligence level of scheduling, supports globally optimal decision-making, and enhances the adaptability and reliability of emergency response. Attached Figure Description

[0031] Figure 1 This is an overall flowchart of a multi-event fusion scheduling method for emergency tasks in rail transit according to the present invention.

[0032] Figure 2 This is a graph structure with added constraints in one embodiment of a multi-event fusion scheduling method for emergency rail transit tasks according to the present invention. Detailed Implementation

[0033] See Figures 1-2 As shown, a multi-event fusion scheduling method for rail transit emergency tasks includes: For multiple orbital emergency events occurring simultaneously, event templates are instantiated into corresponding task branches, and all task nodes and dependencies are merged to form an initial candidate graph; Based on the real-time collected context information of the orbital system, feasibility predicate judgment is performed on the task nodes, infeasible nodes and their associated dependency edges are removed, and a feasibility task graph is obtained. By identifying similar task nodes in different task branches using the canonical key, the merge operator is executed to eliminate redundancy, and the task nodes and dependencies are updated. Discover cross-branch conflicts and coupling constraints, generate constraint relationships in the form of a hypergraph, output the minimum fully fused subgraph and generate scheduling instructions based on it, and issue them to the track scheduling system as the optimal schedule.

[0034] The problem this invention aims to solve is: how to automatically merge multiple task branches, deduplicate and prune infeasible tasks, discover and handle conflicts and coupling relationships when multiple events occur simultaneously, and generate a minimum fully fused subgraph that can be directly used for multi-agent scheduling, thereby improving the efficiency and safety of emergency response in rail transit.

[0035] This invention proposes a Multi-Incident Subgraph Fusion (MISF) algorithm, which automatically completes the following steps based on a global task graph, an event template library, and real-time context information: 1. Event branching expansion; 2. Feasibility assessment; 3. Merge similar tasks across branches; 4. Detection of cross-branch conflict / coupling relationships; 5. Output the merged subgraph.

[0036] The final output fused subgraph can be directly input into scheduling algorithms such as importance ranking and multi-agent task allocation to achieve globally optimal scheduling. The core idea of ​​the Multi-Event Subgraph Fusion (MISF) algorithm is that in rail emergency scenarios, multiple events can trigger simultaneously, such as a leaking station hall, a passenger falling on the platform, or a malfunctioning broadcasting device. In such cases, the global task graph involves multiple branches, and some tasks may share resources or have dependency conflicts. Directly extracting all branches would lead to task duplication, priority conflicts, and wasted resource allocation. Secondly, cross-branch dependencies are "hidden." For example, the "switching broadcasts" task for a leaking station hall and the "switching broadcasts" task for a leaking platform might both operate on the same broadcasting device. Furthermore, branches are not necessarily complete closed loops; some branches are templated and need to be dynamically tailored based on the actual situation.

[0037] Global task graph: G equals (V, E), each task node v∈V describes an executable action (object, action, parameters, location, required qualifications, time window, risk level, etc.); edge "E" represents constraints such as preconditions / mutual exclusion / cooperation (directed / undirected / superedge).

[0038] Event set: F equals {I1, ..., I} m}, each event I j equal to (type) j loc j time j sev j , l j (Type, location, occurrence time, severity, parameters). Events are associated with the global task graph through the event template library T. The template instantiates the event as a set of candidate task chains and constraints.

[0039] Context: CTX (Real-time equipment status, passenger flow, resource online status, regulations / work tickets, etc.).

[0040] Objective: From multiple task branches triggered by multiple events, automatically prune, merge, deduplicat, and decouple conflicts to output a fused influence subgraph G, which can serve as the basis for multi-agent cooperative scheduling.

[0041] like Figure 1 In one embodiment shown, Figure 1 This is an overall flowchart of a multi-event fusion scheduling method for emergency tasks in rail transit according to the present invention. First, for multiple emergency events occurring simultaneously, the system instantiates corresponding task branches using event templates. The event template instantiation process uses an event template library to instantiate each event (defined as a structured object containing type, location, occurrence time, severity, and parameters) into a set of task nodes and a set of dependency edges. The template instantiation function matches predefined task chain templates from the template library based on the event type and dynamically generates candidate task nodes and dependencies by combining real-time context (such as equipment status, passenger flow, resource online status, and regulatory information). Finally, the task node sets and dependency edge sets of all event branches are combined to form an initial candidate graph.

[0042] Then, feasibility predicates are used to determine the task nodes based on real-time context information. The feasibility predicate takes a value of 0 or 1, where 1 indicates that the task is executable in the current context, and 0 indicates that it is not executable (e.g., because the device is already in the target state or resources are lacking). After feasibility pruning, the system removes all infeasible nodes and their associated dependent edges, updates the dependent edge set, and retains only edges where both ends of the node are feasible, thus obtaining the feasibility task graph.

[0043] Next, the system identifies similar task nodes in different task branches using the canonical key. The canonical key is a triple consisting of device identifier, action type, and region identifier. During the identification process, the system groups all task nodes in the feasibility task graph according to the canonical key, and each group contains task nodes with the same canonical key (i.e., nodes from different event branches but corresponding to the same device, the same action, and the same region).

[0044] Next, the merge operator is executed to eliminate redundancy. The merge operator is applied to each canonical key group, merging multiple similar task nodes within the group into a single representative task node. Merging rules include attribute merging (e.g., taking the most stringent parameter from the original task nodes, such as earliest deadline or highest risk level), dependency merging (mapping all pre- and post-dependent edges of the original task to the representative task node), and context merging (preserving the task's source event information for easy traceability). After merging, a merged set of task nodes is generated, and the dependency edge set is updated.

[0045] Then, cross-branch conflict and coupling constraints are identified. The system constructs a conflict and cooperation constraint hypergraph, which includes mutually exclusive hyperedges (generated from mutually exclusive operations on the same device), resource contention capacity constraints (generated from the concurrency limit of shared resources), safety interlocking hyperedges (generated from job safety rules), and cooperative batch processing hyperedges (generated from a set of parallelizable tasks). When generating the constraint relationships in the form of the hypergraph, based on the merged task node set and the real-time context, functions are set to detect device mutual exclusion, resource contention, safety interlocking, and cooperation opportunities, and the hyperedges are converted into ordinary edges or hyperedge forms and integrated into the task graph structure.

[0046] Finally, the minimum sufficient fusion subgraph is output. The system combines the merged task node set with the newly added constraint edge set identified during the cross-branch conflict and coupling relationship discovery process to generate the final fusion subgraph. The task node set of the fusion subgraph is directly taken from the merged task node set, and the edge set is composed of the merged updated dependency edge set and the newly added constraint edge set, ensuring that the subgraph is minimum sufficient and can be directly used for multi-agent scheduling.

[0047] In addition, the event template library can be expanded according to different rail transit scenarios, adding new event types and task templates; the real-time context dynamically adapts to changing conditions, and the source event identifier is retained in the merging operator through context merging rules to achieve task traceability.

[0048] In another embodiment, the algorithm flow of the present invention is as follows: S1: Event Branching Expansion For each event I j Call the template instantiation function: (V) j E j ) equals InstantiateBranch(T, I) j (CTX).

[0049] Where: V j It is caused by event I j The generated set of candidate task nodes; E jIt is a set of task dependencies (directed edges), representing the sequential execution, conditional triggering, or mutual exclusion relationships between tasks.

[0050] Branches are merged into an initial candidate set: By taking the union of the task set and dependency set of all events, we obtain the initial task candidate graph under multiple events: V （0） equal E （0） equal ; in: V （0） The complete set of task nodes from all event branches; E （0） : The complete set of corresponding task dependencies.

[0051] S2: Feasibility Trial Define the feasibility predicate ϕ(v, CTX)∈{0,1}.

[0052] Where ϕ = 1: indicates that task v can be executed under the current context CTX; ϕ=0: This indicates that task v is not executable in the current context CTX (and should be pruned).

[0053] Common instances of ϕ=0 include: equipment already in target state, work order missing, resource qualifications not met, and time window expired.

[0054] Pruning infeasible nodes and dependency closures: V （1） equals {v∈V} （0） | ϕ(v, CTX) = 1}, E （1） Equal to E （0） ∩(V （1） ×V （1） ).

[0055] Among them, V （1） It is the set of task nodes remaining after feasibility filtering, all of which are candidate tasks that are "theoretically executable". E （1） It is the set of dependency edges retained after feasibility filtering, i.e., E （0） Only both ends are retained in V. （1） This establishes dependencies within the graph. This ensures the integrity and correctness of the graph.

[0056] S3: Merging similar tasks across branches Define a canonical key for each task: k(v) equals {device(v), action(v), zone(v)}; For a set C with the same k, the set C is equal to {v1, ..., v}. r Perform merge operator: V equals ; Where k(v) is the canonical key of the task, a triple consisting of the core features of the task, used to determine whether two tasks belong to the "same type of task": device(v): A unique identifier for the equipment involved in the task, such as "Station Lighting No. 1" or "Escalator No. 2".

[0057] action(v): The action type of the task, such as "close", "open", "switch mode", etc.

[0058] zone(v): The area identifier for the task's function, such as "Area A of the station hall" or "Platform 2 side".

[0059] If two tasks have exactly the same k(v), it means that they are repeated operations on the same device, the same action, and the same area, and can be merged.

[0060] C is the set of all tasks with the same canonical key after grouping according to k(v), which may come from different event branches; The merge operator is a custom task fusion operator that combines multiple similar tasks in set C into a single representative task v. Common rules include: Attribute merging: such as taking the earliest deadline, the highest risk level, the longest estimated duration, etc.; Dependency merging: Merges all pre- and post-dependencies of the original task; Context merging: Preserves the source event information of the original task for easy traceability.

[0061] v is the sole representative task after the merger, used to replace all similar tasks in set C. After the merger, the number of nodes in the task graph is reduced, avoiding duplicate assignments or conflict control in multi-event scenarios.

[0062] S4: Detection of cross-branch conflict / coupling relationships A conflict and collaboration constraint hypergraph H is constructed to capture higher-order constraints between multiple tasks, not just binary conflicts. Construction rules: Device mutual exclusion: The "on / off" and "mode switching" of the same device form a mutually exclusive superedge h. mutex ; Resource competition: The concurrent upper limit for the same skill / personnel creates a capacity constraint h cap ; Safety interlocks: For example, interlocking "power supply" with "water-related operations" h safe ; Collaborative merging: A set of tasks h that can be processed in parallel or merged into batches. batch .

[0063] Transform H into a new hyperedge E on the graph. （3） And add selection variables to incompatible sets.

[0064] S5: Merge Subgraph Output G' equals (V', E'), where V' equals V （2） E' equals E （2） ∪E （3） ; At this point, G' is the minimum sufficient subgraph after "multi-event fusion", ensuring subsequent schedulability, verifiability, and traceability. It also serves as the direct input for subsequent scheduling algorithms (such as importance ranking and multi-agent matching).

[0065] The specific pseudocode is as follows: MISF(Incidents I={I1..Im}, GlobalGraph G, Context CTX): A) Branch expansion V0, E0 ← ∅, ∅ for each Ij in I: (Vj, Ej) ← InstantiateBranch(T, Ij, CTX) V0 ← V0 ∪ Vj ; E0 ← E0 ∪ Ej B) Feasibility Cutting V1 ← { v in V0 | phi(v,CTX)=1} E1 ← { (u,w) in E0 | u∈V1 and w∈V1} C) Deduplication and Merging buckets ← group_by_key(V1, key=kappa(v)) V2 ← ∅ For each bucket C: v_star ← merge_oplus(C)⊕ Merge Operator V2 ← V2 ∪ {v_star} E2 ← map_edges(E1, merge_map) Dependency mapping to merged nodes D) Conflict / Coupling Detection H ← build_hyper_constraints(V2, CTX)mutex / cap / safe / batch E3 ← encode_to_edges(V2, H) generates newly added constraint edges / superedges. E) Blended subgraph output V_star ← V2 E_star ← E2 ∪ E3 G_tilde_star ← (V_star, E_star).

[0066] The beneficial effects of this invention are as follows: 1. Global consistency and conflict resolution The Multi-Event Subgraph Fusion (MISF) algorithm can automatically identify similar tasks, resource conflicts, and security interlocks in multi-branch task graphs triggered by multiple sources of events, and handle them uniformly during the fusion process, avoiding duplicate distribution, mutual exclusion conflicts, and security risks, thereby ensuring the consistency and reliability of global scheduling.

[0067] 2. Task minimization and executability assurance By introducing a feasibility pruning and normalized key merging mechanism, the output subgraph retains only tasks that are executable in the current context, eliminates redundant and invalid nodes, reduces scheduling pressure, improves execution efficiency, and ensures that the resulting subgraph is "minimum sufficient" and can be directly used for downstream scheduling and execution.

[0068] 3. Automatic discovery of implicit dependencies across branches By using hypergraph modeling with conflict and collaboration constraints, implicit constraint relationships across branches (such as shared equipment, resource capacity, and batch processing opportunities) can be captured. These are difficult to automatically identify using manual rules or single-branch scheduling, thus improving the overall intelligence level of scheduling.

[0069] 4. Traceability and scalability The algorithm preserves the source events, merging rules, and context information of tasks during the merging and pruning process, providing a basis for subsequent event tracing, execution auditing, and strategy optimization. Furthermore, the algorithm can be adapted to different rail transit scenarios, achieving rapid expansion by changing the template library and adjusting the merging operators and constraint types.

[0070] Compared with the prior art, the present invention has the following advantages: Cross-event optimization: Integrate multiple event tasks from the perspective of a global task graph to reduce redundant execution; Automatic conflict detection: Capturing high-order constraint relationships through hypergraph modeling; Context Adaptation: Feasibility pruning ensures that the scheduling plan is consistent with the real-time state; Structured output: The fused subgraph can be directly used in the scheduling algorithm, reducing manual intervention; Highly scalable: The template and constraint libraries can be expanded according to lines, equipment, and procedures.

[0071] In another embodiment, the entire process of the Multi-Event Fusion (MISF) algorithm is illustrated using the simultaneous occurrence of three types of events within a subway station as an example: E1: Leaking in the station hall E2: Passenger falls E3: Broadcast failure The system executes steps S0–S5, and the task graph gradually evolves from multiple independent branches into a fused minimum sufficient subgraph.

[0072] S0: Scene initialization (event triggering phase) Description of state changes: The monitoring system detected the following events: ISCS report "Station hall humidity exceeds threshold", triggering E1: Station hall water leakage; CCTV intelligently detected "passenger falling on the platform", triggering E2: Passenger falls; The BAS communication subsystem reports "Main broadcast channel failure", triggering E3: Broadcast Failure.

[0073] The system encapsulates the data into structured event objects and loads the template library. At this point, the task graph is empty, with only three event root nodes created.

[0074] S1: Event Template Instantiation and Branch Expansion The status change description states that the system generates three task branches based on the event template library.

[0075] The changes in the diagram are as follows: The number of nodes is 9 (A1-A3, B1-B3, C1-C3). Each event branch forms a directed dependency chain, and the branches are independent of each other, with no cross-branch connections. Only specific details are expanded; for example, the passenger fall branch is expanded to: stop the escalator → call for medical assistance → switch the broadcast; the station hall water leak branch is expanded to: turn off the lighting → start the drainage pump → notify the duty officer.

[0076] S2: Contextual Feasibility Trimming Context state (CTX): The escalator is currently out of service. The drainage pump is available; Alternate broadcast is available; Description of state changes: Algorithm calculates feasibility predicate φ(v, CTX): φ(B1, "Stop escalator") equals 0 (because it has stopped) → delete node and associated edge.

[0077] Other tasks with φ=1 are reserved.

[0078] The changes to the cropped task image are as follows: Delete node B1 and its outgoing edges; Update dependencies: B2 directly becomes the branch starting point; The number of nodes was reduced from 9 to 8; The graph structure maintains directed connectivity.

[0079] For example: the branch for water leakage in the station hall remains unchanged: turn off the lighting → start the drainage pump → notify the duty officer; the branch for a passenger falling is changed to: call for medical care → switch the broadcast; the broadcast branch remains unchanged: check the main broadcast → switch the backup broadcast → notify the communication duty officer.

[0080] S3: Identification and Merging of Similar Tasks Across Branches Canonical key matching: The system scans all task nodes and calculates k(v) equal to {device(v), action(v), zone(v)}; Test results: B3 (Switching broadcast) and C2 (Switching backup broadcast) are broadcast hosts of the same device, with the same action type "switching" and the same area "station hall / platform", belonging to the same type of task.

[0081] Execute the merge operator: Merge into node D1 = "Switch broadcast mode (merge E2c+E3b)"; Merging precursors: B2, C1; Merged successors: A3, C3 (notify the duty officer and communications officer respectively).

[0082] The task map has been updated; the changes are as follows: The number of nodes changed from 8 to 7; The first cross-branch merge node D1 appears; Branches E2 and E3 are merged through D1; Add cross-branch edges: C1→D1, B2→D1, D1→A3 / C3; The diagram begins to show a multi-event fusion structure.

[0083] For example: If the water leakage branch in the station hall remains unchanged: turn off the lighting → start the drainage pump → notify the duty officer; if the passenger falls and the broadcast branch are merged and the broadcast mode is switched: call for medical care and testing main broadcast → switch broadcast mode → notify the communication duty officer.

[0084] S4: Conflict and Coupling Constraint Detection Test results: Device mutual exclusion constraints: "Disconnect lighting (A1)" and "Switch broadcast (D1)" are both located on the same power circuit in the station hall → they must be executed sequentially; → The system adds constraint edge A1 → D1 to the graph.

[0085] Safety interlock constraints: There are water safety restrictions between "Starting the drainage pump (A2)" and "Powering on" → Keep the execution order A1 → A2.

[0086] Resource competition constraints: Both "Calling Medical Staff (B2)" and "Notification Communication Duty (C3)" require a communication channel → The system sets the resource limit to 1, which is resolved during the scheduling phase; → Add a mutual exclusion edge B2 ↔ C3.

[0087] Collaborative constraints: "Notify Duty Officer (A3)" and "Notify Communication Duty Officer (C3)" can be merged into a batch process → the record is a collaboration set.

[0088] The structure after adding constraints is as follows: Figure 2 As shown, Figure 2 This is a graph structure with added constraints in one embodiment of a multi-event fusion scheduling method for emergency rail transit tasks according to the present invention.

[0089] The changes in the diagram are as follows: Add 3 new constraint edges (sequential, mutually exclusive, cooperative); The number of nodes remains unchanged; The graph structure is transformed from a simple dependency chain to a constraint-enhanced graph; The system forms a complete integrated task network.

[0090] S5: Merge Subgraph Output The system performs fusion, reconstruction, and minimization, removing redundant dependencies and compressing collaborative tasks.

[0091] The final output fusion sub-graph is as follows: Cut off lighting → Start drainage pump → Call medical staff → Switch broadcast mode → Notify duty officer & communication supervisor.

[0092] Interpretation of the fusion result: All duplicate tasks are eliminated; all conflicting tasks are made explicit; all collaborative tasks are packaged; event origin and execution traceability are preserved. The output fusion subgraph represents a set of immediately executable, conflict-free, and minimally sufficient contingency tasks.

Claims

1. A multi-event fusion scheduling method for emergency tasks in rail transit, characterized in that, include: For multiple orbital emergency events occurring simultaneously, event templates are instantiated into corresponding task branches, and all task nodes and dependencies are merged to form an initial candidate graph; Based on the real-time collected context information of the orbital system, feasibility predicate judgment is performed on the task nodes, infeasible nodes and their associated dependency edges are removed, and a feasibility task graph is obtained. By identifying similar task nodes in different task branches using the canonical key, the merge operator is executed to eliminate redundancy, and the task nodes and dependencies are updated. Discover cross-branch conflicts and coupling constraints, generate constraint relationships in the form of a hypergraph, output the minimum fully fused subgraph and generate scheduling instructions based on it, and issue them to the track scheduling system as the optimal schedule.

2. The multi-event fusion scheduling method for emergency tasks in rail transit according to claim 1, characterized in that, The instantiation of the event template into the corresponding task branch includes: using the event template library to instantiate each event into a set of task nodes and a set of dependency edges; the template instantiation function matches a predefined task chain template from the template library according to the event type, and dynamically generates candidate task nodes and dependencies in combination with the real-time context; and finally, the union of the set of task nodes and the set of dependency edges of all event branches is taken to form an initial candidate graph.

3. The multi-event fusion scheduling method for emergency tasks in rail transit according to claim 2, characterized in that, The feasibility predicate judgment for task nodes includes: defining a feasibility predicate, which takes the value 0 or 1. When it is 1, it means that the task is executable in the current context, and when it is 0, it means that it is not executable; after feasibility pruning, remove all task nodes with a value of 0 and their associated dependency edges, and update the dependency edge set to retain only the edges where both ends of the nodes are feasible, to obtain a feasibility task graph. The dependency edges represent the temporal relationship, condition triggering relationship, and mutual exclusion relationship between control actions; and dynamically determine the target device identifier, control action, action parameters, and execution area of ​​the task node by combining event description information and context information.

4. A multi-event fusion scheduling method for rail transit emergency tasks according to claim 2 or 3, characterized in that, The method of identifying similar task nodes in different task branches using a standard key includes: defining a standard key for each task node, which is a triple consisting of a device identifier, an action type, and a region identifier; during the identification process, all task nodes in the feasibility task diagram are grouped according to the standard key, and each group contains task nodes with the same standard key. The nodes come from different event branches but correspond to the same device, the same action, and the same region; the standard key consists of the device identifier of the target rail transit equipment, the action type of the control action to be performed, and the region identifier where the equipment is located or the action involves.

5. The multi-event fusion scheduling method for rail transit emergency tasks according to claim 4, characterized in that, The execution of the merging operator to eliminate redundancy includes: applying the merging operator to each canonical key group, the operator merging multiple similar task nodes within the group into a representative task node; the merging rules include attribute merging, dependency merging, and context merging, wherein attribute merging takes the most stringent parameters in the original task node, including the earliest deadline or the highest risk level, dependency merging maps all the pre- and post-dependent edges of the original task to the representative task node, and context merging retains the source event information of the task; after merging, a merged task node set is generated and the dependency edge set is updated.

6. The multi-event fusion scheduling method for emergency tasks in rail transit according to claim 5, characterized in that, The discovery of cross-branch conflict and coupling constraints includes: constructing a conflict and cooperation constraint hypergraph, which contains mutually exclusive hyperedges, resource contention capacity constraints and security interlocking hyperedges, and cooperative batch processing hyperedges; wherein, mutually exclusive hyperedges include control actions executed by the same device that are mutually exclusive in terms of physical or safety rules, resource contention hyperedges include the real-time occupancy and concurrency limits of signal system resources and personnel skill resources, security interlocking hyperedges are generated by electrical safety rules or spatial safety rules, and cooperative hyperedges are generated by a set of parallelizable tasks; the hypergraph is encoded as newly added constraint edges on the graph and added to the task graph.

7. A multi-event fusion scheduling method for rail transit emergency tasks according to claim 5 or 6, characterized in that, The constraints in the generated hypergraph form include: based on the merged task node set and real-time context, a function is set to detect device mutual exclusion, resource contention, security interlocks, and collaborative opportunities; among them, device mutual exclusion detects conflicting operations on the same device, resource contention detects concurrent limitations of skills or human resources, security interlocks detect mutual exclusion relationships, and collaborative batch processing detects task groups that can be merged and executed; after the hypergraph is constructed, a function is set to convert hyperedges into ordinary edges or hyperedge forms and integrate them into the task graph structure.

8. The multi-event fusion scheduling method for emergency tasks in rail transit according to claim 7, characterized in that, The output minimum fully fused subgraph includes: combining the set of task nodes obtained by merging similar tasks across branches with the set of newly added constraint edges identified during the discovery of cross-branch conflicts and coupling relationships to generate the final fused subgraph; wherein, the set of task nodes in the fused subgraph is directly taken from the merged set of task nodes, and the set of edges is composed of the merged updated set of dependency edges and the set of newly added constraint edges.

9. A multi-event fusion scheduling method for emergency tasks in rail transit according to claim 5, characterized in that, The event template library is expanded according to different rail transit scenarios, adding new event types and task templates; the real-time context includes equipment status, passenger flow and resource online status, as well as regulatory information, dynamically adapting to changing conditions. In the merge operator, the context merge rule preserves the source event identifier of the original task node, so that each task in the merge subgraph can be traced back to the triggering event.

10. A multi-event fusion scheduling method for emergency tasks in rail transit according to claim 2, characterized in that, The event is defined as a structured object containing an identifier, severity, and parameters, where the identifier includes type, location, and time of occurrence.

Images