A rail transit system fault analysis method, device, equipment and storage medium

Abstract

The application discloses a rail transit system fault analysis method and device, equipment and a storage medium, and relates to the field of fault identification. The method comprises the following steps: acquiring business scenario data, and constructing a cross-professional fault analysis model based on the business scenario data; the cross-professional fault analysis model is used to represent the correlation relationship, interaction signal and transmission path among a plurality of devices of each different professional department in a rail transit system; a sensing data access channel is established, and a fault device is determined based on acquired fault information; when the location of the fault device is a professional combination department, the monitoring data of the fault device and associated devices are acquired through the sensing data access channel; based on the monitoring data and the cross-professional fault analysis model, the entire fault process corresponding to the fault information is simulated, and backtracking data is obtained; and the backtracking data is analyzed with preset abnormal data, and a target fault result is obtained. The application realizes data backtracking of the entire fault process, and can accurately determine the target fault result.

Description

Technical Field

[0001] This application relates to the field of fault identification technology, and in particular to a fault analysis method, apparatus, equipment and storage medium for rail transit systems. Background Technology

[0002] As a core component of modern urban public transportation, rail transit effectively alleviates urban traffic congestion and provides great convenience for residents' daily travel due to its significant advantages such as large capacity, high efficiency, and punctuality. However, rail transit systems encompass multiple complex and interconnected professional fields, including rolling stock, communication signals, power supply systems, and electromechanical equipment. The high degree of integration and comprehensiveness of the system makes it highly susceptible to various cross-disciplinary faults during operation. These faults are often caused by a combination of factors, and the relationship between the fault phenomena and their root causes is intricate, greatly increasing the difficulty of fault analysis and handling.

[0003] Currently, in the rail transit industry, related technologies monitor the status of equipment through sensors (temperature sensors, current sensors, etc.) deployed in subsystems of various professional fields. This enables each fault diagnosis system to acquire operational data, which is then analyzed and processed to identify fault types. However, since each subsystem operates independently, this approach is based on single-device data processing and analysis during fault analysis. This lack of a global perspective makes it easy to miss key information, and the same data may be analyzed multiple times, resulting in a one-sided and incomplete analysis, leading to low accuracy in fault identification. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, equipment, and storage medium for fault analysis of rail transit systems.

[0005] To achieve the above objectives, this application provides the following solution:

[0006] Firstly, this application provides a fault analysis method for a rail transit system, including:

[0007] Acquire business scenario data and construct a cross-disciplinary fault analysis model based on the business scenario data; the cross-disciplinary fault analysis model is used to characterize the correlation, interaction signals and transmission paths between multiple devices in different professional departments of the rail transit system;

[0008] Establish a sensing data access channel and identify faulty devices based on the acquired fault information;

[0009] When the faulty device is located at a junction of different professional departments, the monitoring data of the faulty device and related devices are obtained through the sensing data access channel; the junction of different professional departments refers to the intersection of the various professional departments.

[0010] Based on the monitoring data and the cross-disciplinary fault analysis model, the entire fault process corresponding to the fault information is simulated to obtain retrospective data.

[0011] The backtracking data is analyzed together with the preset abnormal data to obtain the target fault result.

[0012] Optionally, a cross-disciplinary fault analysis model is constructed based on the business scenario data, including:

[0013] Based on the business scenario data, a structural topology relationship of the rail transit system is established; the structural topology relationship is used to characterize the connection relationship and layout of multiple devices in various professional departments of the rail transit system.

[0014] Based on the structural topology, the interaction rules between the devices are obtained; the interaction rules include at least one of the following: signal interaction rules, interaction triggering rules, and interaction verification rules.

[0015] The interaction rules are combined to obtain a set of rules between the devices;

[0016] The structural topology and the rule set are embedded as configuration parameters into a preset model to construct the cross-disciplinary fault analysis model.

[0017] Optionally, based on business scenario data, the structural topology of the rail transit system is established, including:

[0018] The visualization program is invoked and run to extract rail transit equipment data from the business scenario data; the visualization program is used to display the visualization interface.

[0019] In response to the operation command, the data of the rail transit equipment is associated and organized in the visualization interface to establish the structural topology relationship.

[0020] Optionally, after determining the faulty device based on the acquired fault information, the method further includes:

[0021] Determine whether the faulty device is within the coverage area of ​​the structural topology;

[0022] When the faulty device is within the coverage area of ​​the aforementioned structural topology, its location is determined to be a professional junction.

[0023] When the faulty device is not within the coverage area of ​​the structural topology, it is determined that the location of the faulty device is not a professional junction.

[0024] Optionally, based on the monitoring data and the cross-disciplinary fault analysis model, the entire fault process corresponding to the fault information is simulated to obtain retrospective data, including:

[0025] The monitoring data is time-synchronized to obtain time-synchronized monitoring data;

[0026] Based on the monitoring data after time calibration, the fault process is simulated using a cross-disciplinary fault analysis model to obtain retrospective data.

[0027] Optionally, based on the monitoring data after time synchronization, a fault process simulation is performed using a cross-disciplinary fault analysis model to obtain retrospective data, including:

[0028] By using a cross-disciplinary fault analysis model, the logical relationship between the faulty device and the associated device is obtained; the logical relationship includes a preceding logical relationship and / or a following logical relationship.

[0029] Based on the aforementioned logical relationship, the time-corrected data is arranged in a chronological order to simulate the fault process and obtain the backtracking data.

[0030] Optionally, the backtracking data is analyzed with preset abnormal data to obtain the target fault result, including:

[0031] Obtain the target anomaly data corresponding to the backtracking data from the preset anomaly data;

[0032] According to the preset configuration rules, the backtracking data is compared with the target abnormal data;

[0033] The target fault result is obtained by analyzing the inconsistent backtracking data.

[0034] Secondly, this application provides a fault analysis device for a rail transit system, comprising:

[0035] A construction module is used to acquire business scenario data and build a cross-professional fault analysis model based on the business scenario data; the cross-professional fault analysis model is used to characterize the correlation, interaction signals, and transmission paths between multiple devices in different professional departments of the rail transit system.

[0036] The determination module is used to establish a sensing data access channel and determine the faulty device based on the acquired fault information;

