Mechanical and electrical system operation and maintenance method, device and equipment based on knowledge graph and medium

Abstract

Embodiments of the present disclosure disclose a knowledge graph-based electromechanical system operation and maintenance method, device, equipment and medium. A specific implementation of the method includes: generating original time series data and text record data; performing multi-dimensional time series feature extraction on the original time series data, and performing natural language processing on the text record data to obtain causal correlation path features and time delay features; performing pruning processing on an electromechanical field knowledge graph to obtain a fault candidate root cause subgraph; fusing the time series features, the time delay features and the fault subgraph to generate a directed acyclic causal topology structure; determining first root cause information, second root cause information and a fault propagation path; generating an operation and maintenance scheme; and in response to receiving an operation and maintenance instruction corresponding to the operation and maintenance scheme, performing a corresponding operation and maintenance operation. The implementation can accurately locate the root cause of the electromechanical system fault and automatically generate and execute the operation and maintenance scheme, saving fault troubleshooting time and operation and maintenance cost.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a knowledge graph-based method, apparatus, device, and medium for the operation and maintenance of electromechanical systems. Background Technology

[0002] Currently, root cause reasoning for electromechanical system failures mainly relies on three types of methods: expert rules, data-driven approaches, and physical models. For the fault operation and maintenance of complex electromechanical systems, the common approaches are: constructing fault trees or using expert systems for rule matching, utilizing machine learning models for fault classification and pattern recognition, or performing residual analysis and simulation verification based on mathematical models.

[0003] However, when using the above methods for the operation and maintenance of electromechanical systems, the following technical problems often arise: traditional rule-based methods rely on static models, which are difficult to adapt to equipment changes and dynamic operating conditions; pure data-driven methods have weak generalization ability in small sample scenarios, and the reasoning results lack physical interpretability, resulting in long root cause localization time and high misjudgment rate, thus causing a waste of operation and maintenance costs and time.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose a knowledge graph-based method, apparatus, equipment, and medium for the operation and maintenance of electromechanical systems to address one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a knowledge graph-based operation and maintenance method for electromechanical systems, including: in response to receiving fault alarm information, generating raw time-series data and text record data based on collected multi-source heterogeneous operating data of the electromechanical system; extracting multi-dimensional time-series features from the raw time-series data and performing natural language processing on the text record data to obtain causal association path features and time delay features; pruning the electromechanical knowledge graph based on a preset electromechanical knowledge graph, starting from the fault node corresponding to the current fault, to obtain a fault candidate root factor graph; fusing the multi-dimensional time-series features, the time delay features, and the fault candidate root factor graph to generate a directed acyclic causal topology; determining a first root cause information, a second root cause information, and a fault propagation path using a Bayesian network based on the directed acyclic causal topology; generating an operation and maintenance plan based on the first root cause information, the second root cause information, and the fault propagation path; and executing the corresponding operation and maintenance operation upon receiving the operation and maintenance instruction corresponding to the operation and maintenance plan.

[0008] Secondly, some embodiments of this disclosure provide a knowledge graph-based electromechanical system operation and maintenance device, including: a first generation unit configured to, in response to receiving fault alarm information, generate raw time-series data and text record data based on collected multi-source heterogeneous operating data of the electromechanical system; a first processing unit configured to perform multi-dimensional time-series feature extraction on the raw time-series data and natural language processing on the text record data to obtain causal relationship path features and time delay features; and a second processing unit configured to, based on a preset electromechanical knowledge graph, process the electromechanical knowledge graph starting from the fault node corresponding to the current fault. The system performs pruning to obtain a fault candidate root factor graph; a fusion unit is configured to fuse the aforementioned multi-dimensional temporal features, the aforementioned time delay features, and the aforementioned fault candidate root factor graph to generate a directed acyclic causal topology; a determination unit is configured to determine the first root cause information, the second root cause information, and the fault propagation path based on the aforementioned directed acyclic causal topology using a Bayesian network; a second generation unit is configured to generate an operation and maintenance plan based on the aforementioned first root cause information, the aforementioned second root cause information, and the aforementioned fault propagation path; and an execution unit is configured to execute the corresponding operation and maintenance operation in response to receiving the operation and maintenance instruction corresponding to the aforementioned operation and maintenance plan.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, such that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any implementation of the first aspect.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0011] The above-described embodiments of this disclosure have the following beneficial effects: Through the knowledge graph-based electromechanical system operation and maintenance method of some embodiments of this disclosure, the root cause of electromechanical system failures can be accurately located, and operation and maintenance plans can be automatically generated and executed, saving troubleshooting time and operation and maintenance costs. Specifically, the reasons for the low efficiency and high cost of traditional electromechanical system failure troubleshooting are: existing technologies heavily rely on expert experience to build static failure models, which are difficult to adapt to the dynamic changes and multi-fault coupling and propagation characteristics of electromechanical systems. At the same time, data-driven methods lack physical interpretability and rely on a large number of labeled samples, resulting in insufficient root cause location accuracy, long inference time, and high misjudgment rate, thus causing low troubleshooting efficiency and high operation and maintenance costs. Based on this, the knowledge graph-based electromechanical system operation and maintenance method of some embodiments of this disclosure firstly, in response to receiving fault alarm information, generates original time-series data and text record data based on the collected multi-source heterogeneous operating data of the electromechanical system. By collecting multi-source heterogeneous operational data and generating raw time-series data and text records, unified digitization of real-time sensor data and historical text knowledge is achieved, laying a data foundation for subsequent multimodal fusion analysis and avoiding the information gaps caused by a single data source. Then, multi-dimensional time-series feature extraction is performed on the raw time-series data, and natural language processing is applied to the text records to obtain causal relationship path features and time delay features. Through time-series feature extraction and text natural language processing, the raw data is transformed into causal relationship path features and time delay features, revealing the structured relationships and temporal patterns of fault propagation, providing quantifiable causal clues for subsequent reasoning. Next, based on a pre-defined electromechanical knowledge graph, the knowledge graph is pruned starting from the fault node corresponding to the current fault, resulting in a fault candidate root factor graph. This knowledge graph pruning process, starting from the fault node, eliminates irrelevant entities and paths, narrowing the reasoning scope to the candidate root factor graph, significantly reducing the complexity of subsequent calculations and improving the real-time performance of fault location. Next, the aforementioned multi-dimensional temporal features, time delay features, and fault candidate root factor graphs are fused to generate a directed acyclic causal topology. By fusing temporal features, time delay features, and fault candidate root factor graphs, a directed acyclic causal topology is generated, achieving a deep integration of data-driven and knowledge-driven approaches, eliminating spurious correlations, and constructing an accurate causal propagation framework. Secondly, based on the aforementioned directed acyclic causal topology, a Bayesian network is used to determine the first root cause information, the second root cause information, and the fault propagation path. Based on the directed acyclic causal topology and the Bayesian network, the posterior probability of each candidate root cause is quantified, accurately distinguishing between core and secondary root causes, and outputting a clear fault propagation path, improving the interpretability and credibility of the diagnostic results. Thirdly, based on the aforementioned first root cause information, second root cause information, and fault propagation path, an operation and maintenance plan is generated.Based on root cause information and propagation paths, an operation and maintenance (O&M) plan is generated, automating the transition from diagnosis to decision-making. This provides O&M personnel with targeted and actionable operational guidance, shortening decision-making time. Finally, in response to receiving O&M instructions corresponding to the aforementioned O&M plan, the corresponding O&M operations are executed. By receiving O&M instructions and executing corresponding operations, a complete closed-loop automation from diagnosis to repair is achieved, reducing manual intervention, lowering the risk of operational errors, and accelerating the recovery of electromechanical systems. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the knowledge graph-based electromechanical system operation and maintenance method according to this disclosure; Figure 2 This is a schematic diagram of the structure of some embodiments of the knowledge graph-based electromechanical system operation and maintenance device according to this disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0016] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] refer to Figure 1 The diagram illustrates a flow 100 of some embodiments of a knowledge graph-based electromechanical system operation and maintenance method according to the present disclosure. This knowledge graph-based electromechanical system operation and maintenance method includes the following steps: Step 101: In response to receiving the fault alarm information, generate raw time-series data and text record data based on the collected multi-source heterogeneous operation data of the electromechanical system.

[0021] In some embodiments, the executing entity (e.g., an electronic device) of the knowledge graph-based electromechanical system operation and maintenance method described above can be hardware or software. When the computing device is hardware, it can be implemented as a distributed cluster composed of multiple servers or terminal devices, or as a single server or a single terminal device. When the computing device is software, it can be installed in the hardware devices listed above. It can be implemented as multiple software programs or software modules to provide distributed services, or as a single software program or software module. No specific limitations are made here.

