Railway disaster prevention on-site controller

Abstract

The application discloses a railway disaster prevention on-site controller and relates to the technical field of controllers. The controller comprises a digital twin management module, a cooperative decision execution module and a communication bus. The digital twin management module is used for creating and maintaining digital twins for each physical device on the communication bus, calculating dynamic deviation and generating health state evaluation results based on real-time running data flow of the physical device and a pre-stored benchmark health model. The cooperative decision execution module is used for starting a local cooperative process when the health state evaluation is abnormal, exchanging state data that is verified by security with an associated device group to form a local situation consensus, and querying a local preplan library according to the consensus to generate and execute control instructions. The application monitors the state of disaster prevention lighting and evacuation indicating lamps through digital twins, automatically executes emergency lighting, evacuation sign adjustment and partition dimming through local cooperative decision and sand table deduction, and ensures that an evacuation path is clear and lighting coverage is reasonable.

Description

Technical Field

[0001] This invention relates to the field of controller technology, specifically to a local controller for railway disaster prevention. Background Technology

[0002] As a critical node in rail transit networks, railway tunnels, with their enclosed environment and complex structure, present significant challenges to personnel evacuation and emergency rescue during sudden disasters such as fires and smoke intrusions. Therefore, disaster prevention lighting and evacuation guidance systems within railway tunnels are core infrastructure for ensuring life safety, and their reliability, real-time performance, and intelligence are paramount. However, existing local controllers have significant limitations: limited equipment status perception dimensions, lack of local intelligent analysis, and reliance on manual or host computer-based decision-making.

[0003] The invention patent with patent publication number CN115562368A discloses a local controller, including: a CPU; the CPU is used to: receive and according to the target control command sent by the host computer, and determine whether the target control command is an automatic tracking control command, and obtain a first judgment result; when the first judgment result is negative, to perform local control on the hydraulic system corresponding to the heliostat to be controlled, so that the hydraulic system drives the elevation angle of the heliostat to be controlled to adjust to the first target elevation angle, and to adjust the azimuth angle of the heliostat to be controlled to the first target azimuth angle.

[0004] However, the above and similar technical solutions still have the following shortcomings: the control logic still relies on direct instructions from the host computer and lacks the ability to deeply perceive and evaluate the operating status of the equipment group; the decision-making mode is based on threshold judgment of preset rules, which is difficult to cope with dynamic factors such as equipment aging and sudden environmental changes; there is a lack of effective information exchange and collaborative decision-making between equipment, which may lead to a high false alarm rate and a high risk of fault spread when dealing with complex scenarios such as railway tunnel disaster prevention that require rapid, collaborative and intelligent response from multiple equipment. Summary of the Invention

[0005] The purpose of this invention is to provide a local controller for railway disaster prevention to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a local controller for railway disaster prevention, comprising:

[0007] The digital twin management module is used to create and maintain digital twins for each physical device on the communication bus. Based on the real-time operating data stream of the physical device and the pre-stored baseline health model, it calculates the dynamic deviation and generates health status assessment results.

[0008] The collaborative decision-making and execution module is used to initiate a local collaborative process when the health status assessment is abnormal, to form a local situational consensus by exchanging security-verified status data with the associated device group, and to query the local contingency plan library based on the consensus to generate and execute control commands.

[0009] The intelligent communication processing module is used to evaluate the reporting value of newly collected data based on the dynamic numerical distribution model of monitoring parameters, and encapsulate the abnormal data that is determined to be reported, along with the corresponding diagnostic information and local situation consensus, into structured semantic intelligence for reporting.

[0010] Furthermore, the method for constructing the benchmark health model includes:

[0011] Guide the physical equipment to operate under preset standard operating conditions, record its multidimensional response data sequence, and obtain the equipment baseline fingerprint data;

[0012] The baseline fingerprint data is classified based on operating mode, load and environmental factors, and several interrelated baseline feature curves are fitted to form a family of multimodal baseline curves.

[0013] For each characteristic curve in the family of reference curves, based on the data dispersion and the criticality of the equipment, the time-varying confidence interval of each prediction point on the characteristic curve is dynamically calculated to define the normal fluctuation range of that point.

[0014] Establish logical connections and transformation relationships between various benchmark characteristic curves to form a working condition association map describing the working condition switching logic;

[0015] The aforementioned family of baseline curves, time-varying confidence intervals, and operating condition correlation maps are integrated and encapsulated into an embedded baseline health model service that can be called by the digital twin in real time.

[0016] Furthermore, the calculation of dynamic deviation and generation of health status assessment specifically includes:

[0017] The real-time device operation data stream is synchronously segmented according to a preset time scale and time-aligned with the corresponding scale expected sequence generated by the benchmark health model.

[0018] For each monitoring parameter at each time scale, a weight is dynamically assigned based on its current operating condition importance and historical statistical noise, and its weighted deviation relative to the expected sequence is calculated accordingly.

[0019] Dynamic pattern features are extracted from the time series of weighted deviations of each monitoring parameter; the dynamic pattern features include the steady-state level of deviation, the trend of change, the periodic fluctuation pattern and the sudden peak characteristics.

[0020] Based on preset fusion rules, the extracted dynamic pattern features are fused and analyzed to generate device health status results with confidence assessment.

[0021] The equipment health status results are encoded into a structured status vector; the status vector includes health level, major abnormal parameters, dominant deviation pattern, confidence level, and abnormal start time.

[0022] Furthermore, the local collaboration process specifically includes:

[0023] When the digital twin determines that it is abnormal, it immediately securely broadcasts a collaboration request carrying a digital signature and anomaly digest to the predefined associated device group;

[0024] Each associated device's digital twin that receives the collaboration request generates and returns a credible evidence package containing its current health status and proof of data integrity.

[0025] The collaborating initiator verifies the source and content of all collected feedback evidence, and assigns weights to the feedback evidence based on the historical credibility of each device, and performs weighted fusion.

[0026] Identify and arbitrate descriptive conflicts between different pieces of evidence, resolve conflicts and generate a unified situational outcome through weight comparison and contextual analysis;

[0027] The unified situation results, key evidence indexes, and arbitration basis are encapsulated into a verifiable local situation consensus record, which is then distributed to all participating parties for local storage and confirmation.

[0028] Furthermore, the method for constructing the local contingency plan library includes:

[0029] Risk events, equipment status, and handling operations in railway tunnel disaster prevention scenarios are deconstructed into composable standardized elements; the standardized elements include event triggering conditions, situational impact range, local available resources, and preset target actions;

