Equipment fault information sharing system and method based on Internet of Things

Abstract

The invention discloses an equipment fault information sharing system and method based on the Internet of Things, and relates to the technical field of equipment fault sharing. Causal relationships among parts, faults and operation parameters are identified, real-time operation data, historical fault data and maintenance records are integrated, association relationships among various types of data are combined, a fault knowledge graph is constructed, and fault information sharing is performed. Reasoning is executed through a rule engine in the knowledge graph, possible fault causes are deduced, and cross-modal fusion is performed on fault phenomena, parameter changes and historical records to obtain a more accurate fault cause reasoning result. According to the sharing system, after the parts, the operation parameters and the fault types of the electric water heater are associated, the comprehensive fault knowledge graph is constructed, so that when the electric water heater breaks down, the parts which possibly have abnormity can be displayed to maintenance personnel after reasoning, the maintenance efficiency is improved, and the maintenance cost is reduced. And the use safety of the electric water heater after maintenance is guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of equipment fault sharing, and in particular to an equipment fault information sharing system and method based on the Internet of Things. Background Art

[0002] Electric water heaters are high-power electrical appliances commonly used in households and are closely related to daily life. The stability and safety of their operation are of vital importance. Due to factors such as high temperature, high-pressure water and electricity, failure of electric water heaters may lead to risks such as leakage, overheating and even explosion. Therefore, an effective monitoring and early warning mechanism is needed. The sharing system aims to use the Internet of Things technology to monitor and analyze the operating status of electric water heaters in real time, and quickly share information with users, maintenance personnel and manufacturers when failures or potential failures occur.

[0003] The prior art has the following deficiencies:

[0004] The operation of electric water heaters involves monitoring of hydraulic, electrical and mechanical components. When an electric water heater fails, the existing shared system can only display the fault area and fault cause to the maintenance personnel. However, due to the certain correlation between the components of the electric water heater, the shared system cannot infer possible abnormalities based on the current fault cause. Manual troubleshooting will reduce the maintenance efficiency of the electric water heater and may cause problems such as false detection or missed detection, which will still pose a safety hazard to the subsequent use of the electric water heater.

[0005] The present invention provides an equipment fault information sharing system and method based on the Internet of Things. By associating the components, operating parameters and fault types of the electric water heater, a comprehensive fault knowledge graph is constructed. When the electric water heater fails, the components that may have abnormalities can be displayed to the maintenance personnel after reasoning. This not only helps to improve the maintenance efficiency, but also ensures the safety of the electric water heater after maintenance. Summary of the invention

[0006] The purpose of the present invention is to provide a device fault information sharing system and method based on the Internet of Things to solve the shortcomings of the background technology.

[0007] In order to achieve the above object, the present invention provides the following technical solution: a device fault information sharing system and method based on the Internet of Things, wherein the sharing method comprises the following steps:

[0008] Collect log information of faulty equipment through IoT sensors, use equipment components, operating parameters, and fault types as nodes, obtain node relationships between nodes, and use natural language processing technology to extract entities from text records of log information;

[0009] Through semantic analysis and pattern matching algorithms, the relationship between entities is extracted from equipment operating parameters and maintenance records, the causal relationship between components, faults and operating parameters is identified, and real-time operating data, historical fault data and maintenance records are integrated. Combined with the association between various types of data, a fault knowledge graph is constructed.

[0010] Based on the real-time data stream of the Internet of Things, the nodes and relationships in the knowledge graph are dynamically updated. The nodes and relationships in the knowledge graph are embedded into a low-dimensional space using a graph embedding algorithm. Reasoning is performed through the rule engine in the knowledge graph to deduce the cause of the fault. Combined with graph data and IoT sensor data, the fault phenomenon, parameter changes, and historical records are cross-modally fused to obtain the fault cause reasoning results, and the knowledge graph is displayed using graph visualization tools.

[0011] In a preferred embodiment, the components, operating parameters and fault types of the equipment are taken as nodes, and the node relationship between the nodes is obtained, including the following steps:

[0012] The components of the electric water heater include heater, temperature sensor, water pump, and control module, and each component is regarded as an independent node;

[0013] Identify the operating parameters of the electric water heater, including temperature, water flow, and current, and use the operating parameters as nodes in the knowledge graph;

[0014] Analyze historical fault data, determine the fault type, and use each fault type as a node in the knowledge graph;

[0015] By analyzing the structure and function of the electric water heater, the connection relationship between components is obtained, the operating parameters are connected with related components, and the causal relationship between each fault type and the component is identified, and the relationship between the fault type and the operating parameters is obtained;

[0016] Based on historical failure data and component health status, the strength of the relationship between nodes is evaluated and a weight is assigned to each relationship.

[0017] In a preferred embodiment, based on historical fault data and component health status, the relationship strength between nodes is evaluated and a weight is assigned to each relationship, including the following steps:

[0018] Collect the historical fault records of electric water heaters, including fault type, occurrence time, related components and fault description, and obtain the simultaneous fault frequency and health status correlation coefficient between each node, and calculate the relationship strength between nodes. The expression is: Where S(i,j) is the strength of the relationship between node i and node j, F(i,j) is the frequency of simultaneous failures between node i and node j, H(i,j) is the health status correlation coefficient between node i and node j, α and β are adjustment coefficients, and both are greater than 0, and N represents the total failure time;

[0019] Assign a weight to the relationship between node i and node j according to the relationship strength. The expression is:

[0020] W(i,j)=k·S(i,j), where S(i,j) is the strength of the relationship between node i and node j, W(i,j) is the weight of the relationship between node i and node j, and k is the weight ratio coefficient.

[0021] In a preferred embodiment, the fault phenomenon, parameter change and historical record are cross-modally fused in combination with graph data and IoT sensor data to obtain the fault cause reasoning result, including the following steps:

[0022] Synchronize data from IoT sensors with knowledge graph data and normalize node attributes in the knowledge graph;

[0023] The time series features of sensor data are integrated with the attribute data of knowledge graph nodes to construct feature vectors of graph nodes, perform pattern matching on sensor data and graph data, and combine similar features;

[0024] Use cosine similarity to calculate the cross-modal similarity between cross-modal feature vectors, measure the matching degree between the current fault features and the historical records, assign weights according to the importance of different modalities, and integrate similarity scores to generate a comprehensive similarity index to guide fault cause reasoning;

[0025] According to the calculated cross-modal similarity, the current fault characteristics are matched with the historical fault patterns to determine the cause of the fault.

[0026] In a preferred embodiment, the calculation expression of the health status correlation coefficient is:

[0027] Where n is the number of time points to compare, H i (g) is the health status score of node i at the gth time point, H j (g) is the health status score of node j at the gth time point, μ i is the mean health status score of node i, μ j is the mean health status score of node j, σ i is the standard deviation of the health status score of node i, σ jThe standard deviation of the health status score of node j, parameter deviation includes but is not limited to temperature deviation, vibration deviation, pressure deviation, current deviation and water flow deviation. The general calculation expression of the health status score of node i at the gth time point is:

[0028] H i (g)=w1·P1(g)+w2·P2(g)+w3·P3(g)+…+w n ·P n (g), where P n (g) represents the deviation of each parameter at the gth time point, w n is the corresponding parameter deviation weight.

[0029] In a preferred embodiment, real-time operation data, historical fault data and maintenance records are integrated, and the association between various types of data is combined to construct a fault knowledge graph, including the following steps:

[0030] Map the entities involved in each data set and unify them into the same format or representation, connecting real-time operation data, fault data and maintenance records through timestamps, equipment IDs or component names;

[0031] Based on the interaction and co-occurrence relationship of various data, the association relationship between various entities is established to identify the component-fault and parameter-fault relationship;

[0032] Based on the integrated data, each entity is instantiated and added to the graph, and nodes and relationships are gradually added using the graph database to form a preliminary knowledge graph structure;

[0033] Combining different data types, by analyzing the association between operating parameters and fault records, a cross-modal association network is established, and similarity measurement methods are used to match entities and infer relationships between different data modalities, identify different manifestations of the same equipment, component or fault, and integrate their relationships;

[0034] Based on the association rule mining algorithm, potential relationships between components and fault associations are discovered and added to the knowledge graph to improve the relationship network. Through graph structure analysis, isolated nodes and weakly connected nodes in the graph are detected.

[0035] In a preferred embodiment, extracting entities from text records of log information using natural language processing technology includes the following steps:

[0036] Remove useless characters, special symbols, and punctuation noise from the log text, use the word segmentation tool to split the text into single words or phrases, and mark the part of speech for each word;

[0037] Use pre-trained NER models or fine-tune them on existing log data to identify equipment components, fault types, and parameter entities, and identify and label entity categories in text;

[0038] Construct a dictionary in the field of electric water heaters, including vocabulary in the fields of equipment components, fault types, and operating parameters. Use the vocabulary in the dictionary for matching, correct or supplement the recognition results, and determine the relationship between entities by analyzing the context of the entities in the log text.

[0039] The equipment fault information sharing system based on the Internet of Things includes a data collection module, a knowledge graph construction module, a dynamic update module, a derivation module, and a graph display module;

[0040] Data collection module: collects log information of faulty equipment through IoT sensors, takes equipment components, operating parameters, and fault types as nodes, and obtains the node relationships between nodes;

[0041] Knowledge graph construction module: Use natural language processing technology to extract entities from the text records of log information, extract the relationship between entities from equipment operating parameters and maintenance records through semantic analysis and pattern matching algorithms, identify the causal relationship between various components, faults and operating parameters, integrate real-time operating data, historical fault data and maintenance records, and combine the associations between various types of data to build a fault knowledge graph;

[0042] Dynamic update module: Based on the real-time data stream of the Internet of Things, dynamically update the nodes and relationships in the knowledge graph;

[0043] Inference module: Use graph embedding algorithm to embed nodes and relationships in the knowledge graph into low-dimensional space, perform reasoning through the rule engine in the knowledge graph, and deduce the cause of the fault;

[0044] Graph display module: Combine graph data and IoT sensor data to cross-modally fuse fault phenomena, parameter changes, and historical records, obtain fault cause inference results, and use graph visualization tools to display knowledge graphs.

[0045] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0046] The present invention extracts the relationship between entities from the equipment operating parameters and maintenance records, identifies the causal relationship between various components, faults and operating parameters, integrates real-time operating data, historical fault data and maintenance records, and builds a fault knowledge graph based on the association between various types of data. The rule engine (such as Cypher query language) in the knowledge graph performs reasoning to deduce possible fault causes, and cross-modally fuses fault phenomena, parameter changes and historical records to obtain more accurate fault cause reasoning results. The shared system builds a comprehensive fault knowledge graph by associating the components, operating parameters and fault types of the electric water heater, so that when the electric water heater fails, it can show the maintenance personnel the components that may have abnormalities after reasoning, which is not only conducive to improving maintenance efficiency, but also ensures the safety of the electric water heater after maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0048] Figure 1 The figure is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] Example 1: Please refer to Figure 1 As shown, the device fault information sharing method based on the Internet of Things described in this embodiment includes the following steps:

[0051] The sharing system collects log information of faulty equipment through IoT sensors, takes equipment components, operating parameters, and fault types as nodes, and obtains the node relationships between each node. It uses natural language processing technology to extract entities from the text records of log information, such as equipment component names, fault types, and related parameters. It uses semantic analysis and pattern matching algorithms to extract the relationship between entities from equipment operating parameters and maintenance records, identify the causal relationship between components, faults, and operating parameters, integrate real-time operating data, historical fault data, and maintenance records, and combine the associations between various types of data to build a comprehensive fault knowledge graph. Based on the real-time data stream of the IoT, it dynamically updates the nodes and relationships in the knowledge graph. For example, when new fault information is added, , add new fault nodes and their associated relationships to the knowledge graph, use the graph embedding algorithm to embed the nodes and relationships in the knowledge graph into a low-dimensional space, perform reasoning through the rule engine in the knowledge graph (such as Cypher query language), deduce possible fault causes, combine graph data and IoT sensor data, cross-modally fuse fault phenomena, parameter changes, and historical records to obtain more accurate fault cause reasoning results, use graph visualization tools (such as Neo4j-Bloom, Graph-X) to display the knowledge graph, so that maintenance personnel can intuitively view the fault associations and causal relationships between the various components of the electric water heater, and collect feedback from maintenance personnel after fault handling to correct incorrect relationships in the knowledge graph or supplement new fault modes.

[0052] This application extracts the relationship between entities from the equipment operating parameters and maintenance records, identifies the causal relationship between each component, fault and operating parameter, integrates the real-time operating data, historical fault data and maintenance records, and builds a fault knowledge graph based on the association between various types of data. The rule engine in the knowledge graph (such as Cypher query language) performs reasoning to deduce possible causes of the fault, and cross-modally fuses the fault phenomenon, parameter changes and historical records to obtain more accurate fault cause reasoning results. The shared system builds a comprehensive fault knowledge graph by associating the components, operating parameters and fault types of the electric water heater, so that when the electric water heater fails, it can show the maintenance personnel the components that may have abnormalities after reasoning, which is not only conducive to improving maintenance efficiency, but also ensures the safety of the electric water heater after maintenance.

