A fault tracing method and system based on double knowledge graphs, a medium and a product

Abstract

A fault tracing method and system based on double knowledge graphs, a medium and a product are related to the field of digital data processing. The method comprises: obtaining multi-dimensional data sources of an industrial product to be analyzed, and constructing double knowledge graphs; receiving a tracing request, determining a target component node based on a device identity and a fault occurrence time window; calculating the semantic similarity of fault description text and entities in the fault knowledge graph to determine a target fault phenomenon entity; retrieving the causal association path connecting the target component node and the target fault phenomenon entity, and extracting the entities on the path as a candidate fault root cause set; jumping to the standard knowledge graph through the common mapping hub of the product structure tree to determine the compliance parameter threshold corresponding to the candidate fault root cause; obtaining actual operating state data to generate a fault tracing report containing comparison out-of-limit results. The application can improve the positioning accuracy of complex industrial product fault root causes in the whole life cycle operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing, and in particular to a fault tracing method, system, medium, and product based on dual knowledge graphs. Background Technology

[0002] With the development of intelligent manufacturing, the research and development and operation and maintenance of large and complex industrial equipment (such as rail transit vehicles, aircraft, and large energy equipment) have generated an explosive growth in big data. This data mainly includes unstructured fault repair records, semi-structured product design bills of materials (BOMs), and unstructured technical standard documents. In the field of industrial big data applications, effectively integrating this multi-source heterogeneous data to achieve rapid and accurate traceability of equipment faults is the core of improving equipment reliability.

[0003] In related technologies, keyword-based knowledge base systems or single-dimensional fault maps are typically used to assist decision-making. Specifically, the system inputs historical fault cases, maintenance work orders, and product manuals into a relational database or constructs a single fault association map, building an index mapping of "fault symptom keywords - component names - historical solutions." When equipment malfunctions, maintenance personnel input a fault description into the system interface. The system matches the closest historical case based on text similarity and displays a link to the associated static document for the user to download and review to confirm the repair standards.

[0004] However, due to the system's lack of structured understanding of the standard document content, it is difficult to associate the parameter thresholds in the standard with the current fault conditions. As a result, after obtaining the candidate fault causes, the operation and maintenance personnel still need to search for the corresponding parameter entries in the standard document for comparison. When faced with complex conditions such as frequent updates to standard versions or cross-references of multiple standards, there is a risk of misjudgment of faults due to improper reference of standards. Summary of the Invention

[0005] This application provides a fault tracing method, system, medium, and product based on dual knowledge graphs, which can improve the accuracy of locating the root cause of complex industrial product failures during the entire life cycle of operation and maintenance.

[0006] Firstly, this application provides a fault tracing method based on dual knowledge graphs, applied to a data processing system. The method includes: acquiring multi-dimensional data sources of the industrial product to be analyzed; constructing dual knowledge graphs based on the multi-dimensional data sources; the dual knowledge graphs include a fault knowledge graph, a standard knowledge graph, and a product structure tree as a connection hub; receiving a tracing request containing fault description text, equipment identification, and a fault occurrence time window; locating the target component node in the product structure tree based on the equipment identification and the fault occurrence time window; calculating the semantic similarity between the fault description text and entities in the fault knowledge graph to determine the target fault phenomenon entity; retrieving causal association paths connecting the target component node and the target fault phenomenon entity in the fault knowledge graph, and extracting entities on the paths as a candidate fault root cause set; traversing each candidate fault root cause in the candidate fault root cause set, jumping to the standard knowledge graph through the common mapping hub of the product structure tree, and determining the compliance parameter threshold corresponding to the corresponding candidate fault root cause; acquiring the actual operating status data of the target component node within the fault occurrence time window, comparing the actual operating status data with the compliance parameter threshold, and generating a fault tracing report containing the comparison exceeding the limit result.

[0007] In the above embodiments, when the data processing system performs traceability, the method can not only infer candidate root causes from the fault knowledge graph, but also obtain and compare compliance parameters through the standard knowledge graph, realizing a closed-loop analysis from fault phenomenon to root cause location and then to standard verification, thereby improving the accuracy of locating the root cause of complex industrial product faults in the entire life cycle operation and maintenance.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the step of constructing a dual knowledge graph based on a multidimensional data source specifically includes: parsing the design bill of materials and the operation and maintenance bill of materials in the multidimensional data source, fusing nodes with the same name in the design bill of materials and the operation and maintenance bill of materials based on an entity alignment algorithm, and constructing a product structure tree; extracting unstructured fault logs from the multidimensional data source, extracting fault phenomenon entities and fault mechanism entities based on a named entity recognition model, and attaching the fault phenomenon entities and fault mechanism entities to the corresponding nodes of the product structure tree to generate a fault knowledge graph; parsing technical standard documents from the multidimensional data source, extracting standard specification entities and technical parameter entities based on a relation extraction model, constructing constraint relationships between standard specification entities and technical parameter entities, and mapping the constraint relationships to the product structure tree to generate a standard knowledge graph; and constructing a dual knowledge graph with the product structure tree as the common mapping center, connecting the fault knowledge graph and the standard knowledge graph respectively.

[0009] In the above embodiments, the data processing system, based on the lifecycle structure view, structurally mounts fault entities extracted from unstructured logs and standard documents with standard entities, forming two independent knowledge graphs that are linked through the product structure tree, thus ensuring the comprehensiveness of data sources and the regularity of knowledge structure.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the step of locating and determining the target component node in the product structure tree based on the device identity identifier and the fault occurrence time window specifically includes: parsing the device identity identifier to obtain device configuration version information and physical code; locating the corresponding time slice subtree in the product structure tree according to the fault occurrence time window and device configuration version information; retrieving leaf nodes that match the physical code in the time slice subtree, and marking the leaf nodes and their parent nodes as target component nodes.

[0011] In the above embodiments, the data processing system uses time slicing and version control positioning mechanisms to ensure that the analysis object is the exact physical component and its hierarchical structure at the time of the fault, avoiding component mismatch problems caused by product iteration updates and ensuring the accuracy of fault location.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the step of retrieving causal association paths connecting target component nodes and target fault phenomenon entities in the fault knowledge graph, and extracting entities on the paths as a candidate set of fault root causes, specifically includes: taking the target fault phenomenon entity as the endpoint and the fault entity associated with the target component node as the starting point, performing a reverse path search or a bidirectional path search in the fault knowledge graph to obtain all entity paths connecting the starting point and the endpoint; extracting fault cause entities from the entity paths, removing preset general stop word nodes, and determining the remaining entities as a candidate set of fault root causes.

[0013] In the above embodiments, the data processing system adopts a goal-oriented path search strategy to efficiently retrieve causal chains related to specific fault phenomena and components in the vast fault knowledge graph. This can converge the search space, quickly discover potential fault propagation paths, and eliminate common stop word nodes, making the final generated set of candidate fault root causes more focused and effective.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, before calculating the semantic similarity between the fault description text and entities in the fault knowledge graph to determine the target fault phenomenon entity, the method further includes: acquiring a specialized corpus in the industrial field, fine-tuning a pre-trained language model to obtain a domain embedding model; inputting the fault description text into the domain embedding model to identify non-standard terms; mapping the non-standard terms to standard fault terms based on a thesaurus in the fault knowledge graph; and generating a fault query vector based on the standard fault terms to perform semantic similarity calculation.

[0015] In the above embodiments, the data processing system converts colloquial and non-standard field terms into standardized entities in the knowledge graph, which solves the semantic gap problem caused by inconsistent expressions, makes semantic similarity calculation more accurate, and ensures the accuracy of fault phenomenon entity matching.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after obtaining the actual operating status data of the target component node, comparing the actual operating status data with the compliance parameter threshold, and generating a fault tracing report containing the comparison of the limit violation results, the method further includes: counting the cumulative frequency of the same candidate fault root cause being judged as parameter limit violation within a preset period; when the cumulative frequency exceeds a preset warning threshold, marking the corresponding compliance parameter threshold as a state to be revised in the standard knowledge graph; and constructing a reverse association edge from the state to be revised to the candidate fault root cause.

