Intelligent auxiliary decision-making methods and systems applied to emergency command in urban rail transit systems

Abstract

This invention provides an intelligent auxiliary decision-making method and system for emergency command in urban rail transit systems, belonging to the field of urban rail transit technology. First, it constructs a digital twin covering all elements of the urban rail transit system, including trains, tracks, stations, power supply, and emergency resources. Each scenario is decomposed into independent twin units, and their physical entity status and location are synchronized. Based on the digital twin, abnormal trigger signals are captured, an event deconstruction chain is constructed, and resource combination schemes are generated by calling blockchain-stored data on urban rail emergency resources. Based on the resource combination schemes and the event deconstruction chain, trigger rules and execution logic for smart contracts are generated. The smart contracts are deployed to urban rail dispatching blockchain nodes, and parameters are optimized through digital twin simulation. When an abnormality meets the trigger rules, dispatching instructions are automatically generated and synchronized to the control terminal, achieving rapid and accurate emergency response and effectively ensuring the safe operation of the urban rail transit system.

Description

Technical Field

[0001] This invention relates to the field of urban rail transit technology, and more specifically, to an intelligent auxiliary decision-making method and system for emergency command in urban rail transit systems. Background Technology

[0002] During the operation of urban rail transit systems, numerous emergencies arise, such as train malfunctions, track damage, station overcrowding, and power supply system anomalies. These situations can severely impact the normal operation of the urban rail system and passenger safety. Traditional emergency command and decision-making methods primarily rely on human experience and pre-set, fixed emergency plans, lacking real-time, accurate perception and dynamic analysis of all elements of the urban rail system. When dealing with complex and ever-changing anomalies, it is difficult to quickly and accurately locate the source of the anomaly, determine the fault propagation path and scope of impact, and efficiently allocate emergency resources. This leads to untimely emergency response, unscientific decision-making, and an inability to effectively address various emergencies, posing significant risks to the safe operation of the urban rail system. Furthermore, existing technologies suffer from problems such as information opacity and low collaboration efficiency in emergency resource management and scheduling, making it difficult to achieve optimal allocation and efficient utilization of emergency resources. Summary of the Invention

[0003] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide an intelligent auxiliary decision-making method for emergency command in urban rail transit systems, the method comprising:

[0004] A digital twin of all elements of the urban rail transit system is constructed, which covers scenarios of trains, tracks, stations, power supply and emergency resources. Each scenario is decomposed into an independent twin unit. Each independent twin unit synchronizes the operating status and spatial location of the physical entity through a real-time sensing channel to realize the mapping between the physical world and the digital space.

[0005] By leveraging the dynamic perception capabilities of digital twins, abnormal trigger signals are captured, and the propagation trajectory of abnormal trigger signals among independent twin units is tracked. An event deconstruction chain is constructed, which includes the location of the abnormal source, the hierarchy of the affected independent twin units, and the fault propagation intensity. The fault propagation intensity reflects the difference in the degree of impact of the abnormality on different independent twin units.

[0006] By calling the blockchain-based evidence data of urban rail emergency resources, the event deconstruction chain is dynamically coupled with the independent twin unit of emergency resources to generate a resource combination scheme that covers resource adaptation characteristics, response efficiency and deployment order. The blockchain-based evidence data of urban rail emergency resources includes the attribute characteristics, storage location, maintenance records and availability status of emergency resources.

[0007] Based on the transmission characteristics of resource combination schemes and event deconstruction chains, triggering rules and execution logic of smart contracts are generated. The smart contracts are used to clarify the automatic execution process of scheduling instructions, the boundaries of rights and responsibilities for resource use, and the timing coordination requirements of emergency links. The timing coordination requirements standardize the action connection nodes and interaction methods of each participant.

[0008] The smart contract is deployed to the urban rail transit scheduling blockchain node. A simulation environment is built using a digital twin to simulate the contract execution process and optimize parameters. When an abnormal state meets the triggering rules, the smart contract automatically generates scheduling instructions and synchronizes them to the control terminal of the corresponding physical entity.

[0009] Furthermore, embodiments of the present invention also provide an intelligent auxiliary decision-making system for emergency command in urban rail transit systems, characterized in that it includes:

[0010] A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the aforementioned intelligent auxiliary decision-making method for emergency command of urban rail transit systems by executing the machine-executable instructions.

[0011] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, the processor of a computer device reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the computer device to execute the above-described intelligent auxiliary decision-making method for emergency command of urban rail transit systems.

[0012] Based on the above, by constructing a full-element digital twin of the urban rail transit system, a precise mapping between the physical world and the digital space is achieved. This enables real-time perception of the operational status and spatial location of each element of the urban rail transit system. Then, relying on the dynamic perception capabilities of the digital twin, abnormal trigger signals are captured and an event deconstruction chain is constructed. This allows for rapid location of the anomaly source, clarification of the affected scope and fault propagation intensity, and generation of resource combination schemes by invoking blockchain-stored data of urban rail emergency resources. This ensures the adaptability, response efficiency, and reasonable deployment sequence of emergency resources, improving their utilization efficiency. Based on the resource combination scheme and event deconstruction chain, smart contracts are generated, clarifying the automatic execution process of dispatch instructions, the boundaries of responsibility for resource use, and the timing coordination requirements of emergency links, achieving automation and collaboration in emergency command. A simulation environment is built using the digital twin to simulate the contract execution process and optimize parameters, improving the scientific nature and effectiveness of emergency command. When an abnormal state meets the triggering rules, the smart contract automatically generates dispatch instructions and synchronizes them to the control terminals of the corresponding physical entities, achieving rapid and accurate emergency response and effectively ensuring the safe operation of the urban rail transit system. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the execution flow of the intelligent auxiliary decision-making method for emergency command of urban rail transit systems provided in this embodiment of the invention.

[0014] Figure 2 This is a schematic diagram of exemplary hardware and software components of an intelligent auxiliary decision-making system for emergency command of urban rail transit systems provided in an embodiment of the present invention. Detailed Implementation

[0015] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating an intelligent auxiliary decision-making method for emergency command in urban rail transit systems, provided by an embodiment of the present invention. The following is a detailed description of this intelligent auxiliary decision-making method for emergency command in urban rail transit systems.

[0016] Step S110: Construct a full-element digital twin of the urban rail transit system. This full-element digital twin of the urban rail transit system covers scenarios of trains, tracks, stations, power supply and emergency resources. Each scenario is decomposed into an independent twin unit. Each independent twin unit synchronizes the operating status and spatial location of the physical entity through a real-time sensing channel to realize the mapping between the physical world and the digital space.

[0017] In the daily operation of urban rail transit systems, to achieve accurate mapping and efficient management of the physical world, it is necessary to construct the aforementioned full-element digital twin. Taking a city's subway line as an example, this line includes multiple trains, tens of kilometers of track, multiple stations, a complex power supply network, and various emergency resources. First, comprehensive data collection and model construction are carried out on the aforementioned physical entities, dividing the trains, tracks, stations, power supply, and emergency resources into independent twin units. Each independent twin unit is equipped with a dedicated real-time sensing channel to receive various operational status data and spatial location information from the physical entities. Through the real-time synchronization of this data, the digital twin can accurately reflect the current state of the physical world.

[0018] Step S111: Collect full-dimensional data of the physical entities of the urban rail system, and construct a high-precision basic twin model of each entity based on the above full-dimensional data. The above full-dimensional data covers geometric structure data, material attribute data, operating parameter data and correlation data. Among them, the geometric structure data includes the outline of the train body, the shape of the track cross section, the layout of the station buildings and the direction of the power supply line.

[0019] When constructing the basic twin model, it is necessary to collect comprehensive data on the physical entities of the urban rail transit system. For the train entity, this involves collecting data on its length, width, and height, as well as the geometric structure data such as the outlines of the front, carriages, and rear of the train. Simultaneously, it requires acquiring material property data such as the hardness and density of the metal materials used in the train body. Furthermore, it involves collecting operational parameter data such as speed, acceleration, traction, and braking force during train operation, as well as correlation data such as the connection methods between the train and the track and power supply system. For the track entity, this involves collecting data on the track's cross-sectional shape, gauge, rail material properties, and geometric structure data such as gradient and curvature at different locations. It also includes operational parameter data such as vibration frequency and stress of the track during train operation, and correlation data between the track and stations and power supply lines. Geometric structure data for station building layout includes the area and height of the concourse and platforms, and the location and number of entrances and exits. Material property data involves the fire resistance rating and load-bearing capacity of building materials. Operational parameter data includes temperature, humidity, and ventilation within the station. Correlation data includes the connection between the station and the track line, and the communication relationships between equipment within the station. The geometric data of the power supply line route includes the line path, tower location and height, etc.; material property data includes conductor conductivity, insulation performance of insulation materials, etc.; operating parameter data includes line voltage, current, etc.; correlation data involves the connection between the power supply line and power plants, substations, and various electrical equipment. Based on the above comprehensive data, high-precision basic twin models of each entity are constructed using 3D modeling technology and computer-aided design software. These models can accurately reproduce the physical entity's appearance features, internal structure, and material properties.

[0020] Step S112: Configure a multi-source sensing interface for each basic twin model and access the real-time monitoring data of the corresponding physical entity. The data accessed by the train independent twin unit includes driving status, braking feedback and passenger distribution in the carriages. The data accessed by the track independent twin unit includes track gauge shape, structural stress and vibration characteristics. The data accessed by the station independent twin unit includes pedestrian flow at entrances and exits, passenger gathering on the platform and occupancy of evacuation passages. The data accessed by the power supply independent twin unit includes voltage stability, current load and line insulation status.

[0021] After constructing the high-precision basic twin model, each model needs to be configured with multi-source sensing interfaces to enable real-time data interaction with physical entities. For the train independent twin unit, interfaces for speed sensors, acceleration sensors, braking system feedback, and cameras and infrared sensors within the carriage are configured. These interfaces allow real-time access to train speed, acceleration, braking pressure, braking distance, and other driving status data; braking system response time and brake pad wear, and other braking feedback data; as well as passenger distribution data such as the number and density of people in different areas of the carriage. The track independent twin unit is configured with interfaces for track gauge measurement, stress sensors, and vibration sensors to access real-time track gauge measurements, track structure stress distribution data, and vibration characteristic data such as vibration frequency and amplitude generated when the train passes. The station independent twin unit is configured with infrared counter interfaces for entrances and exits, video monitoring interfaces for the platform, and pressure sensor interfaces for evacuation routes to obtain data such as hourly passenger flow at entrances and exits, the number and density of people gathered in different areas of the platform, and whether and to what extent evacuation routes are occupied. The power supply independent twin unit is equipped with voltage sensor interface, current sensor interface and insulation resistance tester interface, etc., to receive real-time voltage value, current load and insulation resistance value of the line, so as to reflect voltage stability, current load and insulation status of the line. The configuration of the above multi-source sensing interface enables the basic twin model to receive various monitoring data of the physical entity in real time, thereby realizing dynamic synchronization between the digital twin and the physical world.

[0022] Step S113: Perform timestamp alignment and spatial coordinate calibration on the status data of each independent twin unit, and establish real-time binding between the train independent twin unit and the track independent twin unit through track mileage coordinates. The station independent twin unit and the emergency resource independent twin unit are associated through the station area grid coordinates. The power supply independent twin unit forms a linkage relationship with other independent twin units through the power supply network topology. The association relationship is dynamically adjusted according to the entity's operating status.

[0023] Since the status data of each independent twin unit comes from different sensing devices, their acquisition time and spatial coordinates may differ. Therefore, timestamp alignment and spatial coordinate calibration are required. For timestamp alignment, a precise timestamp is added to the status data of each independent twin unit using the unified clock of the urban rail system as a reference. A time synchronization algorithm is then used to adjust the data collected by different devices to the same time dimension. Spatial coordinate calibration involves uniformly converting and correcting the spatial location data of each entity according to the geographic information coordinate system of the urban rail system, ensuring that the spatial coordinates of all independent twin units are consistent within the digital twin. Train independent twin units and track independent twin units are linked in real-time using track mileage coordinates. During operation, the train's current position is represented by track mileage coordinates, and the digital twin can determine its specific position on the track independent twin unit in real time based on the train's mileage coordinates. Station independent twin units divide the station into multiple regional grids and assign unique coordinates to each grid. The storage location of the emergency resource independent twin unit is represented by the coordinates of the station's regional grid, thus achieving the association between the station independent twin unit and the emergency resource independent twin unit. Based on the topology of the power supply network, the independent power supply twin unit clarifies the connection relationship between each power supply line, substation and other independent twin units such as trains and stations. When the train's running position changes or the station's electrical equipment is turned on or off, the linkage relationship between the independent power supply twin unit and other independent twin units will be dynamically adjusted accordingly to accurately reflect the actual operation of the power supply system.

[0024] Step S114: Use layered rendering and dynamic highlighting technology to display the operating status of each independent twin unit.

[0025] To intuitively display the operational status of each independent twin unit, layered rendering and dynamic highlighting techniques are employed. In the visualization interface of the digital twin, different components of the urban rail system are rendered hierarchically. For example, the bottom layer displays basic geographic information of the track lines and stations; the middle layer renders dynamic operating entities such as trains and power supply lines; and the top layer displays various status indicators and alarm information. For each independent twin unit, different colors, textures, or animation effects are used for dynamic highlighting based on its current operational status data. When the speed of a train twin unit exceeds the normal range, its model color changes to yellow as a warning; when a fault occurs, it changes to red as an alarm. Areas of abnormal structural stress in track twin units are highlighted with a flashing red texture. Areas with high population density in station twin units are displayed with different shades of color depending on the population density, such as dark red when people are densely packed. Through these layered rendering and dynamic highlighting techniques, operation and management personnel can quickly and clearly understand the operational status of each independent twin unit and promptly detect anomalies.