[0037] The acquisition module is used to acquire monitoring data of the faulty device and related devices through the sensing data access channel when the location of the faulty device is a professional junction; the professional junction refers to the intersection of the various different professional departments.

[0038] The fault simulation module is used to simulate the entire fault process corresponding to the fault information based on the monitoring data and the cross-disciplinary fault analysis model to obtain retrospective data.

[0039] The result determination module is used to analyze the backtracking data and preset abnormal data to obtain the target fault result.

[0040] Thirdly, 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 rail transit system fault analysis method described in any one of the above.

[0041] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the fault analysis method for a rail transit system as described above.

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

[0043] This application provides a method, apparatus, equipment, and storage medium for fault analysis in rail transit systems. By acquiring business scenario data and constructing a cross-disciplinary fault analysis model based on the business scenario data, a sensing data access channel is established, and faulty equipment is identified based on the acquired fault information. When the location of the faulty equipment is at a professional junction, monitoring data of the faulty equipment and related equipment are acquired through the sensing data access channel. Based on the monitoring data and the cross-disciplinary fault analysis model, the entire fault process corresponding to the fault information is simulated to obtain retrospective data. The retrospective data is then analyzed with preset abnormal data to obtain the target fault result. Compared with existing technologies, this solution, on the one hand, breaks down information silos between different professional departments by constructing a professional fault analysis model. It presents the connections between equipment in different professional departments as a whole, providing a more comprehensive perspective for fault analysis. It also identifies faulty equipment through fault information, providing a clear target for subsequent fault analysis. Furthermore, it establishes a sensing data access channel to ensure timely acquisition of equipment data related to the fault, providing data support for fault identification. On the other hand, for fault scenarios spanning multiple professional departments, it can comprehensively acquire monitoring data of relevant equipment and comprehensively consider information from other professional departments. By combining monitoring data and cross-professional fault analysis models, it achieves data tracing of the entire fault process, thereby more clearly reproducing the fault occurrence process and facilitating a more accurate determination of the root cause of the fault. In addition, by analyzing the retrospective data and preset abnormal data, it can quickly and accurately determine the target fault result, improving the accuracy of fault identification. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments 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.

[0045] Figure 1 This is a schematic diagram of the structure of a fault analysis system for a rail transit system according to one embodiment of this application;

[0046] Figure 2 A flowchart illustrating a fault analysis method for a rail transit system provided in an embodiment of this application;

[0047] Figure 3 A flowchart illustrating a method for constructing a cross-disciplinary fault analysis model based on business scenario data, provided in an embodiment of this application;

[0048] Figure 4 A flowchart illustrating a method for simulating a fault process to obtain backtracking data, provided in an embodiment of this application;

[0049] Figure 5 A flowchart illustrating a fault analysis method for a rail transit system provided in another embodiment of this application;

[0050] Figure 6 A functional module diagram of a fault analysis device for a rail transit system provided in an embodiment of this application;

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

[0052] 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, and 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.

[0053] 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:

[0054] Specialized intersections refer to the areas where different professional departments overlap or connect. In the rail transit industry, these departments can include rolling stock, signaling, power supply, electromechanical systems, etc. Specialized intersections encompass the areas where these multiple departments intersect.

[0055] Device topology: The way and arrangement of devices in a system or network. It describes the physical connections or logical relationships between devices.

[0056] Data retrospection: refers to the process of tracking and analyzing past situations or events using historical data.

[0057] Root cause analysis is a systematic method used to identify the root causes of problems and prevent their recurrence. Its goal is to find the deepest reasons that led to the problem, rather than simply addressing the surface symptoms. Root cause analysis is commonly used in quality improvement, incident investigation, and troubleshooting.

[0058] In related technologies, sensors deployed in subsystems across various professional fields monitor equipment status in real time and collect operational data. The fault diagnosis system then processes this data, using statistical analysis and simulation identification methods to identify anomalies in individual devices and determine the fault type. However, because each professional fault diagnosis system operates independently and their data is not shared, data silos arise. When a fault spans multiple departments, the lack of a global perspective easily leads to the omission of crucial information. Furthermore, the absence of a unified platform to coordinate diagnostic work across different departments can result in the same data being analyzed multiple times, increasing workload and potentially causing conflicts due to differing analysis results. Additionally, a fault diagnosis system for a single professional field may not fully consider the impact of other fields, leading to lower fault identification accuracy.

[0059] To address the aforementioned shortcomings, this application provides a fault analysis method for rail transit systems. Compared with existing technologies, on the one hand, this solution, by constructing a specialized fault analysis model, can break down information silos between different professional departments, presenting a holistic view of the connections between equipment in different departments, providing a more comprehensive perspective for fault analysis, and identifying faulty equipment through fault information, providing a clear target for subsequent fault analysis, establishing a sensing data access channel to ensure timely acquisition of fault-related equipment data, and providing data support for fault identification; on the other hand, for fault scenarios spanning multiple professional departments, it can comprehensively acquire monitoring data of relevant equipment, comprehensively consider information from other professional departments, and achieve data tracing of the entire fault process by combining monitoring data and cross-professional fault analysis models, thereby more clearly reproducing the fault occurrence process, facilitating more accurate judgment of the root cause of the fault, and further, by analyzing the retrospective data with preset abnormal data, it can quickly and accurately determine the target fault result, improving the accuracy of fault identification.

[0060] This application provides a fault analysis method for rail transit systems, which can be applied to, for example... Figure 1 The illustrated rail transit system fault analysis system includes a terminal 102, a server 104, and a data storage system. The terminal 102 communicates with the server 104 via a network. The data storage system stores the data that the server 104 needs to process. The data storage system can be set up independently, integrated into the server 104, or placed in the cloud or on another server. The terminal 102 can send acquired business scenario data to the server 104. After receiving the business scenario data, the server 104 constructs a cross-disciplinary fault analysis model and performs root cause analysis to obtain the target fault result. Furthermore, in some embodiments, the rail transit system fault analysis method can also be implemented independently by the server 104 or the terminal 102. For example, the terminal 102 can directly construct a cross-disciplinary fault analysis model based on the acquired business scenario data and perform root cause analysis to obtain the target fault result. The terminal 102 can pre-store signal interaction rules, equipment anomaly databases, etc., to facilitate rail transit system fault analysis.

