System abnormal state tracing method and device and storage medium

Abstract

The invention discloses a system abnormal state tracing method and device and a storage medium. The method comprises the steps that a device tree and a fault tree of a target system are acquired, the device tree is used for describing the hierarchical relation among multiple devices in the target system, and the fault tree is used for describing the causal relation among multiple standardized fault events occurring in the target system; according to the equipment tree and the fault tree, generating an associated heterogeneous graph of the target system; the abnormal state of the target system in the first time period is obtained, and the abnormal state comprises equipment operation abnormity or a fault event; and tracing the abnormal state according to the associated heterogeneous atlas, and outputting a tracing result. According to the method, the technical problem that the accuracy of a tracing result is relatively poor as the related technology depends on an independent equipment tree and a fault tree to trace the abnormal state of the system is solved.

Description

Technical Field

[0001] This application relates to the field of industrial Internet of Things (IoT) technology, and more specifically, to a method, apparatus, and storage medium for tracing the source of abnormal system states. Background Technology

[0002] In the field of intelligent operation and maintenance of industrial equipment, when a system anomaly is detected, the system first checks the equipment layer by layer from the top level according to a manually constructed static equipment tree until the possible faulty equipment or component is located. Then, it analyzes the possible causes of the fault according to a manually constructed fixed fault tree. Finally, based on the analysis results of the fault tree, it conducts further manual verification to confirm the root cause of the fault.

[0003] While this tracing method can meet the tracing requirements to some extent, the lack of an automated correlation mechanism means that the association between fault events and specific equipment components requires manual verification. This is not only inefficient but may also lead to incomplete fault chain analysis due to human error or knowledge gaps, affecting the accuracy of maintenance decisions.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and storage medium for tracing the source of system abnormal states, in order to at least solve the technical problem that related technologies rely on independent device trees and fault trees to trace the source of system abnormal states, resulting in poor accuracy of the tracing results.

[0006] According to one aspect of the embodiments of this application, a method for tracing the source of abnormal states in a system is provided, comprising: obtaining a device tree and a fault tree of a target system, wherein the device tree is used to describe the hierarchical relationship between multiple devices in the target system, and the fault tree is used to describe the causal relationship between multiple standardized fault events occurring in the target system; generating an association heterogeneous graph of the target system based on the device tree and the fault tree; obtaining the abnormal state of the target system within a first time period, wherein the abnormal state includes abnormal device operation or fault events; tracing the source of the abnormal state based on the association heterogeneous graph, and outputting the tracing result.

[0007] Optionally, the device tree is determined as follows: the technical document of the target system is divided according to a preset partitioning rule to obtain multiple text blocks, wherein the technical document includes at least the connection relationship between multiple devices within the target system; for each text block, the text block is analyzed using a first named entity recognition model to obtain multiple devices, and the device information of each device is determined, wherein the device information includes at least one of the following: device identifier, device model, and device parameters; the text block is analyzed using a dependency parsing model to determine the hierarchical relationship between each device; a multi-level tree structure is constructed based on the hierarchical relationship of each device, and the device information of each device is used as the node information of each tree node in the tree structure to obtain the device tree.

[0008] Optionally, after constructing the device tree based on the technical documentation, the method further includes: verifying the hierarchical conflict of the device tree using a pre-defined generative model to obtain corresponding verification results. The generative model is trained using a pre-defined system knowledge corpus, and the system knowledge corpus includes at least: standard hierarchical relationships between multiple devices, and adjustment suggestions for different types of hierarchical conflicts. The verification results are used to reflect at least two abnormal devices with hierarchical conflicts in the device tree and the adjustment suggestions corresponding to the hierarchical conflicts occurring in the at least two abnormal devices. The adjustment suggestions in the verification results are used to perform hierarchical adjustments on the at least two abnormal devices with hierarchical conflicts to obtain an updated device tree.

[0009] Optionally, the fault tree is determined as follows: The operation and maintenance log information of the target system within a second time period is obtained, wherein the operation and maintenance log information includes at least multiple operation and maintenance records occurring within the second time period, which is a time period earlier than the first time period; for each operation and maintenance record, the operation and maintenance record is analyzed using a second named entity recognition model to obtain an operation and maintenance triplet, wherein the operation and maintenance triplet includes: fault device identifier, fault type, and fault cause; the operation and maintenance triplet is standardized to obtain standardized fault events corresponding to the operation and maintenance record; based on the frequency of occurrence of each operation and maintenance record in the operation and maintenance log information, the probability of occurrence of the standardized fault event corresponding to each operation and maintenance record is determined, and the causal relationship between each standardized fault event is determined based on the fault cause in each standardized fault event; a multi-level tree structure is constructed based on the causal relationship between each standardized fault event, and the probability of occurrence of each standardized fault event is used as the node information of each tree node in the tree structure to obtain the fault tree.

[0010] Optionally, before constructing the heterogeneous graph of the target system based on the device tree and fault tree, the method further includes: obtaining the health parameter sequence of each device in the target system within a first time period, wherein the health parameter sequence includes at least one of the following: efficiency health sequence, traffic health sequence; when the health parameter sequence of any target device in the target system is lower than a preset threshold, obtaining the device health file of the target device when the first standardized fault event occurs in a third time period before the first time period, and analyzing the device health file using a preset lifetime prediction model to obtain the predicted remaining lifetime of the target device, wherein the device health file includes at least one of the following: multi-dimensional sensor data, operation and maintenance status sequence, cumulative runtime, operation and maintenance log information; determining the probability increment of the occurrence of the first standardized fault event based on a preset scaling factor, the predicted remaining lifetime, and the maximum lifetime of the target device; adjusting the probability of occurrence of the first standardized fault event in the fault tree using the probability increment to obtain an updated fault tree.

[0011] Optionally, based on the device tree and fault tree, a heterogeneous graph of the target system is constructed, including: determining the first feature information of each device based on the device information of each device in the device tree and the structural information of each device in the device tree; and determining the second feature information of each fault event based on the occurrence probability of each standardized fault event in the updated fault tree and the structural information of each standardized fault event in the fault tree. The structural information includes at least one of the following: the depth corresponding to the level, the number of parent nodes, and the number of child nodes; using the first feature information of each device in the device tree and the second feature information of each standardized fault event in the updated fault tree as the node information of multiple graph nodes, and determining the edge between every two graph nodes based on the device tree and the updated fault tree to construct the heterogeneous graph of the target system.

[0012] Optionally, determining the edge between every two graph nodes based on the device tree and the updated fault tree includes: encoding the first feature information of each device and the second feature information of each standardized fault event to obtain the node feature vector of each graph node, wherein the type of the graph node includes: device or fault event; for each graph node, aggregating the node feature vectors of at least k-order neighbor nodes of the graph node to obtain the neighborhood summary vector of the graph node, and determining the fused node feature vector of the graph node based on the neighborhood summary vector and the node feature vector of the graph node; for the graph node connecting the device and the graph node corresponding to the standardized fault event, the edge between each two graph nodes is determined. For a first-class edge, obtain the target object's score for the first-class edge; determine the minimum health score based on the health score sequence of the devices in the two graph nodes corresponding to the first-class edge within the first time period; determine the association score of the first-class edge based on the fused node feature vectors of the two graph nodes corresponding to the edge; determine the confidence score of the first-class edge based on the score, minimum health score, and association score, and determine whether the first-class edge exists based on the relationship between the confidence score and a preset threshold; for a second-class edge connecting two graph nodes corresponding to two devices or connecting two graph nodes corresponding to standardized fault events, determine whether the corresponding second-class edge exists based on the device tree or the updated fault tree.

