Equipment fault root cause analysis system fusing data of Internet of Things

Abstract

The invention relates to the technical field of equipment fault analysis, and discloses an equipment fault root cause analysis system fusing Internet of Things data. An edge computing node of the system carries out timestamp alignment and abnormal value cleaning on a real-time operation data stream of industrial equipment to generate a standardized equipment state sequence; the multi-source data fusion engine carries out space-time alignment on the multi-source data, environment monitoring data and equipment maintenance logs, an association mapping relation is established, and a multi-dimensional equipment operation state matrix is formed; a fault feature mining assembly extracts vibration spectrum, temperature gradient change and energy consumption fluctuation features, and constructs a fault feature evolution graph in combination with a historical fault case library; the digital twin mapper generates an equipment virtual entity and loads the atlas to form a fault feature projection with a space-time mark; and the root cause reasoning model analyzes a feature node propagation path, calculates contribution degrees and outputs potential root cause chains sorted according to the contribution degrees. The system improves the comprehensiveness and accuracy of equipment fault root cause analysis.

Description

Technical Field

[0001] This invention relates to the field of equipment failure analysis technology, specifically to a root cause analysis system for equipment failures that integrates Internet of Things (IoT) data. Background Technology

[0002] With the rapid development of Industrial Internet of Things (IIoT) technology, the monitoring of industrial equipment operation status has entered a data-intensive stage. A large number of industrial devices generate massive amounts of operational data in real time through sensors, covering multiple dimensions such as vibration, temperature, and energy consumption. Meanwhile, environmental monitoring data, equipment maintenance logs, and other multi-source data continue to accumulate. However, this data is often scattered across different systems, resulting in issues such as inconsistent timestamps, inconsistent formats, and outlier interference, making effective data integration and utilization difficult.

[0003] Existing root cause analysis methods for equipment failures often rely on a single data source or human experience, making it difficult to handle the fusion of multi-source heterogeneous data. For example, fault diagnosis methods based on vibration data can only reflect the local mechanical state of the equipment, ignoring the impact of environmental temperature and humidity changes on equipment performance; analysis methods relying on maintenance logs are limited by the completeness and accuracy of the records, easily leading to biased root cause judgments. In addition, traditional analysis methods lack dynamic tracking of the evolution process of fault characteristics and cannot build correlations between characteristics. When complex anomalies occur in equipment, it is difficult to locate the core root cause, often resulting in long fault troubleshooting cycles and low maintenance efficiency.

[0004] Industrial equipment structures are becoming increasingly complex, and a single failure can trigger a chain reaction of multiple related characteristics. Traditional linear analysis models struggle to capture such nonlinear correlations. While digital twin technology has been applied to virtual equipment mapping, accurately matching fault characteristics fused from multi-source data with virtual entities to achieve dynamic spatiotemporal projection of fault characteristics remains an unresolved technical challenge. These issues result in existing systems lacking comprehensiveness and accuracy in root cause analysis when facing complex industrial scenarios, failing to meet the high reliability requirements of modern industrial production. Summary of the Invention

[0005] The purpose of this invention is to provide a device failure root cause analysis system that integrates Internet of Things (IoT) data to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides a device failure root cause analysis system integrating Internet of Things (IoT) data, the system comprising: Edge computing nodes are used to receive real-time operating data streams from industrial equipment, perform timestamp alignment and outlier cleanup on the data streams, and generate standardized equipment status sequences. The multi-source data fusion engine is used to align standardized equipment status sequences with environmental monitoring data and equipment maintenance logs in time and space, and to establish cross-data source association mapping relationships through entity recognition technology to form a multi-dimensional equipment operation status matrix. The fault feature mining component is used to extract equipment vibration spectrum features, temperature gradient change features, and energy consumption fluctuation features from the multi-dimensional equipment operating state matrix, and combine them with feature tags in the historical fault case library to construct a fault feature evolution map. A digital twin mapper is used to generate a virtual entity of the equipment based on the parameters of the equipment's 3D model and real-time operating data. A fault feature evolution map is synchronously loaded into the virtual entity to form a fault feature projection with spatiotemporal markers. The root cause reasoning model is used to analyze the propagation path of different feature nodes in the fault feature projection. It calculates the contribution of each feature node to the current abnormal state of the equipment through a dynamic weight allocation algorithm and outputs the potential root cause chain sorted by contribution.

[0007] Preferably, when the multi-source data fusion engine performs data alignment: The coordinates of temperature and humidity sampling points in the collected environmental monitoring data are matched with the physical location coordinates in the equipment status sequence using a grid. Extract timestamps and operation types from equipment maintenance logs and map them to the corresponding time intervals of standardized equipment status sequences; When maintenance operation records are detected within the same time interval, the maintenance event impact window is marked in the device status sequence.

[0008] Preferably, when the fault feature mining component constructs the fault feature evolution map: Wavelet packet decomposition is performed on the vibration spectrum characteristics of the equipment, and the energy proportion of each frequency band is extracted as the first-level feature node. Calculate the diffusion rate of temperature gradient change features in the thermal imaging map of the device surface, and generate second-level feature nodes; Identify the deviation between energy consumption fluctuation characteristics and equipment load curves, and establish third-level feature nodes; The three-level feature nodes are connected along the time dimension to form feature evolution edges with directional weights.

[0009] Preferably, when the digital twin mapper generates the fault feature projection: Divide the feature-bearing region in the 3D mesh model of the virtual device entity; The first-level feature nodes are mapped to the corresponding mesh of the device transmission components, and the second-level feature nodes are mapped to the corresponding mesh of the heat dissipation structure. Based on the directional weights of the feature evolution edges, feature propagation trajectories of different colors are rendered in the virtual entity.