[0026] Step S120: Relying on the dynamic perception capability of the digital twin, capture the abnormal trigger signal, track the propagation trajectory of the abnormal trigger signal among each independent twin unit, and construct an event deconstruction chain that includes the location of the abnormal source, the hierarchy of the affected independent twin unit, and the fault propagation intensity. The fault propagation intensity reflects the difference in the degree of impact of the abnormality on different independent twin units.

[0027] Digital twins possess powerful dynamic sensing capabilities, enabling real-time monitoring of the operational status of each independent twin unit. When an anomaly occurs in a physical entity within the urban rail system, the corresponding independent twin unit transmits the anomaly data to the digital twin via a real-time sensing channel. The digital twin analyzes and judges this anomaly data, capturing the anomaly trigger signal. Subsequently, it tracks the propagation path and process of this anomaly trigger signal among the various independent twin units, determining which independent twin units are affected and analyzing the degree of impact of the anomaly on different independent twin units, i.e., the fault propagation strength. Information such as the location of the anomaly source, the hierarchical relationship of the affected independent twin units, and the fault propagation strength are integrated to construct an event deconstruction chain.

[0028] Step S121: Generate differentiated anomaly judgment criteria for each independent twin unit. The above anomaly judgment criteria are generated based on the entity's historical operating data, industry safety specifications, and equipment performance parameters. The anomaly judgment criteria for the train independent twin unit include sudden changes in driving status, abnormal braking feedback, and overcrowding in the carriage. The anomaly judgment criteria for the track independent twin unit include track gauge deviation, abnormal structural stress, and excessive vibration frequency.

[0029] Different types of independent twin units have different functions and operating characteristics, thus requiring the generation of differentiated anomaly judgment criteria. For train independent twin units, historical operating data such as speed and acceleration variation range over a period of time are collected. Combined with industry-specific requirements for train operation safety and equipment performance parameters such as engine power and braking system performance, a judgment threshold for sudden changes in operating state is established. For example, if the speed change exceeds a certain value per unit time, it is judged as a sudden change in operating state. Based on the design standards of the braking system and historical braking feedback data, the judgment conditions for abnormal braking feedback are determined, such as braking response time exceeding the specified value or braking pressure not meeting expectations. Based on the design passenger capacity and personnel safety standards of the carriages, judgment criteria for overcrowding in the carriages are set, such as the number of people exceeding the percentage of the carriage's rated passenger capacity. For independent track twin units, based on historical gauge measurement data, track design standards, and industry safety regulations, the allowable range for gauge shape deviation is determined. When the actual gauge exceeds this range, it is considered abnormal. Based on the strength parameters of the track structural materials, historical stress monitoring data, and industry safety regulations, a threshold for structural stress anomalies is established, such as stress values ​​exceeding the material's yield strength. Combining the track's design vibration frequency range and historical vibration data, a standard for determining vibration frequency exceeding the normal range is set; when the vibration frequency exceeds the normal range, it is considered abnormal. By comprehensively considering historical operational data, industry safety regulations, and equipment performance parameters, scientifically sound and differentiated anomaly determination standards are generated for each independent twin unit, ensuring accurate identification of anomalies.

[0030] Step S122: The real-time monitoring data of each independent twin unit is continuously analyzed through the perception data processing module of the digital twin. When the real-time monitoring data exceeds the anomaly judgment standard for multiple consecutive synchronization cycles, the anomaly is confirmed to exist by comparing the data of the independent twin unit with historical anomaly data. An anomaly trigger signal is then generated. The content of the anomaly trigger signal includes the time of anomaly occurrence, the corresponding independent twin unit identifier, and the specific anomaly manifestation.

[0031] Using a fixed synchronization cycle as the unit, real-time monitoring data is compared with corresponding anomaly judgment criteria. If the real-time monitoring data of a certain independent twin unit exceeds the anomaly judgment criteria for multiple consecutive synchronization cycles—for example, if the speed of a train independent twin unit exceeds the judgment threshold for sudden changes in running state for three consecutive synchronization cycles—then an anomaly is initially judged to be possible. To confirm the authenticity of the anomaly, the data of this independent twin unit is further correlated with other relevant independent twin units to check for any correlated anomaly changes. Simultaneously, the current anomaly data is compared with similar anomaly data that occurred historically to analyze the similarity of data characteristics. If the anomaly is confirmed through correlation and historical comparison, an anomaly trigger signal is generated. The anomaly trigger signal includes the specific time of the anomaly occurrence, accurate to the second; the unique identifier of the corresponding independent twin unit, such as train number, track section number, station number, etc.; and the specific anomaly manifestations, such as excessive train speed, excessive track stress, or crowding at stations. The anomaly trigger signal generated in the above manner can accurately reflect the occurrence and specific characteristics of the anomaly.

[0032] Step S123: Using the independent twin unit that triggered the anomaly as the starting point for tracing, find the independent twin units that have a direct physical connection or functional dependency with the above-mentioned starting point for tracing, mark them as first-level affected independent twin units, and record the connection type and the method of influence transmission.

[0033] Taking a train-specific independent twin unit experiencing braking feedback anomalies as an example, this train-specific independent twin unit is the source of the problem. Then, other independent twin units with direct physical connections or functional dependencies to this source are identified. Directly physically connected independent twin units may include track-specific twin units corresponding to the train's current track, as the train travels directly on the track, and braking anomalies may affect the track. Functionally dependent independent twin units may have corresponding power supply twin units, as the train's braking system requires power, and power supply anomalies may lead to braking feedback anomalies; there are also corresponding station-specific twin units, as train braking anomalies may affect arrival times, thus impacting passenger flow at the station. These directly connected independent twin units are marked as Level 1 affected independent twin units. During the marking process, the connection type, such as physical connection or functional dependency, and the impact transmission method, such as impact transmitted through mechanical contact, impact transmitted through power supply, or impact transmitted through operational scheduling, are recorded.

[0034] Step S124: Perform trend analysis on the monitoring data of the first-level affected independent twin units. If the data shows obvious abnormal change characteristics and conforms to the transmission law, continue to traverse its associated independent twin units and mark them as second-level affected independent twin units. Expand layer by layer according to this logic until the traversal program does not find any new affected independent twin units.

[0035] After identifying the first-level affected independent twin units, trend analysis is performed on the real-time monitoring data of these units. For example, for the track independent twin units marked as first-level affected due to train braking anomalies, the changing trends of their structural stress data and vibration characteristic data after the train braking anomaly occurs are analyzed. If the above data exhibit obvious abnormal change characteristics, such as a continuous increase in stress values ​​and abnormal fluctuations in vibration frequency, and these changes conform to the transmission law of anomalies from the train to the track, then it indicates that the anomaly has further propagated from the first-level affected independent twin unit. At this point, other independent twin units associated with the first-level affected independent twin unit are searched, such as track independent twin units corresponding to adjacent track sections, independent twin units of stations connected to the track, etc., and these are marked as second-level affected independent twin units. Following the same logic, trend analysis is performed on the monitoring data of the second-level affected independent twin units to determine whether the anomaly continues to propagate, and then third-level, fourth-level, and so on, affected independent twin units are marked, until the traversal program finds no new affected independent twin units after checking all associated independent twin units. By expanding layer by layer as described above, it is possible to comprehensively track the propagation trajectory of abnormal trigger signals between each independent twin unit.

[0036] Step S125: Calculate the fault propagation strength for each affected independent twin unit. The fault propagation strength is generated based on the degree of association between the independent twin unit and the abnormal origin, the physical distance, and the functional dependency level. The degree of association is quantified by entity connection relationship, the physical distance is calculated by spatial coordinates, and the functional dependency level is determined by system architecture analysis.

[0037] Step S1251: Extract the relationship data of all physical entities in the urban rail transit system from the digital twin, and generate an entity relationship table based on the above relationship data. The relationship data includes the physical connection type, functional interaction frequency and historical fault impact record between entities. The rows and columns of the entity relationship table correspond to each physical entity. The element record in the above entity relationship table corresponds to the relationship tightness score between entities. The relationship tightness score is calculated by comprehensively considering the physical connection type weight, the functional interaction frequency statistics and the historical fault impact coefficient.

[0038] The database of the digital twin extracts relationship data between all physical entities in the urban rail transit system. This data details the physical connection methods between entities, such as the direct physical connection between the train and the track, and the physical connection between the train and the power supply line via pantograph; the frequency of functional interactions, such as the number of communications between the train and the dispatch center, and the frequency of information exchange between stations and trains; and historical fault impact records, i.e., the number and extent to which a fault in one entity affected another entity in the past. An entity relationship table is generated based on this relationship data. The rows and columns of the table represent different physical entities, and each element records the degree of association between the entities in the corresponding row and column. The degree of association score is calculated as follows: first, different physical connection types are assigned corresponding weights, such as direct physical connections having a higher weight than indirect physical connections; then, the frequency of functional interactions between entities is statistically analyzed and converted into a statistical value within a certain range; next, a historical fault impact coefficient is determined based on the historical fault impact records, such as a larger coefficient for two entities with more frequent and more severe past fault impacts. Finally, the physical connection type weights, the statistical values ​​of functional interaction frequencies, and the historical fault impact coefficients are comprehensively calculated to obtain the degree of association score.

[0039] Step S1252: Based on the distribution range of the association tightness scores in the entity association table, classify the association tightness levels. The first level corresponds to the situation where there is a direct physical connection between entities and a change in the operating status of one entity will directly trigger a security alarm for the other entity. The second level corresponds to the situation where entities are affected by an intermediate link and the failure of the intermediate link will block the transmission of the impact. The third level corresponds to the situation where changes in the operating status of entities do not interfere with each other. Each level corresponds to a fixed association strength coefficient.

[0040] After obtaining the association strength scores in the entity association table, the distribution range of these scores is analyzed. Based on the distribution, the association strength is divided into different levels. Level 1 represents the highest level of association, corresponding to a direct physical connection between entities. A change in the operating state of one entity directly triggers a safety alarm in the other. For example, the relationship between a train and the currently running track twin is at Level 1; abnormal braking of the train may directly cause track stress to exceed the safety threshold, triggering a safety alarm in the track twin. Level 2 represents the next level of association, where entities influence each other through one or more intermediate links. If these intermediate links fail, the transmission of influence is interrupted. For example, the train twin and the power supply twin are connected through intermediate links such as a pantograph; a pantograph malfunction interrupts the transmission of power supply to the train. Level 3 represents the lowest level of association, where changes in the operating state of entities do not interfere with each other. For example, train twins on different lines typically belong to Level 3 association. A fixed association strength coefficient is assigned to each level of association strength, with the highest coefficient for Level 1, followed by Level 2, and the lowest for Level 3.

[0041] Step S1253: Extract the correlation tightness score between the abnormal starting point and each affected independent twin unit from the entity relationship table, and combine it with the correlation strength coefficient corresponding to the correlation tightness level to obtain the basic correlation strength data. The value of the basic correlation strength data is positively correlated with the correlation tightness score and the correlation strength coefficient.

[0042] The association strength score between the anomaly origin and each affected independent twin unit is found in the entity association table. Then, based on the association strength level of these two entities, the corresponding association strength coefficient is determined. The association strength score and the association strength coefficient are multiplied to obtain the basic association strength data. The value of the basic association strength data is positively correlated with both the association strength score and the association strength coefficient; that is, the higher the association strength score and the larger the association strength coefficient, the larger the value of the basic association strength data, indicating a stronger basic association between the anomaly origin and the affected independent twin unit.

[0043] Step S1254: Obtain the spatial coordinate data of the abnormal starting point and each affected independent twin unit through the digital twin. The spatial coordinate data adopts the three-dimensional coordinates calibrated by the urban rail transit system's dedicated geographic information system. Calculate the straight-line distance between the two based on the three-dimensional coordinates and take this straight-line distance as the actual physical distance.

[0044] The spatial coordinate data of each independent twin unit stored in the digital twin is used. This coordinate data is calibrated using a geographic information system (GIS) specific to urban rail transit systems, and contains the precise location of the entity in three-dimensional space. For the anomalous origin and each affected independent twin unit, their three-dimensional coordinate data is extracted. Then, the straight-line distance between the anomalous origin and the affected independent twin unit is calculated based on the three-dimensional coordinates; this straight-line distance is the actual physical distance between them. For example, the anomalous origin is a train independent twin unit with three-dimensional coordinates (X1, Y1, Z1), and the affected track independent twin unit has three-dimensional coordinates (X2, Y2, Z2). The actual physical distance between them can be obtained using the three-dimensional spatial distance calculation formula.

[0045] Step S1255: Based on the functional architecture of the urban rail system, extract the functional positioning information of each entity in the operation of the urban rail system. The functional positioning information includes the supporting role of the entity in core businesses such as train operation, passenger flow management, and power supply guarantee. The functional dependency level is divided according to the degree of irreplaceability of the supporting role. Each functional dependency level corresponds to a fixed dependency weight coefficient. The higher the irreplaceability of the supporting role, the larger the dependency weight coefficient.