[0013] Optionally, the abnormal state is traced based on the correlation heterogeneous graph, and the tracing results are output, including: when the abnormal state is a fault event, the fault event is standardized to obtain a second standardized fault event, and the source abnormal device directly associated with the second standardized fault event is located using the correlation heterogeneous graph, and the source abnormal device is output; when the abnormal state is a device malfunction, the initial fault type is determined based on the operating status information of the device corresponding to the device malfunction, and the structural information of the device corresponding to the device malfunction in the device tree is determined based on the correlation heterogeneous graph; the starting graph node corresponding to the initial fault type in the correlation heterogeneous graph is determined, and the starting node is used as the starting point. Starting from the initial graph node, the associated heterogeneous graph is searched based on structural information to obtain multiple suspected fault propagation paths. Each suspected fault propagation path includes at least one intermediate graph node. For each suspected fault propagation path, the real-time health of each intermediate graph node in the suspected fault propagation path is determined, and the propagation probability of the suspected fault propagation path is determined based on the sum of the real-time health of all intermediate graph nodes in the suspected fault propagation path. The larger the sum, the lower the propagation probability of the suspected fault propagation path. Based on the propagation probability of each suspected fault propagation path, the predicted fault propagation path corresponding to the equipment malfunction is determined, and the predicted fault propagation path is output.

[0014] According to another aspect of the embodiments of this application, a system abnormal state tracing device is also provided, comprising: a first acquisition module, configured to acquire a device tree and a fault tree of a target system, wherein the device tree is used to describe the hierarchical relationship between multiple devices in the target system, and the fault tree is used to describe the causal relationship between multiple standardized fault events occurring in the target system; a construction module, configured to generate an association heterogeneous graph of the target system based on the device tree and the fault tree; a second acquisition module, configured to acquire the abnormal state of the target system within a first time period, wherein the abnormal state includes device malfunction or fault events; and an output module, configured to trace the abnormal state based on the association heterogeneous graph and output the tracing result.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-described system abnormality tracing method by running the computer program.

[0016] This application's embodiments generate a heterogeneous correlation graph of the target system based on its device tree and fault tree. The device tree describes the hierarchical relationships between multiple devices within the target system, while the fault tree describes the causal relationships between various standardized fault events occurring within the target system. Furthermore, the abnormal states of the target system within a first time period are obtained, and bidirectional source tracing analysis is performed on these abnormal states based on the heterogeneous correlation graph, outputting the tracing results. Therefore, this technical solution achieves the technical effect of rapid and accurate source tracing of abnormal states in the target system, improving the efficiency of industrial equipment health management and reducing unplanned downtime. It also solves the technical problem that related technologies rely on independent device trees and fault trees for tracing abnormal system states, resulting in poor accuracy of the tracing results. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a flowchart illustrating an optional system anomaly tracing method according to an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of an optional system abnormality tracing device according to an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the hardware structure of an electronic device for implementing a system abnormal state tracing method according to an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0022] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] Example 1

[0024] According to an embodiment of this application, a method for tracing the source of system abnormal states is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] Figure 1 This is a flowchart illustrating a system anomaly tracing method according to an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps:

[0026] Step S102: Obtain the device tree and fault tree of the target system. The device tree is used to describe the hierarchical relationship between multiple devices in the target system, and the fault tree is used to describe the causal relationship between various standardized fault events that occur in the target system.

[0027] Step S104: Generate the correlation heterogeneity map of the target system based on the device tree and fault tree.

[0028] Step S106: Obtain the abnormal state of the target system within a first time period, wherein the abnormal state includes abnormal equipment operation or fault events.

[0029] Step S108: Trace the abnormal state to its source based on the correlation heterogeneous graph and output the source tracing results.

[0030] Based on the scheme defined in steps S102 to S108 above, it can be understood that in this embodiment of the application, the associated heterogeneous graph generated by the device tree and the fault tree can be used to quickly and accurately trace the abnormal state of the target system, thereby achieving the purpose of improving the efficiency of industrial equipment health management and reducing unplanned downtime. This solves the technical problem that related technologies rely on independent device trees and fault trees to trace the abnormal state of the system, resulting in poor accuracy of the tracing results.

[0031] The following section explains each step of the system anomaly tracing method in conjunction with the specific implementation process.

[0032] In the technical solution provided in step S102 above, the system can first obtain the device tree and fault tree of the target system. The target system can be any industrial equipment or device with a complex hierarchical structure and fault logic, including but not limited to high-end equipment manufacturing systems, vehicle systems in automobile repair, wind power generation systems in wind farms, and production systems in chemical plants.

[0033] Specifically, the aforementioned device tree can be a tree-like data structure used to describe the hierarchical relationships between multiple devices within a target system. Taking a vehicle system in automotive repair as an example, its corresponding device tree can be a five-level hierarchy from the product level to the specific component level, including the product level (i.e., the whole vehicle), system level (such as powertrain system, transmission system, suspension system, electrical system, interior system, chassis system, etc.), subsystem level (such as the motor subsystem, gearbox subsystem, driveshaft subsystem, differential subsystem, etc. in the transmission system), secondary subsystem level (such as the clutch secondary subsystem, gear set secondary subsystem, lubrication circuit secondary subsystem, etc. in the differential subsystem), and component level (such as the input shaft gear, output shaft gear, synchronizer gear, etc. in the gear set secondary subsystem).

[0034] Furthermore, a fault tree is a tree-like logical diagram used to describe the causal relationships between various standardized fault events occurring within a target system. It includes, but is not limited to, different levels from top to bottom events. Taking a vehicle system in automotive repair as an example, its corresponding fault tree could include:

[0035] Top event: describes the most serious failure consequence of the entire system or subsystem, such as gearbox failure;

[0036] Intermediate events: These are the direct causes or triggering conditions of the top event. Taking gearbox failure as an example, the corresponding intermediate events include, but are not limited to: shifting mechanism jamming, low lubricating oil pressure, abnormal wear of gear sets, etc.

[0037] Bottom events: These are the most basic fault causes that are not further decomposed in the fault tree. Taking a stuck gear shift mechanism as an example, the corresponding bottom events include, but are not limited to: wear of the gear shift lever mechanism, failure of the gear shift solenoid valve, etc. Taking low lubricating oil pressure as an example, the corresponding bottom events include, but are not limited to: lubricating oil pump failure, lubricating oil circuit blockage, etc. Taking abnormal wear of the gear set as an example, the corresponding bottom events include, but are not limited to: input shaft gear peeling, output shaft gear cracking, excessive gear clearance.

[0038] It should be noted that fault trees can also represent the logical relationships between events at different levels using logic gates (AND or OR). For example, the intermediate event "shift mechanism jamming" may be triggered by either the bottom-level event "shift lever mechanism wear" or "shift solenoid valve failure," so an OR logic gate can be used here. As another example, the top-level event "transmission failure" may only be triggered by the simultaneous occurrence of the two intermediate events "shift mechanism jamming" and "low lubricating oil pressure," so an AND logic gate can be used in this case.

[0039] As an alternative implementation, the device tree described above can be constructed in the following manner:

[0040] Step 1: Divide the technical documents of the target system into multiple text blocks according to the preset division rules.

[0041] Specifically, technical documents include, but are not limited to: technical specifications, equipment manuals, bills of materials, interface specifications, and drawing descriptions. Their content should at least include the connection relationships between multiple devices within the target system. For example, taking a battery pack system as an example, its technical documents include, but are not limited to: technical specifications (including cells, modules, and bills of materials), real-time voltage, temperature, and current timing data uploaded by the battery management system, and historical fault records (such as insulation faults, excessive voltage differentials, etc.) from the cloud big data platform.

[0042] Optionally, the division of technical documents can be achieved as follows: First, the technical document is parsed using a document parsing library to obtain its text layout, including titles, paragraphs, lines, and words; then, a segmentation strategy is determined based on the text layout, and the technical document is segmented according to the segmentation strategy to obtain multiple text blocks. Specifically, the above segmentation strategy can be determined based on chapter titles, that is, identifying the titles in the technical document and treating the text under each title as a separate text block. Alternatively, the above segmentation strategy can be determined based on paragraphs, that is, treating each paragraph as a text block.

