Knowledge graph-based photothermal equipment anomaly diagnosis and processing decision method and system

Abstract

The application discloses a kind of based on knowledge graph's photothermal equipment exception diagnosis and processing decision method and system, belong to industrial intelligent operation and maintenance technical field.The method first constructs the knowledge graph mode layer containing equipment component, operating parameter, fault mode and four big ontology of fault reason, and the transitivity constraint is configured for fault propagation relationship by OWL language, and unified semantic framework is formed.Secondly, using BIO marking method and multi-scale convolution kernel process multi-source heterogeneous data, automatically build or update data layer instance.Subsequently, by double-factor production rule, identify abnormal and demarcate suspicious range, combine FAQ, knowledge graph and three-level fusion of reading comprehension question and answer engine, along fault propagation path reverse traversal to locate root cause of failure.Finally, generate the decision including maintenance suggestion and carry out visual display.The application solves the problem that photothermal system fault cause-effect relationship is difficult to trace back, significantly improves the accuracy and explainability of exception diagnosis.

Description

Technical Field

[0001] This invention relates to the field of industrial intelligent operation and maintenance and artificial intelligence, specifically to a method and system for abnormal diagnosis and handling decision-making of photothermal equipment based on knowledge graph. Background Technology

[0002] With the rapid development of concentrated solar power (CSP) technology, CSP plants are evolving towards large-scale, high-parameter operations, leading to increasingly complex equipment systems and higher requirements for operational stability. CSP plants involve multiple subsystems, including heliostats, receivers, heat storage and exchange systems, and turbine generator sets. These systems are highly coupled, and fault propagation paths are often concealed. Once a critical component malfunctions, it can easily spread rapidly throughout the entire system via thermal or fluid connections, resulting in significant economic losses.

[0003] Currently, anomaly diagnosis for solar thermal equipment mainly relies on traditional threshold alarms and expert experience. Existing technologies typically monitor the numerical range of a single parameter using sensors, triggering an alarm when the parameter exceeds a preset threshold. However, this approach has significant drawbacks: First, a single threshold is insufficient to distinguish between normal parameter fluctuations and actual faults, resulting in a high false alarm rate; second, alarm information often exists in isolation, lacking semantic correlation and failing to reveal the causal link between "abnormal phenomena" and "root cause of faults," making it difficult for maintenance personnel to quickly locate the source of the fault; third, the operational logs and alarm texts generated by solar thermal systems are mostly unstructured data, making it difficult for traditional methods to effectively extract deep fault characteristics.

[0004] Furthermore, most existing fault diagnosis systems lack the ability to formally model fault propagation paths. This is fundamentally because traditional fault tree models can only express "AND" and "OR" logical relationships, failing to utilize the topological connections between devices for directional reverse reasoning, and lacking automatic derivation capabilities under attribute transitivity constraints. When faced with multi-cascade faults, existing technologies often only scratch the surface of the anomaly, failing to achieve automated and intelligent tracing from anomaly identification to the root cause. Therefore, there is an urgent need for a method for anomaly diagnosis and handling decisions in solar thermal equipment that can integrate multi-source heterogeneous data, possess formal fault propagation modeling capabilities (especially reverse reasoning capabilities under transitivity constraints), and offer strong interpretability. Summary of the Invention

[0005] This invention aims to solve the technical problems of difficulty in tracing fault propagation paths, difficulty in integrating multi-source data, and low root cause localization accuracy in the diagnosis of anomalies in photothermal equipment, and provides an anomaly diagnosis and processing decision-making method and system based on knowledge graphs.

[0006] In a first aspect, embodiments of this application provide a method for diagnosing and handling anomalies in photothermal equipment based on knowledge graphs, the method comprising:

[0007] A schema layer of a knowledge graph for anomaly diagnosis of photothermal equipment is constructed, defining four main entities: equipment components, operating parameters, fault modes, and fault causes. Transitive constraints are configured for fault propagation relationships using the OWL language to form a unified semantic framework.

[0008] The system periodically collects operational data from the photothermal equipment, uses BIO tagging for named entity recognition, employs multi-scale convolutional kernels for text classification, and automatically constructs or updates data layer instances of the knowledge graph according to the four main ontology types.

[0009] Using the data layer instance, the changes and deviation rates of key parameters are statistically analyzed, and anomaly identification is achieved by comparing production rules with preset thresholds, generating anomaly identifiers and a range of suspicious devices;

[0010] Starting from the anomaly identifier and taking the range of suspicious devices as the boundary, a question-and-answer mechanism integrating the FAQ engine, graph engine and reading comprehension engine is used, combined with the transitivity constraint to traverse backward along the fault propagation path to locate the root cause of the fault.

[0011] Based on the anomaly identification results and the root cause of the fault, a fault handling decision is generated, which includes the fault source identifier, fault type and maintenance suggestions, and the equipment topology and fault propagation path are displayed through a visual interface.

[0012] In a second aspect, embodiments of this application provide a knowledge graph-based solar thermal equipment anomaly diagnosis and handling decision system, applied to the knowledge graph-based solar thermal equipment anomaly diagnosis and handling decision method described in the first aspect, the system comprising:

[0013] The semantic framework construction module is used to build the schema layer of the knowledge graph for anomaly diagnosis of photothermal equipment. It defines four main ontology: equipment components, operating parameters, fault modes, and fault causes. It also uses the OWL language to configure transitivity constraints for fault propagation relationships, forming a unified semantic framework.

[0014] The data layer update module is used to periodically collect the operating data of the photothermal equipment, use the BIO tagging method for named entity recognition, use multi-scale convolution kernels for text classification, and automatically construct or update the data layer instance of the knowledge graph according to the four main ontology.

[0015] The anomaly detection module is used to use the data layer instance to statistically analyze the changes and deviation rates of key parameters, and to achieve anomaly detection by comparing production rules with preset thresholds, thereby generating anomaly identifiers and a range of suspicious devices.

