Rail transit digital system operation control system and method

Abstract

The application relates to the technical field of rail transit simulation control, in particular to a rail transit digital system operation control system and method, edge nodes are deployed locally in subsystems, regional nodes coordinate interaction in the region, a central node controls the global clock and leads global emergency, forming a hierarchical and graded distributed control system of local problem local processing, regional problem regional coordination and global problem centralized decision-making; the interaction data of the subsystems in the region do not need to be uploaded to the central node and are directly forwarded through the regional nodes, meeting the real-time requirement of the strongly coupled subsystems and realizing efficient cooperation and precise control of the rail transit digital system multi-subsystems.

Description

Technical Field

[0001] This application relates to the field of rail transit simulation control technology, and in particular to an operation control system and method for a rail transit digital system. Background Technology

[0002] As rail transit evolves towards intelligence and integration, the digital whole system, which integrates multiple subsystems such as power supply, traction, pantograph-catenary system, and braking system, has become the core development direction of the industry. Its operational efficiency and safety level directly depend on the architecture design of the operation control software. As the central core of the digital whole system, the operation control software needs to coordinate the collaboration of multiple subsystems, respond to real-time control commands, and resist fault risks, which is the key to ensuring the stable operation of the system.

[0003] Currently, the application scenarios of digital systems in rail transit are continuously expanding, such as intelligent scheduling and autonomous driving. This has upgraded the performance requirements for operation control software to the stringent microsecond-level real-time performance standard. However, the design logic and technical solutions of existing operation control software architectures remain at the traditional stage of single-function verification and local module control, which is significantly out of step with the complex needs of current systems. Specifically, in related technologies, the entire digital system requires global collaboration among all modules, and the local decisions of any module need to be quickly synchronized to the entire system.

[0004] Therefore, how to provide a digital system operation control scheme for rail transit to solve the technical problems of high control complexity and low control efficiency caused by the coupling of multiple subsystems is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide an operation control system and method for a digital rail transit system, which can solve the technical problems of high control complexity and low control efficiency caused by the coupling of multiple subsystems.

[0006] This application provides an operation control system for a rail transit digital system. The rail transit digital system includes multiple subsystems distributed by region, each subsystem including a simulation model for simulating the actual operating state of equipment. The system includes: Edge nodes deployed locally in each subsystem are connected to the simulation model within the subsystem. They are used to collect the running data of the simulation model, perform local simulation control, detect local anomalies and perform local fault tolerance processing, and report local anomaly information when local fault tolerance processing fails. The regional node, deployed in the region, communicates with each of the edge nodes in its region and is used to coordinate the interaction between the subsystems in its region, receive the local anomaly information reported by the edge nodes, and report the local anomaly information to the central node when it cannot handle the local anomaly information. A central node deployed in the central control center communicates with each of the aforementioned regional nodes and is used to periodically send clock synchronization messages to each of the aforementioned regional nodes. This enables each regional node to perform clock synchronization calibration on each of the aforementioned edge nodes within its region based on the clock synchronization messages. The edge nodes then execute local simulation control according to the calibrated clock step size. Furthermore, the central node triggers a global emergency response plan based on the received local anomaly information.

[0007] In a preferred embodiment, this application can be further configured as follows: the process of coordinating the interaction between subsystems within the region by the regional node includes: identifying the simulation model group that needs to interact based on preset regional coordination rules, allocating communication bandwidth and computing resources within the region to the simulation model group that needs to interact; monitoring the model interaction process in real time, triggering preset resolution rules when data conflicts occur; automatically downgrading the interaction strategy and reporting an interaction warning to the central node when a model response timeout occurs and the non-feedback time exceeds a preset percentage of the simulation step size; collecting the output data after the interaction of each simulation model, integrating it into a regional coordination status report, and uploading the regional coordination status report to the central node.

[0008] In a preferred embodiment, this application can be further configured as follows: the local fault tolerance processing of the edge node includes: when the local anomaly is a single-device local anomaly, switching the data of the backup sensor, or correcting the data fluctuation through a filtering algorithm, and synchronizing the anomaly record and processing result to the regional node for filing after processing; wherein, the single-device local anomaly is when the sensor data deviation of a single device does not exceed a preset threshold; when the local anomaly is a device-level operational anomaly, switching to a simple model and performing at least one of the following local repair operations: restarting the model, switching to a backup computing core, and switching to a backup simulation model.

[0009] In a preferred embodiment, this application can be further configured as follows: the regional node is also used to process the regional cluster-level fault when a regional cluster-level fault is detected, and report to the central node that the fault has been repaired after processing; the central node is also used to trigger a global emergency plan when a global cross-regional severe anomaly is detected, so as to issue an instruction to suspend the simulation of all subsystems and restart the global clock synchronization mechanism; after all regions re-align the simulation step size, an instruction to resume operation is issued to restore the coordinated operation of the entire subsystem; wherein, the global cross-regional severe anomaly includes the global control clock deviation exceeding a preset deviation threshold, or the existence of a synchronization failure warning reported by multiple regions at the same time.

[0010] In a preferred embodiment, this application can be further configured such that: the regional node handles the regional cluster-level fault, including: scheduling the task of the simulation model that failed in the regional cluster-level fault to a backup simulation model in the same region; coordinating other simulation models in the region to resynchronize with the backup simulation model to restore regional collaboration; wherein, the regional cluster-level fault includes the simulation model in the region timeout exceeding a preset single-step time limit, resulting in multiple simulation systems in the region being unable to synchronize.

[0011] In a preferred embodiment, this application can be further configured as follows: during the initialization phase, the central node is also used to issue a global configuration; the regional nodes are also used to configure tasks to the edge nodes according to the global configuration; the edge nodes are also used to load the simulation model and self-check resources, and report the ready status to the central node; after confirming that all subsystems are ready, the central node issues a start command.

[0012] In a preferred embodiment, this application can be further configured such that, during the operation phase, the central node is also used to receive test instructions and decompose the test instructions into timing instructions for each of the edge nodes; wherein, the timing instructions include at least one of the following instruction types: scene start instruction, scene switching instruction, scene parameter adjustment instruction, scene termination instruction, and scene reset instruction; the edge nodes are also used to configure each simulation model according to the timing instructions, so that each simulation model completes the operation of the experimental simulation scene according to the configuration instructions.

[0013] In a preferred embodiment, this application can be further configured such that: during the termination phase, the central node is also used to issue a termination command; the edge nodes are also used to stop the simulation in response to the termination command and save local data; the regional nodes are also used to summarize the data within the region and generate a regional report; and the central node is also used to integrate the regional reports to generate a global report.

[0014] In a preferred embodiment, this application can be further configured such that the global configuration includes a pre-configured scenario-level-permission lookup table, wherein the scenario-level-permission lookup table is used to set the instruction issuance level for multiple preset control scenarios respectively, and the instruction issuance level includes the field level executed by the edge node, the regional level executed by the regional node, and the central level executed by the central node.

[0015] Secondly, a method for operation control of a rail transit digital system is provided, based on the system described in any one of the first aspects. The method includes: edge nodes collecting operation data of the simulation model, performing local simulation control, detecting local anomalies and performing local fault tolerance processing, and reporting local anomaly information when local fault tolerance processing fails; regional nodes coordinating the interaction between subsystems within their respective regions, receiving the local anomaly information reported by the edge nodes, and reporting the local anomaly information to a central node when they cannot process the local anomaly information; the central node periodically sending clock synchronization messages to each of the regional nodes, enabling the regional nodes to perform clock synchronization calibration on each of the edge nodes within their respective regions according to the clock synchronization messages, and the edge nodes performing local simulation control according to the calibrated clock step size; and triggering a global emergency plan based on the received local anomaly information.

[0016] In summary, the system and method provided in this application have the following beneficial technical effects: Edge nodes are deployed locally within subsystems, regional nodes coordinate interactions within their respective regions, and central nodes control the global clock and lead global emergency response, forming a hierarchical distributed control system where local problems are handled locally, regional problems are coordinated regionally, and global problems are centrally decided upon. Interaction data between subsystems within a region does not need to be uploaded to the central node; it is directly forwarded through regional nodes, meeting the real-time requirements of strongly coupled subsystems and achieving efficient collaboration and precise control of multiple subsystems in the rail transit digital system.

[0017] In addition, this application also provides a method that has the aforementioned beneficial technical effects. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the operation control system of a rail transit digital system provided in an embodiment of this application; Figure 2 This is a schematic diagram of a layered architecture for a running control system software provided in an embodiment of this application. Detailed Implementation

[0020] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0021] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the permission and consent of the object, the permission and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the permission and consent of the object.

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Furthermore, the terms "and / or" in this document are merely descriptions of the relationships between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0024] To better understand and explain the solutions of the embodiments of this application, some technical terms involved in the embodiments of this application will be briefly explained below.

[0025] A rail transit digital system refers to a system that utilizes technologies such as digital twins, the Internet of Things, real-time communication, and edge computing to transform the physical world's train equipment, track facilities, and operational status into digital models and data streams, thereby supporting the visualized monitoring and precise control of the entire system. A rail transit digital system includes multiple subsystems, such as the power supply system, traction subsystem, pantograph-catenary subsystem, and braking subsystem.

[0026] Multi-subsystem coupling refers to a system in which the various parts are not isolated but closely connected. For example, fluctuations in traction load can affect the grid current, thereby changing the pantograph-catenary electrical operating state.

[0027] Microsecond (μs) level real-time performance refers to a microsecond-level response speed, meaning that the delay in control commands and data processing must be controlled at the microsecond level to meet the real-time control requirements of high-speed rail transit.

[0028] A simulation model is a digital model deployed in various subsystems to simulate the actual operating state of equipment. Examples of its carriers include multi-core simulators for power supply systems, hardware-in-the-loop platforms for traction systems, and pantograph-catenary models. The simulator is the core hardware of the edge nodes.