[0030] Based on the physical causal relationships, functional substitutions, and spatial topological relationships between devices, standardized elements are dynamically connected as nodes to construct a dynamic contingency plan knowledge graph that supports situational analysis and path discovery.

[0031] Key elements from historical events are input into the contingency plan knowledge graph for forward extrapolation to generate theoretical handling paths. These paths are then compared with historically validated and effective execution paths to label the effective confidence level and historical success rate of different response paths in the contingency plan knowledge graph.

[0032] The paths that reach the confidence threshold in the contingency plan knowledge graph are encapsulated into a structured and executable sequence of contingency plan instructions, and their contextualized priorities are dynamically calculated in combination with the real-time resource status and environmental constraints of the current device group.

[0033] Based on feedback from the local implementation of the contingency plan, the path parameters and confidence level are adaptively calibrated, and the contingency plan knowledge is synchronized bidirectionally with the superior monitoring system.

[0034] Furthermore, the step of querying the local contingency plan repository based on the consensus to generate and execute control instructions specifically includes:

[0035] The local situation consensus record is analyzed to extract key feature vectors that include anomaly type, scope of impact, status of involved equipment, real-time environmental constraints, and confidence level of uncertainty in the consensus.

[0036] The key feature vectors are matched with the dynamic contingency plan knowledge graph in the local contingency plan library in multiple dimensions to generate a candidate contingency plan list sorted by context matching degree and expected utility.

[0037] Based on the current local situation, a plan logic flow is selected from the candidate plan list through a preset multi-objective optimization function, and the parameters in the logic flow are dynamically bound and instantiated with the current local situation data;

[0038] The instantiated contingency plan and the complete data of the current local situation are input into a real-time sand table model built based on the digital twin of the local equipment group for simulation; the deviation between the simulation results and the expected goals is analyzed, and the contingency plan parameters or path switching are dynamically adjusted based on the potential conflicts exposed during the simulation.

[0039] The contingency plan instances verified through simulation are broken down into serialized atomic control instructions and issued to the corresponding control mechanisms; based on real-time feedback and preset fault tolerance and degradation rules, the instructions are adaptively switched between different branches of the instruction sequence.

[0040] Furthermore, the method for constructing the dynamic numerical distribution model includes:

[0041] For each monitoring parameter, define its typical operating conditions, and establish a corresponding baseline probability distribution based on the historical normal data under each typical operating condition to form an initial multi-operating condition distribution library.

[0042] A fixed-capacity sliding window is maintained for each monitoring parameter. When new data enters, a time decay weight is applied to the historical data within the window to amplify the impact of recent data.

[0043] The system identifies the current operating condition of the equipment in real time, and adaptively fuses the sliding window data with the baseline probability distribution of the corresponding operating condition in the initial multi-condition distribution library to generate a conditional dynamic numerical distribution model that reflects the current situation.

[0044] Based on the conditional dynamic numerical distribution model, the dynamic probability boundary threshold used to determine the price value on the data is calculated and updated in real time.

[0045] Compared with the prior art, the beneficial effects of the present invention are:

[0046] A local railway disaster prevention controller monitors the status of disaster prevention lighting and evacuation indicator lights through a digital twin. Through local collaborative decision-making and scenario simulation, it automatically executes adjustments to emergency lighting and evacuation signs, as well as zoned dimming, ensuring clear evacuation routes and reasonable lighting coverage. Through a cross-validation-based local consensus mechanism, it can effectively identify and isolate single-point equipment failures or data anomalies, and conduct scenario simulations of contingency plans, effectively avoiding secondary risks caused by misoperation.

[0047] Meanwhile, by constructing and utilizing a dynamic contingency plan knowledge graph, combined with multi-objective optimization and sand table simulation, the controller generates and verifies the optimal handling plan locally based on the real-time situation, effectively addressing situations such as equipment aging and sudden environmental changes; by establishing and maintaining a dynamic baseline health model for each physical device, it achieves in-depth perception and health assessment of the multi-dimensional operating status of the equipment; through local collaborative processes and intelligent communication processing modules, the controller can quickly exchange verification information with associated devices, form local situational consensus, and collaboratively execute contingency plans, reducing false alarm rates. Attached Figure Description

[0048] Figure 1 This is a schematic diagram of the overall architecture of the controller of the present invention;

[0049] Figure 2 This is a schematic diagram of the baseline health model construction method of the present invention;

[0050] Figure 3 This is a schematic diagram of the health status assessment method of the present invention;

[0051] Figure 4 This is a schematic diagram of the local collaborative decision-making method of the present invention;

[0052] Figure 5 This is a schematic diagram of the local plan library construction method of the present invention;

[0053] Figure 6 This is a schematic diagram of the execution method of the present invention. Detailed Implementation

[0054] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] like Figure 1As shown, this invention provides a technical solution: a railway disaster prevention local controller. The railway disaster prevention local controller (hereinafter referred to as the controller) of this embodiment is deployed inside a railway tunnel, and its hardware includes a processor, a memory, and a communication interface. In terms of software, the controller runs a digital twin management module, a collaborative decision-making execution module, and an intelligent communication processing module.

[0056] The digital twin management module is used to create and maintain digital twins for each physical device on the communication bus. Based on the real-time operating data stream of the physical device and the pre-stored baseline health model, it calculates the dynamic deviation and generates health status assessment results.

[0057] like Figure 2 As shown, the present invention provides a method for constructing a benchmark health model;

[0058] Specifically:

[0059] Step 1: Guide the physical device to operate under preset standard operating conditions, record its multidimensional response data sequence, and obtain the device baseline fingerprint data.

[0060] It is important to note that when new equipment is connected to the system, the controller initiates a baseline health model learning program. Taking railway tunnel lighting fixtures as an example, the controller sends instructions to the fixture via the communication bus, instructing it to operate stably for a sufficient time (e.g., 30 minutes) under each of the following preset standard operating conditions, and to collect data at a fixed frequency (e.g., 1Hz): ambient temperature T a =25±2℃, operating power P=100%; T a =40±2℃, P=80%; T a =5±2℃, P=30%. The collected multidimensional response data sequence includes: voltage U, current I, and lamp housing temperature T. c Junction temperature T j Illuminance (L), ambient temperature (T) a After removing transient data during the start-up and shutdown phases, the arithmetic mean and standard deviation of the steady-state data for the last 20 minutes under each operating condition are calculated to form the baseline fingerprint data for that operating condition.

[0061] Step 2: Classify the benchmark fingerprint data based on operating mode, load and environmental factors, and fit to generate several interrelated benchmark feature curves to form a multimodal benchmark curve family.