[0016] The root cause reasoning module is used to locate the root cause of the fault by taking the anomaly identifier as the starting point and the range of the suspicious devices as the boundary, and using a question-and-answer mechanism that integrates the FAQ engine, graph engine and reading comprehension engine, combined with the transitivity constraints to traverse backward along the fault propagation path.

[0017] The decision display module is used to generate fault handling decisions based on anomaly identification results and root cause of fault, including fault source identification, fault type and maintenance suggestions, and to display the equipment topology and fault propagation path through a visual interface.

[0018] Thirdly, embodiments of this application provide an electronic device, including:

[0019] processor;

[0020] Memory used to store processor-executable instructions;

[0021] The processor is configured to implement the knowledge graph-based photothermal equipment anomaly diagnosis and handling decision-making method as described in the first aspect when executing the instructions.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing a program that instructs a device to execute the knowledge graph-based photothermal equipment anomaly diagnosis and processing decision-making method as described in the first aspect.

[0023] Beneficial Effects: By configuring transitive constraints for fault propagation relationships, the physical topology is transformed into a computable reverse inference chain, solving the problem of the difficulty in formally expressing the causal relationships of faults in photothermal systems. Combining BIO tagging with multi-scale convolutional kernels to process unstructured logs achieves high-precision mapping of text data to structured graph instances, improving the accuracy of data layer updates. Employing a two-factor trigger condition (change rate + deviation rate) instead of a single threshold effectively distinguishes between instantaneous fluctuations and real faults, reducing false alarm rates and accurately defining the scope of anomaly impact. A pioneering three-level progressive question-answering engine—FAQ-knowledge graph-reading comprehension—combining graph traversal and parameter comparison, achieves automated and highly reliable localization from abnormal phenomena to the root cause of faults. A visual interface synchronously displays the topology, parameter curves, and inference paths, providing an intuitive explanatory chain of evidence, significantly enhancing the credibility of diagnostic results and the value of operational guidance. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of a knowledge graph-based photothermal equipment anomaly diagnosis and handling decision-making method provided in an embodiment of this application.

[0025] Figure 2 This is an architecture diagram of a knowledge graph-based photothermal equipment anomaly diagnosis and processing decision system provided in an embodiment of this application.

[0026] Figure 3 A schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0028] It should be noted that in the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the specification of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.

[0029] Based on the embodiments described in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] Example 1

[0031] Figure 1 This is a schematic flowchart illustrating a knowledge graph-based method for diagnosing and handling anomalies in a photothermal device, as provided in one embodiment of this application. Figure 1 As shown, a knowledge graph-based method for diagnosing and handling anomalies in photothermal equipment includes:

[0032] S1. Construct the schema layer of the knowledge graph for anomaly diagnosis of photothermal equipment, defining four main ontology components: equipment components, operating parameters, fault modes, and fault causes. Then, using the OWL language, configure transitivity constraints for fault propagation relationships to form a unified semantic framework. This step establishes the "syntactic rules" of the knowledge graph by defining the four core ontology components: equipment, parameters, faults, and causes. In particular, by assigning transitivity constraints to fault propagation relationships using the OWL language, the system can transform physical connections into computable logical reasoning chains, providing a formal semantic foundation for subsequent reverse tracing from apparent anomalies to root cause faults.

[0033] During implementation, the system first defines a top-level ontology architecture. For example, it defines an "equipment component ontology" to describe physical entities such as heliostats, receivers, or circulating pumps; an "operating parameter ontology" to cover monitoring indicators such as temperature, pressure, and flow rate; an "failure mode ontology" to record manifestations such as "overheating" or "blockage"; and an "failure cause ontology" to correspond to root causes such as "sensor drift" or "pipeline fouling." The hierarchical relationships between these classes are defined using OWL (Web Ontology Language), establishing that "receiver" is a subclass of "equipment component," thereby creating a standardized semantic dictionary.

[0034] Specifically, the system defines an object property called "faultPropagatesTo". In OWL, this property is declared as having the logical characteristic of "transitive". This means that if the system infers "fault A propagates to fault B", and "fault B propagates to fault C", then the inference engine will automatically conclude that "fault A propagates to fault C". This configuration enables the knowledge graph to simulate chain reactions, providing a logical basis for root cause analysis across devices.

[0035] Through the above steps, previously isolated data is given semantic relationships. For example, the system clearly defines that "outlet temperature" in the "operating parameter ontology" belongs to "heat absorber" in the "equipment component ontology," and that an anomaly (failure mode) in this parameter may be caused by "decreased heat transfer efficiency" (failure cause). This unified framework ensures that subsequent text analysis and numerical calculations can be performed within the same logical context, avoiding data ambiguity and achieving a seamless mapping between physical equipment and logical faults.

[0036] Specifically, in this embodiment, configuring transitivity constraints for fault propagation relationships includes:

[0037] S1.1 Define the "faultPropagatesTo" object property that represents the direction of fault propagation in the physical topology, and declare that this property has a transitivity axiom using the OWL language.

[0038] First, an object property named "faultPropagatesTo" is defined in the schema layer of the knowledge graph. This property is designed to have a clear directionality, representing the propagation direction of fault energy or anomalous states in the physical topology. Subsequently, through the inference mechanism of OWL (Web Ontology Language), this property is formally declared to possess "transitiveness." This means that if a continuous path connected by this property exists in the graph, the inference engine will be able to automatically complete the direct relationship from the starting point to the end point.

[0039] S1.2. Set the first-level transmission path from the fault cause body to the fault mode body, and the second-level transmission path from the fault mode body to the device component body.