[0043] Optionally, the segmentation of technical documents can also be achieved by analyzing the documents using a classification model or a sequence labeling model to obtain multiple text blocks. The classification model or sequence labeling model can be trained on a large dataset of segmented documents to learn how to automatically determine segmentation rules based on text content and context.

[0044] Step 2: For each text block, the first named entity recognition model is used to analyze the text block to obtain multiple devices and determine the device information of each device. The dependency parsing model is then used to analyze the text block to determine the hierarchical relationship between the devices.

[0045] Specifically, each text block after the above division is traversed, and the current text block is analyzed using the pre-trained first named entity recognition model to obtain multiple device entities contained in the current text block. The device information of each device entity is extracted, which includes at least one of the following: device identifier, device model, device parameters, etc. Then, the device information is matched with the corresponding device entity to form a complete device information record, such as "engine (model; domestic identifier)".

[0046] The aforementioned first Named Entity Recognition (NER) model was fine-tuned and trained using the first corpus in the domain corresponding to the target system.

[0047] Regarding the aforementioned first corpus, for vehicle systems, it could be vehicle electronic architecture documents (which detail the hardware and software components of the vehicle's electronic systems and their interconnections), maintenance service manuals (which provide fault diagnosis, repair procedures, and replacement guidelines for various components during automotive repair), and component specifications (which record in detail the technical specifications and characteristics of each device or component, such as dimensions, weight, and electrical parameters). For aerospace systems, it could be system architecture manuals (which describe the composition and structure of various systems and subsystems on an aircraft), maintenance manuals (which provide equipment maintenance procedures, inspection procedures, and component replacement guidelines), and fault isolation manuals (which list in detail possible fault modes). For chemical production systems, this could be a process flow diagram of a chemical plant (showing the material flow, equipment connection, and control logic in the chemical production process), equipment technical manuals (providing detailed operating parameters, design principles, and safety specifications), maintenance and operation procedures (recording the procedures and standards for daily operation, maintenance, and troubleshooting), etc. For power systems, this could be electrical schematic diagrams and wiring diagrams (providing the electrical connections and control logic of equipment in power generation, transmission, and distribution systems), equipment manuals and specifications (providing technical parameters and maintenance guidelines for generators, transformers, switchgear, etc.), and power system design specifications (specifying the design standards and installation requirements for power equipment).

[0048] Furthermore, a dependency parsing model is used to analyze the dependency relationships between each word and other words in the current text block and output the dependency tree structure. For example, in the phrase "engine drives gearbox," "engine" is the subject of "drives," and "gearbox" is the object, thus implying a hierarchical or connecting relationship between "engine" and "gearbox." Therefore, words representing hierarchical or containment relationships, such as "contains," "composed of," and "in," can be identified through the dependency tree structure; thereby determining the hierarchical relationships between various devices. For example, by analyzing the text block "an engine is composed of a crankshaft, connecting rod, and cylinder block," the model can identify that "engine" contains "crankshaft," "connecting rod," and "cylinder block," thus constructing the hierarchical relationship of the device tree.

[0049] Step 3: Construct a multi-level tree structure based on the hierarchical relationship of each device, and use the device information of each device as the node information of each tree node in the tree structure to obtain the device tree.

[0050] The above steps can be understood as follows: A hierarchical relationship matrix is ​​formed based on the hierarchical relationships of each device. Each row in the matrix represents a device, and each column represents another related device. Matrix elements represent the relationships between devices (such as "system," "subsystem," "secondary subsystem," and "component"). Next, based on the hierarchical relationship matrix, a tree structure is constructed starting from the highest-level device. During tree structure initialization, the highest-level device is set as the root node. The hierarchical relationship matrix is ​​then recursively traversed downwards, assigning an appropriate tree level to each device and establishing parent-child relationships between levels, such as a five-level structure: overall level—system level—subsystem level—secondary subsystem level—component level. Finally, the device information of each device is stored as additional attribute information for the corresponding node in the tree structure within the node information.

[0051] In addition to basic equipment information, node information can also integrate dynamic information such as equipment operating status and historical maintenance records as extended attributes of tree nodes, making the equipment tree a comprehensive carrier of real-time reflection of equipment status and historical records.

[0052] Using the above method, the device tree of the target system can be automatically constructed from a large number of technical documents without human intervention. This device tree can dynamically reflect the actual hierarchical relationship and status information of each device in the target system, thereby greatly improving the automation level of device information management, reducing the workload of manual maintenance, enhancing the real-time performance and accuracy of device status monitoring, and facilitating the rapid location of abnormal states in the target system.

[0053] However, since the construction of a device tree typically relies on multiple data sources, and data from different sources may provide inconsistent hierarchical descriptions of the same device or component, or differ in their interpretation of the device structure, hierarchical conflicts can arise during import. Therefore, the constructed device tree can be adjusted to ensure accuracy and compliance with practical and regulatory requirements: A pre-defined generative model is used to verify hierarchical conflicts in the device tree, yielding corresponding verification results. This generative model is trained using a pre-defined system knowledge corpus, which includes at least: standard hierarchical relationships between multiple devices, and adjustment suggestions for different types of hierarchical conflicts. The verification results reflect at least two abnormal devices with hierarchical conflicts in the device tree and corresponding adjustment suggestions for the hierarchical conflicts occurring in these at least two abnormal devices. The adjustment suggestions from the verification results are then used to adjust the hierarchical structure of the at least two abnormal devices with hierarchical conflicts, resulting in an updated device tree.

[0054] The content of the aforementioned system knowledge corpus is related to the type and industry of the target system. For example, for aerospace systems, the system knowledge corpus used to train generative models may include, but is not limited to, aerospace engineering specifications and aircraft structure and system manuals; while for automotive systems, the system knowledge corpus used to train generative models may include, but is not limited to, information on vehicle electronic architecture, CAN (Controller Area Network) bus protocol, and automotive repair manuals. For target systems in the chemical industry, the system knowledge corpus used to train generative models may also include chemical industry standards; and for target systems in the automotive industry, the system knowledge corpus used to train generative models may also include automotive production standards and automotive management standards.

[0055] Specifically, the generative model can be pre-trained using a system knowledge corpus. The purpose of pre-training is to enable the model to master the standardized definition of device hierarchy relationships, identify different types of hierarchy conflicts, and learn rules for generating adjustment suggestions. Then, the constructed device tree is input into the generative model, which performs a deep analysis of the device tree's hierarchy relationships based on its pre-trained knowledge. It checks whether the devices at each level conform to the defined standard hierarchy relationships and whether the positions of each device in the tree are reasonable. If a device's hierarchy allocation is found to be inconsistent with its standard hierarchy relationships, the generative model can mark this device as an abnormal device. Furthermore, based on its learned system knowledge corpus, the generative model can generate corresponding adjustment suggestions. These suggestions not only point out the conflicts but also include recommended hierarchy adjustment schemes, such as reclassifying a subsystem as a system-level component or transferring a component from one subsystem to a more reasonable one. Therefore, by integrating deep learning models and professional standard knowledge, the model can intelligently identify and resolve hierarchy conflicts that may be encountered during device tree construction, ensuring the accuracy and standardization of the device tree.

[0056] Furthermore, over time, the design of devices in the target system may undergo multiple updates and improvements, potentially leading to adjustments in the device tree hierarchy. Therefore, the system can periodically retrieve the latest technical documentation for the target system and continuously update the device tree based on this information, ensuring its accuracy.

[0057] As another alternative implementation, the fault tree described above can be constructed through the following steps:

[0058] Step 1: Obtain the operation and maintenance log information of the target system in the second time period. The operation and maintenance log information shall include at least multiple operation and maintenance records that occurred in the target system in the second time period, which is a time period earlier than the first time period.

[0059] Step 2: For each operation and maintenance record, analyze the operation and maintenance record using the second named entity recognition model to obtain the operation and maintenance triple; standardize the operation and maintenance triple and convert it into a unified and standardized format to obtain the standardized fault event corresponding to the operation and maintenance record.

[0060] The aforementioned second named entity recognition model is fine-tuned and trained using a second corpus within the target system's domain. It can accurately identify faulty equipment identifiers, fault types, and fault causes in maintenance records, thereby constructing maintenance triples, such as (motor 001, overheating, heat sink blockage) and (oil pump 102, reduced efficiency, filter blockage). The analysis process of the second named entity recognition model involves natural language processing of the maintenance records, including word segmentation, part-of-speech tagging, entity recognition, and relation extraction.

[0061] Regarding the aforementioned second corpus, for vehicle systems, it could include vehicle fault code descriptions, maintenance work orders, vehicle health reports, and user-reported fault records; for aerospace systems, it could include aircraft maintenance manuals, fault reports, replacement records of replaceable parts on the flight path, alarm information from engine health monitoring systems, and interpretation reports from flight data recorders; for chemical production systems, it could include chemical plant fault analysis reports, safety incident records, equipment performance monitoring data, and investigation reports of chemical spill accidents; and for power systems, it could include generator set fault logs, power equipment maintenance manuals, power grid accident analysis reports, and power equipment operating status monitoring data.

[0062] Furthermore, these maintenance triples can be standardized to unify the descriptions of faulty device identifiers, fault types, and fault causes, eliminating inconsistencies in terminology and facilitating subsequent statistical analysis and model building. Therefore, the standardization process includes, but is not limited to, synonym replacement, terminology standardization, and entity linking to ensure data consistency and comparability.

[0063] Step 3: Based on the frequency of occurrence of each operation and maintenance record in the operation and maintenance log information, determine the probability of occurrence of the standardized fault event corresponding to each operation and maintenance record, and determine the causal relationship between each standardized fault event based on the fault cause in each standardized fault event.

[0064] The above steps can be understood as follows: for each maintenance record, the system can calculate the number of times it appears in the maintenance log information, then normalize this number, using the total number of all maintenance records in the maintenance log information as the base, to obtain the relative frequency of the standardized fault event corresponding to each maintenance record. This frequency can be directly used as the primary probability value of the standardized fault event. Simultaneously, the fault causes in each of the standardized fault events are analyzed to identify conjunctions or phrases expressing causal relationships, such as "due to… causing…" or "…leading to…", thereby determining the causal relationship between two standardized fault events.

[0065] Step 4: Construct a multi-level tree structure based on the causal relationships between the standardized fault events, and use the occurrence probability of each standardized fault event as the node information of each tree node in the tree structure to obtain the fault tree.

[0066] Specifically, a causal relationship matrix is ​​formed based on the causal relationships of various standardized failure events. Each row in the matrix represents a standardized failure event, and each column represents another standardized failure event related to it. The matrix elements represent the causal relationships between standardized failure events. Next, based on the causal relationship matrix, a tree structure is constructed starting from the highest-level standardized failure event. During tree structure initialization, the highest-level standardized failure event is set as the root node. Then, the causal relationship matrix is ​​recursively traversed downwards, assigning an appropriate tree level to each standardized failure event and establishing parent-child relationships between levels, such as top event—middle event—bottom event. Finally, the occurrence probability of each standardized failure event is stored as additional attribute information of the corresponding node in the tree structure in the node information.

[0067] Using the above method, a fault tree of the target system can be automatically constructed from the operation and maintenance records without human intervention. This fault tree can dynamically reflect the actual causal relationship of each standardized fault event in the target system, thereby greatly improving the automation level of information management, reducing the workload of manual maintenance, and facilitating the rapid analysis of abnormal states in the target system.

[0068] Furthermore, the health and performance of equipment within the target system can change over time due to natural aging, maintenance activities, or changes in external environmental conditions. If the fault tree remains static, it cannot accurately reflect these dynamic changes, leading to inaccurate predictions and diagnoses.

[0069] Therefore, this application proposes the following method to continuously update the fault tree of the target system:

[0070] Step 1: Obtain the health parameter sequence of each device in the target system within the first time period. The health parameter sequence includes at least one of the following: efficiency health sequence and traffic health sequence.

[0071] Specifically, the system can continuously collect sensor data sequences from various devices within the target system during a first time period. These data sequences include, but are not limited to, key performance indicators such as efficiency and flow rate. These data sequences are then converted into efficiency health sequences and flow rate health sequences. For each device, each efficiency health score within its efficiency health sequence equals the device's actual efficiency divided by its rated efficiency, used to assess the device's production capacity, processing speed, and response time. Conversely, each flow rate health score within its flow rate health sequence equals the device's actual flow rate divided by its rated flow rate, used to detect abnormal flow rates.

[0072] Step 2: When the health parameter sequence of any target device in the target system is lower than the preset threshold, obtain the device health record when the first standardized fault event occurs in the third time period before the first time period, and analyze the device health record using the preset life prediction model to obtain the predicted remaining life of the target device.

[0073] In simple terms, if the health parameter of any target device remains below a preset threshold (e.g., efficiency health below 0.7 or traffic health below 0.8) for a certain duration (e.g., a first time period), it can be determined that the health status of the target device has significantly declined. At this point, the lifespan analysis process can be triggered.

[0074] Specifically, regarding the lifespan analysis process: First, obtain the equipment health record of the target equipment when the first standardized failure event occurs in the third time period (e.g., the most recent 24 hours) prior to the first time period. The health record includes, but is not limited to, at least one of the following: multi-dimensional sensor data, operational status sequence, cumulative runtime, and operational log information. Next, use a pre-trained lifespan prediction model, such as the GBDT (Gradient Boosting Decision Tree) model, to perform deep learning analysis on the equipment health record. This lifespan prediction model is trained based on the historical full lifespan health records of multiple devices (i.e., all equipment health records from commissioning to the moment before the first standardized failure time during decommissioning). It can predict the remaining lifespan of the equipment, i.e., predict the remaining lifetime, based on the input health parameter sequence, multi-dimensional sensor data, cumulative runtime, and other features.

[0075] Step 3: Determine the probability increment of the first standardized failure event based on the preset scaling factor, the predicted remaining lifespan, and the maximum lifespan of the target device.

[0076] Specifically, the increment of the probability of the first standardized failure event is inversely proportional to the predicted remaining lifetime, that is, it satisfies the relationship that "the smaller the predicted remaining lifetime, the greater the increment of the probability of the first standardized failure event." Therefore, the formula for calculating the increment of the probability of the first standardized failure event can be written as: In the formula, This represents the preset scaling factor (used to control the magnitude of the event probability increment, ensuring the rationality and stability of model adjustments; its value can be 0.1), and RUL represents the predicted remaining lifetime of the target device where the first standardized failure event occurs. This represents the probability increment of the first standardized failure event.

[0077] Step 4: Adjust the occurrence probability of the first standardized fault event in the fault tree using the occurrence probability increment to obtain the updated fault tree.

[0078] The above-mentioned adjustment of the occurrence probability of the first standardized fault event using the occurrence probability increment is to add the occurrence probability of the first standardized fault event to the corresponding occurrence probability increment to obtain the latest occurrence probability, and then use the latest occurrence probability to update the node information of the tree nodes in the fault tree, so as to ensure that the fault tree can dynamically reflect the actual health status of the equipment, thereby improving the effectiveness and prediction accuracy of the fault tree.

[0079] Therefore, by using the above method, the remaining lifespan of the equipment is predicted based on the equipment's health parameter sequence, and the occurrence probability of standardized fault events in the fault tree is adjusted accordingly, realizing dynamic updating of the fault tree and providing more accurate and real-time support for fault diagnosis and predictive maintenance.

[0080] It should be noted that when there are multiple devices of the same type experiencing the same standardized failure event, the probability increment of the standardized failure event can be calculated based on the predicted remaining lifetime of each device, and the largest probability increment can be used as the update probability of the standardized failure event.

[0081] In the technical solution provided in step S104 above, the system can generate a heterogeneous correlation map of the target system based on the device tree and fault tree.

[0082] As an optional implementation, in the technical solution provided in step S104 above, the associated heterogeneous map can be constructed according to the following method:

[0083] Step S1041: Determine the first feature information of each device based on the device information of each device in the device tree and the structural information of each device in the device tree, and determine the second feature information of each fault event based on the occurrence probability of each standardized fault event in the updated fault tree and the structural information of each standardized fault event in the fault tree.

[0084] The aforementioned structural information includes, but is not limited to, at least one of the following: the depth of the level, the number of parent nodes, and the number of child nodes, wherein:

[0085] The depth corresponding to the level refers to the position of the device or fault event in the device tree or fault tree, that is, the number of levels away from the root node. Therefore, the greater the depth, the more specific the device or fault event; the smaller the depth, the more abstract the device or fault event.

[0086] The number of parent nodes indicates the dependency or scope of influence of a device or fault event in the corresponding level of the device tree or fault tree;

[0087] The number of child nodes reflects the degree of segmentation of the device or failure event, or the complexity of the cause.

[0088] Therefore, the device information of each device in the device tree, along with the structural information of each device within the device tree, constitutes the first characteristic information of each device. This information describes the characteristics of each device and its relative position and hierarchical relationship within the device tree. This is crucial for identifying the role and importance of each device, as well as its relationship with other devices. Simultaneously, the occurrence probability of each standardized fault event in the updated fault tree, along with the structural information of each standardized fault event within the fault tree, constitutes the second characteristic information of each fault event. This information reflects the nature of the fault event, its potential impact range, and its position in the fault logic chain.

[0089] Step S1042: The first feature information of each device in the device tree and the second feature information of each standardized fault event in the updated fault tree are used as the node information of each of the multiple graph nodes. The edges between each pair of graph nodes are determined based on the device tree and the updated fault tree to construct the associated heterogeneous graph of the target system.

[0090] Specifically, the edges between nodes in a correlated heterogeneous graph can be determined as follows:

[0091] Step 1: Encode the first feature information of each device and the second feature information of each fault event to obtain the node feature vector of each graph node. The type of graph node includes: device or fault event.

[0092] The above method can encode the first feature information of each device and the second feature information of each standardized fault event through one-hot encoding, etc., to obtain the node feature vector of the graph node corresponding to each device and the (initial) node feature vector of the graph node corresponding to each standardized fault event.

[0093] Step 2: For each graph node, aggregate the node feature vectors of at least one k-order neighbor node of the graph node to obtain the neighborhood summary vector of the graph node, and determine the fused node feature vector of the graph node based on the neighborhood summary vector and the node feature vector of the graph node.

[0094] In other words, each graph node is traversed to determine its set of k-order neighbors, where k represents the number of steps from the current node along the edges of the graph to reach the node. When k=1, only directly connected first-order neighbors are considered, while when k is greater than 1, a wider neighborhood is considered, allowing the node to acquire deeper information. Next, the node feature vectors of the set of k-order neighbors are aggregated. Aggregation operations include, but are not limited to, average pooling, max pooling, and attention-weighted summation. Through aggregation, a neighborhood summary vector is obtained, reflecting the characteristics of the surrounding structure. Finally, a series of neural network layers (such as fully connected layers and convolutional layers) and nonlinear activation functions (such as ReLU) combine the (initial) node feature vector of the current graph node with the obtained neighborhood summary vector to obtain the enhanced fused node feature vector of the current graph node. This fused node feature vector not only contains the inherent properties of the node but also reflects the interaction and relationship between the node and its surrounding environment.

[0095] Step 3: For the first type of edges of the graph nodes corresponding to the connected devices and the graph nodes corresponding to the standardized fault events, first obtain the scoring results of the target object for the first type of edges; then determine the minimum health score based on the health score sequence of the devices in the two graph nodes corresponding to the first type of edges within the first time period; determine the association score of the first type of edges based on the fused node feature vectors of the two graph nodes corresponding to the edges; determine the confidence score of the first type of edges based on the scoring results, the minimum health score and the association score, and determine whether the first type of edges exist based on the relationship between the confidence score and the preset threshold.

[0096] The above scoring result refers to the score after the experts judge the association between the graph nodes corresponding to each device and the graph nodes corresponding to standardized fault events based on domain knowledge, historical data and operational experience. Therefore, it reflects the experts' reasonable judgment on the first type of edge. The closer this item is to 1, the higher the probability that the first type of edge association exists in terms of business logic, and the higher the confidence level.

[0097] Generally, if experts believe there is a reasonable correlation between a device and a standardized failure event, they can label it "very reasonable" or "generally reasonable"; otherwise, they can label it "generally unreasonable" or "very unreasonable." Furthermore, the expert labels can be converted into numerical scores. For example, "very reasonable" might have a numerical score of 10, "generally reasonable" a score of 6, "generally unreasonable" a score of 4, and "very unreasonable" a score of 2.

[0098] Furthermore, the system can calculate the similarity between the fused node feature vectors of the two graph nodes corresponding to the edge, and use this similarity as the association score of the first type of edge between the graph node corresponding to the connecting device and the graph node corresponding to the standardized fault event. Common similarity metrics include cosine similarity, Euclidean distance, and Jaccard similarity.

[0099] Furthermore, considering that system anomalies are often caused by a series of complex and interrelated factors, such as equipment aging, improper maintenance, and environmental factors, the confidence level of the first type of edge is determined based on the scoring results, minimum health score, and correlation score to evaluate the reliability of the correlation score. The formula for determining the confidence level is as follows: In the formula, represents the confidence level of the first type of edge; c represents the score of the first type of edge; represents the minimum health level, reflecting the recent operating performance of the equipment; A represents the association score of the first type of edge.

[0100] Step 4: For the second type edge connecting two graph nodes corresponding to two devices or connecting two graph nodes corresponding to two standardized fault events, determine whether the corresponding second type edge exists based on the device tree or the updated fault tree.

[0101] By determining the edges between all nodes through the above steps, the construction of the heterogeneous graph of the target system is completed. The heterogeneous graph integrates information from the device tree and fault tree, providing a comprehensive and structured perspective for anomaly detection and fault analysis.

[0102] In the technical solution provided in step S106 above, the system can obtain the abnormal state of the target system in the first time period, wherein the abnormal state includes abnormal equipment operation or fault events.

[0103] The first time period mentioned above is a specific time window preceding the current analysis moment, which can be the most recent minutes, hours, or days, depending on the operating characteristics of the equipment and monitoring requirements. The aforementioned abnormal state refers to any deviation of equipment operating parameters from the normal range or any fault mode (i.e., abnormal equipment operation) detected by the system within the first monitoring time period. Examples include a sudden drop in equipment efficiency, abnormal fluctuations in flow parameters, unexpected increases in temperature, increased vibration intensity, and abnormal readings from other sensors; or specific fault events extracted from historical maintenance records, such as oil pump stall, sudden drop in battery cell voltage, and turbine blade cracks.

[0104] In the technical solution provided in step S108 above, the system can trace the source of abnormal states based on the correlation heterogeneous map constructed in the above steps and output the source tracing results.

[0105] Optionally, when the abnormal state is a fault event, the fault event is standardized to obtain a second standardized fault event, and the source abnormal device directly associated with the second standardized fault event is located using the correlation heterogeneous map, and the source abnormal device is output.

[0106] Specifically, the standardization process described above compares fault events with a predefined fault pattern library to convert descriptive fault events into standardized fault event representations, i.e., second-standardized fault events, ensuring the accuracy and consistency of fault event descriptions. Subsequently, the system utilizes the constructed heterogeneous relational graph, starting from the graph node corresponding to the second-standardized fault event, and tracing backwards along the edges to the specific device node in the device tree. The edge weights on the path are used to assess the strength of the direct association; edges with higher weights indicate stronger associations. Finally, once the source faulty device directly associated with the second-standardized fault event is found, the system can output information about this device, including but not limited to: the source faulty device's hierarchical position in the device tree, model, health parameters, and the strength of its relationship with the fault event. This helps maintenance personnel quickly understand the root cause of the fault and take appropriate maintenance actions.

[0107] Therefore, the above methods can achieve standardized handling of fault events and precise location of the source of the fault, which is of great significance for rapid fault response, accurate diagnosis of equipment health status, and the formulation of predictive maintenance strategies.

[0108] Optionally, if the abnormal state is that the equipment is malfunctioning, the system can also determine the predicted fault propagation path corresponding to the equipment malfunction using the following method:

[0109] Step 1: Determine the initial fault type based on the operating status information of the equipment corresponding to the equipment malfunction, and determine the structural information of the equipment corresponding to the equipment malfunction in the device tree based on the correlation heterogeneity graph.

[0110] The aforementioned equipment malfunctions typically refer to a state where the equipment exhibits behavior that deviates from expectations or standards during operation, i.e., it cannot perform its intended function under specified conditions. This state may indicate a decline in equipment performance. Therefore, embodiments of this application can use the operating status information (such as efficiency health, flow health, and other multi-dimensional sensor data) of the equipment corresponding to a certain malfunction to preliminarily determine the possible type of fault of the equipment, serving as the first step in fault detection and diagnosis. For example, regarding the wind turbine gearbox in a wind power generation system, if the efficiency health of the equipment is significantly lower than a preset threshold, it can be preliminarily determined that the internal mechanical components of the equipment, such as bearing wear or pump seal failure, are at fault. These faults directly affect the transmission efficiency and cooling system performance of the wind turbine gearbox, thereby affecting the power output and operational stability of the entire wind turbine generator set.

[0111] Step 2: Determine the starting graph node corresponding to the initial fault type within the associated heterogeneous graph, and starting from the starting graph node, search the associated heterogeneous graph based on the structural information to obtain multiple suspected fault propagation paths.

[0112] Specifically, based on the initial graph node determined by the initial fault type, the system uses graph algorithms such as depth-first search or breadth-first search, combined with the device's structural information in the device tree, to perform a depth search on the associated heterogeneous graph. This identifies other lower-level devices (i.e., devices at a lower level in the device tree than the initial graph node) that the initial graph node may affect, thus forming multiple suspected fault propagation paths. Each suspected fault propagation path consists of a series of intermediate graph nodes, representing device components or fault events from the initial fault type to the possible fault endpoint.

[0113] Based on the structural information, a device search is performed on the child nodes of the starting node in the associated heterogeneous graph to identify other devices that may be affected by the device with abnormal operation, thus forming a suspected fault propagation path.

[0114] Step 3: For each suspected fault propagation path, determine the real-time health of each intermediate graph node in the suspected fault propagation path, and determine the propagation probability of the suspected fault propagation path based on the sum of the real-time health of all intermediate graph nodes in the suspected fault propagation path.

[0115] Specifically, the aforementioned real-time health score can be a comprehensive health index obtained by fusing the maximum efficiency health score and maximum traffic health score of each intermediate graph node within the first time period (e.g., simple averaging, weighted averaging, etc.). Then, the sum of the real-time health scores of all intermediate graph nodes along the suspected fault propagation path is calculated. During the calculation, since the different levels of each intermediate graph node in the device tree lead to different impacts of their target real-time health scores on the system, the level of the intermediate graph node in the device tree can be used as a weight to perform a weighted summation of the real-time health scores of the intermediate graph nodes, resulting in the final sum. This sum reflects the health status of each device along the suspected fault propagation path. Generally, the larger the sum, the higher the average health score of the devices along the path, and the lower the probability of fault propagation. Therefore, the system uses the magnitude of the sum as the basis for calculating the propagation probability; the larger the sum, the lower the propagation probability of the corresponding path. This inverse proportional relationship can be achieved through various mathematical functions, such as the exponential decay function.

[0116] Step 4: Determine the predicted fault propagation path corresponding to the equipment malfunction based on the propagation probability of each suspected fault propagation path, and output the predicted fault propagation path as the result of reverse tracing.

[0117] Specifically, based on the propagation probability of each suspected fault propagation path, the system can filter out the most likely actual fault propagation path by setting a probability threshold, and use this path as the predicted fault propagation path. The output of the predicted fault propagation path provides maintenance personnel with the possible development trend of the fault, which helps to carry out preventative maintenance or resource allocation in advance.

[0118] Therefore, the above methods can achieve accurate prediction and analysis of the path from equipment malfunction to fault propagation. This not only helps in early warning of faults, but also provides real-time, dynamic fault chain maps for decision support systems, thereby enabling predictive maintenance and optimized operation strategies for industrial equipment.

[0119] In summary, the system anomaly tracing method provided in this application embodiment can effectively trace the anomaly state of the target system based on the correlation heterogeneous map of the fused device tree and fault tree. Compared with existing tracing schemes, it has the following technical advantages:

[0120] (1) In this application embodiment, the large model knowledge enhancement and causal reasoning correction mechanism are used to adjust the equipment tree and fault tree, which ensures the rationality and accuracy of the equipment tree and fault tree, and reduces the error rate and the manual review cost of updating.

[0121] (2) The fault tree in this application supports dynamic updates and can adjust the logical relationship and event probability of the fault tree according to the changes in the health status of the equipment. This enables the fault tree to adjust itself according to the changes in the actual performance of the equipment, thereby more closely tracking the state evolution of the physical equipment. This avoids the problem of the existing static model being out of touch with the actual equipment state and improves the real-time performance and effectiveness of fault prediction and maintenance decision-making.

[0122] (3) The embodiments of this application are based on the association mapping mechanism of graph neural network, which transforms the complex changes of the device tree hierarchical structure and fault tree logical relationship into an association heterogeneous graph, enabling the system to perform forward fault location and reverse anomaly prediction. That is, it can trace from the fault event to the specific device, or directly predict the possible fault chain from the device anomaly, which provides a comprehensive perspective for maintenance decision making.

[0123] Example 2

[0124] According to an embodiment of this application, a system anomaly tracing device is also provided for implementing the system anomaly tracing method in Embodiment 1, such as... Figure 2 As shown, the abnormal state tracing device of this system includes at least: a first acquisition module 22, a construction module 24, a second acquisition module 26, and an output module 28, wherein:

[0125] The first acquisition module 22 is used to acquire the device tree and fault tree of the target system. The device tree is used to describe the hierarchical relationship between multiple devices in the target system, and the fault tree is used to describe the causal relationship between multiple standardized fault events that occur in the target system.

[0126] Module 24 is used to generate a heterogeneous association map of the target system based on the device tree and fault tree.

[0127] The second acquisition module 26 is used to acquire the abnormal state of the target system within a first time period, wherein the abnormal state includes abnormal equipment operation or fault events.

[0128] Output module 28 is used to trace the source of abnormal states based on the correlation heterogeneous graph and output the source tracing results.

[0129] The following section describes the functions of each module of the system abnormal state tracing device in conjunction with the specific implementation process.

[0130] In an exemplary embodiment, the apparatus further includes: a first construction module, configured to divide the technical document of the target system according to a preset partitioning rule to obtain multiple text blocks, wherein the technical document includes at least the connection relationship between multiple devices within the target system; for each text block, analyze the text block using a first named entity recognition model to obtain multiple devices, and determine the device information of each device, wherein the device information includes at least one of the following: device identifier, device model, and device parameters; analyze the text block using a dependency parsing model to determine the hierarchical relationship between the devices; construct a multi-level tree structure based on the hierarchical relationship of each device, and use the device information of each device as the node information of each tree node in the tree structure to obtain a device tree.

[0131] In an exemplary embodiment, the apparatus further includes: a first update module, configured to perform hierarchical conflict verification on the device tree using a preset generative model to obtain corresponding verification results, wherein the generative model is trained using a preset system knowledge corpus, and the system knowledge corpus includes at least: standard hierarchical relationships between multiple devices, adjustment suggestions for different types of hierarchical conflicts, and the verification results are used to reflect at least two abnormal devices in the device tree that have hierarchical conflicts and the adjustment suggestions corresponding to the hierarchical conflicts occurring in the at least two abnormal devices; and to perform hierarchical adjustment on the at least two abnormal devices with hierarchical conflicts using the adjustment suggestions in the verification results to obtain an updated device tree.

[0132] In an exemplary embodiment, the apparatus further includes: a second construction module, configured to acquire operation and maintenance log information of the target system within a second time period, wherein the operation and maintenance log information includes at least multiple operation and maintenance records occurring in the target system within the second time period, and the second time period is a time period earlier than the first time period; for each operation and maintenance record, the operation and maintenance record is analyzed using a second named entity recognition model to obtain an operation and maintenance triplet, wherein the operation and maintenance triplet includes: fault device identifier, fault type, and fault cause; the operation and maintenance triplet is standardized to obtain standardized fault events corresponding to the operation and maintenance record; the occurrence probability of the standardized fault event corresponding to each operation and maintenance record is determined based on the occurrence frequency of each operation and maintenance record in the operation and maintenance log information, and the causal relationship between each standardized fault event is determined based on the fault cause in each standardized fault event; a multi-level tree structure is constructed based on the causal relationship between each standardized fault event, and the occurrence probability of each standardized fault event is used as the node information of each tree node in the tree structure to obtain a fault tree.

[0133] In an exemplary embodiment, the apparatus further includes: a second update module, configured to acquire a health parameter sequence of each device in the target system within a first time period, wherein the health parameter sequence includes at least one of the following: an efficiency health sequence and a traffic health sequence; when the health parameter sequence of any target device in the target system is lower than a preset threshold, acquire the device health file of the target device when a first standardized fault event occurs in a third time period before the first time period, and analyze the device health file using a preset lifetime prediction model to obtain the predicted remaining lifetime of the target device, wherein the device health file includes at least one of the following: multi-dimensional sensor data, operation and maintenance status sequence, cumulative runtime, and operation and maintenance log information; determine the probability increment of the occurrence of the first standardized fault event based on a preset scaling factor, the predicted remaining lifetime, and the maximum lifetime of the target device; and adjust the probability of occurrence of the first standardized fault event in the fault tree using the probability increment to obtain an updated fault tree.

[0134] In an exemplary embodiment, the above-mentioned construction module is further configured to construct an associated heterogeneous graph of the target system based on the device tree and the fault tree, including: determining the first feature information of each device based on the device information of each device in the device tree and the structural information of each device in the device tree, and determining the second feature information of each fault event based on the occurrence probability of each standardized fault event in the updated fault tree and the structural information of each standardized fault event in the fault tree, wherein the structural information includes at least one of the following: the depth corresponding to the level, the number of parent nodes, and the number of child nodes; using the first feature information of each device in the device tree and the second feature information of each standardized fault event in the updated fault tree as the node information of each of the multiple graph nodes, and determining the edge between every two graph nodes based on the device tree and the updated fault tree, thereby constructing an associated heterogeneous graph of the target system.

[0135] In an exemplary embodiment, the above-described construction module is further configured to determine the edge between every two graph nodes based on the device tree and the updated fault tree, including: encoding the first feature information of each device and the second feature information of each standardized fault event to obtain the node feature vector of each graph node, wherein the type of the graph node includes: device or fault event; for each graph node, aggregating the node feature vectors of at least one k-order neighbor node of the graph node to obtain the neighborhood summary vector of the graph node, and determining the fused node feature vector of the graph node based on the neighborhood summary vector and the node feature vector of the graph node; for the graph node corresponding to the connected device and the standardized fault event... For the first type of edge corresponding to the graph node, obtain the score result of the target object for the first type of edge; determine the minimum health degree based on the health degree sequence of the devices in the two graph nodes corresponding to the first type of edge within the first time period; determine the association score of the first type of edge based on the fusion node feature vector of each of the two graph nodes corresponding to the edge; determine the confidence degree of the first type of edge based on the score result, minimum health degree and association score, and determine whether the first type of edge exists based on the relationship between the confidence degree and the preset threshold; for the second type of edge connecting two graph nodes corresponding to two devices or connecting two graph nodes corresponding to two standardized fault events, determine whether the corresponding second type of edge exists based on the device tree or the updated fault tree.

[0136] In an exemplary embodiment, the output module is further configured to: standardize the fault event to obtain a second standardized fault event when the abnormal state is a fault event; locate the source abnormal device directly associated with the second standardized fault event using the correlation heterogeneous graph; and output the source abnormal device. When the abnormal state is a device malfunction, determine the initial fault type based on the device's operating status information and determine the device's structural information in the device tree based on the correlation heterogeneous graph. Determine the starting graph node corresponding to the initial fault type within the correlation heterogeneous graph, and search the correlation heterogeneous graph based on the structural information, starting from the starting graph node, to obtain multiple suspected fault propagation paths, where each suspected fault propagation path includes at least one intermediate graph node. For each suspected fault propagation path, determine the real-time health of each intermediate graph node in the suspected fault propagation path, and determine the propagation probability of the suspected fault propagation path based on the sum of the real-time health of all intermediate graph nodes in the suspected fault propagation path, where a larger sum indicates a lower propagation probability. Determine the predicted fault propagation path corresponding to the device malfunction based on the propagation probability of each suspected fault propagation path, and output the predicted fault propagation path.

[0137] It should be noted that each module in the system abnormal state tracing device in this application embodiment corresponds one-to-one with each implementation step of the system abnormal state tracing method in embodiment 1. Since embodiment 1 has been described in detail, some details not shown in this embodiment can be referred to embodiment 1, and will not be elaborated further here.

[0138] Example 3

[0139] According to an embodiment of this application, a computer program product is also provided, which includes a computer program, wherein when the computer program is executed by a processor, it implements the system abnormal state tracing method in Embodiment 1.

[0140] According to an embodiment of this application, a non-volatile storage medium is also provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the system abnormal state tracing method in Embodiment 1 by running the computer program.

[0141] According to an embodiment of this application, a processor is also provided for running a computer program, wherein the computer program executes the system abnormal state tracing method in Embodiment 1 during runtime.

[0142] According to an embodiment of this application, an electronic device is also provided, comprising: a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the system abnormal state tracing method of Embodiment 1 through the computer program.

[0143] Specifically, the computer program executes the following steps during runtime: obtaining the device tree and fault tree of the target system, wherein the device tree is used to describe the hierarchical relationship between multiple devices in the target system, and the fault tree is used to describe the causal relationship between various standardized fault events occurring in the target system; generating an association heterogeneous graph of the target system based on the device tree and fault tree; obtaining the abnormal states of the target system within a first time period, wherein the abnormal states include abnormal device operation or fault events; tracing the source of the abnormal states based on the association heterogeneous graph, and outputting the tracing results.

[0144] As an alternative implementation, the above-mentioned electronic device may exist in the form of a mobile terminal, a computer terminal, or a similar computing device. Figure 3 A hardware block diagram of an electronic device for implementing a system anomaly tracing method is shown. (See diagram for example.) Figure 3As shown, the electronic device 30 may include one or more processors 302 (shown as 302a, 302b, ..., 302n in the figure) (processor 302 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 304 for storing data, and a transmission device 306 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, electronic device 30 may also include... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.

[0145] It should be noted that the aforementioned one or more processors 302 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element of the electronic device 30. As involved in the embodiments of this application, the data processing circuit serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0146] The memory 304 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the system anomaly tracing method in this embodiment. The processor 302 executes various functional applications and data processing by running the software programs and modules stored in the memory 304, thereby implementing the above-mentioned application vulnerability detection method. The memory 304 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 304 may further include memory remotely located relative to the processor 302, and these remote memories can be connected to the electronic device 30 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0147] The transmission device 306 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 30. In one example, the transmission device 306 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 306 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0148] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the electronic device 30.