[0061] The terminal 102 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, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 104 can be implemented using a standalone server or a server cluster composed of multiple servers, or it can be a cloud server.

[0062] In one exemplary embodiment, such as Figure 2As shown, a fault analysis method for a rail transit system 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 104 as an example, the explanation includes the following steps S201 to S205. Wherein:

[0063] Step S201: Obtain business scenario data and construct a cross-professional fault analysis model based on the business scenario data; the cross-professional fault analysis model is used to characterize the correlation, interaction signals and transmission paths between multiple devices in different professional departments of the rail transit system.

[0064] It should be noted that the above business scenarios refer to those within the rail transit industry. Each different business scenario can correspond to a cross-disciplinary fault analysis model. These business scenarios could include, for example, train dispatching, station operations, and interval operation. Business scenario data refers to data covering the entire lifecycle of all business scenarios within the rail transit system.

[0065] The aforementioned business scenario data can be obtained through a database or blockchain, imported from external devices, or obtained by sending a request to other systems. This embodiment does not impose any limitations on the method of obtaining business scenario data.

[0066] After obtaining the business scenario data, the data can be analyzed to extract the rail transit equipment data corresponding to the business scenario. Then, the correlation between the rail transit equipment data can be analyzed to build a cross-disciplinary fault analysis model.

[0067] In another exemplary embodiment of this application, in order to achieve simulation and backtracking of the entire failure process, it is necessary to construct a cross-disciplinary failure analysis model, which is as follows: Figure 3 As shown, the method includes the following steps S301 to S304:

[0068] Step S301: Based on business scenario data, establish the structural topology relationship of the rail transit system; the structural topology relationship is used to characterize the connection relationship and layout of multiple devices in different professional departments of the rail transit system.

[0069] Step S302: Based on the structural topology, obtain the interaction rules between each device; the interaction rules include at least one of the following: signal interaction rules, interaction triggering rules, and interaction verification rules.

[0070] Step S303: Combine the interaction rules to obtain a set of rules between devices.

[0071] Step S304: Embed the structural topology relationship and rule set as configuration parameters into the preset model to construct a cross-disciplinary fault analysis model.

[0072] As one feasible approach, after acquiring business scenario data, the data can be analyzed to establish the structural topology of the rail transit system. By calling and running a visualization program, rail transit equipment data can be extracted from the business scenario data. The visualization program is used to display the visualization interface. In response to operation commands, the rail transit equipment data is correlated and organized in the visualization interface to establish structural topology.

[0073] The rail transit equipment data includes multiple pieces of equipment information, such as equipment name, manufacturer, identifier, and attributes. First, rail transit equipment data is extracted from the business scenario data. Then, a visualization program is invoked and run, displaying a visual interface on the computer device. Users can operate on this interface, allowing the computer device to receive user commands and execute corresponding operations on the rail transit equipment data, thereby establishing the cross-departmental structural topology of this business scenario.

[0074] For example, in a rail transit vehicle departure scenario, suppose the fault information is that a platform screen door malfunction prevents the doors from closing, thus preventing the vehicle from leaving the station. In this scenario, the rail transit system may include multiple specialized departments, such as the electromechanical department, the signaling department, and the rolling stock department. The data for this scenario can include data covering the entire lifecycle of the vehicle departure scenario. First, a visualization program is invoked and run to extract rail transit equipment data from the scenario data, which may include data from the electromechanical, signaling, and rolling stock departments. Specifically, the electromechanical department deals with platform screen doors, which are responsible for platform safety isolation and other functions; the signaling department deals with interlocking devices, which are responsible for ensuring train operation safety and controlling signal transmission; and the rolling stock department deals with train doors, which provide passenger boarding and alighting access. By unifying and integrating the track equipment from these different professional departments, users can click on different controls on the visual interface, such as clicking, dragging, and sliding controls, to respond to user operation commands. The visual interface will then use graphics, lines, and other intuitive methods to display the connections and interactions between the equipment, thereby establishing the cross-professional structural topology of the vehicle's departure scenario.

[0075] This embodiment avoids the limitations of a single professional perspective. By establishing the structural topology of the rail transit system based on business scenario data, it can comprehensively integrate the relationships between different equipment in various professional departments. This facilitates subsequent triggering from a global perspective and comprehensively considers the mutual influence between different professional fields, thereby providing a more comprehensive and accurate fault analysis. This helps to discover and solve deep-seated fault problems that span multiple professions.

[0076] As another feasible approach, in establishing the structural topology of a rail transit system, since business scenario data may come from different data sources, such as equipment ledgers, line parameter tables, equipment manuals, maintenance manuals, and text reports, after acquiring the business scenario data, we can first identify structured data (equipment ledgers, line parameter tables) and unstructured data (equipment manuals, maintenance manuals, text reports) from the business scenario data. Then, we can directly extract entity data from the structured data, which may include lines, equipment, stations, etc., and obtain relational data through surface association fields, including the attribution relationship between equipment and lines, the adjacency relationship between stations, and the relationship between stations and lines. Then, we can extract entity information from the text of the unstructured data using a named entity recognition model. For example, we can identify "Line 3 signal system fault, involving signal S15" from the maintenance log, and parse the association between entities in the text using a relation extraction model. For example, we can infer "Equipment A and Equipment B are connected by cable" (physical connection relationship) from the construction report.

[0077] The aforementioned entity recognition model has the ability to extract entity data, and the aforementioned relation extraction model has the ability to extract relation data. Graph neural networks are pre-built systems capable of graph processing of entity and relation data, and have the ability to establish structural topological relationships. After obtaining entity and relation data from both structured and unstructured data, all entity and relation data can be input into the pre-built graph neural network. This network then categorizes the entity and relation data into physical entities, logical entities, physical connections, logical associations, spatial adjacencies, etc. For example, physical entities include: lines, stations, sections, and equipment; logical entities include: systems (signal systems, power supply systems, vehicle systems) and sub-networks (such as communication sub-networks); physical connections include: equipment installed on lines / stations / sections; logical associations include adjacent stations, serial sections, etc. All data is then correlated and organized to obtain structural topological relationships.

