Internet of Things-based Device Fault Information Sharing System and Method

Abstract

The present invention discloses an Internet of Things-based device fault information sharing system and method, which relates to the technical field of device fault sharing. It identifies the causal relationships among various components, faults, and operating parameters, integrates real-time operating data, historical fault data, and maintenance records, constructs a fault knowledge graph in combination with the correlation relationships among various types of data, and performs reasoning through the rule engine in the knowledge graph to deduce possible fault causes. It performs cross-modal fusion on fault phenomena, parameter changes, and historical records to obtain more accurate fault cause reasoning results. After associating the components, operating parameters, and fault types of an electric water heater, the sharing system constructs a comprehensive fault knowledge graph, so that when the electric water heater fails, it can reason and display the components that may be abnormal to maintenance personnel, which not only helps improve the maintenance efficiency but also ensures the safety of the electric water heater after maintenance.

Description

Technical Field

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

[0002] As a commonly used high-power electrical appliance device in households, the electric water heater is closely related to daily life. The stability and safety of its operation are crucial. Due to factors such as high temperature, high-pressure water, and electricity, failures of the electric water heater may lead to risks such as electric leakage, overheating, and even explosion. Therefore, an effective monitoring and early warning mechanism is required. The sharing system aims to utilize Internet of Things technology to monitor and analyze the operation status of the electric water heater in real time, and when a failure or potential failure occurs, quickly share the information with users, maintenance personnel, and manufacturers.

[0003] The existing technology has the following deficiencies:

[0004] When the electric water heater is in operation, it involves monitoring of water power, electricity, and mechanical components. When a failure occurs in the electric water heater, the existing sharing system can only display the failure area and cause to the maintenance personnel. However, due to certain correlation relationships between the components of the electric water heater, the sharing system cannot infer possible abnormalities based on the current failure cause. When manually checking, on the one hand, it will reduce the maintenance efficiency of the electric water heater, and on the other hand, problems such as misdetection or missed detection may occur, resulting in potential safety hazards in the subsequent use of the electric water heater.

[0005] The present invention provides an equipment failure information sharing system and method based on the Internet of Things. By associating the components, operating parameters, and failure types of the electric water heater, a comprehensive failure knowledge graph is constructed, so that when a failure occurs in the electric water heater, it can be inferred and the components that may have abnormalities can be shown to the maintenance personnel, which not only helps to improve the maintenance efficiency but also ensures the safety of the electric water heater during subsequent use. Summary of the Invention

[0006] The purpose of the present invention is to provide an equipment failure information sharing system and method based on the Internet of Things to solve the deficiencies in the background art.

[0007] To achieve the above purpose, the present invention provides the following technical solutions: An equipment failure information sharing system and method based on the Internet of Things, and the sharing method includes the following steps:

[0008] Collect the log information of the failed equipment through Internet of Things sensors, use the components, operating parameters, and failure types of the equipment as nodes, obtain the node relationships between each node, and extract entities from the text records of the log information using natural language processing technology;

[0009] Extract the relationships between entities from the device operation parameters and maintenance records through semantic analysis and pattern matching algorithms, identify the causal relationships among components, faults, and operation parameters, integrate real-time operation data, historical fault data, and maintenance records, and construct a fault knowledge graph by combining the correlation relationships among various types of data;

[0010] Based on the real-time data stream of the Internet of Things, dynamically update the nodes and relationships in 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 to deduce the cause of the fault, combine the graph data and the Internet of Things sensor data, perform cross-modal fusion of the fault phenomenon, parameter changes, and historical records to obtain the reasoning result of the fault cause, and use the graph visualization tool to display the knowledge graph.

[0011] In a preferred embodiment, take the components, operation parameters, and fault types of the device as nodes, and obtain the node relationships between each node, including the following steps:

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

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

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

[0015] By analyzing the structure and function of the electric water heater, obtain the connection relationships between components, establish connections between operation parameters and related components, identify the causal relationships between each fault type and components, and obtain the relationships between fault types and operation parameters;

[0016] Based on the historical fault data and the component health status, evaluate the relationship strength between nodes and assign weights to each relationship.

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

[0018] Collect the historical fault records of the electric water heater, including fault types, occurrence times, related components, and fault descriptions. After obtaining the simultaneous fault frequency and the health status correlation coefficient between each node, calculate the relationship strength between nodes. The expression is: Wherein, S(i, j) is the relationship strength between node i and node j, F(i, j) is the simultaneous failure frequency 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, both greater than 0, and N represents the total number of failure times;

[0019] Allocate weights to the relationship between node i and node j according to the relationship strength, and the expression is:

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

[0021] In a preferred embodiment, by combining graph data and Internet of Things sensor data, cross-modal fusion of fault phenomena, parameter changes, and historical records is performed to obtain the reasoning result of the fault cause, including the following steps:

[0022] Synchronize the data from the Internet of Things sensors with the knowledge graph data, and normalize the node attributes in the knowledge graph;

