Subway door and shielding door linkage fault root cause analysis method and equipment

Abstract

The invention relates to the technical field of electrical digital data processing, in particular to a metro door and shielding door linkage fault root cause analysis method and equipment, and the metro door and shielding door linkage fault root cause analysis method comprises the steps: taking a door control system and a shielding door control system as objects; constructing a cross-professional equipment topology model based on the signal interaction path, the power supply chain and the control logic node; determining target equipment related to the target fault; and obtaining fault process backtracking data, carrying out association analysis on the signal abnormal node and the equipment state abnormity, and outputting a fault root cause of a cross-professional combination part. According to the scheme, the cross-professional equipment topology model is constructed and the multi-source operation data is integrated, so that information islands among professional systems are broken, global data sharing and unified analysis of a vehicle door-shielding door linkage scene are realized, and the completeness and accuracy of troubleshooting are improved.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and more specifically, to a method and equipment for root cause analysis of linkage faults between subway car doors and platform screen doors. Background Technology

[0002] In rail transit operations, the synchronized operation of subway car doors and platform screen doors is a crucial link in ensuring passenger safety and train efficiency. This linkage process involves multiple professional systems, including vehicle, signaling, power supply, and electromechanical systems: the car door controller is responsible for issuing open / close commands; the signaling system forwards commands through train stop detection, communication buses, and other links; the power supply system provides a stable power supply to the door and platform screen door drive mechanisms; and the electromechanical system's platform screen door controller ultimately executes the open / close action. These systems exchange information via PLCs, relays, or Ethernet. An anomaly in any link can cause the car doors and platform screen doors to fail to operate synchronously, leading to train delays, passenger congestion, or even safety accidents.

[0003] Currently, the diagnostic systems of various specialties are independent of each other, forming "data silos". There is a lack of unified cross-disciplinary data fusion and linkage analysis methods, which leads to fault diagnosis mainly relying on manual experience, which is inefficient and makes it difficult to accurately locate the root cause at the cross-disciplinary junction. Summary of the Invention

[0004] The purpose of this invention is to provide a method and equipment for analyzing the root cause of linkage failures between subway car doors and platform screen doors, in order to solve the above-mentioned technical problems.

[0005] In a first aspect, embodiments of the present invention provide a method for root cause analysis of linkage faults between subway car doors and platform screen doors, the method comprising:

[0006] Taking the vehicle door control system and platform screen door control system as examples, a cross-disciplinary equipment topology model is constructed based on the signal interaction path, power supply chain and control logic node.

[0007] Real-time acquisition of multi-source operational data from various professional departments, followed by standardized processing and mapping to the cross-professional equipment topology model, to identify target equipment related to the target fault; wherein, the target fault is a linkage fault between subway car doors and platform screen doors;

[0008] The historical operating data of the target device is compared with a preset signal interaction rule base to dynamically simulate the linkage process between the vehicle door and the platform screen door, and obtain fault process backtracking data.

[0009] Based on the fault process backtracking data, correlation analysis is performed on the signal abnormality nodes and equipment status abnormalities to output the root cause of the fault at the cross-disciplinary junction; wherein, the cross-disciplinary junction is used to characterize the interactive coupling part between the various professional departments.

[0010] Furthermore, the construction of a cross-disciplinary equipment topology model, based on signal interaction paths, power supply chains, and control logic nodes, using the vehicle door control system and platform screen door control system as examples, includes:

[0011] Collect information on the equipment attributes, physical connections, and control logic of the vehicle door control system and the platform screen door control system;

[0012] The device attributes and physical connection relationships are abstracted using a node-edge data structure, and the control logic information is mapped to control logic node attributes to generate a cross-professional device topology model.

[0013] The consistency of the cross-disciplinary equipment topology model is verified, and redundant nodes and erroneous connections are eliminated.

[0014] Furthermore, the real-time acquisition of multi-source operational data from various professional departments, after standardization processing, and mapping it to the cross-professional equipment topology model includes:

[0015] Access to real-time data streams from various professional departments is achieved through a unified interface protocol.

[0016] The real-time data stream is converted into a standardized data object that includes timestamps, device identifiers, and numerical values.

[0017] Based on the device identifier, the standardized data object is mapped to the corresponding node of the cross-professional device topology model to generate a data-topology association table.

[0018] Furthermore, determining the target device associated with the target fault includes:

[0019] Based on the data-topology association table, an anomaly threshold detection algorithm is used to identify candidate anomaly nodes that match the target fault time window;

[0020] Starting from the candidate abnormal node, reachability analysis is performed along the signal interaction path to determine the target device set.

[0021] Furthermore, the step of comparing the historical operating data of the target device with a preset signal interaction rule base, dynamically simulating the linkage process between the vehicle door and the platform screen door, and obtaining fault process retrospective data includes:

[0022] A vehicle door-platform screen door linkage state machine is constructed based on a preset signal interaction rule base; wherein, the vehicle door-platform screen door linkage state machine includes at least one normal state and multiple abnormal transition conditions;