[0149] The sequence numbers of the above embodiments are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0150] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0151] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0152] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0154] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0155] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for tracing the source of abnormal system states, characterized in that, include: Obtain the device tree and fault tree of the target system, wherein the device tree is used to describe the hierarchical relationship between multiple devices in the target system, and the fault tree is used to describe the causal relationship between multiple standardized fault events occurring in the target system; Based on the device tree and the fault tree, a heterogeneous association map of the target system is generated; The abnormal state of the target system within a first time period is obtained, wherein the abnormal state includes abnormal equipment operation or malfunction events; The abnormal state is traced based on the aforementioned heterogeneous correlation graph, and the tracing results are output.

2. The method according to claim 1, characterized in that, The device tree is determined in the following way: The technical documents of the target system are divided according to a preset division rule to obtain multiple text blocks, wherein the technical documents include at least the connection relationships between multiple devices within the target system; For each text block, the text block is analyzed using a first named entity recognition model to obtain multiple devices, and the device information of each device is determined, wherein the device information includes at least one of the following: device identifier, device model, and device parameters; the text block is analyzed using a dependency parsing model to determine the hierarchical relationship between the devices; A multi-level tree structure is constructed based on the hierarchical relationship of each device, and the device information of each device is used as the node information of each tree node in the tree structure to obtain the device tree.