[0010] Preferably, when the root cause reasoning model calculates the contribution: Traverse all feature nodes in the fault feature projection and record the shortest path from each node to the current abnormal state node. Statistically analyze the trigger frequency of each characteristic node as a root cause in the historical failure case database; Dynamic weight coefficients are generated by integrating path length and trigger frequency to perform topological sorting of potential root cause chains.

[0011] Preferably, the root cause reasoning model further includes: The real-time monitoring module is used to capture newly generated alarm events in the equipment control system; An event matcher is used to perform semantic similarity matching between alarm event description text and feature nodes in the fault feature evolution graph. When the matching degree exceeds the set threshold, the root cause reasoning model is triggered to recalculate the contribution of the associated feature nodes.

[0012] Preferably, when the event matcher performs semantic similarity matching: Extract device component names and keywords related to abnormal phenomena from the alarm event description text; Retrieve feature nodes containing the same keywords in the fault feature evolution map; The co-occurrence probability of keywords in historical failure cases is calculated and used as a weighting factor for semantic similarity.

[0013] Preferably, the system further includes: A data quality evaluator is used to detect standardized device status sequences output by edge computing nodes; When the proportion of missing values ​​in a sequence exceeds the tolerance threshold, the redundant data source switching mechanism is activated. Missing segments are filled in by using homogeneous data streams from adjacent devices, generating a repaired device status sequence.

[0014] Preferably, when the data quality evaluator activates the redundant data source switching mechanism: Query the backup data collection points for the current device in the device topology database; Compare the historical data deviation rates between each backup data collection point and the main data collection point; The data stream from the backup acquisition point with the smallest deviation rate is selected for missing value imputation.

[0015] Preferably, the system further includes: Version controller, used to manage the iterative updates of the fault feature evolution map; When the potential root cause chain output by the root cause reasoning model is manually confirmed, the combination of feature nodes in the confirmation result is extracted. The confirmed feature node combinations are inserted as new cases into the historical fault case library, and the edge weights of the feature evolution graph are reconstructed.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This system uses edge computing nodes to timestamp and clean outliers from real-time industrial equipment operation data streams, generating standardized equipment status sequences. This eliminates noise interference and format differences in the original data, providing a unified and standardized foundation for subsequent data processing. The multi-source data fusion engine aligns the standardized equipment status sequences with environmental monitoring data and equipment maintenance logs in time and space. Through entity recognition technology, it establishes cross-data source mapping relationships, forming a multi-dimensional equipment operation status matrix. This breaks down information barriers between different data sources, transforming previously isolated data into an organic whole that comprehensively reflects the overall operational status of the equipment.

[0017] The fault feature mining component extracts equipment vibration spectrum features, temperature gradient change features, and energy consumption fluctuation features from a multi-dimensional equipment operating state matrix. Combined with feature markers from a historical fault case library, it constructs a fault feature evolution map. This not only uncovers key features during equipment operation but also assigns clear fault orientations to features through the correlation of historical cases, presenting the evolutionary patterns of features over time. The digital twin mapper generates a virtual entity of the equipment based on the equipment's 3D model parameters and real-time operating data, and simultaneously loads the fault feature evolution map to form a fault feature projection with spatiotemporal markers. This achieves a precise mapping between physical equipment and virtual entities, transforming abstract fault features into a visualized spatiotemporal distribution, intuitively presenting the propagation path of features within the equipment.

[0018] The root cause reasoning model analyzes the propagation paths of different feature nodes in the fault feature projection. Through a dynamic weight allocation algorithm, it calculates the contribution of each feature node to the current abnormal state of the equipment, outputting potential root cause chains sorted by contribution. This allows for the identification of key influencing factors from complex feature associations, clarifying the development path of the fault. The collaborative work of all components enables end-to-end processing from multi-source data acquisition, fusion, and feature mining to root cause reasoning, covering all aspects of equipment fault analysis. This makes the root cause analysis process more systematic and coherent, adaptable to the fault diagnosis needs of complex industrial equipment, and provides more comprehensive and in-depth reference information for equipment maintenance. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the working principle of the device failure root cause analysis system integrating Internet of Things data as described in this invention; Figure 2 Workflow diagram for performing data alignment for multi-source data fusion engines; Figure 3A flowchart illustrating the workflow for constructing a fault feature evolution map for the fault feature mining component. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please see Figure 1 This invention provides a device failure root cause analysis system integrating IoT data. The system integrates edge computing, multi-source data fusion, fault feature mining, digital twin mapping, and root cause reasoning technologies to achieve intelligent diagnosis of industrial equipment failures. The overall system architecture includes edge computing nodes, a multi-source data fusion engine, a fault feature mining component, a digital twin mapper, and a root cause reasoning model. Edge computing nodes are deployed near the equipment, receiving real-time operational data streams from industrial sensors. These data streams contain various parameters such as vibration, temperature, and current. The edge computing nodes perform timestamp alignment on the raw data streams, using interpolation methods to compensate for time deviations caused by transmission delays. Simultaneously, an outlier detection algorithm based on statistical distribution is applied to identify and clean outliers, generating a standardized equipment state sequence. The multi-source data fusion engine receives the standardized equipment state sequence and integrates it with temperature and humidity data from an environmental monitoring system and equipment maintenance logs. The multi-source data fusion engine aligns multi-source data through spatial grid matching and time interval mapping, and uses entity recognition technology to establish relationships between data, forming a multi-dimensional equipment operating state matrix containing equipment status, environmental factors, and maintenance history. The fault feature mining component extracts key features from the multi-dimensional equipment operating state matrix, including vibration spectrum features, temperature gradient change features, and energy consumption fluctuation features. Combining these with feature patterns annotated in a historical fault case library, the component constructs a fault feature evolution map centered on feature nodes and evolutionary edges. The digital twin mapper generates a high-fidelity virtual entity based on the equipment's 3D model parameters and real-time operating data. Feature nodes from the fault feature evolution map are projected onto corresponding positions in the virtual entity, forming a fault feature projection with spatiotemporal markers. The root cause reasoning model analyzes the propagation paths of feature nodes in the fault feature projection, employs a dynamic weight allocation algorithm to calculate the contribution of each node to the current abnormal state, and outputs potential root cause chains sorted by contribution, providing a basis for maintenance decisions. All system components exchange data through a message middleware to ensure the real-time performance and reliability of the data processing flow.