[0023] The historical operating data of the target equipment is input into the door-platform screen door linkage state machine in chronological order, and the door-platform screen door linkage state machine is driven to run to obtain the fault evolution trajectory.

[0024] Record state transition events in the fault evolution trajectory as fault process backtracking data.

[0025] Furthermore, the step of comparing the historical operating data of the target device with a preset signal interaction rule base, dynamically simulating the linkage process between the vehicle door and the platform screen door, and obtaining fault process retrospective data also includes:

[0026] A visualization timeline is generated based on the fault process backtracking data; wherein, the visualization timeline is used to present the signal timing and state changes of each node during the linkage process between the vehicle door and the platform screen door;

[0027] Mark abnormal events on the visualized timeline.

[0028] Furthermore, based on the fault process backtracking data, the correlation analysis between abnormal signal nodes and abnormal equipment status is performed to output the root cause of the fault at the cross-disciplinary junction, including:

[0029] Extract the signal anomaly features and equipment status features from the fault process retrospective data;

[0030] Input the signal anomaly characteristics and the device status characteristics into the correlation analysis model to calculate the correlation degree between the anomaly nodes;

[0031] The candidate root cause list is output based on the correlation degree, and the node with the highest correlation degree is selected as the root cause of the failure at the cross-disciplinary junction.

[0032] Furthermore, the method also includes:

[0033] The identified root causes of the fault are mapped back to the cross-disciplinary equipment topology model, and a diagnostic report containing the fault path and affected equipment is automatically generated.

[0034] The diagnostic report is pushed to each professional maintenance terminal to guide on-site repair work.

[0035] Furthermore, the method also includes:

[0036] When new operational data or rule updates are received, the cross-disciplinary equipment topology model and the signal interaction rule base are incrementally updated.

[0037] Secondly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the root cause analysis method for the linkage failure of subway car doors and platform screen doors as described above.

[0038] According to the specific embodiments provided in this application, the following technical effects are disclosed:

[0039] This application provides a method and device for root cause analysis of subway door and platform screen door linkage faults. It constructs a cross-disciplinary equipment topology model based on the door control system and platform screen door control system, using signal interaction paths, power supply chains, and control logic nodes. Real-time multi-source operational data from various departments is acquired, standardized, and mapped to the cross-disciplinary equipment topology model to identify the target equipment related to the target fault. The target fault is a subway door and platform screen door linkage fault. Historical operational data of the target equipment is compared with a preset signal interaction rule base to dynamically simulate the linkage process between the doors and platform screen doors, obtaining fault process backtracking data. Based on the fault process backtracking data, correlation analysis is performed on abnormal signal nodes and abnormal equipment states, outputting the root cause of the fault at the cross-disciplinary junction. The cross-disciplinary junction characterizes the interactive coupling points between various departments. Compared with existing technologies, this solution, on the one hand, breaks down information silos between various professional systems by constructing a cross-professional equipment topology model and integrating multi-source operational data from vehicles, signals, power supply, and electromechanical systems. This enables global data sharing and unified analysis of the door-platform door linkage scenario, helping to improve the completeness and accuracy of fault diagnosis. On the other hand, by utilizing historical operational data and dynamic simulation driven by a signal interaction rule base, this solution can trace the fault evolution trajectory throughout the entire process, accurately reproducing key nodes such as signal loss, delay, or abnormal equipment status. This transforms traditional experience-based qualitative analysis into traceable and reproducible quantitative analysis, thereby shortening fault location time. Furthermore, based on the correlation analysis model, it automatically outputs the root cause of faults and visualized diagnostic reports at cross-professional junctions, achieving standardized and automated identification and push of fault causes. This reduces the risk of manual coordination and misjudgment, providing clear and actionable guidance for on-site maintenance, thereby improving the safety and reliability of subway operations. Attached Figure Description

[0040] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a schematic diagram of the root cause analysis system for the linkage failure of subway car doors and platform screen doors in one embodiment of this application;

[0042] Figure 2 A flowchart illustrating a method for analyzing the root cause of a subway car door and platform screen door linkage failure according to an embodiment of this application;

[0043] Figure 3This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0044] The technical solutions of the embodiments of this application will be clearly and comprehensively described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0045] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. The following is an explanation of relevant terms:

[0046] Interdisciplinary interface: This refers to the functional coupling area formed between the vehicle door control system and the platform screen door control system across the four disciplines of vehicle, signaling, power supply, and electromechanical engineering. This area includes both physical interfaces (such as relay contacts, power terminals, and communication bus ports) and logical interfaces (such as signal timing and protocol conversion rules). When any discipline experiences an abnormality in the output signal or electrical energy within this area, it may cause the vehicle door and platform screen door to fail to operate according to the predetermined logic.

[0047] Equipment structure topology: An abstract model describing all relevant equipment and their connections in the vehicle door control system and platform screen door control system in a "node-edge" format. Among them:

[0048] Nodes: Corresponding physical devices or logical functional units such as controllers, relays, power modules, and communication interfaces;

[0049] Edge: Corresponds to physical connections such as signal lines, power lines, and communication buses, and records the signal flow direction, power polarity, and communication protocol attributes.