3. The method according to claim 2, characterized in that, After constructing the device tree based on the aforementioned technical documentation, the method further includes: The device tree is subjected to hierarchical conflict verification using a pre-defined generative model to obtain corresponding verification results. The generative model is trained using a pre-defined system knowledge corpus, which includes at least: standard hierarchical relationships between multiple devices and adjustment suggestions for different types of hierarchical conflicts. The verification results are used to reflect at least two abnormal devices in the device tree that have hierarchical conflicts and the adjustment suggestions corresponding to the hierarchical conflicts that occur in the at least two abnormal devices. Using the adjustment suggestions in the verification results, the hierarchical adjustment is performed on the at least two abnormal devices with hierarchical conflicts to obtain the updated device tree.

4. The method according to claim 1, characterized in that, The fault tree is determined in the following way: Obtain the operation and maintenance log information of the target system during a second time period, wherein the operation and maintenance log information includes at least multiple operation and maintenance records that occurred in the target system during the second time period, and the second time period is a time period earlier than the first time period; For each of the operation and maintenance records, the operation and maintenance records are analyzed using the second named entity recognition model to obtain operation and maintenance triples, wherein the operation and maintenance triples include: fault device identifier, fault type, and fault cause; the operation and maintenance triples are standardized to obtain the standardized fault event corresponding to the operation and maintenance record; Based on the frequency of occurrence of each of the operation and maintenance records in the operation and maintenance log information, the probability of occurrence of the standardized fault event corresponding to each operation and maintenance record is determined, and the causal relationship between each standardized fault event is determined based on the fault cause in each standardized fault event. A multi-level tree structure is constructed based on the causal relationships between the standardized fault events, and the occurrence probability of each standardized fault event is used as the node information of each tree node in the tree structure to obtain the fault tree.