[0053] Embodiment 2: The sharing system collects log information of faulty equipment through IoT sensors, including the following steps:

[0054] Sensor data collection: The system collects real-time operating data through sensors on the electric water heater, including key parameters such as temperature, water flow, and current. These data are centrally collected by the IoT platform for unified processing and analysis.

[0055] Log data acquisition: The fault log information (such as alarm information, abnormal status description, etc.) generated by the electric water heater is connected to the system through the Internet of Things. The log information is usually stored in text form, containing information such as the equipment's fault time, fault description, and component status.

[0056] Data cleaning: Clean the collected raw data to remove redundant or noisy information, and perform pre-processing such as word segmentation and punctuation removal on text logs to extract useful information.

[0057] Data structuring: The cleaned log information and sensor data are structured and organized into a unified format to facilitate subsequent data processing, analysis and storage. In this way, the system can manage and analyze data more efficiently.

[0058] Data storage: Store structured data in the IoT data platform to ensure data traceability and security, and provide basic data support for knowledge graph construction and analysis.

[0059] The components, operating parameters and fault types of the equipment are taken as nodes, and the node relationship between the nodes is obtained, including the following steps:

[0060] Component node identification: Identify the key components of the electric water heater, such as the heater, temperature sensor, water pump, control module, etc., and treat each component as an independent node.

[0061] Operating parameter node identification: Identify the operating parameters of the electric water heater, such as temperature, water flow, current, etc., and use these parameters as nodes in the knowledge graph to monitor the real-time status of the device.

[0062] Fault type node identification: Analyze historical fault data to identify common fault types, such as "temperature abnormality", "heater failure", "low water flow", etc., and use each fault type as a node in the knowledge graph.

[0063] Equipment structure relationship: By analyzing the structure and function of the electric water heater, the connection relationship between the components is determined. For example, there is a "monitoring" relationship between the "heater" and the "temperature sensor", and there is a "control" relationship between the "control module" and the "heater".

[0064] Parameter-component relationship: Establish connections between operating parameters and related components. For example, there is a "measurement" relationship between the "temperature sensor" and "temperature" nodes, and there is an "influence" relationship between the "water pump" and "water flow" nodes.

[0065] Fault-component relationship: Identify the cause-effect relationship between each fault type and the component. For example, the "abnormal temperature" fault may be directly related to the "heater", and the "low water flow" fault may be related to the "water pump".

[0066] Fault-parameter relationship: Determine the relationship between the fault type and the operating parameters. For example, the "abnormal temperature" fault has an "abnormal indication" relationship with the "temperature" node, and the "low water flow" fault has a "cause" relationship with the "water flow" node.

[0067] Relationship weight calculation: Based on historical fault data and component health status, the relationship strength between nodes is evaluated and a weight is assigned to each relationship. For example, if the effect of "heater" on "temperature anomaly" occurs frequently, the system can assign a higher weight to the relationship.

[0068] Relationship directionality definition: Define the directionality of the relationship between nodes to more accurately reflect the fault propagation path. For example, the relationship from "control module" to "heater" is unidirectional, while the relationship from "temperature" to "temperature anomaly" may be bidirectional, indicating that the two affect each other.

[0069] Graph database storage: Store all nodes and relationships in a graph database (such as Neo4j) to ensure that each node and relationship has a clear connection for subsequent query and reasoning.

[0070] Relationship update mechanism: Establish a dynamic update mechanism so that when new components, parameters or fault information are added, the nodes and relationships in the knowledge graph can be automatically updated to maintain the real-time and accuracy of the data.

[0071] Based on historical fault data and component health status, the strength of the relationship between nodes is evaluated and a weight is assigned to each relationship, including the following steps:

[0072] Collect the historical fault records of electric water heaters, including fault type, occurrence time, related components and fault description, and obtain the simultaneous fault frequency and health status correlation coefficient between each node, and calculate the relationship strength between nodes. The expression is:

[0073] Where S(i,j) is the strength of the relationship between node i and node j, F(i,j) is the frequency of simultaneous failures between node i and node j, H(i,j) is the health status correlation coefficient between node i and node j, α and β are adjustment coefficients, and both are greater than 0, and N represents the total failure time;

[0074] Assign a weight to the relationship between node i and node j according to the relationship strength. The expression is:

[0075] W(i,j)=k·S(i,j), where S(i,j) is the strength of the relationship between node i and node j, W(i,j) is the weight of the relationship between node i and node j, and k is the weight ratio coefficient, which is used to adjust the weight range and is usually set to 1.

[0076] The calculation logic of the frequency of simultaneous failures between nodes is as follows: obtain the number of simultaneous failures of nodes within the monitoring period, and divide the number of simultaneous failures of nodes by the monitoring duration to obtain the frequency of simultaneous failures between nodes. The greater the frequency of simultaneous failures between nodes, the greater the strength of the relationship between the nodes.

[0077] The calculation expression of health status correlation coefficient is:

[0078] Where n is the number of time points to compare, H i (g) is the health status score of node i at the gth time point, H j (g) is the health status score of node j at the gth time point, μ i is the mean health status score of node i, μ j is the mean health status score of node j, σ i is the standard deviation of the health status score of node i, σ j The standard deviation of the health status score of node j. In this application, parameter deviation includes but is not limited to temperature deviation, vibration deviation, pressure deviation, current deviation, and water flow deviation. The larger the health status correlation coefficient between nodes, the stronger the relationship between nodes.

[0079] The general calculation expression of the health status score of node i at the gth time point is:

[0080] H i (g)=w1·P1(g)+w2·P2(g)+w3·P3(g)+…+w n ·P n (g), where P n (g) represents the deviation of each parameter at the gth time point, w n To correspond to the parameter deviation weight, the health status score of node j at the g-th time point is the same as above, and this application will not go into details.

[0081] Use natural language processing technology to extract entities from the text records of log information, such as equipment component names, fault types, and related parameters, including the following steps:

[0082] Remove useless characters, special symbols, punctuation marks and other noise from the log text to ensure that the text is clean and standardized. Use word segmentation tools to split the text into single words or phrases (such as "heater", "temperature abnormality") to facilitate subsequent entity recognition. Restore the words in the text to their original form (such as "run" is restored to "run"), and mark the part of speech for each word to facilitate the identification of key information such as nouns.