[0022] In other embodiments, the aforementioned execution entity can, in response to receiving fault alarm information, generate raw time-series data and text record data based on the collected multi-source heterogeneous operating data of the electromechanical system. The fault alarm information can be an abnormal alarm signal issued by the electromechanical system monitoring platform; for example, it could be an alarm notification of "abnormal outgoing voltage of low-voltage distribution cabinet" in a power supply and distribution system. The electromechanical system can be a complex engineering system comprising specialized subsystems such as HVAC, power supply and distribution, and water supply and drainage; for example, it could be the power supply and distribution system of a commercial complex. The multi-source heterogeneous operating data can be data in different formats from various sources such as sensors, equipment ledgers, and maintenance records. Examples include voltage time-series data, Excel equipment lists, and Word maintenance reports. The raw time-series data can be unprocessed time-series signals collected by sensors; for example, a sequence of current values ​​sampled per second [120.3, 120.5, 119.8, ...]. The text record data can be unstructured or semi-structured text such as equipment ledgers, maintenance records, and technical disclosure documents.

[0023] In some optional implementations of certain embodiments, the aforementioned execution entity may, in response to receiving fault alarm information, generate raw time-series data and text record data based on the collected multi-source heterogeneous operating data of the electromechanical system, which may include the following steps: The first step, in response to a received fault alarm, involves collecting runtime sequence data from the target sensors and synchronizing multiple text records via an interface to generate multi-source heterogeneous raw data. These multiple text records include at least: equipment ledgers, maintenance records, and technical disclosure documents. The target sensors can be monitoring devices directly related to the current fault. For example, voltage transformers or current transformers corresponding to voltage anomalies. The runtime sequence data can be continuously collected state parameters that change over time during equipment operation. For example, compressor exhaust temperature recorded every 0.5 seconds. The equipment ledger can be an information table recording the static attributes of the equipment, including model, location, and commissioning date. For example, "Distribution cabinet number PD-03, location B1" obtained from the CMMS system. The maintenance records can be historical fault handling documents, including fault symptoms, root causes, and maintenance measures. For example, "Voltage anomaly was caused by poor circuit breaker contact; replacement resolved the issue." The technical disclosure documents can be technical specifications for equipment installation, commissioning, and maintenance. For example, "Power supply and distribution system technical disclosure: Circuit breaker contact resistance should be less than 0.5mΩ." In practice, in response to a "low-voltage distribution cabinet voltage abnormality" fault alarm, the system collects real-time operational sequence data of the voltage transformers and current transformers (one sampling point every 10 milliseconds) via the OPC UA protocol. Then, it synchronizes the distribution cabinet's equipment ledger (equipment number, model, location, commissioning date) from the CMMS system via a REST API interface, along with maintenance records (all maintenance work orders related to the cabinet within the past year) and technical handover documents (operation manuals provided by the equipment manufacturer). Finally, the collected time-series data and the synchronized multi-document data are associated and packaged according to equipment ID and timestamp to generate multi-source heterogeneous raw data.

[0024] The second step involves interpolating and performing wavelet denoising on the time-series data from the aforementioned multi-source heterogeneous original data to obtain standardized time-series data. This time-series data can be a sequence of data points arranged in chronological order. The interpolation can be performed using mathematical methods (e.g., linear interpolation) to estimate the values ​​of missing data points. The wavelet denoising can utilize wavelet transform to decompose the signal and remove high-frequency noise components. For example, wavelet soft thresholding can be used for voltage signals. The standardized time-series data can be uniformly formatted time-series data after cleaning, denoising, and normalization. For example, pressure data normalized to the [0, 1] interval. In practice, firstly, the location of missing points in the original time-series data is detected, and the missing value is calculated using linear interpolation (taking the weighted average of two consecutive valid values). Then, wavelet decomposition is performed on the interpolated complete time-series data (using the db4 wavelet basis, with 3 decomposition levels), and noise in the high-frequency detail coefficients is zeroed out using a soft thresholding function. Finally, the processed wavelet coefficients of each layer are reconstructed by inverse transform to obtain smooth, continuous, and noise-free standardized time series data.

[0025] The third step involves performing entity recognition on the text data from the aforementioned multi-source heterogeneous raw data to extract fault phenomenon entities, root cause entities, and maintenance measure entities, generating structured text record data. This entity recognition can be achieved using natural language processing techniques that automatically identify and extract specific categories of words from the text. For example, the BERT-BiLSTM-CRF named entity recognition model can be used for entity recognition. Fault phenomenon entities can be words describing the fault's manifestation. For example, "high-voltage alarm" can be extracted from the text. Root cause entities can be words describing the fundamental cause of the fault. For example, "bearing wear" can be extracted. Maintenance measure entities can be operational actions that solve the problem. For example, "replace the bearing and correct the coupling" can be extracted. First, the text data, including equipment ledgers, maintenance records, and technical briefing documents, are uniformly segmented, part-of-speech tagging, and syntactic dependency analysis are performed to divide long texts into sentence units. Then, a pre-trained BERT-BiLSTM-CRF named entity recognition model is used to label and extract the three types of entities—fault phenomenon, root cause, and maintenance measure—from each sentence. Finally, the extracted entities are organized according to the triple structure of "fault phenomenon entity - root cause entity - maintenance measure entity" and stored as structured text record data in JSON format.

[0026] Step 102 involves extracting multidimensional time-series features from the original time-series data and performing natural language processing on the text record data to obtain causal relationship path features and time delay features.

[0027] In some embodiments, the aforementioned execution entity can perform multi-dimensional time-series feature extraction on the aforementioned original time-series data and natural language processing on the aforementioned text record data to obtain causal relationship path features and time delay features. The aforementioned multi-dimensional time-series feature extraction can be a process of extracting feature parameters reflecting the signal change patterns from time-series data. For example, calculating the mean and variance of a voltage waveform. The aforementioned natural language processing can be a technique for extracting structured information from text using algorithms. For example, using named entity recognition to extract fault keywords. The aforementioned causal relationship path features can be structured path information describing the causal transmission relationship between fault phenomena and candidate root causes. For example, "circuit breaker poor contact -> voltage abnormality -> compressor shutdown". The aforementioned time delay features can be the time difference experienced by the fault propagating from the root cause to the downstream node. For example, the compressor shuts down 2 seconds after the voltage abnormality.

[0028] In some optional implementations of certain embodiments, the execution entity may perform multi-dimensional time-series feature extraction on the original time-series data and natural language processing on the text record data to obtain causal relationship path features and time delay features, which may include the following steps: The first step is to perform feature extraction processing on the original time-series data to generate multi-dimensional time-series features, including time-domain features, frequency-domain features, and time-frequency features. These multi-dimensional time-series features can be comprehensive feature vectors extracted from multiple perspectives, such as time domain, frequency domain, and time-frequency. For example, [mean 0.5, variance 0.1, dominant frequency 50Hz]. The time-domain features can be statistics directly extracted from the changes of the original signal over time. For example, peak value, mean, variance, and kurtosis. The frequency-domain features can be spectral characteristics extracted after transforming the signal to the frequency domain. For example, the fault characteristic frequency 50Hz and its amplitude. The time-frequency features can be features that simultaneously describe local information about the signal's time and frequency. For example, wavelet packet decomposition coefficients. In practice, firstly, the standardized time-series data is divided into sliding segments according to a fixed time window (e.g., 1 second), and the time-domain statistics such as mean, variance, peak value, and kurtosis within each window are calculated. Then, a Fast Fourier Transform (FFT) is performed on the time-series data for each window to extract the three frequency components with the largest amplitudes in the spectrum and their amplitudes as frequency domain features. Finally, a three-level wavelet packet decomposition is performed on the time-series data to extract the energy coefficients of each frequency band node as time-frequency features. The three types of features are then concatenated to generate a multi-dimensional time-series feature vector. For example, the voltage data is calculated with a mean of 220V and a variance of 5 per second window; FFT extracts the 50Hz fundamental amplitude of 220V and the 100Hz harmonic amplitude of 2V; wavelet packet decomposition yields energy coefficients for 8 frequency bands, ultimately generating a 15-dimensional feature vector.

[0029] The second step involves entity linking and relational reasoning based on the structured text record data to generate causal path features for the fault. Entity linking involves aligning and matching entities extracted from the text with existing entities in the knowledge graph. For example, "contact erosion" is linked to the "circuit breaker contact erosion" node in the graph. Relational reasoning involves inferring implicit causal relationships between entities based on existing relationships in the knowledge graph. For example, "A causes B" and "B causes C" can be used to infer "A causes C". In practice, first, fault phenomenon entities (such as "abnormal voltage") and candidate root cause entities (such as "poor contact"), as well as equipment identifiers from maintenance records, are extracted from the structured text record data. Then, the extracted entities are linked with nodes in a pre-defined electromechanical knowledge graph to find the corresponding standardized node names. Finally, a graph traversal algorithm (such as depth-first search) is used to start from the root cause node and follow the "cause" relationship path in the graph to reach the fault node, recording the node sequence and edge type of each path to generate causal path features for the fault. The aforementioned candidate root cause entities can be abnormal terms related to equipment status or components extracted from text that may lead to failure, such as "bearing wear," "contact erosion," and "cable aging." The aforementioned pre-built electromechanical knowledge graph can be a pre-constructed structured knowledge network containing entities such as equipment, components, parameters, failure modes, and root causes, along with their causal relationships. For example, the aforementioned pre-built electromechanical knowledge graph could be a knowledge graph in the field of building electromechanical systems, containing nodes such as "circuit breaker -> contact -> poor contact -> voltage anomaly" and "cause" relationship edges.