[0040] Next, the system establishes a logical hierarchical structure for fault propagation. Specifically, it constructs a first-level propagation path from the "fault cause ontology" to the "fault mode ontology," representing how a specific root cause can lead to a certain abnormal behavior. Simultaneously, it constructs a second-level propagation path from the "fault mode ontology" to the "device component ontology," representing how the abnormal behavior affects specific physical devices. This hierarchical structure clearly defines the transformation process from logical cause to physical manifestation of a fault.

[0041] S1.3 In response to a specific fault cause occurring in the first device, based on the transitivity axiom, it is automatically deduced that the fault cause can cause an abnormal fault mode in the downstream second device, thereby forming a reverse reasoning link across physical connection layers in the knowledge graph.

[0042] In actual operation, in response to the specific fault cause of "impeller wear" in the upstream first equipment (such as a circulating pump), based on the transitivity axiom set in step S1.1, the system can not only deduce that the fault caused the "insufficient flow" fault mode of this equipment, but also further deduce that the fault mode will propagate through the pipeline to the downstream second equipment (such as a heat exchanger), causing the "heat exchange efficiency to decrease" anomaly. Thus, a complete reasoning link that crosses physical connection levels and traces back from the downstream anomaly to the upstream root cause is automatically formed in the knowledge graph.

[0043] Specifically, in this embodiment, the attribute constraint configuration of the four main ontology types also includes:

[0044] S1.4 Define data attributes with numerical constraints in the running parameter body, the numerical constraints including upper threshold, lower threshold and unit attribute.

[0045] Within the "Operating Parameter Ontology," each parameter instance defines a data property with strict numerical constraints. For example, for the "Heat Transfer Oil Temperature" instance, the system mandates an upper threshold of 400 degrees Celsius, a lower threshold of -20 degrees Celsius, and explicitly specifies its unit attribute as degrees Celsius. This constraint ensures that when data layer instances are updated, the values ​​must be within a physically feasible range, providing a quantitative benchmark for subsequent anomaly detection.

[0046] S1.5 Define the "isConnectedTo" topology attribute in the device component body to represent the physical connection direction, and set the attribute to a non-reflexive and asymmetric constraint.

[0047] Within the "Device Component Ontology," a topology attribute named "isConnectedTo" is defined to describe the physical piping or circuit connections between devices. To prevent logical paradoxes, the system uses the OWL language to set this attribute to an "Irreflexive" constraint, which prohibits devices from connecting to themselves; it is also set to an "Asymmetric" constraint, meaning that if device A is connected to device B, the system will not assume that device B is also connected to device A, thus accurately reflecting the true unidirectional or bidirectional non-equivalence of fluid or energy flow.

[0048] S1.6 Define the "hasSymptom" object property in the fault mode ontology to associate it with the specific deviation of the operating parameters.

[0049] In the "Fault Mode Ontology," an object property named "hasSymptom" is defined. The purpose of this property is to link abstract fault types with specific quantitative indicators. For example, the fault mode instance "insufficient traffic" is associated with the "sudden drop in outbound traffic" instance in the "Running Parameter Ontology" through the "hasSymptom" property, thus semantically completing the mapping between "fault phenomenon - quantitative indicator."

[0050] S1.7. Through the attribute constraints, the knowledge graph can distinguish between secondary parameter deviations caused by upstream equipment failures and primary deviations caused by equipment failures.

[0051] Based on the aforementioned attribute constraints, the system possesses the ability to distinguish the source of a fault. When an abnormal parameter of a device is detected, the system checks whether that device has an upstream device pointed to by the "isConnectedTo" relationship. If the upstream device is faulty and the fault is transmitted through "faultPropagatesTo", the parameter deviation of the current device is determined to be a "secondary deviation"; conversely, if the upstream is normal but the local parameter exceeds the limit, it is determined to be a "primary deviation". This mechanism enables the knowledge graph to identify, like an expert, who is the culprit and who is the victim.

[0052] S2. Periodically collect operational data from the photothermal equipment, employ BIO tagging for named entity recognition, and multi-scale convolutional kernels for text classification. Automatically construct or update data layer instances of the knowledge graph according to the four main ontology types. This step is responsible for transforming the real-time data stream from the site into graph instances. Utilizing BIO tagging to accurately extract entities from unstructured logs, and combining it with multi-scale convolutional kernels to recognize parameter text, the system can automatically map the collected values ​​and status information to a preset ontology framework, enabling the dynamic evolution and real-time updating of the data layer as the equipment's operating conditions change.

[0053] Specifically, in this embodiment, the automatic construction or updating of data layer instances according to the four main ontology includes:

[0054] S2.1 Map the entity sequence output based on the pre-trained model and the labeling method to instances of the device component ontology or fault mode ontology, and use non-entity fields as candidate sets of attribute values.

[0055] The system receives output from the natural language processing model. Specifically, it maps the sequences output by the BERT-BiLSTM-Attention-CRF model based on the BIO tagging method (e.g., "B-device I-component" corresponds to "heat absorber") to instances of "device component ontology"; and maps "B-fault I-mode" to instances of "fault mode ontology". Simultaneously, fields not labeled as entities (e.g., specific numbers or date text) are automatically aggregated as candidate datasets for subsequent attribute filling.

[0056] S2.2. Use multi-scale convolution kernels to extract features and classify the candidate set, identify the numerical type and unit of measurement in the running parameter ontology, and normalize the numerical values ​​according to the predefined data attribute constraints in the four ontology.

[0057] The system utilizes multi-scale convolution kernels to perform convolution operations on the aforementioned candidate datasets to capture numerical text features of varying lengths. In this way, the system can accurately identify the numerical types (such as temperature and pressure) belonging to the "operational parameter ontology" and their suffixes of measurement units (such as ℃ and MPa). Subsequently, based on the predefined "unit attribute" constraints in step S1.4, the system automatically converts monitoring values ​​in different formats into unified international standard units, completing the data normalization process.