[0078] Understandably, in rail transit systems, different rail transit equipment corresponds to different interaction rules. Signal interaction rules determine the format, content, and path of information transmission between equipment. For example, between signal controllers in the signaling department and trains in the rolling stock department, the signal controller sends signals such as speed limits and route openings to the train using specific codes. The train receives the signal, parses it, and executes the corresponding operation. Signal interaction rules must clearly define the signal format, transmission frequency, encoding method, signal strength requirements, etc.

[0079] After establishing the structural topology, the interaction rules between each device can be obtained. This can be done by obtaining the manufacturer information of each device and then obtaining the signal interaction rules of each device from the manufacturer information, or by obtaining the signal interaction rules of each device based on experience information, or by importing them from external devices.

[0080] For example, in the scenario of a platform screen door malfunction when a vehicle is about to leave the station, the signal logic between the platform screen door and the signal system when the vehicle is about to leave the station varies slightly between different manufacturers' equipment, and specific rules need to be customized for each real-world scenario.

[0081] It should be noted that interaction triggering rules are used to characterize the conditions under which interactive behavior occurs between devices. For a train's braking and traction systems, when the train receives a stop command, detects an obstacle ahead, or experiences overspeeding, the braking system will trigger an interaction with the traction system, causing the traction system to reduce power or stop operating, while the braking system initiates braking. These triggering conditions can be based on various factors such as time, events, and state changes, and require precise setting of thresholds and judgment logic to ensure the timeliness and accuracy of the interaction.

[0082] Interactive verification rules are used to ensure the reliability of equipment interaction. Taking the power supply system and overhead contact line equipment as an example, when the power supply system supplies power to the overhead contact line, it needs to verify parameters such as voltage, current, and phase in real time. If parameters are detected to be outside the normal range, the system will issue an alarm and take corresponding measures, such as cutting off the power supply or adjusting the power supply parameters. Interactive verification rules also include data integrity verification, protocol consistency verification, etc., ensuring the stability and security of equipment interaction through multiple verification mechanisms.

[0083] The acquired interaction rules are systematically combined to form a set of rules between devices. During this combination process, the rules are first categorized and organized to clarify the relationships and priorities between different types of rules. For example, signal interaction rules are fundamental, interaction triggering rules initiate corresponding operations based on the results of signal interactions, and interaction verification rules run throughout the entire interaction process, supervising and verifying the former two.

[0084] After obtaining the rule set, the structural topology and rule set are embedded into a pre-defined model to construct a cross-disciplinary fault analysis model. The pre-defined model can be a pre-established algorithm framework. The structural topology is input into the pre-defined model in the form of a graph structure, where nodes represent devices and edges represent the connections between devices. The rule set is transformed into the constraints and computational logic of the pre-defined model, which guides the model to analyze and predict device interaction behavior, thereby constructing a cross-disciplinary fault analysis model.

[0085] In this embodiment, by combining and processing the interaction rules, a comprehensive, orderly, and efficient set of rules can be identified, providing good data guidance information for signal interaction between devices. Furthermore, by comprehensively considering the structural topology relationship and the set of rules, they are embedded as configuration parameters into a preset model, thereby establishing a unified data platform or database, namely a cross-professional fault analysis model. The cross-professional fault analysis model can realize data sharing between different professions, which means that data from multiple systems such as vehicles, signals, communications, and power supply can be centrally managed and uniformly analyzed, thereby improving the accuracy and efficiency of fault identification.

[0086] Step S202: Establish a sensing data access channel and determine the faulty device based on the acquired fault information.

[0087] It should be noted that the aforementioned sensing data access channels refer to the data transmission interfaces of various professional departments. For example, in the scenario of a platform screen door malfunction when a vehicle is leaving the station, sensing and monitoring points (data transmission interfaces) can be set up at the platform screen door, signal system, and vehicle doors, so that computer equipment can obtain data on the opening and closing status of the platform screen door itself, the signal transmission status data exchanged with the signal system, the vehicle status data monitored by the signal system, and the vehicle door status data, etc.

[0088] After establishing a sensing data access channel for each device, fault information is acquired. This fault information can be sent to the computer device when an anomaly is detected, pushed to the computer device from an external device, or manually entered into the computer device.

[0089] After obtaining the fault information, it can be analyzed to preliminarily identify the faulty equipment. For example, if the fault information is "platform door cannot be opened," then the faulty equipment is identified as the "platform door," and further investigation is needed to determine whether the root cause of the fault belongs to a fault in another department.

[0090] In this embodiment, by identifying the faulty equipment based on the acquired fault information, the cause of the fault can be preliminarily determined, providing good data guidance for subsequent cross-departmental fault analysis and facilitating a deeper search for the root cause of the fault.

[0091] Step S203: When the location of the faulty equipment is at a professional junction, the monitoring data of the faulty equipment and related equipment are obtained through the sensing data access channel; the professional junction refers to the intersection of different professional departments.

[0092] The monitoring data of the aforementioned faulty equipment and related equipment refers to the data of real-time monitoring of the rail transit system. For example, when the faulty equipment is a turnout switch machine and the related equipment is a track circuit device, the monitoring data corresponding to the faulty equipment may include: current data, voltage data and action time data. Then, the monitoring data corresponding to the track circuit device may include: track circuit voltage data, frequency data and train occupancy information data.

[0093] After identifying the faulty device based on the acquired device information, the method further includes:

[0094] Determine whether the faulty equipment is within the coverage area of ​​the structural topology; if it is within the coverage area, determine that the location of the faulty equipment is a professional junction; if it is not within the coverage area, determine that the location of the faulty equipment is not a professional junction.

[0095] In this embodiment, after identifying the faulty device, it is necessary to further determine whether the location of the faulty device is a professional junction, that is, whether it is within the coverage of the structural topology. The structural topology, as a "digital map" of the equipment architecture across different professional departments, clearly marks the connection relationships and hierarchical structure between the devices. By checking whether the faulty device is within the coverage of the structural topology, it can be determined whether the location of the faulty device is a professional junction.