[0022] Example 1: See Figure 2The multi-source data fusion engine receives standardized equipment status sequences from edge computing nodes. These sequences contain time-series data of industrial equipment operating parameters, such as vibration amplitude, rotational speed, and current values. Each data point is accompanied by a precise timestamp and the physical coordinates of the equipment. The engine also receives data from an environmental monitoring system comprised of a network of temperature and humidity sensors deployed throughout the factory. Each sensor has a unique identifier and geographic coordinates, and data is reported at fixed intervals. Equipment maintenance logs are retrieved from the enterprise asset management system. Log entries record the start and end times of maintenance activities, operation types, specific equipment numbers involved, and maintenance personnel information. When processing environmental monitoring data, the multi-source data fusion engine reads the coordinates of sampling points from all active temperature and humidity sensors, represented in a three-dimensional coordinate system. The engine divides the entire factory floor into uniform three-dimensional grid cells, with the grid cell size configured based on equipment and sensor distribution density. Finally, the engine calculates the Euclidean distance between the physical coordinates of all equipment and the coordinates of all temperature and humidity sensors within each grid cell. For each device, the multi-source data fusion engine finds the temperature and humidity sensor closest to its physical location coordinates and designates this sensor as the device's matching data source. After the matching relationship is established, the multi-source data fusion engine binds the temperature and humidity readings of the corresponding sensor to the device's standardized device state sequence. The mesh matching process is executed periodically to adapt to changes in the sensor network topology, such as the addition of new sensors or device relocation.

[0023] When processing equipment maintenance logs, the multi-source data fusion engine parses the timestamp and operation type fields. Timestamps are accurate to the millisecond level, and operation types include various predefined categories such as preventative maintenance, fault diagnosis, component replacement, and lubrication maintenance. The multi-source data fusion engine maps the timestamps of the equipment maintenance logs to a continuous timeline of a standardized equipment state sequence. The mapping process uses a sliding time window algorithm, with the window width dynamically adjusted according to the type of maintenance operation. For example, a component replacement operation corresponds to a wider time window, while a lubrication maintenance operation corresponds to a narrower time window. The multi-source data fusion engine checks whether the timestamps of the equipment maintenance logs fall within a certain time interval of the standardized equipment state sequence. When time overlap exists, the multi-source data fusion engine marks this time interval as affected by a maintenance event. When the multi-source data fusion engine detects maintenance operation records within the same time interval, it creates a maintenance event impact window in the standardized equipment state sequence. The maintenance event impact window is a special data structure containing the window start time, window end time, maintenance operation type descriptor, and a list of affected equipment parameters. The boundaries of the maintenance event impact window are calculated based on the duration of the maintenance operation and the expected scope of impact. The multi-source data fusion engine inserts maintenance event markers into the standardized equipment state sequence, marking the metadata associated with the maintenance event impact window. The maintenance event impact window is used in subsequent data analysis phases to distinguish whether changes in equipment state are caused by normal operation or external maintenance procedures.

[0024] After performing spatiotemporal alignment, the multi-source data fusion engine constructs cross-data source association mapping relationships. These mapping relationships are stored in relational database tables, where each record contains a device identifier, timestamp, device status parameters, environmental parameters, and maintenance event markers. The multi-source data fusion engine associates entities from different data sources using entity recognition technology, which is based on a composite key of device number, location code, and timestamp. The engine performs consistency checks on the fused data, checking for contradictory records, such as maintenance logs recording device shutdown while sensor reports indicate the device is still running. If consistency checks fail, an exception handling process is triggered, sending an alert to the system administrator. The multi-source data fusion engine ultimately outputs a multi-dimensional device operating status matrix. This matrix is ​​a two-dimensional data structure where row indices represent uniform sampling time points and column indices represent different data dimensions. These dimensions include device operating parameters, local environmental parameters, and maintenance event markers. Each element of the multi-dimensional device operating status matrix is ​​a normalized value, achieved using min-max scaling to convert parameters of different dimensions to the [0,1] range. The multi-dimensional device operation status matrix supports efficient matrix operations, providing input for downstream fault feature mining components. The multi-source data fusion engine is implemented based on a distributed computing framework. Data partitioning is performed according to device IDs, with each computing node processing data from a group of devices. The multi-source data fusion engine adopts a streaming processing mode, consuming data streams from edge computing nodes and the environmental monitoring system in real time. The multi-source data fusion engine has a built-in backpressure mechanism to handle scenarios where the data inflow rate exceeds the processing rate. The health status of the multi-source data fusion engine is monitored via a heartbeat signal, automatically triggering computing node switching in case of failure.

[0025] The configuration information for the multi-source data fusion engine is stored in an external configuration file, including grid size, time window parameters, and normalization coefficients. This configuration information supports hot updates, allowing algorithm parameters to be adjusted without restarting the service. The multi-source data fusion engine provides data lineage tracing, recording the source data source and processing history of each output data point. This data lineage information is used for auditing and fault diagnosis, graphically displaying the data flow path. The multi-source data fusion engine's interfaces with other system components use a standardized message format, and the message serialization protocol uses Protocol Buffers to ensure cross-language compatibility and high serialization efficiency. The message middleware adopts a publish-subscribe model, with the multi-source data fusion engine acting as a subscriber to consume data from edge computing nodes and simultaneously acting as a publisher to output a multi-dimensional device operating status matrix to the fault feature mining component. The network communication layer uses TLS encryption to ensure the security and integrity of data transmission.