[0083] According to the characteristics of the log data, use pre-trained NER models (such as BERT, spaCy's NER) or fine-tune training on existing log data to identify entities such as equipment parts, fault types, and parameters. Identify and annotate specific entity categories in the text, such as "part name", "fault type", "operating parameters", etc. For example, "heater" is labeled as "part name" and "temperature abnormality" is labeled as "fault type".

[0084] Build a specialized dictionary for the electric water heater field, including domain terms such as equipment components, fault types, and operating parameters, to improve accuracy during the recognition process. Use the vocabulary in the custom dictionary for matching, correct or supplement the recognition results, and improve the recognition rate of professional terms and domain-specific vocabulary. By analyzing the context of entities in the log text, determine the relationship between entities, especially between multiple entities that appear in the same sentence. For example, if the log mentions "abnormal heater temperature", it can be identified that "heater" and "abnormal temperature" are related. Analyze the co-occurrence frequency of each entity in the log to discover possible implicit relationships or high-frequency fault combinations.

[0085] Use a pre-trained NER model or fine-tune it on existing log data to identify equipment components, fault types, and parameter entities, and identify and label entity categories in the text, including the following steps:

[0086] Get log data related to electric water heaters, including equipment operating status, fault information, etc. For example:

[0087] Device A fails, the temperature sensor fails, and the current temperature is 75°C.

[0088] Label the log data and identify entity categories, for example:

[0089] Equipment components: temperature sensor;

[0090] Fault type: Fault;

[0091] Parameter entity: 75℃;

[0092] Select an existing and trained BERT model, use the labeled data to fine-tune the pre-trained model to improve its recognition ability in specific fields (such as electric water heater log data), and apply the fine-tuned NER model to new log data for entity recognition. For example, for the following text:

[0093] The heater of device A failed at 12:00 and the current was overloaded with a current of 20A.

[0094] The entities in the text will be identified and labeled. The results may be:

[0095] Equipment parts: heater;

[0096] Fault type: Fault;

[0097] Parameter entity: current, 20A;

[0098] Ultimately, in this way, key entity information can be effectively extracted from device logs to facilitate subsequent fault analysis and decision support.

[0099] By analyzing the context of entities in log text, the relationship between entities is determined, including the following steps:

[0100] Extract relevant entities from the log text, such as equipment components, fault types, and parameters. Assume that there is the following log:

[0101] The temperature sensor of device C failed at 12:00 and the current temperature was 95°C, causing the heater to fail to work.

[0102] Analyze the contextual relationship of the extracted entities in the text. Use natural language processing techniques (such as dependency parsing or word vector models) to understand the semantic relationship between entities;

[0103] Example analysis: In the sentence, "temperature sensor" is followed by "failed", indicating that there is a problem with the sensor. "Caused the heater to fail to work" indicates that the failure of the temperature sensor affected the normal operation of the heater. Based on the context information, the relationship type between entities is determined (such as causal relationship, dependency relationship, etc.);

[0104] Relationship example: From the context analysis, the relationship between "temperature sensor" and "fault" is "fault exists". Judging from the context, "temperature sensor fault" causes "heater not to work", so it can be considered that there is an "influence" relationship between "temperature sensor" and "heater".

[0105] Through semantic analysis and pattern matching algorithms, the relationship between entities is extracted from equipment operating parameters and maintenance records, and the causal relationship between components, faults and operating parameters is identified, including the following steps:

[0106] Causal pattern definition: Based on the knowledge in the field of fault diagnosis, a common causal pattern library is constructed, such as "X abnormality leads to Y fault" or "Z component damage causes X abnormality".

[0107] Pattern library expansion: Combine historical maintenance records to identify and summarize common fault cause patterns, and continuously improve the relationship pattern library to cover more causal relationship types.

[0108] Dependency parsing: Dependency parsing is performed on text records to identify the grammatical structure between entities to determine the relationship between components such as subject, predicate, and object. Dependency analysis helps to determine the specific semantic roles of cause and effect in causal relationships.

[0109] Semantic similarity calculation: By calculating the semantic similarity of different entities in the text, similar or related entities are identified and the potential relationship between them is analyzed. For example, "temperature rise" and "temperature abnormality" may have high similarity and can be classified as a causal pair under the same relationship mode.

[0110] Regular expression matching: Use regular expressions to match text patterns and extract entity pairs that match the preset causal relationship pattern. For example, "low water flow leads to overheating of the heater" matches the "low X leads to overheating of Y" pattern, and the causal relationship between "low water flow" and "overheating of the heater" can be extracted.

[0111] Rule-based relationship extraction: Combine dependency analysis and pattern matching results to extract qualified relationship pairs. Determine the direction and type of relationship between entities through preset rules. For example, "monitoring anomalies" indicates a direct association between the monitoring component and the fault type.

[0112] Integrate real-time operation data, historical fault data and maintenance records, and combine the relationships between various types of data to build a comprehensive fault knowledge graph, including the following steps:

[0113] Entity standardization mapping: Map the entities involved in each data set (such as components, parameters, fault types, etc.) and unify them into the same format or representation. For example, the names describing the same component in different records are standardized into a consistent format.

[0114] Data table connection: Connect real-time operation data, fault data and maintenance records through key fields such as timestamp, device ID or component name to ensure that all data can be associated with specific equipment and fault instances.

[0115] Relationship analysis: Based on the interaction and co-occurrence of various data, the relationship between various entities is established to identify common component-fault and parameter-fault relationships. For example, the relationship between "heater abnormality" and "temperature rise".

[0116] Node and relationship definition: Entities such as equipment components, operating parameters, fault types, and maintenance measures are defined as nodes in the knowledge graph, and the relationships between components, between components and faults, and between faults and maintenance measures are defined as edges in the knowledge graph.

[0117] Knowledge graph instantiation: Based on the integrated data, each entity is instantiated and added to the graph. For example, the specific time points of "heater" and "temperature anomaly" are added to the graph as nodes.

[0118] Initial relationship construction: Use a graph database (such as Neo4j) to gradually add nodes and relationships to form a preliminary knowledge graph structure to ensure the queryability of the data.

[0119] Cross-modal fusion: Combine different data types (such as sensor data and text maintenance records) and establish a cross-modal association network by analyzing the association between operating parameters and fault records.

[0120] Similarity calculation: Use similarity measurement methods (such as cosine similarity) to match entities and infer relationships between different data modalities, identify different manifestations of the same device, component or fault, and integrate their relationships.

[0121] Complex relationship expansion: Based on the association rule mining algorithm, potential relationships between components, fault associations, etc. are discovered and added to the knowledge graph to improve the relationship network.

[0122] Graph structure analysis: Through graph structure analysis, isolated nodes, weakly connected nodes, etc. in the graph are detected to ensure the integrity and consistency of the knowledge graph.

[0123] Combining different data types, by analyzing the association between operating parameters and fault records, a cross-modal association network is established, and similarity measurement methods are used to match entities and infer relationships between different data modalities, identify different manifestations of the same equipment, component or fault, and integrate their relationships. Specifically:

[0124] Calculate the similarity between the operating parameters and the fault records. For example, for the temperature data of the heater and the fault conditions (such as overheating) in the fault record, calculate their similarity through cosine similarity. This method belongs to the prior art and will not be described in detail in this application.

[0125] The identified entities and the calculated similarity relations are integrated to form a network structure, with nodes: heater, temperature, fault code 123; edges: similarity relations between temperature and fault, and similar entities and their relations are fused. For example, if "heater fault" is recorded in different forms in different logs (such as "heater overheating" and "heater failure"), they are classified as the same fault type through similarity measurement and contextual relations.

[0126] Based on the association rule mining algorithm, potential component relationships and fault association relationships are discovered and added to the knowledge graph to improve the relationship network. Through graph structure analysis, isolated nodes and weakly connected nodes in the graph are detected, including the following steps:

[0127] The Apriori association rule mining algorithm is used to discover potential component and fault association relationships from the data. For example, the discovery rules are as follows:

[0128] {Heater Failure} {Temperature sensor failure} (support: 0.7, confidence: 0.9);

[0129] {Abnormal pressure} {heater failure} (support: 0.6, confidence: 0.8);

[0130] Based on the mined rules, nodes (equipment components, fault types) and relationships (associations between faults) in the knowledge graph are constructed;

[0131] Nodes: heater, temperature sensor, pressure;

[0132] Relationship: heater failure → temperature sensor failure, abnormal pressure → heater failure;

[0133] Detect isolated and weakly connected nodes:

[0134] Orphan Node: A node that has no connections, for example if a component does not appear in any failure records.

[0135] Weakly connected nodes: nodes with fewer connections or whose connected edges have smaller weights.

[0136] Analysis method: Use graph analysis algorithms (such as degree centrality and clustering coefficient) to evaluate the importance of nodes.

[0137] Isolated Node Example: If "Water Level Sensor" is a node and has no connections, it is an isolated node.

[0138] Example of a weakly connected node: If a Stress node is only connected to one faulty node and the connection weight is low, then the node is a weakly connected node.

[0139] Based on the real-time data stream of the Internet of Things, the nodes and relationships in the knowledge graph are dynamically updated. For example, when new fault information is added, the new fault node and its associated relationship are added to the knowledge graph, including the following steps:

[0140] Identify abnormal data in the data stream and determine whether there is new fault information. For example, if the sensor detects that the temperature exceeds the normal range, anomaly detection is triggered.

[0141] Fault feature identification: Based on the detected abnormal features, the corresponding fault type and component location are analyzed to determine the detailed information of the new fault.

[0142] Fault node generation: Create a new fault node in the knowledge graph and annotate the node attributes (such as fault type, affected components, abnormal parameter values, etc.) based on the fault characteristics.

[0143] Relationship construction and expansion: Generate new relationships based on fault characteristics, connect new fault nodes with related equipment component nodes and operating parameter nodes, so that the association between new faults and existing nodes can be reflected in the knowledge graph.

[0144] Node and relationship merging: Check whether the new nodes and relationships are repeated or similar to the information in the existing graph. If repeated or similar relationships are found, merge or update them. For example, associate the newly detected "temperature anomaly" fault with the existing temperature node.

[0145] Consistency verification: Through the constraints and verification mechanism of the graph database, ensure that the newly added nodes and relationships meet the consistency requirements of the graph structure, and avoid destroying the logical integrity of the graph due to redundant information or unreasonable relationships.

[0146] Using graph embedding algorithms to embed nodes and relationships in knowledge graphs into low-dimensional space includes the following steps:

[0147] Ensure that the nodes (such as equipment components, fault types, operating parameters, etc.) and relationships (such as causal relationships, association relationships) in the knowledge graph have been constructed and stored in the graph database. Extract graph structure data from the graph database, including node lists, edge lists and their attributes, for subsequent graph embedding processing.

[0148] Generate node sequences through random walks, and then use the Skip-Gram model for node embedding, which can effectively capture the similarity and structural information between nodes. Set the parameters of random walks according to the selected algorithm, such as walk step length, number of walks, etc. For Node2Vec, set the walk strategy parameters (such as p and q) to control the regression and exploratory nature of the walk. Perform random walks in the graph to generate a series of node sequences. These sequences will be used in the subsequent embedding learning process.

[0149] The generated node sequence is used to train the Skip-Gram model to learn the embedded representation of the node in the low-dimensional space. The model predicts the target node based on the context node, thereby generating a low-dimensional vector of the node. In order to improve the training efficiency, negative sampling technology is used to select a small number of negative samples for optimization to speed up the model convergence.

[0150] After training is complete, the embedding vector of each node is extracted from the model to obtain the representation of the node in a low-dimensional space. According to the specific application requirements, the appropriate embedding dimension (such as 50 dimensions, 100 dimensions, etc.) is selected to balance the model complexity and expressiveness. The embedding representation of the relationship is generated by operating the embedding vectors of related nodes (such as addition or multiplication). For example, the embedding vectors of node A and node B are used to calculate the vector representation of the relationship between them.

[0151] Generate node sequences through random walks, and then use the Skip-Gram model for node embedding, which can effectively capture the similarity and structural information between nodes. Set the parameters of random walks according to the selected algorithm, such as walk step length, number of walks, etc. For Node2Vec, set the walk strategy parameters (such as p and q) to control the regression and exploratory nature of the walk. Perform random walks in the graph to generate a series of node sequences. These sequences will be used in the subsequent embedding learning process, which includes the following steps:

[0152] Knowledge graph, including equipment components and their fault relationships. For example:

[0153] Nodes: heater, temperature sensor, pressure sensor, fault;

[0154] Side: Heater failure → temperature sensor failure, abnormal pressure → heater failure;

[0155] Select the walk parameters:

[0156] Step length (walk_length): The number of steps in each random walk, for example, set it to 10.

[0157] Number of walks (num_walks): The number of walks for each node. For example, 5 walk sequences are generated for each node.

[0158] Node2Vec parameters:

[0159] p (return parameter): controls the regressivity of the walk, for example, set it to 0.5.

[0160] q (exploration parameter): controls the exploratory nature of the walk, for example, set it to 2.

[0161] Starting from each node, a random walk is performed based on the set parameters. The Node2Vec strategy is used to control the walk behavior.

[0162] Example: Starting from the "heater" node, a walk might produce the following sequence:

[0163] Heater → temperature sensor → heater → pressure sensor → fault.

[0164] Repeat the above steps to generate multiple node sequences. For example:

[0165] Sequence 1: [heater, temperature sensor, fault];

[0166] Sequence 2: [pressure sensor, heater, fault];

[0167] Sequence 3: [temperature sensor, heater, fault];

[0168] Input node sequence: Input the generated node sequence into the Skip-Gram model.

[0169] Training model: Use the Skip-Gram model to learn the vector representation of nodes to capture the similarity and structural information between nodes.

[0170] Output embedding: Each node will be mapped into a low-dimensional vector space, representing its semantic relationship in the graph.

[0171] The generated node sequence is used to train the Skip-Gram model to learn the embedded representation of the node in the low-dimensional space. The model predicts the target node based on the context node, thereby generating a low-dimensional vector of the node. In order to improve the training efficiency, the negative sampling technology is used to select a small number of negative samples for optimization to speed up the model convergence, including the following steps:

[0172] The Skip-Gram model takes context nodes as input and target nodes as output. For each node, the model learns its representation in the context.

[0173] Context Window Size: Set the context window size (such as 2) to determine the number of context nodes considered when predicting the target node.

[0174] Selecting negative samples: In each training, a small number of negative samples (usually 5-20) are selected for each target node, which do not appear in the context.

[0175] Negative sample selection method: Based on the global node frequency, some irrelevant nodes can be randomly selected as negative samples. Example:

[0176] For the target node “fault”, the context nodes may be “heater” and “temperature sensor”, and the negative samples may be randomly selected “water level sensor”, “pump”, etc.

[0177] After training, the model will generate a low-dimensional vector representation for each node, which can capture the similarity and structure information between nodes:

[0178] The embedding representation of the heater might be [0.2, -0.5, 0.1], while the embedding representation of the temperature sensor might be [0.3, -0.4, 0.2].

[0179] Reasoning is performed through the rule engine in the knowledge graph (such as Cypher query language) to deduce possible causes of failures, including the following steps:

[0180] Choose a suitable rule engine, such as Neo4j's Cypher query language. Cypher allows complex graph data queries and reasoning through a graph query language. If using Neo4j, make sure the database is installed and configured correctly so that it can connect and execute queries;

[0181] Write the corresponding Cypher query according to the defined inference rules. For example:

[0182] MATCH(a:Component)-[:CAUSES]->(b:Fault);

[0183] WHERE - a.status = 'faulty';

[0184] RETURN-b.name,b.description;

[0185] Parameterize the query based on real-time data or specific conditions to flexibly adjust the query content. For example, query a specific fault type or the fault condition of a specific component;

[0186] Execute the written Cypher query in the knowledge graph to obtain qualified fault causes or potential faults, process the query results, and sort out possible fault causes and related information, including fault type, related components, influencing parameters, etc.

[0187] Combine graph data and IoT sensor data to cross-modally fuse fault phenomena, parameter changes, and historical records to obtain more accurate fault cause inference results, including the following steps:

[0188] Synchronize the data from IoT sensors with the knowledge graph data to ensure consistency in timestamps, formats, units, etc. Clean and denoise the data, filter out irrelevant information, extract important features from IoT sensor data (such as changes in parameters such as temperature, pressure, and current), and normalize the node attributes in the knowledge graph to ensure comparability during cross-modal fusion;

[0189] The time series features of sensor data are integrated with the attribute data of knowledge graph nodes to construct the feature vector of graph nodes. For example, the temperature change when a fault occurs is combined with the attribute data of related components to form the cross-modal features of the fault node. The sensor data and graph data are pattern matched to combine similar features. For example, if temperature and current anomalies occur at the same time, determine whether they are consistent with the existing historical fault mode;

[0190] Use cosine similarity to calculate the cross-modal similarity between cross-modal feature vectors, measure the matching degree between the current fault features and the historical records, assign weights according to the importance of different modalities (sensor data and knowledge graphs), and integrate similarity scores to generate a comprehensive similarity index to guide fault cause reasoning;

[0191] According to the calculated cross-modal similarity, the current fault characteristics are matched with the historical fault patterns to determine the most likely fault cause.

[0192] The time series features of sensor data are integrated with the attribute data of knowledge graph nodes to construct feature vectors of graph nodes, perform pattern matching on sensor data and graph data, and combine similar features, including the following steps:

[0193] Collect real-time sensor data from IoT devices, such as temperature, pressure, humidity, etc. Temperature sensor data: 20.5, 21.0, 21.5, 22.0, 22.5 (time series);

[0194] Extract features from temperature sensor data:

[0195] Mean: 21.1

[0196] Standard deviation: 0.5;

[0197] Maximum value: 22.5;

[0198] Minimum value: 20.5.

[0199] Extract attribute data related to equipment or components from the knowledge graph, such as status, fault type, component characteristics, etc.

[0200] For a Heater node, properties might include:

[0201] Status: Normal;

[0202] Fault type: No fault;

[0203] Service life: 3 years.

[0204] The extracted sensor features are integrated with the knowledge graph node attributes to form a new feature vector;

[0205] Heater node feature vector: Feature vector = [mean, standard deviation, maximum, minimum, state, fault type, service life] = [21.1, 0.5, 22.5, 20.5, normal, no fault, 3];

[0206] Assume there are two feature vectors: Feature vector A (heater): 21.1, 0.5, 22.5, 20.5, normal, no fault, 3;

[0207] Feature vector B (temperature sensor): 22.0, 0.3, 22.5, 21.0, normal, no fault, 2; identify similar feature combinations (such as the same state and fault type).

[0208] The cosine similarity is used to calculate the cross-modal similarity between cross-modal feature vectors, measure the matching degree between the current fault features and the historical records, assign weights according to the importance of different modalities, integrate the similarity scores to generate a comprehensive similarity index, and guide the fault cause reasoning, including the following steps:

[0209] Current fault feature vector: 0.8, 0.6, 0.9 (heater fault feature);

[0210] Historical record feature vector 1: 0.7, 0.5, 0.8 (historical failure 1);

[0211] Historical record feature vector 2: 0.9, 0.6, 0.9 (historical failure 2);

[0212] For the current fault feature vector and the historical record feature vector 1: a similarity score is calculated, assuming it is 0.95.

[0213] Determine the weight of each modality based on business scenarios or historical data analysis.

[0214] Example weight assignment:

[0215] Sensor data weight: 0.6;

[0216] Knowledge graph weight: 0.4;

[0217] The sensor similarity and the knowledge graph similarity are weighted to obtain the comprehensive similarity. Assume that the cosine similarity of the historical record feature vector 2 is 0.90.

[0218] Comprehensive similarity calculation:

[0219] Comprehensive similarity = 0.6*0.95+0.4*0.90=0.93.

[0220] If the comprehensive similarity is greater than or equal to the preset similarity threshold, it means that the current fault is highly matched with the historical record, and the possible cause of the fault can be inferred. If the comprehensive similarity is less than the preset similarity threshold, further analysis or consideration of other potential faults is required;

[0221] Through the above steps, cosine similarity is used to calculate the similarity between cross-modal feature vectors, integrate the importance of different modes, and generate a comprehensive similarity index to guide fault cause reasoning. This method can effectively improve the accuracy and efficiency of fault diagnosis.

[0222] According to the calculated cross-modal similarity, the current fault feature is matched with the historical fault mode to determine the cause of the fault, including the following steps:

[0223] Current fault features extracted from sensors and knowledge graphs; Current fault feature vector: 0.85, 0.65, 0.9 (corresponding to heater failure);

[0224] Calculate the similarity scores between the current fault signature and the historical fault signature: Similarity with historical fault mode 1: 0.92; Similarity with historical fault mode 2: 0.88;

[0225] According to the similarity score, historical fault modes that are similar to the current fault characteristics are selected: Historical fault mode 1: feature vector 0.80, 0.60, 0.85, fault cause: temperature sensor failure; Historical fault mode 2: feature vector 0.75, 0.65, 0.80, fault cause: heating element damage.

[0226] Based on the similarity score, the most matching historical fault mode is determined. The similarity between the current fault feature and historical fault mode 1 is 0.92, which is a high match. The similarity between the current fault feature and historical fault mode 2 is 0.88, which is a slightly lower match.

[0227] Since the current fault characteristics are highly similar to the historical fault mode 1, it is inferred that the current fault cause may be "temperature sensor failure". Combined with historical data, decide whether further troubleshooting or repair is needed.

[0228] Through the above steps, the calculated cross-modal similarity is used to match the current fault characteristics with the historical fault mode, and finally determine the cause of the fault. This process improves the efficiency of fault diagnosis, helps to quickly locate problems, and reduces downtime.

[0229] Using graph visualization tools (such as Neo4j-Bloom, Graph-X) to display the knowledge graph includes the following steps:

[0230] Make sure that graph database tools (such as Neo4j) and visualization tools (such as Neo4jBloom or Graph-X) are installed and configured correctly. Configure the graph database connection and confirm that the permissions are set correctly. Load the knowledge graph data into the graph database. Usually includes nodes, relationships and their properties. For Neo4j, you can use CSV files, JSON or API to import data.

[0231] Write a Cypher query to select the nodes and relationships to be displayed based on the display requirements. For example, you can filter out the corresponding graph structure based on a specific fault type, time range, or component, query it in the graph database, and check the results. Confirm that the query results meet expectations and ensure that all nodes and relationships required for display are included.

[0232] Select the appropriate layout method (such as force-directed layout, tree layout, etc.) in the visualization tool to clearly display the node relationship. Different layout methods help to highlight different structural features. Use different colors, shapes or sizes to distinguish according to the node type (such as equipment components, operating parameters, fault types) to facilitate intuitive understanding of the graph information. Set the color and line type of the edge to indicate the type or weight of different relationships.

[0233] Use the tool's built-in filtering function to filter by node attributes or relationship types. For example, focus on a specific fault type or directly related nodes of a component, and filter out irrelevant information to improve clarity. For large knowledge graphs, you can use the aggregation function to merge similar nodes, or expand the aggregated nodes as needed to display a more detailed hierarchy and relationships.

[0234] Add clear labels to each node (such as "temperature sensor", "heater", "water leak", etc.) to help viewers understand the type and role of the node. Add descriptive information to each edge, such as the relationship type and weight value, displayed in the visualization interface to help explain the meaning of the relationship (such as "causes", "associated with", or "monitors", etc.).

[0235] If the knowledge graph needs to be updated during use, the real-time update function can be set to enable the graph visualization tool to dynamically load the latest nodes and relationships. For knowledge graphs containing time series information, a timeline control can be added to view graph structure changes at different time points to identify historical and current failure modes.

[0236] Embodiment 3: The device fault information sharing system based on the Internet of Things described in this embodiment includes a data collection module, a knowledge graph construction module, a dynamic update module, a derivation module, and a graph display module;

[0237] Data collection module: collects log information of faulty equipment through IoT sensors, takes the equipment components, operating parameters and fault types as nodes, obtains the node relationship between each node, and sends the node information and log information to the knowledge graph construction module;

[0238] Knowledge graph construction module: Use natural language processing technology to extract entities from the text records of log information, such as equipment component names, fault types, and related parameters. Through semantic analysis and pattern matching algorithms, extract the relationship between entities from equipment operating parameters and maintenance records, identify the causal relationship between components, faults, and operating parameters, integrate real-time operating data, historical fault data, and maintenance records, and combine the associations between various types of data to build a comprehensive fault knowledge graph, which is sent to the dynamic update module.

[0239] Dynamic update module: Based on the real-time data stream of the Internet of Things, the nodes and relationships in the knowledge graph are dynamically updated. For example, when new fault information is added, the new fault node and its associated relationship are added to the knowledge graph, and the dynamically updated knowledge graph is sent to the derivation module;

[0240] Inference module: Use graph embedding algorithm to embed nodes and relationships in the knowledge graph into low-dimensional space, perform reasoning through the rule engine in the knowledge graph (such as Cypher query language), deduce possible fault causes, and send the derivation results to the graph display module;

[0241] Graph display module: Combine graph data and IoT sensor data to cross-modally fuse fault phenomena, parameter changes, and historical records to obtain more accurate fault cause inference results. Use graph visualization tools (such as Neo4j-Bloom and Graph-X) to display knowledge graphs, so that maintenance personnel can intuitively view the fault associations and causal relationships between the various components of the electric water heater. After the fault is handled, feedback from maintenance personnel is collected to correct erroneous relationships in the knowledge graph or supplement new fault modes.

[0242] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0243] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