[0029] Simulation step size refers to the time base used by the simulation model to perform a single step of calculation. For example, the simulation step size can be adjusted from 1 millisecond to 2 milliseconds.

[0030] Communication latency refers to the time overhead of transmitting data or instructions between the device interface layer and the subsystem hardware / emulator. Specifically, it includes: transmission latency from the subsystem hardware to the device interface layer; and the latency of issuing control commands / parameter configurations from the device interface layer to the subsystem hardware. If the communication latency exceeds a preset duration, it is considered asynchronous, which may lead to simulation distortion.

[0031] Global configuration refers to the unified operating baseline parameters for the entire system issued by the central node, including but not limited to static configuration items such as global clock synchronization cycle, simulation step size, security level adaptation rules, and cross-regional resource allocation threshold. It is mainly issued during the initialization phase and can be adjusted as needed during operation.

[0032] Control flow refers to a dynamic sequence of instructions executed in order of priority. It includes the instruction target subsystem, instruction type, specific content, security level, and execution timing. It is the action chain that transforms configuration rules into actual operations, such as emergency braking fault injection, pantograph-catenary arc parameter adjustment, and simulation step size adjustment.

[0033] Safety Integrity Level (SIL) refers to the level of operational safety integrity classified according to functional safety standards. For example, operations directly related to driving safety, such as emergency braking, correspond to SIL4, cross-regional power supply coordination operations correspond to SIL3, and simulation efficiency optimization operations correspond to SIL2.

[0034] Edge nodes, regional nodes, and central nodes correspond to the physical carriers of the three levels of control: field level, regional level, and central level, respectively. Edge nodes are deployed locally in the subsystem, corresponding to the field level; regional nodes are deployed on the regional server, corresponding to the regional level; and central nodes are deployed on the central control center server, corresponding to the central level.

[0035] To better understand the solution provided in the embodiments of this application, the solution will be described below in conjunction with a specific application scenario.

[0036] In one embodiment, please refer to Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of an operation control system for a rail transit digital system, provided in an embodiment of this application. The operation control system can be applied to a rail transit digital system comprising multiple subsystems distributed by region. Each subsystem includes a simulation model for simulating the actual operating state of equipment. The operation control software adopts a distributed deployment architecture of central nodes, regional nodes, and edge nodes.

[0037] Edge nodes are deployed locally in subsystems, such as embedded controllers in power supply simulators and traction hardware platforms, directly processing local data such as inter-core communication in the power supply system and input / output (IO) interface interaction in the traction system; regional nodes are deployed on regional servers to coordinate the interaction of edge nodes in their respective regions, such as regional collaboration between power supply and pantograph-catenary systems; and central nodes are deployed on the central control server to integrate data from all regional nodes and provide a global view and decision support.

[0038] In some embodiments, the subsystem includes, but is not limited to, a multi-core simulator for an electronic system such as a power supply system, a semi-physical interface device for a traction subsystem such as a traction system, a traction semi-physical platform, a pantograph-catenary subsystem such as a pantograph-catenary model, and a braking subsystem such as a braking semi-physical platform. It is understood that the above is merely an example, and this embodiment is not intended to be limiting.

[0039] The core of this application's embodiments lies in the four-dimensional collaborative design of layering, grading, distribution, and step-by-step processes. With decoupling without disconnection as the core logic, the four-dimensional design of vertical layering, horizontal grading, physical distribution, and step-by-step processes simultaneously solves the problems of complexity, physical dispersion, and collaborative orderliness in rail transit digital systems.

[0040] Please refer to Figure 2 The operation control software is structured in four layers from low to high according to data flow and functional responsibilities: device interface layer, real-time control layer, collaborative scheduling layer, and application decision layer. Each layer focuses on a specific task and achieves vertical integration through standardized interfaces to avoid functional overlap. Edge nodes run the functions of the device interface layer and real-time control layer; regional nodes run at least the regional-level functions of the collaborative scheduling layer; and central nodes run the global functions of the collaborative scheduling layer and the functions of the application decision layer.

[0041] The device interface layer (the lowest layer, directly facing the subsystems) serves as the physical interface between the software and various subsystems, such as the power supply simulator, the traction hardware platform, and the pantograph-catenary model, and is responsible for data transmission and reception and protocol conversion. Specifically, dedicated driver modules represent interface drivers developed for the hardware characteristics of different subsystems, such as the reflective memory interface driver for the multi-core power supply simulator and the MVB (Multifunction Vehicle Bus) bus interface for the traction hardware platform. Private protocols refer to the communication formats specific to each subsystem, such as a custom communication format for a particular simulator. General protocols refer to the data format uniformly adopted by the system, such as a standardized data format based on Protobuf (Protocol Buffers).

[0042] Specifically, the device interface layer develops dedicated driver modules for the hardware characteristics of different subsystems to achieve microsecond-level data acquisition, such as real-time voltage / current values ​​of the power supply system, motor speed of the traction system, and command issuance, such as simulation step size adjustment and model parameter updates. The acquired raw data is preprocessed, including filtering and format conversion, converting the subsystem's private protocols into a system-wide protocol for upper-layer use. For example, a control flow can contain three core instructions: Instruction 1: Emergency braking fault injection, target subsystem is the traction semi-physical platform, instruction type is fault injection, specific content is a sudden 90% pressure drop in the braking system, safety level SIL4, priority 1 (highest priority); Instruction 2: Pantograph-catenary arc parameter adjustment, target subsystem is the pantograph-catenary model, instruction type is parameter adjustment, specific content is adjusting the arc discharge intensity from 0.5 to 1.2, safety level SIL3, priority 2; Instruction 3: Simulation step size adjustment, target subsystem is the power supply simulator, instruction type is simulation configuration, specific content is adjusting the step size from 1 millisecond to 2 milliseconds, safety level SIL2, priority 3. The scheduling layer executes commands in this priority order: Command 1, which is directly related to driving safety and requires the fastest response, is executed first; Command 2, which affects the stability of the power supply system, follows closely behind; and Command 3, which only involves simulation efficiency optimization and does not involve real-time safety, is executed last. This design ensures the realism of the simulation in critical scenarios while effectively avoiding command delays caused by resource contention.

[0043] The reasons for the priority of instructions mainly include four aspects: First, the physical limitations of hardware resources. The communication bandwidth, CPU computing power, and interface transmission capabilities of the simulation system are limited. When multiple instructions are issued simultaneously, the hardware cannot process them in absolute parallelism. Priority must be used to ensure that critical instructions occupy resources first. Second, the differences in the real-time performance and safety levels of instructions. Different instructions have completely different response time requirements and safety impacts. Instructions such as fault injection and emergency braking require microsecond-level responses. Delays can lead to simulation distortion or safety risks, while instructions such as parameter adjustment and step size optimization can tolerate millisecond-level delays without affecting core safety. Third, some instructions have execution order requirements. For example, subsystem initialization instructions must be completed before parameter adjustment instructions can be issued. Priority can ensure the correct execution of dependency chains. Fourth, the dynamic changes in the simulation scenario. When a sudden fault occurs in the simulation, such as a short circuit in the traction system, fault-related instructions need to interrupt normal parameter adjustment instructions and be executed first to ensure the realism and safety of the simulation.

[0044] The real-time control layer (middle layer, handling dynamic responses) is the core execution layer of distributed control, based on data from the device interface layer, enabling real-time control and status monitoring at the subsystem level. Real-time control algorithms are simulation algorithms embedded in each subsystem and matched to its dynamic characteristics, such as power flow calculation models for power supply systems and proportional-integral-derivative (PID) speed regulation algorithms for traction systems. Subsystem status evaluation models are evaluation models used for real-time monitoring of key subsystem operating indicators, such as whether the simulation step size has timed out or whether communication delays have exceeded set values.

[0045] Specifically, the real-time control layer obtains data from the subsystems through the device interface layer, inputs this data into the corresponding control algorithm (simulation algorithm), and outputs simulation results. Simultaneously, it obtains simulation data during the simulation process, such as step size and communication delay. For the dynamic characteristics of a single subsystem, such as the calculation of 30 substation sections in the power supply system or the inverter control of the traction system, single-step simulation control is completed within 50 microseconds, such as adjusting the power supply power based on the pantograph-catenary contact force. If the simulation data exceeds the set value, local fault tolerance is assessed, and actions such as increasing the step size, switching models, or switching to a backup core are taken based on the abnormal situation. If an anomaly occurs, such as a timeout in the calculation of a substation model in the power supply system, a local fault tolerance mechanism is immediately triggered, such as switching to a backup core or temporarily increasing the step size, to avoid affecting the overall system. It should be noted that, regarding the priority mechanism, the application decision layer sets instructions and priorities, while the coordination scheduling layer arranges the order and issues instructions. Priority is the strategy output of the decision layer. The scheduling layer is the intermediate link in executing the scheduling and does not actively set priorities; it only follows rules, such as SIL4 safety instructions > SIL3 > SIL2 fault injection > parameter adjustment > simulation configuration execution ordering and issuance.

[0046] The collaborative scheduling layer (intermediate layer, coordinating multi-system interactions) breaks down subsystem boundaries, enabling cross-domain coordination of strongly coupled systems such as power supply, pantograph-catenary, and traction. It serves as the connecting layer between hierarchical control and step-by-step processes. Time-triggered synchronization refers to a periodic synchronization mechanism based on the global clock of the central control system, such as sending a synchronization pulse every 10 milliseconds; event-triggered synchronization refers to a non-periodic synchronization mechanism based on specific events, such as synchronization triggered by offline events in the power supply system.