[0017] In the above embodiments, the data processing system can proactively identify compliance parameter thresholds that may have problems (such as unreasonable threshold settings or outdated thresholds), mark them as pending revision, provide data-driven decision-making basis for the maintenance and updating of standard documents, and realize continuous optimization of the knowledge base.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after constructing the reverse association edge pointing to the candidate fault root cause from the state to be revised, the method further includes: obtaining the operating status data of the target component node during the historical normal operation cycle; fitting the distribution characteristics of the data during the historical normal operation cycle based on a Gaussian distribution model to calculate and generate a dynamic reference threshold; associating the dynamic reference threshold with the compliance parameter threshold in the standard knowledge graph that is in the state to be revised, as a basis for parallel verification; when processing a new traceability request, simultaneously comparing the actual operating status data based on the compliance parameter threshold and the dynamic reference threshold, and generating a flexible judgment result containing risk warnings in the fault traceability report when the comparison results are inconsistent.

[0019] In the above embodiments, the data processing system can provide a reference baseline based on actual operating conditions and generate flexible judgment results when static standards may fail, providing maintenance personnel with more comprehensive information and risk warnings, and enhancing the robustness and reliability of diagnostic conclusions.

[0020] In a second aspect, embodiments of this application provide a data processing system comprising: one or more processors and a memory; the memory is coupled to the one or more processors and is used to store computer program code, the computer program code including computer instructions, wherein the one or more processors invoke the computer instructions to cause the data processing system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a data processing system, cause the data processing system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a data processing system, cause the data processing system to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the data processing system provided in the second aspect, the computer storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. By adopting a technical solution that constructs a dual knowledge graph including a fault knowledge graph, a standard knowledge graph, and a product structure tree, and by using the common mapping hub of the product structure tree in the fault tracing process to achieve the jump association from candidate fault root causes in the fault knowledge graph to compliance parameter thresholds in the standard knowledge graph, the data processing system can deeply integrate and link discrete, experience-based fault causal relationships with structured, standardized technical standard requirements. This enables rapid, accurate, and objectively supported tracing and location of the root causes of complex industrial product faults, improving the efficiency and reliability of operation and maintenance decisions.

[0026] 2. By employing a technical solution that parses device configuration version information based on device identity and combines it with the fault occurrence time window to locate the time slice subtree in the product structure tree, and then retrieves the leaf node matching the physical code within the subtree as the target component, the data processing system can accurately pinpoint the specific physical component at the moment of fault occurrence within the vast and dynamically evolving product lifecycle structure data. Large industrial products undergo multiple design changes, component replacements, and batch differences throughout their lifecycle, resulting in configurational differences for the same model of product at different times and in different individuals. This enables high-precision targeted localization of faulty components, defining the correct and minimized analysis scope for root cause analysis.

[0027] 3. By adopting the cumulative frequency of statistical candidate fault root causes being judged as parameter exceeding limits, when the frequency exceeds the threshold, the corresponding compliance parameter is marked as pending revision in the standard knowledge graph, and a reverse association edge is constructed. Therefore, the data processing system establishes a dynamic feedback and self-correction mechanism from the application layer to the knowledge layer, realizing the continuous learning and evolution capability of the standard knowledge graph, enabling it to dynamically adapt to changes in the external environment and equipment status, ensuring the freshness and accuracy of the knowledge base, and fundamentally improving the long-term reliability of the fault tracing system. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of a topological structure of a dual knowledge graph in an embodiment of this application;

[0029] Figure 2 This is a flowchart illustrating a fault tracing method based on dual knowledge graphs in an embodiment of this application;

[0030] Figure 3 This is a structural diagram of the entity relationship definition and data model in the embodiments of this application;

[0031] Figure 4 This is a schematic diagram of the product structure decomposition and traceability process in the embodiments of this application;

[0032] Figure 5 This is another flowchart illustrating the fault tracing method based on dual knowledge graphs in this application embodiment;

[0033] Figure 6 This is a schematic diagram of an implementation scenario of the fault tracing method based on dual knowledge graphs in this application.

[0034] Figure 7 This is a schematic diagram of another implementation scenario of the fault tracing method based on dual knowledge graphs in this application;

[0035] Figure 8This is a schematic diagram of the physical device structure of a data processing system in an embodiment of this application. Detailed Implementation

[0036] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0037] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0038] In the specific implementation scenarios of this application, fault tracing analysis of some complex equipment is involved. These complex equipment include rail transit vehicles, aircraft, large energy equipment, and precision instruments. For ease of understanding, the following uses the fault tracing of the braking system of a rail transit vehicle as an example to explain the relevant technical terms and technical logic. The industrial product to be analyzed refers to a specific model of train. The multidimensional data sources include: the bill of materials (BOM) during the train design phase, the maintenance BOM recording the history of component replacement and repair during the operation and maintenance phase, unstructured fault logs containing fault codes and free text descriptions recorded by the onboard monitoring system, and the technical standard document system promulgated by the state or industry regarding the requirements for train braking performance, component materials, etc.

[0039] In the dual knowledge graph built upon these data sources, the product structure tree is the core. This structure tree, through the integration of design and operation BOMs, constructs a tree-like structure that reflects the hierarchical relationships from the whole vehicle, system, subsystem to specific parts (such as brake discs and brake pads), and can trace version changes. The fault knowledge graph links fault phenomenon entities such as excessive braking distance extracted from fault logs with fault mechanism entities such as severe brake pad wear and insufficient braking pressure through causal relationships, and attaches them to the corresponding part nodes in the product structure tree.

[0040] The standard knowledge graph parses technical standard documents, associating standard specification entities such as TB / Txxxx with technical parameter entities and thresholds such as the minimum brake pad thickness and the rated pressure range of the brake cylinder, and also mapping them to the corresponding nodes in the product structure tree.

[0041] Please see Figure 1 This is a schematic diagram of a topology of the dual knowledge graph in this application embodiment. As shown in the figure, this topology illustrates the core ternary architecture of this application. The left area is the fault knowledge graph, which contains entity nodes such as fault phenomena (e.g., excessive braking distance), fault causes (e.g., brake pad wear), and solutions. These nodes are connected by causal relationship chains. The right area is the standard knowledge graph, which contains entity nodes such as referenced files (standard documents, such as national standards GB, railway standards TB), standard types, and standard parameters (e.g., thickness threshold, pressure range). These nodes are connected by constraint relationships. The middle area is the product structure tree, which serves as the central hub of the common mapping. It vertically displays the hierarchical decomposition relationship from platform, project, train, system to specific components. Figure 1 This demonstrates how the left and right knowledge graphs are interconnected through the central product structure tree: fault phenomena and causes in the fault knowledge graph are attached to specific component nodes in the product structure tree; simultaneously, standard parameter entities in the standard knowledge graph are mapped to the same component nodes in the product structure tree. This topology allows the data processing system to make bidirectional jumps between the fault domain and the standard domain, using components as anchor points.

[0042] When a traceability request is received, the device identification (such as vehicle number + component serial number) and the fault occurrence time window are used to precisely locate the specific brake disc that failed within the product structure tree. Through semantic computation, the "brakes not working" input by maintenance personnel is mapped to the "excessive braking distance" entity in the fault knowledge graph. Subsequently, causal paths from the brake disc node to the excessive braking distance node are retrieved to obtain candidate root causes such as brake pad wear.