[0096] For example, in the area where the power supply system and the overhead contact line meet, if an abnormal voltage is detected in the overhead contact line, the first step is to locate the corresponding overhead contact line equipment node in the structural topology diagram of the power supply system by equipment number or physical location. If the node exists in the structural topology and has an edge connecting it to power supply equipment (such as traction substations or feeder switches), then the faulty equipment can be determined to be within the coverage area of ​​the structural topology, and its location can be identified as a professional junction. Conversely, if no corresponding node can be found in any professional structural topology diagram, then the location of the faulty equipment can be determined not to be a professional junction.

[0097] Understandably, fault diagnosis at the intersection of different specialties faces challenges such as complex equipment interactions and ambiguous responsibility definitions. For example, when a fault occurs at the junction of the train operation control system and the communication system, it may involve multiple factors such as onboard equipment, trackside base stations, and communication protocols. In this case, it is necessary to combine the structural topology relationships and rule sets in the cross-disciplinary fault analysis model to conduct in-depth analysis of the monitoring data of the faulty equipment and related equipment. Therefore, monitoring data of the faulty equipment and related equipment must be obtained through data access channels.

[0098] In this embodiment, when the faulty device is located at a professional junction, the monitoring data of the faulty device and related devices are obtained through the sensing data access channel, which provides data support for subsequent fault process simulation, facilitates accurate location of the root cause of the fault, and realizes cross-professional collaborative fault diagnosis and handling.

[0099] Step S204: Based on monitoring data and cross-disciplinary fault analysis models, the entire fault process corresponding to the fault information is simulated to obtain retrospective data.

[0100] Understandably, in rail transit systems, equipment from various specialized departments is widely distributed and supplied by different manufacturers. Due to factors such as differences in hardware clock accuracy, network transmission latency, and system time setting deviations, the timestamps of data collected by different devices often have varying degrees of error. For example, the timestamps of data collected by onboard sensors and trackside signaling equipment may be inconsistent. Without time synchronization, this can lead to time misalignment during data analysis, making it impossible to accurately reconstruct the true sequence and causal relationship of fault occurrences. In this embodiment, by performing time synchronization on the monitoring data, the time reference of each monitoring data point can be unified, ensuring the consistency and accuracy of the data in the time dimension, and providing a reliable data foundation for subsequent fault analysis.

[0101] In another exemplary embodiment of this application, in order to accurately determine the target fault result, it is necessary to simulate the entire fault process corresponding to the fault information. Figure 4 As shown, the method includes the following steps S401 to S402:

[0102] Step S401: Perform time synchronization processing on the monitoring data to obtain the time-synchronized monitoring data.

[0103] Step S402: Based on the monitoring data after time calibration, the fault process is simulated through a cross-disciplinary fault analysis model to obtain retrospective data.

[0104] Specifically, a high-precision, stable, and reliable time source is first selected as the time calibration benchmark, such as the time signal provided by the Global Positioning System (GPS) or the BeiDou Navigation Satellite System. These satellite time signals have nanosecond-level accuracy, which can meet the high-precision requirements for time calibration of rail transit monitoring data. A master clock server can be set up in the rail transit control center to receive satellite time signals and synchronize the time with each monitoring device through the network. Then, the time of each device is synchronized. Each specialized device synchronizes its time with the master clock server through the network according to a time synchronization protocol. Common time synchronization protocols include Network Time Protocol (NTP) and Precision Time Protocol (PTP). For equipment with high time accuracy requirements, such as signaling systems and train control systems, the PTP protocol can be used to achieve sub-microsecond time synchronization accuracy; while for general specialized equipment, the NTP protocol can be used. During operation, each device can periodically perform time calibration with the master clock server to ensure time accuracy.

[0105] During data acquisition, an accurate timestamp is added to each monitoring data point. For data already acquired with error timestamps, corrections are made based on the time deviation between the device and the master clock server to obtain calibrated monitoring data. For example, if the time of a vehicle-mounted sensor is 500 milliseconds behind the master clock, the timestamp of the sensor's data is uniformly increased by 500 milliseconds to obtain calibrated monitoring data.

[0106] The time synchronization logic in this step confirms the time difference between devices by checking the delay of the perceived data of the same event between the two devices, and is used to calibrate the time of the perceived data related to this fault.

[0107] As one possible approach, in the process of simulating the fault process through a cross-disciplinary fault analysis model, the model can be used to obtain the preceding and / or following logical relationships between the faulty equipment and related equipment. Based on the preceding and / or following logical relationships, the time-calibrated data can be arranged in a time sequence to simulate the fault process and obtain backtracking data.

[0108] In this embodiment, the cross-disciplinary fault analysis model uses the logical relationships between devices as clues to dynamically extrapolate the monitoring data after time calibration during the fault simulation process.

[0109] Specifically, the cross-disciplinary fault analysis model starts from key event nodes and, based on prior logical relationships, traces the evolution of equipment states before the fault occurs. For example, when a fault occurs in the simulated signal system, if the train overspeed protection (ATP) device issues an emergency braking command, the model will, based on prior logical relationships, retrieve data from the onboard speed sensor, track circuit speed limit information, etc., to simulate the speed monitoring and command generation process and determine whether the braking command was triggered by an abnormal speed. It then performs a post-fault logic propagation simulation: based on the post-fault logic, the model forward-deduces the path of the impact after the fault occurs. For instance, in the simulation of a short-circuit fault in the power supply system, when the output voltage of the traction substation suddenly drops, the model, based on post-fault logic, sequentially analyzes the magnitude of the contact network voltage drop, the action time of the train pantograph protection device, and the chain reaction of onboard electrical equipment faults. By calculating the signal transmission delay and response threshold between various devices, it simulates the propagation trajectory of the fault in the system.

[0110] During fault simulation, the timing logic of the data is strictly followed, and time windows and delay parameters are set. If the response time of a device exceeds the threshold range specified by the logical relationship, the model automatically marks it as an anomaly and re-evaluates the fault development path. For example, in a car door control system, if the door drive motor fails to start within a specified time after receiving a closing command, the model considers this an anomaly, adjusts the subsequent simulation process, and investigates faults in the motor control circuit or drive module.