[0047] Specifically, the collaborative scheduling layer coordinates the simulation rhythm of each subsystem based on the global clock of the central control system. It achieves multi-system step size alignment through time-triggered periodic synchronization and event-triggered aperiodic synchronization, such as strict synchronization of the simulation steps of the power supply system and the traction system, to avoid data misalignment. The periodic synchronization process is as follows: when a preset period is reached, a synchronization pulse is sent to the device interface layer, which then sends it to the subsystem. The subsystem synchronizes its time upon receiving the synchronization signal. When simulation is required, the application decision layer issues a control flow. The collaborative scheduling layer breaks down the control flow into independent simulation instructions corresponding to each subsystem. These instructions include the simulation start time. Since the time is synchronized, the simulation times of each subsystem are the same, achieving synchronized simulation. The application decision layer only generates a complete control flow, containing multiple instructions, start times, priorities, etc. The collaborative scheduling layer is responsible for breaking down the control flow, combining it with the synchronization pulse, and uniformly scheduling and issuing it according to the simulation start time. The global functions of the collaborative scheduling layer, deployed at the central node, are responsible for coordinating the collaboration of the entire system. Specifically, this includes global clock synchronization and system-wide step size control, global orchestration and issuance of cross-regional collaborative instructions, global resource scheduling and cross-regional resource allocation, and global collaborative status monitoring and anomaly coordination, enabling unified collaboration, synchronous execution, and global controllability of multi-regional subsystems. The regional functions of the collaborative scheduling layer, deployed at regional nodes, specifically include clock synchronization and calibration within the region, dynamic allocation of resources at edge nodes, establishment of interactive channels and conflict handling, and issuance and execution of regional collaborative instruction sequences, responsible for coordinating the efficient collaboration of subsystems within the region.

[0048] Application Decision Layer (top layer, user-facing and global strategy-oriented). Based on data from the real-time control layer and the collaborative scheduling layer, the application decision layer provides a global view and decision support, and is the highest layer of hierarchical management. High-level decision algorithms refer to decision support algorithms embedded in the application decision layer, including multi-system collaborative simulation scenario generation and fault contingency plan simulation. Step-by-step control processes refer to the business execution sequence automatically generated by the application decision layer based on user input, organized step-by-step. For example, for an emergency braking scenario of a test train, it automatically generates the following steps: first, triggering the braking command; second, the power supply system cutting off the traction voltage; and third, the pantograph-catenary system recording the offline status.

[0049] Specifically, the application decision layer constructs the data sources required for the entire system's digital twin visualization platform, integrating the real-time status of each subsystem, such as the power supply network topology and traction motor operating curves. It supports the visualization system in displaying the overall operational status to users through graphical interfaces, such as 3D track scenes and subsystem status dashboards. Subsystem data obtained from the interface layer is not only transmitted to the control layer for monitoring but also sent to the decision layer for display. Subsystem status monitored by the control layer and command priority results from the scheduling layer are also sent to the decision layer for display. The application decision layer automatically generates step-by-step control flows based on user input and distributes them to each subsystem through the collaborative scheduling layer. It should be noted that the step-by-step control flow is the business sequence defined by the application decision layer, while simulation step size alignment ensures the synchronous execution of each simulation model by the simulator subsystem. The former is high-level scenario planning, and the latter is low-level real-time assurance. The two are layered and collaborative, indispensable, jointly ensuring the sequential, synchronous, and accurate execution of complex simulation scenarios.

[0050] Please continue to refer to this. Figure 1 The operation and control software adopts a distributed deployment architecture of central nodes, regional nodes, and edge nodes. The central node corresponds to the central level, regional nodes to the regional level, and edge nodes to the field level. Edge nodes are deployed locally within subsystems, such as embedded controllers in power supply simulators and traction hardware-in-the-loop platforms, running device interface and real-time control layer functions, directly processing local data, with a response time of no more than 50 microseconds. Regional nodes are deployed on regional servers, running regional-level functions of the collaborative scheduling layer, coordinating the interaction of edge nodes within their region, with a response time of no more than 1 millisecond. The central node is deployed on the central control center server, running the global functions of the collaborative scheduling layer and the application decision layer, integrating data from all regional nodes, providing a global view and decision support, with a response time of no more than 10 milliseconds. Through this deployment, when digital model machines within a subsystem region interact, data does not need to be uploaded to the central node; it is directly forwarded through regional nodes. The communication latency is reduced from tens of milliseconds between the central and edge levels to microseconds between edge-to-edge levels within a region, meeting the real-time requirements of strongly coupled systems.

[0051] Edge nodes collect simulation model runtime data, execute local simulation control, detect local anomalies and perform local fault tolerance processing, and report local anomaly information when local fault tolerance processing fails.

[0052] In this context, edge nodes refer to field-level control nodes deployed locally within each subsystem, such as embedded controllers in power supply simulators and traction hardware-in-the-loop platforms. Their carriers are the simulator itself—the model runner, real-time calculator, and core hardware of the physical linkage bridge. Operational data refers to dynamic and high-frequency data generated during the simulation model's operation, including physical state data, simulation state data, and command interaction data. Local simulation control refers to the single-step simulation control executed by the edge node's real-time control layer based on data collected from the device interface layer and according to the simulation algorithm. Local anomalies represent abnormal conditions occurring locally within the subsystem that can be detected by the edge node itself, such as local anomalies of a single device or device-level operational anomalies. Local fault tolerance processing refers to the actions taken by the edge node to eliminate the impact of anomalies within its local scope.

[0053] In this embodiment of the application, after the system completes initialization and receives the start command, it executes periodically according to the simulation step size. Specifically, edge nodes acquire simulation model operation data with microsecond-level precision through dedicated driver modules in their device interface layer, such as reflective memory interface drivers and MVB bus interfaces. This includes real-time voltage / current values ​​of the power supply system and motor speed of the traction system. After preprocessing the raw data, such as filtering and format conversion, and completing protocol conversion, the data is input into the real-time control algorithm embedded in the real-time control layer, such as the power flow calculation model of the power supply system and the PID speed adjustment algorithm of the traction system. Single-step simulation control is completed within 50 microseconds, such as adjusting the power supply power according to the pantograph-catenary contact force. At the same time, the real-time control layer monitors whether the simulation step size has exceeded the time limit and whether the communication delay has exceeded the set value based on the subsystem state evaluation model. (Communication delay refers to the time overhead of data / instructions transmitted between the device interface layer and the subsystem hardware / simulation machine, including uplink transmission delay, downlink transmission delay, and the total time spent on bus transmission, driver processing, and protocol parsing. Once an anomaly occurs, a local fault tolerance mechanism is triggered, such as switching to a backup core or temporarily increasing the step size. When local fault tolerance processing fails, the edge node reports the local anomaly information to the regional node.)

[0054] In some embodiments, the device interface layer of the edge node loads a dedicated driver module that matches the hardware characteristics of the subsystem, such as a reflective memory interface driver; periodically reads sensor data and status feedback data from the shared memory area or bus buffer of the subsystem hardware according to the simulation step size; performs filtering and format conversion on the collected raw data, and converts the subsystem private protocol into a general protocol based on Protobuf before handing it over to the real-time control layer for processing.

[0055] Regional nodes coordinate the interactions between subsystems within their respective regions, receive local anomaly information reported by edge nodes, and report local anomaly information to the central node when they are unable to process it.

[0056] In this context, a regional node refers to a regional-level control node deployed on a regional server. It communicates with all edge nodes within its region and manages geographically or functionally related subsystems, such as the two simulators and two sets of semi-physical equipment in a traction system. Interaction between subsystems within the region refers to the data exchange and collaborative computation between the simulation models of these subsystems due to strong physical coupling. Local anomaly information refers to anomaly records reported by edge nodes, such as fault type, location, and local fault tolerance processing results.

[0057] Specifically, regional nodes operate regional-level functions of the collaborative scheduling layer, receiving synchronization instructions from the central node and real-time data from edge nodes. Based on regional collaborative rules, they identify simulation model groups that need to interact, allocate communication bandwidth and computing resources to the model groups, and establish temporary interaction channels to achieve direct data transmission between edge nodes without going through the central node, reducing communication latency within the region to the microsecond level. For local anomaly information reported by edge nodes, regional nodes assess the severity of the anomaly and coordinate its handling within their own authority. If they cannot handle it, they report the local anomaly information to the central node.

[0058] In some embodiments, the regional node identifies the simulation model group that needs to interact based on preset regional collaboration rules; establishes a temporary interaction channel within the region for the model group and allocates communication bandwidth and computing resources; and monitors the interaction process in real time and summarizes the interaction output data.

[0059] By coordinating the collaborative interaction of tightly coupled subsystems at the regional level, the data exchange between subsystems within the region does not need to be relayed through the central node. The communication latency is reduced from tens of milliseconds to microseconds. Furthermore, the regional nodes, acting as an intermediate layer, filter out most local anomalies and only report unprocessable anomalies to the central node. This reduces the processing burden on the central node and improves the efficiency and orderliness of collaboration.

[0060] The central node periodically sends clock synchronization messages to each regional node, enabling the regional nodes to perform clock synchronization calibration on each edge node within their respective regions based on the clock synchronization messages. The edge nodes then execute local simulation control according to the calibrated clock step size and trigger a global emergency plan based on the received local anomaly information.

[0061] Here, the central node refers to the central-level control node deployed on the central control center server, which communicates with each regional node. Clock synchronization messages represent high-precision global synchronization pulses periodically sent by the central node, such as clock synchronization signals based on PTP (Precision Time Protocol, such as the IEEE 1588 protocol). Clock synchronization calibration represents the process by which regional nodes align the local clocks of all edge nodes within their region with the global clock. The global emergency response plan represents the emergency response strategies triggered by the central node in response to severe anomalies affecting the entire system, such as suspending all subsystem simulations, restarting the global clock synchronization mechanism, and reconstructing the digital system.