[0043] Finally, through the mapping of the product structure tree, the system jumps to the standard knowledge graph to find the minimum thickness of the brake pads—a compliance parameter threshold—and compares it with the actual thickness data collected by the sensors. This generates a traceability report containing brake pad thicknesses below the standard threshold, completing root cause confirmation. This process demonstrates the necessity and rationality of the solution in fusing multi-source heterogeneous data and achieving automated and intelligent traceability from phenomenon to root cause to standard verification.

[0044] The following describes the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is a flowchart illustrating a fault tracing method based on dual knowledge graphs in an embodiment of this application.

[0045] S201. Obtain multidimensional data sources for the industrial products to be analyzed.

[0046] The industrial products to be analyzed refer to complex equipment that requires fault analysis, such as rail transit vehicles, aircraft, large energy equipment, and precision instruments. Multidimensional data sources refer to a diverse collection of data related to the entire lifecycle of the product's design, manufacturing, and operation, including but not limited to structured bills of materials (BOMs), semi-structured equipment ledgers, and unstructured fault logs and technical standard documents.

[0047] Specifically, before initiating a fault tracing task, the data processing system first needs to access and integrate the required data. This step involves acquiring data in batches or in real-time from multiple information systems, such as Enterprise Resource Planning (ERP), Product Lifecycle Management (PLM), Manufacturing Execution System (MES), and Maintenance and Repair (MRO) systems, through pre-defined data interfaces or data acquisition agents. For example, it might retrieve the design BOM from the PLM system, the maintenance BOM and fault repair records from the MRO system, and technical standard PDF documents from a file server.

[0048] S202. Construct a dual knowledge graph based on multi-dimensional data sources.

[0049] The dual knowledge graph refers to a composite knowledge graph structure consisting of two core graphs: a fault knowledge graph and a standard knowledge graph, along with a product structure tree serving as a connecting hub. The fault knowledge graph represents the causal relationships between fault phenomena, mechanisms, and causes. The standard knowledge graph represents the constraint relationships between technical standards, specifications, and parameters. The product structure tree represents the hierarchical decomposition structure of a product from the complete machine to its components.

[0050] Specifically, the data processing system executes a knowledge extraction and graph construction process. First, it parses the design BOM and operation BOM, identifying and merging nodes referring to the same physical entity using an entity alignment algorithm to construct a unified product structure tree. Then, it uses Named Entity Recognition (NER) and Relation Extraction (RE) technologies to process unstructured fault logs and technical standard documents, extracting fault-related entities and relationships, as well as standard-related entities and relationships. Finally, it loads these entities and relationships into a graph database and links fault-related and standard-related entities to their corresponding component nodes in the product structure tree, forming the final dual knowledge graph.

[0051] like Figure 3 As shown, Figure 3 This is a structural diagram of the entity relationship definition and data model in the embodiments of this application. Figure 3This paper details the underlying ontology construction logic of the dual knowledge graph. The model is primarily divided into three interconnected regions: the left region defines the hierarchical inclusion relationships between systems, subsystems, components, and parts, describing the belonging logic of the physical world and encompassing basic attributes such as product lines, products, specifications, parameters, models, and dimensions, with data types defined as strings; the middle region uses structural entities as its core hub, not only connecting the physical hierarchy of the left region but also linking information such as manufacturers and their respective specialties, acting as a bridge between the physical and knowledge worlds; the right region defines the knowledge dimensions of faults and standards in detail. The fault dimension includes causal chains between fault phenomena, causes, modes, and states, and links specific attributes such as fault occurrence time, frequency, description, and severity. The maintenance and process dimensions further link entities such as maintenance methods, maintenance personnel, equipment, and process defects, clarifying the data structure for process optimization principles and parameter optimization. Through this definition of entity relationships, the system can map discrete multidimensional data sources into structured graph data.

[0052] Please see Figure 4 , Figure 4 This is a schematic diagram of the product structure decomposition and traceability process in an embodiment of this application. Figure 4 This diagram intuitively demonstrates how to link macroscopic knowledge documents with microscopic physical components. The upper part of the diagram shows that the knowledge originates from GB national standards, TB standards, CRRC standards, and various design and quality planning case studies. The middle part displays a concrete, instantiated product structure tree, which is vertically decomposed according to the hierarchy of platform-project-train number-vehicle number-system-component-part. For example, it decomposes from the EMU platform to the SFE32 project, then further refines to the bogie of car 01, and finally locates leaf nodes such as wheels, clearly expressing the hierarchical relationship after the integration of the design BOM and the operation and maintenance BOM. The lower part of the diagram shows the logic of fault object attachment, i.e., the configuration fault tree. It accurately attaches knowledge entities such as fault causes, fault modes, and fault analysis to specific structure tree nodes such as primary vertical dampers or axle box springs, thereby achieving knowledge tracing and location from documents to specific physical components.

[0053] S203. Receive a traceability request containing a fault description text, device identification, and fault occurrence time window.

[0054] A tracing request is a query command initiated by a user or external system to explore the root cause of a specific fault. The fault description text is a natural language description of the fault phenomenon entered by maintenance personnel. The device identification identifier is a code used to uniquely identify the faulty device and may include information such as model number, serial number, and physical code. The fault occurrence time window is the time interval between the occurrence and duration of the fault.

[0055] Specifically, the data processing system receives traceability requests through its front-end application interface or API. For example, maintenance personnel enter a fault description in a web form: an abnormal noise occurred during emergency braking of a train. They then select the corresponding vehicle number and the approximate time period in which the fault occurred, and submit the request. After the back-end service of the data processing system listens for this request, it parses the various fields in the request body and structures them into data objects required for internal processing tasks.

[0056] In some embodiments, request reception can be implemented in several ways: Optionally, a graphical user interface (GUI) can be provided, allowing users to submit requests by filling out forms and using selectors; this method is user-friendly and suitable for manual operation. Optionally, a standardized set of RESTful APIs can be provided, allowing other automated monitoring systems to programmatically call this interface to initiate tracing requests when an anomaly is detected; this method facilitates system integration. It is understood that other methods can also be used to implement request reception, such as through a command-line interface (CLI) or parsing email requests in a specific format; this is not limited here.

[0057] S204. Based on the device identification and the fault occurrence time window, locate the target component node in the product structure tree.

[0058] In this context, the target component node refers to the graph node in the product structure tree that directly corresponds to the specific physical component targeted by the traceability request, along with its related parent nodes. These nodes constitute the starting point and scope for subsequent fault cause analysis.

[0059] Specifically, the data processing system first parses the device identification, extracting information such as device model, batch, and unique serial number, which correspond to a specific configuration version of the product. Next, using the fault occurrence time window, it filters out valid version configurations within the product structure tree containing historical version information. Finally, in the determined version configuration subtree, based on the physical code or serial number in the device identification, it precisely retrieves the corresponding leaf node and identifies it, along with its parent node at a certain level, as the target component node.

[0060] In some embodiments, there may be situations where the device identification is incomplete, making it impossible to uniquely identify a leaf node. In such cases, the data processing system will return a list of candidate components. For example, if only a system-level identifier is provided, the system will consider all sub-components under that system as candidate target component nodes, and will examine each candidate in subsequent analysis, or prompt the user to further clarify the specific component.

[0061] S205. Calculate the semantic similarity between the entities in the fault description text and the fault knowledge graph to determine the target fault phenomenon entity.

[0062] Semantic similarity refers to the metric that measures the degree of semantic closeness between two texts. The target fault phenomenon entity refers to the predefined fault phenomenon node in the fault knowledge graph that best matches the semantics of the fault description text input by the user, such as abnormal braking noise or weak traction.

[0063] Specifically, the data processing system first converts the user-input fault description text and the text descriptions of all fault phenomenon entities in the fault knowledge graph into high-dimensional vector representations (Embeddings) using a pre-trained or domain-fine-tuned language model (such as BERT). Then, it calculates a similarity score list by measuring the cosine similarity or other distance metrics between the user-input text vector and each phenomenon entity vector. Finally, it selects the fault phenomenon entity with the highest score as the target fault phenomenon entity.