[0046] This analysis examines the functional architecture of the urban rail transit system to clarify the functional positioning of each entity in its operation. The functional positioning information details the supporting role of each entity in core operations such as train operation, passenger flow management, and power supply assurance. For example, the train independent twin unit directly supports the core operation of train operation; the station independent twin unit primarily supports passenger flow management; and the power supply independent twin unit supports power supply assurance. Functional dependency levels are categorized based on the irreplaceability of these supporting roles. If an entity's supporting role is irreplaceable by other entities, its functional dependency level is high, and its corresponding dependency weight coefficient is large. For instance, the power supply independent twin unit's supporting role in train operation is highly irreplaceable, resulting in a high functional dependency level and a large dependency weight coefficient. Conversely, some auxiliary equipment entities, whose functions can be replaced by other equipment, have a low functional dependency level and a small dependency weight coefficient.

[0047] Step S1256: Standardize the basic association strength data to compress the numerical range of the basic association strength data to a fixed interval to obtain standardized association values; normalize the actual physical distance and calculate the distance weight by combining the dependency weight coefficient corresponding to the functional dependency level. The magnitude of the distance weight is negatively correlated with the actual physical distance and positively correlated with the dependency weight coefficient.

[0048] To ensure comparability between different indicators, the basic association strength data needs to be standardized. Standardization involves compressing the numerical range of the basic association strength data into a fixed interval, such as [0, 1], through mathematical transformations, resulting in standardized association values. For the actual physical distance, normalization is performed, converting its value to the [0, 1] interval. Then, the distance weight is calculated by combining the dependency weight coefficient corresponding to the functional dependency level. The distance weight is calculated by combining the normalized actual physical distance with the dependency weight coefficient. Since the closer the actual physical distance, the greater the potential impact on the affected independent twin units, the magnitude of the distance weight is negatively correlated with the actual physical distance; that is, the smaller the distance, the larger the distance weight. Simultaneously, the higher the functional dependency level, the larger the dependency weight coefficient, and therefore the larger the distance weight; thus, the distance weight is positively correlated with the dependency weight coefficient.

[0049] Step S1257: Multiply the standardized correlation value with the distance weight to obtain the initial fault transmission strength value. If the initial fault transmission strength value exceeds the preset reasonable range, it is corrected by using the historical fault transmission strength dataset stored in the digital twin. The correction method is to take the average of the multiple values ​​in the historical dataset that are closest to the current initial value as the corrected fault transmission strength.

[0050] The standardized correlation value is multiplied by the distance weight to obtain the initial fault propagation strength value. This initial fault propagation strength value reflects the initial strength of the anomaly propagating from the source to the affected independent twin unit. A reasonable range for the fault propagation strength is preset. If the initial fault propagation strength value exceeds this range, it indicates that the initial value may be anomaly. In this case, the historical fault propagation strength dataset stored in the digital twin is retrieved, and the multiple values ​​closest to the current initial value are found in this dataset. The average of these values ​​is calculated, and this average is used as the corrected fault propagation strength value. Through the above method, the reasonableness and accuracy of the fault propagation strength value are ensured.

[0051] Step S1258: If there are multiple associated paths between the affected independent twin unit and the abnormal origin, and each associated path corresponds to a different entity connection order, calculate the fault propagation strength corresponding to each associated path. The calculation method is the same as the fault propagation strength calculation method for a single path, and obtain the path fault propagation strength of each path.

[0052] In urban rail transit systems, there may be multiple different associated paths between an affected independent twin unit and the origin of an anomaly, each path having a different sequence of physical connections. For example, an anomaly originating from a train braking anomaly may affect a station independent twin unit through a track independent twin unit, or it may affect a station independent twin unit through a power supply independent twin unit; these are two different associated paths. For each associated path, the fault propagation intensity is calculated using the same method as for a single path, which involves sequentially performing steps such as correlation tightness analysis, physical distance calculation, and functional dependency level classification, to determine the path fault propagation intensity for each path.

[0053] Step S1259: Compare the fault conduction strengths of all paths, select the path with the largest fault conduction strength as the final fault conduction strength of the affected independent twin unit, and record the entity connection order of the path.

[0054] After obtaining the path fault propagation strength for each associated path, the strength values ​​are compared. Since different paths have different fault propagation capabilities, the highest path fault propagation strength represents the maximum possible impact of the anomaly on the affected independent twin unit via that path. Therefore, the highest path fault propagation strength is selected as the final fault propagation strength for the affected independent twin unit. Simultaneously, the entity connection order corresponding to the path with the highest strength is recorded for subsequent analysis of the anomaly propagation path and the development of targeted mitigation measures.

[0055] Step S126: According to the order of anomaly propagation, organize the anomaly origin and the affected independent twin units at all levels into a hierarchical sequence. Each independent twin unit is labeled with the fault propagation intensity, anomaly change characteristics and propagation path, forming a structured hierarchical table of affected independent twin units.

[0056] After identifying the affected independent twin units at each level, along with their fault propagation strength, propagation paths, and anomaly characteristics, the data is organized according to the order of anomaly propagation. The anomaly originates at the first node, followed by the first-level affected independent twin units, then the second-level affected independent twin units, and so on, forming a hierarchical sequence. For each independent twin unit, the hierarchical table is labeled with its corresponding fault propagation strength, anomaly characteristics (such as abnormal velocity changes, abnormal stress increases, or abnormal increases in personnel density), and the path traversed by the anomaly propagation, i.e., the order of entity connections. Through this method, a structured hierarchical table of affected independent twin units is constructed, which displays the hierarchical relationship and related characteristics of anomaly propagation among the independent twin units.

[0057] Step S127: Locate and identify the starting point of the anomaly. The identification content includes the anomaly type, specific location coordinates, initial impact range and development trend prediction. Integrate the anomaly source identification, the affected independent twin unit hierarchy table and the fault propagation intensity data to form an event deconstruction chain.

[0058] The precise location of the anomaly's origin is determined, establishing its specific coordinates within the urban rail transit system. These coordinates are based on a dedicated geographic information coordinate system for urban rail transit. Simultaneously, the anomaly type is identified, such as train braking anomalies, track stress anomalies, or abnormal station crowding. Based on the anomaly's current state and development pattern, the initial impact range is estimated, i.e., the range of independent twin units that the anomaly may affect in a short period. Combining the development of similar historical anomalies with current system operating parameters, the anomaly's development trend is predicted, such as whether the anomaly will expand and at what rate. The aforementioned anomaly source identification information, including anomaly type, specific location coordinates, initial impact range, and predicted development trend, is integrated with the affected independent twin unit hierarchy table and the fault propagation intensity data of each unit to form a complete event deconstruction chain. This event deconstruction chain comprehensively reflects key information such as the anomaly's source, propagation path, impact range, and intensity.

[0059] Step S128: After each twin synchronization cycle, reassess the abnormal state and fault propagation strength of each affected independent twin unit, and add, delete, or adjust the hierarchy table of affected independent twin units.

[0060] The digital twin updates the state data of the physical entities at fixed synchronization cycles. At the end of each synchronization cycle, the abnormal states of each affected independent twin are reassessed to check whether the anomalies have been mitigated, persisted, or exacerbated. Simultaneously, the fault propagation strength is recalculated based on the new state data. If the abnormal states of some affected independent twins have disappeared, or their association with the anomaly origin has changed, rendering them no longer affected, they are removed from the affected independent twin hierarchy table. If new affected independent twins are discovered, or the hierarchy of existing affected independent twins changes, the hierarchy table is added or adjusted accordingly. Through this dynamic assessment and adjustment, the affected independent twin hierarchy table accurately reflects the impact of the current anomalies.

[0061] Step S130: Call the blockchain evidence data of urban rail emergency resources, dynamically couple the above event deconstruction chain with the independent twin unit of emergency resources, and generate a resource combination scheme covering resource adaptation characteristics, response efficiency and deployment order. The blockchain evidence data of urban rail emergency resources includes the attribute characteristics, storage location, maintenance records and availability status of emergency resources.

[0062] Data related to urban rail emergency resources is stored using blockchain technology to ensure data security, immutability, and traceability. Once the event deconstruction chain is formed, this blockchain-stored data needs to be accessed. Anomaly information contained in the event deconstruction chain, such as anomaly type, distribution of affected independent twin units, and fault propagation intensity, is dynamically coupled with the attribute characteristics and storage location of the emergency resource independent twin units. The matching degree between emergency resources and anomaly handling needs is analyzed, the response efficiency of resources arriving at the anomaly site is assessed, the deployment order of resources is determined, and a resource combination plan is ultimately generated. This resource combination plan details the required types of emergency resources, their compatibility characteristics, response efficiency, and deployment order.

[0063] Step S131: Access the distributed nodes of the urban rail emergency resource blockchain and retrieve the encrypted and stored emergency resource data. The emergency resource data is processed using hash encryption technology and includes the resource's unique identifier, type attribute, storage location coordinates, technical performance parameters, historical maintenance records, and current availability status.

[0064] The urban rail emergency resource blockchain consists of multiple distributed nodes located at different locations within the urban rail system, collectively maintaining the blockchain data. Accessing these distributed nodes allows retrieval of emergency resource data stored on the blockchain. To ensure data security, emergency resource data is processed using hash encryption technology before storage. Hash encryption converts the original data into a fixed-length hash value; even minor changes to the original data will significantly alter the hash value, thus ensuring data integrity and tamper-proof nature. The retrieved emergency resource data includes: a unique identifier for each resource to distinguish different emergency resources; type attributes, such as rescue equipment, medical supplies, and repair personnel; storage location coordinates, accurate to the specific warehouse or station location; technical performance parameters, such as the equipment's operating range, power, and efficiency; historical maintenance records, recording past repair times, repair content, and replaced parts; and current availability status, such as normally available, under repair, or damaged.

[0065] Step S132: Extract the type information of the anomaly source, the distribution range of the affected independent twin units and the fault characteristics from the above event deconstruction chain, and extract the resource and functional requirements required for emergency response.

[0066] A detailed analysis of the event deconstruction chain is conducted to extract key information. The type of the anomaly source indicates its nature, such as mechanical failure, electrical failure, or personnel gathering. The distribution range of the affected independent twin units indicates the areas and entities affected by the anomaly, such as a section of track or several stations. Fault characteristics describe the specific manifestations of the anomaly, such as track stress values ​​and train braking pressure. Based on this information, the resource and functional requirements for emergency response are determined. For example, if the anomaly source is a train braking failure, the affected area includes the train and related tracks, and the fault characteristic is insufficient braking pressure, then the resource and functional requirements for emergency response might include equipment capable of providing temporary braking support, track repair equipment, and professional maintenance personnel.

[0067] Step S133: Based on the resource function requirements and the resource type attributes in the blockchain evidence data, perform a preliminary match to select resources that meet the functional requirements and are currently in a normal available state, forming a candidate resource set.

[0068] The extracted emergency response resource functional requirements are compared with the resource type attributes in the blockchain-based evidence data. Resource type attributes clearly define the functional category of the resource, such as lifting equipment, power generation equipment, and medical rescue equipment. Through preliminary matching, emergency resources whose type attributes match the resource functional requirements are identified. Simultaneously, the current availability status of these resources is checked, and resources with a normal availability status are selected. Resources that meet the functional requirements and are available are grouped together to form a candidate resource set. For example, if the resource functional requirement is track repair, then resources with the type attribute of track repair equipment and a normal current availability status are selected from the blockchain-based evidence data to form the candidate resource set.

[0069] Step S134: Obtain the real-time location information of the independent twin units of the emergency resources corresponding to the candidate resources in the above candidate resource set through the digital twin, and combine the mobility characteristics of the candidate resources to obtain the response efficiency of each candidate resource to the anomaly source and the main affected independent twin units.

[0070] Digital twins can acquire the location information of independent twin units of emergency resources in real time because the location data of these independent twin units is synchronized to the digital twin through a real-time sensing channel. For each candidate resource in the candidate resource set, the real-time location coordinates of its corresponding independent twin unit are obtained from the digital twin. Simultaneously, the mobility characteristics of the candidate resources are understood, such as the resource's own movement speed (e.g., the maximum speed of repair vehicles), whether external transportation is required (e.g., certain large equipment requires specialized vehicles), and limitations during transportation (e.g., road width restrictions, bridge load-bearing limits). Based on the real-time location information and mobility characteristics, the estimated time for each candidate resource to reach the anomaly source and the main affected independent twin units from its current location is calculated. Response efficiency is typically measured by the time required for arrival; the shorter the arrival time, the higher the response efficiency.

[0071] Step S135: By comparing the resource technical performance parameters with the anomaly handling requirement parameters, calculate the resource adaptation characteristics, call the resource historical maintenance database, and extract the fault handling success rate data to correct the above resource adaptation characteristics.

[0072] Resource technical performance parameters are important indicators for measuring the strength of resource functionality, such as the equipment's operating pressure range, output power, and operational accuracy. Anomaly handling requirements parameters are determined based on the anomaly situation, such as the need to reduce track stress to a certain value or the required timeframe for power restoration. A detailed comparison of resource technical performance parameters and anomaly handling requirements parameters is performed to analyze whether the resource can meet the handling requirements and to what extent, thereby calculating the resource adaptability characteristics. Resource adaptability characteristics can be a comprehensive score reflecting the degree of matching between the resource and the requirements. To improve the accuracy of adaptability characteristics, the resource's historical maintenance database is accessed to extract past success rate data for handling similar faults. If the resource's historical fault handling success rate is high, it indicates good practical application performance, and the resource adaptability characteristics are positively adjusted; conversely, if the success rate is low, negative adjustments are made.

