Rail transit equipment fault real-time detection method and system based on knowledge graph

Abstract

The application discloses a kind of based on knowledge graph's rail transit equipment fault real-time detection method and system, based on the rich corpus data about city rail field section equipment fault analysis collected, the extraction of entity and its attribute, entity relationship is carried out, and city rail field section equipment knowledge graph is constructed;Real-time fault phenomenon set is input to the city rail field section equipment fault diagnosis reasoning strategy model based on knowledge graph established in advance, and the fault cause diagnosis and fault treatment scheme result are output.The present application can realize the inference and detection prompt of city rail field section equipment fault based on knowledge graph, and can improve the efficiency and accuracy of rail transit equipment fault detection.

Description

Technical Field

[0001] This invention relates to the field of digital twin technology, specifically to a method and system for real-time fault detection of rail transit equipment based on knowledge graphs. Background Technology

[0002] In the rail transit sector, critical equipment in urban rail depots includes trains, signaling systems, and power supply systems, whose normal operation is crucial for the safety and smooth flow of urban traffic. However, these critical equipment inevitably experience malfunctions during long-term operation, posing significant challenges to maintenance. Timely detection and handling of equipment faults are key to ensuring operational safety and improving equipment reliability. Traditional fault detection methods primarily rely on reasoning-based approaches, analyzing fault phenomena and relying on experiential knowledge to determine if equipment has malfunctioned. However, this method suffers from limited reasoning capabilities and the inability to analyze and alert on faults in real time, failing to meet the need for rapid and accurate fault detection. Summary of the Invention

[0003] This application provides a knowledge graph-based real-time fault detection method and system for rail transit equipment to solve the problems of limited reasoning ability and inability to analyze faults and provide prompts in real time in traditional fault detection methods.

[0004] According to the first aspect, one embodiment provides a real-time fault detection method for rail transit equipment based on knowledge graphs, characterized in that the method includes:

[0005] Based on the rich corpus data collected on the analysis of equipment failures in urban rail transit depots, entities and their attributes and entity relationships are extracted to construct a knowledge graph of urban rail transit depot equipment. The knowledge graph includes graph nodes and directed relation edges. The graph nodes include equipment type nodes, component type nodes, failure phenomenon type nodes, failure cause type nodes, and failure handling solution type nodes.

[0006] The real-time fault phenomenon set is input into a pre-established knowledge graph-based urban rail transit equipment fault diagnosis reasoning strategy model, and the fault cause diagnosis and fault handling solution results are output.

[0007] Furthermore, based on the rich corpus data collected regarding equipment failure analysis in urban rail transit depots, specifically including:

[0008] The corpus data includes original equipment fault manuals, maintenance manuals, and equipment user manuals.

[0009] Furthermore, a knowledge graph of urban rail transit depot equipment will be constructed, specifically including:

[0010] The Neo4j graph database is used to store all entities and the relationships between entities in the knowledge graph of equipment faults in urban rail transit sections. Each entity is stored independently according to its specific attribute type.

[0011] The collected corpus data is processed to remove fault experience data that does not form a complete closed loop of fault phenomena, causes, and solutions. Operations including entity alignment, attribute fusion, and relationship fusion are performed, and finally the data is imported into the neo4j graph database.

[0012] Furthermore, a knowledge graph of urban rail transit depot equipment will be constructed, specifically including:

[0013] The knowledge ontology for fault diagnosis of urban rail transit equipment is represented as follows:

[0014] Knowledge ontology = <C, AC, R, AR, I>

[0015] In the formula: C is the set of ontology concepts; R is the set of ontology relations; AC is the attribute of the ontology concept; AR is the attribute of the relation; I is the set of entity elements;

[0016] The diagnostic knowledge of the field equipment is divided into 5 different categories of ontologies, and the set of ontology concepts is represented as follows:

[0017] C = {C1, C2, C3, C4, C5}

[0018] In the formula: C1 is the equipment structure ontology concept; C2 is the measuring point ontology concept; C3 is the fault phenomenon ontology concept; C4 is the fault cause ontology concept; C5 is the maintenance measure ontology concept;

[0019] In a knowledge ontology, the relationships between different categories of concepts constitute a set of relations R, represented as:

[0020] R={R1, R2, R3, R4, R5, R6}

[0021] In the formula: R1 represents the relationship between the equipment structure class and the fault cause class; R2 represents the relationship between the measuring point class and the equipment structure class; R3 represents the relationship between the maintenance measure class and the fault cause class; R4 represents the relationship between the fault phenomenon class and the fault cause class; R5 represents the relationship between the measuring point class and the fault phenomenon class; R6 represents the relationship between the measuring point class and the fault phenomenon class.

[0022] According to the definition in the ontology representation model, the semantic relations represented by the above relations are as follows:

[0023] R1 = R located (C4,C1) indicates that the fault occurred at a certain part of the equipment structure;

[0024] R2 = R monitor(C2,C1) represents a measurement point monitoring the structure of a certain equipment;

[0025] R3 = R advice (C4, C5) indicate the repair recommendations needed to address the cause of the malfunction;

[0026] R4 = R cause (C4,C3) indicates that the cause of the fault led to a certain fault phenomenon;

[0027] R5 = R relative (C2, C3) indicates that the abnormal indicators of the fault phenomenon are monitored by the measuring points;

[0028] R6 = R hasPhe (C1,C3)) A fault occurred in the structure of a certain device;

[0029] In the ontology representation model of knowledge in the field equipment fault diagnosis domain, AC and AR are defined as conceptual attributes and relational attributes, respectively, and directly inherit the definitions in the ontology representation model; instance I represents the set of knowledge entity elements, and the relations between entities inherit the set of relations R between conceptual sets.

[0030] Furthermore, the real-time fault phenomenon set is input into a pre-established knowledge graph-based fault diagnosis reasoning strategy model for urban rail transit equipment, and the output results of fault cause diagnosis and fault handling solutions are provided, specifically including:

[0031] The set of input fault phenomena is P = {p1, p2, ..., pn}, where n is a positive integer;

[0032] Traverse the set of fault phenomena P and determine whether the condition is satisfied. G represents the set of all entities in the knowledge graph. If the condition is met, the set of known entities Pd = P is used for the next step of reasoning. If the condition is not met, the set P is operated on to remove entity elements in set P that are not in the knowledge graph G, and then the entity set Pd = {pi | pi ∈ G and pi ∈ P} is obtained.