[0023] Fuse the time series features of the sensor data with the attribute data of the knowledge graph nodes, construct the feature vectors of the graph nodes, perform pattern matching on the sensor data and the graph data, and combine the 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 feature and the historical record, allocate weights according to the importance of different modalities, and integrate the similarity scores to generate a comprehensive similarity index to guide the reasoning of the fault cause;

[0025] According to the calculated cross-modal similarity, match the current fault feature with the historical fault mode to determine the fault cause.

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

[0027] Where n is the number of comparison time points, H i (g) is the health status score of node i at the g-th time point, H j (g) is the health status score of node j at the g-th time point, μ i is the mean value of the health status scores of node i, μ j is the mean value of the health status scores of node j, σ i is the standard deviation of the health status scores of node i, σ jThe standard deviation of the health status score of node j, and the parameter deviation includes but is not limited to temperature deviation, vibration deviation, pressure deviation, current deviation, and water flow deviation. The general calculation expression for the health status score of node i at the g-th 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 various parameter deviations at the g-th time point, and w n is the corresponding parameter deviation weight.

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

[0030] Map the entities involved in each dataset to the same format or representation, and connect the real-time operation data, fault data, and maintenance records through timestamps, device IDs, or component names;

[0031] Based on the interaction and co-occurrence relationships of various types of data, establish the correlation relationships between various entities, and identify component-fault and parameter-fault relationships;

[0032] Based on the integrated data, instantiate each entity and add it to the graph, and use a graph database to gradually add nodes and relationships to form a preliminary knowledge graph structure;

[0033] Combined with different data types, by analyzing the correlation relationship between operation parameters and fault records, establish a cross-modal correlation relationship network, and use a similarity measurement method to match and infer the relationships between entities in different data modalities, and identify different manifestations of the same device, component, or fault and fuse their relationships;

[0034] Based on the association rule mining algorithm, discover potential relationships between components and fault correlation relationships, and add them to the knowledge graph to improve the relationship network. Through graph structure analysis, detect isolated nodes and weakly connected nodes in the graph.

[0035] In a preferred embodiment, natural language processing technology is used to extract entities from the text records of log information, including the following steps:

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

[0037] Use a pre-trained NER model or fine-tune and train on existing log data to identify device components, fault types, and parameter entities, and identify and label the entity categories in the text.

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

[0039] An IoT-based device fault information sharing system, including 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: Collect the log information of faulty devices through IoT sensors. Use the components, operating parameters, and fault types of the devices as nodes, and obtain the node relationships between each node.

[0041] Knowledge graph construction module: Use natural language processing technology to extract entities from the text records of log information. Through semantic analysis and pattern matching algorithms, extract the relationships between entities from device operating parameters and maintenance records, identify the causal relationships between each component, fault, and operating parameter, integrate real-time operating data, historical fault data, and maintenance records, and combine the association relationships between various types of data to construct a fault knowledge graph.

[0042] Dynamic update module: Dynamically update the nodes and relationships in the knowledge graph based on the real-time data stream of the IoT.

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

[0044] Graph display module: Combine graph data and IoT sensor data to perform cross-modal fusion of fault phenomena, parameter changes, and historical records, obtain the reasoning results of the cause of the fault, and use a graph visualization tool to display the knowledge graph.

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

[0046] The present invention extracts the relationships between entities from device operation parameters and maintenance records, identifies the causal relationships among various components, faults, and operation parameters, integrates real-time operation data, historical fault data, and maintenance records, combines the correlation relationships among various types of data, constructs a fault knowledge graph, performs reasoning through a rule engine (such as the Cypher query language) in the knowledge graph, deduces possible fault causes, and performs cross-modal fusion of fault phenomena, parameter changes, and historical records to obtain more accurate fault cause reasoning results. After associating the components, operation parameters, and fault types of the electric water heater through the sharing system, a comprehensive fault knowledge graph is constructed, so that when the electric water heater fails, it can be inferred and the components that may be abnormal can be displayed to the maintenance personnel, which not only helps improve the maintenance efficiency but also ensures the safety of the electric water heater after maintenance. Description of the Drawings

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in the present invention, and those of ordinary skill in the art can also obtain other drawings based on these drawings.

[0048] Figure 1 It is a flowchart of the method of the present invention. Detailed Embodiments

[0049] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

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

[0051] The shared system collects the log information of faulty devices through Internet of Things sensors. It takes the components, operating parameters, and fault types of the devices as nodes, obtains the node relationships between each node, and uses natural language processing technology to extract entities from the text records of the log information, such as device component names, fault types, and related parameters. Through semantic analysis and pattern matching algorithms, it extracts the relationships between entities from the device operating parameters and maintenance records, identifies the causal relationships between each component, fault, and operating parameter, integrates real-time operating data, historical fault data, and maintenance records, combines the correlation relationships between various types of data, and constructs a comprehensive fault knowledge graph. Based on the real-time data stream of the Internet of Things, it dynamically updates the nodes and relationships in the knowledge graph. For example, when new fault information is added, the new fault node and its associated relationships are added to the knowledge graph. It uses graph embedding algorithms to embed the nodes and relationships in the knowledge graph into a low-dimensional space, performs reasoning through the rule engine (such as Cypher query language) in the knowledge graph, deduces possible fault causes, combines graph data and Internet of Things sensor data, and performs cross-modal fusion of fault phenomena, parameter changes, and historical records to obtain more accurate fault cause reasoning results. It uses graph visualization tools (such as Neo4j-Bloom, Graph-X) to display the knowledge graph, enabling maintenance personnel to intuitively view the fault associations and causal relationships between the components of the electric water heater. After the fault is processed, it collects the feedback from the maintenance personnel to correct the incorrect relationships in the knowledge graph or supplement new fault patterns.