[0030] The third step involves calculating the fault propagation delay of the aforementioned multi-dimensional time-series features to generate a fault propagation time delay feature. This calculation can be performed by determining the time delay of fault propagation between different nodes based on the time difference between sensor anomalies. For example, calculating the difference between the time of anomaly at sensor A and the time of anomaly at sensor B. In practice, firstly, anomaly detection is performed on different sensor signals in the multi-dimensional time-series features, marking the time point when each parameter first exceeds the alarm threshold. Then, using the sensor anomaly time corresponding to the fault phenomenon as a reference, the difference between the anomaly time of each candidate root cause-related sensor and this reference is calculated. Finally, the median of multiple sampling calculations is taken as the stable propagation delay, and positive and negative delays are processed separately (positive delay indicates that the root cause precedes the fault) to generate a fault propagation time delay feature. For example, if the voltage anomaly occurs at t=10.0 seconds and the current fluctuation anomaly occurs at t=8.0 seconds, the delay feature is -2.0 seconds (indicating that the current fluctuation occurs first), and the compressor shutdown lags by 2 seconds, resulting in a delay of +2.0 seconds.

[0031] Step 103: Based on the preset electromechanical knowledge graph, the electromechanical knowledge graph is pruned starting from the fault node corresponding to the current fault to obtain the fault candidate root factor graph.

[0032] In some embodiments, the aforementioned execution entity can prune the electromechanical knowledge graph based on a preset electromechanical knowledge graph, starting from the fault node corresponding to the current fault, to obtain a fault candidate root factor graph. The fault node corresponding to the current fault can be a unique node in the knowledge graph representing the currently occurring fault phenomenon. For example, the "voltage anomaly" node. The pruning process can be a process of deleting entities and paths in the knowledge graph that are not causally related to the fault, starting from the fault node. For example, deleting the "oil pressure" node, which is unrelated to "voltage anomaly". The fault candidate root factor graph can be a simplified subgraph containing only the fault node, candidate root factor nodes, and the causal path between them. For example, the fault candidate root factor graph can be a subgraph of "poor contact -> voltage anomaly".

[0033] In some optional implementations of certain embodiments, the aforementioned execution entity may, based on a preset electromechanical knowledge graph, prune the electromechanical knowledge graph starting from the fault node corresponding to the current fault to obtain a fault candidate root factor graph, which may include the following steps: The first step involves starting with the fault node corresponding to the current fault and tracing upstream through the pre-defined electromechanical knowledge graph to identify entity nodes with causal relationships to that fault node, thus generating an initial candidate root cause set. The upstream direction can be the source direction of the causal relationship in the knowledge graph, i.e., the root cause side traced back from the fault node along the "cause" edge. For example, tracing upstream from "voltage anomaly" to find "poor contact." The initial candidate root cause set can be the set of all entity nodes that could potentially cause the fault, obtained by tracing upstream. For example, {circuit breaker poor contact, transformer fault, cable aging}. In practice, firstly, starting with the fault node corresponding to the current fault "voltage anomaly," all "cause" relationships pointing to that node are identified in the pre-defined electromechanical knowledge graph. Then, the graph recursively traverses along the reverse direction of these relationships (i.e., from the fault node upstream), collecting all entity nodes that can reach the fault node through one or more "cause" edges. Finally, all collected nodes are deduplicated and added to the candidate set to generate the initial candidate root cause set.

[0034] The second step involves classifying each entity node in the initial candidate root cause set by equipment type to eliminate cross-system interference nodes unrelated to the subsystem to which the current fault belongs, thus generating a filtered candidate root cause set. This equipment type classification can be based on the equipment category to which the entity belongs (e.g., power supply and distribution, HVAC). For example, "circuit breaker" can be categorized as power supply and distribution, and "compressor" as HVAC. Cross-system interference nodes can be entities from other systems that are not directly related to the subsystem to which the current fault belongs. For example, the "water pump motor" node in a voltage anomaly fault. The filtered candidate root cause set can be a set of relevant candidate root causes retained after eliminating cross-system interference nodes. For example, only {circuit breaker poor contact, transformer fault} from the power supply and distribution system can be retained. In practice, first, the identifier of the subsystem to which the current fault belongs (e.g., "power supply and distribution system") is obtained, and the equipment type label associated with each node in the initial candidate root cause set is obtained. Then, each candidate root cause node is traversed to determine whether its equipment type matches the current fault subsystem (e.g., "circuit breaker" belongs to power supply and distribution, and "compressor" belongs to HVAC). Finally, all cross-system interference nodes that do not match the subsystems are removed to generate a filtered set of candidate root causes.

[0035] The third step involves performing path connectivity checks on each entity node in the filtered candidate root cause set to generate a path-connected candidate root cause set. This path connectivity check can examine whether a complete directed causal path exists between a candidate root cause node and the fault node. For example, it checks whether "transformer fault" is connected to "voltage anomaly" through intermediate nodes. The path-connected candidate root cause set can be the set of candidate root causes that form complete causal paths after passing the connectivity check. For example, {circuit breaker contact failure} (transformer faults are eliminated because they have no connected path). In practice, firstly, for each node in the filtered candidate root cause set, all directed paths from that node to the fault node are extracted. Then, the connectivity of each path is checked sequentially to confirm that all intermediate nodes and edges on the path exist in the knowledge graph and are in the correct direction (from the root cause to the fault). Finally, only those candidate root cause nodes with at least one complete directed connected path are retained, generating the path-connected candidate root cause set.

[0036] The fourth step involves merging redundant paths in the candidate root cause set after the paths are connected, to generate a simplified set of causal propagation paths. This redundancy merging can involve combining multiple causal paths pointing to the same node or repeating paths into a single unique path. For example, two paths, "poor contact -> increased resistance -> voltage drop -> abnormal voltage," can be merged into one. The simplified set of causal propagation paths can be a set of unique causal paths after deduplication and merging. For example, {circuit breaker poor contact -> increased contact resistance -> voltage drop -> abnormal voltage}. In practice, first, all causal paths from each root cause node to the fault node in the candidate root cause set after the paths are connected are traversed, and each path is represented as a sequence of nodes. Then, the node sequences of different paths are compared to identify paths with duplicate or inclusion relationships (e.g., two paths passing through the same node sequence). Finally, duplicate paths are merged into a single unique path, and sub-paths in inclusion relationships are merged into the parent path, generating a simplified set of causal propagation paths.

[0037] The fifth step involves generating a fault candidate root factor graph based on the simplified causal propagation path set. First, all nodes (including fault nodes, candidate root cause nodes, and intermediate nodes) and all connecting edges appearing in the paths are extracted from the simplified causal propagation path set. Then, these nodes and edges are extracted from the original knowledge graph to construct an independent subgraph data structure. Finally, the subgraph undergoes format validation and node deduplication to generate a fault candidate root factor graph containing only causal relationships. For example, from the retained unique path, nodes {poor contact, increased resistance, voltage drop, abnormal voltage} and edges {caused by, caused by, caused by} are extracted to generate a directed subgraph with 4 nodes and 3 edges.

[0038] Step 104: The multidimensional time series features, time delay features and fault candidate root factor graph are fused to generate a directed acyclic causal topology.

[0039] In some embodiments, the executing entity can fuse the multidimensional temporal features, the time delay features, and the fault candidate root factor graph to generate a directed acyclic causal topology. This directed acyclic causal topology can be a causal graph structure where variables have directions and no cyclic dependencies. For example, A->B->C, without cycles of A->C or C->A.

[0040] In some optional implementations of certain embodiments, the execution entity may fuse the multidimensional temporal features, the time delay features, and the fault candidate root factor graph to generate a directed acyclic causal topology, which may include the following steps: The first step is to construct an initial variable set using the candidate root cause nodes in the aforementioned fault candidate root factor graph as variable nodes and the various feature components in the aforementioned multidimensional time-series features as variable attributes. The candidate root cause nodes can be entity nodes that may cause faults, obtained after knowledge graph pruning. For example, the "circuit breaker poor contact" node. The variable nodes can be abstract nodes representing equipment parameters or states in causal reasoning. For example, nodes corresponding to voltage, current, and temperature. The various feature components can be single statistics in the multidimensional time-series features. For example, mean 0.5, variance 0.1. The variable attributes can be parameters describing the numerical characteristics of the variable nodes. For example, the mean and variance of the voltage variable. The initial variable set can be a list of variables formed by associating candidate root cause nodes with feature components. For example, {V_mean voltage, V_variance voltage, V_poor contact}. In practice, firstly, all candidate root cause nodes (such as "poor contact", "cable aging") are extracted from the fault candidate root factor graph as variable nodes. Then, each feature component in the multidimensional time series features (such as mean voltage, voltage variance, and peak current) is associated and bound as the attribute value of each variable node. Finally, all variable nodes and their attributes are combined into a list to generate the initial variable set.