[0050] The topology model can reflect both physical wiring and power supply paths, as well as the attributes of control logic nodes, enabling cross-disciplinary signals, power supplies, and logic information to be uniformly expressed in the same data structure.

[0051] Data backtracking refers to the process of retrieving and reproducing the operational data corresponding to past events in the original time sequence based on timestamp order; its purpose is to fully reproduce the historical state and event evolution in order to reproduce and analyze faults or anomalies.

[0052] Root cause analysis refers to the process of identifying and locating the most fundamental factors causing a malfunction through a systematic approach after confirming its symptoms. Its core lies in distinguishing between direct causes and underlying causes, and outputting interpretable and verifiable root cause conclusions.

[0053] In related technologies, the diagnostic process for door-platform screen door linkage faults is executed separately by each professional system: First, sensors deployed on the doors, platform screen doors, and their control circuits collect discrete data such as switch status, voltage, current, and signal strength. Then, each professional system independently determines whether there are internal faults such as signal loss, relay contact abnormalities, or power fluctuations based on its own preset rule base or threshold model. When the fault phenomenon spans multiple professional systems, manual intervention is required. Technicians log into the diagnostic platforms of each professional system, download log files in heterogeneous formats, and then compare timestamps, protocol fields, and event descriptions based on experience to reach a conclusion. However, the above process has a global flaw: because the data storage formats, communication protocols, and semantic definitions of vehicle, signal, power supply, and electromechanical systems are different, the data exists in an "island" state at both the physical and logical levels, making it impossible to share and integrate within the same spatiotemporal dimension. Therefore, existing methods inherently lack an observation perspective on the cross-professional junctions, i.e., the multi-system interactive coupling area—leading to the root cause of the fault often being misjudged as an internal problem of a single professional system, while the cross-system interference, protocol timing deviations, or power coupling abnormalities that truly trigger the fault are overlooked.

[0054] In view of this, this application provides a method for root cause analysis of subway door and platform screen door linkage faults. Compared with the prior art, on the one hand, this solution breaks down information silos between various professional systems by constructing a cross-professional equipment topology model and integrating multi-source operating data from vehicles, signals, power supply, electromechanical systems, etc., and realizes global data sharing and unified analysis of door-platform screen door linkage scenarios, which helps to improve the completeness and accuracy of fault diagnosis. On the other hand, by using historical operating data and dynamic simulation driven by a signal interaction rule base, this solution can trace back the fault evolution trajectory throughout the entire process and accurately reproduce key nodes such as signal loss, delay, or abnormal equipment status, thereby transforming traditional qualitative analysis that relies on experience into traceable and reproducible quantitative analysis, thus shortening the fault location time. Furthermore, based on the correlation analysis model, it automatically outputs the root cause of faults and visualized diagnostic reports at the cross-professional junctions, realizing standardized and automated identification and push of fault causes, reducing the risk of manual coordination and misjudgment, providing clear and actionable guidance for on-site maintenance, and thus improving the safety and reliability of subway operations.

[0055] The root cause analysis method for the linkage fault of subway doors and platform screen doors provided in this application embodiment can be applied to, for example, Figure 1The aforementioned subway door and platform screen door linkage fault root cause analysis system includes a terminal 110, a server 120, and a data storage system. The terminal 110 communicates with the server 120 via a network. The data storage system stores the data that the server 120 needs to process. The data storage system can be set up independently, integrated into the server 120, or placed in the cloud or on another server. The terminal 110 can send multi-source operational data acquired from various professional departments to the server 120. After receiving the multi-source operational data, the server 120 performs fault root cause analysis to obtain the fault root cause. Furthermore, in some embodiments, the aforementioned subway door and platform screen door linkage fault root cause analysis method can also be implemented independently by the server 120 or the terminal 110.

[0056] Among them, terminal 110 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Server 120 can be implemented using a standalone server or a server cluster composed of multiple servers, or it can be a cloud server.

[0057] In one exemplary embodiment, such as Figure 2 As shown, a root cause analysis method for the linkage failure of subway car doors and platform screen doors is provided. This method is executed by computer equipment, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is applied to... Figure 1 Taking server 120 as an example, the above-mentioned root cause analysis method for the linkage failure of subway doors and platform screen doors mainly includes steps S210 to S240, wherein:

[0058] Step S210: Taking the vehicle door control system and the platform screen door control system as objects, construct a cross-disciplinary equipment topology model based on the signal interaction path, power supply chain and control logic nodes.

[0059] The aforementioned door control system, typically located at the train end, is an electromechanical-electronic integrated system responsible for completing the door opening / closing actions and their safety interlocking. Its main hardware consists of a door controller (EDCU), drive motor, locking mechanism, position sensors, door status indicator lights, and a communication interface. The door controller maintains real-time data exchange with the Train Control and Management System (TCMS) via hardwired connections or the train communication bus (such as MVB, CAN, or Ethernet), receiving commands such as "train has stopped" and "door opening permitted" from the signaling system, and driving the motor to complete the door opening or closing actions according to preset logic. Simultaneously, the position sensors provide real-time feedback on the door panel position, locking status, and obstacle detection information, forming a closed-loop control system. The door control system also integrates redundant safety circuits, which can trigger emergency braking or isolate the door when abnormal opening force, power failure, or communication interruption is detected, ensuring train safety.