[0033] The entity set Pd is used as the known entity set for the search, and the known entity set Pd is used according to the relation path. Retrieve the set of entities that are directly associated with the entity set Pd to identify the causes of failures. In the formula: range(R) represents the range of relation R, and the search path for the direct cause is represented as follows:

[0034] Based on the known entity set Pd and the relation path Get the set of associated measurement point entities related to entity set Pd. Based on relation path R monitor(C2,C1), obtain the set of associated device structure entities S = range(R) monitor (C2,C1));

[0035] Verify whether a relationship path R exists between the associated entity set S and the known entity set Pd. hasPhe (C1,C3), that is, the relation Pd = range(R) hasPhe Does (C1,C3) exist?

[0036] If the relationship exists, the associated device structure entity set S is determined according to the relationship path R. hasPhe (C1,C3), obtain the set of indirectly related fault phenomenon entities Pi = range(R) hasPhe (C1,C3)); The set of indirectly related fault phenomenon entities Pi is determined by the relation path. Obtain the set of fault causes indirectly associated with the set of fault phenomena Pd. If it does not exist, the set Fi of indirectly related fault causes is empty; the search path for indirectly related causes is represented as:

[0037] Let the set of fault cause entities be F0 = Fd ∪ Fi, that is, F0 is the union of the directly related set of fault causes Fd and the indirectly related set of fault causes Fi. Then, the set of fault cause entities F0 is determined by the relation path R. advice (C4,C5), obtain the fault handling solution entity set A0 = range(R advice (C4,C5));

[0038] The entities in the fault cause set F0 are sorted as follows: First, the directly related causes are placed before the indirectly related causes; second, the entities in the directly related causes are sorted from most to least related to the entities in the entity set Pd. After sorting, the fault cause entity set F1 is obtained. The fault handling solution entities are sorted in the same order to obtain the entity set A1.

[0039] The entity set F1 representing the cause of the fault and the entity set A1 representing the fault handling solution are formatted, and then the diagnostic results are output.

[0040] Furthermore, the method also includes:

[0041] The diagnosed fault causes and troubleshooting solutions are ranked according to priority, and the best causes and solutions are recommended.

[0042] Furthermore, the deduced fault cause diagnoses and fault handling solutions are prioritized, and the best cause and handling solution are recommended, specifically including:

[0043] Record the number of times the cause of a fault occurred in a certain part of the same device and the number of times the solution was adopted during the user's use;

[0044] The probability of the cause of the failure and the recommended percentage of the failure handling solution are calculated based on the recorded data.

[0045] Furthermore, the probability calculation method for the cause of the failure is as follows:

[0046] The probability of cause A = (a+1) / ((n+m) / α)*100%

[0047] Among them, the number of times the fault phenomenon occurs is n, the number of all causes of this fault phenomenon in the knowledge graph is m, the number of records of cause A is a, and α is the percentage of the assumed causes entered into the system out of the possible causes, which is set according to the actual situation;

[0048] The recommended percentage for troubleshooting solutions is calculated as follows:

[0049] Recommended value for treatment option B = (b+1) / ((N+M) / β)*100%

[0050] Among them, N is the number of records for the same cause under the same fault phenomenon, M is the number of all processing solutions for this cause in the knowledge graph, b is the number of records for processing solution B, and β is the percentage of the processing solutions assumed to be entered into the system as possible solutions, which is set according to the actual situation.

[0051] According to a second aspect, one embodiment provides a real-time fault detection system for rail transit equipment based on a knowledge graph, the system comprising:

[0052] The knowledge graph construction module is used to extract entities and their attributes and entity relationships based on the rich corpus data collected on the analysis of equipment failures in urban rail transit sections, and to construct a knowledge graph of urban rail transit section equipment. The knowledge graph includes graph nodes and directed relation edges. The graph nodes include equipment type nodes, component type nodes, failure phenomenon type nodes, failure cause type nodes, and failure handling solution type nodes.

[0053] The fault reasoning module is used to input the real-time fault phenomenon set into a pre-established knowledge graph-based urban rail depot equipment fault diagnosis reasoning strategy model, and output the fault cause diagnosis and fault handling solution results.

[0054] According to three aspects, one embodiment provides an electronic device, the device comprising: a processor and a memory;

[0055] The memory is used to store one or more program instructions;

[0056] The processor is configured to run one or more program instructions to perform the steps of a knowledge graph-based real-time fault detection method for rail transit equipment as described in any of the preceding claims.

[0057] According to a fourth aspect, one embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a knowledge graph-based real-time fault detection method for rail transit equipment as described in any of the preceding claims.

[0058] This application provides a knowledge graph-based method and system for real-time fault detection of rail transit equipment. Based on rich corpus data collected on fault analysis of urban rail transit equipment, entities, their attributes, and entity relationships are extracted to construct a knowledge graph for urban rail transit equipment. This knowledge graph includes graph nodes and directed edges. A set of real-time fault phenomena is input into a pre-established knowledge graph-based fault diagnosis and reasoning strategy model for urban rail transit equipment, outputting fault cause diagnosis and fault handling solutions. This invention enables fault inference and detection prompts for urban rail transit equipment based on knowledge graphs, improving the efficiency and accuracy of fault detection in rail transit equipment. Attached Figure Description

[0059] Figure 1 A flowchart illustrating a real-time fault detection method for rail transit equipment based on a knowledge graph, as provided in one embodiment of the present invention;

[0060] Figure 2 This is a schematic diagram of a knowledge graph in a real-time fault detection method for rail transit equipment based on a knowledge graph, provided in one embodiment of the present invention.

[0061] Figure 3 The present invention provides a knowledge graph construction process for a real-time fault detection method for rail transit equipment based on a knowledge graph, as an embodiment of the present invention.

[0062] Figure 4 This invention provides a set of key fault concepts for a fixed vehicle jacking machine in a real-time fault detection method for rail transit equipment based on a knowledge graph, as an embodiment of the present invention.

[0063] Figure 5 This invention provides a set of key fault concepts for automatic train cleaning machines in a knowledge graph-based real-time fault detection method for rail transit equipment.