[0026] The performance metrics of the multi-source data fusion engine include throughput, latency, and accuracy. Throughput refers to the number of data records processed per unit of time, latency refers to the time difference between data input and result output, and accuracy is evaluated through manual sampling auditing. Performance monitoring data is displayed in real time on the operations dashboard, and alarms are generated when metrics deviate from the normal range. The multi-source data fusion engine's logging system records detailed operation logs and error logs. Log files are automatically rotated and archived to a long-term storage system for subsequent analysis. The multi-source data fusion engine's code implementation adopts a modular design, with core modules including a data input adapter, grid matcher, time aligner, consistency checker, and matrix builder. Each module has a clear interface definition and independent unit test cases. The continuous integration pipeline automatically runs test suites after each code commit to ensure code quality. The multi-source data fusion engine's deployment package uses containerization technology to achieve environment-independent deployment and elastic scaling.

[0027] Example 2: See Figure 3 The fault feature mining component receives a multi-dimensional equipment operating status matrix from a multi-source data fusion engine. This matrix is ​​a structured dataset containing time-series equipment status, environmental conditions, and maintenance event markers. The component systematically extracts three key features from this matrix to describe the equipment's health status: vibration spectrum features, temperature gradient variation features, and energy consumption fluctuation features. The processing of the vibration spectrum features is based on the raw vibration signals collected by accelerometers installed at key parts of the equipment. The component performs wavelet packet decomposition on the vibration signals. Wavelet packet decomposition is a mathematical tool that performs fine-grained expansion of signals in the time-frequency domain, decomposing complex non-stationary vibration signals into a series of sub-band signals with different frequency ranges. Each sub-band corresponds to a frequency band. The component calculates the signal energy value within each frequency band and uses the ratio of the energy value of each band to the total signal energy as the energy percentage of that band. These energy percentages constitute the first-level feature nodes, which are recorded as vectors, where each element represents the relative energy level of a specific frequency band. Abnormal distribution of vibration energy in different frequency bands is often associated with mechanical failure modes. For example, an increase in energy in the high-frequency band may indicate bearing defects, while abnormal energy in the low-frequency band may point to an imbalance problem.

[0028] The processing of temperature gradient change characteristics relies on the temperature field data of the equipment surface periodically collected by infrared thermal imaging equipment. The fault feature mining component analyzes continuous thermal imaging sequences to calculate the rate of temperature change of a specific area on the equipment surface per unit time. The rate of temperature change is calculated using the finite difference method, obtained by comparing the temperature values ​​of corresponding pixels in thermal imaging images at adjacent time points. The fault feature mining component further analyzes the spatial expansion process of the temperature field on the equipment surface to determine the rate at which heat diffuses outward from the heat source area. This diffusion rate is obtained by solving a discretized heat conduction equation, reflecting the equipment's heat dissipation efficiency and potential problems such as insulation layer degradation and cooling system blockage. The calculated diffusion rate value is quantized into second-level feature nodes, which are associated with the specific physical location of the equipment. The analysis of energy consumption fluctuation characteristics is based on real-time power consumption data of the equipment recorded by smart meters or current sensors. The fault feature mining component compares the actual energy consumption curve of the equipment under the current operating state with the baseline load curve established by the equipment under standard healthy conditions. The comparison process calculates the deviation between the two curves, and the deviation is measured using a dynamic time warping algorithm or root mean square error calculation to eliminate the influence of fluctuations under normal operating conditions. The deviation value is quantified into a third-level feature node, which represents the degree of abnormality in the energy efficiency status of the equipment. An abnormal increase in energy consumption may indicate potential faults such as decreased motor efficiency and increased transmission resistance.

[0029] The fault feature mining component organizes the aforementioned three-level feature nodes in chronological order to construct a fault feature evolution graph. This graph is a directed graph data structure where nodes represent feature vectors extracted at specific timestamps, and edges represent temporal correlations and potential causal relationships between feature nodes. The component assigns a directional weight to each edge, calculated based on the statistical correlation between feature nodes, such as using Pearson correlation coefficients or mutual information to measure the temporal dependence of different features. When constructing the graph, the component integrates knowledge from a historical fault case library, which stores feature patterns corresponding to previously diagnosed fault events. The component performs pattern matching between newly extracted feature nodes and historical cases, using validated feature relationships from historical cases to initialize and strengthen the edge weights of corresponding paths in the evolution graph.

[0030] The process of generating fault feature projections using a digital twin mapper begins with loading a high-precision 3D mesh model of the equipment. This 3D mesh model typically originates from the equipment's computer-aided design model, stored in formats such as STL or OBJ, and details the geometry and surface topology of each component. The digital twin mapper then divides the 3D mesh model into feature-bearing regions, based on the equipment's physical structure and functional partitions. For example, key components such as bearing housings, gearboxes, and motor housings are defined as independent feature-bearing regions. This division can be manual or automated based on the mesh's geometric features. The digital twin mapper then maps feature nodes from the fault feature evolution map to the corresponding feature-bearing regions in the 3D mesh model. Specifically, first-level feature nodes (vibration spectrum features) are mapped to the mesh regions corresponding to components in the equipment that bear mechanical power transmission, such as the mesh facets of bearings or mesh vertices near gear meshing areas. Second-level feature nodes (temperature gradient change features) are mapped to the equipment's heat dissipation structure regions, such as the mesh surfaces of heat sinks, the mesh models of coolant pipes, and the mesh regions of motor housings. The mapping process involves the transformation of the coordinate system, establishing a correspondence between the logical identifiers of feature nodes and the vertex coordinates or patch indices of the 3D mesh model.