[0111] After the fault simulation is completed, the cross-disciplinary fault analysis model generates comprehensive backtracking data based on the logical relationships and simulation process. The backtracking data is presented hierarchically, with a timeline as the main thread, combined with the logical relationships between the equipment. This backtracking data can include detailed information such as the time and location of the fault, the fault propagation path, the state changes of each device during the fault process, and the evolution of relevant parameters. This backtracking data can be stored in a structured format, allowing maintenance personnel to access and analyze it, helping them to gain a deeper understanding of the entire fault process and develop targeted maintenance and preventative measures.

[0112] In this embodiment, a cross-disciplinary fault analysis model can more realistically reconstruct the entire process before and after the fault occurs, thereby obtaining more comprehensive retrospective data. This allows technical personnel from different disciplines to communicate and collaborate more easily, enabling cross-disciplinary collaborative fault identification and handling. This not only helps to quickly locate the root cause of the fault but also improves the speed of fault handling and shortens the time for the system to return to normal operation.

[0113] Step S205: Analyze the backtracking data and preset abnormal data to obtain the target fault result.

[0114] After obtaining the backtracking data, logical verification can be performed on the generated backtracking data to conduct root cause analysis of the fault information and obtain the target fault result. The target fault result refers to the root cause of the fault information that crosses professional departments.

[0115] In the process of analyzing backtracked data and preset abnormal data to obtain the target fault result, the target abnormal data corresponding to the backtracked data can be obtained from the preset abnormal data; the backtracked data and the target abnormal data are compared according to the preset configuration rules; and the inconsistent backtracked data are analyzed to obtain the target fault result.

[0116] For example, in a rail transit system, the target abnormal data is abnormal emergency braking data that occurs during train operation. Preset configuration rules may include: ① If the speed change rate exceeds the normal range during emergency braking (e.g., the speed change rate during normal braking is -1m / s² to -3m / s², while the threshold for abnormal braking is less than -5m / s²), it is determined to be abnormal braking. ② Check whether there are any preconditions such as track circuit abnormalities or signal system malfunctions before the braking command is issued. ③ Check whether the operating status data of each braking device (such as brake pads, brake motors, etc.) is normal during braking. The backtracking data may include detailed records of train speed changes, the time and source of the braking command, and the operating parameters of each braking device (such as pressure, current, etc.).

[0117] After comparing the retrospective data with the target anomaly data, it was found that the train's speed change rate reached -6 m / s² during emergency braking, exceeding the normal range and meeting the anomaly judgment condition in Rule ①. Retrospective data showed that a momentary short circuit occurred in the track circuit before the braking command was issued, which is consistent with the preconditions for checking in Rule ②, suggesting that a track circuit fault may have caused the signal system to mistakenly issue a braking command. During braking, abnormal fluctuations in the brake pad pressure data indicated that the braking equipment's operating state was unstable, meeting the requirements for checking the braking equipment's operating state in Rule ③.

[0118] It should be noted that the causes of anomalies in historical data are pre-organized and configured in the equipment anomaly database. Specifically, after acquiring the backtracking data, each backtracking data is analyzed individually. For the current backtracking data, the target anomaly data corresponding to that current backtracking data is retrieved from the equipment anomaly database. The target anomaly data corresponding to the current backtracking data refers to the anomaly data generated by the same equipment as the current backtracking data in the equipment anomaly database. If the current backtracking data matches the target anomaly data, it indicates that the current backtracking data is correct; if the current backtracking data does not match the target anomaly data, it indicates that the current backtracking data is incorrect, indicating a cross-departmental fault. Then, the inconsistent backtracking data is analyzed to obtain the target fault result. This target fault result may include, for example, the target faulty equipment and the target fault cause. The target faulty equipment may refer to related equipment of the faulty equipment, and the target fault cause may be the abnormal state value corresponding to the related equipment. For example, when the faulty equipment corresponding to the fault information is equipment 'a', after simulating the fault process through the cross-departmental fault analysis model, the target fault result obtained may be that equipment 'b' associated with equipment 'a' has an anomaly.

[0119] For example, please see Figure 5 As shown, in the root cause analysis of a specific business scenario, the structural topology relationship between devices in different professional departments can be constructed first based on the business scenario data, and the interaction rules between each device (signal interaction rules, interaction triggering rules, and interaction verification rules) can be obtained. Then, a perception data access channel can be established, and a cross-professional fault analysis model can be constructed based on the structural topology relationship and interaction rules. When a device malfunctions, fault information is obtained, the faulty device is identified based on the obtained fault information, and then it is determined whether the location of the faulty device is a professional junction. If the location of the faulty device is not a professional junction, it is a non-cross-professional fault, and the analysis ends.

[0120] When the faulty equipment is located at a junction of different professional areas, monitoring data from the faulty equipment and related equipment are acquired. This data is then time-synchronized to obtain time-synchronized monitoring data, and the logical relationships between the faulty equipment and related equipment are identified. These logical relationships include pre- and post-logical relationships. Based on these relationships, the time-synchronized data is arranged chronologically to simulate the fault process and obtain retrospective data. Target anomaly data corresponding to the retrospective data is retrieved from a pre-defined equipment anomaly database. According to pre-defined configuration rules, the retrospective data and target anomaly data are compared. Inconsistent retrospective data is analyzed to obtain the target fault result.

[0121] Furthermore, once the target fault result is identified, it can be corrected in a timely manner, allowing the rail transit system to return to normal operation.

[0122] In this embodiment, by establishing a cross-disciplinary fault analysis model, a standardized process can be constructed, which helps to ensure the consistency of fault handling, reduce misjudgments due to human factors, and greatly improve the quality of fault handling.

[0123] This application provides a fault analysis method for rail transit systems. On the one hand, by constructing a professional fault analysis model, it can break down information silos between different professional departments, present the connections between equipment in different departments as a whole, provide a more comprehensive perspective for fault analysis, and identify faulty equipment through fault information, providing a clear target for subsequent fault analysis. It also establishes a sensing data access channel to ensure timely acquisition of equipment data related to the fault, providing data support for fault identification. On the other hand, for professional junctions where cross-professional faults are frequent, it can comprehensively acquire monitoring data of relevant equipment. By combining monitoring data and cross-professional fault analysis models, it can achieve data tracing of the entire fault process, thereby more clearly reproducing the fault occurrence process and facilitating more accurate judgment of the root cause of the fault. Furthermore, by analyzing the retrospective data and preset abnormal data, it can quickly and accurately determine the target fault result, improving the accuracy of fault identification.