[0060] The aforementioned platform screen door control system is installed on the platform side to synchronously respond to train door movements, providing passengers with a closed waiting environment and preventing falls. The system consists of a central interface panel (PSC), a local control panel (PSL), door control units (DCUs), drive motors, door mechanical structures, safety circuits, and communication links. The central interface panel coordinates all door control units using train occupancy information from the signaling system, door opening / closing commands, and emergency signals from the Integrated Backup Panel (IBP). Each door control unit independently controls a set of sliding doors, collecting real-time data on door position, locking, and obstacle detection, and transmitting this data back to the central interface panel via a safety relay circuit or Ethernet. The platform screen door control system and the train door control system interact via hardwired or communication bus through an "interlocking" signal exchange, ensuring that the platform screen doors cannot open if the train is not aligned with the platform or the signal is not open, and vice versa, thus achieving synchronous linkage between the train doors and the platform screen doors.

[0061] The subway car door-platform door linkage refers to a full-process control mechanism in which, after the train has come to a complete stop at the station and all safety interlocking conditions are met, the train door control system and the platform screen door control system coordinate to execute the opening or closing actions according to predetermined signal interaction rules, synchronization sequence, and safety priority. This mechanism uses the train's zero speed and alignment signals as trigger sources, sending authorization commands simultaneously to the onboard door control unit and the platform central interface panel via the signal system. After each system completes its local safety self-check, they exchange "permission to execute" status via hardwire or communication bus. Under the condition of no faults and no passenger or obstacle interference, the train doors and corresponding platform screen doors open or close synchronously within the permitted time window. The mechanism continuously monitors the position, locking, and fault status throughout the entire operation cycle. Any abnormality in any link can trigger a linkage interruption or emergency braking, thereby ensuring passenger safety and operational efficiency. A subway car door-platform door linkage failure refers to the following: when the train has come to a complete stop at the platform and the signaling system has issued a "door opening permission" command, the car door control system and the platform screen door control system fail to complete the coordinated action according to the established interlocking logic and synchronization sequence. This results in an abnormal state in which the train doors and the corresponding platform screen doors "open unilaterally, close unilaterally, neither of them act, or the action sequence exceeds the limit" within the specified allowable time window. This abnormality directly manifests as passengers being unable to board or alight normally or facing the risk of falling into the track area. The root cause may lie in any professional link of the vehicle, signaling, power supply, or electromechanical systems, or in cross-professional interaction paths.

[0062] The aforementioned signal interaction path refers to the end-to-end complete link in the subway door-platform door linkage system that carries and transmits all digital and analog signals, including "train stopping, alignment, door opening / closing authorization, status feedback, and fault alarm." This link comprises three dimensions: physical medium, protocol layer, and logical channel. The physical medium consists of the train communication bus (MVB, CAN, Ethernet), the platform platform door communication bus, safety hardwire loops, and fiber optic / twisted pair cables. The protocol layer covers field or industrial Ethernet protocols such as Modbus, Profibus, CANopen, and TCP / UDP. The logical channel is a time-controlled data stream composed of the train control management system—onboard door controller, signal system—platform central interface panel, central interface panel—door control unit, and reverse status feedback path, ensuring reliable exchange of commands and status information within millisecond precision. The power supply chain is a hierarchical power supply network that provides continuous, stable, and redundant power to the vehicle door control system, platform screen door control system, and their actuators. Its structure, from top to bottom, includes: main power supply—the vehicle's 110V / 750V DC bus or the platform's 380V AC mains power; secondary power supply—on-board DC / DC converters, platform UPS, isolation transformers, and rectifier modules; end-point power distribution—the door controller's internal 24V / 48V switching power supply, motor drive power supply, safety circuits, and sensor auxiliary power supply; and a protection link throughout the entire process—fuses, circuit breakers, leakage protection devices, and surge suppressors. This supply chain not only provides energy but also maps the system's health status in real time through voltage, current, ripple, and transient parameters, making it a key observation dimension in linkage fault analysis for "power supply abnormalities leading to signal or action failures." A control logic node is the smallest decision-making unit that undertakes the functions of condition judgment, instruction generation, state transition, and fault arbitration in the linkage process between the train door and the platform screen door. Typical nodes include: the "stopping and alignment judgment node" in the train control and management system, the "door opening authorization node" in the signal system, the "interlocking and self-test node" in the door controller / central interface panel, and the "execution and feedback node" in the end door control unit. Each node corresponds to executable software logic and is also mapped to a specific hardware computing unit (PLC, microcontroller, or safety relay), which together form a decision chain for linkage timing, ensuring that the train door and the platform screen door can only act synchronously after all safety conditions are met and two-way confirmation is correct.