[0058] S2.3 When the fluctuation range of the operating parameters under the same device component instance is detected to exceed the allowable range, a fault performance connection edge pointing to the instance is dynamically created, thereby realizing the adaptive evolution of the data layer instance with the real-time data stream.

[0059] The system continuously monitors the fluctuations of various operating parameters within the same equipment component instance. When a fluctuation in a parameter (such as "outlet oil temperature") exceeds the allowable range set in step S1, the system does not simply overwrite the old data. Instead, it dynamically creates a new "hasSymptom" connection edge between the current equipment instance and a "fault mode ontology" instance representing an abnormal state. This mechanism enables the knowledge graph to adaptively grow new fault manifestation nodes based on real-time data streams, achieving dynamic evolution of the graph structure.

[0060] S3. Using the data layer instance, statistically analyze the changes and deviation rates of key parameters. Anomaly identification is achieved by comparing these with preset thresholds using production rules, generating anomaly identifiers and a range of suspicious devices. This stage focuses on the quantitative identification of abnormal behavior. Unlike single threshold alarms, this step comprehensively considers the short-term fluctuation range and long-term deviation ratio of parameters, accurately capturing abnormal signals through production rules. Once an alarm is triggered, the system not only marks the abnormal point in the graph but also delineates the range of potentially affected devices based on topological relationships, defining boundaries for subsequent reasoning.

[0061] Specifically, in this embodiment, the anomaly identification achieved by comparing production rules with preset thresholds includes:

[0062] S3.1 Define a two-factor trigger condition that includes a fluctuation range limit and a deviation ratio limit.

[0063] The system predefines a composite judgment logic for measuring parameter health, namely the "two-factor trigger condition." This condition includes two dimensions: "fluctuation amplitude limit" and "deviation ratio limit." The fluctuation amplitude limit is used to capture the behavior of parameters that change drastically in a short period of time, while the deviation ratio limit is used to assess the degree of long-term drift between the current value of the parameter and the historical benchmark value. Together, they constitute the quantitative threshold for anomaly judgment.

[0064] S3.2. If the actual fluctuation of a key operating parameter within the same time window exceeds the fluctuation limit, and the deviation ratio between the current parameter value and the benchmark value exceeds the deviation ratio limit, an alarm rule is triggered.

[0065] The system continuously monitors key operating parameters within a preset time window (e.g., the last 5 minutes). When the actual fluctuation of a parameter (e.g., "molten salt pump vibration value") exceeds the preset fluctuation limit, and the deviation ratio of the current value of the parameter from the normal operating baseline value also exceeds the deviation ratio limit, the system determines that the parameter has a substantial abnormality and then activates the built-in generational alarm rule.

[0066] Step S3.2a: Construct a two-factor anomaly trigger function. To overcome the technical deficiency of a single threshold judgment in distinguishing between instantaneous fluctuations and steady-state drift, this embodiment constructs a two-factor anomaly trigger function as shown in formula (1):

[0067] ,

[0068] in, For a moment The abnormal trigger flag, a value of 1 indicates that an abnormal alarm has been triggered; Key operating parameters In the time window The actual fluctuation range within; The preset fluctuation range limit is defined by step S3.1; This is the fluctuation amplitude sensitivity coefficient, used to adjust the response strength to instantaneous jumps; For a moment Current values ​​of key operating parameters; For a moment The baseline values ​​of the operating parameters are calculated using the moving average method based on historical operating data from the same period. For a moment The adaptive deviation ratio limit is calculated by formula (2); This is an indicator function that takes the value 1 when the condition inside the parentheses is true, and 0 otherwise; This is the logical AND operator, indicating that two conditions must be met simultaneously.

[0069] The system in the time window Internal continuous collection of key operating parameters The actual fluctuation range is obtained by calculating the absolute value of the difference between the current value and the previous value. Simultaneously, the system calculates the ratio of the absolute value of the deviation between the current value and the historical benchmark value P_base(t) to the benchmark value to obtain the deviation ratio. Then, the system uses a logical AND operator to jointly determine the two conditions. If the ratio of the fluctuation amplitude divided by the preset limit ΔP_th is greater than the sensitivity coefficient α, and the deviation ratio is greater than the adaptive limit at the current moment... When the condition is met, the indicator function outputs 1, triggering an anomaly alarm; otherwise, the indicator function outputs 0, and monitoring continues. This implementation ensures that anomaly triggering must simultaneously meet both the conditions of "short-term drastic fluctuation" and "long-term significant drift" through logical AND operation, thus eliminating false alarms caused by a single condition.

[0070] S3.3 Generate anomaly identifiers in the knowledge graph and mark the device component instances that trigger the anomaly identifiers and their topological adjacent nodes as objects to be investigated, thereby defining the initial boundary of anomaly propagation.

[0071] Once an alarm rule is triggered, the system immediately generates a visual "anomaly identifier" node in the knowledge graph and connects it to the device component instance that triggered the anomaly via attribute edges. At the same time, using the graph's neighborhood query capability, the system marks the device instance that triggered the anomaly and its directly connected adjacent nodes in the topology as "objects to be investigated," thereby logically defining the maximum initial boundary of the anomaly's potential spread.

[0072] Specifically, in this embodiment, the generation and scope definition of the anomaly identifier further includes:

[0073] S3.4. Based on the historical operating data of the running parameter body in the data layer instance, adaptively adjust the level of the deviation ratio limit.

[0074] The system utilizes historical operational data accumulated in the data layer instances to dynamically calibrate the "deviation from the proportional limit." For example, during the startup phase of a concentrated solar power plant, parameter fluctuations are naturally larger, and the system automatically raises the limit based on historical data from the same period; while under steady-state conditions such as nighttime insulation, the limit is automatically lowered. This adaptive mechanism effectively avoids false alarms or missed alarms caused by changes in operating conditions.