[0124] Based on the same inventive concept, this application also provides a device for implementing the above-described rail transit system fault analysis apparatus. The solution provided by this apparatus is similar to the solution described in the above method; therefore, the specific limitations in one or more embodiments of the rail transit system fault analysis apparatus provided below can be found in the limitations of the rail transit system fault analysis method described above, and will not be repeated here.

[0125] In one exemplary embodiment, such as Figure 6 As shown, a fault analysis device for a rail transit system is provided, comprising:

[0126] Module 510 is used to acquire business scenario data and build a cross-professional fault analysis model based on the business scenario data; the cross-professional fault analysis model is used to characterize the relationship, interaction signals, and transmission paths between multiple devices in different professional departments of the rail transit system.

[0127] The determination module 520 is used to establish a sensing data access channel and determine the faulty device based on the acquired fault information;

[0128] The acquisition module 530 is used to acquire monitoring data of the faulty equipment and related equipment through the sensing data access channel when the location of the faulty equipment is at the intersection of different professional departments. The intersection of professional departments refers to the location where different professional departments meet.

[0129] The fault simulation module 540 is used to simulate the entire fault process corresponding to the fault information based on monitoring data and cross-disciplinary fault analysis models to obtain retrospective data.

[0130] The result determination module 550 is used to analyze the backtracking data and preset abnormal data to obtain the target fault result.

[0131] As an optional implementation, the construction module 510 is specifically used for:

[0132] Based on business scenario data, the structural topology of the rail transit system is established; the structural topology is used to characterize the connection relationships and layout of multiple devices in different professional departments of the rail transit system.

[0133] Based on the structural topology, obtain the interaction rules between each device; the interaction rules include at least one of the following: signal interaction rules, interaction triggering rules, and interaction verification rules.

[0134] The interaction rules are combined to obtain a set of rules between devices;

[0135] By embedding structural topology relationships and rule sets as configuration parameters into a preset model, a cross-disciplinary fault analysis model is constructed.

[0136] As an optional implementation, the construction module 510 is also used for:

[0137] The visualization program is invoked and run to extract rail transit equipment data from business scenario data; the visualization program is used to display the visualization interface; in response to operation commands, the rail transit equipment data is correlated and organized in the visualization interface to establish structural topological relationships; or...

[0138] The process involves identifying structured and unstructured data from business scenario data; extracting entity data and relational data from the structured data; using a named entity recognition model to extract entity data from the unstructured data; and using a relation extraction model to parse the relationships between entity data. Entity data is then converted into node features, and relational data is converted into edge features. Finally, the entity data and relational data are processed using a graph neural network to generate structural topological relationships.

[0139] As an optional implementation, the above-described apparatus is further used for:

[0140] Determine whether the faulty device is within the coverage area of ​​the structural topology;

[0141] When the faulty equipment is within the coverage area of ​​the structural topology, its location is determined to be a professional junction.

[0142] When the faulty device is not within the coverage area of ​​the structural topology, it is determined that the location is not a professional junction.

[0143] As an optional implementation, the fault simulation module 540 is specifically used for:

[0144] The monitoring data is time-synchronized to obtain the time-synchronized monitoring data;

[0145] Based on the monitoring data after calibration, the fault process is simulated through a cross-disciplinary fault analysis model to obtain retrospective data.

[0146] As an optional implementation, the fault simulation module 540 is also used for:

[0147] Obtain the logical relationship between the faulty device and related devices; the logical relationship includes preceding logical relationships and / or following logical relationships.

[0148] Based on logical relationships, the data after time synchronization is arranged in chronological order to simulate the fault process and obtain backtracking data.

[0149] As an optional implementation, the result determination module 550 is specifically used for:

[0150] Obtain the target anomaly data corresponding to the backtracking data from the preset anomaly data;

[0151] According to the preset configuration rules, the backtracking data is compared with the target abnormal data;

[0152] By comparing and analyzing inconsistent backtracking data, the target fault result is obtained.

[0153] The rail transit system fault analysis device provided in this application has two main advantages. First, by constructing a professional fault analysis model, this solution can break down information silos between different professional departments, present the connections between equipment in different departments as a whole, provide a more comprehensive perspective for fault analysis, identify faulty equipment through fault information, provide clear targets for subsequent fault analysis, establish a sensing data access channel, ensure timely acquisition of equipment data related to the fault, and provide data support for fault identification. Second, for fault scenarios spanning multiple professional departments, it can comprehensively acquire monitoring data of relevant equipment, comprehensively consider information from other professional departments, and achieve data tracing of the entire fault process by combining monitoring data and cross-professional fault analysis models. This allows for a clearer reproduction of the fault occurrence process, facilitates more accurate judgment of the root cause of the fault, and further, by analyzing the retrospective data with preset abnormal data, it can quickly and accurately determine the target fault result, improving the accuracy of fault identification.

[0154] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 7 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 a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores video tag processing data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a fault analysis method for a rail transit system.

[0155] Those skilled in the art will understand that Figure 7 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.

[0156] 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.

[0157] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0158] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0159] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0160] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can 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 can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0161] 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.

[0162] 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.