[0063] Preferably, in one embodiment of the present invention, step S210 may include: collecting equipment attributes, physical connection relationships, and control logic information of the vehicle door control system and the platform screen door control system; abstracting equipment attributes and physical connection relationships using a node-edge data structure, and mapping control logic information to control logic node attributes to generate a cross-disciplinary equipment topology model; performing consistency verification on the cross-disciplinary equipment topology model, and eliminating redundant nodes and erroneous connections. An example of this implementation is:

[0064] First, the configuration databases, PLC programs, I / O lists, and CAD / CAE wiring diagrams of the vehicle door control system and platform screen door control system are accessed in parallel through a unified data interface (such as OPC UA, Modbus-TCP, or RESTful API). This allows for the batch capture of device attributes (model, firmware version, port type, rated power, logical address), physical connection relationships (cable number, terminal block, communication bus segment, circuit breaker-fuse link), and discrete control logic information (Boolean expressions, state transition conditions, interlock equations, timing constraints). Then, a node-edge data structure is used for abstraction: physical devices such as the vehicle door controller, platform screen door controller, relays, switches, UPS, circuit breakers, sensors, and actuators are mapped as nodes with unified identifiers; communication links in the signal interaction path, busbars in the power supply chain, and hardwired connections in the control loop are mapped as edges with direction and attributes. Communication edges are appended with protocol type, message period, and delay tolerance; power edges are appended with voltage level, power capacity, and protection level; and control edges are appended with logical conditions and priorities. Next, the collected control logic information is mapped to the "control logic node attributes" of the nodes, including state machine definitions, input / output condition tables, fault masks, and safety interlock identifiers, enabling logical operations and physical topology to coexist in a unified graph model. Finally, the call... Figure 1 The consistency verification algorithm traverses the entire set of nodes and edges, detects and removes isolated nodes, nodes with duplicate names, loop conflicts, and erroneous connections with out-of-bounds electrical parameters, and outputs a verified cross-disciplinary equipment topology model, providing a unique and reliable digital twin baseline for subsequent data mapping, dynamic simulation, and root cause analysis.

[0065] Understandably, after generating a cross-disciplinary equipment topology model, a graphical topology editor can be invoked to provide users with a visual canvas of nodes and edges in a human-computer interactive manner. Users can modify the node positions, connection relationships, and control logic node attributes in the cross-disciplinary equipment topology model in real time through drag-and-drop, connection, and attribute configuration operations, and immediately synchronize the modification results to the in-memory graph database to ensure that the topology baseline on which subsequent data mapping and fault analysis depend is consistent with the actual wiring on site.

[0066] Step S220: Real-time acquisition of multi-source operation data from various professional departments, after standardization processing, mapping to cross-professional equipment topology model, and identification of target equipment related to the target fault; among which, the target fault is the linkage fault between subway car doors and platform screen doors.

[0067] Preferably, in one embodiment of the present invention, step S220 may include: accessing the real-time data streams of various professional departments through a unified interface protocol; converting the real-time data streams into standardized data objects including timestamps, device identifiers, and values; mapping the standardized data objects to corresponding nodes in the cross-professional device topology model based on the device identifiers, and generating a data-topology association table.

[0068] In step S220 above, server 120, as the data fusion hub, first accesses the real-time data streams of the four major professional departments—vehicle, signal, power supply, and electromechanical—in parallel through a unified interface protocol stack (including but not limited to OPCUA, Modbus-TCP, MQTT, RESTfulAPI, and private SDK). The data streams of each professional department may originate from the TCMS vehicle bus, PSC station ring network, SCADA front-end unit, or IED interval unit at the physical layer, with different protocols and sampling periods. Server 120 continuously pulls the data in a publish-subscribe mode and aligns it according to UTC time. Subsequently, server 120 performs standardization processing: parsing the raw messages of any format into standardized data objects in a unified mode. Each object contains at least (1) a 64-bit Unix timestamp, (2) a globally unique device identifier, (3) a numerical field with normalized dimensions and ranges, and optional quality code and status word, ensuring that heterogeneous data are comparable and computable under the same spatiotemporal reference. After standardization, server 120 maps data objects to the corresponding nodes in the cross-disciplinary equipment topology model constructed in step S210, using the device identifier as a foreign key. This generates a data-topology association table in a graph database or in-memory graph structure. This table stores real-time values ​​and quality indicators using node ID as the row key and timestamp as the column key, supporting subsequent anomaly threshold detection, reachability analysis, and status backtracking. Through this process, server 120 can complete the aggregation, standardization, and topology mapping of multi-source data within millisecond latency, laying a data foundation for quickly locating target equipment related to door-platform door linkage faults.

[0069] Preferably, in one embodiment of the present invention, step S220 may further include: identifying candidate abnormal nodes that match the target fault time window based on the data-topology association table and using an anomaly threshold detection algorithm; and performing reachability analysis along the signal interaction path starting from the candidate abnormal nodes to determine the target device set.