[0075] Step S3.4a: Construct an adaptive deviation ratio limit function. To address the technical challenge that static thresholds cannot adapt to the multi-condition operation of photothermal equipment (such as start-up / shutdown, insulation, and variable load phases), this embodiment constructs an adaptive deviation ratio limit function as shown in formula (2):

[0076] ,

[0077] in, This is the operating condition adjustment coefficient, during the start-up and shutdown phases. >0, in the steady state phase =0. For a moment The adaptive deviation ratio limit is dynamically adjusted according to changes in operating conditions. The baseline deviation ratio limit is initialized and set by domain experts based on the equipment's factory parameters. The average value of this parameter under the same historical operating conditions is calculated based on historical instances of the operating parameter ontology in the knowledge graph; This represents the standard deviation of the parameter under historical operating conditions, used to characterize the degree of fluctuation of the parameter under normal operating conditions. This represents the standard deviation of real-time parameters within the current time window. This is the standard deviation benchmark value of the equipment under ideal steady-state operating conditions. This value is obtained by extracting a data segment of the equipment that has been running stably for 72 consecutive hours without any alarm records, and calculating the standard deviation of the key parameters within this data segment.

[0078] The system first extracts the parameter sequence of the same equipment under the same historical operating conditions from the knowledge graph's operational parameter ontology, and calculates its mean. and standard deviation Then, based on the current operating stage of the equipment (determined by detecting the rate of change of parameters to determine whether it is in the start-up / shutdown or steady-state stage), the operating condition adjustment coefficient is set. (Start-up and shutdown phase) >1. Steady-state phase <1, and calculate the real-time standard deviation within the current time window. Compared with the ideal steady-state standard deviation The ratio; finally, the system will determine the deviation of the benchmark from the proportional limit. Multiply by the exponential decay term , plus The product of the ratio term and the adaptive deviation ratio limit at the current time is obtained. This implementation method allows the deviation ratio limit to be automatically adjusted according to the equipment operating conditions, and the limit tends to approach the historical average value when the parameter is close to the historical average value. When fluctuations are severe, a secondary correction is made through the ratio term.

[0079] S3.5 Utilize the neighborhood traversal capability of the knowledge graph to calculate the influence radius of the anomaly identifier in the physical topology.

[0080] Based on a knowledge graph-based graph traversal algorithm, the system calculates the "influence radius" of anomaly identifiers. Specifically, starting from the device component instance that triggered the anomaly, the system performs a breadth-first search (BFS) outward along the "isConnectedTo" attribute. Based on the physical characteristics of fault propagation (such as fluid velocity and thermal inertia), the search depth or number of hops is set as the influence radius, thereby quantifying the furthest distance the anomaly may reach.

[0081] Step S3.5a: Constructing an anomaly influence radius quantification function. To achieve quantitative definition of the anomaly influence range and avoid boundary ambiguity caused by subjective experience, this embodiment constructs an influence radius function based on graph traversal as shown in formula (3):

[0082] ,

[0083] in, The radius of influence of the anomaly identifier in the physical topology, expressed in hops of graph traversal; The set of all device component instances that satisfy the parameter deviation condition, i.e.: , It is the collection of instances of all device component ontology in the knowledge graph; For equipment At any moment Key operating parameter values; For equipment The moment Parameter baseline value; The local deviation ratio threshold is usually taken as... To reduce the impact of false alarms; The set of confirmed anomaly source devices, initial state. ,in The device node that triggered the anomaly flag; For knowledge graphs from nodes To the node The shortest path length is calculated using the breadth-first search algorithm combined with the isConnectedTo attribute defined in step S1.5; Represents device node Minimum number of hops to any known anomaly source; This represents the maximum value among the minimum hop counts from all affected devices to the anomaly source.

[0084] The system triggers the device node with the anomaly flag. For the initial set of anomaly sources The collection of all device component instances in the knowledge graph To search the space; first traverse Each device node in Through formula Determine whether the deviation condition is met, and add nodes that meet the condition to the affected device set. Then for Each device in The breadth-first search algorithm, combined with the isConnectedTo property defined in step S1.5, is used to calculate the distance to the set of anomaly sources. Each node Shortest path length The minimum value among these is taken as the minimum hop count from the device to the anomaly source; finally, all affected devices are traversed, and the maximum value among these minimum hop counts is taken as the influence radius. This implementation quantifies the scope of suspicion as "centered on the source of the anomaly, and..." The semantic set of devices with "jump as radius" provides a rigorous mathematical basis for the subsequent step S3.6 of delineating the objects to be investigated.

[0085] S3.6. Include all device component instances within the influence radius into the set of objects to be investigated, thereby achieving semantic delineation of the scope of the abnormal impact.

[0086] Based on the influence radius calculated in step S3.5, the system automatically captures all device component instances within that radius and includes them in the "set of objects to be investigated". This topological neighborhood-based delineation method transforms the originally vague "suspicious range" into a set of devices with clear semantic boundaries (such as "within two hops of the fault source") in the knowledge graph, providing clear input boundaries for subsequent accurate reasoning.

[0087] S4. Starting from the anomaly identifier and using the range of suspicious devices as the boundary, a question-and-answer mechanism integrating a FAQ engine, a knowledge graph engine, and a reading comprehension engine is employed. Combined with the transitivity constraints, the system performs a reverse topology traversal along the fault propagation path to locate the root cause of the fault. This step is the core of root cause localization, employing a three-tiered progressive question-and-answer mechanism of FAQ, knowledge graph, and reading comprehension. Starting from the anomaly point, within the defined suspicious range, the system performs a reverse topology traversal based on the transitivity constraints set in step S1. By comparing upstream and downstream parameter deviations, secondary faults are eliminated layer by layer, ultimately pinpointing the source fault point that triggered the chain reaction.

[0088] Specifically, in this embodiment, the question-answering mechanism that integrates the FAQ engine, graph engine, and reading comprehension engine includes:

[0089] S4.1 In response to receiving a fault diagnosis request, the first engine based on FAQ semantic matching is called first for retrieval. If no matching item is found, the second engine based on knowledge graph triple query is called for structured reasoning.

[0090] When the system receives a fault diagnosis request (such as a user inputting "What should I do if the heat transfer oil temperature is too high"), it first calls the first engine based on FAQ (Frequently Asked Questions) semantic matching. This engine uses vector similarity calculation to search for the most matching standard answer in a pre-set question-and-answer database. If no matching item with sufficient similarity is found, the system determines that the problem belongs to a non-standard fault and then downgrades to calling the second engine based on knowledge graph triple query, attempting to find structured logical relationships through graph traversal.

[0091] S4.2 When the second engine cannot return a definite result, the third engine based on machine reading comprehension is started to perform semantic parsing on the unstructured log text.

[0092] If the second engine fails to find a definite causal relationship in the knowledge graph (e.g., missing corresponding triple connections), the system activates a third engine based on machine reading comprehension. This engine focuses on recently collected unstructured alarm logs and runtime text, and through deep semantic understanding, extracts potentially relevant evidence fragments from the long text as supplementary information for reasoning.

[0093] S4.3. By sequentially scheduling and fusing the results of the three engines, a progressive semantic understanding of the fault phenomenon and dynamic generation of the root cause candidate set are achieved.

[0094] The system performs weighted fusion and logical verification on the outputs of the three engines. For example, when the FAQ engine provides general suggestions, the graph engine provides topological relationships, and the reading engine provides log clues, the system integrates them into a "root cause candidate set" containing multiple possibilities. This progressive semantic understanding mechanism ensures that the system can dynamically generate highly reliable troubleshooting suggestions for both common and rare faults.

[0095] Specifically, in this embodiment, the reverse traversal along the fault propagation path in conjunction with transitivity constraints further includes:

[0096] S4.4. Using the anomaly identifier as the starting point for reasoning, within the scope of the suspected devices, perform a reverse graph traversal operation based on the transitivity constraint of the fault propagation relationship.

[0097] The system uses the "abnormal identifier" generated in step S3 as the starting point for inference and operates within the "set of objects to be investigated" defined in step S3.6. Based on the transitivity axiom of the "faultPropagatesTo" attribute set in step S1.1, the system executes a reverse graph traversal algorithm. That is, starting from the current abnormal device node, it backtracks level by level along the reverse direction (i.e., upstream) of the "isConnectedTo" attribute to find all possible fault propagation paths.

[0098] S4.5 By comparing the degree of parameter deviation of upstream and downstream equipment within the same time window, secondary fault nodes that are only affected are eliminated, and the source node of the fault propagation chain is identified.

[0099] During the traversal, the system compares the degree of parameter deviation between upstream and downstream devices within the same time window. If it finds that the upstream device's parameter deviation occurred earlier and with a larger magnitude, while the downstream device merely passively follows the fluctuations, the downstream device is identified as a "secondary fault node" and removed. Through this dual comparison of timing and magnitude, the system can effectively distinguish between "primary faults" and "secondary deviations."

[0100] S4.6. Determine the fault cause ontology instance corresponding to the source node as the root fault cause, and generate an explanatory evidence chain containing the reasoning path.

[0101] After layers of screening, the system finally identified the source node of the fault propagation chain and determined the "fault cause ontology" instance associated with that node as the "root fault cause". At the same time, the system automatically concatenates all triple relationships from the root cause node to the end anomaly identifier node, generating an explanatory evidence chain containing timestamps, parameter values, and topological connections, providing a transparent logical basis for operation and maintenance decisions.

[0102] S5. Based on the anomaly identification results and the root cause of the fault, generate a fault handling decision that includes the fault source identifier, fault type, and maintenance suggestions, and display the device topology and fault propagation path through a visual interface. The final step transforms the reasoning results into executable operation and maintenance instructions. The system automatically generates a handling plan that includes the fault type, source identifier, and maintenance suggestions, and visualizes the abstract logical reasoning as highlighted paths and parameter change curves on the topology map through a visual interface, allowing operation and maintenance personnel to intuitively understand the ins and outs of the fault.

[0103] Specifically, in this embodiment, displaying the device topology and fault propagation path through a visual interface includes:

[0104] S5.1 Based on the location of the root cause of the fault in the knowledge graph, extract the complete reasoning link from the fault source identifier to the anomaly identifier.

[0105] Based on the root cause of the fault determined in step S4.6, the system performs path lookup in the knowledge graph. Specifically, it extracts all entities and relationships from the device component node representing the source of the fault, through intermediate transmission links, all the way to the terminal anomaly identifier node, thereby constructing a complete and traceable logical reasoning link.

[0106] S5.2. In the visualization interface, the device topology is rendered differentially. The device component carrying the root cause of the failure is marked as the source node, and the downstream device that only exhibits abnormal parameters is marked as the affected node. In the topology diagram of the visualization interface, the system performs visual differentiation processing on different device components. The device component carrying the root cause of the failure is highlighted as the "source node" (e.g., indicated by flashing red), while those devices that only exhibit abnormal parameters but have no cause of failure are marked as "affected nodes" (e.g., indicated by yellow), thereby intuitively distinguishing the cause and the victim of the failure.

[0107] S5.3 Simultaneously display the associated operating parameter change curves and overlay the inference link on the topology diagram to graphically present the mapping relationship from physical connection to logical fault propagation.

[0108] The system simultaneously displays the curves of operational parameter changes associated with the aforementioned nodes (such as temperature trend graphs) on the side or bottom of the same interface. At the same time, the inference links extracted in step S5.1 are overlaid on the topology map as arrowed lines. This graphical presentation clearly reveals the mapping relationship from physical connections (lines) to logical fault propagation (arrow direction), greatly reducing the understanding cost for maintenance personnel.