[0073] Step S136: Set evaluation weight parameters based on the initial impact level of the anomaly source. The initial impact level is quantified by the anomaly's spread and severity. The response efficiency is converted into a standardized response score, where a higher response efficiency indicates a faster response and a higher score. The resource adaptation characteristics and the standardized response score are weighted according to the evaluation weight parameters to obtain the comprehensive adaptation score of each candidate resource.

[0074] The initial impact level of the anomaly source is quantified based on the number and range of independent twin units affected by the anomaly, as well as the potential degree of harm. Different evaluation weight parameters are set according to the initial impact level. A higher initial impact level indicates a more severe anomaly, and resource evaluation may place more emphasis on resource suitability characteristics; therefore, the evaluation weight parameter for suitability characteristics can be set higher. Conversely, the weight parameter for response efficiency can be appropriately increased. Response efficiency is converted into a standardized response score. The conversion method involves converting the response efficiency value (e.g., arrival time) into a score of [0, 100] according to certain rules; the higher the response efficiency (the shorter the arrival time), the higher the score. Then, the resource suitability characteristics and the standardized response score are weighted and calculated according to the evaluation weight parameters. For example, if the evaluation weight parameters allocate 60% to suitability characteristics and 40% to response score, then the comprehensive suitability score is the sum of the suitability characteristics multiplied by 60% and the response score multiplied by 40%, yielding the comprehensive suitability score for each candidate resource.

[0075] Step S137: Sort the candidate resources according to the above comprehensive adaptation score, extract the quantity distribution data and fault propagation intensity data of the affected independent twin units, and select the K types of resources with the highest comprehensive adaptation scores to form a resource combination, covering all abnormal scenarios and affected independent twin units.

[0076] Based on the comprehensive suitability score, candidate resources in the resource set are sorted in descending order. Resources with higher scores have better comprehensive suitability. Simultaneously, the distribution data of the number of affected independent twin units is extracted from the event deconstruction chain to understand the quantity of affected independent twin units of different types and locations; and fault propagation intensity data is used to clarify the degree of impact of the anomaly on each affected independent twin unit. Based on this data, it is determined how many types of resources are needed to cover all anomaly scenarios and affected independent twin units. The top K types of resources with the highest comprehensive suitability scores are selected. The value of K is determined based on the actual anomaly situation and resource requirements. This combination of resources can meet the resource functionality requirements under different anomaly scenarios, ensuring that all affected independent twin units receive appropriate emergency resource support.

[0077] Step S138: Label each resource in the above resource combination with specific resource adaptation characteristics, response efficiency evaluation results and deployment order. The deployment order is determined by the fault propagation strength of the affected independent twin unit corresponding to the resource in the event deconstruction chain. When the affected independent twin unit corresponding to the fault propagation strength is a core-level functional dependency entity, its corresponding resource deployment order is set to the first priority; when it is a line-level functional dependency entity, it corresponds to the second priority; when it is a facility-level entity, it corresponds to the third priority. Resource allocation instructions are issued in order of priority.

[0078] After the resource combination is determined, each resource in the combination is labeled with its specific resource adaptation characteristics, such as how the technical performance parameters of the resource meet the requirements for anomaly handling; the response efficiency assessment results, i.e., the estimated time to reach the anomaly site; and the deployment order. The deployment order is determined based on the fault propagation strength of the affected independent twin unit corresponding to the resource in the event deconstruction chain and the functional dependency level of the affected independent twin unit. The functional dependency levels of the affected independent twin units are divided into core level, line level, and facility level. Core-level functional dependency entities are the key core parts of the urban rail system, and their failure may paralyze the entire system, such as the train's power system and main power supply lines. When the affected independent twin unit is core level, the corresponding resource deployment order is set as the first priority. Line-level functional dependency entities are important components of a line, and their failure will affect the normal operation of the line but will not lead to the paralysis of the entire system, such as the track and stations of a line. The corresponding resource deployment order is the second priority. Facility-level functional dependency entities are some auxiliary facilities, and their failure has a relatively small impact on system operation, such as elevators and lighting equipment in stations. The corresponding resource deployment order is the third priority. Allocation instructions are issued to each emergency resource in the order of first, second, and third priority to ensure that critical resources can arrive at the scene first for disposal.

[0079] Step S140: Based on the resource combination scheme and the transmission characteristics of the event deconstruction chain, generate the triggering rules and execution logic of the smart contract. The smart contract is used to clarify the automatic execution process of the scheduling instructions, the boundaries of rights and responsibilities for resource use, and the timing coordination requirements of emergency links. The timing coordination requirements standardize the action connection nodes and interaction methods of each participant.

[0080] The resource combination scheme determines the required emergency resources and their deployment sequence, while the propagation characteristics of the event deconstruction chain reflect the anomaly's propagation patterns and impact. Combining these two aspects, the triggering rules and execution logic of the smart contract are generated. The triggering rules specify the conditions under which the smart contract begins execution, while the execution logic clarifies the specific steps and operations during the smart contract's execution. The role of the smart contract is to ensure that scheduling instructions are automatically executed according to the predetermined process, to clarify the boundaries of rights and responsibilities during resource usage, and to standardize the action coordination and interaction methods between various participants in the emergency response, ensuring the orderly conduct of emergency response work.

[0081] Step S141: Extract the deployment order and response efficiency data of each resource from the resource combination scheme, and extract the fault propagation strength and abnormal development trend of each affected independent twin unit from the event deconstruction chain. Based on the deployment order and response efficiency data of each resource and the fault propagation strength and abnormal development trend of each affected independent twin unit, determine the triggering rules of the smart contract. The triggering rules are divided into immediate triggering and time-series triggering. The abnormal source and the affected independent twin unit containing core-level functional dependencies correspond to the immediate triggering rules. Among them, a status monitoring threshold is set. The status monitoring threshold is the safety threshold of the core operating parameters of the entity. When the digital twin detects that the abnormal state of the independent twin unit continues to escalate to the status monitoring threshold, the triggering is initiated. Other affected independent twin units correspond to the time-series triggering rules, and the step-by-step triggering time points are set according to the response efficiency data.

[0082] The deployment order of each resource (first priority, second priority, third priority, etc.) and its response efficiency data, such as the estimated time to reach the anomaly site, are obtained from the resource combination scheme. The fault propagation strength of each affected independent twin unit is extracted from the event deconstruction chain to understand the impact of the anomaly on each unit; simultaneously, the anomaly development trend is analyzed to determine whether the anomaly is expanding, stabilizing, or shrinking. Taking into account the resource deployment order, response efficiency, fault propagation strength of the affected independent twin units, and anomaly development trend, the triggering rules for the smart contract are determined. Triggering rules are divided into two types: immediate triggering and time-sequential triggering. The anomaly source itself and the affected independent twin units containing core-level functional dependencies are of high importance and require immediate handling upon an anomaly; therefore, immediate triggering rules apply. State monitoring thresholds are set for these entities. These thresholds are safety critical values ​​for the entity's core operating parameters, such as the minimum pressure of a train braking system or the maximum track stress. When the digital twin detects that the anomaly state of these independent twin units is continuously escalating and reaches the state monitoring threshold, the execution of the smart contract is immediately initiated. For other affected independent twin units, such as entities at the line-level and facility-level functional dependency levels, a timing-based triggering rule is adopted. Based on resource response efficiency data, tiered triggering times are set for different affected independent twin units. For example, affected independent twin units corresponding to resources with high response efficiency can have earlier triggering times set; affected independent twin units corresponding to resources with low response efficiency can have later triggering times set to ensure that resources arrive and are processed in a timely manner.

[0083] Step S142: Construct the automatic execution logic of scheduling instructions. The content of the automatic execution logic of scheduling instructions covers resource scheduling path planning, resource startup operation process, and collaborative action requirements with affected independent twin units.

[0084] The automatic execution logic of dispatch instructions is the core of the smart contract, detailing how dispatch instructions are automatically generated, transmitted, and executed. Resource dispatch path planning, based on the location of emergency resources and the location of affected independent twin units, plans the optimal transportation route. This route must consider factors such as road conditions, traffic control, and emergency access routes to ensure resources reach their destination as quickly as possible. The resource activation operation process specifies activation steps for different types of resources. For example, for power generation equipment, it includes steps such as checking fuel, starting the engine, and adjusting output power; for personnel resources, it includes steps such as mobilizing personnel, assigning tasks, and preparing equipment. The collaborative action requirements with affected independent twin units clarify how emergency resources cooperate with these units during task execution. For instance, when emergency resources arrive at the location of the train's independent twin unit, they need to interact with the train's control system to obtain real-time train status data for targeted action.

[0085] Step S1421: Call the urban rail geographic information module of the digital twin to obtain electronic map data containing track lines, station layout, emergency passages, restricted areas and real-time traffic status. This electronic map data is synchronized with the current train location, road occupancy and temporary traffic control information through the real-time update module.

[0086] The urban rail transit geographic information module of the digital twin stores detailed geographic information data of the urban rail transit system. By calling this module, electronic map data containing information such as the direction of the track, the specific layout of stations, the location and width of emergency passages, the scope of restricted areas, and real-time traffic conditions can be obtained. To ensure the accuracy and timeliness of the electronic map data, it is dynamically updated through a real-time update module. The real-time update module can receive real-time information from various sources, such as the location information of currently running trains, which is synchronized to the electronic map through the spatial coordinate data of the train's independent twin unit; road occupancy information, such as the location and duration of construction sections and accident sections; and temporary control information, such as the closure of certain areas due to activities or maintenance. The above real-time information is promptly integrated into the electronic map data to ensure that the map data used for resource scheduling and route planning is up-to-date.

[0087] Step S1422: Plan a scheduling path for each resource in the above resource combination. The scheduling path planning adopts the logic of integrating emergency channel priority, setting the emergency channel inside the urban rail system as the highest priority, and setting the prohibited areas, the expected travel trajectory of the running train and densely populated areas in the electronic map data as avoidance objects.

[0088] After acquiring electronic map data, a scheduling path is planned for each resource in the resource combination. Path planning employs a logic that integrates emergency access priority, setting emergency access within the urban rail system as the highest priority. Resource scheduling paths should prioritize emergency access as much as possible to improve transportation speed. Simultaneously, prohibited areas, the predicted routes of running trains, and densely populated areas in the electronic map data are designated as avoidance targets. Prohibited areas are areas where resources are not allowed to pass and must be strictly avoided; the predicted routes of running trains are based on the train's current location and operational plan, and scheduling paths need to avoid these routes to avoid conflicts with trains; densely populated areas may affect the speed and safety of resource passage and should also be avoided as much as possible. By comprehensively considering the priority of emergency access and avoidance targets, optimal scheduling paths are planned for each resource using path planning algorithms such as A* algorithm and Dijkstra's algorithm.

[0089] Step S1423: Mark key nodes and corresponding operation specifications in the above scheduling path. The key nodes include the resource storage starting point, the passage intersection point, the temporary avoidance point, and the location of the destination affected independent twin unit. The operation specifications include the passage order at the intersection point, the stopping requirements at the avoidance point, and the destination stopping area.

[0090] Once the dispatch route is determined, key nodes are marked along the route. These key nodes include the starting point of resource storage, i.e., the initial warehouse or site where the resources are located; intersections of passageways, such as the junctions of multiple emergency passages; temporary avoidance points, such as locations where temporary stops are needed to avoid trains or other obstacles; and the specific location of the affected independent twin units at the destination. For each key node, corresponding operational procedures are established. At passageway intersections, the order of resource passage is clearly defined, such as following the principle of "first-come, first-served" or "main road priority"; at temporary avoidance points, the required time for stopping and the safe distance are specified; at the destination stopping area, the specific stopping location and method of the resources are designated to ensure that other rescue operations are not affected. By marking key nodes and establishing operational procedures, the orderliness and safety of the resource dispatch process can be improved.

[0091] Step S1424: Generate a targeted startup operation procedure based on the resource type. The startup operation procedure for mechanical resources includes the power-on sequence, function mode settings, fault self-check items and parameter calibration requirements. The startup operation procedure for personnel resources includes the assembly point, equipment wearing specifications, task division instructions and safety protection requirements. The startup operation procedure for equipment resources includes the power-on verification procedure, mode switching steps and connection debugging methods.