[0041] The second step involves performing a conditional independence test on each pair of variable nodes in the aforementioned causal relationship path features, based on the initial variable set, to generate an undirected causal skeleton graph. Each pair of variable nodes can be any two distinct variables from the initial variable set, such as (mean voltage, mean current). The conditional independence test can be a statistical test to determine whether two variables are independent given other variables, such as a partial correlation coefficient test. The undirected causal skeleton graph can simply represent the correlation between variables (without direction), such as voltage-current-temperature with no arrows on the edges. In practice, first, a partial correlation coefficient is calculated for each pair of variable nodes in the initial variable set (e.g., mean voltage and mean current) to control for the influence of other variables. Then, variable pairs with absolute partial correlation coefficients less than a preset threshold (e.g., 0.3) are considered conditionally independent, and their candidate edges are deleted. Finally, all edges between conditionally independent variable pairs are retained to generate the undirected causal skeleton graph.

[0042] The third step involves assigning causal directions to each edge in the generated undirected causal skeleton graph based on the aforementioned time delay characteristics, thereby generating a directed causal graph with directional labels. This causal direction assignment can be based on determining the direction of causal edges according to time delays. For example, a variable that occurs earlier points to a variable that occurs later. The directed causal graph with directional labels can be a causal graph where each edge has been assigned a direction but cycles may exist. For example, A->B, B->C, C->A (with cycles). In practice, first, the time delay characteristics corresponding to the variable nodes of each pair of edges are obtained (e.g., voltage anomalies lag behind current fluctuations by 2 seconds). Then, the causal direction is determined based on the sign of the time delay: the earlier occurrence is the cause, and the later occurrence is the effect (a negative delay indicates that the former precedes the latter). Finally, an arrow pointing from the cause node to the effect node is added to each edge in the skeleton graph, generating a directed causal graph with directional labels.

[0043] The fourth step involves performing loop detection and direction correction on the directed causal graph based on the prior causal constraints in the aforementioned fault candidate root factor graph, to generate an acyclic directed causal topology. The prior causal constraints can be pre-existing causal relationship rules in a knowledge graph. For example, "poor contact" necessarily leads to "voltage drop". Loop detection can check for the existence of directed cycles (cyclic dependencies) in the directed graph. For example, a cycle A->B->C->A is detected. Direction correction can eliminate loops by reversing or deleting edges that cause cycles based on prior constraints. For example, deleting the C->A edge breaks the cycle. First, a depth-first search is performed on the directed causal graph generated in the third step to detect the existence of directed cycles (such as A->B->C->A). Then, if a cycle is detected, the prior causal constraints in the fault candidate root factor graph (such as the rule "A cannot cause C" in the knowledge graph) are used to determine which edge should be deleted or reversed. Finally, the direction of edges in the cycle is corrected or redundant edges are deleted based on the constraints to generate an acyclic directed causal topology.

[0044] Step 105: Based on the directed acyclic causal topology, use a Bayesian network to determine the first root cause information, the second root cause information, and the fault propagation path. In some embodiments, the aforementioned executing entity can utilize a Bayesian network based on the aforementioned directed acyclic causal topology to determine the first root cause information, the second root cause information, and the fault propagation path. The Bayesian network can be a probabilistic graphical model based on a directed acyclic graph representing the probabilistic dependencies between variables. For example, nodes represent fault causes, and edges represent causal relationships. The first root cause information can be the core root cause node with the highest posterior probability and its attributes. For example, the core root cause is "circuit breaker poor contact," with a probability of 92%. The second root cause information can be the secondary root cause node with the second highest posterior probability and its attributes. For example, the secondary root cause is "load imbalance," with a probability of 18%. The fault propagation path can be a sequence of directed edges from the root cause node to the fault node along the causal relationship. For example, poor contact -> increased resistance -> voltage drop -> abnormal voltage.

[0045] In some optional implementations of certain embodiments, the aforementioned execution entity can determine the first root cause information, the second root cause information, and the fault propagation path based on the aforementioned directed acyclic causal topology using a Bayesian network, which may include the following steps: The first step is to use the aforementioned directed acyclic causal topology as the fixed skeleton of the Bayesian network to determine the conditional dependencies between nodes in the network. These conditional dependencies can be probabilistic dependencies between nodes, represented by directed edges. For example, A->B means that the probability of B depends on A. In practice, firstly, the DAG (directed acyclic causal topology) generated in the previous step is directly imported into the Bayesian network construction tool. Then, each node and each directed edge in the DAG is parsed, and the same node and edge connections are established in the Bayesian network. Finally, the set of parent nodes for each node is automatically determined based on the DAG's topology, generating the fixed skeleton of the Bayesian network, thus clarifying the conditional dependencies between nodes.

[0046] The second step involves quantifying the causal intensity of the directed edges from each candidate root cause node to the fault node based on the aforementioned multidimensional time-series features and causal path features, to generate the average causal effect value for each directed edge. This causal intensity quantification can be achieved by calculating the influence of each directed edge using an algorithm (such as a causal forest). For example, the causal intensity of "poor contact -> abnormal voltage" is calculated to be 0.92. The average causal effect value for each directed edge can be the standardized influence score (0-1) of each causal edge. For example, the ATE value for edge A->B is 0.87. In practice, firstly, multidimensional time-series features (such as average voltage and peak current) and causal path features (such as path length and number of intermediate nodes) are obtained along the path from each candidate root cause node to the fault node. Then, the causal forest algorithm is used, with these features as input, to model the causal effect of each directed edge and calculate the average causal effect (ATE) value. Finally, the ATE value of each edge is normalized to the [0,1] interval to generate the average causal effect value for each directed edge.

[0047] The third step involves using the average causal effect values ​​of the directed edges mentioned above as prior parameters for the conditional probability table of the Bayesian network, based on the aforementioned conditional dependencies, to generate the initialized Bayesian network. These prior parameters can be the initial values ​​of the probability distribution of each node in the Bayesian network depending on its parent node. For example, P(voltage anomaly|poor contact) = 0.9. The initialized Bayesian network can be a Bayesian network with a fixed topology and pre-filled with prior conditional probability tables. First, the set of parent nodes for each node is obtained from the Bayesian network skeleton determined in the first step. Then, for each node, the combined states of its parent nodes are used as conditions, and the average causal effect values ​​of the corresponding directed edges obtained in the second step are used to fill the probability values ​​in the conditional probability table. Finally, the conditional probability tables for all nodes are assigned values, generating the initialized Bayesian network. For example, the parent node of node "voltage anomaly" is "voltage dip", and we set P(voltage anomaly|voltage dip) = 0.95; the parent node of node "voltage dip" is "resistance increase", and we set P(voltage dip|resistance increase) = 0.92, and so on. The fourth step involves performing a posterior inference process based on the current fault phenomenon and the initialized Bayesian network to generate posterior probability information for each candidate root cause node. This posterior inference process can be the calculation of the probability of each node given observed evidence (fault phenomenon). The posterior probability information for each candidate root cause node can be the probability of each candidate root cause occurring after the fault is observed. For example, P(poor contact|abnormal voltage) = 0.92. In practice, firstly, the currently observed fault phenomenon (such as "abnormal voltage" occurring) is input as evidence into the initialized Bayesian network, fixing the state of that node as "true". Then, a Bayesian posterior inference algorithm (such as variable elimination or belief propagation) is run to calculate the posterior probability of all unobserved nodes given the evidence. Finally, the posterior probability values ​​of each candidate root cause node are collected, generating posterior probability information for each candidate root cause node. For example, if the input evidence is "abnormal voltage = true", the reasoning results in P(poor contact | evidence) = 0.92, P(load imbalance | evidence) = 0.18, and P(cable aging | evidence) = 0.05.

[0048] The fifth step involves sorting and comparing the posterior probability information of each candidate root cause node to determine the first and second root cause information. The activated directed edge paths can be paths formed by the edges traversed during probability propagation in posterior inference, such as poor contact -> increased resistance -> abnormal voltage. In practice, firstly, the posterior probability values ​​of each candidate root cause node are sorted from largest to smallest. Then, the first (maximum value) after sorting is taken as the first root cause information, and its node name and posterior probability value are recorded. Finally, the second (second largest value) after sorting is taken as the second root cause information, and its node name and posterior probability value are also recorded. For example, if the sorting results in [poor contact (0.92), load imbalance (0.18), cable aging (0.05)], then the first root cause information is "poor contact (92%)", and the second root cause information is "load imbalance (18%)".