[0064] S206. In the fault knowledge graph, retrieve the causal relationship path connecting the target component node and the target fault phenomenon entity, and extract the entities on the path as a set of candidate fault root causes.

[0065] In this context, a causal path refers to a directed path in a fault knowledge graph that starts from a node representing a physical component, passes through a series of causal edges (such as those causing or triggering faults), and ultimately reaches the entity node representing the target fault phenomenon. The candidate root cause set refers to the set of all entity nodes along this path that are defined as fault causes or fault mechanism types.

[0066] Specifically, the data processing system uses the target component node determined in step S204 and the target fault phenomenon entity determined in step S205 as the starting and ending points of the graph search. A path search algorithm is executed on the fault knowledge graph to find all paths connecting these two endpoints. After finding all paths, the system traverses all intermediate nodes on each path, extracts nodes that meet the predefined criteria (such as fault causes) based on the node's predefined type, and summarizes them to form a candidate fault root cause set.

[0067] In some embodiments, path retrieval can be implemented in several ways: Optionally, a breadth-first search (BFS) algorithm can be used, which guarantees finding the shortest causal path, typically representing the most direct causal chain. Optionally, a bidirectional search algorithm can be used, that is, searching simultaneously from both the starting and ending points; a path is found when the two search fronts meet. This method is generally more efficient than unidirectional search in large graphs. It is understood that other graph algorithms such as A* search can also be used, and paths can be sorted according to the weights of relation edges (such as historical probability of occurrence); this is not limited here.

[0068] In some embodiments, there may be too many retrieved causal paths, resulting in a large set of candidate root causes that are difficult to identify. To address this, the data processing system performs path pruning and sorting. For example, pruning can be performed based on path length, prioritizing shorter causal chains; or the total score of the path can be calculated based on the historical frequency of each relationship on the path or the weights assigned by experts, and the candidate root causes corresponding to the highest-scoring paths can be displayed to the user first.

[0069] S207. Traverse each candidate fault root cause in the candidate fault root cause set, jump to the standard knowledge graph through the common mapping hub of the product structure tree, and determine the compliance parameter threshold corresponding to the corresponding candidate fault root cause.

[0070] In this context, the public mapping hub refers to the role of the product structure tree in the dual knowledge graph. It is associated with both faulty entities and standard entities, acting as a bridge. Compliance parameter thresholds refer to the specific values ​​or ranges specified in technical standard documents for measuring whether the performance or condition of a component is qualified; for example, brake pad thickness should not be less than 10mm.

[0071] Specifically, the data processing system iterates through the candidate root cause set generated in step S206. For each candidate root cause (e.g., brake pad wear), the root cause entity was attached to a component node (e.g., the brake pad node) in the product structure tree during construction. Using this link, the system first locates the brake pad node in the product structure tree, and then checks if the node has an associated standard knowledge graph entity. If there is an association (e.g., associated with the brake pad wear limit parameter in the braking system technical specifications), the specific compliance parameter threshold (e.g., 10mm) is extracted from it.

[0072] In some embodiments, the jump and threshold determination can be implemented in several ways: Optionally, in a graph database, candidate root cause nodes, product structure tree nodes, and standard parameter nodes are connected by direct relational edges, and can be directly obtained through one or two-step graph queries. Optionally, an external mapping table (such as a hash table) can be maintained, with the key being the candidate root cause entity and the value being its corresponding standard parameter entity identifier, enabling fast jumps through table lookups. Understandably, rule-based reasoning can also be used, for example, if the rule is that the root cause is XX wear, then look up the XX thickness standard; this is not limited here.

[0073] S208. Obtain the actual operating status data of the target component node within the fault occurrence time window, compare the actual operating status data with the compliance parameter threshold, and generate a fault tracing report containing the comparison results of exceeding the limit.

[0074] The actual operating status data refers to the real physical quantities or state values ​​of the target component during a fault, collected from sensors, monitoring systems, or detection equipment. The comparison of exceedance results refers to the conclusions drawn by comparing actual data with standard thresholds, such as normal, exceeding the upper limit, or below the lower limit. The fault tracing report is a document summarizing the entire analysis process and the final conclusions.

[0075] Specifically, the data processing system initiates a query request to a time-series database or data lake based on the target component node and the time window of the failure, obtaining the corresponding sensor data (e.g., the measured value of brake pad thickness). Then, this actual data is numerically compared with the compliance parameter threshold obtained in step S207. Finally, all candidate root causes and their comparison results are summarized to generate a structured report. The report highlights candidate root causes whose actual data exceeds the compliance threshold and marks them as the most likely root causes.

[0076] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 5 This is another flowchart illustrating the fault tracing method based on dual knowledge graphs in this application embodiment.

[0077] S501. Obtain multidimensional data sources for the industrial products to be analyzed.

[0078] Refer to step S201, which will not be repeated here.

[0079] S502. Construct a dual knowledge graph based on multi-dimensional data sources.

[0080] Refer to step S202, which will not be repeated here.

[0081] In some embodiments, the data processing system parses the design bill of materials (BOM) and maintenance bill of materials (BOM) from the multidimensional data source, merges the nodes with the same name in the design BOM and maintenance BOM based on an entity alignment algorithm, and constructs a product structure tree; it extracts unstructured fault logs from the multidimensional data source, extracts fault phenomenon entities and fault mechanism entities based on a named entity recognition model, and attaches the fault phenomenon entities and fault mechanism entities to the corresponding nodes in the product structure tree to generate a fault knowledge graph; it parses technical standard documents from the multidimensional data source, extracts standard specification entities and technical parameter entities based on a relation extraction model, constructs constraint relationships between standard specification entities and technical parameter entities, and maps the constraint relationships to the product structure tree to generate a standard knowledge graph; and it constructs a dual knowledge graph with the product structure tree as the common mapping center, connecting the fault knowledge graph and the standard knowledge graph respectively.

[0082] The Design Bill of Materials (BOM) refers to the hierarchical relationships of components and the theoretical material requirements defined during the product design phase. The Maintenance Bill of Materials (BOM) reflects the actual equipment configuration and maintenance / replacement records during actual operation and maintenance. Entity alignment algorithms are used to identify and merge different nodes referring to the same physical entity in two BOMs. Named Entity Recognition (NER) models are used to automatically extract predefined entity types from text, such as fault phenomena. Relationship Extraction (RE) models are used to identify relationships between entities, such as causal relationships or constraint relationships.

[0083] Specifically, this construction process forms the data foundation of the entire method. The data processing system first processes the BOM data. For example, a component in the design BOM might be called a brake pump, while in the maintenance BOM it might be recorded as brake master pump - model A. The entity alignment algorithm determines that they are the same entity based on features such as name similarity and position in the structure tree, thus creating a node that integrates information from both in a unified product structure tree. Next, the system applies the NER model to process vehicle vibration during braking, checking and finding fault logs such as brake disc overheating, extracting two entities: vehicle vibration (fault phenomenon) and brake disc overheating (fault mechanism), and establishing a causal relationship. Then, the system applies the RE model to process the standard T123, which stipulates that the brake disc operating temperature must not exceed 300 degrees Celsius, extracting standard T123 (specification entity) and operating temperature (parameter entity), establishing constraint relationships, and extracting 300 degrees Celsius as a threshold. Finally, both brake disc overheating and operating temperature are linked to the brake disc node in the product structure tree, completing the construction and association of the dual graphs.