[0062] Specifically, the central node periodically sends synchronization messages to the edge nodes (forwarded by the regional nodes) through its collaborative scheduling layer. The edge nodes receive the synchronization messages through the device interface layer. After receiving the high-precision global synchronization pulse from the central node, the regional nodes enter the regional clock calibration process: the regional nodes capture the timestamp of the synchronization pulse sent by the central node through a high-precision hardware timer, such as the core clock of a Field Programmable Gate Array (FPGA) or a general-purpose timer of an ARM Cortex-A53 core; based on historical measurement data, the local clock drift curves of all edge nodes (digital model machines) in the region are fitted using a linear regression algorithm; the clock deviation value of each node is calculated, and the local counter is phase-adjusted and frequency-trimmed according to the frequency deviation coefficient of the node's hardware crystal oscillator, so that the clocks of all nodes in the region are completely synchronized with the global clock within a microsecond-level time window. After the clock calibration is completed, the edge nodes execute local simulation control according to the calibrated clock step size, and each subsystem advances at the same simulation moment, achieving multi-system step size alignment. When the central node receives local anomaly information reported by a regional node and determines it to be a serious cross-regional anomaly, it triggers the global emergency response plan.

[0063] The combination of time-triggered synchronization and event-triggered synchronization at the central node ensures strict alignment of simulation steps for strongly coupled subsystems such as power supply, traction, and pantograph-catenary systems. This avoids secondary processing delays caused by data misalignment and provides an accurate timing basis for centralized decision-making on global anomalies, thereby achieving the core objectives of microsecond-level synchronization, cross-system collaboration, and fault tolerance.

[0064] In one possible implementation of this application embodiment, in order to solve the problem of lack of unified coordination and easy occurrence of data conflicts and response timeouts in the interaction of multiple strongly coupled subsystems within a region, the process of coordinating the interaction between subsystems within the region by a regional node in this application embodiment includes three stages: identifying the simulation model group that needs to interact based on preset regional coordination rules and allocating resources; monitoring the interaction process in real time and performing conflict resolution and timeout degradation; and collecting and integrating the interaction output for reporting. The details are as follows: Step S210: Based on the preset regional collaboration rules, identify the simulation model groups that need to interact, and allocate communication bandwidth and computing resources within the region to the simulation model groups that need to interact. Among them, regional coordination rules refer to pre-defined coordination rules based on the functional requirements of interaction among edge nodes, such as the linkage priority rules for power supply-traction-pantograph-catenary systems. Simulation model groups requiring interaction represent a set of cross-subsystem models with strong physical coupling, whose simulation solution process relies on real-time data transmission between them. Examples include a model group consisting of traction dynamics, pantograph-catenary electrical contact, and power supply network power flow models. Traction load fluctuations affect grid current, thus changing the pantograph-catenary electrical operating state; continuous interaction among the three is necessary. Independently operating, non-real-time coupled data statistics and environmental parameter auxiliary models do not belong to the model groups requiring real-time interactive scheduling. Communication bandwidth and computing resources represent the adjustable link bandwidth within the region, such as bandwidth utilization and link latency, and computing resources, such as CPU load and memory usage of each server. Key models refer to models corresponding to key subsystems of rail transit equipment, such as traction system dynamics models, power supply network power flow solution models, pantograph-catenary electrical contact simulation models, and train braking dynamics models.

[0065] Specifically, the regional node collaborative scheduling layer receives real-time collected data uploaded by each edge node via the device interface layer. After unifying the data interface protocol and completing clock calibration, it identifies the model groups that need to interact based on preset regional collaborative rules and issues interaction trigger commands to the target model machine. It allocates regional communication bandwidth and computing resources for model interaction, prioritizes the interaction priority of key models, and establishes temporary interaction channels to avoid network congestion caused by concurrent interaction of multiple models. The regional node also establishes a resource scheduling pool: for high-priority tasks, such as multi-subsystem collaboration in fault injection scenarios, it prioritizes the allocation of idle computing power and dedicated communication links; when regional resources are scarce, it initiates resource compression strategies, such as suspending the real-time transmission of non-critical data and merging computation requests for low-priority tasks; it supports resource mutual assistance between edge nodes, such as scheduling idle simulators in the same region to share some of the solution tasks when a simulator's computing power is insufficient.

[0066] Regional nodes can accurately identify model groups that truly require real-time interaction, avoid unnecessary scheduling of independent models, and ensure the bandwidth and computing power for key model interactions through temporary interaction channels and resource scheduling pools, thereby reducing communication latency, avoiding network congestion, and improving the real-time performance and relevance of regional collaboration.

[0067] Step S220: Monitor the model interaction process in real time. When a data conflict occurs, trigger the preset resolution rules. When the model response times out and the time without feedback exceeds the preset percentage of the simulation step size, automatically downgrade the interaction strategy and report the interaction warning to the central node.

[0068] Data conflict refers to inconsistent interactions, such as multiple subsystems simultaneously modifying the same parameter. Resolution rules represent pre-defined conflict handling principles, such as prioritizing real-time edge data or core parameters (i.e., using real-time data collected by edge nodes as the standard) or initiating a weighted fusion algorithm for fusion. Model response timeout indicates that the participating model failed to provide feedback on interaction data within the expected time; the preset percentage represents a pre-defined timeout judgment ratio relative to the simulation step size (e.g., 50%). Degraded interaction strategy represents a strategy to reduce non-critical interactions while maintaining core interactions, such as transmitting only core fields or suspending non-critical data interactions. Interaction warning represents anomaly alerts reported by regional nodes to the central node.

[0069] Specifically, regional nodes monitor the model interaction process in real time. If data conflicts occur, such as when the same parameter is modified by two subsystems simultaneously, preset resolution rules are triggered based on the principle of prioritizing edge real-time data and core parameters. This could be done by using real-time data collected by edge nodes or by activating a weighted fusion algorithm. If a model response times out, such as when more than 50% of the step size is not responded to, the interaction strategy is automatically downgraded, such as transmitting only core fields, suspending non-critical data interaction, and reporting an interaction warning to the central node. In addition, regional nodes also record scheduling process data within the region, such as resource allocation records, interaction delay statistics, and conflict handling results, generating regional scheduling status reports that are synchronized to the regional decision-making level in real time. In case of abnormal situations, such as scheduling failures or persistent resource shortages, reports are submitted to the central node according to permissions, supporting global scheduling optimization.

[0070] Data conflicts can be resolved in a timely manner, preventing the spread and contamination of erroneous data between subsystems. Response timeouts can be automatically downgraded to avoid prolonged blocking of interaction links. Furthermore, interactive early warnings provide front-end sentinel information for the central node's global monitoring, thereby improving the robustness of regional collaboration.

[0071] Step S230: Collect the output data after the interaction of each simulation model, integrate it into a regional collaborative status report, and upload the regional collaborative status report to the central node.

[0072] The output data represents the collaborative computing results and status assessment reports generated after the interaction of each model machine. The regional collaborative status report is a comprehensive report reflecting the regional collaborative operation status, generated by the regional nodes in accordance with the format required by the central node.

[0073] Specifically, regional nodes collect the output data from interactions between various model machines, such as collaborative calculation results and status assessment reports, and integrate them into a regional collaborative status report. Following the format required by the central node, the report, along with any unresolved interaction anomalies (if any), is uploaded to the central node to support global status monitoring. For example, after a train emergency braking command is issued, the traction system outputs the braking force curve, the power supply system cuts off the traction power, and the pantograph-catenary model calculates the offline arc. The collaborative calculation results include the cumulative energy value of the pantograph-catenary arc during the entire braking process and the transient disturbance waveform of the power grid. Regional nodes collect these cross-model collaborative calculation results, integrate them into the regional collaborative status report, and upload them to the central node for global monitoring, fault review, and test data storage.

[0074] The central node can grasp the collaborative status of each region without directly connecting to a massive number of edge nodes, providing a high-quality data foundation for global decision-making, fault review, and experimental data storage, thereby improving the orderliness of the entire system's management and control.

[0075] In one implementation, in addition to the aforementioned coordination and interaction functions, the regional node also possesses the following functions to support the complete capability of regional-level cluster collaborative control: The regional-level real-time control algorithm is executed for multi-subsystem collaborative scenarios within the region, such as power matching of the power supply-pantograph-catenary cluster and timing linkage of the traction-braking cluster. It embeds region-specific control algorithms, such as cluster load balancing algorithms and cross-subsystem parameter coupling correction models, and completes regional-level collaborative control calculations within 1 millisecond. For example, it dynamically adjusts the output power distribution strategy of the power supply simulator within the region based on the real-time value of the pantograph-catenary contact force.

[0076] Regional Status Aggregation Assessment: Summarize the subsystem status data of all edge nodes in the region, such as the calculation time of each simulator, communication link stability, and core parameter deviation, to build a regional global status assessment model and monitor the regional health in real time. If more than or equal to 3 edge nodes time out, it is judged as a regional anomaly, avoiding the mis-triggering of a global response by a single node anomaly.

[0077] Regional fault tolerance mechanism triggering: When local repair of an edge node fails, such as ineffective backup core switching or cross-node association anomalies, such as communication interruption between a traction simulator and its corresponding power supply simulator, the regional fault tolerance strategy is immediately triggered: ① Temporarily disconnect the interaction link between the abnormal node and other nodes in the region to avoid data contamination; ② Call up regional backup resources, such as regional shared simulators, to take over the core tasks of the abnormal node; ③ Adjust the regional coordination rules, such as temporarily reducing the simulation accuracy of non-critical subsystems to prioritize the smooth operation of core links.

[0078] Optimized control command distribution: Receive control commands from the central node or regional decision-making layer, and combine them with the real-time status of the region, such as the current computing load and communication latency, to adapt and optimize the commands. For example, convert the global step size adjustment command into a differentiated execution command adapted to the hardware characteristics of different subsystems in the region, and distribute it to the edge nodes through a standardized interface to ensure the accuracy and efficiency of command execution.