[0163] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A fault analysis method for a rail transit system, characterized in that, This is applied to the vehicle departure scenario of rail transit. In this scenario, the rail transit system includes multiple professional departments, including the electromechanical department, the signaling department, and the vehicle department. The track equipment involved in the electromechanical department is the platform screen doors, which are responsible for the safety isolation of the platform. The track equipment involved in the signaling department is the interlocking equipment, which is responsible for ensuring train operation safety and controlling signal transmission. The vehicle engineering department deals with track equipment such as doors, which provide passageways for passengers to get on and off the train. The fault analysis method for the rail transit system includes: Acquire business scenario data and construct a cross-disciplinary fault analysis model based on the business scenario data; the cross-disciplinary fault analysis model is used to characterize the correlation, interaction signals and transmission paths between multiple devices in different professional departments of the rail transit system; the business scenario data includes data of the entire life cycle of the vehicle departure scenario; Establish a sensing data access channel and identify faulty devices based on the acquired fault information; When the faulty device is located at a professional junction, monitoring data of the faulty device and related devices are obtained through the sensing data access channel; the professional junction refers to the intersection of various different professional departments; based on the monitoring data and the cross-professional fault analysis model, the entire fault process corresponding to the fault information is simulated to obtain retrospective data; The backtracking data is analyzed together with preset abnormal data to obtain the target fault result; The cross-disciplinary fault analysis model, constructed based on the aforementioned business scenario data, includes: Based on the business scenario data, the track data of different professional departments are integrated in a unified manner to establish the structural topology of the rail transit system; the structural topology is used to characterize the connection relationship and layout of multiple devices in various professional departments of the rail transit system. Based on the structural topology, the interaction rules between the devices are obtained; the interaction rules include at least one of the following: signal interaction rules, interaction triggering rules, and interaction verification rules. The interaction rules are combined to obtain a set of rules between the devices; The structural topology and the rule set are embedded as configuration parameters into a preset model to construct the cross-disciplinary fault analysis model. The preset model is a pre-established algorithm framework. The structural topology is input into the preset model in the form of a graph structure. The rule set is transformed into the constraints and calculation logic of the preset model to guide the model to analyze and predict the interaction behavior of the equipment. Based on the monitoring data and the cross-disciplinary fault analysis model, the entire fault process corresponding to the fault information is simulated to obtain retrospective data, including: The monitoring data is time-synchronized to obtain time-synchronized monitoring data; The logical relationship between the faulty device and the associated device is obtained through the cross-disciplinary fault analysis model; the logical relationship includes a preceding logical relationship and / or a following logical relationship. Based on the aforementioned logical relationship, the time-corrected data is arranged in a chronological order to simulate the fault process and obtain the backtracking data.

2. The fault analysis method for rail transit systems according to claim 1, characterized in that, Based on the aforementioned business scenario data, the structural topology of the rail transit system is established, including: A visualization program is invoked and run to extract rail transit equipment data from the business scenario data; the visualization program is used to display a visualization interface; in response to operation instructions, the rail transit equipment data is correlated and organized in the visualization interface to establish the structural topology; or... Structured and unstructured data are determined from the business scenario data; data extraction is performed on the structured data to obtain entity data and relationship data; entity data is extracted from the unstructured data using a named entity recognition model; and relationship data between the entity data is parsed using a relationship extraction model; the entity data is converted into node features, and the relationship data is converted into edge features; the entity data and the relationship data are processed through a graph neural network to generate the structural topology relationship.

3. The fault analysis method for rail transit systems according to claim 1, characterized in that, After identifying the faulty device based on the acquired fault information, the method further includes: Determine whether the faulty device is within the coverage area of ​​the structural topology; When the faulty device is within the coverage area of ​​the aforementioned structural topology, its location is determined to be a professional junction. When the faulty device is not within the coverage area of ​​the structural topology, it is determined that the location of the faulty device is not a professional junction.

4. The fault analysis method for rail transit systems according to claim 1, characterized in that, The backtracking data is analyzed together with preset abnormal data to obtain the target fault result, including: Obtain the target anomaly data corresponding to the backtracking data from the preset anomaly data; According to the preset configuration rules, the backtracking data is compared with the target abnormal data; The target fault result is obtained by analyzing the inconsistent backtracking data.

5. A fault analysis device for a rail transit system, characterized in that, This invention relates to a vehicle departure scenario in rail transit. In this scenario, the rail transit system comprises multiple specialized departments, including the electromechanical department, the signaling department, and the vehicle department. The electromechanical department is responsible for platform screen doors, which are used to ensure platform safety isolation. The signaling department is responsible for interlocking devices, which are used to ensure train operation safety and control signal transmission. The vehicle department is responsible for train doors, which are used to provide passenger boarding and alighting access. The rail transit system fault analysis device includes: A construction module is used to acquire business scenario data and build a cross-disciplinary fault analysis model based on the business scenario data; the cross-disciplinary fault analysis model is used to characterize the correlation, interaction signals, and transmission paths between multiple devices in different professional departments of the rail transit system; the business scenario data includes data on the entire lifecycle of the vehicle departure scenario; The determination module is used to establish a sensing data access channel and determine the faulty device based on the acquired fault information; The acquisition module is used to acquire monitoring data of the faulty device and related devices through the sensing data access channel when the location of the faulty device is a professional junction; the professional junction refers to the intersection of the various different professional departments. The fault simulation module is used to simulate the entire fault process corresponding to the fault information based on the monitoring data and the cross-disciplinary fault analysis model to obtain retrospective data. The result determination module is used to analyze the backtracking data and preset abnormal data to obtain the target fault result; The building module is specifically used for: Based on the business scenario data, the track data of different professional departments are integrated in a unified manner to establish the structural topology of the rail transit system; the structural topology is used to characterize the connection relationship and layout of multiple devices in various professional departments of the rail transit system. Based on the structural topology, the interaction rules between the devices are obtained; the interaction rules include at least one of the following: signal interaction rules, interaction triggering rules, and interaction verification rules. The interaction rules are combined to obtain a set of rules between the devices; The structural topology and the rule set are embedded as configuration parameters into a preset model to construct the cross-disciplinary fault analysis model. The preset model is a pre-established algorithm framework. The structural topology is input into the preset model in the form of a graph structure. The rule set is transformed into the constraints and calculation logic of the preset model to guide the model to analyze and predict the interaction behavior of the equipment. The fault simulation module is specifically used for: The monitoring data is time-synchronized to obtain time-synchronized monitoring data; The logical relationship between the faulty device and the associated device is obtained through the cross-disciplinary fault analysis model; the logical relationship includes a preceding logical relationship and / or a following logical relationship. Based on the aforementioned logical relationship, the time-corrected data is arranged in a chronological order to simulate the fault process and obtain the backtracking data.

6. 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 fault analysis method for a rail transit system according to any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements a fault analysis method for a rail transit system according to any one of claims 1-4.

Images