[0031] The digital twin mapper visualizes the feature propagation trajectory in the 3D scene of the virtual device entity based on the directional weight information of the feature evolution edges in the fault feature evolution graph. The visualization rendering uses a color-coding scheme, mapping the directional weight values ​​of the feature evolution edges to a continuous color scale, for example, transitioning from blue (low weight) through green (medium weight) to red (high weight). The digital twin mapper draws lines or surfaces with color gradients along the time series of feature nodes in the 3D model to visually demonstrate the path and intensity of fault features propagating between device components. The final fault feature projection with spatiotemporal markers is a dynamic 3D visualization scene that not only statically displays the spatial distribution of the current feature nodes but also shows the dynamic changes of the feature evolution graph over historical time periods through animation playback. This fault feature projection provides users with an immersive visualization interface for intuitively understanding the origin and development of faults. The collaborative work of the fault feature mining component and the digital twin mapper realizes the transformation process from multi-dimensional data to a structured knowledge graph, and then to an intuitive 3D projection. The construction of fault feature evolution maps relies on rigorous mathematical feature extraction methods and statistical learning of historical data, while the generation of fault feature projections relies on 3D rendering and visualization techniques in computer graphics.

[0032] Example 3: The root cause reasoning model receives fault feature projections from a digital twin mapper. These projections are complex data structures containing spatial location information, timestamp sequences, and relationships between feature nodes. The core task of the root cause reasoning model is to analyze the propagation paths of different feature nodes in the fault feature projections and quantify the contribution of each node to the ultimately observed abnormal equipment state. The root cause reasoning model traverses all feature nodes in the fault feature projections. These nodes originate from the fault feature evolution graph, and each node has type and timestamp attributes. The traversal process employs a graph traversal algorithm, starting from the node identified as the current abnormal state and performing a breadth-first search along the feature evolution edges. The root cause reasoning model records the shortest path from each feature node to the node in the current abnormal state. The length of the shortest path is measured by the sum of the weights of all feature evolution edges along the path. The weights of the feature evolution edges are determined when constructing the fault feature evolution graph and reflect the strength of the influence between feature nodes. The pathfinding algorithm needs to handle possible loops in the graph, avoiding infinite loops by marking visited nodes. The root cause inference model accesses a historical failure case database, which stores a large number of manually verified failure event records. The model then counts the frequency with which each feature node appears as the root cause in these historical failure cases. This statistical process is based on precise pattern matching, comparing the similarity between the node feature vector in the current failure feature projection and the feature vectors in historical cases. When a feature node matches a root cause feature in a historical case within a preset similarity threshold, the node's trigger frequency increases by one. The root cause inference model performs this statistical operation on all feature nodes to obtain the historical trigger frequency for each node.

[0033] The root cause reasoning model integrates shortest path length and historical trigger frequency to generate dynamic weight coefficients. The calculation of these dynamic weight coefficients uses a mathematical formula designed to assign higher weights to nodes with shorter paths and more frequent historical occurrences. The dynamic weight coefficients are defined by the following formula: Where: symbol Representatives are assigned to feature nodes The dynamic weighting coefficient. (Symbol) It is a feature node The normalized trigger frequency as a root cause in the historical failure case library. The normalization process involves dividing the original frequency by the maximum frequency of all feature nodes in the historical case library, such that... The value of is between 0 and 1. (Symbol) Indicates from feature node The shortest path to the node currently in an abnormal state. (Symbol) Representing a path Evolution of all features on the edge weight The sum, this sum represents the total resistance or distance of the path. Exponential function. Used to amplify the contribution of high-frequency nodes, in the denominator To ensure the formula remains meaningful even when the sum of path weights is zero, and that the longer the path and the larger the sum of edge weights, the larger the denominator, and the smaller the dynamic weight coefficients will be, the more meaningful the root cause inference model will be. The calculated dynamic weight coefficients will then be used to further refine the formula. All potential root cause nodes are sorted to generate a potential root cause chain arranged from highest to lowest contribution. The potential root cause chain is an ordered list, and each entry in the list contains the identifier of a feature node and its calculated dynamic weight coefficient.

[0034] The root cause reasoning model includes a real-time monitoring module that continuously listens for newly generated alarm event streams in the equipment control system. Alarm events typically appear as unstructured text messages, such as "motor bearing temperature too high alarm" or "pump vibration intensified." The real-time monitoring module captures these alarm events, performs preliminary parsing and standardization, and extracts key event timestamps, equipment identifiers, and alarm description text. An event matcher is responsible for semantic similarity matching between the alarm event description text and feature nodes in the fault feature evolution graph. The event matcher first performs natural language processing on the alarm event description text, including word segmentation, stop word removal, and stemming. From the purified text, the event matcher extracts entity words representing equipment component names and keywords describing abnormal phenomena; for example, extracting "spindle drive motor" and "current fluctuation" from "large current fluctuation in spindle drive motor." The event matcher then searches the fault feature evolution graph for feature nodes containing the same or synonymous keywords. The search process is based on a pre-built domain ontology library, which defines the hierarchical relationships between equipment components and the associations between abnormal phenomena. The event matcher calculates the semantic similarity between the set of keywords in the alarm event text and the set of keywords associated with the feature nodes.