[0064] Figure 6 This invention provides a set of key fault concepts for wheelset dynamic detection equipment in a knowledge graph-based real-time fault detection method for rail transit equipment, as an embodiment of the present invention.

[0065] Figure 7An example of a knowledge graph in a real-time fault detection method for rail transit equipment based on a knowledge graph provided in one embodiment of the present invention;

[0066] Figure 8 An example of the neo4j storage structure in a knowledge graph-based real-time fault detection method for rail transit equipment, provided as an embodiment of the present invention;

[0067] Figure 9 An example of the relationship between a scheme and a cause graph in a real-time fault detection method for rail transit equipment based on a knowledge graph, provided as an embodiment of the present invention;

[0068] Figure 10 An example of the relationship between faults and cause graphs in a real-time fault detection method for rail transit equipment based on knowledge graphs, provided as an embodiment of the present invention;

[0069] Figure 11 An example of the relationship between faults and locations in a knowledge graph-based real-time fault detection method for rail transit equipment, provided as an embodiment of the present invention;

[0070] Figure 12 An example of the relationship between equipment and parts in a knowledge graph-based real-time fault detection method for rail transit equipment, provided as an embodiment of the present invention;

[0071] Figure 13 This invention provides a method for real-time fault detection of rail transit equipment based on a knowledge graph, which includes fault knowledge graph entity nodes and relationships.

[0072] Figure 14 This invention provides a diagnostic reasoning process based on knowledge graph relationship paths in a real-time fault detection method for rail transit equipment based on knowledge graphs, as an embodiment of the present invention.

[0073] Figure 15 This is an example of auxiliary decision recommendation in a knowledge graph-based real-time fault detection method for rail transit equipment, provided as an embodiment of the present invention.

[0074] Figure 16 This invention provides an example of a real-time fault detection method for rail transit equipment based on knowledge graphs, which includes a fault cause and solution recommendation based on probability inference.

[0075] Figure 17 This is a schematic diagram of the logical structure of a knowledge graph-based real-time fault detection system for rail transit equipment, provided as an embodiment of the present invention. Detailed Implementation

[0076] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings. Similar elements in different embodiments are referred to by associated similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of this application. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to this application are not shown or described in the specification. This is to avoid obscuring the core parts of this application with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0077] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0078] The first embodiment of this invention provides a real-time fault detection method for rail transit equipment based on knowledge graphs. The following is a combination of... Figure 1 Please provide a detailed explanation.

[0079] like Figure 1 As shown, in step S100, based on the rich corpus data collected on fault analysis of urban rail transit equipment, entities and their attributes and entity relationships are extracted to construct a knowledge graph of urban rail transit equipment. The knowledge graph includes graph nodes and directed relation edges.

[0080] Knowledge graphs are essentially semantic networks built upon graphs, forming a unique data structure system. The core idea of ​​knowledge graphs is to categorize and organize diverse information sources into entities with varying attributes and the intricate relationships between these entities, thereby generating a deeply interconnected network. The aim is to utilize this network structure to accurately mine, filter, and infer the interrelationships between various things from a large amount of unstructured knowledge, significantly improving the efficiency of storing, retrieving, and analyzing this information. Knowledge graphs have already achieved widespread application results in many fields, such as search engines, social networks, healthcare, and education and training. They also play a crucial role in semantic search, intelligent question answering systems, personalized recommendation algorithms, big data analysis, natural language processing, and explainable artificial intelligence, demonstrating enormous application potential.

[0081] Knowledge graphs are primarily composed of two elements: nodes and edges. Nodes can represent concrete entities, such as a device or a person, or abstract concepts, such as the knowledge graph itself or artificial intelligence. Edges typically describe relationships between entities, such as teacher-student relationships or family member relationships, or attributes of entities, such as the name or model of a device. Knowledge graphs are usually represented using triples: (entity 1, relation, entity 2) or (entity, relation, attribute). Entities and attributes serve as nodes, and relations are directed edges connecting two nodes. By analyzing entities or attributes and the relationships between them, a network-structured knowledge graph diagram can be constructed, as shown below. Figure 2 As shown.

[0082] In handling faults in large-scale equipment such as urban rail transit depots, knowledge graph technology has demonstrated its unique advantages and key strengths. Specifically, it can successfully and effectively integrate unstructured data, including equipment maintenance strategies, common fault phenomena, and corresponding solutions, significantly improving the speed and efficiency of data retrieval, and especially greatly enhancing the capabilities of equipment maintenance teams. Furthermore, knowledge graph technology can tightly integrate various equipment fault instances and associated maintenance documents, providing maintenance personnel with more intelligent auxiliary maintenance suggestions and automatically generating accurate and personalized solutions based on the attribute characteristics of fault instances, further saving time and effort.

[0083] Knowledge graph construction:

[0084] When building a knowledge base, three different technical approaches are typically employed: automated construction, semi-automated construction, and manual construction. Given that the specific domain of equipment fault knowledge primarily serves the purpose of assisting in fault diagnosis, strict requirements are placed on the quality of the knowledge base construction. Overly simplistic automated construction methods often fail to meet the needs of subsequent practical applications of the knowledge graph. To ensure a high-quality knowledge base construction, this embodiment incorporates the seven-step domain ontology construction method advocated by Stanford University, building upon the foundation of manual knowledge base construction. This results in a proposed construction strategy suitable for knowledge graphs of equipment faults in urban rail transit depots. The detailed process is as follows: Figure 3 As shown.

[0085] Given that most knowledge graph data on equipment faults in the field relies on in-depth mining of key corpus information and careful extraction of the rich experience of on-site operators and experts in related fields, the resulting information is mostly semi-structured and non-standardized. Therefore, to ensure a higher standard of accuracy for the knowledge graph and to fully reflect it in a visually intuitive format, this embodiment adopts a combined "top-down" and "bottom-up" strategy to construct this knowledge graph.

[0086] Definition of concept set:

[0087] After clarifying the primary need for constructing a knowledge graph for the research of major equipment failures in urban rail transit depots, through in-depth research and thorough analysis of relevant knowledge content, we were able to summarize the key terms and core concepts of major equipment failures in urban rail transit depots. We also systematically classified and comprehensively organized unstructured and semi-structured data, such as failure cases of these equipment. While ensuring the rationality of each concept division, we accurately depicted the knowledge system of urban rail transit depot equipment failures and the close relationships between its various knowledge points. We removed information with weak relevance and high repetition, corrected ambiguous and easily confused terminology, and ultimately formed a precise and complete set of core concepts for urban rail transit depot equipment failures. In this research, three major categories of depot equipment were selected as research objects: pit-type fixed-frame car carriers, automatic cleaning equipment for subway cars, and wheelset pantograph monitoring equipment. The framework of key failure concepts for these three types of equipment is shown in the following diagram. Figure 4 , Figure 5 , Figure 6 As shown. The main research focus is on the common failure modes of these three devices.

[0088] Entity and attribute extraction:

[0089] The purpose of entity and attribute extraction is to select words representing entities or attributes from the corpus of urban rail transit equipment fault analysis and to perform part-of-speech tagging on them. Through the extraction of attributes and attribute values, we can more comprehensively build the entity concept set in the knowledge graph. The urban rail transit equipment fault knowledge graph is depicted using a graphical model. The entity extraction process forms the node structure, while attribute extraction is used to construct the characteristics of the relationships between nodes. When defining entities or attributes, we should minimize data redundancy while ensuring that this information meets the actual application requirements and visualization needs. The entity attributes in the urban rail transit equipment fault knowledge graph can be summarized into five aspects: name, type, overview, analysis, and method. Specific extraction examples are shown in Table 1.

[0090] Table 1 Examples of entity and attribute extraction

[0091]

[0092]

[0093] Entity relation extraction:

[0094] The main purpose of semantic relation extraction is to accurately extract the semantic relationships between different entities from the corpus of urban rail transit equipment failure case analyses, thereby clearly illustrating the inherent connections and logical relationships between each entity. This step plays a crucial role in realizing query functions and providing visualization. Specifically, the knowledge graph of urban rail transit equipment failures can define various complex relationships by combining the part-of-speech characteristics of entities and their attributes. Table 2 shows some examples of relation extraction in practical applications.

[0095] Table 2 Examples of Relation Extraction

[0096]

[0097] Fault knowledge storage:

[0098] A massive database of knowledge graphs for urban rail transit equipment is constructed and maintained using a Neo4j-based tag-attribute graph data model. Neo4j is a high-performance NoSQL graph database that uniquely and innovatively stores structured data in various complex topological graphs, enabling convenient, effective, and centralized management and control of massive amounts of data. Neo4j's proprietary tag-attribute graph model consists of two main parts: nodes and relationships. Nodes store detailed information about entities, and nodes are tightly connected through their relationships. Furthermore, the properties and labels of nodes and relationships are stored and managed in a key-value pair format.

[0099] Specifically, an entity can be represented by the following formula:

[0100] Entity=(Node:Label{Propertyname:`Propertyvalue`});

[0101] Here, Node represents a specific node name, Label is the tag name of that Node, Propertyname represents the name of the corresponding property, and Propertyvalue is the specific value of the property. It's worth noting that each node may be assigned one or more tags, and may also have zero or more properties. In other words, there is a one-to-one correspondence between the property name and its corresponding value, for example: (Fixed Car Lifting Machine: Equipment {Name: `Fixed Car Lifting Machine`}).

[0102] Considering the specific association between the two entity nodes Node1 and Node2, we call it the "relationship label name," and the actual meaning represented by this relationship is the "Relationship name" (a detailed description of the relationship). In this example, we can see that the "Relationship name" specifically points to a specific directional relationship from Node1 to Node2. For example, we can list an example like "(Unable to operate normally during lifting)" - [r: Cause of failure] → ("Aging or poor contact of electrical wiring") to explain that aging or poor contact of electrical wiring is the root cause of the inability to operate normally during lifting.

[0103] According to the design requirements of this urban rail transit depot knowledge graph, five types of entities are planned to be constructed, including equipment, location, fault, cause, and solution. For details on these entities and their related attributes and relationships, please refer to [link / reference needed]. Figure 7 The content displayed.

[0104] By organizing the data from original equipment fault manuals, maintenance manuals, and equipment user manuals, removing fault experience data that did not form a complete closed loop of fault phenomena, causes, and solutions, and performing operations such as entity alignment, attribute fusion, and relationship fusion, the data was finally imported into the Neo4j graph database. The following is the data structure for storing causes and phenomena in Neo4j data: Figure 8 As shown.

[0105] By linking nodes such as type, entity, attribute, and relationship, solution-cause relationship graphs, fault-cause graphs, fault-location graphs, and equipment-location graphs are generated, respectively, as shown below. Figure 9 , Figure 10 , Figure 11 As shown.

[0106] Fault diagram data display:

[0107] Based on a large corpus of collected data on equipment failure analysis in urban rail transit depots, and after in-depth exploration and research into entities and relationships, and subsequent extraction and storage operations, a knowledge graph model for urban rail transit equipment failures has been successfully constructed. To date, we have built a total of 348 entity nodes in the graph database, including 131 nodes related to the causes of failures and 84 nodes related to failure phenomena. Furthermore, we have provided 109 solutions for these failure phenomena, covering 34 different failure locations.

[0108] The knowledge graph of equipment faults in urban rail transit depots is stored in the Neo4j graph database primarily through graph nodes and relational edges. For details, please refer to [link / reference needed]. Figure 12 The diagram showcases the creation of various equipment fault-related nodes and their relationships. In this diagram, each node represents the fault location, fault phenomenon, fault cause, or fault handling solution for various types of equipment, and each node also includes its own unique attribute information. For ease of understanding, different attributes are distinguished by different colors on the visualization interface; for example, equipment type nodes are typically displayed in red, fault cause nodes in brown, fault handling solution nodes in green, and component nodes in orange. Furthermore, the relationships between entities are represented by directed edges, each containing three parts: a starting node, relationship attributes, and an ending node. Finally, the fault graph relationships are displayed... Figure 12 middle.