[0084] In some embodiments, the construction process can be implemented in several ways: Optionally, entity alignment can employ a hybrid algorithm based on string similarity (such as Jaro-Winkler distance) and graph structure similarity; NER and RE can be based on traditional machine learning models such as CRF and BiLSTM-CRF, or fine-tuned using more advanced pre-trained language models such as BERT. Optionally, for parsing standard documents, scanned PDFs can be processed first using OCR technology, then layout analysis models can be used to identify tables and clauses, and then information extraction can be performed; the entire construction process can be scheduled and managed through workflow engines such as Airflow. Understandably, a manual verification step can also be introduced to review and correct the entities and relationships extracted by the model to ensure the quality of the knowledge graph; this is not limited here.

[0085] In some embodiments, inconsistent IDs between heterogeneous data sources can lead to difficulties in entity alignment and mounting. For example, the design BOM uses design drawing numbers, the maintenance BOM uses material codes, while the fault log only contains the natural language names of components. To address this, the data processing system constructs a Master Data Management (MDM) module. This module is dedicated to creating a unique golden ID for each physical entity and maintaining a mapping table from this golden ID to different IDs in various source systems. When building the graph, all entities are first mapped to this golden ID before subsequent fusion and mounting, thus solving the problem of inconsistent IDs.

[0086] S503: Receive a traceability request containing a fault description text, device identification, and the fault occurrence time window.

[0087] Refer to step S203, which will not be repeated here.

[0088] S504. Parse the device identity identifier to obtain the device configuration version information and physical code.

[0089] Among them, the equipment identification identifier is a string or code that can uniquely identify a specific physical instance of an industrial product. It is usually defined by the manufacturer and may combine product model, production batch, serial number, etc. The equipment configuration version information refers to a set of information parsed from the identifier that indicates the design version, software version, or key component configuration of the equipment.

[0090] Specifically, after receiving a device identifier such as TRAIN_G1234-BCU_S5678, the data processing system invokes a predefined parser. This parser segments the identifier into several parts according to predetermined rules (such as using separators - and _). For example, TRAIN_G1234 is identified as vehicle information, where G1234 may represent a specific batch, while BCU_S5678 represents the brake control unit and its serial number. The system queries its internal configuration management database or version mapping table to map the G1234 batch to its corresponding design BOM version V2.1, thereby obtaining accurate device configuration version information.

[0091] In some embodiments, version information can be obtained in several ways: Optionally, version information can be directly encoded in the device identifier, such as TRAIN_G1234_V2.1-BCU..., and extracted directly during parsing. Optionally, a mapping database from device serial number ranges to configuration versions can be maintained, and the version can be determined by querying the range in which serial number S5678 falls; this method is applicable when the identifier itself does not contain version information. It is understood that it is also possible to query its detailed configuration in real time by calling the API of an external product management system and passing in the device identifier; this is not limited here.

[0092] In some embodiments, there may be situations where equipment has undergone on-site modifications, resulting in a discrepancy between its actual configuration and the factory configuration. In such cases, the data processing system prioritizes the records in the Maintenance Bill of Materials (M-BOM). After parsing the identifier, the system checks the M-BOM for any component replacement records related to that serial number. If found, the system uses the replaced component version as its current actual configuration version, ensuring the timeliness of the information.

[0093] S505. Based on the fault occurrence time window and device configuration version information, locate the corresponding time slice subtree in the product structure tree.

[0094] The time-slice subtree refers to a specific subset of configurations that is valid at a given time point and version, selected from the overall product structure tree that records the entire product lifecycle evolution. It represents the true structure of the product at the time of failure.

[0095] Specifically, when constructing the product structure tree of the data processing system, each node and relationship is accompanied by two attributes: effective start time and effective end time. Upon receiving the fault occurrence time window (e.g., from 10:00 AM on December 27, 2025 to 10:05 AM on December 27, 2025) and the configuration version information obtained in step S504, the system executes a graph query. The query condition is to filter out all nodes and relationships with matching version numbers whose effective time intervals intersect with the fault time window. The subgraph formed by these nodes and relationships that meet the conditions is the time-slice subtree.

[0096] In some embodiments, subtree location can be achieved in several ways: Optionally, the entire graph can be traversed, and the timestamp and version attributes of each node and relation can be checked one by one to see if they meet the conditions. Optionally, an index can be created for the timestamp and version attributes in the graph database, and efficient queries can be performed through the index to directly return the subgraph that meets the conditions. This method has better performance in large-scale graphs. It is understood that structures of different versions or time periods can also be stored in different graph spaces or layers, and the corresponding layer can be selected directly during location. This is not limited here.

[0097] In some embodiments, the evolution record of the product structure tree may be incomplete, resulting in a situation where a perfectly matching configuration cannot be found within a certain time window. To address this, the data processing system employs the nearest-neighbor principle. That is, if no accurate configuration record is found within the failure time window, the system automatically backtracks and uses the known valid configuration closest to and prior to the failure time point as the analysis benchmark. This is noted in the final report when this occurs, indicating a potential risk of configuration information uncertainty.

[0098] S506. Retrieve leaf nodes that match the physical encoding in the time slice subtree, and mark the leaf nodes and their parent nodes as target component nodes.

[0099] The physical code is the part of the device identification used to uniquely identify the lowest-level replaceable unit (LRU), such as the serial number of a specific sensor. A leaf node is the terminal node in the product tree structure that has no child nodes, typically representing a specific part. A parent node is a node directly connected to and located one level above a leaf node in the tree structure, typically representing the subsystem or module to which the part belongs.

[0100] Specifically, after obtaining the precise time-slice subtree in step S505, the data processing system extracts the physical code (such as S5678) from the device identifier. Then, it searches through all leaf nodes of this subtree to find the node whose serial number or physical code attribute value matches S5678. Once this leaf node is found, the system marks it as one of the target component nodes. Simultaneously, it traces back one level along the is_part_of relationship in the graph, marking its direct parent node (e.g., the brake control unit) as a target component node as well.

[0101] In some embodiments, node retrieval and labeling can be implemented in several ways: Optionally, all leaf nodes of the time slice subtree can be traversed, and attribute values ​​can be compared one by one. Optionally, if the physical encoding attribute has been indexed, a fast lookup with O(1) or O(logN) complexity can be performed directly through the index. The labeling process can add a temporary label to the node object in memory or add a temporary attribute to the node in the graph database. It is understood that the number of levels to mark the parent node can be configurable, for example, marking up to the system level to expand the scope of the initial analysis, which is not limited here.

[0102] In some embodiments, a physical code may be theoretically unique, but duplicates may occur due to data entry errors. To address this, when the data processing system retrieves multiple matching leaf nodes, it triggers a disambiguation process. The system checks the parent paths of these duplicate nodes and compares them with other information in the device identifier (such as the subsystem code), selecting the node with the most matching path information. If a match still cannot be determined, all matching nodes are marked as targets, and the risk of data inconsistency is reported.

[0103] S507. Calculate the semantic similarity between entities in the fault description text and the fault knowledge graph to determine the target fault phenomenon entity.

[0104] Refer to step S205, which will not be repeated here.

[0105] In some embodiments, the data processing system further performs a preprocessing step before semantic similarity calculation. Specifically, the data processing system acquires a specialized corpus for the industrial field, fine-tunes the pre-trained language model to obtain a domain embedding model, inputs the fault description text into the domain embedding model to identify non-standard terms, maps the non-standard terms to standard fault terms based on the thesaurus in the fault knowledge graph, and generates a fault query vector based on the standard fault terms to perform semantic similarity calculation.

[0106] Specifically, the industry-specific corpus refers to a dataset containing a large amount of industry-specific text, such as maintenance manuals, fault reports, and technical forum discussions. Pre-trained language models are models like BERT and GPT that have been trained on general, large-scale corpora. Fine-tuning refers to further training the model on the specific corpus to better adapt it to the language styles and terminology within the domain. Non-standard terminology refers to colloquial, abbreviated, or non-standard expressions used by operations and maintenance personnel. The thesaurus is a pre-built knowledge base that stores the correspondence between non-standard and standard terms.