[0035] Semantic similarity calculation considers not only literal keyword matching but also incorporates their co-occurrence probability in historical fault cases as a weighting factor. Co-occurrence probability refers to the statistical frequency of two keywords appearing simultaneously in the same historical fault case description. For a keyword in an alarm event and a keyword in a feature node, the event matcher queries the historical fault case database to calculate the proportion of cases where they co-occur to the total number of cases. This co-occurrence probability is integrated into the semantic similarity calculation, ensuring that keyword pairs frequently mentioned together in history, even if not literally identical, can achieve high similarity scores. When the semantic similarity calculated by the event matcher exceeds a preset threshold, it determines that the alarm event is highly correlated with a specific feature node in the fault feature evolution graph. The event matcher sends a trigger signal to the root cause inference model, containing the identifier of the matched feature node. Upon receiving the trigger signal, the root cause inference model initiates a recalculation process for the contribution of the associated feature node. This recalculation process considers information from new alarm events and may adjust the historical trigger frequency of related feature nodes. Alternatively, the weights of the feature evolution edges can be re-evaluated. Then, the dynamic weighting coefficients are recalculated according to the formula. The root cause reasoning model updates the order of potential root cause chains based on the recalculation results, ensuring that diagnostic results reflect the latest changes in the equipment's condition. The final output of the potential root cause chains is then passed to the system user interface or relevant maintenance decision support systems to provide prioritization guidance for maintenance actions.

[0036] Example 4: The data quality evaluator continuously monitors the standardized equipment status sequence output from the edge computing node. This standardized equipment status sequence is a structured data stream generated by the edge computing node after timestamp alignment and outlier cleansing of the raw industrial equipment sensor data. The data quality evaluator performs multi-dimensional quality assessments on the standardized equipment status sequence, including data integrity, temporal continuity, and numerical reasonableness. The data quality evaluator calculates the proportion of missing values ​​in the sequence; missing value identification is achieved by analyzing the interval patterns of timestamps. The data quality evaluator checks the time difference between consecutive data points; when the time difference exceeds a preset sampling interval tolerance, it determines that there is data missing in that time interval. Data integrity is quantified by the proportion of missing values, calculated as the ratio of the number of missing time points to the total expected number of time points. The data quality evaluator compares the calculated proportion of missing values ​​with a preset tolerance threshold. The tolerance threshold is set hierarchically according to equipment type and parameter importance; the tolerance threshold is lower for vibration data of critical equipment and higher for temperature data of auxiliary equipment.

[0037] When the proportion of missing values ​​in a standardized equipment status sequence exceeds a tolerance threshold, the data quality evaluator activates a redundant data source switching mechanism. This mechanism aims to obtain data from backup data acquisition points to fill in missing sequence segments. The data quality evaluator queries the equipment topology database, which stores the network topology connections of all equipment in the industrial field, as well as the primary and backup data acquisition points configured for each device. The data quality evaluator retrieves a list of all available backup data acquisition points for the current device from the equipment topology database. It then searches the historical database to obtain data records from each backup data acquisition point that were synchronously monitored with the primary data acquisition point within a historical time period. Finally, the data quality evaluator calculates the historical data deviation rate between each backup data acquisition point and the primary data acquisition point. This historical data deviation rate is measured by statistically analyzing the average absolute error or root mean square error of the measurements of the same parameter from the two acquisition points.

[0038] The data quality evaluator compares the historical data deviation rates of each backup data collection point and selects the backup data collection point with the lowest historical data deviation rate as the supplementary data source. Table 1 shows a comparison example of the data quality evaluator selecting backup data sources, listing the comparison results of key parameters for three backup collection points: Table 1: Comparison of the Quality of Backup Data Collection Points Based on the comparison results in Table 1, the data quality evaluator selects the acquisition point BKP_02346, which has the lowest historical data deviation rate, as the data completion source. The data quality evaluator sends a command to the data acquisition system to switch the data stream input source from the primary acquisition point to the selected backup acquisition point. The data quality evaluator uses the data stream from the backup acquisition point to impute missing segments in the standardized equipment state sequence. The imputation method is selected based on the data type and missing pattern; linear interpolation or spline interpolation is used for continuous numerical parameters, and nearest neighbor imputation is used for categorical variables. The imputation algorithm considers the temporal characteristics of the data, maintaining the continuity and trend of the data points. The data quality evaluator smooths the imputed data segments to eliminate any abrupt changes that may be introduced by the imputation.

[0039] The data quality evaluator generates a repaired device status sequence, which is then sent to the multi-source data fusion engine for further processing. The repaired device status sequence includes data quality tags indicating which segments are original data and which segments have undergone interpolation and repair. The data quality evaluator records a complete repair log, including the start and end times of missing intervals, the identifiers of the backup collection points used, a description of the interpolation method, and the repaired quality assessment score. The data quality evaluator periodically performs data quality health checks, with the check cycle dynamically adjusted based on data importance. The data quality evaluator maintains a data quality scorecard, which quantitatively evaluates the data stream across four dimensions: completeness, accuracy, consistency, and timeliness. Each dimension is assigned a weight, and a weighted average is used to calculate the overall data quality score. The data quality score is displayed in real-time on a monitoring dashboard, and an alert is triggered when the score falls below a threshold.

[0040] The data quality evaluator establishes a two-way communication channel with edge computing nodes. When persistent data quality issues are detected, it sends a quality report to the edge computing nodes. The edge computing nodes adjust their data acquisition strategies based on the quality report, such as increasing the sampling frequency, adjusting filtering parameters, or restarting the data acquisition service. This feedback mechanism forms a closed-loop system for data quality control, progressively optimizing the quality of source data. A redundant data source switching mechanism supports automatic fault recovery. When the primary data acquisition point resumes normal operation, the data quality evaluator checks the stability of the primary data acquisition point's data quality. The evaluator compares the real-time data deviation between the primary data acquisition point and the currently used backup acquisition point. When the data quality of the primary data acquisition point consistently meets the standards and is consistent with the backup acquisition point's data, the evaluator automatically switches the data stream back to the primary data acquisition point. The switching process employs a smooth transition strategy to avoid sudden data stream jumps affecting downstream analysis components.