[0244] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0245] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0246] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for sharing equipment fault information based on the Internet of Things, characterized in that: The sharing method comprises the following steps: Collect log information of faulty equipment through IoT sensors, use equipment components, operating parameters, and fault types as nodes, obtain node relationships between nodes, and use natural language processing technology to extract entities from text records of log information; Through semantic analysis and pattern matching algorithms, the relationship between entities is extracted from equipment operating parameters and maintenance records, the causal relationship between components, faults and operating parameters is identified, and real-time operating data, historical fault data and maintenance records are integrated. Combined with the association between various types of data, a fault knowledge graph is constructed. Based on the real-time data stream of the Internet of Things, the nodes and relationships in the knowledge graph are dynamically updated. The nodes and relationships in the knowledge graph are embedded into a low-dimensional space using a graph embedding algorithm. Reasoning is performed through the rule engine in the knowledge graph to deduce the cause of the fault. Combined with graph data and IoT sensor data, the fault phenomenon, parameter changes, and historical records are cross-modally fused to obtain the fault cause reasoning results, and the knowledge graph is displayed using graph visualization tools.

2. The method for sharing device fault information based on the Internet of Things according to claim 1, characterized in that: The components, operating parameters and fault types of the equipment are taken as nodes, and the node relationship between the nodes is obtained, including the following steps: The components of the electric water heater include heater, temperature sensor, water pump, and control module, and each component is regarded as an independent node; Identify the operating parameters of the electric water heater, including temperature, water flow, and current, and use the operating parameters as nodes in the knowledge graph; Analyze historical fault data, determine the fault type, and use each fault type as a node in the knowledge graph; By analyzing the structure and function of the electric water heater, the connection relationship between components is obtained, the operating parameters are connected with related components, and the causal relationship between each fault type and the component is identified, and the relationship between the fault type and the operating parameters is obtained; Based on historical failure data and component health status, the strength of the relationship between nodes is evaluated and a weight is assigned to each relationship.