[0070] After generating the data-topology association table, server 120 can perform anomaly localization, which mainly includes: First, based on the target fault trigger time T0 and a preset time window ΔT (e.g., ±2s), all time series data within this window are extracted from the association table, and anomaly threshold detection is performed on the numerical sequence corresponding to each node: for analog quantities, a sliding window mean-variance model or an IQR-based statistical threshold is used; for digital quantities, state mutation counting is used. Nodes exceeding the threshold are marked as candidate anomaly nodes. Subsequently, using these candidate anomaly nodes as starting vertices, a breadth-first or depth-first reachability traversal is performed in the directed graph of the cross-professional equipment topology, extending k hops forward and backward along the edge direction of the signal interaction path (k is configurable, usually 1–3 hops), collecting all reachable nodes to form a target equipment set. This set serves as the pruning boundary for historical operating data in subsequent steps, ensuring that dynamic simulation and root cause analysis focus only on equipment links directly related to fault propagation, reducing computational load and improving localization accuracy.

[0071] Understandably, after determining the set of target devices related to the target fault, the fault type can be determined. The determination method includes: if all nodes in the target device set belong to the same professional subgraph, it is determined to be a "non-cross-professional fault", the process is terminated, and the fault information is pushed to the maintenance terminal of the corresponding profession for independent handling; if the nodes in the target device set span more than one professional subgraph, it is determined to be a "cross-professional fault", and step S230 and subsequent steps are continued.

[0072] Step S230: Compare the historical operating data of the target device with the preset signal interaction rule base, dynamically simulate the linkage process between the vehicle door and the platform screen door, and obtain fault process backtracking data.

[0073] Preferably, in one embodiment of the present invention, step S230 may include: constructing a door-platform screen door linkage state machine according to a preset signal interaction rule base; wherein, the door-platform screen door linkage state machine includes at least one normal state and multiple abnormal transition conditions; inputting the historical operating data of the target device into the door-platform screen door linkage state machine in chronological order, driving the door-platform screen door linkage state machine to run to obtain a fault evolution trajectory; and recording the state transition events in the fault evolution trajectory as fault process backtracking data.

[0074] In this embodiment, the signal interaction rule base is first invoked to construct a door-platform screen door linkage state machine using a finite state machine paradigm. This state machine defines a normal state "train stops → doors / platform screen doors open synchronously → hold → close synchronously" and several abnormal transition conditions, including signal timeout, voltage drop, communication interruption, interlock failure, and obstacle triggering. Each abnormal condition is bound to a Boolean expression and a timing threshold, forming deterministic transition rules. Subsequently, the historical operating data stream of the target device set is injected into the state machine sequentially according to the UTC timestamp: each time the analog clock advances by one sampling cycle, the state machine calculates the next state based on the current node value and the transition rules, and records the event ID, timestamp, source node, target node, and state variable values ​​that trigger the transition, thereby generating a complete fault evolution trajectory. This trajectory is persisted in the form of an ordered event chain, serving as fault process backtracking data for subsequent root cause analysis, and can be directly used to reproduce the entire linkage failure process.

[0075] Preferably, in one embodiment of the present invention, step S230 may further include: generating a visualization timeline based on fault process retrospective data; wherein the visualization timeline is used to present the signal timing and state changes of each node during the linkage process between the vehicle door and the platform screen door; and marking abnormal events on the visualization timeline. An example of this implementation is:

[0076] Upon obtaining the fault process backtracking data, the visualization engine is immediately invoked to generate a visualization timeline aligned with the global UTC time axis. The engine establishes a time-node two-dimensional coordinate system with event-by-event granularity: the horizontal axis represents the absolute timestamp, and the vertical axis lists all relevant nodes in hierarchical order according to the door control system, platform screen door control system, and cross-professional signal links; each sampling period corresponds to a time slice, and the signal values ​​or states of nodes within that slice are enumerated using discrete color levels or Boolean icons to form continuous time-series strips. Subsequently, based on the abnormal event records in the backtracking data, the engine overlays vertical marker lines and flashing anchors on the timeline. The marker content includes event type, triggering conditions, numerical offset, and confidence interval, and supports hover prompts and zoom positioning. This visualization timeline can be rendered in real time using WebGL or SVG vector format and can be viewed without plugins on the maintenance terminal, thus transforming the millisecond-level linkage process into an intuitive and interactive fault replay interface.

[0077] Step S240: Based on the fault process backtracking data, perform correlation analysis on the abnormal signal nodes and abnormal equipment status, and output the root cause of the fault at the cross-professional junction; whereby the cross-professional junction is used to characterize the interactive coupling part between various professional departments.

[0078] Understandably, before performing the correlation analysis in step S240, the following refinement operations can be performed: Signal anomaly detection: Compare the actual signal values ​​in the fault process backtracking data with the corresponding standard thresholds and timing windows in the signal interaction rule base item by item to mark key nodes where signals are lost, delayed, or have incorrect values; Equipment status correlation analysis: Perform secondary feature extraction on the power supply voltage, relay contact status, and circuit breaker on / off status associated with the key nodes, and input the extraction results into the correlation analysis model to determine whether the equipment itself fault is the direct cause of the signal anomaly.