[0052] This application extracts the relationships between entities from the device operating parameters and maintenance records, identifies the causal relationships between each component, fault, and operating parameter, integrates real-time operating data, historical fault data, and maintenance records, combines the correlation relationships between various types of data, constructs a fault knowledge graph, performs reasoning through the rule engine (such as Cypher query language) in the knowledge graph, deduces possible fault causes, and performs cross-modal fusion of fault phenomena, parameter changes, and historical records to obtain more accurate fault cause reasoning results. After associating the components, operating parameters, and fault types of the electric water heater, the shared system constructs a comprehensive fault knowledge graph, so that when a fault occurs in the electric water heater, it can deduce and display the components that may be abnormal to the maintenance personnel, which not only helps to improve the maintenance efficiency but also ensures the safety of the electric water heater after maintenance.

[0053] Embodiment 2: The shared system collects the log information of faulty devices through Internet of Things sensors, including the following steps:

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

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

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

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

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

[0059] Take the components, operating parameters, and fault types of the device as nodes, and obtain the node relationships between each node, including the following steps:

[0060] Component node identification: Determine the key components of the electric water heater, such as heaters, temperature sensors, water pumps, control modules, etc., and take 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 rate, current, etc., and take 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 determine common fault types, such as "temperature anomaly", "heater fault", "low water flow rate", etc., and take each fault type as a node in the knowledge graph.

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

[0064] Relationship between parameters and components: Establish a connection between the operating parameters and related components. For example, there is a "measurement" relationship between the "temperature sensor" and the "temperature" node, and an "influence" relationship between the "water pump" and the "water flow rate" node.

[0065] Relationship between faults and components: Identify the causal relationship between each fault type and components. For example, the "temperature anomaly" fault may be directly related to the "heater", and the "low water flow rate" fault is related to the "water pump".

[0066] Relationship between faults and parameters: Determine the relationship between fault types and operating parameters. For example, the "temperature anomaly" fault has an "abnormal indication" relationship with the "temperature" node, and the "low water flow" fault has a "causing" relationship with the "water flow" node.

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

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

[0069] Graph database storage: Store all nodes and relationships in a graph database (such as Neo4j), ensuring that each node and relationship has a clear connection for subsequent querying 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 timeliness and accuracy of the data.

[0071] Based on historical fault data and component health status, evaluate the strength of the relationship between nodes and assign weights to each relationship, including the following steps:

[0072] Collect the historical fault records of the electric water heater, including fault types, occurrence times, related components, and fault descriptions. After obtaining the co-occurrence fault frequency and health status correlation coefficient between each node, calculate the strength of the relationship between nodes. The expression is:

[0073] In the formula, S(i,j) is the strength of the relationship between node i and node j, F(i,j) is the co-occurrence fault frequency 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, both greater than 0, and N represents the total number of fault times;

[0074] Assign weights 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). In the formula, S(i,j) is the strength of the relationship between node i and node j, W(i,j) is the relationship weight between node i and node j, and k is the weight ratio coefficient used to adjust the weight range, usually set to 1.

[0076] The calculation logic of the simultaneous failure frequency 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 simultaneous failure frequency between nodes. The greater the simultaneous failure frequency between nodes, the greater the relationship strength between nodes.

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

[0078] In the formula, n is the number of comparison time points, H i (g) is the health status score of node i at the g-th time point, H j (g) is the health status score of node j at the g-th time point, μ i is the mean value of the health status scores of node i, μ j is the mean value of the health status scores of node j, σ i is the standard deviation of the health status scores of node i, σ j is the standard deviation of the health status scores of node j. In this application, the parameter deviation includes but is not limited to temperature deviation, vibration deviation, pressure deviation, current deviation, and water flow deviation, etc. The greater the health status correlation coefficient between nodes, the greater the relationship strength between nodes;

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

[0080] H i (g) = w1·P1(g) + w2·P2(g) + w3·P3(g) + … + w n ·P n (g), in the formula, P n (g) represents each parameter deviation at the g-th time point, w n is the corresponding 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 elaborate further.

[0081] Using natural language processing technology to extract entities from the text records of log information, such as device component names, failure types, and relevant parameters, includes the following steps:

[0082] Remove noises such as useless characters, special symbols, and punctuation marks in the log text to ensure the text is clean and standardized. Use a word segmentation tool to split the text into individual words or phrases (such as "heater", "temperature anomaly") for subsequent entity recognition. Restore the words in the text to their original forms (such as restoring "running" to "run"), and label the part of speech of each word to facilitate the identification of key information such as nouns.