[0049] The sixth step is to determine the directed edge paths activated during the posterior reasoning process as the fault propagation paths. In practice, firstly, the path of message propagation, i.e., the trajectory of probability updates flowing along directed edges, is recorded during the posterior reasoning process. Then, tracing backward from the fault node (observation node), the edges traversed by all nodes whose posterior probabilities are significantly higher than their prior probabilities are identified. Finally, these edges are extracted in connection order to form a complete sequence of directed edges from the root cause node to the fault node, which is determined as the fault propagation path. For example, tracing backward from "voltage anomaly," the nodes with significantly increased probabilities are found to be "voltage drop," "resistance increase," and "poor contact," respectively. Therefore, the fault propagation path is "poor contact -> increased resistance -> voltage drop -> voltage anomaly."

[0050] Step 106: Generate an operation and maintenance plan based on the first root cause information, the second root cause information, and the fault propagation path.

[0051] In some embodiments, the aforementioned execution entity can generate an operation and maintenance plan based on the aforementioned first root cause information, the aforementioned second root cause information, and the aforementioned fault propagation path. The operation and maintenance plan can be a structured set of operation instructions generated for the root cause, including the operation sequence, equipment, and parameters. For example, {Step 1: Remotely restart the PLC, Step 2: Replace the circuit breaker}.

[0052] In addressing the technical challenges of the aforementioned background technologies, and considering the application scenario—a large commercial complex or industrial production line experiencing multiple cascading alarms requiring root cause analysis and maintenance within minutes—the following technical issues often arise: traditional maintenance solutions only output a list of root causes, lacking an executable operational sequence and spatial scheduling, leading to operational conflicts, low repair efficiency, and long overall repair time. To meet the specific requirements of this application scenario—rapid response, spatial parallelism, temporal coordination, and conflict-preventing execution—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity may generate an operation and maintenance plan based on the aforementioned first root cause information, the aforementioned second root cause information, and the aforementioned fault propagation path, which may include the following steps: The first step, based on the aforementioned first root cause information, involves querying related historical maintenance records and standard handling measures from the electromechanical knowledge graph to generate a core root cause treatment plan. These related historical maintenance records can be past fault handling records similar to the current root cause. For example, the "replace circuit breaker" record corresponding to the previous "poor contact" issue. The aforementioned standard handling measures can be routine operations corresponding to predefined root causes in the knowledge graph. For example, the standard measure for "bearing wear" is "add lubricating oil or replace the bearing." The aforementioned core root cause treatment plan can be a set of direct repair operations for the first root cause. For example, {inspect circuit breaker contacts, replace burnt contacts}. In practice, firstly, the first root cause information (such as "poor circuit breaker contact") is obtained as the query keyword. Then, historical maintenance records (such as maintenance work orders for previous "poor contact" issues) and predefined standard handling measures (such as "replace contacts") associated with this root cause are retrieved from the electromechanical knowledge graph. Finally, the effective operations and standard measures from the retrieved similar cases are merged and deduplicated to generate the core root cause treatment plan. For example, querying "circuit breaker poor contact" yields historical records such as "replace the A-phase contact of the circuit breaker" and the standard measure "check the contact resistance". These are combined into a core root cause treatment plan: first check the contact resistance, and if it exceeds the tolerance, replace the contact.

[0053] The second step involves supplementing and optimizing the core root cause handling scheme based on the aforementioned second root cause information and the intermediate node states in the fault propagation path to generate a comprehensive handling scheme. The intermediate node states can be the current operating parameters of non-root cause, non-faulty nodes on the fault propagation path. For example, the current resistance value of the "increased resistance" node is 2.5Ω. The comprehensive handling scheme can be a complete set of operations combining the handling of the core root cause and secondary root causes. For example, {replacing the circuit breaker, adjusting load distribution}. In practice, first, the second root cause information (such as "load imbalance") and the intermediate node states in the fault propagation path (such as the current value of the "voltage drop" node) are read. Then, it is determined whether the secondary root cause needs independent handling (such as adjusting the load) or can be integrated into the core scheme (such as redistributing the load after replacing the circuit breaker). Finally, the handling measures for the secondary root cause are added to the core scheme to generate a comprehensive handling scheme that includes multi-factor processing. For example, the core solution is "replacing the contactor contacts", the secondary root cause is "load imbalance", the supplementary measure is "redistributing the three-phase load", and the comprehensive solution is "after replacing the contacts, measure the three-phase current and adjust the load".

[0054] The third step involves identifying the spatial location and dependencies of the equipment corresponding to each node based on the propagation order of the nodes in the fault propagation path, thereby generating maintenance task groups clustered by spatial proximity. The spatial location of the equipment can be its physical coordinates within the factory or building. For example, the distribution cabinet might be located next to column E03 on floor B1. The dependencies can be sequential constraints between operations, such as operation A must be completed before operation B. For example, a circuit breaker can only be replaced after a power outage. The maintenance task groups can be sets of tasks clustered by spatial proximity, allowing for centralized execution within the same group. For example, all maintenance tasks within the B1 distribution room can be grouped together. Spatial proximity clustering can be a method of grouping maintenance tasks of equipment with similar spatial coordinates into the same task group to minimize the distance personnel travel across areas. For example, multiple distribution cabinet maintenance tasks on the same floor can be clustered together. In practice, firstly, based on the node propagation order in the fault propagation path (e.g., "poor contact -> voltage drop -> compressor shutdown"), the spatial location of the equipment corresponding to each node (e.g., B1 distribution room, rooftop compressor room) is obtained. Then, the spatial distance between devices is calculated, and devices with a distance less than a threshold (e.g., 10 meters) are grouped into the same spatial cluster. Finally, maintenance tasks within the same cluster are divided into maintenance task groups, generating groups clustered by spatial proximity. For example, circuit breakers, cables, and distribution cabinets in the B1 power distribution room are grouped into one group, while compressors and motors in the rooftop compressor room are grouped into another group, and the two groups can operate in parallel.

[0055] The fourth step involves determining the execution time window and sequential dependency constraints for each maintenance task based on the aforementioned maintenance task groupings and fault propagation paths, thereby generating a timestamped maintenance task scheduling sequence. The aforementioned time delay characteristics can be the time difference between the root cause and downstream nodes of a fault propagation. For example, a voltage anomaly occurs 2 seconds after a poor connection, and the compressor stops 5 seconds later. The aforementioned execution time window can be the optimal execution time for a particular operation. For example, replacing a circuit breaker must be completed within 10 minutes of a power outage. The aforementioned sequential dependency constraints can be the temporal logic between operations, such as B only starting after A is completed. For example, power outage first, then voltage testing, then maintenance. The aforementioned maintenance task scheduling sequence can be a list of operation tasks arranged along a timeline, including start / end times. For example, T0-5min: power outage, T5-15min: replacement. First, obtain the time delay characteristics corresponding to each maintenance task group (e.g., compressor stops 2 seconds after a voltage anomaly). Then, determine the earliest start time of the task based on the delay characteristics (root cause handling has the highest priority) and set the time window (e.g., root cause handling must be completed before secondary faults worsen). Finally, a specific timestamp is assigned to each task (e.g., T0+0min to T0+5min), generating a timestamped operation and maintenance task scheduling sequence. For example, the root cause task "replace contact point" has a time window of T0~T5min, while the secondary task "check compressor" has a 2-second delay and can be scheduled in T5~T10min, with the two tasks running sequentially.

[0056] The fifth step involves parallelizing and merging the operations and maintenance (O&M) tasks based on the aforementioned O&M task scheduling sequence, and performing conflict detection on the O&M operations corresponding to each node to generate a step-by-step O&M operation sequence. Parallelizing and merging can involve combining conflict-free, simultaneously executable operations into parallel task groups. For example, two groups of personnel simultaneously inspecting electrical distribution boxes on different floors. Conflict detection can identify resource, spatial, or temporal conflicts between operations. For example, the same power cabinet cannot be repaired by two people simultaneously. The O&M operation sequence can be a conflict-free sequence after conflict detection and adjustment. For example, staggering the operation times in the same space. First, the O&M task scheduling sequence is scanned to identify task pairs whose time windows do not overlap and whose resources (tools, personnel, space) do not conflict. Then, these task pairs are merged into parallel task groups, and it is checked whether new conflicts arise after merging (such as simultaneous operations in the same space). Finally, the order or resource allocation of conflicting tasks is adjusted to generate a step-by-step O&M operation sequence.

[0057] The sixth step involves associating and encapsulating the aforementioned maintenance operation sequence with corresponding equipment identifiers and operation parameters to generate a structured maintenance solution. The equipment identifier can be a unique identifier for the equipment, such as an asset number or barcode. For example, "PD-03" represents distribution cabinet number 3. The operation parameters can be specific values ​​or instructions required to execute the operation. For example, the restart instruction "REBOOT" with a target speed of "1500 rpm". First, each operation in the maintenance operation sequence is bound to its corresponding equipment identifier (e.g., "PD-03") and operation parameters (e.g., "torque value 15 N·m"). Then, the operation sequence, equipment identifier, operation parameters, and timestamp are packaged into JSON or XML format. Finally, solution metadata (e.g., generation time, fault ID, root cause probability) is added to generate a structured maintenance solution that can be directly parsed and executed by downstream systems (e.g., work order system, PLC).