[0109] This embodiment successfully constructed a knowledge graph of urban rail transit equipment faults by employing in-depth and precise knowledge extraction techniques and scientifically sound node relationship attribute definitions. The Neo4j graph database, with its concise and clear storage structure, displays all entities in the urban rail transit equipment fault knowledge graph and the complex relationships between them. Each entity is stored independently according to its specific attribute type, facilitating refined management and maintenance of various entities. Furthermore, this storage structure makes expanding the knowledge graph content remarkably easy. Simply creating the corresponding entities and relationship attributes in the graph database is sufficient to handle new fault analysis corpora without requiring large-scale adjustments to the entire database's storage architecture, significantly improving the efficiency of knowledge updates.

[0110] like Figure 1 As shown, in step S200, the real-time fault phenomenon set is input into the pre-established knowledge graph-based urban rail depot equipment fault diagnosis reasoning strategy model, and the fault cause diagnosis and fault handling solution results are output.

[0111] To address equipment failures in urban rail transit depots, this embodiment proposes a novel, efficient, and rigorous knowledge graph-based equipment failure diagnosis and reasoning strategy. This strategy leverages the structural characteristics of knowledge graphs and incorporates knowledge graph reasoning techniques based on relational paths. The specific execution flow of this diagnostic reasoning strategy is as follows: Figure 14 The diagram illustrates the logical connections and operational sequence between each step. The detailed steps of the graph construction and reasoning method are described below:

[0112] First, a knowledge graph of equipment failures in urban rail transit depots is constructed:

[0113] The knowledge ontology for fault diagnosis of urban rail transit equipment is represented as follows:

[0114] Knowledge ontology = <C, AC, R, AR, I>

[0115] In the formula: C—the set of ontology concepts; R—the set of ontology relations; AC—the attributes of concepts; AR—the attributes of relations; I—the set of entity elements.

[0116] The diagnostic knowledge of field equipment can be divided into 5 different categories of ontologies, and the set of ontology concepts is represented as follows:

[0117] C = {C1, C2, C3, C4, C5}

[0118] In the formula: C1—Equipment structure ontology concept; C2—Measuring point ontology concept; C3—Fault phenomenon ontology concept; C4—Fault cause ontology concept; C5—Maintenance measure ontology concept.

[0119] In a knowledge ontology, the relationships between different categories of concepts constitute a set of relations R, which can be represented as:

[0120] R={R1, R2, R3, R4, R5, R6}

[0121] In the formula: R1—the relationship between equipment structure class and fault cause; R2—the relationship between measuring point class and equipment structure class; R3—the relationship between maintenance measure class and fault cause class; R4—the relationship between fault phenomenon class and fault cause class; R5—the relationship between measuring point class and fault phenomenon class; R6—the relationship between measuring point class and fault phenomenon class.

[0122] According to the definition in the ontology representation model, the semantic relations represented by the above relations are as follows:

[0123] (1)R1=R located (C4,C1) indicates that the fault occurred at a certain part of the equipment structure;

[0124] (2) R2=R monitor(C2,C1) represents a measurement point monitoring the structure of a certain equipment;

[0125] (3) R3=R advice (C4, C5) indicate the repair recommendations needed to address the cause of the malfunction;

[0126] (4) R4 = R cause (C4,C3) indicates that the cause of the fault led to a certain fault phenomenon;

[0127] (5) R5 = R relative (C2, C3) indicates that the abnormal indicators of the fault phenomenon are monitored by this measuring point;

[0128] (6)R6=R hasPhe (C1,C3) A fault occurred in the structure of a certain device.

[0129] In the ontology representation model of knowledge in the field of equipment fault diagnosis, AC and AR are defined as conceptual attributes and relational attributes, respectively, directly inheriting the definitions in the ontology representation model. Instance I represents the set of knowledge entity elements, and the relations between entities inherit the set of relations R between conceptual sets.

[0130] The detailed steps of the reasoning method are as follows:

[0131] (1) Input the set of fault phenomena P = {p1, p2, ..., pn}, where n is a positive integer;

[0132] (2) Traverse the set of fault phenomena P and determine whether the conditions are met. G represents the set of all entities in the knowledge graph. If the condition is met, the set of known entities Pd = P is used for the next step of reasoning. If the condition is not met, the set P is operated on to remove entity elements in set P that are not in the knowledge graph G, and then the entity set Pd = {pi | pi ∈ G and pi ∈ P} is obtained.

[0133] (3) Use the entity set Pd as the known entity set for the search, and let the known entity set Pd be used according to the relation path. Retrieve the set of entities that are directly associated with the entity set Pd to identify the causes of failures. The search path for directly related causes can be represented as follows: In the formula: range(R) — the range of relation R;

[0134] (4) Based on the known entity set Pd and the relation path Get the set of associated measurement point entities related to entity set Pd. Based on relation path R monitor (C2,C1), obtain the set of associated device structure entities S = range(R) monitor(C2,C1));

[0135] (5) Verify whether there is a relationship path R between the associated entity set S and the known entity set Pd. hasPhe (C1,C3), that is, the relation Pd = range(R) hasPhe Does (C1,C3) exist?

[0136] (6) If the relationship exists, the set of associated device structure entities S is determined by the relationship path R. hasPhe (C1,C3), obtain the set of indirectly related fault phenomenon entities Pi = range(R) hasPhe (C1,C3)); The set of indirectly related fault phenomenon entities Pi is determined by the relation path. Obtain the set of fault causes indirectly associated with the set of fault phenomena Pd. If it does not exist, then the set Fi of indirectly related fault causes is empty; the search path for indirectly related causes can be represented as:

[0137]

[0138] (7) Take the set of fault cause entities F0 = Fd ∪ Fi, that is, F0 is the union of the directly related set of fault causes Fd and the indirectly related set of fault causes Fi. The set of fault cause entities F0 is determined by the relation path R. advice (C4,C5), obtain the fault handling solution entity set A0 = range(R advice (C4,C5));

[0139] (8) Sort the entities in the fault cause set F0. The sorting method is as follows: First, place the directly related causes before the indirectly related causes; second, sort each entity in the directly related causes according to the number of direct related paths with the entities in the entity set Pd from most to least. After sorting, the fault cause entity set F1 is obtained. The fault handling solution entities are sorted in the same order to obtain the entity set A1.

[0140] (9) Format the fault cause entity set F1 and the fault handling scheme entity set A1, and then output the diagnostic results.

[0141] The effectiveness of diagnosing fault causes and recommending solutions based on this diagnostic reasoning process is as follows: Figure 15 As shown.