[0083] According to the characteristics of the log data, use a pre-trained NER model (such as BERT, NER of spaCy) or fine-tune the training on the existing log data to identify entities such as device components, fault types, and parameters. Identify and label specific entity categories in the text, such as "component name", "fault type", "operating parameter", etc. For example, "heater" is labeled as "component name", and "temperature anomaly" is labeled as "fault type".

[0084] Build a special dictionary for the field of electric water heaters, including vocabulary in the fields of device components, fault types, operating parameters, etc., in order to improve the accuracy during the identification process. Use the vocabulary in the custom dictionary for matching, correct or supplement the identification results, and enhance the recognition rate of professional terms and domain-specific vocabulary. By analyzing the context of entities in the log text, judge the relationships between entities, especially between multiple entities that appear in the same sentence. For example, if the log mentions "the temperature of the heater is abnormal", then it can be recognized that there is an association between "heater" and "temperature anomaly". Analyze the co-occurrence frequency of each entity in the log to dig out possible implicit relationships or high-frequency fault combinations.

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

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

[0087] Device A has a fault, the temperature sensor is faulty, and the current temperature is 75°C.

[0088] Annotate the log data to determine the entity categories. For example:

[0089] Device component: temperature sensor;

[0090] Fault type: fault;

[0091] Parameter entity: 75°C;

[0092] Select the existing and trained BERT model, use the labeled data to fine-tune the pre-trained model to improve its recognition ability for a specific domain (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, with an overcurrent, and the current current is 20A.

[0094] The entities in the recognized text will be identified and labeled with categories, and the results may be:

[0095] Device component: Heater;

[0096] Fault type: Fault;

[0097] Parameter entity: Current, 20A;

[0098] Finally, in this way, key entity information can be effectively extracted from the device log, facilitating subsequent fault analysis and decision support.

[0099] Judging the relationships between entities by analyzing the context of entities in the log text includes the following steps:

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

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

[0102] Analyze the context relationships of the extracted entities in the text. Through natural language processing techniques (such as dependency syntax analysis or word vector models), understand the semantic relationships between entities;

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

[0104] Relationship example: Analyzing from the context, the relationship between "temperature sensor" and "fault" is "there is a fault". Judging from the context that the "temperature sensor fault" causes the "heater to stop working", so it can be considered that there is an "influence" relationship between the "temperature sensor" and the "heater".

[0105] Through semantic analysis and pattern matching algorithms, extract the relationships between entities from the device operation parameters and maintenance records, and identify the causal relationships between components, faults, and operation parameters, including the following steps:

[0106] Definition of causal relationship patterns: Based on the knowledge in the field of fault diagnosis, construct a common causal relationship pattern library. For example, patterns such as "X abnormality causes Y fault" or "Z component damage causes X abnormality".

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

[0108] Dependency syntactic analysis: Perform dependency syntactic analysis on text records to identify the grammatical structures between entities, so as to determine the relationships between components such as the subject, predicate, and object. Dependency analysis helps to determine the specific semantic roles of the cause and effect in a causal relationship.

[0109] Semantic similarity calculation: By calculating the semantic similarity of different entities in the text, identify similar or related entities and analyze the potential relationships between them. For example, "temperature increase" and "temperature anomaly" may have a high similarity and can be grouped into causal pairs under the same relationship pattern.

[0110] Regular expression matching: Use regular expressions to perform pattern matching on the text and extract entity pairs that conform to the preset causal relationship pattern. For example, "low water flow causes the heater to overheat" matches the pattern "X is low causes Y to overheat", and the causal relationship between "low water flow" and "heater overheat" can be extracted.

[0111] Rule-based relationship extraction: Combine the results of dependency analysis and pattern matching to extract eligible relationship pairs. Determine the relationship direction and type between entities through preset rules. For example, "abnormality detected" 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 correlation relationships between various types of data to construct a comprehensive fault knowledge graph, including the following steps:

[0113] Entity standardization mapping: Map the entities involved in each dataset (such as components, parameters, fault types, etc.) and unify them into the same format or representation. For example, standardize the names of the same component described in different records 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 devices and fault instances.

[0115] Correlation relationship analysis: Based on the interaction and co-occurrence relationships of various types of data, establish the correlation relationships between various entities and identify common component-fault and parameter-fault relationships. For example, the relationship between "heater abnormality" and "temperature increase".

[0116] Node and relationship definition: Define entities such as equipment components, operation parameters, fault types, and maintenance measures as nodes in the knowledge graph, and define the relationships between components, between components and faults, and between faults and maintenance measures as edges in the knowledge graph.

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

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

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

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

[0121] Complex relationship extension: Based on the association rule mining algorithm, discover potential relationships between components, fault association relationships, etc., and add them to the knowledge graph to improve the relationship network.

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

[0123] Combine different data types, establish a cross-modal association relationship network by analyzing the association relationship between operating parameters and fault records, use similarity measurement methods to match and infer relationships between entities in different data modalities, identify different manifestations of the same device, component, or fault, and fuse their relationships. Specifically:

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

[0125] Integrate the identified entities and the calculated similarity relationships to form a network structure. Nodes: heater, temperature, fault code 123; Edges: similarity relationships between temperature and faults, and fuse similar entities and their relationships. For example, if "heater failure" is recorded in different logs in different manifestations (such as "heater overheating", "heater failure"), classify them as the same fault type through similarity measurement and context relationships.

[0126] Based on the association rule mining algorithm, discover potential relationships between components, fault association relationships, and add them to the knowledge graph to improve the relationship network. Through graph structure analysis, detect isolated nodes, weakly connected nodes in the graph, including the following steps:

[0127] Use the Apriori association rule mining algorithm to discover potential associations between components and faults from the data. For example, the discovered 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, construct the nodes (equipment components, fault types) and relationships (associations between faults) in the knowledge graph;

[0131] Nodes: Heater, Temperature sensor, Pressure;

[0132] Relationships: Heater failure → Temperature sensor failure, Abnormal pressure → Heater failure;

[0133] Detect isolated nodes and weakly connected nodes:

[0134] Isolated node: A node with no connections. For example, if a component does not appear in any fault records.

[0135] Weakly connected node: A node with few connections or with edges of low weight connecting to it.

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

[0137] Example of an isolated node: If "water level sensor" is a node with no connections, it indicates that this node is an isolated node.

[0138] Example of a weakly connected node: If the "pressure" node is only connected to one fault node with a very low connection weight, then this node is a weakly connected node.

[0139] Based on the real-time data stream of the Internet of Things, dynamically update the nodes and relationships in the knowledge graph. For example, when new fault information is added, add the new fault node and its associated relationships 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, an anomaly detection is triggered.

[0141] Fault feature identification: Based on the detected abnormal features, analyze the corresponding fault types and component locations to determine the detailed information of the new fault.

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

[0143] Relationship construction and expansion: Generate new relationships according to fault characteristics, and connect the new faulty nodes with relevant equipment component nodes and operating parameter nodes, so as to reflect the association between the new fault and the existing nodes 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 operations are performed. For example, associate the newly detected "temperature anomaly" fault with the existing temperature node.

[0145] Consistency verification: Through the constraint rules 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] Embed the nodes and relationships in the knowledge graph into a low-dimensional space using graph embedding algorithms, including 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 the graph structure data from the graph database, including the node list, edge list 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 the walk step size, the number of walks, etc. For Node2Vec, set the walk strategy parameters (such as p and q) to control the regression and exploration of the walks. 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] Use the generated node sequences to train the Skip-Gram model to learn the embedding representation of nodes in the low-dimensional space. The model will predict the target node based on the context nodes, thereby generating the low-dimensional vectors of the nodes. To improve the training efficiency, adopt negative sampling technology, select a small number of negative samples for optimization, and accelerate the model convergence speed.