[0079] Preferably, in one embodiment of the present invention, step S240 may include: extracting signal anomaly features and equipment status features from the fault process retrospective data; inputting the signal anomaly features and equipment status features into a correlation analysis model to calculate the correlation degree between anomaly nodes; outputting a candidate root cause list based on the correlation degree ranking, and selecting the node with the highest correlation degree as the root cause of the fault at the cross-disciplinary junction. An example of this implementation is:

[0080] First, feature engineering is performed on the fault process retrospective data: for signal anomalies, timing offset, amplitude drop depth, packet loss rate, and message cycle jitter are extracted; for equipment status anomalies, voltage drop amplitude, current surge peak, relay contact jitter count, and firmware error codes are extracted. Both types of features are dimensionless and Z-score standardized to construct a high-dimensional feature vector set. Then, a correlation analysis model is invoked. This model can employ a hybrid metric based on mutual information (MI) and conditional entropy, or a semi-supervised correlation calculation framework based on graph neural networks (GNNs). Inputting the feature vectors into the model yields a correlation score between any two anomaly nodes; a higher score indicates a tighter statistical or graph-structured coupling. The model outputs a candidate root cause list sorted in descending order of correlation. The node with the highest correlation and meeting the confidence threshold (≥0.85) is automatically selected as the root cause of the cross-disciplinary junction. The corresponding signal link, power supply bus segment, and logical conditions are returned to the maintenance terminal in JSON format for subsequent maintenance decisions.

[0081] It is understandable that after outputting the root cause of the cross-professional junction in step S240, the verification engine can be called to perform model accuracy verification. The main steps include: (1) extracting N labeled subway car door-platform door linkage fault records from the historical fault database, where N≥100; (2) using the cross-professional equipment topology model and signal interaction rule base as a benchmark, performing the full process calculation of steps S210-S240 on each record to obtain the predicted root cause; (3) comparing the predicted root cause with the manually labeled root cause for consistency and calculating the accuracy rate; (4) if the accuracy rate is lower than 95%, triggering the incremental learning process, adaptively adjusting the threshold in the abnormal threshold detection algorithm and the weight parameters of the correlation analysis model until the accuracy rate is ≥95%.

[0082] Preferably, in one embodiment of the present invention, the above-mentioned method for analyzing the root cause of subway car door and platform screen door linkage failures may further include: mapping the determined root cause of the failure back to a cross-disciplinary equipment topology model, automatically generating a diagnostic report containing the failure path and affected equipment; and pushing the diagnostic report to each professional maintenance terminal to guide on-site maintenance work. An example of this implementation is:

[0083] After determining the root cause of the fault, its node identifier, abnormal characteristics, and correlation score are immediately back-mapped to the constructed cross-professional equipment topology model. The mapping process starts from the root cause node, traverses the execution graph along the signal interaction path and power supply chain, extracts the attributes of all reachable nodes and corresponding edges, and forms a fault propagation subgraph. Then, the report generation engine is called to convert the subgraph into a structured diagnostic report: the main body of the report includes (1) the root cause node of the fault and its physical location, logical conditions, and abnormal threshold; (2) the node sequence, link type, and delay / voltage drop quantification value of the fault propagation path; (3) a list of affected equipment, listing the equipment ID, abnormality level, required spare parts, and estimated maintenance time. The generated diagnostic report is encapsulated in JSON+SVG dual format, where JSON is used for data interaction and SVG is used for visualization. The report is pushed to the vehicle, signal, power supply, and electromechanical professional maintenance terminals in real time through the message bus (MQTT) or RESTful Webhook. After receiving the report, the terminal automatically matches the work order system according to the equipment ID, generates maintenance tasks and attaches positioning navigation to realize closed-loop fault processing.

[0084] Preferably, in one embodiment of the present invention, the above-mentioned root cause analysis method for the linkage failure of subway car doors and platform screen doors may further include: incrementally updating the cross-disciplinary equipment topology model and signal interaction rule base when new operating data or rule updates are received. For example, this implementation method includes:

[0085] By continuously monitoring the OPCUA subscription channel, Modbus event queue, and RESTful Webhook callback interface, two types of incremental events are captured in real time: new operational data streams from various professional departments and updates to the signal interaction rule base version caused by signal system upgrades, PLC firmware replacements, or adjustments to maintenance strategies. Upon capture, the incremental data is first timestamped and consistency-checked, then the incremental graph update algorithm is invoked: for cross-professional equipment topology models, insertion, deletion, or attribute modification operations are performed only on newly added or changed nodes-edges, and a versioned snapshot is maintained in the in-memory graph database; for the signal interaction rule base, a difference patch (JSON patch) method is used to merge newly added or revised Boolean conditions, timing thresholds, and state transition rules into the existing rule set, while retaining the old version for historical backtracking. After the incremental update is completed, a lightweight consistency verification is triggered to ensure that the topology model and rule base remain compatible at the logical, timing, and electrical parameter levels; if the verification passes, an update notification is broadcast to each maintenance terminal, enabling online evolution of the system-level model without downtime reconstruction.

[0086] Based on the same inventive concept, embodiments of the present invention also provide a computer device, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 3 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network. When the computer program is executed by the processor, it implements a root cause analysis method for the linkage fault of subway car doors and platform screen doors.