[0058] The above-described operation steps, combined with step 107, constitute an inventive point of this disclosure, solving the technical problem mentioned in the background art: "Traditional operation and maintenance solutions only output a root cause list, lacking an executable operation sequence and spatial scheduling, leading to operation and maintenance conflict, low maintenance efficiency, and long total repair time." The reasons for these technical problems are as follows: existing solutions do not utilize the spatial location relationships and time delay characteristics in the fault propagation path for operation and maintenance task orchestration, nor do they perform conflict detection and resource scheduling for parallel operations. This invention, through spatial clustering and grouping based on the fault propagation path, time window scheduling, parallel merging, and conflict detection, generates a structured operation and maintenance solution containing device identifiers, operation parameters, timestamps, and anti-conflict constraints, saving average fault repair time, reducing on-site personnel travel and waiting time, and lowering operation and maintenance costs.

[0059] Step 107: In response to receiving the operation and maintenance instructions corresponding to the above operation and maintenance plan, execute the corresponding operation and maintenance operations.

[0060] In some embodiments, the aforementioned execution entity may, in response to receiving the operation and maintenance instructions corresponding to the aforementioned operation and maintenance scheme, execute the corresponding operation and maintenance operations. The aforementioned corresponding operation and maintenance instructions may be a start command that triggers the execution of the structured operation and maintenance scheme. For example, a JSON instruction generated by clicking the "Start Execution" button. The aforementioned operation and maintenance operations may be specific actions defined in the operation and maintenance scheme, such as remote restart or on-site component replacement. For example, "Replace circuit breaker contacts."

[0061] In addressing the technical challenges of the aforementioned background technologies, and considering the application scenario—large data centers or hospitals operating 24 / 7 electromechanical systems—maintenance operations must be completed within a very short timeframe without impacting business continuity. This often involves automated equipment (such as smart valves and remote circuit breakers), which frequently presents the following technical issues: After the maintenance plan is generated, the execution level lacks the ability to coordinate and schedule automated equipment and manual operations simultaneously. It cannot dynamically allocate execution resources based on task dependencies, leading to automated equipment idling or conflicts between manual and automated instructions, resulting in low execution efficiency and a high risk of omissions or duplicate executions, wasting valuable time. To meet the following requirements for this application scenario: remote priority, human-machine collaboration, dependency-driven, dynamic adaptation, and full traceability, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity may, in response to receiving the operation and maintenance instructions corresponding to the operation and maintenance scheme, execute the corresponding operation and maintenance operations, which may include the following steps: The first step, in response to the received maintenance instructions corresponding to the aforementioned maintenance plan, is to perform dependency resolution and resource requirement analysis on each operation in the maintenance plan to generate a maintenance task dependency graph with resource constraints. Each operation can be an atomic task in the maintenance plan. For example, {"seq": 1, "action": "power off"}. Dependency resolution involves analyzing the sequential constraints between operations to determine which operations depend on other operations. For example, "power testing" depends on "power off". Resource requirement analysis involves identifying the equipment, tools, personnel, and other resources required for each operation. For example, a "torque wrench" and an "electrician" are needed. The maintenance task dependency graph can be a directed graph containing operation nodes, dependency edges, and resource labels. For example, the node "replace contact" requires the resource "wrench", and the edge is "power off -> power testing". In practice, first, a topological sort is performed on the maintenance task dependency graph, and the in-degree (number of prerequisite tasks) of each node is calculated. Then, nodes with an in-degree of 0 are marked as root tasks with no prerequisites and added to the first-level execution queue; nodes with an out-degree of 0 are marked as leaf tasks with dependencies. Finally, layer numbers are assigned sequentially according to the topology hierarchy to generate hierarchical task execution queues from root to leaf. For example, the parsed solution yields "power off -> power testing -> contact replacement". Power testing requires an "electrical detector", and contact replacement requires a "wrench". The graph is constructed as follows: node A performs power off, node B performs power testing, and node C replaces the contact; edge A->B->C; B provides an electrical detector, and C provides a wrench.

[0062] The second step, based on the aforementioned operation and maintenance task dependency graph, identifies root tasks without prerequisite dependencies and leaf tasks with dependencies to generate a hierarchical task execution queue. The root tasks without prerequisite dependencies can be operations that have no predecessor tasks and can be executed immediately. For example, "power outage" has no prerequisite operations. The leaf tasks with dependencies can be terminal operations with predecessor tasks but no successor tasks. For example, "test run" is a terminal operation. The hierarchical task execution queue can be a list of tasks organized according to the topology hierarchy, with tasks at the same level allowed to run in parallel. In practice, first, the operation and maintenance task dependency graph is topologically sorted, and the in-degree (number of predecessor tasks) of each node is calculated. Then, nodes with an in-degree of 0 are marked as root tasks without prerequisite dependencies and added to the first-level execution queue; nodes with an out-degree of 0 are marked as leaf tasks with dependencies. Finally, layer numbers are assigned sequentially according to the topology hierarchy to generate a hierarchical task execution queue from root to leaf. For example, power failure with an in-degree of 0 is the root task, belonging to level 1; power testing with an in-degree of 1 (dependent on power failure) belongs to level 2; contact replacement with an in-degree of 1 belongs to level 3; and test operation with an in-degree of 1 and an out-degree of 0 is a leaf task, belonging to level 4.

[0063] The third step is to generate a parallel task allocation scheme based on the hierarchical task execution queues described above. This scheme can be a plan to assign conflict-free tasks at the same level to different execution units. For example, assigning group A to perform electrical testing and group B to hang tags. In practice, first, all task nodes within the same level are obtained, and resource conflicts (such as needing the same wrench) or spatial conflicts (such as working at the same station) are checked. Then, conflict-free tasks are paired and simulated for allocation to different execution units (such as a remote PLC, group A, and group B). Finally, a parallel task allocation scheme is generated, specifying who will execute each task and when it will start. For example, in the second level, there are "electrical testing" and "tag hanging," which require different tools and are spatially independent. "Electrical testing" is assigned to electrician A, and "tag hanging" is assigned to electrician B, executed simultaneously, generating a parallel allocation scheme.

[0064] The fourth step, based on the above parallel task allocation scheme, involves issuing the first wave of operation instructions to the automated equipment and pushing the second wave of operation notifications to the maintenance terminal to generate a dual-channel, phased execution plan. The automated equipment can be a remotely controllable PLC, robot, smart switch, etc., such as a remotely controllable circuit breaker. The first wave of operation instructions can be immediate instructions issued to the automated equipment, such as a "PLC restart instruction." The maintenance terminal can be a handheld PDA, mobile phone, or tablet used by maintenance personnel, such as a dedicated tablet computer for maintenance workers. The second wave of operation notifications can be manual task prompts pushed to the maintenance terminal, such as "Please replace the circuit breaker contacts in the B1 power distribution room." The dual-channel, phased execution plan can be a timing scheme that simultaneously schedules automated and manual tasks. For example, T0 automatically cuts off power, and T1 notifies manual power testing. First, tasks that can be executed by the automated equipment (such as remote power cut-off and remote restart) are selected from the parallel task allocation scheme, generating the first wave of operation instructions, which are then issued via an industrial protocol. Then, tasks requiring manual on-site execution (such as replacing parts and cleaning filters) are selected, and a second wave of operation notifications is generated and pushed to the maintenance personnel's terminal. Finally, the timelines of the two waves of operations are aligned to generate a dual-channel, wave-by-wave execution plan. For example, in the first wave: at T0, a "remotely disconnect QF101 circuit breaker" command is issued to the PLC; in the second wave: after T1 seconds, a "verify and tag" notification is pushed to the maintenance worker's PDA, and after T5 seconds, a "replace contact" notification is pushed.

[0065] The fifth step involves responding to the detection of operation completion in either execution channel of the dual-channel system by updating the completion status of the corresponding node in the aforementioned maintenance task dependency graph in real time, and releasing the resource locks of the corresponding subsequent tasks to generate a dynamic task dependency unlocking sequence. The completion status can be the execution result of a task node (success / failure / in progress). For example, the status of "node power failure" is "success". The corresponding subsequent task can be a task that depends on the completion of the current task. For example, "power testing" is a subsequent task of "power failure". The resource lock can be a temporary occupation of resources after allocating them for a task to prevent conflicts. For example, locking the "torque wrench" to group A. The dynamic task dependency unlocking sequence can be a list of sequences for releasing subsequent task resources based on the real-time completion status. For example, "power failure completed -> unlocking power testing". The task can be an atomic operation unit defined in the maintenance plan. For example, "replacing circuit breaker contacts". In practice, firstly, the task completion signals returned by both channels (automated equipment and manual terminals) are monitored in real time. Then, when a node's status changes to "complete," the node is marked in the task dependency graph, and all its successor nodes are traversed to check if all prerequisites for each successor node have been completed. Finally, if all prerequisites for each successor node have been completed, the resource lock on that successor node is released, it is added to the ready queue, and a dynamic task dependency unlocking sequence is generated.