[0150] After training is completed, extract the embedding vectors of each node from the model to obtain the representation of nodes in the low-dimensional space. Select an appropriate embedding dimension (such as 50 dimensions, 100 dimensions, etc.) according to specific application requirements to balance model complexity and expressive power. Generate an embedded representation of the relationship by operating on the embedding vectors of related nodes (such as addition or multiplication). For example, calculate the vector representation of the relationship between nodes A and B using their embedding vectors.

[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 the random walk according to the selected algorithm, such as the walk length, the number of walks, etc. For Node2Vec, set the walk strategy parameters (such as p and q) to control the recurrence and exploratory nature of the walk. Conduct random walks in the graph to generate a series of node sequences. These sequences will be used in the subsequent embedding learning process, including the following steps:

[0152] The knowledge graph contains device components and their fault relationships. For example:

[0153] Nodes: Heater, Temperature Sensor, Pressure Sensor, Fault;

[0154] Edges: Heater Fault → Temperature Sensor Fault, Pressure Abnormality → Heater Fault;

[0155] Select walk parameters:

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

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

[0158] Node2Vec parameters:

[0159] p (return parameter): Control the recurrence of the walk, for example, set to 0.5.

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

[0161] Starting from each node, conduct random walks based on the set parameters. Use the strategy of Node2Vec to control the walk behavior.

[0162] Example: Starting from the "Heater" node, the walk may generate 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] Train the 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 to represent its semantic relationship in the graph.

[0171] Train the Skip - Gram model using the generated node sequence to learn the embedding representation of nodes in the low - dimensional space. The model predicts the target node based on the context nodes, thereby generating low - dimensional vectors for the nodes. To improve the training efficiency, negative sampling technology is adopted, selecting a small number of negative samples for optimization to accelerate the model convergence speed, including the following steps:

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

[0173] Context Window Size: Set the context window size (e.g., 2), which determines the number of context nodes considered when predicting the target node.

[0174] Select Negative Samples: In each training, select a small number of negative samples (usually 5 - 20) for each target node, and these samples do not appear in the context.

[0175] Negative Sample Selection Method: Some irrelevant nodes can be randomly selected as negative samples based on the global node frequency. Example:

[0176] For the target node "Fault", the context nodes may be "Heater" and "Temperature Sensor", and the negative samples can be randomly selected "Water Level Sensor", "Pump", etc.

[0177] After training is completed, the model will generate a low - dimensional vector representation for each node, and these vectors can capture the similarity and structural information between nodes:

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

[0179] Perform inference through the rule engine in the knowledge graph (such as the Cypher query language) to derive possible fault causes, including the following steps:

[0180] Select a suitable rule engine, such as the Cypher query language of Neo4j. Cypher allows complex graph data queries and inferences through the graph query language. If using Neo4j, ensure that the database is installed and correctly configured so that it can be connected and queries can be executed;

[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 according to real-time data or specific conditions to flexibly adjust the query content. For example, query the fault conditions of specific fault types or specific components;

[0186] Execute the written Cypher query in the knowledge graph to obtain fault causes or potential faults that meet the conditions, process the query results, and sort out possible fault causes and relevant information, including fault types, related components, impact parameters, etc.

[0187] Combine graph data and IoT sensor data to perform cross-modal fusion of 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 that the timestamps, formats, units, etc. of the two types of data are consistent. Clean and denoise the data, filter out irrelevant information, extract important features from the IoT sensor data (such as changes in parameters such as temperature, pressure, current, etc.), and normalize the node attributes in the knowledge graph so that they are comparable during cross-modal fusion;

[0189] Fuse the time series features of the sensor data with the attribute data of the knowledge graph nodes to construct the feature vectors of the graph nodes. For example, combine the temperature change at the time of fault occurrence with the attribute data of related components to form cross-modal features of the fault nodes, perform pattern matching on the sensor data and graph data, and group similar features together. For example, if temperature and current anomalies occur simultaneously, determine whether they are consistent with the existing historical fault patterns;

[0190] Calculate the cross-modal similarity between cross-modal feature vectors using cosine similarity, measure the matching degree between the current fault feature and the historical record, assign weights according to the importance of different modalities (sensor data and knowledge graph), and integrate the similarity scores to generate a comprehensive similarity index to guide the reasoning of fault causes;

[0191] Match the current fault feature with the historical fault mode according to the calculated cross-modal similarity, and judge the most likely fault cause.

[0192] Fuse the time series features of sensor data with the attribute data of knowledge graph nodes, construct the 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 Internet of Things 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 the 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 devices or components from the knowledge graph, such as status, fault type, component characteristics, etc.;

[0200] For the "heater" node, the attributes may include:

[0201] Status: normal;

[0202] Fault type: no fault;

[0203] Service life: 3 years.

[0204] Fuse the extracted sensor features with the knowledge graph node attributes to form new feature vectors;

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

[0206] Suppose 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 status and fault type).

[0208] Use cosine similarity to calculate the cross-modal similarity between cross-modal feature vectors, measure the matching degree between the current fault feature and the historical record, assign weights according to the importance of different modalities, and integrate the similarity scores to generate a comprehensive similarity index to guide the reasoning of the fault cause, 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 fault 1);

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

[0212] For the current fault feature vector and historical record feature vector 1: Calculate the similarity score, assumed to be 0.95.

[0213] Determine the weight of each modality according to business scenario or historical data analysis.

[0214] Example weight assignment:

[0215] Weight of sensor data: 0.6;

[0216] Weight of knowledge graph: 0.4;

[0217] Weighted calculation of sensor similarity and knowledge graph similarity to obtain the comprehensive similarity. Assume the cosine similarity of 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 indicates that the current fault highly matches the historical record, and infer the possible fault cause. 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, use cosine similarity to calculate the similarity between cross-modal feature vectors, integrate the importance of different modalities, and generate a comprehensive similarity index, thereby guiding the reasoning of the fault cause. This method can effectively improve the accuracy and efficiency of fault diagnosis.

[0222] Based on the calculated cross-modal similarity, match the current fault feature with the historical fault modes to determine the cause of the fault, including the following steps:

[0223] The current fault feature extracted from the sensor and the knowledge graph; The current fault feature vector: 0.85, 0.65, 0.9 (corresponding to heater failure);

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

[0225] According to the similarity scores, select the historical fault mode similar to the current fault feature: Historical fault mode 1: Feature vector 0.80, 0.60, 0.85, Cause of the fault: Temperature sensor failure; Historical fault mode 2: Feature vector 0.75, 0.65, 0.80, Cause of the fault: Heating element damage.

[0226] Based on the similarity scores, determine the most matching historical fault mode. The similarity between the current fault feature and historical fault mode 1 is 0.92, with a relatively high matching degree. The similarity between the current fault feature and historical fault mode 2 is 0.88, with a slightly lower matching degree.

[0227] Since the similarity between the current fault feature and historical fault mode 1 is relatively high, it is speculated that the current cause of the fault may be "temperature sensor failure". Combining historical data, decide whether further fault troubleshooting or repair is needed.

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

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