5. The method according to claim 4, characterized in that, Before constructing the correlation heterogeneity map of the target system based on the device tree and the fault tree, the method further includes: Obtain the health parameter sequence of each device in the target system within a first time period, wherein the health parameter sequence includes at least one of the following: efficiency health sequence and traffic health sequence; If the health parameter sequence of any target device in the target system is lower than a preset threshold, the device health file of the target device when the first standardized fault event occurs in the third time period before the first time period is obtained, and the device health file is analyzed using a preset life prediction model to obtain the predicted remaining life of the target device. The device health file includes at least one of the following: multi-dimensional sensor data, operation and maintenance status sequence, cumulative runtime, and operation and maintenance log information. The probability increment of the first standardized failure event is determined based on a preset scaling factor, the predicted remaining lifetime, and the maximum lifetime of the target device. The occurrence probability of the first standardized fault event in the fault tree is adjusted using the occurrence probability increment to obtain the updated fault tree.

6. The method according to claim 1, characterized in that, Based on the device tree and the fault tree, a heterogeneous correlation graph of the target system is constructed, including: Based on the device information of each device in the device tree and the structural information of each device in the device tree, the first feature information of each device is determined, and based on the occurrence probability of each standardized fault event in the updated fault tree and the structural information of each standardized fault event in the fault tree, the second feature information of each fault event is determined, wherein the structural information includes at least one of the following: the depth corresponding to the level, the number of parent nodes, and the number of child nodes. The first feature information of each device in the device tree and the second feature information of each standardized fault event in the updated fault tree are used as the node information of multiple graph nodes. Based on the device tree and the updated fault tree, the edges between every two graph nodes are determined to construct the associated heterogeneous graph of the target system.