[0142] In order to comprehensively improve the accuracy and reliability of equipment fault diagnosis results and reduce the deviation or inaccuracy of reasoning results due to data errors or other sample problems, this reasoning work will use the probability analysis method to prioritize the results based on the reasoning results in step (9) and recommend the best cause and treatment plan.

[0143] Specifically, the system will make full use of the number of times the cause of a failure and the number of times the solution was adopted for a certain part of the same device, as recorded by users during use. Through in-depth analysis and mining of this data, the probability of the cause and solution will be further deduced, thereby improving the accuracy and reliability of the reasoning results.

[0144] Finally, based on the calculation results, combined with user feedback and actual conditions, the inference results will be corrected and optimized to improve their accuracy and reliability.

[0145] Based on probability, the recommended processing flow is as follows:

[0146] 1. Assuming the percentage of possible causes entered into the system is α, it is set to 80% here. This percentage can be manually adjusted according to the actual situation. (Because without a large amount of fault data accumulated, the result cannot directly produce a 100% result. The highest percentage of causes can be dynamically adjusted according to the completeness of fault experience data.)

[0147] 2. Number of times the fault phenomenon occurred (n)

[0148] 3. The total number of causes m for this fault phenomenon in the graph.

[0149] 4. The number of records for reason A is a.

[0150] That is, the probability of cause A = (a+1) / ((n+m) / 0.8)*100%

[0151] The calculation method for the percentage of recommendation for the treatment plan is as follows:

[0152] Premise: Same phenomenon, same cause

[0153] 1. Assume that the percentage of possible solutions processed by the data entry system is β, which is set to 80% here. This percentage can be manually adjusted according to the actual situation; (the percentage definition is the same as above).

[0154] 2. The number of times N records the same phenomenon and the same cause.

[0155] 3. The number M of all treatment options for this cause in the graph.

[0156] 4. The number of records for processing scheme B is b.

[0157] The recommended value for treatment option B is (b+1) / ((N+M) / 0.8)*100%.

[0158] Based on the above probability analysis, the causes of the fault and the recommended solutions are as follows: Figure 16 As shown.

[0159] In summary, the goal of this inference is to improve the accuracy of equipment fault diagnosis results and reduce inaccurate inference results caused by data errors by combining user usage records and equipment management knowledge with experience-based recommendation algorithms.

[0160] Validation of equipment fault diagnosis results based on knowledge graph:

[0161] To verify the performance and effectiveness of the fault diagnosis and mitigation suggestion system for major equipment in urban rail vehicle depots built based on knowledge graph technology, this embodiment selected 14 common historical fault data of fixed-type vehicle jacking machines as research samples, successfully collecting a total of 25 typical fault instances containing all initial fault symptom information. Based on this solid foundation, a series of rigorous test cases were carefully designed, and the specific design process is as follows:

[0162] (1) First, extract the mapping relationship between each fault and its corresponding fault phenomenon from rich historical fault experience to ensure that each fault can be matched with at least one set of multiple fault phenomena.

[0163] (2) Secondly, for each type of fault, we set the cases where only one phenomenon is missing, two phenomena, ... up to the case where all n-1 phenomena are missing. Then we combine the remaining fault phenomena in various possible ways to generate a series of comprehensive and detailed test cases.

[0164] The following example, using a car wash machine's pneumatic solenoid valve malfunction, illustrates in detail how to design test cases based on the above method.

[0165] When the pneumatic solenoid valve of a car wash machine malfunctions, it may exhibit the following three symptoms: the solenoid valve does not produce any action during normal operation, the pneumatic actuator moves in the opposite direction to the expected direction, and the response speed of the pneumatic valve is significantly slowed down. These three symptoms are logically related by an "AND" condition; that is, only when all three symptoms occur simultaneously can it be confirmed that the pneumatic solenoid valve of the car wash machine has indeed malfunctioned.

[0166] The test case information used to verify the diagnostic methods is shown in Table 3.

[0167] Table 3 Test Cases

[0168]

[0169]

[0170] Given the diversity and complexity of accompanying diagnostic results, this study will use the first two correctly classified results as the basis for judging the final diagnostic result.

[0171] The diagnostic accuracy rate is calculated as follows:

[0172] Where: n—total number of test cases; N—number of test cases that accurately diagnose.

[0173] During the specific and comprehensive diagnostic verification of the above test cases, it was found that when complete fault phenomenon information was provided for testing, the number of accurate diagnoses reached as high as 18; while in other cases where only symptoms were missing, the diagnostic accuracy rate also remained at a high level, reaching 52 times.

[0174] The diagnostic results are shown in Table 4.

[0175] Table 4. Validation Results of Diagnostic Reasoning Method

[0176] Test categories Complete fault symptoms Fault symptoms missing total Number of accurate diagnoses / cases 17 69 86 Number of test cases / 20 75 95 accuracy 85％ 92％ 90.5％

[0177] As shown in Table 4, even when the input fault symptoms are very complete, the accuracy of this fault diagnosis method only reaches 85%. This phenomenon mainly stems from the fact that in the established knowledge graph, there is a one-to-many mapping relationship between fault symptoms and their potential causes, and there are also special cases where inputting only a single fault symptom perfectly meets all the necessary conditions for diagnosis. In such cases, the method will produce multiple fault diagnosis results; however, these results cannot be effectively sorted based on the existing information, thus failing to obtain an accurate diagnostic conclusion.

[0178] Therefore, with the continuous enrichment and improvement of historical fault data, this method has demonstrated a remarkably high level of accuracy in its recommendation results, significantly improving the efficiency of maintenance personnel in diagnosing and handling faults after they occur. Furthermore, the application of knowledge graphs makes this method universally applicable and easily extendable to other equipment fields, providing a new direction for intelligent equipment diagnostic technology.

[0179] Corresponding to the aforementioned knowledge graph-based real-time fault detection method for rail transit equipment, this invention also discloses a knowledge graph-based real-time fault detection system for rail transit equipment, such as... Figure 17 As shown, it specifically includes:

[0180] The knowledge graph construction module is used to extract entities and their attributes and entity relationships based on the rich corpus data collected on the fault analysis of urban rail transit equipment, and to construct a knowledge graph of urban rail transit equipment. The knowledge graph includes graph nodes and directed relation edges.