[0230] Ensure that the graph database tool (such as Neo4j) and the visualization tool (such as Neo4jBloom or Graph-X) are installed and correctly configured. Configure the graph database connection and confirm that the permission settings are correct. Load the knowledge graph data into the graph database. Usually includes nodes, relationships, and their attributes. For Neo4j, data can be imported using CSV files, JSON, or APIs.

[0231] Write Cypher queries to select the nodes and relationships to be displayed according to the display requirements. For example, you can filter out the corresponding graph structures based on specific fault types, time ranges, or components, query in the graph database, and check the results. Confirm that the query results meet the expectations and ensure that all nodes and relationships required for display are included.

[0232] Select a suitable layout method (such as force-directed layout, tree layout, etc.) in the visualization tool to clearly display the node relationships. Different layout methods help highlight different structural features. Distinguish according to node types (such as device components, operating parameters, fault types) using different colors, shapes, or sizes for easy intuitive understanding of the graph information. Set the color and line type of the edges to represent the types or weights of different relationships.

[0233] Use the built-in filtering function of the tool to filter according to node attributes or relationship types. For example, focus on specific fault types or directly related nodes of a certain component, and filter out irrelevant information to improve clarity. For large knowledge graphs, the aggregation function can be used to merge similar nodes, and the aggregated nodes can also be expanded as needed to display a more detailed hierarchical structure and relationships.

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

[0235] If there is a need to update data during the use of the knowledge graph, a real-time update function can be set so that the graph visualization tool dynamically loads the latest nodes and relationships. For knowledge graphs containing time series information, a timeline control can be added to view the changes in the graph structure at different time points to identify historical and current fault patterns.

[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: Collect the log information of faulty devices through Internet of Things sensors. Use the components, operating parameters, and fault types of the devices as nodes, and obtain the node relationships between each node. Send 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 device component names, fault types, and related parameters. Through semantic analysis and pattern matching algorithms, extract the relationships between entities from device operation parameters and maintenance records, identify the causal relationships between components, faults, and operation parameters, integrate real-time operation data, historical fault data, and maintenance records, and combine the association relationships between various types of data to construct a comprehensive fault knowledge graph. The fault knowledge graph is sent to the Dynamic Update Module;

[0239] 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. For example, when new fault information is added, add the new fault node and its associated relationships to the knowledge graph. The dynamically updated knowledge graph is sent to the Deduction Module;

[0240] Deduction Module: Use graph embedding algorithms to embed the nodes and relationships in the knowledge graph into a low-dimensional space, and perform reasoning through the rule engine (such as Cypher query language) in the knowledge graph to deduce possible fault causes. The deduction results are sent to the Graph Display Module;

[0241] Graph Display Module: Combine graph data and Internet of Things sensor data to perform cross-modal fusion of 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, enabling maintenance personnel to intuitively view the fault associations and causal relationships between the components of the electric water heater. After the fault is processed, collect the feedback from the maintenance personnel to correct the wrong relationships in the knowledge graph or supplement new fault modes.

[0242] The above formulas are all dimensionless and take their numerical values for calculation. The formulas are obtained by collecting a large amount of data for software simulation to get a formula that is closest to the actual situation. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

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

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

[0245] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application. Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0246] As described above, it is only the specific implementation manner of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed by this application can easily think of changes or substitutions, which should all be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claimed rights.

Claims

1. A method for sharing device fault information based on the Internet of Things, characterized in that: The shared method includes the following steps: Collect the log information of the faulty device through Internet of Things sensors. Take the components, operating parameters, and fault types of the device as nodes, obtain the node relationships between each node, and use natural language processing technology to extract entities from the text records of the log information; Through semantic analysis and pattern matching algorithms, extract the relationships between entities from the device operating parameters and maintenance records, identify the causal relationships between each component, fault, and operating parameter, integrate the real-time operating data, historical fault data, and maintenance records, and combine the association relationships between various types of data to construct a fault knowledge graph; By analyzing the structure and function of the faulty equipment, obtaining the connection relationships between components, establishing connections between operating parameters and relevant components, obtaining the relationships between fault types and operating parameters, and evaluating the relationship strength between nodes based on historical fault data and component health status, the expression is: In the formula, S(i,j) is the relationship strength between node i and node j, F(i,j) is the co-failure frequency 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 are both greater than 0, N represents the total number of fault times, and weights are assigned to each relationship; Based on the real-time data stream of the Internet of Things, dynamically update the nodes and relationships in the knowledge graph. Use graph embedding algorithms to embed the nodes and relationships in the knowledge graph into a low-dimensional space. Execute reasoning through the rule engine in the knowledge graph to deduce the cause of the fault. Combine the graph data and Internet of Things sensor data to perform cross-modal fusion of the fault phenomenon, parameter changes, and historical records to obtain the reasoning result of the fault cause, and use a graph visualization tool to display the knowledge graph.