[0079] Precise clock synchronization within the region: Receives global synchronization pulses from the central node and uses a local clock calibration algorithm, such as high-precision synchronization based on the PTP protocol, to control the clock deviation of all edge nodes and shared devices within the region to within 1 microsecond, ensuring strict alignment of subsystem steps within the region, such as complete synchronization of the simulation cycle between the power supply simulator and the traction semi-physical platform.

[0080] Dynamic scheduling of regional resources: Real-time monitoring of computing resources within the region, such as CPU load and memory usage of each server, and communication resources, such as bandwidth utilization and link latency, to establish a resource scheduling pool and perform dynamic scheduling.

[0081] Subsystem interaction scheduling within the region: According to the requirements of the real-time operation stage in the step-by-step process, refine the subsystem interaction logic within the region: Identify the subsystem groups that need to interact based on the preset regional collaboration rules and generate an interaction time sequence table; establish temporary interaction channels within the region to realize direct data transmission between edge nodes (without going through the central node) to reduce communication latency; monitor the interaction process and trigger conflict resolution according to the principle of prioritizing edge real-time data and core parameters.

[0082] Scheduling status feedback and reporting: Record scheduling process data within the region, such as resource allocation records, interaction delay statistics, and conflict handling results, generate a regional scheduling status report, synchronize it to the regional decision-making level in real time, and report abnormal situations to the central node according to permissions to support global scheduling optimization.

[0083] Regional operation mode adaptation decision-making: Based on the global operation strategy issued by the central node, such as fault simulation mode or normal operation mode, and combined with the subsystem status within the region, such as equipment health and task type, specific operation parameters within the region are determined. For example: when the global mode is fault simulation, the priority order and scope of fault injection within the region are determined, such as injecting faults only into the traction-braking subsystem cluster without affecting the power supply-pantograph cluster; when the global mode is high-efficiency operation, the optimization scheme for resource allocation within the region is determined, such as increasing the computing power ratio of the core subsystem.

[0084] Local decision-making for scene switching in the region: Upon receiving scene switching instructions from the central node, such as switching from normal operating conditions to emergency braking conditions, decide on the specific execution plan for scene switching within the region: ① Determine the switching order of subsystems within the region, such as switching the braking subsystem first, and then simultaneously switching the power supply and traction subsystems; ② Set switching buffer parameters, such as switching transition time and data inheritance rules, to avoid subsystem state disorder caused by scene switching; ③ Decide on the timing of activating backup scenarios within the region, such as immediately activating the preset backup scenarios within the region when the main scene switching fails, to ensure operational continuity.

[0085] Regional anomaly handling decision-making: Receive anomaly information reported by edge nodes or the regional control layer, assess the severity of the anomaly (e.g., minor local anomalies, regionally related anomalies, or severe anomalies affecting the entire region); decide on the handling method: minor anomalies trigger local fault tolerance at the regional control layer; related anomalies initiate regional collaborative repair, such as scheduling multiple nodes to jointly investigate the cause of the fault; severe anomalies are reported to the central node and a global emergency response is recommended; decide on the anomaly recovery plan, such as the restart sequence of subsystems within the region and the data recovery strategy after anomaly repair.

[0086] Regional operation optimization decisions: Based on long-term operational data within the region, such as control delay statistics, fault tolerance success rate, and resource utilization, regional operation optimization suggestions are generated. For example: when the interaction latency of a certain type of subsystem remains high, the decision is made to adjust the interaction rules, such as optimizing the data transmission format and adjusting the interaction timing; when a certain type of fault occurs frequently, the decision is made to increase the configuration of backup resources within the region, such as adding a backup simulator, and to report to the central node to suggest optimizing the global architecture.

[0087] The control scope of a regional node is a geographically or functionally related subsystem, such as two simulators and two sets of semi-physical equipment in a traction system. It has cluster coordination rights and can schedule resources within the subsystem area, such as assigning the task of a traction simulator to a backup device in the same area. It can handle anomalies in the subsystem area and report to the central level if it cannot resolve the issue.

[0088] As can be seen, in this embodiment, the regional node can accurately identify the strongly coupled simulation model group that needs to interact based on the regional collaboration rules and prioritize the allocation of communication bandwidth and computing resources to it. By real-time monitoring, it can resolve data conflicts in a timely manner and automatically downgrade the interaction strategy when the response times out, thus avoiding the spread of data misalignment and network congestion to the whole system. The regional collaboration status report provides the basis for global status monitoring for the central node, ensuring the real-time performance, consistency and controllability of cross-subsystem interaction.

[0089] In one possible implementation of this application embodiment, in order to solve the problem that if local anomalies in a subsystem are reported and processed indiscriminately, it will lead to a lengthy response chain and affect the overall operation, the local fault tolerance processing of edge nodes in this application embodiment includes two types of processing branches for different anomaly levels, as follows: Step S310: When the local anomaly is a single device local anomaly, switch the data of the backup sensor, or correct the data fluctuation through a filtering algorithm, and synchronize the anomaly record and processing result to the regional node for filing after the processing is completed; wherein, a single device local anomaly is when the sensor data deviation of a single device does not exceed the preset threshold.

[0090] In this context, "single-device local anomaly" refers to a minor anomaly affecting only a single device and not impacting the overall system. The criterion is that the sensor data of the single device shows a deviation, but this deviation does not exceed a preset threshold. For example, fluctuations in the speed sensor data of a traction semi-physical platform (±5% deviation, not exceeding the threshold). The preset threshold can be customized by the user, as long as it achieves the purpose of this application. "Backup sensor" refers to redundantly configured sensor channels for the same measurand; "filtering algorithm" refers to the signal processing algorithm used to correct data fluctuations, such as moving average filtering or Kalman filtering; and "record" refers to the process of synchronizing anomaly records and processing results to regional nodes for archiving and future reference, without requiring further action.

[0091] This step is executed when a local anomaly in a single device is detected by the subsystem state assessment model at the real-time control layer of the edge node. Specifically, after the field level (edge ​​node, real-time control layer) detects an anomaly in sensor data, it directly triggers local fault tolerance: switching to backup sensor data or correcting fluctuations through filtering algorithms; after processing, only the anomaly record and processing results are synchronized to the regional level for record-keeping, without needing to report to the central level, and without affecting other subsystems.

[0092] In some embodiments, the edge node compares the readings of the primary sensor and the backup sensor in real time and calculates the percentage deviation. If the deviation does not exceed a preset threshold, such as ±5%, it is determined to be a local anomaly in a single device. The node seamlessly switches to the backup sensor data channel and packages the anomaly record and the switching result to the regional node for record-keeping. The edge node performs sliding window filtering on the sensor data sequence to extract data fluctuation characteristics. After determining that the fluctuation is a random fluctuation that does not exceed a preset threshold, a filtering algorithm, such as Kalman filtering, is used to correct the data fluctuation. The edge node continuously monitors the quality of the corrected data, and after it returns to normal, it generates an anomaly record and processing result and synchronizes it to the regional node for record-keeping.

[0093] Local anomalies in a single device can be resolved quickly without going through regional or central processing links, ensuring data quality without interfering with the normal operation of other subsystems, thereby reducing the overall system processing overhead and response latency.

[0094] Step S320: When the local anomaly is a device-level operational anomaly, switch to running a simple model and perform at least one of the following local repair operations: restart the model, switch to a standby computing core, or switch to a standby simulation model.

[0095] Among them, "device-level operational anomaly" represents an anomaly situation involving the operation of a device, which is more severe than a local anomaly of a single device. "Simple model" represents a reduced-order model with lower accuracy or scale than the original model, but which can maintain the continuity of the core simulation. "Local repair operation" represents repair actions that edge nodes can perform within their local permissions, including at least one of restarting the model, switching to a backup computing core, or switching to a backup simulation model.

[0096] Specifically, edge nodes first switch to running a simple model to ensure simulation continuity, and then attempt local repair, such as restarting the model, switching to a backup core, or switching to a backup simulator. If the local repair is successful, normal model operation is restored; if it fails, the local anomaly information is reported to the regional node.

[0097] In some embodiments, when an edge node detects a model solution timeout or abnormal output, it determines it as a device-level operational anomaly; it immediately loads a pre-set simple model to take over the current solution task, maintaining the continuity of external output; it performs a model restart operation in the background, and after restarting, it switches back to the original model and compares the state consistency. If an edge node detects a continuous timeout in the solution of a certain computing core, it marks that core as a faulty core; it dynamically migrates the solution task to a backup computing core (in a multi-core simulator scenario) or a backup simulation model on the same node; after migration, it verifies the simulation state before and after migration, such as step size and key parameters. If the verification passes, it restores full-function operation; if the verification fails, it reports to the regional node. It is understood that other methods can also be used to achieve local fault tolerance for device-level operational anomalies, which are not limited here.

[0098] Edge nodes can maintain simulation continuity even under device-level anomalies, avoiding global shutdowns caused by simulation interruptions, and can quickly recover through various local repair methods, thus achieving a balance between fault tolerance and real-time performance.

[0099] It should be noted that adjusting the step size and restarting the model are specific fault-tolerance measures of the subsystem state assessment model for local anomalies in a single system. These are local fault-tolerance mechanisms of the real-time control layer and are consistent with the logic of handling local problems at the field level in hierarchical control, without any conflict.

[0100] As can be seen, in the embodiments of this application, edge nodes adopt differentiated local fault tolerance measures for local anomalies of different severity: minor fluctuations in sensor data are directly resolved locally and only reported to the regional level without affecting other subsystems; device-level operational anomalies are resolved by switching to a simple model to ensure simulation continuity and are quickly restored by various local repair operations, thereby avoiding the spread of local anomalies into global risks.