[0181] The fault reasoning module is used to input the real-time fault phenomenon set into a pre-established knowledge graph-based urban rail depot equipment fault diagnosis reasoning strategy model, and output the fault cause diagnosis and fault handling solution results.

[0182] It should be noted that for a detailed description of the real-time fault detection system for rail transit equipment based on knowledge graph provided in the embodiments of the present invention, please refer to the relevant description of the real-time fault detection method for rail transit equipment based on knowledge graph provided in the embodiments of this application, which will not be repeated here.

[0183] In addition, embodiments of the present invention also provide an electronic device, the device comprising: a processor and a memory; the memory being used to store one or more program instructions; the processor being used to execute one or more program instructions to perform the steps of a knowledge graph-based real-time fault detection method for rail transit equipment as described in any of the preceding embodiments.

[0184] It should be noted that for a detailed description of an electronic device provided in the embodiments of the present invention, please refer to the relevant description of a real-time fault detection method for rail transit equipment based on knowledge graphs provided in the embodiments of this application, which will not be repeated here.

[0185] In addition, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a knowledge graph-based real-time fault detection method for rail transit equipment as described in any of the preceding embodiments.

[0186] It should be noted that for a detailed description of the computer-readable storage medium provided in the embodiments of the present invention, please refer to the relevant description of the real-time fault detection method for rail transit equipment based on knowledge graph provided in the embodiments of this application, which will not be repeated here.

[0187] Those skilled in the art will understand that all or part of the functions of the various methods in the above embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, which may include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the program is executed by a computer to achieve the above functions. For example, the program can be stored in the memory of a device, and when the program in the memory is executed by the processor, all or part of the above functions can be achieved. In addition, when all or part of the functions in the above embodiments are implemented by computer programs, the program can also be stored in a server, another computer, disk, optical disk, flash drive, or external hard drive, etc., and can be downloaded or copied to the memory of a local device, or the system of the local device can be updated. When the program in the memory is executed by the processor, all or part of the functions in the above embodiments can be achieved.

[0188] The above examples illustrate the present invention only to aid in understanding it and are not intended to limit the scope of the invention. Those skilled in the art can make various simple deductions, modifications, or substitutions based on the principles of this invention.

Claims

1. A real-time fault detection method for rail transit equipment based on knowledge graphs, characterized in that, The method includes: Based on the rich corpus data collected on the failure analysis of urban rail transit equipment, entities and their attributes and entity relationships are extracted to construct a knowledge graph of urban rail transit equipment. The knowledge graph includes graph nodes and directed relation edges. The real-time fault phenomenon set is input into a pre-established knowledge graph-based urban rail transit equipment fault diagnosis reasoning strategy model, and the fault cause diagnosis and fault handling solution results are output. in: Constructing a knowledge graph for urban rail transit depot equipment, specifically including: The knowledge ontology for fault diagnosis of urban rail transit equipment is represented as follows: Knowledge ontology = <C, AC, R, AR, I> In the formula: C is the set of ontology concepts; R is the set of ontology relations; AC is the attribute of the ontology concept; AR is the attribute of the relation; I is the set of entity elements; The diagnostic knowledge of the field equipment is divided into 5 different categories of ontologies, and the set of ontology concepts is represented as follows: C = {C1, C2, C3, C4, C5} In the formula: C1 is the equipment structure ontology concept; C2 is the measuring point ontology concept; C3 is the fault phenomenon ontology concept; C4 is the fault cause ontology concept; C5 is the maintenance measure ontology concept; In a knowledge ontology, the relationships between different categories of concepts constitute a set of relations R, represented as: R= { R1, R2, R3, R4, R5, R6} In the formula: R1 represents the relationship between the equipment structure class and the fault cause class; R2 represents the relationship between the measuring point class and the equipment structure class; R3 represents the relationship between the maintenance measure class and the fault cause class; R4 represents the relationship between the fault phenomenon class and the fault cause class; R5 represents the relationship between the measuring point class and the fault phenomenon class; R6 represents the relationship between the measuring point class and the fault phenomenon class. According to the definition in the ontology representation model, the semantic relations represented by the above relations are as follows: R1 = This indicates that the fault occurred at a specific part of the equipment structure; R2 = This indicates that the measuring point is used to monitor the structure of a certain piece of equipment. R3 = This indicates the repair recommendations needed to address the cause of the malfunction; R4 = This indicates that the cause of the fault led to a certain fault phenomenon. R5 = Abnormal indicators representing fault phenomena are monitored by measuring points; R6 = A malfunction has occurred in a certain part of the equipment structure; In the ontology representation model of knowledge in the field of equipment fault diagnosis, AC and AR are defined as conceptual attributes and relational attributes, respectively, and directly inherit the definitions in the ontology representation model; instance I represents the set of knowledge entity elements, and the relations between entities inherit the relation set R between the concept sets.

2. The real-time fault detection method for rail transit equipment based on knowledge graph as described in claim 1, characterized in that, Based on the rich corpus data collected on equipment failure analysis in urban rail transit sections, specifically including: The corpus data includes original equipment fault manuals, maintenance manuals, and equipment user manuals.

3. The real-time fault detection method for rail transit equipment based on knowledge graph as described in claim 1, characterized in that, Constructing a knowledge graph for urban rail transit depot equipment, specifically including: The Neo4j graph database is used to store all entities and the relationships between entities in the knowledge graph of equipment faults in urban rail transit sections. Each entity is stored independently according to its specific attribute type. The collected corpus data is processed to remove fault experience data that does not form a complete closed loop of fault phenomena, causes, and solutions. Operations including entity alignment, attribute fusion, and relationship fusion are performed, and finally the data is imported into the neo4j graph database.