[0066] Step 6: Based on the aforementioned dynamic task-dependent unlocking sequence, generate an adaptive iterative execution flow. The "adaptive" aspect can mean dynamically adjusting the execution plan based on real-time feedback without manual intervention. For example, if a task completes ahead of schedule, subsequent tasks are automatically triggered. The execution flow can be a complete dynamic execution path from task start to finish. For example, power outage -> power testing -> contact replacement -> test run. The adaptive iterative execution flow can also be a complete dynamic execution path that progresses dynamically based on task completion status. For example, completing one batch, unlocking another, and then executing yet another. In practice, first, newly unlocked tasks are taken from the dynamic task-dependent unlocking sequence, and the parallel grouping in step 3 and the instruction issuance process in step 4 are repeated. Then, the process of "waiting for completion -> unlocking the successor -> issuing a new task" is executed cyclically until all task nodes are marked as completed. Finally, the start and end times of each iteration are recorded to generate the adaptive iterative execution flow.

[0067] Step 7: Based on the execution logs and completion timestamps of each operation in the adaptive iterative execution flow described above, generate an execution review report. The execution logs can record detailed information about each operation's execution process, including start / end time, result, and execution unit. The timestamps can be the specific time points when task execution events occurred, used for time-series analysis and bottleneck identification. The execution review report can be a summary document summarizing the execution logs, critical paths, and resource bottlenecks, used for optimization. For example, {"Total Time": "20min", "Bottleneck": "Wrench", "Recommendation": "Add a spare wrench"}. In practice, first, collect the execution logs (start time, completion time, execution unit, result status) and completion timestamps for each operation in the adaptive iterative execution flow. Then, identify the critical path (the longest-running path) and the utilization rate of each resource (idle / busy ratio). Finally, generate an execution review report containing critical path analysis, resource bottleneck suggestions, and anomaly records, and store it in a knowledge graph for subsequent optimization.

[0068] The above-described operational steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background art: "After the operation and maintenance plan is generated, there is a lack of dual-channel collaborative scheduling capability for automated equipment and manual operation at the execution level. Execution resources cannot be dynamically allocated according to task dependencies, leading to automated equipment idling or conflicts between manual operation and automated instructions, resulting in low execution efficiency and frequent omissions or duplicate executions, wasting valuable time." The reasons for this technical problem are as follows: Traditional operation and maintenance execution methods either rely entirely on manual operation item by item or only support simple automated instruction issuance, lacking a dual-channel collaborative scheduling mechanism for automated equipment and manual operation. They cannot dynamically allocate execution resources according to task dependencies and resource constraints, resulting in low execution efficiency, resource idleness, and conflicts. This invention constructs an operation and maintenance task dependency graph with resource constraints, generates hierarchical task execution queues and parallel task allocation schemes, and establishes a dual-channel, wave-based execution plan and a dynamic task dependency unlocking mechanism, forming an adaptive iterative execution flow. This achieves automated collaborative scheduling and real-time adaptive adjustment of the operation and maintenance execution process, saving execution waiting time, resource idleness waste, and rework costs caused by operational conflicts.

[0069] In some optional implementations of certain embodiments, the aforementioned execution entity may further perform the following steps: The first step is to update the electromechanical domain knowledge graph based on the knowledge information of the corresponding maintenance cases for the aforementioned fault alarm information, thereby generating an updated electromechanical domain knowledge graph. The aforementioned maintenance cases can refer to a complete record of the fault from alarm to repair completion, including the fault phenomenon, root cause, propagation path, and maintenance measures. For example, {Fault: “Abnormal Voltage”, Root Cause: “Poor Contact”, Measures: “Replace Contact”}. The aforementioned knowledge information can be structured knowledge extracted from the maintenance cases, including entities (fault, root cause) and relationships (cause, repair). The updated electromechanical domain knowledge graph can be a new version of the graph obtained by integrating the knowledge from the new cases, adding nodes, edges, or updating probability weights. For example, if the original graph did not have “Poor Contact -> Abnormal Voltage”, this edge is added after the update. First, extract the fault phenomenon entity (e.g., “Abnormal Voltage”), root cause entity (e.g., “Poor Contact”), maintenance measure entity (e.g., “Replace Contact”), and fault propagation path (e.g., “Poor Contact -> Voltage Drop -> Abnormal Voltage”) from the aforementioned maintenance cases. Then, the extracted entities are linked with nodes in the existing knowledge graph. If a node already exists, the probability weights of its associated edges are updated (e.g., the count of the "cause" relationship is increased); if a node does not exist, a new node is created. Finally, relational reasoning is performed to complete the new knowledge (e.g., "A->C" is inferred from the newly added "A->B" and the existing "B->C"), and an expert review process is triggered to confirm the newly added fault modes. After the review is approved, the knowledge is officially written into the graph, generating the updated electromechanical domain knowledge graph.

[0070] The above-described embodiments of this disclosure have the following beneficial effects: Through the knowledge graph-based electromechanical system operation and maintenance method of some embodiments of this disclosure, the root cause of electromechanical system failures can be accurately located, and operation and maintenance plans can be automatically generated and executed, saving troubleshooting time and operation and maintenance costs. Specifically, the reasons for the low efficiency and high cost of traditional electromechanical system failure troubleshooting are: existing technologies heavily rely on expert experience to build static failure models, which are difficult to adapt to the dynamic changes and multi-fault coupling and propagation characteristics of electromechanical systems. At the same time, data-driven methods lack physical interpretability and rely on a large number of labeled samples, resulting in insufficient root cause location accuracy, long inference time, and high misjudgment rate, thus causing low troubleshooting efficiency and high operation and maintenance costs. Based on this, the knowledge graph-based electromechanical system operation and maintenance method of some embodiments of this disclosure firstly, in response to receiving fault alarm information, generates original time-series data and text record data based on the collected multi-source heterogeneous operating data of the electromechanical system. By collecting multi-source heterogeneous operational data and generating raw time-series data and text records, unified digitization of real-time sensor data and historical text knowledge is achieved, laying a data foundation for subsequent multimodal fusion analysis and avoiding the information gaps caused by a single data source. Then, multi-dimensional time-series feature extraction is performed on the raw time-series data, and natural language processing is applied to the text records to obtain causal relationship path features and time delay features. Through time-series feature extraction and text natural language processing, the raw data is transformed into causal relationship path features and time delay features, revealing the structured relationships and temporal patterns of fault propagation, providing quantifiable causal clues for subsequent reasoning. Next, based on a pre-defined electromechanical knowledge graph, the knowledge graph is pruned starting from the fault node corresponding to the current fault, resulting in a fault candidate root factor graph. This knowledge graph pruning process, starting from the fault node, eliminates irrelevant entities and paths, narrowing the reasoning scope to the candidate root factor graph, significantly reducing the complexity of subsequent calculations and improving the real-time performance of fault location. Next, the aforementioned multi-dimensional temporal features, time delay features, and fault candidate root factor graphs are fused to generate a directed acyclic causal topology. By fusing temporal features, time delay features, and fault candidate root factor graphs, a directed acyclic causal topology is generated, achieving a deep integration of data-driven and knowledge-driven approaches, eliminating spurious correlations, and constructing an accurate causal propagation framework. Secondly, based on the aforementioned directed acyclic causal topology, a Bayesian network is used to determine the first root cause information, the second root cause information, and the fault propagation path. Based on the directed acyclic causal topology and the Bayesian network, the posterior probability of each candidate root cause is quantified, accurately distinguishing between core and secondary root causes, and outputting a clear fault propagation path, improving the interpretability and credibility of the diagnostic results. Thirdly, based on the aforementioned first root cause information, second root cause information, and fault propagation path, an operation and maintenance plan is generated.Based on root cause information and propagation paths, an operation and maintenance (O&M) plan is generated, automating the transition from diagnosis to decision-making. This provides O&M personnel with targeted and actionable operational guidance, shortening decision-making time. Finally, in response to receiving O&M instructions corresponding to the aforementioned O&M plan, the corresponding O&M operations are executed. By receiving O&M instructions and executing corresponding operations, a complete closed-loop automation from diagnosis to repair is achieved, reducing manual intervention, lowering the risk of operational errors, and accelerating the recovery of electromechanical systems.

[0071] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a knowledge graph-based electromechanical system operation and maintenance device. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, this knowledge graph-based electromechanical system maintenance device can be specifically applied to various electronic devices.