[0041] The data quality evaluator is implemented using a microservice architecture, interacting with other system components via a RESTful API. Its configuration information is stored in an external configuration center, allowing for dynamic adjustment of quality evaluation rules and tolerance thresholds at runtime. The evaluator's operational status is integrated into a unified system monitoring framework, with monitoring metrics including service response time, memory usage, and data processing throughput. Designed as a stateless service, the evaluator supports horizontal scaling to handle real-time quality evaluation needs from large-scale device data streams. The data quality metadata generated by the evaluator is persistently stored in a time-series database, which can be used for long-term data quality trend analysis and data acquisition system optimization. The evaluator provides data quality report generation capabilities, regularly generating daily, weekly, and monthly reports to help managers understand the overall health of their data assets. Finally, the evaluator integrates with the enterprise's data governance platform, incorporating device data quality information into the enterprise-level data governance system.

[0042] Example 5: The version controller, acting as the management module of the system knowledge base, is responsible for tracking the evolution of fault diagnosis knowledge, ensuring that the fault feature evolution map is continuously optimized as new fault cases are confirmed. The version controller monitors the potential root cause chains output by the root cause reasoning model, which is an ordered list of inferences generated by the model after analyzing the current abnormal equipment state. The version controller provides a human-machine interface through which maintenance engineers review potential root cause chains and confirm the correct root cause. After completing equipment maintenance and determining the true root cause of the fault, the maintenance engineer selects the feature node combination that matches the actual situation on the interface and clicks the confirmation button to submit feedback. The version controller captures this confirmation action and extracts the feature node combinations contained in the confirmation result. A feature node combination is a collection containing the identifiers of the feature nodes confirmed as the root cause and their associated relationships. The version controller inserts the confirmed feature node combination as a new fault case into the historical fault case library. The insertion operation follows a strict case template; the new case record includes fields such as case number, equipment identifier, fault occurrence time, feature node combination, maintenance measure description, and resolution time. Case numbers are generated using timestamp hash values ​​to ensure uniqueness, device identifiers are associated with specific physical device files, and fault occurrence times are accurate to the millisecond level. The feature node combination field stores a list of confirmed feature node IDs and their weight relationships in this fault. Maintenance action descriptions record the repair actions taken in structured text, and the resolution timestamp marks the moment the fault was eliminated.

[0043] The historical fault case library uses a distributed database for storage, supporting high-concurrency read / write operations and data version management. The version controller creates a version tag for each newly inserted case, which is associated with the system's timestamp and update batch. A multi-dimensional index is built into the historical fault case library, using keywords such as device type, fault mode, and time range to accelerate subsequent case retrieval. The version controller triggers the reconstruction process of the fault feature evolution graph. This reconstruction process is executed by the fault feature mining component, which sends a graph update instruction containing the identifier of the newly inserted case. The fault feature mining component loads all case data from the historical fault case library, including newly confirmed cases and all historical cases. The component re-analyzes the relationships between feature nodes in all cases, calculating the correlation strength between them. The edge weight reconstruction of the fault feature evolution graph is based on the co-occurrence frequency and causal relationship strength of feature nodes in the cases. The component counts the number of times any two feature nodes co-occur in all historical cases; a higher co-occurrence frequency indicates a stronger correlation between the two feature nodes. The component analyzes the chronological order of feature nodes in the time series to determine the causal direction between nodes. The fault feature mining component uses statistical learning methods to calculate the weight values ​​of feature evolution edges. These weight values ​​reflect the probabilistic strength of the influence between feature nodes. The version controller maintains the version history of the fault feature evolution graph. After each graph reconstruction, the version controller archives a snapshot of the old version and records a version change log. The version change log details each update, including the number of new cases, the list of affected feature nodes, and an overview of edge weight changes. The version controller supports graph version retrospective functionality, allowing users to view the graph status at any historical point in time and compare differences between different versions.

[0044] The version controller implements an incremental update mechanism. When the number of new cases is small, an incremental algorithm is used to update the graph edge weights, avoiding the computational overhead of full reconstruction. The incremental update algorithm locally adjusts the weights of relevant edges based on the characteristic node relationships of new cases, maintaining the stability of the overall graph structure. The version controller sets trigger conditions for full reconstruction. When the number of new cases reaches a threshold or the time interval reaches a set period, the complete graph reconstruction process is initiated. Collaboration between the version controller and other system components is achieved through a message queue. The version controller subscribes to the result topic of the root cause reasoning model and listens for manual confirmation messages. Upon receiving a confirmation message, the version controller initiates the case entry process. The version controller publishes graph update notifications. After receiving the notification, the digital twin mapper and the root cause reasoning model reload the latest version of the fault feature evolution graph, ensuring the consistency of the knowledge bases of all system components. The version controller provides a graph quality assessment function, monitoring quality indicators during the graph iteration process. Quality indicators include topological features such as the number of nodes, edge density, and clustering coefficients of the graph, as well as the trend of graph accuracy changes in fault diagnosis. Version controllers visualize quality metrics, helping system administrators understand the evolution of the knowledge base.

[0045] The version controller's data persistence layer employs a multi-replica storage strategy to prevent data loss. The version controller periodically backs up the historical fault case library and fault feature evolution graph, with the backup data encrypted and stored on storage nodes in different physical locations. The version controller implements a data recovery process, enabling rapid recovery of knowledge base data from backups in the event of system failure. The version controller's update strategy supports configurable adjustments; system administrators can set parameters such as the review process for case entry, the trigger conditions for graph reconstruction, and version retention policies. The version controller's configuration information is stored in a separate configuration repository, supporting hot updates without requiring a service restart. The version controller records all configuration change history, meeting auditing requirements. The version controller's interface design conforms to RESTful specifications, providing API interfaces for case querying, version comparison, and graph export. External systems can access the system's knowledge base through the API interface, achieving integration with other enterprise knowledge management systems. The version controller's API interface employs authentication and access control to ensure secure access to knowledge base data. The implementation of the version controller enables the fault diagnosis system to continuously learn, optimizing the accuracy of the fault feature evolution graph by constantly absorbing new fault cases. Version controllers ensure that the evolution of the system's knowledge base is traceable and manageable, meeting the high requirements of industrial applications for system reliability and maintainability. As a core component of the system's knowledge cycle, the version controller completes a closed-loop feedback loop from data to knowledge and from knowledge to diagnostics.