[0101] In one possible implementation of this application embodiment, the regional node is further configured to process the regional cluster-level fault when a regional cluster-level fault is detected, and report to the central node that the fault has been repaired after the processing is completed. The central node is also used to trigger a global emergency plan when a severe cross-regional anomaly is detected, so as to issue an instruction to suspend the simulation of all subsystems and restart the global clock synchronization mechanism; after all regions realign the simulation step size, it issues a resumption instruction to restore the coordinated operation of all subsystems; among them, severe cross-regional anomalies include the global control clock deviation exceeding a preset deviation threshold, or the existence of synchronization failure warnings reported simultaneously by multiple regions, as detailed below: When a regional node detects a regional cluster-level fault, it handles the fault and reports to the central node that the fault has been repaired after the handling is completed.

[0102] Among them, regional cluster-level faults refer to faults that affect multiple simulation systems in the region but do not cross regions. Typical scenarios include simulation model calculations within the region exceeding the preset single-step time limit, such as a traction system simulator timeout exceeding the 50-microsecond single-step time limit, causing multiple simulation systems within the region to fail to synchronize; it also includes edge node local repair failures or cross-node association anomalies, such as a traction simulator and its corresponding power supply simulator experiencing communication interruptions.

[0103] This step is executed when a regional node detects a regional cluster-level fault through the regional state aggregation assessment model. Specifically, the regional node (the collaborative scheduling layer running on the regional node) schedules resources within its region to handle the regional cluster-level fault. After handling, it reports to the central level that the fault has been repaired, requiring no central-level intervention and not affecting other areas such as power supply and pantograph-catenary systems. Specific fault-tolerance strategies for handling regional cluster-level faults by regional nodes include: temporarily severing the interaction links between the abnormal node and other nodes within the region to avoid data contamination; calling upon regional backup resources (such as a regional shared simulator) to take over the core tasks of the abnormal node; and adjusting regional collaborative rules, such as temporarily reducing the simulation accuracy of non-critical subsystems to prioritize ensuring the smooth operation of core links.

[0104] Regional cluster-level failures can be quickly recovered without central-level intervention, avoiding the mis-triggering of a global response by a single node malfunction. At the same time, the central level is kept informed of the global status through reporting, thus achieving the hierarchical control goal of handling local problems locally.

[0105] When the central node detects a severe cross-regional anomaly, it triggers a global emergency plan to issue an instruction to suspend the simulation of all subsystems and restart the global clock synchronization mechanism. After all regions re-align the simulation step size, it issues a resumption instruction to restore the coordinated operation of all subsystems.

[0106] The "Global Cross-Regional Severe Anomaly" refers to a serious anomaly affecting the synchronization and operational safety of the entire system. This includes situations where the global control clock deviation exceeds a preset deviation threshold (e.g., greater than 1 millisecond, causing the simulation step sizes of all traction, power supply, and pantograph-catenary systems to be out of sync), or multiple regions simultaneously reporting synchronization failure warnings. The "Global Emergency Plan" represents an emergency response process led by the central government, including suspending all subsystem simulations, restarting the global clock synchronization mechanism, and, if necessary, reconstructing the digital system. The preset deviation threshold can be customized by the user; this application's embodiments do not limit it, as long as it achieves the purpose of this application.

[0107] Taking the global clock deviation exceeding the preset deviation threshold as an example, the processing flow is as follows: multiple regional levels simultaneously report synchronization failure warnings; the central level (central node, application decision-making layer) determines it as a global anomaly and triggers the global emergency plan; an instruction is issued: suspend all subsystem simulations and restart the global clock synchronization mechanism; after all regions re-align their step sizes, the central level issues a resumption command, and the entire system restarts collaboratively; the central level takes the lead throughout the process, while regional and field levels only execute commands to ensure global consistency. Furthermore, in the event of local repair failure at edge nodes, local anomaly information reported by regional nodes can also trigger a global emergency by the central node, such as suspending the entire system or reconstructing the digital system.

[0108] Global cross-regional severe anomalies are handled and resolved by a central node with global decision-making authority, avoiding global inconsistencies that may arise from each region handling the situation independently, thus ensuring the safety and orderly recovery of the entire system under severe failures.

[0109] As can be seen, in this embodiment of the application, a hierarchical response gradient is formed, which includes local repair of edge nodes, coordinated handling of regional nodes, and global emergency response of central nodes: regional cluster-level faults are resolved on their own within the region and only need to be reported to the central level, avoiding the mis-triggering of global response by a single node anomaly; global cross-regional severe anomalies are uniformly led by the central level for emergency handling and recovery, ensuring global consistency and achieving fault tolerance and risk isolation.

[0110] In one possible implementation of this application embodiment, in order to solve the problem of how to seamlessly take over the simulation tasks after a simulator in a region fails and how to quickly restore regional collaboration, in this application embodiment, the regional node handles the regional cluster-level failure, including: scheduling the tasks of the simulation model that failed in the regional cluster-level failure to a backup simulation model in the same region; coordinating other simulation models in the region to resynchronize with the backup simulation model to restore regional collaboration; wherein, the regional cluster-level failure includes the simulation model in the region timeout exceeding the preset single-step time limit, resulting in multiple simulation systems in the region being unable to synchronize.

[0111] Backup simulation models refer to redundant simulation resources pre-set within the same region that can take over fault model tasks, such as regional shared simulators and backup traction simulators.

[0112] This step is executed after a regional cluster-level fault has failed to be repaired locally. Specifically, taking a typical scenario as an example: one simulator in the traction system times out (exceeding the 50-microsecond single-step time limit), causing the two simulation systems in the region to become unsynchronized, which is a regional cluster-level fault. The field-level (faulty simulator) first attempts local repair (restarting the model, switching to a backup core), and if it fails, reports to the regional level. The regional level (regional nodes, collaborative scheduling layer) schedules resources within the region: assigning the faulty simulator's tasks to a backup traction simulator in the same region; coordinating with other subsystems in the region, such as the pantograph-catenary model, to resynchronize with the new simulator and restore regional collaboration; after processing, it reports to the central level that the fault has been repaired, requiring no central-level intervention and not affecting power supply, pantograph-catenary systems, or other areas.

[0113] In some embodiments, after receiving a local repair failure report from an edge node, a regional node selects a backup simulation model with matching computing power and interface from the regional resource scheduling pool; migrates the model file, parameter set, and current simulation state (such as step size and accumulated state variables) of the failed simulation model to the backup simulation model and initiates takeover; broadcasts a synchronization and reconstruction message to other simulation models within the region, realigns the step size according to the clock reference of the backup simulation model, and restores regional collaborative interaction. It is understood that other methods can also be used to implement task scheduling and resynchronization, which are not limited here.

[0114] In this embodiment, the task of the fault simulation model can be taken over by the backup resource without interrupting the overall operation of the region. Other simulation models in the region can resume collaboration after resynchronization, thereby improving the fault tolerance and operational continuity of the system without affecting other regions.

[0115] In one possible implementation of this application embodiment, during the initialization phase, the central node, regional nodes, and edge nodes execute according to the following ordered process: The central node issues a global configuration; regional nodes configure tasks to edge nodes according to the global configuration; edge nodes load the simulation model and self-check resources, and report their readiness status to the central node; after confirming that all subsystems are ready, the central node issues a start command.

[0116] The global configuration refers to the unified system-wide operating baseline parameters and rule set issued by the central node (including static configuration items such as global clock synchronization cycle, simulation step size, security level adaptation rules, cross-regional resource allocation thresholds, and rule sets such as scene-level-permission lookup tables). Self-check resources represent the pre-startup verification of available resources by edge nodes, such as whether the number of cores is sufficient and whether interfaces are functioning correctly. Ready status represents the availability confirmation information fed back by edge nodes after completing model loading and resource self-checks.

[0117] The initialization phase includes the following steps: the central decision-making layer generates a global configuration, such as the simulation scenario and step size; the central coordination and scheduling layer distributes the configuration to regional nodes; the regional scheduling layer determines priority rules and synchronizes them to edge nodes; the control layer of the edge nodes loads the model and performs self-checks, such as whether the number of cores is sufficient and whether the interfaces are normal; the edge nodes report readiness to the central node's scheduling layer via the regional nodes; the central node's decision-making layer confirms this and issues a start command; the regional scheduling layer forwards the command; and the edge interface layer receives and starts the simulation. Because the global configuration defines the control flow, a dynamic instruction execution sequence ordered by priority, includes the instruction target subsystem, type, specific content, safety level, and execution timing. For example, the aforementioned three instruction control flows for emergency braking fault injection, pantograph-catenary arc parameter adjustment, and simulation step size adjustment allow edge nodes to execute simulations according to a unified benchmark after startup.

[0118] In one possible implementation of this application embodiment, during the operation phase, the central node receives test instructions and decomposes the automated test instructions into timing instructions for each edge node; the edge nodes configure each simulation model according to the timing instructions, so that each simulation model completes the operation of the test simulation scenario according to the configuration instructions.

[0119] Among them, test instructions refer to automated control instructions for experimental simulation scenarios, which are received and decomposed by the central node. Timing instructions refer to instructions formed by the central node after decomposing the test instructions, carrying execution timing requirements, and sent to each edge node. The instruction types include at least one of the following: scenario start instruction, scenario switching instruction, scenario parameter adjustment instruction, scenario termination instruction, and scenario reset instruction.

[0120] Specifically, after receiving automated test commands, the central node decomposes them into timing commands for each edge node. Each edge node configures its simulator according to the timing commands via interface configuration software. Each simulator then runs the test simulation scenario according to the configuration commands. The applicable scenarios and core components of various timing commands are as follows: (1) Scenario start command, used to start a brand new experimental simulation scenario, such as a train entering the station scenario. Its core components include: command ID, scenario identifier, scenario parameter set (including but not limited to simulation duration, step size setting, core simulation index threshold), and start timing requirements, such as unified start at T=0 and batch start according to node priority. It should be noted that the simulation synchronous start is relative to the same simulation subsystem. At this time, the step size of the simulators in the same system needs to be aligned, while the start time of different subsystems can be arranged according to the physical timing.