3. The method for sharing equipment failure information based on the Internet of Things according to claim 2 is characterized in that: Based on historical fault data and component health status, the strength of the relationship between nodes is evaluated and a weight is assigned to each relationship, including the following steps: Collect the historical fault records of electric water heaters, including fault type, occurrence time, related components and fault description, and obtain the simultaneous fault frequency and health status correlation coefficient between each node, and calculate the relationship strength between nodes. The expression is: Where S(i,j) is the strength of the relationship between node i and node j, F(i,j) is the frequency of simultaneous failures between node i and node j, H(i,j) is the health status correlation coefficient between node i and node j, α and β are adjustment coefficients, and both are greater than 0, and N represents the total failure time; Assign a weight to the relationship between node i and node j according to the relationship strength. The expression is: W(i,j)=k·S(i,j), where S(i,j) is the strength of the relationship between node i and node j, W(i,j) is the weight of the relationship between node i and node j, and k is the weight ratio coefficient.

4. The method for sharing equipment failure information based on the Internet of Things according to claim 3 is characterized in that: Combine graph data and IoT sensor data to cross-modally fuse fault phenomena, parameter changes, and historical records to obtain fault cause inference results, including the following steps: Synchronize data from IoT sensors with knowledge graph data and normalize node attributes in the knowledge graph; The time series features of sensor data are integrated with the attribute data of knowledge graph nodes to construct feature vectors of graph nodes, perform pattern matching on sensor data and graph data, and combine similar features; Use cosine similarity to calculate the cross-modal similarity between cross-modal feature vectors, measure the matching degree between the current fault features and the historical records, assign weights according to the importance of different modalities, and integrate similarity scores to generate a comprehensive similarity index to guide fault cause reasoning; According to the calculated cross-modal similarity, the current fault characteristics are matched with the historical fault patterns to determine the cause of the fault.