[0062] It should be noted that, for the current I, the least squares method is used to perform binary linear regression fitting on the benchmark fingerprint data of the above three sets of operating conditions to generate the benchmark characteristic curve function: I(P,T) aThe equation is: a × P + b × Ta + c; where the coefficients a, b, and c are obtained by solving a system of linear equations derived using the least squares method. The required coefficients R0 of the fit are: 2 >0.95. Similarly, for T j Similarity fitting is performed using parameters such as [parameter 1]. The set of all fitted functions is then used to construct a family of multimodal baseline curves.

[0063] Step 3: For each characteristic curve in the family of reference curves, based on the data dispersion and the criticality of the equipment, dynamically calculate the time-varying confidence interval for each prediction point on the characteristic curve, and define the normal fluctuation range of that point.

[0064] It is important to note that for any prediction point on the baseline characteristic curve, the predicted value of the parameter, such as I... 预测 =I(P,T a The width of the time-varying confidence interval at this point is jointly determined by the standard deviation σ of the current data under this operating condition during the acquisition phase and the parameter criticality coefficient k; the smaller the value of k, the narrower the interval width, and the more stringent the monitoring. The controller has a built-in parameter criticality mapping table: High criticality (k=2), parameters directly related to safety, junction temperature T. j Current I; Medium criticality (k=3), parameter related to core functions, illuminance L; Low criticality (k=4), parameter susceptible to environmental influences, casing temperature T. c Then parameter I is in (P,T) a The time-varying confidence interval under the operating condition is [I 预测 -kσ,I 预测 +kσ].

[0065] Step 4: Establish the logical connections and transformation relationships between each benchmark characteristic curve to form a working condition association map that describes the working condition switching logic.

[0066] It should be noted that the aforementioned operating condition correlation graph is a directed graph structure, where nodes represent different stable operating conditions; edges represent operating condition switching paths and are labeled with switching conditions. The controller internally maintains an operating condition state transition table, for example: ambient temperature T. a If the temperature exceeds 35°C for 5 consecutive minutes, a switch from full power at room temperature to reduced power at high temperature is triggered, using the high-temperature group's reference characteristic curve. The transfer process employs a first-order inertial element for smooth transition, with a time constant set to 120 seconds.

[0067] Step 5: Integrate and encapsulate the aforementioned family of baseline curves, time-varying confidence intervals, and operating condition correlation maps into an embedded baseline health model service that can be called by the digital twin in real time, providing a standardized function call interface. Input the current time and operating condition parameters, and output the expected sequence of each monitoring parameter and its corresponding confidence interval sequence over a future period.

[0068] like Figure 3As shown, the present invention provides a method for assessing health status;

[0069] Specifically:

[0070] Step 1: Synchronously segment the real-time device operation data stream according to a preset time scale and align it with the corresponding scale expected sequence generated by the benchmark health model.

[0071] It is important to note that during real-time operation, the controller resamples and analyzes the data stream at three parallel scales: second-level (e.g., 1Hz), minute-level (e.g., 1 / 60Hz), and hour-level (e.g., 1 / 3600Hz). Simultaneously, it calls the baseline health model service to obtain the expected sequence at the same time scale and performs strict time alignment.

[0072] Step 2: For each monitoring parameter at each time scale, dynamically assign weights based on its current operating condition importance and historical statistical noise, and calculate its weighted deviation from the expected sequence based on this.

[0073] It is important to note that for each aligned monitoring parameter i at time t, its weighted deviation component d is calculated. i(t) :

[0074]

[0075] Where, x i(t) This is the measured value; E i(t) The expected value output by the baseline monitoring model; CI i(t) W is the width of the time-varying confidence interval. i(t) The dynamic weights are calculated using the following formula:

[0076]

[0077] Where W0 is the base weight of the parameter, such as I being 0.4, L being 0.30, and T being 0.4. c Take 0.1; 'a' is an adjustment factor, which can be 0.1; the noise variance is the variance of this parameter over a past period (e.g., 1 hour) after removing the linear trend. The comprehensive weighted deviation D(t) at each time scale is the sum of the weighted deviation components of all parameters at that scale:

[0078] D(t) = Σd i(t)

[0079] Step 3: Extract dynamic pattern features from the time series of weighted deviations of each monitoring parameter; the dynamic pattern features include the steady-state level, trend of change, periodic fluctuation pattern and sudden peak characteristics of the deviation.

[0080] It is important to note that real-time signal processing is performed on the D(t) sequence (e.g., minute-level D(t) sequence of the past 30 minutes) to extract features: steady-state level, calculating the moving average of D(t) within a recent time window (e.g., the past 5 minutes), reflecting the persistence and severity of the anomaly; trend, performing linear fitting on the D(t) sequence to obtain its slope, with a positive slope indicating accelerated performance degradation and a negative slope indicating mitigation; periodic fluctuations, performing zero-mean processing on the data within the window, then performing frequency domain analysis (e.g., Fast Fourier Transform) on the D(t) sequence to calculate the normalized amplitude of each frequency component, identifying significant frequency components whose normalized amplitude exceeds a preset threshold (e.g., 5% of total energy); and sudden spikes, calculating the first difference of the D(t) sequence, marking points where the absolute value of the difference exceeds a preset threshold (e.g., 3 times the standard deviation of the D(t) sequence) as spikes.

[0081] Step 4: Based on the preset fusion rules, perform fusion analysis on the extracted dynamic pattern features to generate device health status results with confidence assessment.

[0082] It is important to note that, to achieve the same decision across multiple timescales, features extracted from second-, minute-, and hour-scale features are organized into a multi-dimensional feature vector. This feature vector is input into a rule-based inference engine or a lightweight classification model (such as a decision tree). The fusion rule is as follows: if the second-scale features show a sudden spike and the minute-scale steady-state level increases significantly and synchronously, it is judged as a "sudden failure" with high confidence (e.g., 0.6); if the hour-scale features show a stable positive growth trend, while the second- and minute-scale features are normal, it is judged as "performance degradation" with medium confidence (e.g., 0.4). The inference engine integrates all features and outputs a qualitative health status result and a quantified confidence level.

[0083] Step 5: Encode the equipment health status results into a structured health status vector. The health status vector includes the health level (e.g., normal, sudden failure, performance degradation), major abnormal parameters, dominant deviation mode, confidence level, multi-scale weighted deviation value, and abnormal start time.

[0084] The collaborative decision-making and execution module is used to initiate a local collaborative process when the health status assessment is abnormal. It exchanges security-verified status data with the associated device group to form a local situational consensus, and queries the local contingency plan library based on the consensus to generate and execute control commands.

[0085] like Figure 4 As shown, the present invention provides a local collaborative decision-making method;

[0086] Specifically:

[0087] Step 1: When the digital twin determines that it is abnormal, it immediately securely broadcasts a collaboration request carrying a digital signature and anomaly digest to the predefined associated device group.

[0088] It is important to note that when any digital twin of a device (taking initiator A as an example) malfunctions and its confidence level exceeds a preset threshold (e.g., 0.7), the local collaboration process is immediately triggered. Initiator A generates a structured collaboration request message, which includes at least: a unique collaboration session ID, the initiator device ID, a timestamp, a summary of its own health status assessment, and the expected goal of this collaboration (e.g., confirming the scope of the anomaly). Initiator A uses the controller's asymmetric encryption private key (e.g., based on the ECDSA algorithm) to sign the entire collaboration request message, generating a digital signature. The collaboration request message and the digital signature are encapsulated together and broadcast over the communication network with the highest communication priority to a predefined group of associated devices (based on physical topology and functional association).

[0089] Step 2: The digital twins of each associated device that receive the collaboration request generate and return a trusted evidence package containing proof of its current health status and data integrity.

[0090] It is important to note that after receiving and verifying a valid collaboration request, the digital twins of each device within the associated group perform the following operations to generate trusted evidence: immediately read their own latest complete health status vector; each digital twin maintains a monotonically increasing counter, calculates a message authentication code using a keyed hash function with the current counter value and the health status vector, and uses the counter value and message authentication code together as proof of data integrity; and packages their own health status vector, counter value, and message authentication code into a trusted evidence package and directly replies to the initiator A of the collaboration request.

[0091] Step 3: The collaborating party verifies the source and content of all collected feedback evidence, assigns weights to the feedback evidence based on the historical credibility of each device, and performs weighted fusion.

[0092] It is important to note that initiator A collects trusted evidence packets from all respondents within a preset time window (e.g., 200 milliseconds) and performs the following operations: First, it verifies the message authentication code of each trusted evidence packet to ensure the data originates from the claimed device and has not been tampered with; simultaneously, it checks if the counter value is greater than the value last received from that device to ensure data freshness. Then, it assigns weights to the verified evidence based on historical credibility, current self-assessed confidence, and physical distance.

[0093]

[0094] The historical credibility is initially set at 1.0. If each device in the association group provides evidence and it is subsequently verified to be correct, the credibility is multiplied by 0.99; if it is incorrect, the credibility is multiplied by 0.8.

[0095] Step 4: Identify and arbitrate descriptive conflicts between different pieces of evidence. Through weight comparison and contextual analysis, resolve the conflicts and generate a unified situational outcome.

[0096] It is important to note that this step resolves conflicting evidence through a multi-rule arbitration mechanism, specifically including: the proximity principle, assigning higher weight to evidence from spatially adjacent devices (such as those in the same power supply circuit) (e.g., multiplying the weight by 1.2); causal chain verification, examining the physical / logical causal relationship between conflicting evidence, for example: if the current of initiator A is abnormal, while the current of the adjacent downstream device B is normal, it strongly supports the fault of initiator A; if the currents of initiator A and upstream power supply device C are both abnormal, it strongly supports the fault of the power supply circuit; expert rules, embedding domain knowledge, such as if a single lamp is overloaded while the current of other lamps in the circuit is zero, it strongly supports the fault of that lamp or branch. By comprehensively comparing the tendencies of the weighted evidence and applying the above rules for logical judgment, a unified situational outcome is formed after resolving conflicts. This outcome includes a core situational summary, anomaly description, possible scope of impact, and the status of the involved equipment.

[0097] Step 5: Encapsulate the unified situation results, key evidence index, and arbitration basis into a verifiable local situation consensus record, and distribute it to all participating parties for local storage and confirmation.

[0098] It is important to note that the local situation consensus record adopts a standardized data structure (such as JSON format) and contains fixed fields. The hash value of the record content is calculated, and the hash value is signed using the controller's private key. The complete record and its digital signature are broadcast to all participating devices. Upon receiving the record, each device independently verifies the signature and hash to confirm the validity of the consensus and stores it locally. When more than a certain percentage (e.g., 2 / 3) of the participants confirm the storage of a valid local situation consensus record within a preset time (e.g., 500 milliseconds), the final local situation consensus is considered to have been reached.

[0099] like Figure 5 As shown, the present invention provides a method for constructing a local contingency plan library;

[0100] Specifically:

[0101] Step 1: Deconstruct the risk events, equipment status, and handling operations in the railway tunnel disaster prevention scenario into combinable standardized elements; the standardized elements include event triggering conditions, situational impact range, local available resources, and preset target actions.

[0102] It is important to note that the event triggering condition describes the initial state of the anomaly or risk; the scope of the situational impact describes the spatial and logical scope that the event may affect; the locally available resources describe the current status of the available devices or resources; and the preset target action describes the atomic control operation to be performed.

[0103] Step 2: Based on the physical causal relationships, functional substitutions, and spatial topological relationships between devices, standardized elements are dynamically connected as nodes to construct a dynamic contingency plan knowledge graph that supports situational analysis and path discovery.

[0104] It is important to note that in the controller's built-in graph database (such as Neo4j), node types and relationship types are defined. Node types include: event, resource, action, and constraint. Relationship types include: cause, need, produce, substitute, spatial proximity, and constrained by.

[0105] Analyzing historical event sequence data, the causal strength between different event types is calculated (e.g., using transfer entropy), automatically creating or reinforcing "causing" edges. Based on equipment technical specifications (e.g., luminous flux and illumination angle of lamps) and location information, the functional overlap between equipment is calculated. If the overlap exceeds a threshold (e.g., 70%), "substitutable" edges are established. Based on the installation mileage coordinates of all equipment, spatial nearest neighbor edges are established using the fixed-radius nearest neighbor method, forming a spatial relationship network of tunnel equipment. Industry safety regulations (e.g., upwind evacuation during a fire) are transformed into "constrained by" edges in the graph. This constructs a dynamic contingency plan knowledge graph, whose nodes and edges dynamically evolve with the addition or removal of equipment, rule updates, and historical learning.

[0106] Step 3: Input the key elements of historical events into the contingency plan knowledge graph for forward extrapolation to generate theoretical handling paths. Compare these paths with historically validated and effective execution paths to label the effective confidence level and historical success rate of different response paths in the contingency plan knowledge graph.

[0107] It is important to note that the controller maintains a timestamped historical event-action database. When a learning cycle is triggered, the following operations are performed: A completed historical event case is selected from the database, and its initial event triggering conditions and situational impact range are extracted as input for the dynamic contingency plan knowledge graph query. Starting from the extracted initial event node, a search is performed in the dynamic contingency plan knowledge graph (e.g., limited depth-based search, heuristic path search) to explore all subsequent event nodes that may be triggered through cause-and-effect relationships, as well as all action-resource paths that can be invoked through necessary relationships. The search depth and breadth are limited by predefined logical constraints, ultimately generating multiple theoretical disposal paths from the initial state to the expected stable state.

[0108] The theoretical disposal paths obtained from the search are compared with the execution paths that have been actually adopted and verified to be effective in the historical cases. Algorithms based on edit distance or node sequence matching degree are used to calculate the similarity between each theoretical disposal path and the historical execution paths. Based on the time consumption and resource consumption data in the actual execution records, the efficiency indicators that each theoretical disposal path may produce when actually executed are evaluated. The following attributes are added to the edges of the theoretical disposal paths in the graph: historical success count, average effectiveness, and confidence. The expression for the average effectiveness is:

[0109]

[0110] The initial value of the confidence level is 1, and the expression is:

[0111]

[0112] Step 4: Encapsulate the paths in the contingency plan knowledge graph that reach the confidence threshold into a structured, executable sequence of contingency plan instructions, and dynamically calculate their contextualized priorities by combining the real-time resource status and environmental constraints of the current device group.

[0113] It is important to note that paths with a confidence level exceeding a preset threshold (e.g., 0.7) are pre-compiled into executable contingency plan instruction sequences, while paths with a confidence level below the threshold are retained as paths awaiting verification. When matching and selecting contingency plans, a scenario priority score S is dynamically calculated for each matched contingency plan.

[0114]

[0115] Among them, matching degree refers to the degree of matching between the current event characteristics and the triggering conditions of the contingency plan (e.g., calculating cosine similarity); the estimated execution cost of the contingency plan refers to the estimated resource consumption (e.g., energy consumption, equipment wear and tear) and time cost of executing the contingency plan, which can be estimated based on the real-time status of currently available resources; failure risk is the risk assessment of the contingency plan's failure, based on the degree of compliance between the current environmental constraints (e.g., communication quality) and the contingency plan's execution requirements; α, β, γ, and δ are weight coefficients, set as follows: the initial weight setting is based on reliability, such as α = 0.4, β = 0.3, γ = 0.2, and δ = 0.1; they can be dynamically adjusted under different emergency modes, such as temporarily increasing β and γ under fire emergency mode, adjusting them to α = 0.2, β = 0.4, γ = 0.3, and δ = 0.1. Finally, the contingency plans are arranged in descending order of situation priority scores to form a recommended contingency plan list.

[0116] Step 5: Based on the feedback from the local execution effect of the contingency plan, adaptively calibrate the path parameters and confidence level, and synchronize the contingency plan knowledge with the superior monitoring system in both directions.

[0117] It is important to note that feedback on the effectiveness of the contingency plan execution includes: whether the preset safety target (such as the target area illuminance) has been achieved, the actual total execution time, resource consumption, and whether secondary alarms have been triggered. The confidence adaptive calibration method includes: each contingency plan path is associated with a success counter and a failure counter. After each contingency plan execution, based on its effectiveness evaluation results: if successful, the success counter is incremented by 1 (or an additional quality coefficient based on completion quality); if unsuccessful, the failure counter is incremented by 1 (or an additional quality coefficient based on the degree of failure). The current confidence level of this path is calculated in real time as follows:

[0118] Current confidence level = Success count / (Success count + Failure count)

[0119] Path parameter (such as delay time and substitution efficiency) calibration methods include: for numerical parameters on the path, maintaining their current estimates and the number of observations, and updating them each time a new observation is obtained according to the following formula:

[0120] Current estimate = (Current estimate × Number of observations + New observation) / (Number of observations + 1)

[0121] The bidirectional synchronization of contingency plan knowledge with the superior monitoring system includes: uploading, periodically packaging and reporting locally added contingency plan paths with confidence changes exceeding a threshold (e.g., ±0.1) into structured summaries; and distributing and merging, accepting global contingency plans or parameter updates from the superior system; if there is a conflict with local knowledge, comparing the confidence levels and number of practices of both, prioritizing the one with more practice data; if they are similar, temporarily retaining them in parallel and marking them as conflicting for subsequent data adjudication.

[0122] like Figure 6 As shown, the present invention provides a method for implementing a contingency plan;

[0123] Specifically:

[0124] Step 1: Analyze the local situation consensus record and extract key feature vectors that include anomaly type, scope of impact, status of involved equipment, real-time environmental constraints, and confidence level of uncertainty in the consensus.

[0125] It is important to note that the digital signature at the end of the record is verified using pre-stored public keys of the participating parties to ensure that the record has not been tampered with during transmission and that its source is trustworthy. After successful verification, the local situation consensus record is decoded. From the decoded records, the following core fields are extracted to form a key feature vector for contingency plan matching: Anomaly type, extracted from the "core situation summary" of the local situation consensus record and encoded as an enumeration value or a specific string; Impact range, extracted from the "potential impact range" of the local situation consensus record, including spatial range (e.g., 20-meter sections upstream and downstream of device G) and logical range (e.g., the same power supply circuit, the same ventilation zone), the spatial range can be converted into a tunnel mileage interval representation; Status of the involved equipment, extracted from the "status of the involved equipment" list in the local situation consensus record, each equipment status is a sub-vector, including equipment ID, health level, main anomaly parameters, and confidence level; Real-time environmental constraints, combined with contextual information in the local situation consensus record (e.g., high ambient temperature) and data read in real time from environmental sensors to form a constraint vector; Uncertainty confidence level, extracted from the local situation consensus record regarding the uncertainty measure of the overall judgment, this value is the result of weighing the weights of each conflicting piece of evidence during the collaborative arbitration phase, a scalar between 0 and 1, the lower the value, the higher the uncertainty of the consensus.

[0126] Step 2: Perform multi-dimensional matching between the key feature vectors and the dynamic contingency plan knowledge graph in the local contingency plan library to generate a candidate contingency plan list sorted by context matching degree and expected utility.

[0127] It is important to note that the anomaly type and impact range from the key feature vector are used as the initial query nodes. All event type nodes in the dynamic contingency plan knowledge graph are searched, provided their "triggering condition" attribute has a similarity exceeding a preset threshold (e.g., 0.8 if word vector-based similarity calculation is used). For each matching initial event node, a finite-depth traversal (e.g., depth 3) is performed along relational edges such as "caused" and "generated" to search for all possible subsequent event chains and collect the associated "action" nodes and required "resource" nodes. Each traversal forms a path from the initial event to a stable state achieved through a series of "actions"—a theoretical disposal path. Each path contains an action sequence and its corresponding resource requirement list.

[0128] The context matching degree is calculated by determining the degree of matching between the current key feature vector and the triggering conditions and resource requirements of the theoretical response path. For example, it checks whether the "status of the involved equipment" and "real-time environmental constraints" in the key feature vector meet the resource status and execution conditions required for each action in the theoretical response path. A weighted average method is used: 1 point for complete satisfaction, 0.5 points for partial satisfaction, and 0 points for non-satisfaction. The final weighted average yields the context matching degree (between 0 and 1). The expected utility is calculated comprehensively based on the historical success rate, average effectiveness, and expected execution cost (estimated in real-time based on currently available resources) of the theoretical response path stored in the dynamic contingency plan knowledge graph. The calculation formula is as follows:

[0129] Expected utility = w1 × historical success rate + w2 × average effectiveness - w3 × expected execution cost

[0130] w1, w2, and w3 are adjustable weights that can be set according to the operation and maintenance strategy. For all matched theoretical handling paths, a comprehensive path score is calculated using the following formula:

[0131] Path comprehensive score = ρ × situation fit degree + λ × expected utility - ε × (1 - uncertainty confidence level)

[0132] Where ρ, λ, and ε are adjustable weights; the (1 - uncertainty confidence level) term is used to penalize consensus with high uncertainty. All theoretical solutions are sorted in descending order of comprehensive score to generate a candidate plan list.

[0133] Step 3: Based on the current local situation, select the plan logic flow from the candidate plan list through a preset multi-objective optimization function, and dynamically bind and instantiate the parameters in the logic flow with the current local situation data.

[0134] It should be noted that in the emergency response scenario for railway tunnel disaster prevention, the multi-objective optimization function Z... j The optimization objectives include: maximizing the success rate of handling, maximizing response and execution speed, maximizing robustness, and minimizing secondary risks. The success rate E... j The calculation formula is as follows: The formula is adjusted by combining the historical success rate and current situational matching degree stored in the contingency plan knowledge graph, as well as the uncertainty confidence level of local situational consensus.

[0135]

[0136] Where λ is the uncertainty penalty coefficient (e.g., 0.5). The response and execution speed V... j Calculate the estimated total time t from the triggering of the contingency plan to the generation of critical safety effects. j The reciprocal of the product is calculated using the following formula:

[0137]

[0138] Where ζ is a small constant to prevent division by zero; t j This includes communication latency, device operation time, and the time required for physical processes (such as the time it takes for the lamps to reach the expected illuminance). The robustness R... j The assessment evaluates the ability of the contingency plan to achieve core security objectives even when some devices may fail or experience performance degradation. This is based on an analysis of the "substitutable" relationship edges in the contingency plan's knowledge graph and the health status of the device digital twins. Assume the contingency plan depends on associated device group D, where device d has a current health status confidence level of h. d Calculate the (h) of each critical device d in the dependency chain. d +θ×degree of substitution d The minimum value among these is taken as the reliability score of the contingency plan. The calculation formula is as follows:

[0139]

[0140] Among them, the degree of substitution d The functional substitutability of device d is between 0 and 1; θ is the redundancy weight coefficient. The secondary risk SR... j Quantify the new risks that may arise from the implementation of the contingency plan, such as the possibility that cutting off lighting in non-disaster areas may lead to evacuation chaos. When constructing the contingency plan knowledge graph, each action node can be associated with an edge indicating a "potential risk" and a risk level r. The secondary risks of the contingency plan can then be calculated as follows:

[0141]

[0142] Where Ⅱ is an indicator function, it is 1 if the condition is met, and 0 otherwise. The expression for the multi-objective optimization function is then:

[0143]

[0144] Among them, w E w V w R w SR This is a dynamic scenario weight, determined dynamically based on the current disaster type and emergency mode. For example, in a fire mode, w E Take 0.5, w V Take 0.3, w R Take 0.15, w SR Set to 0.05; Equipment fault early warning mode, w E Take 0.2, w V Take 0.1, w R Take 0.4, w SR Take 0.3.

[0145] In any mode, the success rate must reach a minimum threshold (e.g., 0.6). Based on the hard constraint of security effectiveness, candidate plans are filtered. For the filtered plans, their success rate, response and execution speed, robustness, and secondary risks are calculated, and all candidate plans are linearly normalized to the [0,1] interval. Then, based on the dynamic weights of the current mode, a comprehensive score is calculated:

[0146]

[0147] Finally, select the logic flow with the highest overall score. If the difference between the highest and second-highest scored logic flows is less than a preset percentage (e.g., 5%), then V is selected first. j A faster contingency plan logic flow.

[0148] The parameters of the contingency plan logic flow are dynamically bound to and instantiated with the current local situation data. Specifically, this includes replacing the variables in the selected contingency plan logic flow template with specific values ​​extracted from the current local situation to generate an executable contingency plan instance. The local situation data includes: data in the local situation consensus record, i.e., the key feature vector extracted in step 1; and real-time data from the digital twin management module, which, during instance instantiation, queries the digital twins of relevant devices in real time to obtain their state information that may not be included in the consensus record.

[0149] Step 4: Input the instantiated contingency plan and the complete data of the current local situation into the real-time sand table model built based on the digital twin of the local equipment group for simulation; analyze the deviation between the simulation results and the expected goals, and dynamically adjust the contingency plan parameters or trigger path switching based on the potential conflicts exposed during the simulation.

[0150] It is important to note that the real-time sandbox model is a lightweight discrete event simulation environment that integrates relevant device digital twin behavior models (such as state-event response tables) and preset simplified physical / logical rules (such as a simplified smoke diffusion model). To ensure the real-time performance of the simulation, the model uses a fixed time step (such as 100 milliseconds) and limits the simulation scope to devices directly related to the contingency plan and their immediate surrounding environment. The simulation process simulates the step-by-step execution of the contingency plan instruction sequence and predicts the system state changes after each step based on the device model and rules. If the deviation between the simulation result and the expected target is within an acceptable range (such as ±10%) and no serious conflicts are exposed, the simulation passes verification. If the deviation is acceptable but there is room for optimization, certain parameters in the contingency plan instance are automatically fine-tuned (such as adjusting the turn-on sequence or power of backup lights), and the simulation is repeated. If the simulation exposes serious logical conflicts (such as resource contention), physical infeasibility (such as power over-limit), or failure to achieve the core safety objective, the simulation is immediately backtracked, and the logic flow of the contingency plan with the second highest comprehensive score is selected from the candidate contingency plan list for re-instantiation and simulation. If none of the proposed solutions in the candidate solution list are ideal, new feasible paths can be searched in real time in the solution knowledge graph based on the new constraints exposed during the simulation. If the search is successful, the solution will be used as a temporary solution for simulation and verification, and will be learned as new knowledge after the success.

[0151] Step 5: Decompose the contingency plan instance verified by simulation into serialized atomic control instructions and issue them to the corresponding control mechanism; based on real-time feedback and preset fault tolerance and degradation rules, adaptively switch between different branches of the instruction sequence.

[0152] It is important to note that feedback signals from the executing device are continuously monitored during the execution of the command sequence. Pre-defined fault tolerance and degradation rules are in place. For example, if no confirmation of activation is received within 200 milliseconds after a command to turn on a backup light is issued, and no change in line current is detected, the command is considered to have failed. Once a fault tolerance rule is triggered, the controller immediately switches between predefined branch paths in the contingency plan instance. For instance, after the backup light fails to turn on, it automatically switches to the degradation branch, skips the command, increases the power of the two adjacent non-backup lights to compensate for the illuminance, and reports an alarm.

[0153] The intelligent communication processing module is used to evaluate the reporting value of newly collected data based on the dynamic numerical distribution model of monitoring parameters, and encapsulate the abnormal data that is determined to be reported, along with the corresponding diagnostic information and local situation consensus, into structured semantic intelligence for reporting.

[0154] The method for constructing the dynamic numerical distribution model specifically includes:

[0155] Step 1: Define typical operating conditions for each monitoring parameter, and establish corresponding baseline probability distributions based on historical normal data under each typical operating condition to form an initial multi-operating condition distribution library.

[0156] It is important to note that during the system debugging and learning period or the equipment health operation period, the historical normal data of each monitoring parameter should be clustered according to the operating condition label. For the data under each operating condition, distribution fitting should be performed, such as using Gaussian kernel density estimation to generate a baseline probability density function. The kernel bandwidth can be adaptively calculated using the Silverman rule combined with the actual dispersion of the data within the operating condition. All probability density functions and their corresponding operating conditions should be stored to form an initial multi-operating condition distribution library.

[0157] Step 2: Maintain a fixed-capacity (e.g., 3600) first-in-first-out sliding window for each monitoring parameter. When new data enters, apply a time decay weight to the historical data within the window to enhance the impact of recent data.

[0158] It's important to note that when a new data point enters the window, a time-based decay weight is calculated for all data points within the window. For the y-th data point within the window, its timestamp is t. y Then its weight is:

[0159]

[0160] Among them, T 1 / 2 The half-life is dynamically set based on the rate of parameter change. For rapidly changing parameters (such as current), a shorter half-life is set (e.g., 10 minutes), while for slowly changing parameters (such as equipment aging trends), a longer half-life is set (e.g., 24 hours). now At the current moment, the values ​​of all data points within the window are correlated with their decay weights to form a weighted sample set.

[0161] Step 3: Identify the current operating condition of the equipment in real time, and adaptively fuse the sliding window data with the baseline probability distribution of the corresponding operating condition in the initial multi-condition distribution library to generate a conditional dynamic numerical distribution model that reflects the current situation.

[0162] It is important to note that when new data points arrive, the feature vector of the current operating condition is constructed in real time, and its similarity (e.g., Euclidean distance) with the feature vectors of each benchmark operating condition in the initial multi-operating condition distribution library is calculated. Several benchmark operating conditions (e.g., 3) that best match the current operating condition and their corresponding benchmark probability distributions are selected, and these benchmark probability distributions are weighted and averaged according to similarity to obtain a comprehensive benchmark fusion distribution. Using the weighted sample set within the current sliding window, an online probability distribution reflecting the recent actual operating status of the equipment is generated through a weighted kernel density estimation method. A dynamic confidence factor is introduced. By integrating the baseline fusion distribution and the online probability distribution, a conditional dynamic numerical distribution model is generated, the expression of which is:

[0163]

[0164] Among them, confidence factor Between 0 and 1, the calculation formula is:

[0165]

[0166] Where, n 有效 D is the number of valid weighted samples within the window; KL The KL divergence is the distance between the baseline fusion distribution and the online probability distribution.

[0167] Step 4: Based on the conditional dynamic numerical distribution model, calculate and update the dynamic probability boundary threshold used to determine the price value on the data in real time.

[0168] It is important to note that, based on the current conditional dynamic numerical distribution model, its dynamic probability boundary threshold is calculated to ensure that the probability of a data point falling within this interval is a preset value (e.g., 99%). For newly collected data points, if they fall within the interval, they are considered normal fluctuations and are only used for local updates, not reported; otherwise, they proceed to the next step of multidimensional evaluation.

[0169] The calculation of the multidimensional evaluation factors includes: anomaly significance, calculated based on the probability density of the data point under the current distribution model; the lower the probability, the higher the significance. Anomaly persistence, calculated based on the proportion and deviation trend of the parameter in recent data; continuous deviation results in a high persistence score. Correlation and synergy, calculated based on whether other parameters with physical or functional connections to the parameter are synchronously abnormal; synergistic anomalies result in a high synergy score. A weighted summation is used to calculate the comprehensive reporting value score: Comprehensive Reporting Value Score = w4 × Anomaly Significance + w5 × Anomaly Persistence Score + w6 × Correlation and Synergy Score. The weights w4, w5, and w6 can be dynamically allocated according to the parameter's criticality; high-criticality parameters emphasize significance and synergy, while medium- and low-criticality parameters emphasize persistence. A reporting threshold is set (e.g., 0.7). If the comprehensive reporting value score exceeds the reporting threshold, it is determined to be a high-value anomaly requiring reporting, triggering the encapsulation and reporting process; otherwise, it is determined to be a low-value anomaly or noise, and only recorded locally. The initial reporting threshold can be obtained by training based on historical data in the early stages, and can be dynamically adjusted according to network bandwidth conditions during operation.

[0170] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended embodiments and their equivalents.

Claims

1. A local controller for railway disaster prevention, comprising a memory, a processor, and a communication interface, characterized in that: The digital twin management module is used to create and maintain digital twins for each physical device on the communication bus. Based on the real-time operating data stream of the physical device and the pre-stored baseline health model, it calculates the dynamic deviation and generates health status assessment results. The collaborative decision-making and execution module is used to initiate a local collaborative process when the health status assessment is abnormal, to form a local situational consensus by exchanging security-verified status data with the associated device group, and to query the local contingency plan library based on the consensus to generate and execute control commands. The intelligent communication processing module is used to evaluate the reporting value of newly collected data based on the dynamic numerical distribution model of monitoring parameters, and encapsulate the abnormal data that is determined to be reported, along with the corresponding diagnostic information and local situation consensus, into structured semantic intelligence for reporting.

2. A railway disaster prevention local controller according to claim 1, characterized in that: The method for constructing the benchmark health model includes: Guide the physical equipment to operate under preset standard operating conditions, record its multidimensional response data sequence, and obtain the equipment baseline fingerprint data; The baseline fingerprint data is classified based on operating mode, load and environmental factors, and several interrelated baseline feature curves are fitted to form a family of multimodal baseline curves. For each characteristic curve in the family of reference curves, based on the data dispersion and the criticality of the equipment, the time-varying confidence interval of each prediction point on the characteristic curve is dynamically calculated to define the normal fluctuation range of that point. Establish logical connections and transformation relationships between various benchmark characteristic curves to form a working condition association map describing the working condition switching logic; The aforementioned family of baseline curves, time-varying confidence intervals, and operating condition correlation maps are integrated and encapsulated into an embedded baseline health model service that can be called by the digital twin in real time.

3. A railway disaster prevention local controller according to claim 1, characterized in that: The calculation of dynamic deviation and generation of health status assessment specifically includes: The real-time device operation data stream is synchronously segmented according to a preset time scale and time-aligned with the corresponding scale expected sequence generated by the benchmark health model. For each monitoring parameter at each time scale, a weight is dynamically assigned based on its current operating condition importance and historical statistical noise, and its weighted deviation relative to the expected sequence is calculated accordingly. Dynamic pattern features are extracted from the time series of weighted deviations of each monitoring parameter; the dynamic pattern features include the steady-state level of deviation, the trend of change, the periodic fluctuation pattern and the sudden peak characteristics. Based on preset fusion rules, the extracted dynamic pattern features are fused and analyzed to generate device health status results with confidence assessment. The equipment health status results are encoded into a structured status vector; the status vector includes health level, major abnormal parameters, dominant deviation pattern, confidence level, and abnormal start time.

4. A railway disaster prevention local controller according to claim 1, characterized in that: The local collaboration process specifically includes: When the digital twin determines that it is abnormal, it immediately securely broadcasts a collaboration request carrying a digital signature and anomaly digest to the predefined associated device group; Each associated device's digital twin that receives the collaboration request generates and returns a credible evidence package containing its current health status and proof of data integrity. The collaborating initiator verifies the source and content of all collected feedback evidence, and assigns weights to the feedback evidence based on the historical credibility of each device, and performs weighted fusion. Identify and arbitrate descriptive conflicts between different pieces of evidence, resolve conflicts and generate a unified situational outcome through weight comparison and contextual analysis; The unified situation results, key evidence indexes, and arbitration basis are encapsulated into a verifiable local situation consensus record, which is then distributed to all participating parties for local storage and confirmation.

5. A railway disaster prevention local controller according to claim 1, characterized in that: The method for constructing the local contingency plan database includes: Risk events, equipment status, and handling operations in railway tunnel disaster prevention scenarios are deconstructed into composable standardized elements; the standardized elements include event triggering conditions, situational impact range, local available resources, and preset target actions; Based on the physical causal relationships, functional substitutions, and spatial topological relationships between devices, standardized elements are dynamically connected as nodes to construct a dynamic contingency plan knowledge graph that supports situational analysis and path discovery. Key elements from historical events are input into the contingency plan knowledge graph for forward extrapolation to generate theoretical handling paths. These paths are then compared with historically validated and effective execution paths to label the effective confidence level and historical success rate of different response paths in the contingency plan knowledge graph. The paths that reach the confidence threshold in the contingency plan knowledge graph are encapsulated into a structured and executable sequence of contingency plan instructions, and their contextualized priorities are dynamically calculated in combination with the real-time resource status and environmental constraints of the current device group. Based on feedback from the local implementation of the contingency plan, the path parameters and confidence level are adaptively calibrated, and the contingency plan knowledge is synchronized bidirectionally with the superior monitoring system.

6. A railway disaster prevention local controller according to claim 1, characterized in that: The step of querying the local contingency plan library based on the consensus to generate and execute control instructions specifically includes: The local situation consensus record is analyzed to extract key feature vectors that include anomaly type, scope of impact, status of involved equipment, real-time environmental constraints, and confidence level of uncertainty in the consensus. The key feature vectors are matched with the dynamic contingency plan knowledge graph in the local contingency plan library in multiple dimensions to generate a candidate contingency plan list sorted by context matching degree and expected utility. Based on the current local situation, a plan logic flow is selected from the candidate plan list through a preset multi-objective optimization function, and the parameters in the logic flow are dynamically bound and instantiated with the current local situation data; The instantiated contingency plan and the complete data of the current local situation are input into a real-time sand table model built based on the digital twin of the local equipment group for simulation; the deviation between the simulation results and the expected goals is analyzed, and the contingency plan parameters or path switching are dynamically adjusted based on the potential conflicts exposed during the simulation. The contingency plan instances verified through simulation are broken down into serialized atomic control instructions and issued to the corresponding control mechanisms; based on real-time feedback and preset fault tolerance and degradation rules, the instructions are adaptively switched between different branches of the instruction sequence.

7. A railway disaster prevention local controller according to claim 1, characterized in that: The method for constructing the dynamic numerical distribution model includes: For each monitoring parameter, define its typical operating conditions, and establish a corresponding baseline probability distribution based on the historical normal data under each typical operating condition to form an initial multi-operating condition distribution library. A fixed-capacity sliding window is maintained for each monitoring parameter. When new data enters, a time decay weight is applied to the historical data within the window to amplify the impact of recent data. The system identifies the current operating condition of the equipment in real time, and adaptively fuses the sliding window data with the baseline probability distribution of the corresponding operating condition in the initial multi-condition distribution library to generate a conditional dynamic numerical distribution model that reflects the current situation. Based on the conditional dynamic numerical distribution model, the dynamic probability boundary threshold used to determine the price value on the data is calculated and updated in real time.

Images