[0121] (2) Scene switching instruction, used to switch from the current running scene to the target scene, such as switching from the normal working condition scene to the fault injection scene. Its core components include: instruction ID, original scene identifier, target scene identifier, switching mode (seamless switching / interrupted switching), transition parameters, such as switching buffer duration, data inheritance rules: whether to retain the original scene running status data.

[0122] (3) Scene parameter adjustment command, used to modify the core parameters of the test scene during operation, such as adjusting the environmental interference intensity and coordination rules of the pantograph-catenary system. Its core components include: command ID, adjustment object (target edge node group / single edge node), parameter items, such as adjusting the fault injection probability to 15%, and adjustment timing (immediate effect / next long effect).

[0123] (4) Scenario termination command, used to stop the current test scenario and release resources. Its core components include: command ID, termination mode (normal termination / emergency termination), data processing requirements, such as saving scenario operation logs and uploading core simulation results, and termination confirmation threshold, such as confirming scenario termination after more than 90% of edge nodes have completed feedback.

[0124] (5) Scene reset command, used to restore all simulators to the initial state after the current scene is terminated, such as parameter zeroing or state reset. Its core components include: command ID, reset range (full scene reset / specified node reset), and initial state baseline, such as restoring to the configuration before scene startup or restoring to the original configuration.

[0125] In some embodiments, the central node parses the scenario definition and execution requirements in the automated test instructions, and splits them into sub-instructions for each edge node according to the subsystem boundary; based on the priority rules in the control flow (SIL4 safety instructions > SIL3 > SIL2, fault injection > parameter adjustment > simulation configuration) and timing requirements, it arranges the issuance order and start time of each sub-instruction; and issues them to each edge node in a unified manner according to the simulation start time and the synchronization pulse, and the edge nodes execute them after configuring each simulator through the interface configuration software.

[0126] In this embodiment, the central node only needs to receive test instructions from higher levels to automatically complete instruction decomposition and timing arrangement. The edge nodes can quickly configure each simulator through interface configuration software without manual reconstruction of the control flow, thereby significantly improving the system's adaptability and scalability to diverse test scenarios.

[0127] In one possible implementation of this application embodiment, during the termination phase, the central node is further configured to issue a termination command; the edge nodes are further configured to stop the simulation in response to the termination command and save local data; the regional nodes are further configured to summarize the data within the region and generate a regional report; and the central node is further configured to integrate the regional reports to generate a global report.

[0128] The term "end command" refers to the global stop command issued by the central node at the end of the experiment or upon receiving a stop request. "Local data" refers to the simulation process data generated locally by the edge nodes, such as simulation logs and key curves. "Regional report" refers to the report generated by the regional nodes by summarizing the data from their respective regions. "Global report" refers to the system-wide report generated by the central node by integrating all regional reports.

[0129] Specifically, the process for the end phase includes the central node issuing an end command; the edge nodes stopping the simulation, saving local data such as simulation logs and key curves, and reporting the data summary to the regional nodes within the time limit; the regional nodes summarizing the regional data and generating a regional report; and the central node integrating all data, generating a global report, and releasing computing and communication resources.

[0130] In this embodiment, the experimental data is aggregated in three levels—edge storage, regional aggregation, and central integration—to form a complete global report, ensuring the integrity and traceability of the data. At the same time, computing power and communication resources are released in an orderly manner, providing a clean resource environment for the initialization of the next experiment.

[0131] In one possible implementation of this application embodiment, the global configuration includes: a pre-configured scenario-level-permission lookup table. The scenario-level-permission lookup table is used to set the instruction issuance level for multiple preset control scenarios. The instruction issuance level includes the field level executed by the edge node, the regional level executed by the regional node, and the central level executed by the central node.

[0132] The scenario-level-permission lookup table represents the set of rules pre-configured in the control logic of the central node and regional nodes in the form of a scenario-level-permission table. The instruction issuance level indicates the subject level of instruction issuance for each control scenario, including the field level executed by edge nodes, the regional level executed by regional nodes, and the central level executed by the central node. The field level's control scope is a single simulator or subsystem, such as a power supply simulator or a traction semi-physical platform. It has the operational execution rights of the subsystem and can independently complete local control, such as adjusting its own simulation step size or restarting the model. It does not need to report to the central level and only handles minor anomalies that do not affect the overall system, such as fluctuations in sensor data. The processing results are synchronized to the regional level for record-keeping. The regional level's control scope is geographically or functionally related subsystems, such as two simulators or two sets of semi-physical equipment in the traction system. It has cluster coordination rights, can schedule resources within the subsystem area, and can handle anomalies within the subsystem area. If it cannot resolve the issue, it reports to the central level. The central-level control scope covers the entire digital system, possesses global decision-making authority, formulates system-wide strategies such as simulation scenario configuration and clock synchronization rules, approves major operations that cannot be handled at the regional level, such as cross-regional subsystem linkage, can handle serious anomalies affecting the whole system, and triggers global emergency plans, such as suspending all subsystems and restarting the synchronization mechanism.

[0133] Specifically, the preset command issuance levels follow these core principles: ① Scope of impact principle: Operations involving only a subsystem within a single region are issued by the regional level; operations involving two or more regions, or affecting the entire system, are issued by the central level. ② Safety level principle: Operations at safety level SIL4, such as emergency braking and cross-regional fault linkage, and SIL3, such as cross-regional power supply coordination, are approved and issued by the central level; operations at SIL2 and below, such as resource scheduling and local parameter adjustments within a region, are issued autonomously by the regional level. ③ Resource permission principle: Operations requiring the use of cross-regional resources, such as the simulator in region A providing computing power support to the subsystem in region B, or modifying global configuration parameters, such as system-wide clock synchronization and global simulation step size, are issued by the central level; operations only requiring the use of resources within the local region are issued by the regional level. ④ Preset rule format: The command issuance levels for all scenarios are pre-configured in the control logic of the central node and regional nodes in the form of a scenario-level-permission lookup table, supporting dynamic updates (requiring central level approval) to avoid operational confusion.

[0134] In this embodiment, the instruction issuing entities for each control scenario are pre-fixed, local operations do not require central approval, and global strategies are uniformly and centrally decided. This avoids both the efficiency loss caused by redundant permissions and the security risks caused by control vacuum, thereby achieving the orderliness and consistency of the entire system control.

[0135] In one possible implementation of this application embodiment, an operation control method for a rail transit digital system is also provided, which is implemented based on the aforementioned system. The method includes: Step S1010: The edge node collects the running data of the simulation model, performs local simulation control, detects local anomalies and performs local fault tolerance processing, and reports local anomaly information when local fault tolerance processing fails. Step S1020: The regional node coordinates the interaction between the subsystems within its region, receives local anomaly information reported by the edge nodes, and reports the local anomaly information to the central node when it cannot handle the local anomaly information. In step S1030, the central node periodically sends clock synchronization messages to each regional node, enabling the regional nodes to perform clock synchronization calibration on each edge node within their respective regions based on the clock synchronization messages. The edge nodes then execute local simulation control according to the calibrated clock step size and trigger a global emergency plan based on the received local anomaly information.

[0136] Based on any of the above embodiments, in this embodiment, taking the test simulation of a train emergency braking scenario as an example, it includes: (1) Initialization phase: The central decision-making layer generates a global configuration, including the global clock synchronization cycle, simulation step size, SIL adaptation rules, and scenario-level-permission comparison table, which is then distributed to the regional nodes through the central coordination and scheduling layer; the regional scheduling layer determines the priority rules and synchronizes them to the edge nodes; the edge control layer loads simulation models such as traction, power supply, and pantograph-catenary and performs self-checks on resources (number of cores, interfaces), and feeds back the readiness status to the central node through the regional nodes; the central node issues a start command after confirming that all subsystems are ready.

[0137] (2) Scenario Generation: The user inputs the emergency braking scenario of the test train at the application decision layer; the high-level decision algorithm embedded in the application decision layer automatically generates a step-by-step control flow: Step 1: Trigger the braking command; Step 2: The power supply system cuts off the traction voltage; Step 3: The pantograph-catenary system records the offline status and issues it through the collaborative scheduling layer. The control flow contains commands ordered by priority, such as the SIL4 level emergency braking fault injection command taking precedence over the SIL3 level pantograph-catenary arc parameter adjustment command and the SIL2 level simulation step size adjustment command.

[0138] (3) Synchronous operation: The central node is timed, such as sending a synchronization pulse every 10 milliseconds; the regional nodes capture the synchronization pulse timestamp through the FPGA hardware high-precision timer, fit the clock drift curve of each edge node based on linear regression, calculate the clock deviation value ΔT and perform phase adjustment and frequency fine-tuning to control the clock deviation of the regional nodes within 1 microsecond; the edge nodes execute local simulation control according to the calibrated clock step size, and each subsystem advances at the same simulation time.

[0139] (4) Regional coordination: The traction system outputs the braking force curve, the power supply system cuts off the traction power supply, and the pantograph-catenary model calculates the offline arc; the regional nodes collect the above cross-model coordination calculation results, such as the cumulative value of pantograph-catenary arc energy during the entire braking process and the transient disturbance waveform of the power grid, and integrate them into a regional coordination status report and upload it to the central node.

[0140] (5) Abnormal response: If a speed sensor experiences a ±5% data fluctuation during the simulation (single device local abnormality), the edge node switches to backup sensor data or performs filtering correction and only reports to the regional node; if a traction simulator timeout exceeds 50 microseconds single-step time limit (regional cluster-level fault), after the edge node fails to repair locally, the regional node schedules its task to the backup traction simulator in the same region and coordinates resynchronization. After completion, it reports to the central node that the fault has been repaired; if the global clock deviation exceeds 1 millisecond (global cross-regional severe abnormality), multiple regions simultaneously report synchronization failure warnings. The central node issues an instruction to suspend the simulation of all subsystems and restarts the global clock synchronization mechanism. After all regions realign their step sizes, it issues an instruction to resume operation.