4. The real-time fault detection method for rail transit equipment based on knowledge graph as described in claim 1, characterized in that, The real-time fault phenomenon set is input into a pre-established knowledge graph-based fault diagnosis reasoning strategy model for urban rail transit equipment, and the output results include fault cause diagnosis and fault handling solutions, specifically including: The set of input fault phenomena is P = {p1, p2, ..., pn}, where n is a positive integer; Traverse the set of fault phenomena P and determine whether P is satisfied. G represents the set of all entities in the knowledge graph. If the condition is met, then the set of known entities Pd = P used for the next step of reasoning; if the condition is not met, the set P is operated on to remove entity elements in set P that are not in the knowledge graph G, and then the entity set Pd = {pi | pi ∈ G and pi ∈ P} is obtained. The entity set Pd is used as the known entity set for the search, and the known entity set Pd is used according to the relation path. Get the set of entities that are directly associated with the entity set Pd and are related to the cause of the failure. In the formula: range(R) represents the range of relation R, and the search path for the direct association reason is represented as... ; Based on the known entity set Pd and the relation path Get the set of associated measurement point entities related to entity set Pd. According to the relationship path Obtain the set of associated device structural entities ; Verify whether a relationship path exists between the associated structured entity set S and the known entity set Pd. That is, relationship Does it exist? If the relationship exists, the associated device structure entity set S is determined according to the relationship path. Obtain the set of entities with indirect related fault phenomena. ; The set of indirectly related fault phenomenon entities Pi is determined by the relationship path Obtain the set of fault causes indirectly associated with the set of fault phenomena Pd. If it does not exist, the set Fi of indirectly related fault causes is empty; the search path for indirectly related causes is represented as follows: ; Let the set of fault cause entities be F0 = Fd ∪ Fi, that is, F0 is the union of the directly related set of fault causes Fd and the indirectly related set of fault causes Fi. The set of fault cause entities F0 is determined by the relationship path. Obtain the set of entities for fault handling solutions. ; The entities in the fault cause set F0 are sorted as follows: First, the directly related causes are placed before the indirectly related causes; second, the entities in the directly related causes are sorted from most to least related to the entities in the entity set Pd. After sorting, the fault cause entity set F1 is obtained. The fault handling solution entities are sorted in the same order to obtain the entity set A1. The entity set F1 representing the cause of the fault and the entity set A1 representing the fault handling solution are formatted, and then the diagnostic results are output.

5. The real-time fault detection method for rail transit equipment based on knowledge graph as described in claim 1, characterized in that, The method further includes: The diagnosed fault causes and troubleshooting solutions are ranked according to priority, and the best causes and solutions are recommended.

6. The real-time fault detection method for rail transit equipment based on knowledge graph as described in claim 5, characterized in that, The deduced fault causes and troubleshooting solutions are ranked according to priority, and the best causes and solutions are recommended, including: Record the number of times the cause of a fault occurred in a certain part of the same device and the number of times the solution was adopted during the user's use; The probability of the cause of the failure and the recommended percentage of the failure handling solution are calculated based on the recorded data.

7. The real-time fault detection method for rail transit equipment based on knowledge graph as described in claim 6, characterized in that, The probability calculation method for the possible causes of the failure is as follows: The probability of cause A = (a+1) / ((n+m) / α) * 100% Among them, the number of times the fault phenomenon occurs is n, the number of all causes of this fault phenomenon in the knowledge graph is m, the number of records of cause A is a, and α is the percentage of the assumed cause entered into the system out of the possible causes, which is set according to the actual situation; The recommended percentage for troubleshooting solutions is calculated as follows: Recommended value for treatment option B = (b+1) / ((N+M) / β) * 100% Among them, N is the number of records for the same cause under the same fault phenomenon, M is the number of all processing solutions for this cause in the knowledge graph, b is the number of records for processing solution B, and β is the percentage of the processing solutions assumed to be entered into the system as possible solutions, which is set according to the actual situation.

8. A real-time fault detection system for rail transit equipment based on knowledge graphs, characterized in that, The system includes: The knowledge graph construction module is used to extract entities and their attributes and entity relationships based on the rich corpus data collected on the fault analysis of urban rail transit equipment, and to construct a knowledge graph of urban rail transit equipment. The knowledge graph includes graph nodes and directed relation edges. The fault reasoning module is used to input the real-time fault phenomenon set into the pre-established knowledge graph-based urban rail depot equipment fault diagnosis reasoning strategy model, and output the fault cause diagnosis and fault handling solution results. in: Constructing a knowledge graph for urban rail transit depot equipment, specifically including: The knowledge ontology for fault diagnosis of urban rail transit equipment is represented as follows: Knowledge ontology = <C, AC, R, AR, I> In the formula: C is the set of ontology concepts; R is the set of ontology relations; AC is the attribute of the ontology concept; AR is the attribute of the relation; I is the set of entity elements; The diagnostic knowledge of the field equipment is divided into 5 different categories of ontologies, and the set of ontology concepts is represented as follows: C = {C1, C2, C3, C4, C5} In the formula: C1 is the equipment structure ontology concept; C2 is the measuring point ontology concept; C3 is the fault phenomenon ontology concept; C4 is the fault cause ontology concept; C5 is the maintenance measure ontology concept; In a knowledge ontology, the relationships between different categories of concepts constitute a set of relations R, represented as: R= { R1, R2, R3, R4, R5, R6} In the formula: R1 represents the relationship between the equipment structure class and the fault cause class; R2 represents the relationship between the measuring point class and the equipment structure class; R3 represents the relationship between the maintenance measure class and the fault cause class; R4 represents the relationship between the fault phenomenon class and the fault cause class; R5 represents the relationship between the measuring point class and the fault phenomenon class; R6 represents the relationship between the measuring point class and the fault phenomenon class. According to the definition in the ontology representation model, the semantic relations represented by the above relations are as follows: R1 = This indicates that the fault occurred at a specific part of the equipment structure; R2 = This indicates that the measuring point is used to monitor the structure of a certain piece of equipment. R3 = This indicates the repair recommendations needed to address the cause of the malfunction; R4 = This indicates that the cause of the fault led to a certain fault phenomenon. R5 = Abnormal indicators representing fault phenomena are monitored by measuring points; R6 = A malfunction has occurred in a certain part of the equipment structure; In the ontology representation model of knowledge in the field of equipment fault diagnosis, AC and AR are defined as conceptual attributes and relational attributes, respectively, and directly inherit the definitions in the ontology representation model; instance I represents the set of knowledge entity elements, and the relations between entities inherit the relation set R between the concept sets.

9. An electronic device, characterized in that, The device includes: a processor and a memory; The memory is used to store one or more program instructions; The processor is configured to run one or more program instructions to perform the steps of a knowledge graph-based real-time fault detection method for rail transit equipment as described in any one of claims 1 to 7.

Images