5. The method for sharing equipment failure information based on the Internet of Things according to claim 4 is characterized in that: The calculation expression of the health status correlation coefficient is: Where n is the number of time points to compare, H i (g) is the health status score of node i at the gth time point, H j (g) is the health status score of node j at the gth time point, μ i is the mean health status score of node i, μ j is the mean health status score of node j, σ i is the standard deviation of the health status score of node i, σ j The standard deviation of the health status score of node j, parameter deviation includes but is not limited to temperature deviation, vibration deviation, pressure deviation, current deviation and water flow deviation. The general calculation expression of the health status score of node i at the gth time point is: H i (g)=w1·P1(g)+w2·P2(g)+w3·P3(g)+…+w n ·P n (g), where P n (g) represents the deviation of each parameter at the gth time point, w n is the corresponding parameter deviation weight.

6. The method for sharing equipment failure information based on the Internet of Things according to claim 5 is characterized in that: Integrate real-time operation data, historical fault data and maintenance records, and combine the associations between various types of data to build a fault knowledge graph, including the following steps: Map the entities involved in each data set and unify them into the same format or representation, connecting real-time operation data, fault data and maintenance records through timestamps, equipment IDs or component names; Based on the interaction and co-occurrence relationship of various data, the association relationship between various entities is established to identify the component-fault and parameter-fault relationship; Based on the integrated data, each entity is instantiated and added to the graph, and nodes and relationships are gradually added using the graph database to form a preliminary knowledge graph structure; Combining different data types, by analyzing the association between operating parameters and fault records, a cross-modal association network is established, and similarity measurement methods are used to match entities and infer relationships between different data modalities, identify different manifestations of the same equipment, component or fault, and integrate their relationships; Based on the association rule mining algorithm, potential relationships between components and fault associations are discovered and added to the knowledge graph to improve the relationship network. Through graph structure analysis, isolated nodes and weakly connected nodes in the graph are detected.