[0141] (6) End phase: The central node issues an end command; the edge nodes stop the simulation and save the simulation log and key curves; the regional nodes summarize the regional data and generate regional reports; the central node integrates the regional reports to generate a global report and releases computing power and communication resources.

[0142] In summary, the embodiments of this application can achieve the following effects: First, microsecond-level real-time performance is guaranteed: the response link is shortened by layered decomposition and distributed deployment, and the execution efficiency is optimized by combining dedicated drivers and real-time algorithms; the layered architecture decouples functions vertically to avoid processing delays caused by functional overlap; the dedicated driver of the device interface layer realizes microsecond-level data transmission and reception, and the real-time control layer algorithm completes single-step control within 50 microseconds; the distributed deployment adopts the edge node proximity processing mode, and the interaction between subsystems in the region does not need to go through the central node, reducing the communication latency from tens of milliseconds to the microsecond level; the collaborative scheduling layer ensures the step size alignment of multiple systems through time-triggered and event-triggered synchronization mechanisms, avoiding secondary processing delays caused by data misalignment.

[0143] Secondly, it achieves high efficiency in cross-system collaboration: by establishing clear collaboration rules through layered integration and hierarchical coordination, it achieves decoupling without disconnection; the equipment interface layer converts private protocols into general protocols to solve the data interaction compatibility problem of subsystems; the collaborative scheduling layer breaks down subsystem boundaries, unifies the global clock and synchronization rules, and ensures the dynamic linkage of strongly coupled systems such as power supply, pantograph-catenary, and traction; hierarchical control divides permissions according to field-region-central, with local collaboration handled by regional nodes and global collaboration coordinated by the central node, avoiding inefficiency caused by chaotic collaboration permissions.

[0144] Third, it has strong fault tolerance capabilities: through hierarchical response and local fault tolerance mechanisms, it can handle local problems locally and centrally manage global problems; the real-time control layer embeds a subsystem state assessment model, which can monitor anomalies such as simulation step timeout and communication delay and trigger local fault tolerance mechanisms to prevent the spread of local anomalies; the hierarchical response process clearly defines the gradient strategy of local repair of edge nodes, coordinated handling of regional nodes, and global emergency response of central nodes; under distributed deployment, edge nodes operate independently, and the failure of a single node does not affect other regional subsystems, thereby improving the overall anti-interference capability of the system.

[0145] Fourth, it boasts high scalability and flexibility: it reduces adaptation costs through layered modularization and distributed deployment; each layer in the layered architecture has clear functional boundaries, and adding a new subsystem only requires developing a dedicated driver for the device interface layer, without modifying the upper-layer control logic; edge nodes and regional nodes can be added or removed as needed to adapt to the dynamic adjustment of the physical distribution of the subsystems; during the scenario switching phase, the central node can receive automated test instructions to quickly configure each simulator, supporting flexible switching of multiple test scenarios without refactoring the control flow.

[0146] Fifth, it features strong orderly control: orderly control throughout the entire lifecycle is achieved through step-by-step processes and hierarchical permissions; the step-by-step processes divide the operation into five stages: initialization, real-time operation, exception handling, scene switching, and termination, with clear input, output, and collaboration rules for each stage; hierarchical control divides the scope and permissions of control according to the field, region, and central level to avoid overlapping permissions or missing control; the application decision layer provides a global visual view and decision support, allowing users to clearly grasp the overall system operation status, and the control instructions are issued in an orderly manner through a layered architecture to ensure the accurate execution of control instructions.

[0147] This application's embodiments clarify the vertical responsibilities of data, control, and decision-making through hierarchical layering, classify horizontal permissions at the field, regional, and central levels, distribute and adapt to the physical dispersion of subsystems, and ensure orderly collaboration throughout the entire lifecycle through step-by-step processes. Ultimately, it achieves the core objectives of microsecond-level synchronization, cross-system collaboration, and fault tolerance in the rail transit digital system. This architecture not only meets the real-time interaction requirements of strongly coupled systems such as power supply and traction, but also enhances the system's flexibility and scalability through decoupling design, providing reliable control support for the digital-physical fusion verification of rail transit transport equipment.

[0148] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0149] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An operation control system for a rail transit digital system, the rail transit digital system comprising multiple subsystems distributed by region, each subsystem comprising a simulation model for simulating the actual operating state of equipment, characterized in that, include: Edge nodes deployed locally in each subsystem are connected to the simulation model within the subsystem. They are used to collect the running data of the simulation model, perform local simulation control, detect local anomalies and perform local fault tolerance processing, and report local anomaly information when local fault tolerance processing fails. The regional node, deployed in the region, communicates with each of the edge nodes in its region and is used to coordinate the interaction between the subsystems in its region, receive the local anomaly information reported by the edge nodes, and report the local anomaly information to the central node when it cannot handle the local anomaly information. A central node deployed in the central control center communicates with each of the aforementioned regional nodes and is used to periodically send clock synchronization messages to each of the aforementioned regional nodes. This enables each regional node to perform clock synchronization calibration on each of the aforementioned edge nodes within its region based on the clock synchronization messages. The edge nodes then execute local simulation control according to the calibrated clock step size. Furthermore, the central node triggers a global emergency response plan based on the received local anomaly information.

2. The system according to claim 1, characterized in that, The process by which a regional node coordinates the interactions between subsystems within its region includes: Based on preset regional collaboration rules, identify simulation model groups that need to interact, and allocate communication bandwidth and computing resources within the region to the simulation model groups that need to interact. The model interaction process is monitored in real time. When a data conflict occurs, a preset resolution rule is triggered. When the model response times out and the time without feedback exceeds a preset percentage of the simulation step size, the interaction strategy is automatically downgraded and an interaction warning is reported to the central node. The output data after the interaction of each simulation model is collected, integrated into a regional collaborative status report, and then uploaded to the central node.

3. The system according to claim 1, characterized in that, The local fault tolerance process of the edge nodes includes: When the local anomaly is a single-device local anomaly, the data from the backup sensor is switched, or the data fluctuation is corrected by a filtering algorithm, and the anomaly record and processing result are synchronized to the regional node for filing after the processing is completed; wherein, the single-device local anomaly is when the sensor data deviation of a single device does not exceed a preset threshold. When the local anomaly is a device-level operational anomaly, switch to running a simple model and perform at least one of the following local repair operations: restart the model, switch to a standby computing core, or switch to a standby simulation model.

4. The system according to claim 1, characterized in that, The regional node is also used to process the regional cluster-level fault when it is detected, and to report to the central node that the fault has been repaired after the processing is completed. The central node is also used to trigger a global emergency plan when a severe cross-regional anomaly is detected, so as to issue an instruction to suspend the simulation of all subsystems and restart the global clock synchronization mechanism; after all regions re-align the simulation step size, an instruction to resume operation is issued to restore the coordinated operation of all subsystems; wherein, the severe cross-regional anomaly includes the global control clock deviation exceeding a preset deviation threshold, or a synchronization failure warning reported by multiple regions at the same time.

5. The system according to claim 4, characterized in that, The regional node handles the regional cluster-level fault, including: scheduling the task of the simulation model that failed in the regional cluster-level fault to a backup simulation model in the same region; and coordinating other simulation models in the region to resynchronize with the backup simulation model to restore regional collaboration. Among them, the regional cluster-level fault includes the simulation model solving timeout exceeding the preset single-step time limit within the region, resulting in multiple simulation systems within the region being unable to synchronize.

6. The system according to claim 1, characterized in that, During the initialization phase, the central node is also used to issue global configurations; the regional nodes are also used to configure tasks to the edge nodes according to the global configurations; the edge nodes are also used to load simulation models and self-check resources, and report the ready status to the central node; after confirming that all subsystems are ready, the central node issues a start command.

7. The system according to claim 6, characterized in that, During the operation phase, the central node is also used to receive test instructions and decompose the test instructions into timing instructions for each of the edge nodes; wherein, the timing instructions include at least one of the following instruction types: scene start instruction, scene switching instruction, scene parameter adjustment instruction, scene termination instruction, and scene reset instruction; the edge nodes are also used to configure each simulation model according to the timing instructions, so that each simulation model completes the operation of the experimental simulation scene according to the configuration instructions.

8. The system according to claim 7, characterized in that, In the final stage, the central node is also used to issue a termination command; the edge nodes are also used to stop the simulation in response to the termination command and save local data; the regional nodes are also used to summarize the data within the region and generate a regional report; the central node is also used to integrate the regional reports to generate a global report.

9. The system according to claim 6, characterized in that, The global configuration includes a pre-configured scenario-level-permission lookup table. The scenario-level-permission lookup table is used to set the instruction issuance level for multiple preset control scenarios. The instruction issuance level includes the field level executed by the edge node, the regional level executed by the regional node, and the central level executed by the central node.

10. A method for operation control of a digital rail transit system, characterized in that, Based on the system according to any one of claims 1 to 9, the method comprises: Edge nodes collect the running data of the simulation model, perform local simulation control, detect local anomalies and perform local fault tolerance processing, and report local anomaly information when local fault tolerance processing fails. The regional node coordinates the interaction between the subsystems within its region, receives the local anomaly information reported by the edge node, and reports the local anomaly information to the central node when it cannot process the local anomaly information. The central node periodically sends clock synchronization messages to each of the regional nodes, enabling each regional node to perform clock synchronization calibration on each of the edge nodes within its region based on the clock synchronization messages. The edge nodes then execute local simulation control according to the calibrated clock step size and trigger a global emergency plan based on the received local anomaly information.

Images