7. The method according to claim 6, characterized in that, Determining the edge between every two graph nodes based on the device tree and the updated fault tree includes: The first feature information of each of the devices and the second feature information of each of the standardized fault events are encoded to obtain the node feature vector of each of the graph nodes, wherein the type of the graph node includes: device or fault event; For each graph node, the node feature vectors of at least one k-order neighbor node of the graph node are aggregated to obtain the neighborhood summary vector of the graph node, and the fused node feature vector of the graph node is determined based on the neighborhood summary vector and the node feature vector of the graph node. For the first type of edges of graph nodes corresponding to connected devices and graph nodes corresponding to standardized fault events, obtain the scoring result of the target object for the first type of edges; determine the minimum health score based on the health score sequence of the devices in the two graph nodes corresponding to the first type of edges within the first time period; determine the association score of the first type of edges based on the fused node feature vectors of the two graph nodes corresponding to the edges; determine the confidence score of the first type of edges based on the scoring result, the minimum health score and the association score, and determine whether the first type of edges exist based on the relationship between the confidence score and a preset threshold. For a second type edge connecting graph nodes corresponding to two devices or graph nodes corresponding to two standardized fault events, determine whether the corresponding second type edge exists based on the device tree or the updated fault tree.

8. The method according to claim 1, characterized in that, The abnormal state is traced based on the aforementioned heterogeneous correlation map, and the tracing results are output, including: When the abnormal state is the fault event, the fault event is standardized to obtain a second standardized fault event, and the source abnormal device directly associated with the second standardized fault event is located using the correlation heterogeneous map, and the source abnormal device is output. When the abnormal state is that the device is malfunctioning, the initial fault type is determined based on the operating status information of the device corresponding to the malfunction, and the structural information of the device corresponding to the malfunction in the device tree is determined based on the heterogeneous association graph. The starting graph node corresponding to the initial fault type within the heterogeneous association graph is determined, and starting from the starting graph node, the heterogeneous association graph is searched based on the structural information to obtain multiple suspected fault propagation paths. Each suspected fault propagation path includes at least one intermediate graph node. For each suspected fault propagation path, the real-time health of each intermediate graph node in the suspected fault propagation path is determined, and the propagation probability of the suspected fault propagation path is determined based on the sum of the real-time health of all intermediate graph nodes in the suspected fault propagation path. The larger the sum, the lower the propagation probability of the suspected fault propagation path. The predicted fault propagation path corresponding to the device malfunction is determined based on the propagation probability of each suspected fault propagation path, and the predicted fault propagation path is output.

9. A system abnormal state tracing device, characterized in that, include: The first acquisition module is used to acquire the device tree and fault tree of the target system, wherein the device tree is used to describe the hierarchical relationship between multiple devices in the target system, and the fault tree is used to describe the causal relationship between multiple standardized fault events occurring in the target system. A construction module is used to generate an association heterogeneous graph of the target system based on the device tree and the fault tree; The second acquisition module is used to acquire the abnormal state of the target system within a first time period, wherein the abnormal state includes abnormal equipment operation or fault events. The output module is used to trace the abnormal state based on the correlation heterogeneous graph and output the tracing results.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, wherein the device containing the non-volatile storage medium executes the system abnormal state tracing method according to any one of claims 1 to 8 by running the computer program.

Images