7. The method for sharing equipment failure information based on the Internet of Things according to claim 6 is characterized in that: Using natural language processing technology to extract entities from the text records of log information includes the following steps: Remove useless characters, special symbols, and punctuation noise from the log text, use the word segmentation tool to split the text into single words or phrases, and mark the part of speech for each word; Use pre-trained NER models or fine-tune them on existing log data to identify equipment components, fault types, and parameter entities, and identify and label entity categories in text; Construct a dictionary in the field of electric water heaters, including vocabulary in the fields of equipment components, fault types, and operating parameters. Use the vocabulary in the dictionary for matching, correct or supplement the recognition results, and determine the relationship between entities by analyzing the context of the entities in the log text.

8. An equipment fault information sharing system based on the Internet of Things, used to implement the sharing method according to any one of claims 1 to 7, characterized in that: It includes data collection module, knowledge graph construction module, dynamic update module, derivation module and graph display module; Data collection module: collects log information of faulty equipment through IoT sensors, takes equipment components, operating parameters, and fault types as nodes, and obtains the node relationships between nodes; Knowledge graph construction module: Use natural language processing technology to extract entities from the text records of log information, extract the relationship between entities from equipment operating parameters and maintenance records through semantic analysis and pattern matching algorithms, identify the causal relationship between various components, faults and operating parameters, integrate real-time operating data, historical fault data and maintenance records, and combine the associations between various types of data to build a fault knowledge graph; Dynamic update module: Based on the real-time data stream of the Internet of Things, dynamically update the nodes and relationships in the knowledge graph; Inference module: Use graph embedding algorithm to embed nodes and relationships in the knowledge graph into low-dimensional space, perform reasoning through the rule engine in the knowledge graph, and deduce the cause of the fault; Graph display module: Combine graph data and IoT sensor data to cross-modally fuse fault phenomena, parameter changes, and historical records, obtain fault cause inference results, and use graph visualization tools to display knowledge graphs.

Images