[0109] Example 2

[0110] like Figure 2 As shown, this application provides an architecture diagram of a knowledge graph-based solar thermal equipment anomaly diagnosis and handling decision system, applied to the knowledge graph-based solar thermal equipment anomaly diagnosis and handling decision method as described in Embodiment 1, including:

[0111] The semantic framework construction module 210 is used to construct the schema layer of the knowledge graph for anomaly diagnosis of photothermal equipment. It defines four main ontology: equipment components, operating parameters, fault modes, and fault causes. It also uses the OWL language to configure transitivity constraints for fault propagation relationships, forming a unified semantic framework.

[0112] The data layer update module 220 is used to periodically collect the operating data of the photothermal equipment, use the BIO tagging method for named entity recognition, use multi-scale convolution kernels for text classification, and automatically construct or update the data layer instance of the knowledge graph according to the four main ontology.

[0113] The anomaly identification module 230 is used to use the data layer instance to statistically analyze the changes and deviation rates of key parameters, and to achieve anomaly identification by comparing the results with a preset threshold through production rules, thereby generating anomaly identifiers and a range of suspicious devices.

[0114] The root cause reasoning module 240 is used to locate the root cause of the fault by taking the anomaly identifier as the starting point and the range of the suspicious devices as the boundary, and by using a question-and-answer mechanism that integrates the FAQ engine, graph engine and reading comprehension engine, combined with the transitivity constraints to traverse backward along the fault propagation path.

[0115] The decision display module 250 is used to generate fault handling decisions, including fault source identification, fault type and maintenance suggestions, based on the anomaly identification results and the root cause of the fault, and to display the equipment topology and fault propagation path through a visual interface.

[0116] Figure 3 This is an electronic device provided in one embodiment of this application. For example... Figure 3 As shown, the electronic device includes at least the following components: processor 301 and memory 300, communication interface 303, and bus 302.

[0117] In this embodiment of the application, memory 300 is used to store executable instructions of processor 301, which, when configured to execute instructions, implements the method as described in the first aspect.

[0118] In embodiments of this application, a computer-readable storage medium includes instructions that instruct a device to perform the method as described in the first aspect. For example, the instructions instruct the device to perform... Figure 1 The method is shown in the process steps.

[0119] In one embodiment of this application, the program operating in the electronic device may be a program that controls a central processing unit (CPU) or similar device to achieve the functions of the above-described embodiments of the present invention (a program that enables the computer to function). Information processed by these systems is then temporarily stored in random access memory (RAM) during processing, and subsequently stored in various ROMs such as read-only memory (FlashROM) and hard disk drives (HDDs), and read, corrected, and written by the CPU as needed.

[0120] It should be noted that a portion of the electronic device described above can also be implemented using a computer. In this case, the program for implementing the control function can be recorded on a computer-readable recording medium, and the program recorded on the recording medium can be read into the computer and executed.

[0121] It should be noted that the computer mentioned here refers to a computer built into an electronic device, employing hardware including an operating system and peripheral devices. Furthermore, computer-readable recording media refers to removable media such as floppy disks, magneto-optical disks, ROMs, and CD-ROMs, as well as storage systems such as hard drives built into the computer.

[0122] Furthermore, computer-readable recording media can include: media that dynamically stores programs for short periods of time, such as communication lines used when transmitting programs via networks like the Internet or communication lines like telephone lines; and media that store programs for fixed periods of time, such as volatile memory inside a computer that serves as a server or client in this case. In addition, the aforementioned program can be a program used to implement the above-mentioned functions, or it can be a program that can implement the above-mentioned functions by combining them with programs already recorded in the computer.

[0123] Furthermore, the electronic device in the above embodiments can also be implemented as an assembly (system group) composed of multiple systems. Each system constituting the system group can possess some or all of the functions or functional blocks of the electronic device in the above embodiments. As a system group, it is sufficient to have all the functions or functional blocks of the electronic device.

[0124] Those skilled in the art should recognize that the above embodiments are only used to illustrate this application and are not intended to limit this application. Any appropriate changes and variations made to the above embodiments within the essential spirit and scope of this application fall within the scope of protection claimed in this application.

Claims

1. A method for diagnosing and handling anomalies in photothermal equipment based on knowledge graphs, characterized in that, Includes the following steps: A schema layer of a knowledge graph for anomaly diagnosis of photothermal equipment is constructed, defining four main entities: equipment components, operating parameters, fault modes, and fault causes. Transitive constraints are configured for fault propagation relationships using the OWL language to form a unified semantic framework. The system periodically collects operational data from the photothermal equipment, uses BIO tagging for named entity recognition, employs multi-scale convolutional kernels for text classification, and automatically constructs or updates data layer instances of the knowledge graph according to the four main ontology types. Using the data layer instance, the changes and deviation rates of key parameters are statistically analyzed, and anomaly identification is achieved by comparing production rules with preset thresholds, generating anomaly identifiers and a range of suspicious devices; Starting from the anomaly identifier and taking the range of suspicious devices as the boundary, a question-and-answer mechanism integrating the FAQ engine, graph engine and reading comprehension engine is used, combined with the transitivity constraint to traverse backward along the fault propagation path to locate the root cause of the fault. Based on the anomaly identification results and the root cause of the fault, a fault handling decision is generated, which includes the fault source identifier, fault type and maintenance suggestions, and the equipment topology and fault propagation path are displayed through a visual interface.

2. The method according to claim 1, characterized in that, The configuration of transitivity constraints for fault propagation relationships specifically includes: Define the "faultPropagatesTo" object property that represents the direction of fault propagation in the physical topology, and declare that this property has a transitivity axiom using the OWL language; Define the first-level transmission path from the fault cause body to the fault mode body, and the second-level transmission path from the fault mode body to the device component body. In response to a specific fault cause occurring in the first device, the fault cause is automatically deduced based on the transitivity axiom, which can cause an abnormal fault mode in the downstream second device, thereby forming a reverse reasoning link across physical connection layers in the knowledge graph.

