Rail transit system fault analysis method, device and equipment and storage medium
The method constructs a cross-professional fault analysis model to integrate data across rail transportation system domains, enhancing fault recognition accuracy by providing a unified platform for comprehensive fault analysis and root cause identification.
Patent Information
- Application Number
- CN202510803444.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-17
- Publication Date
- 2025-07-15
- Estimated Expiration
- 2045-06-17
AI Technical Summary
The existing technology lacks a global perspective in fault analysis in various professional fields in rail transit systems, resulting in low accuracy in fault identification and easy to miss key information and repeated analysis.
Build a cross-professional fault analysis model, establish structural topological relationships and interaction rules by obtaining business scenario data, establish a perceived data access channel, obtain monitoring data of fault equipment, and simulate the fault process through the cross-professional fault analysis model, obtain backtracking data for analysis.
The data traceability of the entire process of rail transit system faults is realized, the accuracy and efficiency of fault identification is improved, the root cause of faults can be quickly located, the human misjudgment is reduced, and the consistency of fault handling is ensured.
Smart Images

Figure CN120316451A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of fault identification, and particularly to a method, device, equipment and storage medium for fault analysis of a rail transit system. Background Technique
[0002] As a core component of modern urban public transportation, rail transit effectively alleviates urban traffic congestion problems and provides great convenience for residents' daily travel with its significant advantages such as large passenger capacity, high efficiency, and punctuality. However, the rail transit system covers multiple complex and interrelated professional fields such as vehicles, communication signals, power supply systems, and electromechanical equipment. The high degree of integration and comprehensiveness of the system make it extremely vulnerable to various cross-professional faults during operation. These faults are often caused by the superposition of multiple factors, and the relationship between fault phenomena and their roots 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 each professional field, enabling each fault diagnosis system to obtain operation data and analyze and process the operation data to identify the type of fault. However, since the subsystems of each professional field operate independently, this solution performs fault analysis based on single-device data processing and analysis, lacking a global perspective and being extremely prone to missing key information. It may also result in the same data being analyzed multiple times, making the analysis results relatively single and one-sided, leading to a low accuracy of fault identification. Summary of the Invention
[0004] The purpose of the present application is to provide a method, device, equipment and storage medium for fault analysis of a rail transit system.
[0005] To achieve the above purpose, the present application provides the following solutions: In a first aspect, the present application provides a method for fault analysis of a rail transit system, including: Obtaining 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 association relationships, interaction signals, and transmission paths among multiple devices in different professional departments of the rail transit system; Establishing a perception data access channel and determining a faulty device based on the obtained fault information; When the location where the faulty device belongs is a professional interface, obtaining the monitoring data of the faulty device and associated devices through the perception data access channel; the professional interface refers to the intersection location of different professional departments; Based on the monitoring data and the cross-professional fault analysis model, simulating the entire fault process corresponding to the fault information to obtain retrospective data; Analyze the backtracking data and preset abnormal data to obtain the target fault result.
[0006] Optionally, construct a cross - professional fault analysis model based on the service scenario data, including: Based on the service 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 mode among multiple devices in different professional departments of the rail transit system; According to the structural topology relationship, obtain the interaction rules between the devices; the interaction rules include at least one of the following: signal interaction rules, interaction trigger rules, and interaction verification rules; Perform combined processing on the interaction rules to obtain the rule set between the devices; Embed the structural topology relationship and the rule set as configuration parameters into a preset model to construct the cross - professional fault analysis model.
[0007] Optionally, based on the service scenario data, establish the structural topology relationship of the rail transit system, including: Call and run a visualization program to extract rail transit equipment data from the service scenario data; the visualization program is used to display a visualization interface; In response to an operation instruction, associate and organize the rail transit equipment data in the visualization interface to establish the structural topology relationship.
[0008] Optionally, after determining the faulty device based on the obtained fault information, the method further includes: Judge whether the faulty device is within the coverage of the structural topology relationship; When it is within the coverage of the structural topology relationship, determine that the location where the faulty device belongs is the professional combination part; When it is not within the coverage of the structural topology relationship, determine that the location where the faulty device belongs is not the professional combination part.
[0009] Optionally, based on the monitoring data and the cross - professional fault analysis model, simulate the entire fault process corresponding to the fault information to obtain backtracking data, including: Perform time calibration processing on the monitoring data to obtain time - calibrated monitoring data; According to the time - calibrated monitoring data, perform fault process simulation through the cross - professional fault analysis model to obtain backtracking data.
[0010] Optionally, according to the time - calibrated monitoring data, perform fault process simulation through the cross - professional fault analysis model to obtain backtracking data, including: Obtain the logical relationship between the faulty device and the associated devices through a cross - professional fault analysis model; the logical relationship includes a pre - logical relationship and / or a post - logical relationship; Based on the logical relationship, arrange the time - calibrated data in a time - series manner to simulate the fault process and obtain the retrospective data.
[0011] Optionally, analyze the retrospective data and preset abnormal data to obtain a target fault result, including: Obtain the target abnormal data corresponding to the retrospective data from the preset abnormal data; Compare the retrospective data with the target abnormal data according to the preset configuration rules; Analyze the retrospective data with inconsistent comparison results to obtain the target fault result.
[0012] In a second aspect, the present application provides a rail transit system fault analysis device, including: A construction module, configured to 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 represent the association relationship, interaction signals, and transmission paths among multiple devices in different professional departments of the rail transit system; A determination module, configured to establish a perception data access channel and determine a faulty device based on the obtained fault information; An acquisition module, configured to obtain the monitoring data of the faulty device and associated devices through the perception data access channel when the location of the faulty device is at the professional interface; the professional interface refers to the intersection location of different professional departments; A fault simulation module, configured to simulate the entire fault process corresponding to the fault information based on the monitoring data and the cross - professional fault analysis model to obtain retrospective data; A result determination module, configured to analyze the retrospective data and preset abnormal data to obtain a target fault result.
[0013] In a third aspect, the present application provides a computer device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, where 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.
[0014] In a fourth aspect, the present application provides a computer - readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the rail transit system fault analysis method described in any one of the above are implemented.
[0015] According to the specific embodiments provided in this application, the following technical effects are disclosed in this application: This application provides a method, device, equipment and storage medium for fault analysis of a rail transit system. By obtaining service scenario data, constructing a cross-professional fault analysis model based on the service scenario data, establishing a perception data access channel, and determining a faulty device based on the obtained fault information. When the location of the faulty device is at the professional junction, the monitoring data of the faulty device and associated devices are obtained through the perception 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 to obtain retrospective data, and the retrospective data is analyzed with preset abnormal data to obtain the target fault result. Compared with the prior art, on the one hand, through constructing a professional fault analysis model, this solution can break the information silos between different professional departments, present the connections between devices in different professional departments as a whole, provide a more comprehensive perspective for fault analysis, determine the faulty device through the fault information, provide a clear target for subsequent fault analysis, and establish a perception data access channel to ensure timely acquisition of device data related to the fault, providing data support for fault identification; on the other hand, for fault scenarios across multiple professions, it can comprehensively obtain the monitoring data of relevant devices, comprehensively consider the information of other professional departments, and through combining the monitoring data and the cross-professional fault analysis model, realize data traceability of the entire fault process, thus more clearly reproducing the fault occurrence process, facilitating more accurate judgment of the root cause of the fault, and then through analyzing the retrospective data with preset abnormal data, it can quickly and accurately determine the target fault result, improving the accuracy of fault identification. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] In order to more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following will briefly introduce the drawings required to be used in the embodiments. Obviously, the drawings in the following description are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0017] Figure 1 It is a schematic structural diagram of a rail transit system fault analysis system in an embodiment of this application; Figure 2 It is a schematic flow diagram of a method for fault analysis of a rail transit system provided in an embodiment of this application; Figure 3 It is a schematic flow diagram of a method for constructing a cross-professional fault analysis model based on service scenario data provided in an embodiment of this application; Figure 4 It is a schematic flow diagram of a method for simulating a fault process to obtain retrospective data provided in an embodiment of this application; Figure 5Schematic flowchart of the rail transit system fault analysis method provided by another embodiment of the present application; Figure 6 Schematic diagram of the functional modules of a rail transit system fault analysis device provided by an embodiment of the present application; Figure 7 Schematic diagram of the structure of a computer device provided by an embodiment of the present application. Detailed implementation manners
[0018] Next, the technical solutions in the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.
[0019] To make the above objects, features, and advantages of the present application more obvious and understandable, the present application will be further described in detail below with reference to the accompanying drawings and specific implementation manners. The following are the explanations of relevant terms: Professional interface: It refers to the part where there is an intersection or connection between different professional departments. In the rail transit industry, each department can include: vehicles, signaling, power supply, electromechanics, etc. The professional interface includes the intersection parts between multiple professional departments such as vehicles, signaling, power supply, and electromechanics.
[0020] Equipment structure topology: In the entire system or network, the way of connection and arrangement form between each device. It is used to describe the physical connection or logical relationship between each device.
[0021] Data traceback: It refers to the process of tracking and analyzing past situations or events through historical data.
[0022] Root cause analysis: It is a systematic method used to identify the root cause of a problem and prevent the problem from occurring again. Its purpose is to find out the deepest cause that leads to the problem, rather than just solving the surface symptoms. Root cause analysis is usually used in fields such as quality improvement, accident investigation, and fault troubleshooting.
[0023] In the related art, the status of devices is monitored in real time by sensors deployed in subsystems of various professional fields, and operation data is collected. Then, the fault diagnosis system processes the collected data and uses methods such as statistical analysis and simulation recognition to identify abnormal conditions of individual devices, and then obtains the fault type. However, since the fault diagnosis systems of each specialty operate independently and their data is not shared, the problem of data islands is caused. When a fault crosses multiple professional departments, it is extremely easy to miss key information due to the lack of a global perspective. And because there is no unified platform to coordinate the diagnostic work of different professional departments, the same data may be analyzed multiple times, increasing the workload and possibly causing conflicts due to different analysis results. At the same time, the fault diagnosis system for a single specialty may not be able to comprehensively consider the influence of other specialties, resulting in a low accuracy of fault identification.
[0024] Based on the above defects, the present application provides a fault analysis method for a rail transit system. Compared with the prior art, on the one hand, by constructing a professional fault analysis model, this solution can break the information islands between professional departments, present the connections between devices in different professional departments as a whole, provide a more comprehensive perspective for fault analysis, determine the faulty device through fault information, provide a clear target for subsequent fault analysis, and establish a perception data access channel to ensure timely acquisition of device 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 obtain the monitoring data of relevant devices, comprehensively consider the information of other professional departments, and through combining the monitoring data and the cross-professional fault analysis model, realize data traceability of the entire fault process, so as to more clearly reproduce the fault occurrence process, facilitate more accurate judgment of the root cause of the fault, and then through analyzing the traced-back data and the preset abnormal data, it can quickly and accurately determine the target fault result, improving the accuracy of fault identification.
[0025] A fault analysis method for a rail transit system provided by an embodiment of the present application can be applied to, for example Figure 1The rail transit system fault analysis system shown in the figure. The rail transit system fault analysis system includes: a terminal 102, a server 104, and a data storage system. Among them, the terminal 102 communicates with the server 104 through a network. The data storage system can store the data that the server 104 needs to process. The data storage system can be set separately, integrated on the server 104, placed on the cloud or other servers. The terminal 102 can send the obtained business scenario data to the server 104. After receiving the business scenario data, the server 104 constructs a cross-professional fault analysis model and performs a root cause analysis of the fault to obtain the target fault result. In addition, in some embodiments, the rail transit system fault analysis method can also be implemented separately by the server 104 or the terminal 102. For example, the terminal 102 can directly construct a cross-professional fault analysis model based on the obtained business scenario data and perform a root cause analysis of the fault to obtain the target fault result. Among them, signal interaction rules, device exception libraries, etc. can be pre-stored in the terminal 102 to facilitate the fault analysis of the rail transit system.
[0026] Among them, the terminal 102 can be, but is not limited to, various desktop computers, laptop computers, smart phones, tablet computers, Internet of Things devices, and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. The portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The server 104 can be implemented by an independent server or a server cluster composed of multiple servers, and can also be a cloud server.
[0027] In an exemplary embodiment, as Figure 2 shown, a rail transit system fault analysis method is provided. This method is executed by a computer device, and can be specifically executed by a computer device such as a terminal or a server alone, or jointly executed by a terminal and a server. In the embodiments of the present application, taking this method applied to Figure 1 the server 104 in it as an example for illustration, it includes the following steps S201 to step S205. Among them: 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 represent the association relationship, interaction signals, and transmission paths among multiple devices in different professional departments of the rail transit system.
[0028] It should be noted that the above-mentioned business scenario refers to the scenario corresponding to the rail transit industry, and a cross-professional fault analysis model can be constructed for each different business scenario. The business scenario can be, for example, a train operation dispatching scenario, a station operation scenario, an interval operation scenario, etc. The business scenario data refers to the data covering the entire life cycle of the entire business scenario of the rail transit.
[0029] The above business scenario data can be obtained from a database or a blockchain, imported from external devices, or obtained after sending a request to other systems. This embodiment does not impose any restrictions on the acquisition method of the business scenario data.
[0030] After obtaining the business scenario data, the business scenario data can be analyzed to extract the rail transit equipment data corresponding to the business scenario from the business scenario data, and then the correlation relationship of the rail transit equipment data can be analyzed to construct a cross-professional fault analysis model.
[0031] In another exemplary embodiment of the present application, in order to simulate and trace back the entire fault process, it is necessary to construct a cross-professional fault analysis model, as Figure 3 shown. The method includes the following steps S301 to S304: Step S301, based on the business scenario data, establish the structural topology relationship of the rail transit system; the structural topology relationship is used to represent the connection relationship and layout mode among multiple devices in different professional departments of the rail transit system.
[0032] Step S302, according to the structural topology relationship, obtain the interaction rules between devices; the interaction rules include at least one of the following: signal interaction rules, interaction trigger rules, and interaction verification rules.
[0033] Step S303, perform a combination process on the interaction rules to obtain a rule set between devices.
[0034] Step S304, embed the structural topology relationship and the rule set as configuration parameters into a preset model to construct a cross-professional fault analysis model.
[0035] As an implementable method, after obtaining the business scenario data, the business scenario data can be analyzed to establish the structural topology relationship of the rail transit system, and the rail transit equipment data can be extracted from the business scenario data by calling and running a visualization program; the visualization program is used to display a visualization interface; in response to an operation instruction, the rail transit equipment data is associated and sorted out in the visualization interface to establish a structural topology relationship.
[0036] Among them, the rail transit equipment data includes multiple device information, and the device information may include information such as device name, device manufacturer, device identifier, and device attributes. First, the rail transit equipment data is extracted from the business scenario data, and then the visualization program is called to run the visualization program, so that a visualization interface is presented on the computer device. The user can operate on the visualization interface, so that the computer device receives the operation instruction of the user from the visualization interface, and performs corresponding operations on the rail transit equipment data on the visualization interface, thereby establishing the structural topology relationship of the cross-professional department of the business scenario.
[0037] Exemplarily, for the scenario of a vehicle leaving a station in rail transit, assume that the fault information is that the platform screen door fails, causing the doors to not close, resulting in the vehicle being unable to leave the station. In this business scenario, the rail transit system may include multiple professional departments, such as the mechanical and electrical professional department, the signal professional department, and the vehicle professional department. The business scenario data may be data including the entire life cycle of the vehicle leaving the station scenario. First, call and run the visualization program, and extract rail transit equipment data from the business scenario data, which may include data of the mechanical and electrical professional department, the signal professional department, and the vehicle professional department, etc. Among them, the rail equipment involved in the mechanical and electrical professional department is the platform screen door, which is responsible for functions such as platform safety isolation; the rail equipment involved in the signal professional department is the interlocking equipment, which is responsible for ensuring train operation safety and controlling signal transmission, etc.; the rail equipment involved in the vehicle professional department is the vehicle door, which provides the access for passengers to get on and off the vehicle. Integrate the rail equipment of these different professional departments, and then the user can click on different controls on the visualization interface, such as clicking, dragging, and sliding the controls, so that in response to the user's operation instructions, the various devices are displayed on the visualization interface in an intuitive way such as graphics and lines to show the device connections and interaction relationships, thereby establishing the cross-professional structural topology relationship of this vehicle leaving the station scenario.
[0038] In this embodiment, the limitations under a single professional perspective are avoided. By establishing the structural topology relationship of the rail transit system based on the business scenario data, the association situations between different devices of each professional department can be comprehensively integrated, which is convenient for subsequent triggering from a global perspective and comprehensively considering the mutual influences between different professional fields, thereby providing a more comprehensive and accurate fault analysis and helping to discover and solve deep-seated fault problems spanning multiple professions.
[0039] As another implementable way, in the process of establishing the structural topology relationship of the rail transit system, since the business scenario data may come from different data sources, such as equipment ledgers, line parameter tables, equipment manuals, maintenance manuals, text reports, etc., after obtaining the business scenario data, structured data (equipment ledgers, line parameter tables) and unstructured data (equipment manuals, maintenance manuals, text reports) can be first determined from the business scenario data, and then entity data, which may include lines, equipment, stations, etc., can be directly extracted from the structured data, and relationship data, including the attribution relationship between equipment and lines, the adjacency relationship between stations, and the relationship between stations and lines, can be obtained through surface association fields. Then, entity information is extracted from the unstructured data through a named entity recognition model. For example, "Signal system failure on Line 3, involving Signal Machine S15" is recognized from the maintenance log, and the association between entities in the text is parsed through a relationship extraction model. For example, it is inferred from the construction report that "Equipment A is connected to Equipment B by a cable" (physical connection relationship).
[0040] The above entity recognition model has the ability to extract entity data, and the above relation extraction model has the ability to extract relation data. The graph neural network is pre-established to perform graph processing on entity data and relation data and has the ability to establish structural topological relations. After obtaining entity data and relation data for both structured and unstructured data, all the entity data and relation data can be input into the pre-established graph neural network, and the graph neural network is used to classify the entity data and relation data respectively to obtain physical entities, logical entities, physical connections, logical associations, spatial adjacencies, etc. For example, physical entities include: lines, stations, sections, and devices; logical entities include: systems (such as signal systems, power supply systems, vehicle systems), sub-networks (such as communication subnets); physical connections include: devices installed on lines / stations / sections; logical associations include adjacent stations, series-connected sections, etc., and all data is associated and sorted to obtain the structural topological relation.
[0041] It can be understood that in the rail transit system, different rail transit devices correspond to different interaction rules, and the signal interaction rules determine the format, content, and path of information transmission between devices. For example, between the signal machine in the signal professional department and the train in the vehicle professional department, the signal machine sends signals such as speed limits and route openings to the train through specific codes, and the train parses the signals after receiving them and performs corresponding operations. The signal interaction rules need to clarify the signal format, transmission frequency, coding method, signal strength requirements, etc.
[0042] After establishing the structural topological relation, obtaining the interaction rules between various devices can be to obtain the manufacturer information of each device and obtain the signal interaction rules of each device from the manufacturer information, or to obtain the signal interaction rules of each device according to experience information, or to obtain them through import from external devices.
[0043] For example, in the scenario of the platform screen door failure when the vehicle departs from the station, the signal logic of the interaction between the platform screen door and the signal system when the vehicle is about to depart from the station, and the interaction logics between devices of different manufacturers are slightly different, and specific rules need to be customized for each real scenario.
[0044] It should be noted that the interaction trigger rule is used to characterize the conditions for the occurrence of interaction behaviors between devices. For the braking system and the traction system of a train, when the train receives a stop instruction, detects an obstacle ahead, or exceeds the speed limit, the braking system will trigger an interaction with the traction system, causing the traction system to reduce power or stop working, and at the same time, the braking system starts braking. These trigger conditions can be based on various factors such as time, events, and state changes, and precise thresholds and judgment logics need to be set to ensure the timeliness and accuracy of the interaction.
[0045] The interactive verification rules are used to ensure the reliability of device interaction. Taking the power supply system and the catenary equipment as an example, when the power supply system supplies power to the catenary, it is necessary to perform real-time verification on parameters such as voltage, current, and phase. If it is detected that the parameters exceed 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. The interactive verification rules also include data integrity verification, protocol consistency verification, etc., to ensure the stability and safety of device interaction through various verification mechanisms.
[0046] The various obtained interactive rules are systematically combined to form a rule set between devices. During the combination process, the rules are first classified and sorted out to clarify the associations and priorities between different types of rules. For example, the signal interaction rules are the basis, and the interaction trigger rules are based on the results of signal interaction to initiate corresponding operations. The interactive verification rules run through the entire interaction process to supervise and verify the former two.
[0047] After obtaining the rule set, the structural topology relationship and the rule set are embedded into a preset model to construct a cross-professional fault analysis model. The preset model can be a pre-established algorithm framework. The structural topology relationship is input into the preset model in the form of a graph structure, where nodes represent devices and edges represent the connection relationships between devices; the rule set is then transformed into the constraint conditions and calculation logic of the preset model, which are used to guide the model to analyze and predict the device interaction behavior, thereby constructing a cross-professional fault analysis model.
[0048] In this embodiment, by combining and processing the interactive rules, a comprehensive, orderly, and efficient rule set can be sorted out, providing good data guidance information for signal interaction between devices; and comprehensively considering the structural topology relationship and the rule set, and embedding them into the preset model as configuration parameters, thereby establishing a unified data platform or database, that is, a cross-professional fault analysis model. The cross-professional fault analysis model can realize data sharing between different specialties, which means that data from multiple systems such as vehicles, signals, communications, and power supplies can be centrally managed and analyzed uniformly, thereby improving the accuracy and efficiency of fault identification.
[0049] Step S202, establish a perception data access channel and determine the faulty device based on the obtained fault information.
[0050] It should be noted that the above-mentioned perception data access channel refers to the data transmission interfaces of each different professional department. For example, in the case of the shield door failure scenario when a vehicle leaves the station, perception monitoring points (data transmission interfaces) can be set on the shield door, signal system, doors, etc., so that computer devices can obtain data such as the opening and closing status data of the shield door itself, the signal sending status data of the interaction with the signal system, the vehicle status data monitored by the signal system, and the door status data.
[0051] After establishing a sensing data access channel for each device, fault information is obtained. This fault information can be sent to the computer device when an abnormality is detected in the device, can be pushed from an external device to the computer device, or can be manually input into the computer device.
[0052] After obtaining the fault information, the fault information can be analyzed to preliminarily determine the current faulty device. For example, when the obtained fault information is "the platform screen door cannot be opened", the current faulty device is determined to be the "platform screen door", and it is necessary to further determine whether the most fundamental cause of the fault belongs to the faults of other professional departments.
[0053] In this embodiment, by determining the faulty device based on the obtained fault information, the cause of the fault can be preliminarily determined, providing good data guidance information for subsequent cross-professional department fault analysis and facilitating a more in-depth search for the root cause of the fault.
[0054] Step S203, when the location of the faulty device is at the professional junction, obtain the monitoring data of the faulty device and associated devices through the sensing data access channel; the professional junction refers to the intersection location of different professional departments.
[0055] Among them, the monitoring data of the above-mentioned faulty device and associated devices refers to the data obtained by monitoring the rail transit system in real time. For example, when the faulty device is a switch machine and the associated device is a track circuit device, the monitoring data corresponding to the faulty device may include: current data, voltage data, and action time data, and the monitoring data corresponding to the track circuit device may include: track circuit voltage data, frequency data, and train occupancy information data.
[0056] After determining the faulty device based on the obtained device information, the method further includes: Judge whether the faulty device is within the coverage of the structural topology relationship; when it is within the coverage of the structural topology relationship, determine that the location of the faulty device is at the professional junction; when it is not within the coverage of the structural topology relationship, determine that the location of the faulty device is not at the professional junction.
[0057] In this embodiment, after determining the faulty device, it is necessary to further determine whether the location of the faulty device is at the professional junction, that is, to further determine whether it is within the coverage of the structural topology relationship. The structural topology relationship, as the "digital map" of the various device architectures across professional departments, clearly marks the connection relationships and hierarchical structures between devices. It is possible to determine whether the location of the faulty device is at the professional junction by checking whether the faulty device is within the coverage of the structural topology relationship. For example, in the combined area of the power supply system and the catenary, if an abnormal catenary voltage is detected, first, find the catenary equipment node in the structural topology diagram of the power supply system through the equipment number or physical location. If the node exists in the structural topology relationship and there are connected edges with power supply equipment (such as traction substations and feeder switches), it can be determined that the faulty equipment is within the coverage of the structural topology relationship, and then its location can be determined as the professional interface; conversely, if the corresponding node cannot be found in the structural topology diagrams of any professional, it can be determined that the location of the faulty equipment is not the professional interface. It can be understood that the fault diagnosis of professional interfaces faces difficulties such as complex equipment interaction and fuzzy responsibility definition. For example, when a fault occurs at the interface between the train operation control system and the communication system, it may involve multiple factors such as on-vehicle equipment, trackside base stations, and communication protocols. At this time, it is necessary to deeply analyze the monitoring data of the faulty equipment and related equipment by combining the structural topology relationship and rule set in the cross-professional fault analysis model. Therefore, the monitoring data of the faulty equipment and related equipment are obtained through the data access channel. In this embodiment, when the location of the faulty equipment is the professional interface, the monitoring data of the faulty equipment and related equipment are obtained through the sensing data access channel, providing data support for subsequent fault process simulation, facilitating accurate positioning of the fault root cause, and realizing cross-professional collaborative fault diagnosis and processing.
[0058] Step S204, based on the monitoring data and the cross-professional fault analysis model, simulate the entire fault process corresponding to the fault information to obtain retrospective data.
[0059] It can be understood that in the rail transit system, the equipment of each different professional department is widely distributed and provided by different manufacturers. Due to factors such as the difference in hardware clock accuracy, network transmission delay, and system time setting deviation, the timestamps of the data collected by each device often have different degrees of errors. For example, the data collection times of on-vehicle sensors and trackside signal devices may be inconsistent. If no time calibration is performed, it will lead to time misalignment during data analysis and the true sequence and causal relationship of the fault occurrence cannot be accurately restored. In this embodiment, by performing time calibration on the monitoring data, the time reference of each monitoring data can be unified, ensuring the consistency and accuracy of the data in the time dimension and providing a reliable data basis for subsequent fault analysis. In the process, in another exemplary embodiment of the present application, in order to accurately determine the target fault result, it is necessary to simulate the entire fault process corresponding to the fault information, as Figure 4 shown, the method includes the following steps S401 to step S402: Step S401, perform time calibration on the monitoring data to obtain the time-calibrated monitoring data.
[0060] Step S402: Simulate the fault process based on the time-calibrated monitoring data through a cross-professional fault analysis model to obtain retrospective data.
[0061] Specifically, first select a high-precision, stable and reliable time source as the time-calibration reference, such as the time signal provided by the Global Positioning System (GPS) or the Beidou Satellite Navigation System. These satellite time signals have nanosecond-level precision and can meet the high-precision requirements for calibrating rail transit monitoring data. A master clock server can be set up in the rail transit control center to receive the satellite time signal and synchronize the time to each monitoring device through the network. Then synchronize the time of each device. Each professional device synchronizes its time with the master clock server through the network according to the time synchronization protocol. Common time synchronization protocols include the Network Time Protocol (NTP) and the Precision Time Protocol (PTP). For devices with high requirements for time precision, such as the signal system and the train control system, the PTP protocol can be used to achieve sub-microsecond-level time synchronization precision; while for general professional devices, the NTP protocol can be used. Each device can periodically calibrate its time with the master clock server during operation to ensure the accuracy of the time. During the data acquisition process, add an accurate timestamp to each monitoring data. For the data with an error timestamp that has already been collected, correct it according to the time deviation between the device and the master clock server to obtain the time-calibrated monitoring data. For example, if the time of a vehicle-mounted sensor is 500 milliseconds slower than the master clock, then uniformly add 500 milliseconds to the timestamp of the data collected by this sensor to obtain the time-calibrated monitoring data.
[0062] The time-calibration logic in this step determines the time difference between devices by the delay situation of the perception data of the same event by both devices, and is used to calibrate the time of the perception data related to this fault.
[0063] As an implementation method, during the process of simulating the fault process through a cross-professional fault analysis model, it can be to obtain the pre-logical relationship and / or post-logical relationship between the faulty device and the associated devices through the cross-professional fault analysis model, and arrange the time-calibrated data in chronological order based on the pre-logical relationship and / or post-logical relationship to perform the fault process simulation and obtain the retrospective data.
[0064] In this embodiment, during the fault simulation process, the cross-professional fault analysis model dynamically deduces the time sequence of the time-calibrated monitoring data based on the logical relationship between devices.
[0065] Specifically, starting from the critical event nodes, the cross-professional fault analysis model reversely traces the evolution of the device state before the fault occurs based on the pre-set logical relationships. For example, when a simulation signal system fails, if it is found that the train overspeed protection (ATP) device issues an emergency braking command, the model will, according to the pre-set logical relationships, retrieve the data of on-vehicle speed sensors, the speed limit information of track circuits, etc., simulate the speed monitoring and command generation process, and determine whether the braking command is triggered due to abnormal speed. And perform post-logical propagation simulation: Based on the post-logical relationships, the model forwards the impact diffusion path after the fault occurs. For example, in the simulation of a short-circuit fault in the power supply system, when the output voltage of the traction substation drops suddenly, the model, according to the post-logical relationships, analyzes in sequence the voltage drop amplitude of the catenary, the action time of the pantograph protection device on the train, and the cascading reaction of on-vehicle electrical equipment failures, and simulates the propagation trajectory of the fault in the system by calculating the signal transmission delay and response threshold between devices.
[0066] During the fault simulation process, the time sequence logic of the data is strictly followed, and the time window and delay parameters are set. If the response time of a certain device exceeds the threshold range specified by the logical relationship, the model automatically marks it as abnormal and re-evaluates the fault development path. For example, in the door control system, if the door drive motor does not start within the specified time after receiving the closing command, the model regards this as abnormal, adjusts the subsequent simulation process, and checks for faults in the motor control circuit or drive module.
[0067] After the fault process simulation is completed, the cross-professional fault analysis model generates comprehensive retrospective data according to the logical relationships and the simulation process. The retrospective data is presented in layers with the time axis as the main line and combined with the device logical relationships. Among them, the retrospective data can include detailed information such as the time and location of the fault occurrence, the fault propagation path, the state changes of each device during the fault process, and the evolution of relevant parameters. The retrospective data can be stored in a structured form for maintenance personnel to consult and analyze, helping them deeply understand the whole process of the fault occurrence and formulate targeted maintenance and preventive measures. In this embodiment, through the cross-professional fault analysis model, it is possible to more realistically restore the whole process before and after the occurrence of the fault information, thereby obtaining more comprehensive retrospective data, enabling technicians from different specialties to communicate and collaborate more easily, realizing cross-professional collaborative fault identification and handling, which 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 resume normal operation.
[0068] Step S205: Analyze the retrospective data and the preset abnormal data to obtain the target fault result.
[0069] After obtaining the backtracking data, logical verification can be performed on the generated backtracking data, so as to conduct root cause analysis on the fault information and obtain the target fault result. Among them, the target fault result refers to the root cause of the cross-professional department that causes the fault information.
[0070] Among them, in the process of analyzing the backtracking data and the preset abnormal data to obtain the target fault result, the target abnormal data corresponding to the backtracking data can be obtained from the preset abnormal data; according to the preset configuration rules, the backtracking data and the target abnormal data are compared; the backtracking data with inconsistent comparison results is analyzed to obtain the target fault result.
[0071] For example, in the rail transit system, the target abnormal data is the abnormal emergency braking data that occurs during the train operation. The preset configuration rules may include: ① If the rate of speed change exceeds the normal range when the emergency braking occurs (for example, the rate of speed change during normal braking is -1m / s² to -3m / s², and the set threshold for abnormality is less than -5m / s²), it is determined as abnormal braking. ② Check whether there are preconditions such as abnormal track circuits and signal system failures before the braking command is issued. ③ Check whether the working state data of each braking device (such as brake pads, braking motors, etc.) is normal during the braking process. The backtracking data may include detailed records of the train speed change, the sending time and source of the braking command, and the operating parameters of each braking device (such as pressure, current, etc.).
[0072] After comparing the backtracking data with the target abnormal data, it is found that the rate of speed change during the train emergency braking reaches -6m / s², exceeding the normal range, and meets the abnormal determination condition in Rule ①. The backtracking data shows that there is an instantaneous short circuit in the track circuit before the braking command is issued, which is consistent with the check of the preconditions in Rule ②, and it may be that the track circuit failure causes the signal system to misissue the braking command. During the braking process, the pressure data of the brake pads shows abnormal fluctuations, indicating that the working state of the braking device is unstable during the braking process, which meets the check of the working state of the braking device in Rule ③.
[0073] It should be noted that the abnormal causes of historical data are sorted out in advance and configured in the device exception library. Specifically, after obtaining the retrospective data, each retrospective data is analyzed one by one. For the current retrospective data, the target abnormal data corresponding to the current retrospective data is obtained from the device exception library. The target abnormal data corresponding to the current retrospective data refers to the abnormal data generated by the same device as the current retrospective data in the device exception library. If the current retrospective data is consistent with the target abnormal data, it indicates that the current retrospective data is correct; if the current retrospective data is inconsistent with the target abnormal data, it indicates that the current retrospective data is incorrect, indicating that there is a cross-professional department fault, and then the inconsistent retrospective data is analyzed to obtain the target fault result. The target fault result may include, for example, the target fault device and the target fault cause. The target fault device may refer to the associated device related to the faulty device, and the target fault cause may be the abnormal state value corresponding to the associated device. For example, when the faulty device corresponding to the fault information is device a, after simulating the fault process through the cross-professional fault analysis model, the target fault result obtained may be that device b associated with device a has an abnormality.
[0074] Exemplarily, please refer to Figure 5 As shown, in the process of root cause analysis for a specific business scenario, the structural topology relationship between devices of different professional departments can be constructed based on the business scenario data, and the interaction rules between devices (signal interaction rules, interaction trigger rules, interaction verification rules) can be obtained. Then, a perception data access channel is established, and according to the structural topology relationship and interaction rules, a cross-professional fault analysis model is constructed. When an abnormality occurs in a device, the fault information is obtained, the faulty device is determined based on the obtained fault information, and then it is judged whether the location of the faulty device is a professional junction. When the location of the faulty device is not a professional junction, it is a non-cross-professional fault, and the analysis ends.
[0075] When the location of the faulty device is a professional junction, the monitoring data of the faulty device and the associated device are obtained, and then the monitoring data is time-calibrated to obtain the time-calibrated monitoring data, and the logical relationship between the faulty device and the associated device is obtained; the logical relationship includes a pre-logical relationship and / or a post-logical relationship; based on the logical relationship, the time-calibrated data is arranged in a time sequence manner to simulate the fault process and obtain the retrospective data. The target abnormal data corresponding to the retrospective data is obtained from the preset device exception library, and the retrospective data is compared with the target abnormal data according to the preset configuration rules; the inconsistent retrospective data is analyzed to obtain the target fault result.
[0076] Furthermore, after determining the target fault result, it can be corrected in a timely manner to enable the rail transit system to resume normal operation.
[0077] In this embodiment, by establishing a cross - professional fault analysis model, a standardized process can be constructed, which helps to ensure the consistency of fault handling, reduce misjudgment caused by human factors, and greatly improve the quality of fault handling.
[0078] The present application provides a fault analysis method for a rail transit system. On the one hand, by constructing a professional fault analysis model, the information islands between different professional departments can be broken, the connections between devices in different professional departments can be presented as a whole, providing a more comprehensive perspective for fault analysis. The fault device can be determined through fault information, providing a clear target for subsequent fault analysis, and establishing a perception data access channel to ensure timely acquisition of device data related to the fault, providing data support for fault identification. On the other hand, for the professional interface where cross - professional faults occur frequently, the monitoring data of relevant devices can be comprehensively obtained. By combining the monitoring data and the cross - professional fault analysis model, data traceability of the entire fault process can be realized, so as to more clearly reproduce the fault occurrence process, facilitate more accurate judgment of the root cause of the fault, and then by analyzing the traceback data and preset abnormal data, the target fault result can be quickly and accurately determined, improving the accuracy of fault identification.
[0079] Based on the same inventive concept, the embodiment of the present application also provides a rail transit system fault analysis device for implementing the above - mentioned method. The implementation solutions provided by this device to solve problems are similar to those described in the above - mentioned method. Therefore, the specific limitations in one or more embodiments of the rail transit system fault analysis device provided below can refer to the limitations on the rail transit system fault analysis method in the above text, and will not be repeated here.
[0080] In an exemplary embodiment, as Figure 6 shown, a rail transit system fault analysis device is provided, including: A construction module 510, configured to obtain service scenario data and construct a cross - professional fault analysis model based on the service scenario data; the cross - professional fault analysis model is used to represent the association relationship, interaction signals, and transmission paths among multiple devices in different professional departments of the rail transit system; A determination module 520, configured to establish a perception data access channel and determine a fault device based on the obtained fault information; An acquisition module 530, configured to obtain the monitoring data of the fault device and associated devices through the perception data access channel when the location of the fault device is a professional interface; the professional interface refers to the intersection location of different professional departments; A fault simulation module 540, configured to simulate the entire fault process corresponding to the fault information based on the monitoring data and the cross - professional fault analysis model to obtain traceback data; A result determination module 550 is configured to analyze the backtracking data and preset abnormal data to obtain a target fault result.
[0081] As an alternative implementation, the construction module 510 is specifically configured to: Based on the 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 mode among multiple devices in different professional departments of the rail transit system; According to the structural topology relationship, obtain the interaction rules between devices; the interaction rules include at least one of the following: signal interaction rules, interaction trigger rules, and interaction verification rules; Perform combination processing on the interaction rules to obtain a rule set between devices; Embed the structural topology relationship and the rule set as configuration parameters into a preset model to construct a cross-professional fault analysis model.
[0082] As an alternative implementation, the construction module 510 is further configured to: Call and run a visualization program to extract rail transit equipment data from the business scenario data; the visualization program is used to display a visualization interface; in response to an operation instruction, associate and organize the rail transit equipment data in the visualization interface to establish a structural topology relationship; or, Determine structured data and unstructured data from the business scenario data; perform data extraction on the structured data to obtain entity data and relationship data, and use a named entity recognition model to extract entity data from the unstructured data, and use a relationship extraction model to parse the relationship data between entity data; convert the entity data into node features and the relationship data into edge features respectively; process the entity data and relationship data through a graph neural network to generate a structural topology relationship.
[0083] As an alternative implementation, the above device is further configured to: Determine whether the faulty device is within the coverage of the structural topology relationship; When it is within the coverage of the structural topology relationship, determine that the location of the faulty device is the professional combination part; When it is not within the coverage of the structural topology relationship, determine that the location of the faulty device is not the professional combination part.
[0084] As an alternative implementation, the fault simulation module 540 is specifically configured to: Perform time calibration processing on the monitoring data to obtain time-calibrated monitoring data; Perform fault process simulation through the cross-professional fault analysis model according to the time-calibrated monitoring data to obtain backtracking data.
[0085] As an alternative implementation, the fault simulation module 540 is further configured to: Obtain the logical relationship between the faulty device and the associated devices; the logical relationship includes a pre-logical relationship and / or a post-logical relationship; Based on the logical relationship, arrange the time-calibrated data in a time-sequential manner to simulate the fault process and obtain the retrospective data.
[0086] As an alternative implementation, the result determination module 550 is specifically configured to: Obtain the target abnormal data corresponding to the retrospective data from the preset abnormal data; Compare the retrospective data with the target abnormal data according to the preset configuration rules; Analyze the retrospective data with inconsistent comparison results to obtain the target fault result.
[0087] Among them, for the rail transit system fault analysis device provided in the embodiments of the present application, on the one hand, by constructing a professional fault analysis model, the present solution can break the information silos between different professional departments, present the connections between devices of different professional departments as a whole, provide a more comprehensive perspective for fault analysis, determine the faulty device through the fault information, provide a clear target for subsequent fault analysis, establish a perception data access channel, ensure timely acquisition of device data related to the fault, and provide data support for fault identification; on the other hand, for fault scenarios across multiple professions, it can comprehensively obtain the monitoring data of relevant devices, comprehensively consider the information of other professional departments, and through combining the monitoring data and the cross-professional fault analysis model, realize data traceability of the entire fault process, so as to more clearly reproduce the fault occurrence process, facilitate more accurate judgment of the root cause of the fault, and then through analyzing the retrospective data and the preset abnormal data, it can quickly and accurately determine the target fault result and improve the accuracy of fault identification.
[0088] In an exemplary embodiment, a computer device is provided. The computer device can be a server or a terminal, and its internal structure diagram can be as Figure 7As shown in the figure. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store video tag processing data. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements a method for analyzing rail transit system failures.
[0089] Those skilled in the art can understand that Figure 7 the structure shown in the figure is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.
[0090] In an exemplary embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.
[0091] In an exemplary embodiment, a computer-readable storage medium is provided, storing a computer program, and when the computer program is executed by the processor, the steps in the above method embodiments are implemented.
[0092] In an exemplary embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by the processor, the steps in the above method embodiments are implemented.
[0093] 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 for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with relevant regulations.
[0094] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. 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), magnetoresistive 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 be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.
[0095] The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.
[0096] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, 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, it should be considered as the scope described in this specification.
[0097] Specific examples are used in this article to elaborate on the principles and implementation manners of the present application. The descriptions of the above embodiments are only used to help understand the method and its core idea of the present application; at the same time, for those of ordinary skill in the art, according to the idea of the present application, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present application.
Claims
1. A method for fault analysis of a rail transit system, characterized in that, The method for analyzing faults in the rail transit system includes: 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 association relationships, interaction signals, and transmission paths among multiple devices in different professional departments of the rail transit system; Establish a perception data access channel and determine the faulty device based on the obtained fault information; When the location of the faulty device is at the professional interface, obtain the monitoring data of the faulty device and associated devices through the perception data access channel; the professional interface refers to the intersection location of different professional departments; Based on the monitoring data and the cross - professional fault analysis model, simulate the entire fault process corresponding to the fault information to obtain retrospective data; Analyze the retrospective data and preset abnormal data to obtain the target fault result.
2. The fault analysis method for the rail transit system according to claim 1, wherein Constructing a cross - professional fault analysis model based on the business scenario data includes: Based on the business scenario data, establish the structural topology relationship of the rail transit system; the structural topology relationship is used to characterize the connection relationships and layout methods among multiple devices in different professional departments of the rail transit system; According to the structural topology relationship, obtain the interaction rules between each device; the interaction rules include at least one of the following: signal interaction rule, interaction trigger rule, interaction verification rule; Perform combined processing on the interaction rules to obtain a rule set between the devices; Embed the structural topology relationship and the rule set as configuration parameters into a preset model to construct the cross - professional fault analysis model.
3. The method for analyzing faults of a rail transit system according to claim 2, wherein Based on the business scenario data, establishing the structural topology relationship of the rail transit system includes: Call and run a visualization program to extract rail transit equipment data from the business scenario data; the visualization program is used to display a visualization interface; in response to an operation instruction, associate and organize the rail transit equipment data in the visualization interface to establish the structural topology relationship; or, Determine structured data and unstructured data from the business scenario data; perform data extraction on the structured data to obtain entity data and relationship data, and use a named entity recognition model to extract entity data from the unstructured data, and use a relationship extraction model to analyze the relationship data between the entity data; convert the entity data into node features and the relationship data into edge features respectively; process the entity data and the relationship data through a graph neural network to generate the structural topology relationship.
4. The method for analyzing faults in a rail transit system according to claim 2, wherein After determining the faulty device based on the obtained fault information, the method further includes: Judge whether the faulty device is within the coverage of the structural topology relationship; When it is within the coverage of the structural topology relationship, determine that the location of the faulty device is at the professional interface; When it is not within the coverage of the structural topology relationship, determine that the location of the faulty device is not at the professional interface.
5. The method for analyzing faults of a rail transit system according to claim 1, characterized in that, Based on the monitoring data and the cross - professional fault analysis model, simulating the entire fault process corresponding to the fault information to obtain retrospective data, includes: Perform time calibration processing on the monitored data to obtain the time-calibrated monitored data; Based on the time-calibrated monitored data, perform a fault process simulation through a cross-professional fault analysis model to obtain retrospective data.
6. The method for analyzing faults in a rail transit system according to claim 5, wherein Based on the time-calibrated monitored data, perform a fault process simulation through a cross-professional fault analysis model to obtain retrospective data, including: Through the cross-professional fault analysis model, obtain the logical relationship between the faulty device and the associated devices; the logical relationship includes a pre-logical relationship and / or a post-logical relationship; Based on the logical relationship, arrange the time-calibrated data in chronological order for fault process simulation to obtain the retrospective data.
7. The method for analyzing faults in a rail transit system according to claim 1, characterized in that, Analyze the retrospective data and the preset abnormal data to obtain a target fault result, including: Obtain the target abnormal data corresponding to the retrospective data from the preset abnormal data; According to the preset configuration rules, compare the retrospective data with the target abnormal data; Analyze the retrospective data with inconsistent comparison results to obtain the target fault result.
8. A fault analysis device for a rail transit system, characterized in that The rail transit system fault analysis device includes: A construction module for obtaining 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 association relationship, interaction signals, and transmission paths among multiple devices in different professional departments of the rail transit system; A determination module for establishing a perception data access channel and determining a faulty device based on the obtained fault information; An acquisition module for, when the location of the faulty device is at the professional junction, obtaining the monitored data of the faulty device and the associated devices through the perception data access channel; the professional junction refers to the intersection location of the different professional departments; A fault simulation module for, based on the monitored data and the cross-professional fault analysis model, simulating the entire fault process corresponding to the fault information to obtain retrospective data; A result determination module for analyzing the retrospective data and the preset abnormal data to obtain a target fault result.
9. A computer device, comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of a rail transit system fault analysis method according to any one of claims 1-7.
10. 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 rail transit system fault analysis method according to any one of claims 1-7.
Citation Information
Patent Citations
Transdisciplinary collaborative automatic diagnosing and locating method of electric power telecommunication business faults
CN106789194A
Rail transit multi-specialty intelligent operation and maintenance system and method
CN112596988A
Rail transit signal system fault analysis method and device and electronic equipment
CN113987001A
Rail transit power supply management method and system
CN115792505A
Communication complex network service end-to-end intelligent diagnostic analysis method
CN116800587A
Cited By
Vehicle-mounted fault diagnosis system, method and device and storage medium
CN121115720A