[0107] Specifically, the data processing system first fine-tunes a general BERT model using a large amount of text from the rail transit field. When it receives user input about brake shuddering, the domain embedding model understands that shuddering is semantically similar to shaking in a braking scenario. The system may recognize that shuddering is a non-standard term. Subsequently, it queries a thesaurus (which may contain mappings such as shuddering → shaking, ineffective → malfunction) to convert brake shuddering into brake shaking. Finally, the system uses the domain embedding model to generate a query vector from the standardized brake shaking text, and then uses this vector to calculate similarity with the vectors of standard fault phenomenon entities such as brake shaking and vehicle body shaking in the fault knowledge graph.

[0108] In some embodiments, this preprocessing can be implemented in several ways: Optionally, the thesaurus can be manually constructed by domain experts to ensure accuracy; alternatively, a word embedding model (such as Word2Vec) can be trained on a domain corpus to automatically discover semantically similar word clusters and semi-automatically construct the thesaurus. Optionally, the identification of non-standard terms can be based on dictionary matching or by training a sequence labeling model for automatic identification. The query vector can be generated by directly using the word vectors of standardized terms or by using the sentence vector of the entire sentence containing the term as the query vector. Understandably, an interactive element can also be introduced, providing the user with several candidate standard terms to choose from when the system is uncertain about the term mapping; this is not limited here.

[0109] In some embodiments, a non-standard term may map to different standard terms in different contexts. For example, "low pressure" might refer to insufficient tire pressure when describing a tire, but to low hydraulic oil pressure when describing a hydraulic system. To address this, the data processing system considers contextual information when performing term mapping. The system not only considers the word "low pressure" but also analyzes other words in the sentence containing it, such as "tire" and "hydraulic cylinder." By using these contextual clues and combining them with knowledge of the product structure tree, the system can more accurately determine which specific standard fault term "low pressure" should map to.

[0110] S508. In the fault knowledge graph, retrieve the causal relationship path connecting the target component node and the target fault phenomenon entity, and extract the entities on the path as a set of candidate fault root causes.

[0111] Refer to step S206, which will not be repeated here.

[0112] In some embodiments, the data processing system further retrieves detailed steps for candidate root causes of failure. Specifically, the data processing system takes the target fault phenomenon entity as the endpoint and the fault entity associated with the target component node as the starting point, performs a reverse path search or a bidirectional path search in the fault knowledge graph to obtain all entity paths connecting the starting point and the endpoint; extracts the fault cause entities from the entity paths, removes preset general stop word nodes, and determines the remaining entities as the set of candidate root causes of failure.

[0113] Reverse path search refers to starting from the endpoint node and performing a breadth-first or depth-first search along the opposite direction of the relationship edges. Bidirectional path search means searching simultaneously from both the starting and ending points; a path is found when the two search ranges intersect. General stop word nodes are intermediate nodes that are prevalent in the causal chain of a failure but do not provide a specific cause, such as those indicating abnormal states or performance degradation.

[0114] Specifically, assuming the target component is the brake disc and the target symptom is abnormal brake noise, the data processing system uses the abnormal brake noise as the endpoint and the brake disc as the starting point. A reverse search starts with the abnormal brake noise, finding entities that might cause it, such as brake shudder, then finding entities that cause brake shudder, such as uneven brake disc, until a node on a certain path is the brake disc or its child node, indicating a successful search. A bidirectional search starts with both the brake disc and the abnormal brake noise. A path might be found like this: Brake disc → has_fault → Uneven brake disc → causes → Brake shudder → Manifestation → Abnormal brake noise. The system extracts uneven brake disc and brake shudder from the path as causative entities. If stop word nodes (such as those indicating abnormal states) appear in the path, they are removed and not added to the final set of candidate root causes.

[0115] Please see Figure 6 , Figure 6 This is a schematic diagram of an implementation scenario of the fault tracing method based on dual knowledge graphs in this application. Figure 6 The system demonstrates a visual interactive process when handling traceability requests. The upper half of the interface displays a visual product structure tree, allowing users or the system to clearly see the hierarchical path from vehicle model E01 down to the electrical and distribution panel, and then to the specific automatic phase-change system and connecting switches. This corresponds to the location process of the target component node. The lower half of the interface displays an analysis view of related faults. When a component is locked, the system automatically retrieves and displays specific fault phenomena, such as the tilt of the phase-change solenoid cylinder, and presents the causal path leading to the phenomenon in the form of a directed graph. For example, the path points to improper operation and maintenance, while also relating to deeper factors such as the company's product design quality and manufacturing process quality. Corresponding solutions such as repair, replacement, or upgrade are provided to help maintenance personnel quickly understand the fault mechanism.

[0116] In some embodiments, the retrieval process can be implemented in several ways: Optionally, Depth-First Search (DFS) can be used to find all possible paths, suitable for exploring complex, deep causal relationships. Optionally, Iterative Deeper Depth-First Search (IDDFS) can be used, which combines the spatial advantages of DFS and the shortest path advantage of BFS, and can find shorter causal chains more quickly. For the removal of stop word nodes, a stop word list can be maintained in advance and filtered when extracting entities. Understandably, different weights can also be set for different relation types, and these weights can be considered in the path search to prioritize finding high-probability causal paths; this is not limited here.

[0117] In some embodiments, loops may exist in the graph, causing pathfinding to infinite loops or generating infinite paths. To address this, the data processing system records the nodes already visited on each search branch when executing the pathfinding algorithm. When expanding the path, if the next node to be visited already exists in the current path, it indicates a loop has been encountered, and the algorithm abandons this expansion direction and explores other branches instead. This access history checking mechanism effectively avoids loop problems, ensuring the termination and efficiency of the search process.

[0118] S509. Traverse each candidate fault root cause in the candidate fault root cause set, jump to the standard knowledge graph through the common mapping center of the product structure tree, and determine the compliance parameter threshold corresponding to the corresponding candidate fault root cause.

[0119] Refer to step S207, which will not be repeated here.

[0120] Please see Figure 7This figure is a schematic diagram of another implementation scenario of the fault tracing method based on dual knowledge graphs in this application. Figure 7 This demonstrates the application of a standard knowledge graph in compliance parameter extraction. The graph centers on the brake hose, radiating outwards to connect its associated piping systems and hierarchical relationships with air supply and braking systems, while also linking its specific physical properties and technical standards. Specifically, the graph clearly defines the brake hose's working pressure as 0.9 MPa, its operating temperature range as -50°C to 70°C, and its material as EPDM rubber. These parameters directly point to specific national or industry standard documents such as GB / T 1222-2007 or CB / T 1348-2009. During fault tracing, the system, based on this graph structure, can automatically jump from the root cause of the fault to this type of view, accurately extracting compliance parameter thresholds such as 0.9 MPa for subsequent comparative analysis with actual operating data.

[0121] S510. Statistically count the cumulative frequency of the same candidate fault root cause being judged as having parameters exceeding limits within a preset period.

[0122] The preset period is a configurable time span, such as the past 30 days or 90 days. The same candidate root cause refers to the same entity identified as a potential cause in multiple different fault tracing tasks, such as oil pressure sensor drift. Parameter exceeding limits means that in a certain tracing, the actual operating data corresponding to the root cause is confirmed to exceed its compliance parameter threshold. Cumulative frequency is the total number of times the event has occurred.

[0123] Specifically, the data processing system maintains a historical database of fault analysis. Whenever a tracing task is completed (e.g., after step S513), if the report indicates a parameter exceeding the limit, the system records the candidate root cause entity that caused the limit exceedance and the time of occurrence. During this step, the system queries this historical database and, for each candidate root cause identified in the current tracing task, calculates the total number of times it appears as a cause of exceeding the limit within a preset period.