[0072] like Figure 2 As shown, a knowledge graph-based electromechanical system operation and maintenance device 200 includes: a first generation unit 201, a first processing unit 202, a second processing unit 203, a fusion unit 204, a determination unit 205, a second generation unit 206, and an execution unit 207. The first generation unit 201 is configured to: in response to receiving fault alarm information, generate raw time-series data and text record data based on collected multi-source heterogeneous operating data of the electromechanical system. The first processing unit 202 is configured to: extract multi-dimensional time-series features from the raw time-series data and perform natural language processing on the text record data to obtain causal relationship path features and time delay features. The second processing unit 203 is configured to: based on a preset electromechanical knowledge graph, prune the electromechanical knowledge graph starting from the fault node corresponding to the current fault to obtain a fault candidate root factor graph. The fusion unit 204 is configured to: fuse the multi-dimensional time-series features, the time delay features, and the fault candidate root factor graph to generate a directed acyclic causal topology. The determining unit 205 is configured to: determine the first root cause information, the second root cause information, and the fault propagation path based on the aforementioned directed acyclic causal topology and using a Bayesian network. The second generating unit 206 is configured to: generate an operation and maintenance plan based on the aforementioned first root cause information, the aforementioned second root cause information, and the aforementioned fault propagation path. The executing unit 207 is configured to: execute the corresponding operation and maintenance operation in response to receiving the operation and maintenance instruction corresponding to the aforementioned operation and maintenance plan.

[0073] It is understandable that the units recorded in the knowledge graph-based electromechanical system operation and maintenance device 200 are related to the reference... Figure 1The steps in the described method correspond accordingly. Therefore, the operations, features, and beneficial effects described above for the method are also applicable to the knowledge graph-based electromechanical system operation and maintenance device 200 and the units contained therein, and will not be repeated here.

[0074] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device (e.g., an electronic device) 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0075] like Figure 3 As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0076] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0077] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0078] It should be noted that, in some embodiments of this disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0079] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0080] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs. When the electronic device executes one or more of these programs, the electronic device causes the following actions: In response to receiving a fault alarm information, it generates raw time-series data and text record data based on collected multi-source heterogeneous operating data of the electromechanical system; it performs multi-dimensional time-series feature extraction on the raw time-series data and natural language processing on the text record data to obtain causal path features and time delay features; based on a preset electromechanical knowledge graph, it performs pruning on the electromechanical knowledge graph, starting from the fault node corresponding to the current fault, to obtain a fault candidate root factor graph; it fuses the multi-dimensional time-series features, the time delay features, and the fault candidate root factor graph to generate a directed acyclic causal topology; based on the directed acyclic causal topology, it uses a Bayesian network to determine the first root cause information, the second root cause information, and the fault propagation path; based on the first root cause information, the second root cause information, and the fault propagation path, it generates an operation and maintenance plan; and in response to receiving the operation and maintenance instructions corresponding to the operation and maintenance plan, it executes the corresponding operation and maintenance operations.

[0081] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0082] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more operable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0083] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor can be described as including a first generation unit, a first processing unit, a second processing unit, a fusion unit, a determination unit, a second generation unit, and an execution unit. The names of these units do not necessarily limit the specific unit itself; for example, the first generation unit can also be described as "a unit that, in response to receiving a fault alarm message, generates raw time-series data and text record data based on collected multi-source heterogeneous operating data of the electromechanical system."

[0084] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0085] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A knowledge graph-based operation and maintenance method for electromechanical systems, characterized in that, include: In response to receiving fault alarm information, based on the collected multi-source heterogeneous operating data of the electromechanical system, raw time-series data and text record data are generated; Multidimensional time-series feature extraction is performed on the original time-series data, and natural language processing is performed on the text record data to obtain causal relationship path features and time delay features; Based on a preset electromechanical knowledge graph, the electromechanical knowledge graph is pruned starting from the fault node corresponding to the current fault to obtain a fault candidate root factor graph. The multidimensional temporal features, the time delay features, and the fault candidate root factor graph are fused to generate a directed acyclic causal topology. Based on the aforementioned directed acyclic causal topology, Bayesian networks are used to determine the first root cause information, the second root cause information, and the fault propagation path. Based on the first root cause information, the second root cause information, and the fault propagation path, an operation and maintenance plan is generated. Upon receiving the operation and maintenance instructions corresponding to the operation and maintenance plan, the corresponding operation and maintenance operation is executed.

2. The method according to claim 1, characterized in that, The method further includes: The electromechanical knowledge graph is updated based on the knowledge information of the operation and maintenance cases corresponding to the fault alarm information to generate an updated electromechanical knowledge graph.

3. The method according to claim 1, characterized in that, In response to receiving a fault alarm message, based on the collected multi-source heterogeneous operating data of the electromechanical system, raw time-series data and text record data are generated, including: In response to receiving a fault alarm message, multi-source heterogeneous raw data is generated by collecting runtime sequence data of the target sensor and synchronizing multiple text records through an interface. The multiple text records include at least: equipment ledger, maintenance records and technical handover documents. Interpolation and wavelet denoising are performed on the time-series data in the multi-source heterogeneous original data to obtain standardized time-series data. Entity recognition is performed on the text data in the multi-source heterogeneous raw data to extract fault phenomenon entities, root cause entities, and maintenance measure entities, generating structured text record data.

4. The method according to claim 1, characterized in that, The step of extracting multidimensional time-series features from the original time-series data and performing natural language processing on the text record data to obtain causal relationship path features and time delay features includes: The original time-series data is subjected to feature extraction processing to generate multi-dimensional time-series features, which include: time-domain features, frequency-domain features, and time-frequency features. Based on the structured text record data, entity linking and relational reasoning are performed to generate causal path features of the fault. The multidimensional time-series features are processed by fault propagation delay calculation to generate fault propagation time delay features.

5. The method according to claim 1, characterized in that, The pre-set electromechanical knowledge graph, starting from the fault node corresponding to the current fault, is pruned to obtain a fault candidate root factor graph, including: Starting from the fault node corresponding to the current fault, trace upstream in the preset electromechanical knowledge graph to find entity nodes that have a causal relationship with the fault node, so as to generate an initial set of candidate root causes. Each entity node in the initial candidate root cause set is classified by device type to remove cross-system interference nodes that are unrelated to the subsystem to which the current fault phenomenon belongs, so as to generate a filtered candidate root cause set. Path connectivity is checked for each entity node in the filtered candidate root cause set to generate a path-connected candidate root cause set. Redundant paths in the candidate root cause set after the paths are connected are merged to generate a simplified set of causal propagation paths. Based on the simplified causal propagation path set, a fault candidate root factor graph is generated.

6. The method according to claim 1, characterized in that, The step of fusing the multidimensional temporal features, the time delay features, and the fault candidate root factor graph to generate a directed acyclic causal topology includes: Using the candidate root factor nodes in the fault candidate root factor graph as variable nodes and the feature components in the multidimensional time series features as variable attributes, an initial variable set is constructed. Based on the initial set of variables, conditional independence is tested for each pair of variable nodes in the causal association path features to generate an undirected causal skeleton graph. Based on the time delay feature, the causal direction of each edge in the generated undirected causal skeleton graph is marked to generate a directed causal graph with directional labels. Based on the prior causal constraints in the fault candidate root factor graph, loop detection and direction correction are performed on the directed causal graph to generate an acyclic directed acyclic causal topology.

7. The method according to claim 1, characterized in that, The determination of the first root cause information, the second root cause information, and the fault propagation path based on the directed acyclic causal topology and using a Bayesian network includes: The directed acyclic causal topology is used as the fixed skeleton of the Bayesian network to determine the conditional dependencies between nodes in the Bayesian network. Based on the multidimensional time series features and the causal association path features, the causal strength of the directed edges from each candidate root cause node to the fault node is quantified to generate the average causal effect value information of each directed edge. Based on the conditional dependencies, the average causal effect value of each directed edge is used as the prior parameter of the conditional probability table of the Bayesian network to generate the initial Bayesian network. Based on the current fault phenomenon and the initialized Bayesian network, a posterior inference process is performed to generate posterior probability information for each candidate root cause node. The candidate root cause nodes are sorted and compared based on their posterior probability information to determine the first root cause information and the second root cause information. The directed edge paths activated during the posterior reasoning process are identified as fault propagation paths.

8. A knowledge graph-based electromechanical system operation and maintenance device, characterized in that, include: The first generation unit is configured to generate raw time-series data and text record data in response to receiving fault alarm information, based on the collected multi-source heterogeneous operating data of the electromechanical system. The first processing unit is configured to extract multi-dimensional time-series features from the original time-series data and to perform natural language processing on the text record data to obtain causal relationship path features and time delay features. The second processing unit is configured to perform pruning on the electromechanical knowledge graph based on a preset electromechanical knowledge graph, starting from the fault node corresponding to the current fault, to obtain a fault candidate root factor graph. The fusion unit is configured to fuse the multidimensional temporal features, the time delay features, and the fault candidate root factor graph to generate a directed acyclic causal topology. The determining unit is configured to determine the first root cause information, the second root cause information, and the fault propagation path based on the directed acyclic causal topology using a Bayesian network. The second generation unit is configured to generate an operation and maintenance plan based on the first root cause information, the second root cause information, and the fault propagation path. The execution unit is configured to execute the corresponding operation and maintenance operation in response to receiving the operation and maintenance instruction corresponding to the operation and maintenance plan.

9. An electronic device, characterized in that, include: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

Images