3. The method according to claim 1, characterized in that, The attribute constraint configurations of the four main ontology types also include: In the operating parameter body, data attributes with numerical constraints are defined, including upper threshold, lower threshold, and unit attributes. Define the "isConnectedTo" topology attribute representing the physical connection direction in the device component body, and set this attribute as a non-reflexive and asymmetric constraint; In the fault mode ontology, a "hasSymptom" object property is defined to associate with specific deviations in operating parameters. The attribute constraints enable the knowledge graph to distinguish between secondary parameter deviations caused by upstream equipment failures and primary deviations caused by equipment failures themselves.

4. The method according to claim 1, characterized in that, The automatic construction or updating of data layer instances based on the four main ontology specifically includes: The entity sequence output based on the pre-trained model and the labeling method is mapped to an instance of the device component ontology or the fault mode ontology, and non-entity fields are used as a candidate set of attribute values. Multi-scale convolution kernels are used to extract and classify the candidate set, identify the numerical type and unit of measurement in the running parameter ontology, and normalize the numerical values ​​according to the predefined data attribute constraints in the four ontology. When the fluctuation of operating parameters under the same device component instance is detected to exceed the allowable range, a fault performance connection edge pointing to that instance is dynamically created, thereby enabling the data layer instance to adaptively evolve with the real-time data stream.

5. The method according to claim 1, characterized in that, The method of identifying anomalies by comparing production rules with preset thresholds specifically includes: Define a two-factor trigger condition that includes a volatility limit and a deviation ratio limit; If the actual fluctuation of a key operating parameter within the same time window exceeds the fluctuation limit, and the deviation ratio between the current parameter value and the benchmark value exceeds the deviation ratio limit, an alarm rule is triggered. Anomaly identifiers are generated in the knowledge graph, and the device component instances that trigger the anomaly identifiers and their topological adjacent nodes are marked as objects to be investigated, thereby defining the initial boundary of anomaly propagation.

6. The method according to claim 5, characterized in that, The generation and scope definition of the anomaly identifier also include: Based on the historical operating condition data of the running parameter body in the data layer instance, the deviation ratio limit is adaptively adjusted. Utilizing the neighborhood traversal capability of the knowledge graph, the influence radius of the anomaly identifier in the physical topology is calculated; All device component instances within the influence radius are included in the set of objects to be investigated, thereby achieving semantic delineation of the scope of the abnormal impact.

7. The method according to claim 1, characterized in that, The question-answering mechanism, which integrates a FAQ engine, a graph engine, and a reading comprehension engine, specifically includes: In response to receiving a fault diagnosis request, the first engine based on FAQ semantic matching is called first for retrieval. If no matching item is found, the second engine based on knowledge graph triple query is called for structured reasoning. When the second engine fails to return a definite result, the third engine, based on machine reading comprehension, is activated to perform semantic parsing on the unstructured log text. By sequentially scheduling and fusing the results of the three engines, a progressive semantic understanding of the fault phenomenon and dynamic generation of the root cause candidate set are achieved.

8. The method according to claim 7, characterized in that, The reverse traversal along the fault propagation path, incorporating transitivity constraints, also includes: Using the anomaly identifier as the starting point for reasoning, within the scope of the suspected devices, a reverse graph traversal operation is performed based on the transitivity constraints of the fault propagation relationship; By comparing the degree of parameter deviation of upstream and downstream equipment within the same time window, secondary fault nodes that are only affected are eliminated, and the source node of the fault propagation chain is identified. The fault cause instance corresponding to the source node is identified as the root cause of the fault, and an explanatory evidence chain containing the reasoning path is generated.

9. The method according to claim 1, characterized in that, The visualization of device topology and fault propagation paths through a visual interface specifically includes: Based on the location of the root cause of the failure in the knowledge graph, the complete reasoning link between the failure source identifier and the anomaly identifier is extracted. The device topology is rendered differently in the visualization interface, and the device components that carry the root cause of the failure are marked as source nodes, and the downstream devices that only show abnormal parameters are marked as affected nodes. The associated operating parameter change curves are displayed synchronously, and the inference link is overlaid on the topology diagram to present the mapping relationship from physical connection to logical fault propagation in a graphical way.

10. A knowledge graph-based decision-making system for malfunction diagnosis and handling of photothermal equipment, applied to the method described in any one of claims 1 to 9, characterized in that, The system includes: The semantic framework construction module is used to build the schema layer of the knowledge graph for anomaly diagnosis of photothermal equipment. It defines four main ontology: equipment components, operating parameters, fault modes, and fault causes. It also uses the OWL language to configure transitivity constraints for fault propagation relationships, forming a unified semantic framework. The data layer update module is used to periodically collect the operating data of the photothermal equipment, use the BIO tagging method for named entity recognition, use multi-scale convolution kernels for text classification, and automatically construct or update the data layer instance of the knowledge graph according to the four main ontology. The anomaly detection module is used to use the data layer instance to statistically analyze the changes and deviation rates of key parameters, and to achieve anomaly detection by comparing production rules with preset thresholds, thereby generating anomaly identifiers and a range of suspicious devices. The root cause reasoning module is used to locate the root cause of the fault by taking the anomaly identifier as the starting point and the range of the suspicious devices as the boundary, and using a question-and-answer mechanism that integrates the FAQ engine, graph engine and reading comprehension engine, combined with the transitivity constraints to traverse backward along the fault propagation path. The decision display module is used to generate fault handling decisions based on anomaly identification results and root cause of fault, including fault source identification, fault type and maintenance suggestions, and to display the equipment topology and fault propagation path through a visual interface.

Images