[0124] In some embodiments, frequency statistics can be implemented in several ways: Optionally, a historical record table can be created in a relational database, containing fields such as root cause ID, timestamp, and whether the limit was exceeded, and statistics can be performed using SQL's COUNT and GROUPBY statements. Optionally, in a graph database, an attribute for the number of times the limit was exceeded can be added to each root cause entity node, and this attribute is incremented each time a limit is exceeded; simultaneously, a background task can be used to periodically decay the weight of older records to achieve sliding time window statistics. It is understood that a stream processing engine such as Flink can also be used to calculate the frequency within the time window in real time, which is not limited here.

[0125] In some embodiments, there may be ambiguity in defining the same candidate root cause of a fault, such as whether sensor A drift and inaccurate sensor A readings are the same root cause. To address this, the data processing system establishes a synonym or equivalence relation layer when constructing the fault knowledge graph. During statistical analysis, the system normalizes these synonymous entities, mapping them to the same standard entity ID for cumulative counting, ensuring statistical accuracy.

[0126] S511. When the cumulative frequency exceeds the preset warning threshold, the corresponding compliance parameter threshold is marked as pending revision in the standard knowledge graph.

[0127] The preset warning threshold is a value set based on experience or statistical analysis, such as more than 5 occurrences within 30 days. The compliance parameter threshold is the standard value associated with this high-frequency failure root cause. The "pending revision" status is a special label or attribute used to indicate that the standard parameter may have problems and requires manual review.

[0128] Specifically, after calculating the cumulative frequency of each candidate fault root cause in step S510, the data processing system compares this frequency with a preset warning threshold. If the frequency of a certain root cause (e.g., oil pressure sensor drift) exceeds the threshold (e.g., 6 times), the system will trigger a marking process. It will first locate the compliance parameter entity (e.g., normal oil pressure range) associated with oil pressure sensor drift, and then add a status attribute to the parameter entity node and assign it the value pending_revision.

[0129] In some embodiments, the marking can be implemented in several ways: Optionally, the attribute value of the node in the graph database can be directly modified. Optionally, instead of directly modifying the original node, a new warning node can be created next to it and pointed to the parameter node through a flags relationship; this method can retain the operation history and facilitate auditing. It is understood that, in addition to marking the status, the system can also trigger a notification mechanism at the same time, such as sending an email or notifying the engineering team responsible for standards management through instant messaging tools; this is not limited here.

[0130] In some embodiments, an unreasonable warning threshold setting may lead to false alarms (threshold too low) or missed alarms (threshold too high). To address this, the data processing system can introduce a dynamic threshold adjustment mechanism. The system can analyze the frequency distribution of all root causes of failures and automatically suggest or adjust the warning threshold based on statistical methods (such as percentiles) to adapt it to the overall failure rate of the system.

[0131] S512. Construct reverse association edges that point to candidate root causes of failures in the state to be revised.

[0132] Among them, the reverse association edge refers to creating a new directed edge in the knowledge graph, starting from the standard parameter entity that is marked as being in a state to be revised, and pointing to the high-frequency candidate root cause entity that triggered this marking.

[0133] Specifically, after step S511 marks a parameter entity (such as the normal oil pressure range) as pending revision, the data processing system will immediately perform an edge creation operation in the graph database. This operation uses the normal oil pressure range entity as the starting point of the edge and a frequently occurring candidate root cause of failure entity (such as oil pressure sensor drift) as the ending point of the edge. The edge type can be named flagged_by_cause or a similar name. The creation of this edge records the direct reason why this standard needs to be revised.

[0134] In some embodiments, the construction of related edges can be implemented in several ways: Optionally, an edge can be created by directly executing a CREATE statement in the graph database using Cypher, Gremlin, or other graph query languages. Optionally, the edge's attributes can store richer information, such as the specific frequency of triggering the flag, the timestamp, and a list of related fault report IDs, providing detailed context for subsequent manual review. It is understood that this reverse related edge can also point to a problem node that aggregates multiple fault events, not just the root cause entity itself; this is not limited here.

[0135] In some embodiments, a standard parameter may be triggered and tagged by multiple different high-frequency root causes. In response, the data processing system constructs a reverse correlation edge for each triggered high-frequency root cause. This allows engineers, when reviewing the standard to be revised, to clearly see all associated, recurring failure modes in actual operation, thus enabling a more comprehensive assessment of the standard parameter's rationality.

[0136] S513. Obtain the actual operating status data of the target component node within the fault occurrence time window, compare the actual operating status data with the compliance parameter threshold, and generate a fault tracing report containing the comparison results of exceeding the limit.

[0137] Refer to step S208, which will not be repeated here.

[0138] In some embodiments, the data processing system introduces detailed steps for dynamic reference thresholds. Specifically, the data processing system acquires the operational status data of the target component node during its historical normal operation cycle; it fits the distribution characteristics of the data during the historical normal operation cycle based on a Gaussian distribution model to calculate and generate a dynamic reference threshold; it associates the dynamic reference threshold with compliance parameter thresholds in the standard knowledge graph that are in a state of pending revision, as a basis for parallel verification; when processing new traceability requests, it compares the actual operational status data based on the compliance parameter thresholds and the dynamic reference thresholds simultaneously, and generates a flexible judgment result containing risk warnings in the fault traceability report when the comparison results are inconsistent.

[0139] The historical normal operating period refers to the time during which the component has operated smoothly without any past failures. The Gaussian distribution model is a common probability distribution model used to describe the statistical regularities of many natural phenomena. The dynamic reference threshold, calculated based on this model, reflects a numerical range that indicates the component's individual health status, such as the mean plus or minus three standard deviations (μ ± 3σ). The flexible assessment result is a non-absolute diagnostic conclusion, presenting two different judgments based on both static standards and dynamic baselines.

[0140] Specifically, when a static threshold (e.g., oil pressure range of 2.0-2.5 Bar) is marked as needing revision, the system initiates this process. It queries the historical database, retrieving a large number of data points from the past few months of normal operation for the oil pressure sensor. Then, it calculates the mean (μ, e.g., 2.6 Bar) and standard deviation (σ, e.g., 0.05 Bar) of these data. Based on this, a dynamic reference threshold range is generated (e.g., 2.6 ± 3 * 0.05, i.e., 2.45-2.75 Bar). This dynamic threshold is associated with the parameter node in the standard knowledge graph that needs revision. When a new fault trace points to this oil pressure issue, and the actual measured oil pressure is 2.55 Bar, the system performs a double comparison: comparing it to the static threshold (2.0-2.5 Bar), the result is out of range; comparing it to the dynamic threshold (2.45-2.75 Bar), the result is within normal range. The final report generates a flexible judgment: oil pressure 2.55 Bar, exceeding the design standard, but within the historical normal operating range. Risk warning: The standard may no longer be applicable, or the equipment may show signs of early drift. Close monitoring is recommended.

[0141] In some embodiments, this process can be implemented in several ways: Optionally, in addition to the Gaussian distribution, other statistical models can be selected based on the characteristics of the data, such as using a log-normal distribution for data with long-tail effects. The calculation of the dynamic threshold can also employ more robust methods, such as using the median and interquartile range (IQR) to reduce the impact of extreme outliers. Optionally, the dynamic threshold does not have to be fixed; instead, multiple scenario-based dynamic threshold models can be constructed based on changes in operating conditions such as season and load. During comparison, the current operating condition is first identified, and then the corresponding dynamic threshold is selected. It is understood that the content of the flexible judgment can be graded according to the degree of inconsistency; for example, slight deviation is considered low risk, and severe deviation is considered medium risk, but this is not limited here.