[0046] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0047] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A device failure root cause analysis system integrating Internet of Things (IoT) data, characterized in that, include: Edge computing nodes are used to receive real-time operating data streams from industrial equipment, perform timestamp alignment and outlier cleanup on the data streams, and generate standardized equipment status sequences. The multi-source data fusion engine is used to align standardized equipment status sequences with environmental monitoring data and equipment maintenance logs in time and space, and to establish cross-data source association mapping relationships through entity recognition technology to form a multi-dimensional equipment operation status matrix. The fault feature mining component is used to extract equipment vibration spectrum features, temperature gradient change features, and energy consumption fluctuation features from the multi-dimensional equipment operating state matrix, and combine them with feature tags in the historical fault case library to construct a fault feature evolution map. A digital twin mapper is used to generate a virtual entity of the equipment based on the parameters of the equipment's 3D model and real-time operating data. A fault feature evolution map is synchronously loaded into the virtual entity to form a fault feature projection with spatiotemporal markers. The root cause reasoning model is used to analyze the propagation path of different feature nodes in the fault feature projection. It calculates the contribution of each feature node to the current abnormal state of the equipment through a dynamic weight allocation algorithm and outputs the potential root cause chain sorted by contribution.

2. The device failure root cause analysis system integrating IoT data according to claim 1, characterized in that, When the multi-source data fusion engine performs data alignment: The coordinates of temperature and humidity sampling points in the collected environmental monitoring data are matched with the physical location coordinates in the equipment status sequence using a grid. Extract timestamps and operation types from equipment maintenance logs and map them to the corresponding time intervals of standardized equipment status sequences; When maintenance operation records are detected within the same time interval, the maintenance event impact window is marked in the device status sequence.

3. The device failure root cause analysis system integrating IoT data according to claim 1, characterized in that, When the fault feature mining component constructs the fault feature evolution map: Wavelet packet decomposition is performed on the vibration spectrum characteristics of the equipment, and the energy proportion of each frequency band is extracted as the first-level feature node. Calculate the diffusion rate of temperature gradient change features in the thermal imaging map of the device surface, and generate second-level feature nodes; Identify the deviation between energy consumption fluctuation characteristics and equipment load curves, and establish third-level feature nodes; The three-level feature nodes are connected along the time dimension to form feature evolution edges with directional weights.

4. The device failure root cause analysis system integrating IoT data according to claim 3, characterized in that, When the digital twin mapper generates a projection of fault features: Divide the feature-bearing region in the 3D mesh model of the virtual device entity; The first-level feature nodes are mapped to the corresponding mesh of the device transmission components, and the second-level feature nodes are mapped to the corresponding mesh of the heat dissipation structure. Based on the directional weights of the feature evolution edges, feature propagation trajectories of different colors are rendered in the virtual entity.

5. The device failure root cause analysis system integrating IoT data according to claim 1, characterized in that, When the root cause reasoning model calculates the contribution: Traverse all feature nodes in the fault feature projection and record the shortest path from each node to the current abnormal state node. Statistically analyze the trigger frequency of each characteristic node as a root cause in the historical failure case database; Dynamic weight coefficients are generated by integrating path length and trigger frequency to perform topological sorting of potential root cause chains.

6. The device failure root cause analysis system integrating IoT data according to claim 5, characterized in that, The root cause reasoning model also includes: The real-time monitoring module is used to capture newly generated alarm events in the equipment control system; An event matcher is used to perform semantic similarity matching between alarm event description text and feature nodes in the fault feature evolution graph. When the matching degree exceeds the set threshold, the root cause reasoning model is triggered to recalculate the contribution of the associated feature nodes.

7. The device failure root cause analysis system integrating IoT data according to claim 6, characterized in that, When the event matcher performs semantic similarity matching: Extract device component names and keywords related to abnormal phenomena from the alarm event description text; Retrieve feature nodes containing the same keywords in the fault feature evolution map; The co-occurrence probability of keywords in historical failure cases is calculated and used as a weighting factor for semantic similarity.

8. The device failure root cause analysis system integrating IoT data according to claim 1, characterized in that, Also includes: A data quality evaluator is used to detect standardized device status sequences output by edge computing nodes; When the proportion of missing values ​​in a sequence exceeds the tolerance threshold, the redundant data source switching mechanism is activated. Missing segments are filled in by using homogeneous data streams from adjacent devices, generating a repaired device status sequence.

9. The device failure root cause analysis system integrating IoT data according to claim 8, characterized in that, When the data quality evaluator activates the redundant data source switching mechanism: Query the backup data collection points for the current device in the device topology database; Compare the historical data deviation rates between each backup data collection point and the main data collection point; The data stream from the backup acquisition point with the smallest deviation rate is selected for missing value imputation.

10. The device failure root cause analysis system integrating IoT data according to claim 1, characterized in that, Also includes: Version controller, used to manage the iterative updates of the fault feature evolution map; When the potential root cause chain output by the root cause reasoning model is manually confirmed, the combination of feature nodes in the confirmation result is extracted. The confirmed feature node combinations are inserted as new cases into the historical fault case library, and the edge weights of the feature evolution graph are reconstructed.

Images