2. The method for sharing device fault information based on the Internet of Things according to claim 1, characterized in that: Taking the components, operating parameters, and fault types of the device as nodes, and obtaining the node relationships between each node, includes the following steps: The components of the electric water heater include a heater, a temperature sensor, a water pump, and a control module. Take each component as an independent node; Identify the operating parameters of the electric water heater, including temperature, water flow rate, and current, and take the operating parameters as nodes in the knowledge graph; Analyze the historical fault data, determine the fault types, and take each fault type as a node in the knowledge graph; By analyzing the structure and function of the electric water heater, obtain the connection relationships between the components, establish connections between the operating parameters and the relevant components, and identify the causal relationships between each fault type and the components, as well as obtain the relationships between the fault types and the operating parameters; Based on the historical fault data and the component health status, evaluate the relationship strength between the nodes and assign weights to each relationship.

3. The method for sharing device fault information based on the Internet of Things according to claim 2, wherein: Based on the historical fault data and the component health status, evaluate the relationship strength between the nodes and assign weights to each relationship, includes the following steps: Collect the historical fault records of the electric water heater, including the fault type, occurrence time, relevant components, and fault description; Assign weights 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 relationship strength between node i and node j, W(i,j) is the relationship weight between node i and node j, and k is the weight ratio coefficient.

4. The method for sharing device fault information based on the Internet of Things according to claim 3, wherein: Combining the graph data and Internet of Things sensor data to perform cross-modal fusion of the fault phenomenon, parameter changes, and historical records to obtain the reasoning result of the fault cause, includes the following steps: Synchronize the data from the Internet of Things sensors with the knowledge graph data and normalize the node attributes in the knowledge graph; Fuse the time series features of the sensor data with the attribute data of the knowledge graph nodes, construct the feature vectors of the graph nodes, perform pattern matching on the sensor data and the graph data, and combine the similar features; Calculate the cross-modal similarity between cross-modal feature vectors using cosine similarity, measure the matching degree between the current fault feature and the historical record, assign weights according to the importance of different modalities, and integrate the similarity scores to generate a comprehensive similarity index to guide the reasoning of fault causes; Match the current fault feature with the historical fault mode according to the calculated cross-modal similarity to determine the fault cause.

5. The method for sharing device fault information based on the Internet of Things according to claim 4, characterized in that: The calculation expression of the health status correlation coefficient is: where n is the number of time points for comparison, and H i (g) is the health status score of node i at the g-th time point, and H j (g) is the health status score of node j at the g-th time point, and μ i is the mean value of the health status scores of node i, and μ j is the mean value of the health status scores of node j, and σ i is the standard deviation of the health status scores of node i, and σ j is the standard deviation of the health status scores of node j. The parameter deviation includes temperature deviation, vibration deviation, pressure deviation, current deviation, and water flow deviation. The general calculation expression for the health status score of node i at the g-th 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 respective parameter deviations at the g-th time point, and w n is the corresponding parameter deviation weight.

6. The method for sharing device fault information based on the Internet of Things according to claim 5, characterized in that: Integrate the real-time operation data, historical fault data, and maintenance records, and combine the correlation relationships between various types of data to construct a fault knowledge graph, including the following steps: Map the entities involved in each dataset, and connect the real-time operation data, fault data, and maintenance records through timestamps, device IDs, or component names; Based on the interaction and co-occurrence relationships of various types of data, establish the correlation relationships between various entities, and identify the part-fault and parameter-fault relationships; Based on the integrated data, instantiate each entity and add it to the graph, and gradually add nodes and relationships using a graph database to form a preliminary knowledge graph structure; Combined with different data types, establish a cross-modal correlation relationship network by analyzing the correlation relationship between operation parameters and fault records, use similarity measurement methods to match and infer the relationships between entities in different data modalities, and identify and fuse different manifestation forms of the same device, component, or fault; Based on the association rule mining algorithm, discover potential relationships between components and fault association relationships, and add them to the knowledge graph to improve the relationship network. Through graph structure analysis, detect isolated nodes and weakly connected nodes in the graph.

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

8. An Internet of Things-based device fault information sharing system for implementing the sharing method according to any one of claims 1-7, characterized in that: Include a data collection module, a knowledge graph construction module, a dynamic update module, a derivation module, and a graph display module; Data collection module: Collect the log information of the faulty device through IoT sensors, use the components, operation parameters, and fault types of the device as nodes, and obtain the node relationships between each node; Knowledge graph construction module: Use natural language processing technology to extract entities from the text records of log information, extract the relationships between entities from the device operation parameters and maintenance records through semantic analysis and pattern matching algorithms, identify the causal relationships between each component, fault, and operation parameter, integrate the real-time operation data, historical fault data, and maintenance records, and combine the correlation relationships between various types of data to construct a fault knowledge graph; Dynamic update module: Dynamically update the nodes and relationships in the knowledge graph based on real-time data streams of the Internet of Things; Deduction module: Use graph embedding algorithms to embed the nodes and relationships in the knowledge graph into a low-dimensional space, and perform reasoning through the rule engine in the knowledge graph to deduce the cause of the fault; Graph display module: Combine graph data and Internet of Things sensor data to perform cross-modal fusion of fault phenomena, parameter changes, and historical records, obtain the reasoning results of the cause of the fault, and use graph visualization tools to display the knowledge graph.

Images