[0087] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0088] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0089] Those skilled in the art will understand that implementing all or part of the processes in the above embodiments is possible.

[0090] This is accomplished by instructing related hardware through a computer program, and the computer program can be stored in a non-volatile computer.

[0091] The computer program, when executed, may include processes as described in the embodiments of the methods described above, stored in a readable storage medium.

[0092] in,

[0093] Any references to memory, databases, or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM may take many forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0094] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0095] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0096] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for root cause analysis of linkage failures between subway car doors and platform screen doors, characterized in that, The method includes: Taking the vehicle door control system and platform screen door control system as examples, a cross-disciplinary equipment topology model is constructed based on the signal interaction path, power supply chain and control logic node. Real-time acquisition of multi-source operational data from various professional departments, followed by standardized processing and mapping to the cross-professional equipment topology model, to identify target equipment related to the target fault; wherein, the target fault is a linkage fault between subway car doors and platform screen doors; The historical operating data of the target device is compared with a preset signal interaction rule base to dynamically simulate the linkage process between the vehicle door and the platform screen door, and obtain fault process backtracking data. Based on the fault process backtracking data, correlation analysis is performed on the signal abnormality nodes and equipment status abnormalities to output the root cause of the fault at the cross-disciplinary junction; wherein, the cross-disciplinary junction is used to characterize the interactive coupling part between the various professional departments.

2. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to claim 1, characterized in that, The aforementioned model, focusing on vehicle door control systems and platform screen door control systems, constructs a cross-disciplinary equipment topology model based on signal interaction paths, power supply chains, and control logic nodes, including: Collect information on the equipment attributes, physical connections, and control logic of the vehicle door control system and the platform screen door control system; The device attributes and physical connection relationships are abstracted using a node-edge data structure, and the control logic information is mapped to control logic node attributes to generate a cross-professional device topology model. The consistency of the cross-disciplinary equipment topology model is verified, and redundant nodes and erroneous connections are eliminated.

3. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to claim 1, characterized in that, The process of acquiring multi-source operational data from various professional departments in real time, and mapping it to the cross-professional equipment topology model after standardization processing includes: Access to real-time data streams from various professional departments is achieved through a unified interface protocol. The real-time data stream is converted into a standardized data object that includes timestamps, device identifiers, and numerical values. Based on the device identifier, the standardized data object is mapped to the corresponding node of the cross-professional device topology model to generate a data-topology association table.

4. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to claim 3, characterized in that, The determination of the target device related to the target fault includes: Based on the data-topology association table, an anomaly threshold detection algorithm is used to identify candidate anomaly nodes that match the target fault time window; Starting from the candidate abnormal node, reachability analysis is performed along the signal interaction path to determine the target device set.

5. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to claim 1, characterized in that, The step of comparing the historical operating data of the target device with a preset signal interaction rule base, dynamically simulating the linkage process between the vehicle door and the platform screen door, and obtaining fault process backtracking data includes: A vehicle door-platform screen door linkage state machine is constructed based on a preset signal interaction rule base; wherein, the vehicle door-platform screen door linkage state machine includes at least one normal state and multiple abnormal transition conditions; The historical operating data of the target equipment is input into the door-platform screen door linkage state machine in chronological order, and the door-platform screen door linkage state machine is driven to run to obtain the fault evolution trajectory. Record state transition events in the fault evolution trajectory as fault process backtracking data.

6. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to claim 5, characterized in that, The step of comparing the historical operating data of the target device with a preset signal interaction rule base, dynamically simulating the linkage process between the vehicle door and the platform screen door, and obtaining fault process backtracking data also includes: A visualization timeline is generated based on the fault process backtracking data; wherein, the visualization timeline is used to present the signal timing and state changes of each node during the linkage process between the vehicle door and the platform screen door; Mark abnormal events on the visualized timeline.

7. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to claim 1, characterized in that, Based on the fault process backtracking data, the correlation analysis between abnormal signal nodes and abnormal equipment status is performed to output the root cause of the fault at the cross-disciplinary junction, including: Extract the signal anomaly features and equipment status features from the fault process retrospective data; Input the signal anomaly characteristics and the device status characteristics into the correlation analysis model to calculate the correlation degree between the anomaly nodes; The candidate root cause list is output based on the correlation degree, and the node with the highest correlation degree is selected as the root cause of the failure at the cross-disciplinary junction.

8. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to any one of claims 1 to 7, characterized in that, The method further includes: The identified root causes of the fault are mapped back to the cross-disciplinary equipment topology model, and a diagnostic report containing the fault path and affected equipment is automatically generated. The diagnostic report is pushed to each professional maintenance terminal to guide on-site repair work.

9. The root cause analysis method for the linkage failure of subway car doors and platform screen doors according to any one of claims 1 to 7, characterized in that, The method further includes: When new operational data or rule updates are received, the cross-disciplinary equipment topology model and the signal interaction rule base are incrementally updated.

10. A computer device, comprising: The memory and processor contain a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the root cause analysis method for the linkage failure of subway car doors and platform screen doors as described in any one of claims 1-9.

Images