[0092] Different types of emergency resources have different startup operation requirements, therefore, it is necessary to generate targeted startup operation procedures based on resource type. For mechanical resources, such as cranes and generators, the startup operation procedure includes the power-on sequence (e.g., turning on the main power supply first, then the control power supply); setting the functional mode (e.g., setting the generator to emergency power supply mode); fault self-check items (e.g., checking engine oil pressure, water temperature, and circuit connections); and parameter calibration requirements (e.g., calibrating the generator's output voltage and frequency). For personnel resources, such as rescue personnel and maintenance personnel, the startup operation procedure includes determining the assembly point (e.g., assembling in a designated area at a specific site); equipment wearing specifications (e.g., wearing safety helmets, protective clothing, and protective gloves); task assignment descriptions, clarifying the specific responsibilities of each person (e.g., who is responsible for on-site command, who is responsible for equipment operation, and who is responsible for treating the injured); and safety protection requirements (e.g., protective measures that must be taken when entering dangerous areas). For equipment-related resources, such as communication equipment and testing equipment, the startup operation process includes a power-on verification process, such as checking whether the equipment starts up normally and whether the indicator lights are displaying normally; a mode switching step, such as switching the communication equipment from standby mode to working mode; and a connection and debugging method, such as connecting the testing equipment to the affected independent twin unit and debugging it to ensure accurate data acquisition.

[0093] Step S1425: Assign corresponding collaborative action requirements to each resource. When an abnormality occurs in the train's independent twin unit, the actions of the emergency resources are synchronized with the instructions of the train's braking system and signaling system through the signal interaction module.

[0094] During mission execution, emergency resources need to coordinate with other relevant entities to ensure consistency throughout the emergency response process. Each resource is assigned corresponding coordination requirements, clarifying its interaction methods and timelines with other entities during the response. For example, when a train's independent twin unit malfunctions, the emergency resources dispatched to handle the situation need to coordinate with the train's braking and signaling systems. Through the signal interaction module, emergency resources can receive instructions from the train's braking and signaling systems, such as the current status of the braking system and the train's operational instructions. Simultaneously, the emergency resources' action information, such as arrival time and response progress, is also fed back to the train's braking and signaling systems via the signal interaction module. This allows the systems to adjust their instructions based on the emergency resources' status, ensuring that the emergency resources' actions are synchronized with the train system's instructions and avoiding conflicts or inconsistencies.

[0095] Step S1426: Set up a two-way data interaction interface in the execution logic. After each operation step is executed, the resource will feed back the operation status to the digital twin and the blockchain node in real time through the two-way data interaction interface. The operation status includes not started, in progress, completed, and fault. At the same time, the resource will receive status update instructions from the digital twin through the two-way data interaction interface.

[0096] To achieve real-time monitoring and management of resource operations, a two-way data interaction interface is set up in the automatic execution logic of scheduling instructions. After each operation step is executed by the emergency resource, such as powering on, reaching a critical node, or completing a task, the operation status is fed back to the digital twin and blockchain nodes in real time through this two-way data interaction interface. Operation statuses include: not started (the resource has not yet started executing the operation step); executing (the resource is currently performing the operation step); completed (the operation step has been successfully executed); and fault (an abnormal situation occurred during execution, preventing the operation step from being completed). Simultaneously, the emergency resource also receives status update instructions from the digital twin through the two-way data interaction interface, such as instructions to adjust the handling strategy or change the path when abnormal situations change. Through this two-way data interaction, it is ensured that the digital twin and blockchain nodes can grasp the operational status of the resource in real time, and that the resource can also receive the latest instructions in a timely manner, ensuring the smooth progress of emergency response work.

[0097] Step S1427: For mobile resources, when the digital twin detects new anomalies, obstacles or traffic control on the scheduling path, it initiates a path replanning program to generate the optimal path, updates the path information in the execution logic, and pushes a path adjustment notification and new operating specifications to the resource control terminal.

[0098] Mobile resources, such as emergency repair vehicles and rescue vessels, may encounter various unforeseen circumstances during transportation. The digital twin monitors the dispatch route in real-time through sensing channels. When new anomalies are detected, such as road collapses, new fault points, obstacles like fallen cargo or accident vehicles, or traffic control measures like temporary road closures or restrictions, a route replanning procedure is immediately initiated. This procedure, based on updated electronic map data, uses the same logic as the initial route planning, integrating emergency lane priorities and avoidance targets to generate a new optimal dispatch route. Then, the route information in the execution logic is updated, replacing the original route data with the new one. Simultaneously, a route adjustment notification is pushed to the control terminal of the mobile resources via the communication module, informing the driver of the route change and pushing new operating procedures, such as new key node locations and the order of passage at intersections, ensuring that the mobile resources can smoothly reach their destination according to the new route.

[0099] Step S143: Generate the rights and responsibilities boundary clauses for resource use. The content of the above rights and responsibilities boundary clauses includes the authorizing entity for resource call, the specific user unit, the on-site operator responsible person and the scope of responsibility. The authorizing entity is the urban rail emergency dispatch center, and the information of the operator responsible person is associated and bound with the resource maintenance records stored on the blockchain.

[0100] To clarify the rights and responsibilities in the use of emergency resources and avoid ambiguity, it is necessary to generate boundary clauses for resource use rights and responsibilities. These clauses first define the authorizing entity for resource allocation; only authorized entities can allocate emergency resources. In urban rail transit systems, the authorizing entity is typically the urban rail emergency dispatch center, which is responsible for coordinating the allocation and use of emergency resources. The specific user unit refers to the unit that actually uses the emergency resources for emergency response, such as the maintenance department of a subway operating company or rescue teams. The on-site operator is the person responsible for the specific operation of the emergency resources on-site, and their information needs to be linked to the resource maintenance records stored on the blockchain. Through the blockchain-stored resource maintenance records, it can be verified whether the operator possesses the qualifications to operate the resource, whether they have relevant training records and operational experience, ensuring that the operator is competent to perform the task. The scope of responsibility details the rights and obligations of the authorizing entity, the specific user unit, and the on-site operator in the process of resource allocation, use, and maintenance. For example, the authorizing entity has the right to decide the direction of resource allocation, the user unit is responsible for the reasonable use of resources, and the operator is responsible for safety during the operation.

[0101] Step S144: Set the timing coordination requirements for emergency response. The timing coordination requirements include the scheduling start interval of each resource, the order of deployment completion, and the details of operation connection. The start order of evacuation guidance resources and train adjustment resources is determined by marking time nodes.

[0102] Emergency response involves multiple stages and the coordinated work of various resources, thus requiring the establishment of time-sequential coordination requirements for each stage. These requirements specify the initiation intervals for dispatching various emergency resources—the time interval between the start of dispatching different resources—to avoid congestion or conflicts during resource transportation. The deployment sequence clarifies the order in which resources arrive at their destination and complete deployment, ensuring that critical resources are deployed and put into use first. Operational coordination details describe the coordination methods and time nodes between different resources during operations, such as the timeframe after one resource completes a certain operation before the next resource begins its corresponding operation. For example, in the event of a train malfunction requiring passenger evacuation and train adjustment, time nodes are used to determine the initiation order of evacuation guidance resources and train adjustment resources. Assuming that evacuation guidance resources are activated within five minutes of the malfunction triggering, and train adjustment resources are activated within two minutes of the evacuation guidance resources, this ensures that passenger evacuation precedes train adjustment, guaranteeing passenger safety.

[0103] Step S145: The above triggering rules, the above scheduling instruction automatic execution logic, the above rights and responsibilities boundary clauses, and the above timing coordination requirements are converted into smart contract code. The smart contract code embeds the data interaction interface of the digital twin. The independent twin unit status data is obtained in real time through the above data interaction interface for the determination of triggering conditions.

[0104] After defining the triggering rules, the automatic execution logic of the scheduling instructions, the boundary clauses of rights and responsibilities, and the timing coordination requirements, the above needs to be transformed into computer-executable smart contract code. This process requires professional blockchain developers to write the code using a corresponding smart contract programming language, such as Solidity, based on the aforementioned rules and logic. The smart contract code embeds a data interaction interface for the digital twin. This interface can communicate with the digital twin to obtain real-time state data of each independent twin unit, such as the current state of the anomaly source and changes in the fault propagation intensity of the affected independent twin units. This real-time state data is used to determine the triggering conditions of the smart contract. When the state data meets the conditions set in the triggering rules, the smart contract automatically executes the corresponding scheduling instructions.

[0105] Step S146: An abnormal termination and adjustment module is embedded in the above data interaction contract. This abnormal termination and adjustment module is associated with the dual monitoring channels of the digital twin. The first channel collects the operating parameters of the affected independent twin unit in real time. When the parameters are within the normal range for N consecutive synchronization cycles, the contract termination process is triggered. The second channel collects the functional status parameters of the emergency resource independent twin unit in real time. When the functional status parameters exceed the functional integrity threshold, the contract adjustment process is triggered. When the above dual monitoring channels are executed, the abnormal termination and adjustment module automatically generates an encrypted data block containing the termination reason, adjustment content, and current execution progress, and writes it into the immutable block of the urban rail dispatching blockchain.

[0106] To address anomalies during emergency response, an anomaly termination and adjustment module is embedded in the data interaction contract. This module is linked to the dual monitoring channels of the digital twin, which monitor the progress of the emergency response in real time. The first monitoring channel collects operational parameters of the affected independent twin unit in real time, such as train speed, track stress, and station personnel density. When these parameters remain within the normal range for N consecutive synchronization cycles, it indicates that the anomaly has been resolved, the affected independent twin unit has resumed normal operation, and the anomaly termination and adjustment module triggers the contract termination process, causing the smart contract to stop execution. The second monitoring channel collects functional status parameters of the emergency resource independent twin unit in real time, such as equipment operating temperature, pressure, and power consumption. A functional integrity threshold is set; when the functional status parameters exceed this threshold, it indicates that the emergency resource has malfunctioned or its performance has degraded, making it unable to continue performing tasks normally. This triggers the contract adjustment process, and the smart contract adjusts its execution logic according to preset rules, such as replacing backup resources or adjusting scheduling paths. During the monitoring tasks performed by the dual-channel monitoring system, the abnormal termination and adjustment module automatically generates an encrypted data block containing information such as the reason for contract termination (e.g., restoring the affected independent twin unit to normal), the content of the adjustment (e.g., information on replaced backup resources and new scheduling paths), and the current execution progress (e.g., completed operation steps). This encrypted data block is then processed using encryption technology and written into the immutable block of the urban rail transit scheduling blockchain to ensure the security and traceability of this information.

[0107] Step S150: Deploy the smart contract to the urban rail transit scheduling blockchain node, build a simulation environment through a digital twin to simulate the contract execution process and optimize parameters. When the abnormal state meets the triggering rules, the smart contract automatically generates scheduling instructions and synchronizes them to the control terminal of the corresponding physical entity.

[0108] After the smart contract code is written, it needs to be deployed to nodes of the urban rail transit scheduling blockchain. The urban rail transit scheduling blockchain nodes are responsible for storing and executing the smart contracts. To ensure the correct and efficient execution of the smart contracts, a simulation environment is built using a digital twin. In the simulation environment, the occurrence and development of abnormal states, as well as the execution process of the smart contracts, are simulated. Through simulation, the accuracy of smart contract triggering, the smoothness of scheduling command execution, and the rationality of resource coordination are observed. Based on the simulation results, the parameters of the smart contracts are optimized, such as adjusting the trigger threshold and modifying the parameters of the scheduling path planning algorithm. When an abnormal state occurs in the actual urban rail transit system, and this state meets the triggering rules of the smart contract, the smart contract deployed on the urban rail transit scheduling blockchain node is automatically invoked. It generates scheduling commands according to the preset execution logic. These scheduling commands are synchronously transmitted to the control terminals of the corresponding physical entities, such as train control terminals, station control terminals, and resource control terminals, through an encrypted communication link. The control terminals then execute the corresponding operations according to the command content.

[0109] Step S151: Submit the completed smart contract code to the consensus node of the urban rail transit scheduling blockchain to start the distributed consensus verification process between consensus nodes. The above-mentioned distributed consensus verification process cross-verifies the syntactic correctness, logical integrity and permission compliance of the smart contract code. After the verification is completed, the smart contract code is written into the blockchain block. The deployed smart contract generates a unique contract address, which is used for subsequent calls, queries and status traceability operations of the smart contract.

[0110] After the smart contract code is written, it is first submitted to the consensus nodes of the urban rail transit scheduling blockchain. Consensus nodes are responsible for verifying and confirming transactions and contracts within the blockchain network. A distributed consensus verification process is initiated among the consensus nodes, with multiple nodes simultaneously verifying the smart contract code. Verification includes: syntax correctness (checking for syntax errors and ensuring correct compilation and execution); logical integrity (determining the completeness of the contract code's execution logic and identifying any vulnerabilities or logical contradictions); and permission compliance (ensuring that the contract code's access permissions comply with the security specifications of the urban rail transit scheduling blockchain, such as allowing only authorized entities to call certain critical functions). Each consensus node verifies the smart contract code through cross-validation. Once a certain number of consensus nodes have verified it, the smart contract code is considered secure and reliable. After verification, the smart contract code is written into a block on the blockchain, becoming part of the blockchain. The deployed smart contract generates a unique contract address, similar to a bank account address, used for subsequent operations such as calling the smart contract, querying its execution status, and tracing its status.

[0111] Step S152: Extract the current operating status data of the urban rail system from the digital twin, import the above operating status data into the simulation environment construction module, replicate the current operating scenario of the urban rail system, and form a simulation environment with parameters consistent with the actual system. At the same time, import the triggering rules and execution logic of the smart contract into the simulation environment, so that the simulation environment has the basic conditions for simulating contract execution. The above operating status data includes the real-time parameters, spatial location, correlation relationship and external environmental conditions of each independent twin unit.

[0112] To build a simulation environment capable of accurately simulating the execution process of smart contracts, it is necessary to extract the current operational status data of the urban rail system from the digital twin. This data comprehensively reflects the actual situation of the urban rail system, including real-time parameters of each independent twin unit, such as train speed, track stress, and station temperature; spatial location, i.e., the coordinates of each entity in the geographic coordinate system; relationships, such as physical connections and functional dependencies between entities; and external environmental conditions, such as weather conditions and time (day or night). This operational status data is imported into the simulation environment construction module, which replicates the current operational scenario of the urban rail system based on the data content, including the distribution, status, and interrelationships of entities, forming a simulation environment consistent with the actual system parameters. Simultaneously, the triggering rules and execution logic of the smart contract are also imported into this simulation environment, enabling it to simulate the contract execution process according to the smart contract's rules and logic.

[0113] Step S153: Extract abnormal development trend data from the event deconstruction chain, use the above abnormal development trend data as simulation input conditions, start the simulation execution process, simulate the complete change process of abnormal data from the initial state to meeting the triggering rules, and synchronously simulate the triggering response and scheduling instruction generation operation of the smart contract in this complete change process. The abnormal development trend data includes the diffusion rate of the abnormal source, the state change law of the affected independent twin unit, and the evolution characteristics of the fault propagation intensity.

[0114] The event deconstruction chain contains anomaly development trend data, which describes the entire process characteristics of an anomaly from its occurrence to its development. This data is extracted from the event deconstruction chain, such as the diffusion rate of the anomaly source (i.e., the speed at which the anomaly's influence expands); the state change patterns of the affected independent twin units, such as the trends in their parameters over time; and the evolution characteristics of fault propagation strength (i.e., how the fault propagation strength changes as the anomaly develops). This anomaly development trend data is used as simulation input conditions and input into the constructed simulation environment. The simulation execution process is initiated, and the simulation environment simulates the complete process of an anomaly's development from its initial state, gradually evolving until it meets the smart contract's triggering rules, based on the input anomaly development trend data. Simultaneously, the simulation of the smart contract's trigger response during this process is also performed: how the smart contract is activated when the anomaly state meets the triggering conditions; and the generation of scheduling instructions, i.e., which scheduling instructions the smart contract generates according to its execution logic and what the content of these instructions is.

[0115] Step S154: Collect key data in real time during the simulation process through the simulation data recording module, and organize the key data into a structured simulation execution dataset in chronological order. The key data includes the execution results of each resource scheduling instruction, the collaborative effect of resources and affected independent twin units, the overall process time of emergency response, the effect of anomaly control, and the state change data during contract execution.

[0116] During simulation execution, key data is collected in real time through the simulation data recording module. This key data includes the execution results of each resource scheduling instruction, such as whether resources arrive at their destination on time and whether operation steps are successfully executed; the collaborative effect between resources and affected independent twin units, such as whether resource actions are coordinated with the state changes of affected independent twin units and whether collaborative operations improve handling efficiency; the overall process time of emergency response, i.e., the total time required from the occurrence of an anomaly to its control; the effectiveness of anomaly control, such as whether the scope of the anomaly's impact has been reduced and whether the parameters of affected independent twin units have returned to normal; and state change data during contract execution, such as the trigger time, execution stage, and whether abnormal termination or adjustment occurs. The collected key data is organized chronologically into a structured simulation execution dataset, which reflects the key information at each point in time during the simulation.

[0117] Step S155: Call the urban rail emergency response standard database, extract the emergency response time standard, resource coordination efficiency standard, and anomaly control effect standard, compare the key data in the simulation execution dataset with the above emergency response time standard, resource coordination efficiency standard, and anomaly control effect standard in multiple dimensions, identify the problems that occur during the simulation, locate the smart contract parameter deviations that cause the above problems through the problem tracing module, and generate an optimization scheme that includes the direction and magnitude of parameter adjustment.

[0118] The urban rail emergency response standard database stores various emergency response standards developed based on industry standards, historical experience, and actual needs. This database is used to extract emergency response time standards (the maximum allowable time for handling different types of anomalies); resource coordination efficiency standards (efficiency indicators of coordinated actions between resources, such as response time and accuracy of coordination); and anomaly control effectiveness standards (the expected effectiveness indicators after anomaly handling, such as the reduction in the scope of anomaly impact and the recovery rate of parameters in affected independent twin units). Key data from the simulated execution dataset are compared with these standards in multiple dimensions. For example, the overall emergency response process time obtained from the simulation is compared with the emergency response time standards; the resource coordination effect is compared with the resource coordination efficiency standards; and the anomaly control effect is compared with the anomaly control effectiveness standards. Through comparison, problems in the simulation process are identified, such as excessively long response times, low resource coordination efficiency, and poor anomaly control effects. Then, the problem tracing module analyzes these problems to identify deviations in smart contract parameters that cause the problems, such as unreasonable trigger threshold settings, inappropriate scheduling path planning algorithm parameters, and unsuitable time node settings in timing coordination requirements. Based on the parameter deviation, an optimization scheme is generated that includes the direction and magnitude of parameter adjustment, such as lowering the trigger threshold to a certain extent, adjusting the weight coefficients in the path planning algorithm, and advancing or delaying the timing nodes of time-series coordination.

[0119] Step S156: Adjust the timing coordination parameters, resource deployment order parameters, and scheduling path planning logic parameters in the smart contract according to the above optimization scheme. Re-import the adjusted smart contract parameters into the simulation environment, repeat the simulation process and collect new simulation execution data. Compare the new simulation execution data with the emergency response standard again. If there is still a deviation, continue to optimize the parameters until the key indicators in the simulation execution data meet the emergency response standard requirements, and determine the final smart contract parameters.

[0120] The relevant parameters in the smart contract are adjusted according to the optimization plan. These parameters include timing coordination parameters, such as the start interval of each resource and the operation connection time node; resource deployment order parameters, such as the scheduling order weight of resources with different priorities; and scheduling path planning logic parameters, such as the priority weight of emergency channels and the avoidance coefficient of avoidance objects. After the parameter adjustment is completed, the adjusted smart contract parameters are re-imported into the simulation environment. The above simulation process is repeated, that is, inputting abnormal development trend data, simulating the execution process of the smart contract, and collecting new simulated execution data. The new simulated execution data is compared with the emergency response standard again to check whether the key indicators have met the requirements. If there are still deviations, it means that the parameter adjustment is not perfect enough. It is necessary to analyze the problem again based on the new comparison results, adjust the optimization plan, and further adjust the smart contract parameters. The above process is repeated until all key indicators in the simulated execution data, such as emergency response time, resource coordination efficiency, and abnormal control effect, meet the requirements of the emergency response standard. The smart contract parameters determined at this time are the final optimized parameters.

[0121] Step S157: Collect abnormal state data of each independent twin unit in real time through the sensing channel of the digital twin, and compare the collected abnormal state data with the triggering rules of the smart contract in real time. The comparison process is realized through the condition judgment module built into the contract. When the parameter value in the abnormal state data continuously reaches the threshold set by the triggering rule, the urban rail dispatching blockchain node automatically calls the smart contract and generates the corresponding dispatching instructions according to the execution logic.

[0122] After the smart contract is deployed to the urban rail transit dispatching blockchain node, the digital twin's sensing channels continuously collect abnormal state data from each independent twin unit. This data is then transmitted to the urban rail transit dispatching blockchain node via a real-time transmission link. The blockchain node compares the collected abnormal state data with the trigger rules set in the smart contract in real time. The comparison process is completed by the contract's built-in condition judgment module. This module judges the abnormal state data based on conditions in the trigger rules, such as threshold values ​​and durations of abnormal parameters. When the parameter values ​​in the abnormal state data continuously reach the thresholds set in the trigger rules, such as train braking pressure continuously falling below the safety threshold for five minutes, the condition judgment module determines that the trigger condition is met. At this time, the urban rail transit dispatching blockchain node automatically invokes the smart contract. The smart contract generates corresponding dispatch instructions according to the preset execution logic, such as dispatching repair vehicles or notifying relevant personnel.

[0123] Step S158: After the dispatch instruction is generated, it is transmitted to the instruction distribution module through the encrypted communication link of the blockchain. According to the type of dispatch instruction and the identifier of the corresponding physical entity, the dispatch instruction is sent to the train control terminal, station control terminal, resource control terminal and power supply control terminal respectively.

[0124] After dispatch instructions are generated, they need to be securely and accurately transmitted to the corresponding physical entity control terminals. The blockchain's encrypted communication link employs advanced encryption technologies, such as a combination of symmetric and asymmetric encryption, to encrypt the dispatch instructions, ensuring they are not stolen, tampered with, or leaked during transmission. The encrypted dispatch instructions are then transmitted to the instruction distribution module, which parses them, extracting the instruction type (e.g., train adjustment instructions, resource dispatch instructions, station evacuation instructions), and the identifier of the corresponding physical entity (e.g., specific train number, station number, resource number). Based on the instruction type and physical entity identifier, the dispatch instructions are sent to the corresponding control terminals. For example, the train control terminal receives and executes train-related instructions, the station control terminal handles station-related instructions, the resource control terminal handles emergency resource dispatch instructions, and the power supply control terminal handles power system adjustment instructions.

[0125] Step S159: During the instruction transmission process, a synchronization verification mechanism is initiated. After each control terminal receives the scheduling instruction, it generates a reception confirmation signal containing a summary of the instruction content. The reception confirmation signal is fed back to the instruction distribution module to summarize the confirmation signals of all control terminals. If there is a control terminal that has not received a confirmation signal, the scheduling instruction is retransmitted until all corresponding control terminals have fed back reception confirmation, thus completing the synchronous transmission of the scheduling instruction.

[0126] To ensure all control terminals accurately receive scheduling instructions, a synchronization verification mechanism is initiated during instruction transmission. Upon receiving a scheduling instruction, each control terminal processes the instruction content to generate an instruction digest, which uniquely represents the instruction content. Then, the control terminal generates a reception acknowledgment signal containing this instruction digest and sends it back to the instruction distribution module via an encrypted communication link. The instruction distribution module aggregates and checks all acknowledgment signals from all control terminals to determine if all terminals that should receive the instruction have sent acknowledgment signals. If any control terminal has not received an acknowledgment signal, it indicates that the terminal may not have successfully received the instruction, and the instruction distribution module will retransmit the scheduling instruction to that terminal. This process is repeated until all corresponding control terminals have sent reception acknowledgment signals, ensuring that the scheduling instruction has been successfully received by all relevant control terminals, thus completing the synchronous transmission of the scheduling instruction.

[0127] Step S1510: After each control terminal receives the scheduling instruction, it executes the corresponding operation according to the instruction content. At the same time, the execution status, completion status and abnormal feedback data of the operation are transmitted to the urban rail dispatching blockchain node in real time through the sensing channel of the digital twin. The blockchain node records the above feedback data into the immutable block in chronological order to form a complete contract execution log.

[0128] Upon receiving dispatch instructions, each control terminal executes corresponding operations based on the instructions. For example, the train control terminal adjusts the train's speed or stops at stations according to the instructions; the resource control terminal dispatches emergency resources to designated locations according to the instructions. During operation execution, the control terminal transmits the real-time execution status (e.g., executing, paused), completion status (e.g., percentage completed, successful completion), and any abnormal feedback data (e.g., equipment malfunctions, operational errors) to the urban rail dispatching blockchain node via the digital twin's sensing channel. Upon receiving this feedback data, the blockchain node records it in chronological order into the blockchain's immutable blocks. Due to the characteristics of blockchain, this recorded data cannot be tampered with and can be permanently stored, forming a complete contract execution log. This contract execution log records in detail the entire process of the smart contract from triggering to completion, including the transmission of dispatch instructions and the operation execution status of the control terminals.

[0129] Furthermore, the method may also include:

[0130] Step S210: Throughout the execution of the smart contract, continuously collect data on the abnormal state changes of the affected independent twin units, the working status data and operation progress data of the emergency resource independent twin units through the sensing channel of the digital twin, and classify and integrate the data according to the collection time order to generate a real-time monitoring dataset containing abnormal recovery progress data, resource consumption data and disposal effect evaluation data.

[0131] Throughout the execution of the smart contract, the digital twin's sensing channels remain active, continuously collecting various relevant data. For affected independent twin units, data on changes in their abnormal states is collected, such as trends in abnormal parameter values ​​and the expansion or contraction of the abnormal impact range. For emergency resource independent twin units, operational status data is collected, such as equipment operating temperature, power consumption, and whether malfunctions have occurred. Simultaneously, progress data on emergency resource operations is also collected, such as the start time, end time, and duration of each operation step. The data is categorized and integrated according to the order of collection time, grouping data of the same type or time period together. Through analysis and processing of the integrated data, a real-time monitoring dataset is generated. This dataset includes anomaly recovery progress data, i.e., the degree and speed at which affected independent twin units return to normal; resource consumption data, such as fuel consumption, power consumption, and material usage during emergency resource disposal; and disposal effectiveness evaluation data, such as whether the anomaly has been effectively controlled and whether the disposal measures have achieved the expected goals.

[0132] Step S211: Extract the state recovery data of the affected independent twin unit from the real-time monitoring dataset and compare it with the state recovery standard in the anomaly recovery judgment specification. The anomaly recovery judgment specification includes the state recovery standard of the affected independent twin unit, the anomaly data stability requirements and the safe operation verification items. At the same time, the sensor data of the physical entity and the simulation data of the digital twin are called for multi-source cross-verification. If the monitoring data of the affected independent twin unit continuously covers the synchronization cycle of the complete operation cycle and is within the normal range, and the fluctuation amplitude of the anomaly data is within the benchmark range of normal equipment operation, and passes the multi-dimensional safety verification, then an anomaly recovery confirmation result is generated.

[0133] State recovery data of affected independent twin units were extracted from the real-time monitoring dataset. This data reflects the state changes of the affected independent twin units during emergency response. The data was then compared with the state recovery standards in the anomaly recovery judgment specification. This specification, formulated based on the safety operation requirements and equipment performance standards of the urban rail transit system, includes state recovery standards for affected independent twin units (i.e., the normal range to which each parameter should be restored); anomaly data stability requirements (i.e., the time required for parameters to remain stable after restoration); and safety operation verification items, such as equipment functional tests and performance tests. During the comparison process, sensor data from physical entities, such as data directly collected by sensors installed on trains, tracks, and stations, were simultaneously used for multi-source cross-verification with the simulated data from the digital twin. If the monitoring data of the affected independent twin unit continuously covers a complete operating cycle and remains within the normal range, for example, when a train completes a full travel section and all its parameters are normal; if the fluctuation range of the abnormal data is within the baseline range of normal equipment operation, that is, the parameter changes are within the allowable error range; and if it has passed multi-dimensional safety verification items, such as functional testing and performance testing, then an anomaly recovery confirmation result is generated, indicating that the affected independent twin unit has successfully returned to normal.

[0134] Step S212: Transmit the anomaly recovery confirmation result to the urban rail transit scheduling blockchain node, so that the urban rail transit scheduling blockchain node can execute the termination process of the smart contract after receiving the result and generate an emergency response completion report. The emergency response completion report includes basic event information, resource usage details, response process records and recovery effect evaluation. At the same time, it extracts the visual replay data of the entire process of anomaly development and response from the digital twin and attaches the visual replay data to the emergency response completion report.

[0135] After the anomaly recovery confirmation result is generated, it is transmitted to the urban rail transit dispatch blockchain node via an encrypted communication link. Upon receiving the result, the urban rail transit dispatch blockchain node confirms that the anomaly handling work has been completed and then executes the termination process of the smart contract, stopping further execution of the smart contract. Simultaneously, based on data such as the contract execution log and real-time monitoring dataset recorded in the blockchain, an emergency response completion report is generated. This report includes basic event information, such as the time, location, and type of the anomaly; resource usage details, such as which emergency resources were used, the quantity of each resource used, and the time used; a handling process record, detailing each step and operation of the emergency response; and a recovery effect evaluation, assessing the effectiveness of the anomaly handling, such as whether the recovery time was within the standard range and whether resource usage was reasonable. Furthermore, visualized replay data of the entire process from the anomaly's occurrence to its development, handling, and recovery is extracted from the digital twin. This visualized replay data is presented in the form of 3D animation or video, intuitively showcasing the entire emergency response process. Attaching this visualized replay data to the emergency response completion report makes the report more intuitive and easier to understand.

[0136] Step S213: Write the above emergency response completion report into the urban rail dispatch blockchain through the blockchain's encrypted storage interface to form an immutable response record. At the same time, push the emergency response completion report to the management terminals of the urban rail emergency dispatch center, safety management department, and relevant operating units so that the management terminals can automatically generate a reception log and feed it back to the blockchain node after receiving the report.

[0137] After the emergency response completion report is generated, it is written to the urban rail dispatch blockchain through the blockchain's encrypted storage interface. The encrypted storage interface encrypts the report, ensuring its security and immutability during storage. Once written to the blockchain, the emergency response completion report becomes part of the blockchain, forming an immutable record that can be queried and audited later. Simultaneously, the emergency response completion report is pushed through the communication network to the management terminals of the urban rail emergency dispatch center, safety management department, and relevant operating units. Upon receiving the report, these management terminals automatically generate a reception log, recording the report's reception time, receiving terminal identifier, and other information, and then feed this log back to the urban rail dispatch blockchain nodes. The blockchain nodes associate the reception log with the emergency response completion report, further improving the completeness and traceability of the response record.

[0138] Step S214: After extracting the technical performance parameters, loss data and fault hazard records of the independent twin unit of emergency resources from the real-time monitoring dataset, the status assessment results of each emergency resource are generated by comparing the factory performance parameters and maintenance standards of the resources. The status assessment results include the availability status of the resources, the degree of loss and the recommended maintenance items.

[0139] The real-time monitoring dataset contains various data from independent twin units of emergency resources during the disposal process. Technical performance parameters of the emergency resources are extracted, such as equipment output power, operating pressure, and accuracy; wear and tear data, such as the degree of wear and tear, aging of components, and fuel or electricity consumption; and potential fault records, such as abnormal noise, vibration, and excessively high temperatures during equipment operation. The extracted technical performance parameters are compared with the performance parameters at the time of manufacture to analyze whether the parameters have decreased and the extent of the decrease; wear and tear data are compared with the maximum permissible wear and tear specified in maintenance standards; and combined with potential fault records, the current status of each emergency resource is comprehensively assessed. The generated status assessment results include the resource's availability status (e.g., fully available, partially available, unavailable); the degree of wear and tear (e.g., minor wear, moderate wear, severe wear); and recommended maintenance items (e.g., components to be replaced, maintenance work to be performed, and performance calibration to be performed).

[0140] Step S215: Transmit the above status assessment results to the urban rail emergency resource blockchain node, update the storage data of the corresponding emergency resources in the blockchain, and if the status assessment results show that the resources are faulty or damaged, generate a maintenance resource allocation instruction and send it to the corresponding maintenance unit.

[0141] The status assessment results of emergency resources are transmitted to the urban rail emergency resource blockchain node. The blockchain node updates the stored data of the corresponding emergency resources based on the status assessment results, such as updating information on resource availability and wear and tear, ensuring that the emergency resource data recorded in the blockchain is consistent with the actual status. If the status assessment results indicate that emergency resources are faulty or worn, such as equipment malfunctioning or wear exceeding maintenance standards, the urban rail emergency resource blockchain node generates a maintenance resource allocation instruction. This instruction includes the resource identifier requiring maintenance, a description of the fault or wear, recommended maintenance measures, and maintenance priority. The maintenance resource allocation instruction is then issued to the corresponding maintenance units, such as the urban rail system's maintenance department or the equipment supplier's maintenance team, notifying them to promptly maintain the faulty or worn resources.

[0142] Step S216: Extract the blockchain log data, emergency response completion report and resource status assessment results of this emergency response from the urban rail dispatch blockchain node, calculate the deviation between the anomaly judgment standard of the digital twin and the actual anomaly data, count the misjudgment rate of the smart contract triggering rules, analyze the functional adaptation deviation data of the resource matching algorithm, and generate parameter adjustment suggestions based on the analysis results.

[0143] Blockchain log data related to this emergency response was extracted from the urban rail transit dispatch blockchain nodes. This log data recorded the execution process of the smart contract; the emergency response completion report, which included the overall situation and results of the response; and the resource status assessment results, reflecting the usage and depletion of emergency resources. Using this data, the performance of the digital twin and smart contract was evaluated. The deviation between the anomaly detection criteria of the digital twin and the actual anomaly data was calculated, i.e., the degree of difference between the actual anomaly data and the threshold in the anomaly detection criteria, to analyze whether the anomaly detection criteria needed adjustment. The false positive rate of the smart contract triggering rules was statistically analyzed, including the ratio of false triggers and missed triggers, to assess the accuracy of the triggering rules. The functional adaptation deviation data of the resource matching algorithm was analyzed, i.e., the deviation between the resource combination scheme and the actual emergency response needs, to determine whether the resource matching algorithm needed optimization. Based on the above analysis results, parameter adjustment suggestions were generated, such as adjusting the anomaly detection threshold of the digital twin, optimizing the triggering rule parameters of the smart contract, and improving the weight settings of the resource matching algorithm.

[0144] Step S217: Write the above parameter adjustment suggestions into the configuration module of the digital twin and smart contract, update the anomaly judgment threshold of the digital twin and the trigger parameters of the smart contract, generate a parameter update log after the update is completed, and write the parameter update log into the urban rail dispatching blockchain for parameter traceability in subsequent emergency dispatching processes.

[0145] After parameter adjustment suggestions are generated, they are written into the configuration modules of the digital twin and smart contracts. Based on the suggestions, the configuration modules adjust the anomaly detection thresholds of the digital twin, such as raising or lowering the anomaly threshold of a specific parameter; and update the trigger parameters of the smart contracts, such as modifying threshold conditions in the trigger rules and adjusting the timing nodes for timing coordination. After the parameter updates are completed, a parameter update log is generated, recording information such as the updated parameter name, values ​​before and after the update, update time, and update reason. The parameter update log is written to the urban rail transit dispatch blockchain. Due to the immutability of the blockchain, this parameter update log can be permanently stored for tracing and auditing parameter changes in subsequent emergency dispatch processes, ensuring the traceability and transparency of parameter adjustments.

[0146] Step S218: Extract the event deconstruction chain, resource combination scheme, smart contract content, emergency response completion report and parameter optimization suggestions from the emergency response data, and classify and organize them according to anomaly type, response scenario and resource type, and input them into the standardized emergency response case library. The standardized emergency response case library establishes a multi-dimensional search index for data retrieval by anomaly type, affected independent twin unit category and resource usage type, and automatically associates similar historical cases.

[0147] This emergency response generated a wealth of valuable data. From this data, we extracted the event deconstruction chain, which details the propagation path and impact scope of the anomaly; the resource combination plan, recording the selection and deployment of emergency resources; the smart contract content, including the contract triggering rules and execution logic; the emergency response completion report, summarizing the entire process and results; and parameter optimization suggestions, providing directions for future improvements. The data was categorized and organized according to anomaly type (e.g., mechanical failure, electrical failure, personnel gathering); response scenario (e.g., train anomaly, track anomaly, station anomaly); and resource type (e.g., equipment resources, personnel resources, material resources). The organized data was then input into a standardized emergency response case library. This library has established multi-dimensional search indexes, such as anomaly type index, affected independent twin unit category index, and resource usage type index. These indexes allow for convenient data retrieval based on different criteria, quickly finding the required cases. Furthermore, the case library has an automatic function to link to similar historical cases; when a new anomaly is entered, it can automatically retrieve similar historical emergency response cases.

[0148] Based on the same inventive concept, please refer to Figure 2 This paper shows a schematic block diagram of the structure of an intelligent auxiliary decision-making system 100 for emergency command of urban rail transit systems, which is provided in an embodiment of this application for executing the above-described intelligent auxiliary decision-making method for emergency command of urban rail transit systems. The intelligent auxiliary decision-making system 100 for emergency command of urban rail transit systems may include a communication unit 110, a machine-readable storage medium 120, and a processor 130.

[0149] In this embodiment, both the machine-readable storage medium 120 and the processor 130 are located in the intelligent auxiliary decision-making system 100 for emergency command of urban rail transit systems, and are separately configured. Alternatively, the machine-readable storage medium 120 can also be integrated into the processor 130 and can communicate and interact with external systems through the communication unit 110. The machine-readable storage medium 120 stores machine-executable instructions for executing the scheme of this application, and the processor 130 executes the machine-executable instructions stored in the machine-readable storage medium 120 to implement the intelligent auxiliary decision-making method for emergency command of urban rail transit systems provided in the aforementioned method embodiments.

[0150] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. An intelligent auxiliary decision-making method for emergency command in urban rail transit systems, characterized in that, The method includes: A digital twin of all elements of the urban rail transit system is constructed, which covers scenarios of trains, tracks, stations, power supply and emergency resources. Each scenario is decomposed into an independent twin unit. Each independent twin unit synchronizes the operating status and spatial location of the physical entity through a real-time sensing channel to realize the mapping between the physical world and the digital space. By leveraging the dynamic perception capabilities of digital twins, abnormal trigger signals are captured, and the propagation trajectory of abnormal trigger signals among independent twin units is tracked. An event deconstruction chain is constructed, which includes the location of the abnormal source, the hierarchy of the affected independent twin units, and the fault propagation intensity. The fault propagation intensity reflects the difference in the degree of impact of the abnormality on different independent twin units. By calling the blockchain-based evidence data of urban rail emergency resources, the event deconstruction chain is dynamically coupled with the independent twin unit of emergency resources to generate a resource combination scheme that covers resource adaptation characteristics, response efficiency and deployment order. The blockchain-based evidence data of urban rail emergency resources includes the attribute characteristics, storage location, maintenance records and availability status of emergency resources. Based on the transmission characteristics of resource combination schemes and event deconstruction chains, triggering rules and execution logic of smart contracts are generated. The smart contracts are used to clarify the automatic execution process of scheduling instructions, the boundaries of rights and responsibilities for resource use, and the timing coordination requirements of emergency links. The timing coordination requirements standardize the action connection nodes and interaction methods of each participant. The smart contract is deployed to the urban rail transit scheduling blockchain node. A simulation environment is built using a digital twin to simulate the contract execution process and optimize parameters. When an abnormal state meets the triggering rules, the smart contract automatically generates scheduling instructions and synchronizes them to the control terminal of the corresponding physical entity. The method of capturing abnormal trigger signals based on the dynamic sensing capabilities of digital twins includes: Generate differentiated anomaly detection criteria for each independent twin unit; The digital twin's perception data processing module continuously analyzes the real-time monitoring data of each independent twin unit. When the real-time monitoring data exceeds the anomaly judgment standard for multiple consecutive synchronization cycles, an anomaly trigger signal is generated after confirming the existence of the anomaly by comparing the data of the associated independent twin units and historical anomaly data. The content of the anomaly trigger signal includes the time of the anomaly occurrence, the corresponding independent twin unit identifier, and the specific anomaly manifestation. The process of tracing the propagation trajectory of the anomaly trigger signal among the independent twin units constructs an event deconstruction chain that includes anomaly source location, affected independent twin unit hierarchy, and fault propagation strength, including: Using the independent twin unit that triggered the anomaly as the starting point for tracing the source, find independent twin units that have a direct physical connection or functional dependency with the starting point for tracing the source, mark them as first-level affected independent twin units, and record the connection type and the way the impact is transmitted. Trend analysis is performed on the monitoring data of the first-level affected independent twin units. If the data shows obvious abnormal change characteristics and conforms to the transmission law, the associated independent twin units are continued to be traversed and marked as the second-level affected independent twin units. This logic is followed to expand layer by layer until the traversal program does not find any new affected independent twin units. The fault propagation strength is calculated for each affected independent twin unit. The fault propagation strength is generated based on the degree of association between the independent twin unit and the abnormal origin, the physical distance, and the functional dependency level. The degree of association is quantified by entity connection relationship, the physical distance is calculated by spatial coordinates, and the functional dependency level is determined by system architecture analysis. According to the order of anomaly propagation, the anomaly origin and the affected independent twin units at all levels are organized into a hierarchical sequence. Each independent twin unit is labeled with the fault propagation intensity, anomaly change characteristics and propagation path, forming a structured hierarchical table of affected independent twin units. The origin of the anomaly is located and identified. The identification content includes the anomaly type, specific location coordinates, initial impact range and development trend prediction. The anomaly source identification, the affected independent twin unit hierarchy table and fault propagation intensity data are integrated to form an event deconstruction chain. After each twin synchronization cycle, the abnormal state and fault propagation strength of each affected independent twin unit are reassessed, and the hierarchy table of affected independent twin units is adjusted by adding, deleting, or modifying data.

2. The intelligent auxiliary decision-making method for emergency command of urban rail transit systems according to claim 1, characterized in that, The construction of a full-element digital twin of the urban rail transit system includes: Collect full-dimensional data of physical entities in the urban rail system, and construct a high-precision basic twin model of each entity based on the full-dimensional data. The full-dimensional data includes geometric structure data, material attribute data, operating parameter data and correlation data. Among them, the geometric structure data includes the train body outline, track cross-sectional shape, station building layout and power supply line direction. Configure a multi-source sensing interface for each basic twin model to access the real-time monitoring data of the corresponding physical entity; The status data of each independent twin unit is time-stamped and spatial coordinates are calibrated. The train independent twin unit and the track independent twin unit are linked in real time through track mileage coordinates. The station independent twin unit and the emergency resource independent twin unit are associated through station area grid coordinates. The power supply independent twin unit forms a linkage relationship with other independent twin units through the power supply network topology. The association relationship is dynamically adjusted according to the physical operation status. Layered rendering and dynamic highlighting techniques are used to display the operating status of each independent twin unit.

3. The intelligent auxiliary decision-making method for emergency command of urban rail transit systems according to claim 1, characterized in that, The process of calling the blockchain-stored data of urban rail emergency resources and dynamically coupling the event deconstruction chain with the independent twin unit of emergency resources includes: Access the distributed nodes of the urban rail emergency resource blockchain to retrieve encrypted and stored emergency resource data; Extract the type information of the anomaly source, the distribution range of the affected independent twin units, and the fault characteristics from the event deconstruction chain, and extract the resource and functional requirements for emergency response; Based on the resource functional requirements and the resource type attributes in the blockchain evidence data, a preliminary matching is performed to select resources that meet the functional requirements and are currently in a normal available state, forming a candidate resource set.

4. The intelligent auxiliary decision-making method for emergency command of urban rail transit systems according to claim 3, characterized in that, The generation of resource combination schemes, which encompass resource adaptation characteristics, response efficiency, and deployment order, includes: The real-time location information of the independent twin units of emergency resources corresponding to the candidate resources in the candidate resource set is obtained by digital twins. Combined with the mobility characteristics of the candidate resources, the response efficiency of each candidate resource to the anomaly source and the main affected independent twin units is obtained. By comparing the resource technical performance parameters with the anomaly handling requirement parameters, the resource adaptation characteristics are calculated, the resource historical maintenance database is called, and the fault handling success rate data is extracted to correct the resource adaptation characteristics. The initial impact level of the anomaly source is used to set evaluation weight parameters. The initial impact level is quantified by the scope and severity of the anomaly. The response efficiency is converted into a standardized response score. The resource adaptation characteristics and the standardized response score are weighted according to the evaluation weight parameters to obtain the comprehensive adaptation score of each candidate resource. Candidate resources are sorted according to the comprehensive adaptation score, and the number distribution data and fault propagation intensity data of affected independent twin units are extracted. The top K types of resources with the highest comprehensive adaptation scores are selected to form a resource combination, covering all abnormal scenarios and affected independent twin units. Each resource in the resource combination is labeled with specific resource adaptation characteristics, response efficiency evaluation results, and deployment order. The deployment order is determined by the fault propagation strength of the affected independent twin unit corresponding to the resource in the event deconstruction chain. When the affected independent twin unit corresponding to the fault propagation strength is a core-level functional dependency entity, its corresponding resource deployment order is set to the first priority; when it is a line-level functional dependency entity, it corresponds to the second priority; and when it is a facility-level entity, it corresponds to the third priority. Resource allocation instructions are issued in order of priority.

5. The intelligent auxiliary decision-making method for emergency command of urban rail transit systems according to claim 1, characterized in that, The process of deploying smart contracts to urban rail transit scheduling blockchain nodes, and using digital twins to build a simulation environment to simulate the contract execution process and optimize parameters includes: The completed smart contract code is submitted to the consensus node of the urban rail transit scheduling blockchain, and the distributed consensus verification process between the consensus nodes is initiated. The distributed consensus verification process cross-verifies the syntactic correctness, logical integrity and permission compliance of the smart contract code. After the verification is completed, the smart contract code is written into the blockchain block. The deployed smart contract generates a unique contract address, which is used for subsequent calls, queries and status traceability operations of the smart contract. The current operating status data of the urban rail system is extracted from the digital twin and imported into the simulation environment construction module to replicate the current operating scenario of the urban rail system, forming a simulation environment with parameters consistent with the actual system. At the same time, the triggering rules and execution logic of the smart contract are imported into the simulation environment, so that the simulation environment has the basic conditions to simulate contract execution. The operating status data includes the real-time parameters, spatial location, correlation relationship and external environmental conditions of each independent twin unit. The abnormal development trend data is extracted from the event deconstruction chain. The abnormal development trend data is used as the simulation input condition to start the simulation execution process. The simulation process is simulated to simulate the complete change process of the abnormal data from the initial state to the point of meeting the triggering rules. The triggering response and scheduling instruction generation operation of the smart contract in this complete change process are simulated simultaneously. The abnormal development trend data includes the diffusion rate of the abnormal source, the state change law of the affected independent twin unit, and the evolution characteristics of the fault propagation intensity. The simulation data recording module collects key data in real time during the simulation process, and organizes the key data into a structured simulation execution dataset in chronological order. The key data includes the execution results of each resource scheduling instruction, the collaborative effect of resources and affected independent twin units, the overall process time of emergency response, the effect of anomaly control, and the state change data during contract execution. The emergency response standard database for urban rail transit is accessed, and the emergency response time standard, resource coordination efficiency standard, and anomaly control effect standard are extracted. The key data in the simulation execution dataset are compared with the emergency response time standard, resource coordination efficiency standard, and anomaly control effect standard in multiple dimensions to identify problems that occur during the simulation. The problem tracing module is used to locate the deviation of smart contract parameters that cause the problem, and an optimization scheme including the direction and magnitude of parameter adjustment is generated. Adjust the timing coordination parameters, resource deployment order parameters, and scheduling path planning logic parameters in the smart contract according to the optimization scheme. Re-import the adjusted smart contract parameters into the simulation environment, repeat the simulation process and collect new simulated execution data. Compare the new simulated execution data with the emergency response standard again. If there are still deviations, continue to optimize the parameters until the key indicators in the simulated execution data meet the requirements of the emergency response standard, and determine the final smart contract parameters.

6. The intelligent auxiliary decision-making method for emergency command of urban rail transit systems according to claim 5, characterized in that, When an abnormal state meets the triggering rules, the contract automatically generates a scheduling instruction and synchronizes it to the control terminal of the corresponding physical entity, including: Abnormal status data of each independent twin unit is collected in real time through the sensing channel of the digital twin. The collected abnormal status data is compared with the triggering rules of the smart contract in real time. The comparison process is realized through the condition judgment module built into the contract. When the parameter value in the abnormal status data continuously reaches the threshold set by the triggering rule, the urban rail dispatching blockchain node automatically calls the smart contract and generates the corresponding dispatching instruction according to the execution logic. After the dispatching instruction is generated, it is transmitted to the instruction distribution module through the encrypted communication link of the blockchain. According to the type of dispatching instruction and the identifier of the corresponding physical entity, the dispatching instruction is sent to the train control terminal, station control terminal, resource control terminal and power supply control terminal respectively. During instruction transmission, a synchronization verification mechanism is initiated. After each control terminal receives the scheduling instruction, it generates a reception confirmation signal containing a summary of the instruction content. This reception confirmation signal is fed back to the instruction distribution module to summarize the confirmation signals of all control terminals. If there is a control terminal that has not received a confirmation signal, the scheduling instruction is retransmitted until all corresponding control terminals have fed back reception confirmation, thus completing the synchronous transmission of the scheduling instruction. After receiving the scheduling instructions, each control terminal executes the corresponding operations according to the instructions. At the same time, the execution status, completion status, and abnormal feedback data of the operations are transmitted in real time to the urban rail dispatching blockchain node through the sensing channel of the digital twin. The blockchain node records the feedback data into an immutable block in chronological order to form a complete contract execution log.

7. The intelligent auxiliary decision-making method for emergency command of urban rail transit systems according to claim 1, characterized in that, The method further includes: Throughout the execution of the smart contract, the abnormal state change data of the affected independent twin unit, the working status data and operation progress data of the emergency resource independent twin unit are continuously collected through the sensing channel of the digital twin. The data are then classified and integrated according to the collection time order to generate a real-time monitoring dataset containing abnormal recovery progress data, resource consumption data and disposal effect evaluation data. The state recovery data of the affected independent twin unit is extracted from the real-time monitoring dataset and compared with the state recovery standard in the anomaly recovery judgment specification. The anomaly recovery judgment specification includes the state recovery standard of the affected independent twin unit, the anomaly data stability requirements and the safe operation verification items. At the same time, the sensor data of the physical entity and the simulation data of the digital twin are called for multi-source cross-verification. If the monitoring data of the affected independent twin unit continuously covers the synchronization cycle of the complete operation cycle and is within the normal range, and the fluctuation amplitude of the anomaly data is within the benchmark range of normal equipment operation, and passes the multi-dimensional safety verification, then the anomaly recovery confirmation result is generated. The abnormal recovery confirmation result is transmitted to the urban rail dispatching blockchain node, so that the urban rail dispatching blockchain node executes the termination process of the smart contract after receiving the result and generates an emergency response completion report. The emergency response completion report includes basic event information, resource usage details, response process records and recovery effect evaluation. At the same time, the visualized replay data of the entire abnormal development and response process is extracted from the digital twin and attached to the emergency response completion report. The emergency response completion report is written into the urban rail dispatch blockchain through the blockchain's encrypted storage interface to form an immutable response record. At the same time, the emergency response completion report is pushed to the management terminals of the urban rail emergency dispatch center, safety management department, and relevant operating units, so that the management terminals can automatically generate a reception log after receiving the report and feed it back to the blockchain node. After extracting the technical performance parameters, loss data and fault hazard records of the independent twin units of emergency resources from the real-time monitoring dataset, the status assessment results of each emergency resource are generated by comparing the factory performance parameters and maintenance standards of the resources. The status assessment results include the resource availability status, loss level and recommended maintenance items. The status assessment results are transmitted to the urban rail emergency resource blockchain node to update the storage data of the corresponding emergency resources in the blockchain. If the status assessment results show that the resources are faulty or damaged, a maintenance resource allocation instruction is generated and sent to the corresponding maintenance unit. Extract the blockchain log data, emergency response completion report and resource status assessment results of this emergency response from the urban rail dispatch blockchain node, calculate the deviation between the anomaly judgment standard of the digital twin and the actual anomaly data, count the misjudgment rate of smart contract triggering rules, analyze the functional adaptation deviation data of the resource matching algorithm, and generate parameter adjustment suggestions based on the analysis results. The parameter adjustment suggestions are written into the configuration module of the digital twin and the smart contract, the anomaly judgment threshold of the digital twin and the trigger parameters of the smart contract are updated, a parameter update log is generated after the update is completed, and the parameter update log is written into the urban rail dispatching blockchain for parameter traceability in subsequent emergency dispatching processes. The event deconstruction chain, resource combination scheme, smart contract content, emergency response completion report and parameter optimization suggestions are extracted from the emergency response data. These are then categorized and organized according to anomaly type, response scenario and resource type, and input into a standardized emergency response case library. This standardized emergency response case library establishes a multi-dimensional search index for data retrieval by anomaly type, affected independent twin unit category and resource usage type, while automatically associating similar historical cases.

8. An intelligent auxiliary decision-making system for emergency command in urban rail transit systems, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the intelligent auxiliary decision-making method for emergency command of urban rail systems as described in any one of claims 1 to 7 by executing the machine-executable instructions.

Images