[0142] In some embodiments, there is the issue of how to define historical normal operating cycles. If the selected time period includes undetected latent faults, the calculated dynamic thresholds will be biased and inaccurate. To address this, the data processing system performs a data cleaning and filtering process when selecting historical data. The system cross-validates maintenance records, alarm logs, and other information, eliminating data from periods of sub-health that, while not reporting serious faults, exhibit frequent alarms or slight performance fluctuations, thus ensuring that the data used for modeling represents the true health status as much as possible.

[0143] In this embodiment, by employing a dual knowledge graph architecture and utilizing a product structure tree as the central hub to achieve the linkage verification of fault causal chains and technical standard parameters, coupled with a data-driven adaptive correction mechanism for standards and a flexible dynamic threshold judgment mechanism, this application can effectively integrate multi-source heterogeneous data scattered across different systems and formats to form a structured, reasonable knowledge system. This method effectively solves the problems of existing technologies, such as fault diagnosis relying on human experience, cumbersome and error-prone standard lookup, and fixed knowledge bases that cannot evolve. It thus achieves automated, precise, and objectively quantifiable traceability diagnosis of the root causes of complex industrial product faults, and enables the entire diagnostic system to continuously learn and self-optimize, improving the efficiency and accuracy of fault handling.

[0144] The data processing system in the embodiments of this invention is described below from a hardware processing perspective. Please refer to [link / reference needed]. Figure 8 This is a schematic diagram of the physical device structure of a data processing system in an embodiment of this application.

[0145] It should be noted that, Figure 8 The structure of the data processing system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0146] like Figure 8As shown, the data processing system includes a CPU 801, which can perform various appropriate actions and processes according to a program stored in ROM 802 or a program loaded from storage section 808 into RAM 803, such as executing the methods described in the above embodiments. RAM 803 also stores various programs and data required for system operation. The CPU 801, ROM 802, and RAM 803 are interconnected via bus 804. I / O interface 805 is also connected to bus 804.

[0147] The following components are connected to I / O interface 805: input section 806 including audio input devices, push-button switches, etc.; output section 807 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 808 including hard disks, etc.; and communication section 809 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 809 performs communication processing via a network such as the Internet. Drive 810 is also connected to I / O interface 805 as needed. Removable media 811, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 810 as needed so that computer programs read from them can be installed into storage section 808 as needed.

[0148] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by CPU 801, it performs the various functions defined in the present invention.

[0149] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0150] Specifically, the data processing system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the fault tracing method based on dual knowledge graphs provided in the above embodiment.

[0151] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the data processing system described in the above embodiments; or it may exist independently and not assembled into the data processing system. The storage medium carries one or more computer programs that, when executed by a processor of the data processing system, cause the data processing system to implement the fault tracing method based on dual knowledge graphs provided in the above embodiments.

[0152] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0153] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

Claims

1. A fault tracing method based on dual knowledge graphs, characterized in that, Applied to a data processing system, the method includes: Obtain multidimensional data sources for the industrial products to be analyzed; A dual knowledge graph is constructed based on the multidimensional data source; the dual knowledge graph includes a fault knowledge graph, a standard knowledge graph, and a product structure tree as a connection hub. Receive a traceability request containing a fault description text, device identification, and the fault occurrence time window; Based on the device identification and the fault occurrence time window, the target component node is located in the product structure tree; Calculate the semantic similarity between the fault description text and the entities in the fault knowledge graph to determine the target fault phenomenon entity; In the fault knowledge graph, causal association paths connecting the target component node and the target fault phenomenon entity are retrieved, and the entities on the paths are extracted as a set of candidate fault root causes. Traverse each candidate fault root cause in the candidate fault root cause set, jump to the standard knowledge graph through the common mapping center of the product structure tree, and determine the compliance parameter threshold corresponding to the corresponding candidate fault root cause; Obtain the actual operating status data of the target component node within the fault occurrence time window, compare the actual operating status data with the compliance parameter threshold, and generate a fault tracing report containing the comparison result of exceeding the limit.

2. The method according to claim 1, characterized in that, The steps for constructing a dual knowledge graph based on the multidimensional data source specifically include: The design bill of materials and operation and maintenance bill of materials in the multidimensional data source are parsed, and the same-name nodes in the design bill of materials and operation and maintenance bill of materials are merged based on the entity alignment algorithm to construct a product structure tree; Unstructured fault logs are extracted from the multidimensional data source, fault phenomenon entities and fault mechanism entities are extracted based on the named entity recognition model, and the fault phenomenon entities and fault mechanism entities are attached to the corresponding nodes of the product structure tree to generate the fault knowledge graph. The technical standard documents in the multidimensional data source are parsed, standard specification entities and technical parameter entities are extracted based on the relation extraction model, the constraint relationship between the standard specification entity and the technical parameter entity is constructed, and the constraint relationship is mapped to the product structure tree to generate the standard knowledge graph. Construct a dual knowledge graph with the product structure tree as the common mapping hub, connecting the fault knowledge graph and the standard knowledge graph respectively.

3. The method according to claim 1, characterized in that, The step of locating and determining the target component node in the product structure tree based on the device identification and the fault occurrence time window specifically includes: Parse the device identity identifier to obtain the device configuration version information and physical code; Based on the fault occurrence time window and the device configuration version information, locate the corresponding time slice subtree in the product structure tree; Retrieve leaf nodes that match the physical encoding in the time slice subtree, and mark the leaf nodes and their parent nodes as target component nodes.

4. The method according to claim 1, characterized in that, The step of retrieving causal association paths connecting the target component node and the target fault phenomenon entity in the fault knowledge graph, and extracting the entities on the paths as a set of candidate fault root causes, specifically includes: Taking the target fault phenomenon entity as the endpoint and the fault entity associated with the target component node as the starting point, perform a reverse path search or a bidirectional path search in the fault knowledge graph to obtain all entity paths connecting the starting point and the endpoint. Extract the fault cause entities from the entity path, remove the preset general stop word nodes, and determine the remaining entities as the candidate fault root cause set.

5. The method according to claim 1, characterized in that, Before the step of calculating the semantic similarity between the fault description text and the entities in the fault knowledge graph to determine the target fault phenomenon entity, the method further includes: We acquire a specialized corpus for the industrial domain, fine-tune the pre-trained language model, and obtain a domain embedding model. The fault description text is input into the domain embedding model to identify non-standard terms; Based on the thesaurus in the fault knowledge graph, the non-standard terms are mapped to standard fault terms; A fault query vector is generated based on the standard fault terminology to perform semantic similarity calculation.

6. The method according to claim 1, characterized in that, After the steps of obtaining the actual operating status data of the target component node, comparing the actual operating status data with the compliance parameter threshold, and generating a fault tracing report containing the comparison result of exceeding the limit, the method further includes: The cumulative frequency of the same candidate fault root cause being judged as exceeding parameter limits within a preset period is counted. When the cumulative frequency exceeds a preset warning threshold, the corresponding compliance parameter threshold is marked as pending revision in the standard knowledge graph; Construct a reverse association edge between the state to be revised and the candidate root cause of the fault.

7. The method according to claim 6, characterized in that, After the step of constructing the reverse association edge pointing from the state to be revised to the candidate root cause of the failure, the method further includes: Obtain the operating status data of the target component node during its historical normal operation cycle; Based on the Gaussian distribution model, the distribution characteristics of the data within the historical normal operation cycle are fitted, and a dynamic reference threshold is calculated and generated. The dynamic reference threshold is associated with the compliance parameter threshold in the standard knowledge graph that is in a state of pending revision, as a basis for parallel verification; When processing new traceability requests, the actual operating status data is compared with the compliance parameter threshold and the dynamic reference threshold. If the comparison results are inconsistent, a flexible judgment result containing risk warnings is generated in the fault traceability report.

8. A data processing system, characterized in that, The data processing system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the data processing system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the data processing system, the data processing system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on a data processing system, the data processing system performs the method as described in any one of claims 1-7.

Images