Fault determination methods, electronic devices, storage media and computer program products

By constructing a standard behavioral baseline and parameter dependency graph, dynamic alarm thresholds are obtained, solving the problems of invalid and duplicate alarms in traditional alarm systems, and achieving accurate fault identification and effective alarms.

CN122309212APending Publication Date: 2026-06-30SHENZHEN ZTE NETVIEW TECH

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHENZHEN ZTE NETVIEW TECH
Filing Date
2026-03-31
Publication Date
2026-06-30

AI Technical Summary

Technical Problem

Traditional alarm systems tend to generate a large number of invalid and duplicate alarms in large-scale, highly complex equipment clusters. Fixed threshold judgment methods are difficult to adapt to equipment aging and changes in operating conditions. In multi-parameter coupled scenarios, the threshold adaptability is insufficient, making it difficult to detect critical alarms in a timely manner.

Method used

By collecting equipment operation data, a standard behavioral baseline is constructed, the anomaly confidence level is determined, a parameter dependency graph is generated, and a dynamic alarm threshold is obtained. Combined with the abnormal data, fault alarm information is generated, thereby achieving accurate location and effective alarm for abnormal data.

Benefits of technology

It effectively filters out invalid alarms, prevents critical alarms from being overwhelmed, and achieves adaptability to equipment aging and changes in operating conditions, thereby improving the accuracy and efficiency of fault identification.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122309212A_ABST
    Figure CN122309212A_ABST
Patent Text Reader

Abstract

This application discloses a fault determination method, electronic device, storage medium, and computer program product, relating to the field of intelligent alarm and fault prediction technology. The method includes: collecting equipment operation data of the device under test; constructing a standard behavior baseline based on standard operation data in the equipment operation data; comparing the equipment operation data with the standard behavior baseline to determine the anomaly confidence level of the equipment operation data; extracting data dependencies between the equipment operation data; generating a parameter dependency graph based on the data dependencies; determining abnormal data in the device under test based on the parameter dependency graph and the anomaly confidence level; obtaining the dynamic alarm threshold of the device under test; generating and outputting fault alarm information based on the dynamic alarm threshold and the abnormal data. This application solves the technical problem of poor fault identification performance.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of intelligent alarm and fault prediction technology, and in particular to a fault determination method, electronic device, storage medium and computer program product. Background Technology

[0002] As the scale and complexity of equipment clusters continue to expand, traditional alarm systems are revealing significant limitations during operation. In large-scale, highly complex equipment clusters, traditional alarm systems are prone to generating a large number of invalid and duplicate alarms. Invalid alarms often stem from momentary fluctuations in sensor data and configuration errors, while duplicate alarms occur because the same fault is repeatedly triggered by multiple monitoring modules, overwhelming maintenance personnel with massive amounts of redundant information and making it difficult to detect critical alarms in a timely manner. Meanwhile, existing optimization solutions, particularly those using fixed thresholds, struggle to adapt to equipment aging and changing operating conditions, and their threshold adaptability is insufficient in multi-parameter coupled scenarios. Therefore, current alarm and fault prediction technologies suffer from poor fault identification performance.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide a fault determination method, electronic device, storage medium, and computer program product, which aims to solve the technical problem of poor fault identification performance.

[0005] To achieve the above objectives, this application proposes a fault determination method, which includes: Collect equipment operation data of the device under test, construct a standard behavior baseline based on the standard operation data in the equipment operation data, and compare the equipment operation data with the standard behavior baseline to determine the anomaly confidence level of the equipment operation data; Extract the data dependencies between the device operation data, and generate a parameter dependency graph based on the data dependencies; Abnormal data in the device to be detected are determined based on the parameter dependency graph and the anomaly confidence level. Obtain the dynamic alarm threshold of the device under test, generate fault alarm information based on the dynamic alarm threshold and the abnormal data, and output it.

[0006] In one embodiment, the step of determining the abnormal data in the device under test based on the parameter dependency graph and the anomaly confidence score includes: The abnormal confidence level is used as a weighting factor to perform correlation mining on the equipment operation data, and target data objects with abnormal confidence levels higher than a preset confidence threshold are selected from the equipment operation data. Using the data dependencies in the parameter dependency graph as constraints, cluster analysis is performed on the target data object to generate abnormal data in the device to be detected.

[0007] In one embodiment, the step of obtaining the dynamic alarm threshold of the device under test includes: Acquire the operating characteristics and aging data of the device under test; The aging coefficient of the device under test is calculated based on the aging data, and the operating condition adaptation coefficient of the device under test is generated based on the operating condition characteristics and the aging data. The dynamic alarm threshold of the device under test is generated based on the operating condition adaptation coefficient and the equipment aging coefficient.

[0008] In one embodiment, the fault determination method further includes: The fault risk value of the device under test is determined based on the abnormal data. Based on the fault risk value, an early warning message is generated indicating that the device under test will fail within a preset time interval in the future.

[0009] In one embodiment, the step of determining the fault risk value of the device under test based on the abnormal data includes: Based on the abnormal data, identify the fault information of the device under test, extract the fault type from the fault information, select the target prediction model corresponding to the fault type from each preset fault prediction model to perform fault prediction, and generate fault prediction results. Obtain the dynamic factors of the fault prediction results, and determine the dynamic weights of the fault prediction results based on the dynamic factors. Based on the dynamic weights, the fault prediction results are fused to generate a fault risk value.

[0010] In one embodiment, the fault prediction result includes at least one of a first fault prediction result, a second fault prediction result, and a third fault prediction result; The step of selecting a target prediction model corresponding to the fault type from various preset fault prediction models to perform fault prediction and generate fault prediction results includes at least one of the following: When the fault type includes linear faults and / or periodic faults, the faults with linear trends and periodicity in the abnormal data are analyzed based on the first preset fault prediction model to generate a first fault prediction result. When the fault type includes multi-parameter linear faults, the faults caused by multi-parameter linear correlations in the abnormal data are analyzed based on the second preset fault prediction model to generate a second fault prediction result. When the fault type includes nonlinear faults, the faults with nonlinear relationships in the abnormal data are analyzed based on the third preset fault prediction model to generate a third fault prediction result.

[0011] In one embodiment, the dynamic factors include model performance factors, fault type matching factors, and data quality factors; The step of obtaining the dynamic factors of the fault prediction result and determining the dynamic weights of the fault prediction result based on the dynamic factors includes: The model performance factor is determined based on the performance of each preset fault prediction model within a preset time period. The fault type matching factor is determined based on the matching degree between the abnormal data and each preset fault prediction model. The data quality factor is determined based on the completeness and stability of the abnormal data. The model performance factor, the fault type matching factor, and the data quality factor are input into a preset meta-model to generate dynamic weights for the fault prediction results.

[0012] Furthermore, to achieve the above objectives, this application also proposes a fault determination system, which includes: The baseline comparison module is used to collect the device operation data of the device under test, construct a standard behavior baseline based on the standard operation data in the device operation data, and compare the device operation data with the standard behavior baseline to determine the anomaly confidence level of the device operation data. The graph generation module is used to extract the data dependencies between the device operation data and generate a parameter dependency graph based on the data dependencies. An anomaly determination module is used to determine abnormal data in the device under test based on the parameter dependency graph and the anomaly confidence level. The fault alarm module is used to obtain the dynamic alarm threshold of the device under test, generate fault alarm information based on the dynamic alarm threshold and the abnormal data, and output it.

[0013] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the fault determination method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the fault determination method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the fault determination method described above.

[0016] This application provides a fault determination method, which includes: collecting equipment operation data of the device under test; constructing a standard behavior baseline based on standard operation data in the equipment operation data; comparing the equipment operation data with the standard behavior baseline to determine the anomaly confidence level of the equipment operation data; extracting data dependencies between the equipment operation data; generating a parameter dependency graph based on the data dependencies; determining abnormal data in the device under test based on the parameter dependency graph and the anomaly confidence level; obtaining the dynamic alarm threshold of the device under test; generating and outputting fault alarm information based on the dynamic alarm threshold and the abnormal data.

[0017] This application solves the problems of traditional alarm systems relying on fixed thresholds and difficulty in distinguishing between instantaneous fluctuations and real anomalies by collecting equipment operation data, constructing a standard behavior baseline based on standard operation data, and comparing real-time data with the baseline to determine the anomaly confidence level. This enables a quantitative assessment of the severity of anomalies. By extracting the dependencies between data and generating a parameter dependency graph, this application solves the problems of single-parameter analysis being unable to locate the root cause of the fault and the lack of correlation analysis, and constructs the correlation logic between parameters. By collaboratively identifying abnormal data based on the parameter dependency graph and anomaly confidence level, this application solves the problem of isolated and unlinkable results of multiple algorithms in existing solutions, and achieves an effective integration of anomaly detection and correlation analysis. By acquiring dynamic alarm thresholds and combining them with abnormal data to generate and output fault alarm information, this application solves the problems of fixed thresholds being unable to adapt to equipment aging and changes in operating conditions, and insufficient threshold adaptability in multi-parameter coupling scenarios, and achieves accurate identification and effective alarm of existing faults. Compared to related solutions, which often suffer from limitations such as fixed thresholds failing to adapt to equipment aging and changes in operating conditions, insufficient threshold adaptability in multi-parameter coupled scenarios, and the tendency for invalid and duplicate alarms to overwhelm critical information, this application addresses these limitations by constructing a standard behavioral baseline and generating anomaly confidence levels. This effectively filters invalid alarms caused by instantaneous sensor fluctuations and configuration errors, preventing critical alarms from being overwhelmed by massive amounts of redundant information. By generating parameter dependency graphs and conducting collaborative analysis with anomaly confidence levels, it overcomes the limitations of single-parameter detection, achieving precise location of abnormal data. Furthermore, by introducing dynamic alarm thresholds, it overcomes the shortcomings of fixed thresholds in adapting to equipment aging and changes in operating conditions, maintaining threshold adaptability in multi-parameter coupled scenarios. This solves the current technical problem of poor fault identification performance, transforming traditional coarse-grained alarms based on fixed rules into precise alarms based on dynamic analysis and collaborative mechanisms. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the fault determination method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the fault determination method of this application; Figure 3 This is a system architecture diagram of the fault determination method provided in Embodiment 2 of this application; Figure 4 This is a schematic diagram of the module structure of the fault determination system according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the fault determination method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the first embodiment described herein is merely used to explain the technical solution of this application and is not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of the first embodiment of this application is as follows: collect the device operation data of the device under test, construct a standard behavior baseline based on the standard operation data in the device operation data, compare the device operation data with the standard behavior baseline, and determine the anomaly confidence of the device operation data; extract the data dependency relationship between the device operation data, and generate a parameter dependency graph based on the data dependency relationship; determine the abnormal data in the device under test based on the parameter dependency graph and the anomaly confidence; obtain the dynamic alarm threshold of the device under test, and generate and output fault alarm information based on the dynamic alarm threshold and the abnormal data.

[0025] In the first embodiment, for ease of description, the following description will focus on the fault determination system as the executing entity.

[0026] As the scale and complexity of device clusters continue to expand, traditional alarm systems are revealing significant limitations during operation. In large-scale, highly complex device clusters, traditional alarm systems are prone to generating a large number of invalid and duplicate alarms. Invalid alarms often stem from instantaneous fluctuations in sensor data and configuration errors, while duplicate alarms occur because the same fault is repeatedly triggered by multiple monitoring modules, overwhelming maintenance personnel with massive amounts of redundant information and making it difficult to detect critical alarms in a timely manner. Meanwhile, existing optimization solutions, particularly those using fixed thresholds, struggle to adapt to equipment aging and changing operating conditions, and their threshold adaptability is insufficient in multi-parameter coupled scenarios.

[0027] This application provides a solution that collects equipment operation data, constructs a standard behavior baseline based on standard operation data, and compares real-time data with the baseline to determine the anomaly confidence level. This solves the problems of traditional alarm systems relying on fixed thresholds and difficulty in distinguishing between instantaneous fluctuations and real anomalies, enabling quantitative assessment of the severity of anomalies. By extracting the dependencies between data and generating a parameter dependency graph, it solves the problems of single-parameter analysis being unable to locate the root cause of the fault and the lack of correlation analysis, and constructs the correlation logic between parameters. Based on the parameter dependency graph and the anomaly confidence level, it collaboratively determines abnormal data, solving the problem of isolated and unlinkable results of multiple algorithms in existing solutions, and achieving effective integration of anomaly detection and correlation analysis. It obtains dynamic alarm thresholds and combines them with abnormal data to generate and output fault alarm information, solving the problems of fixed thresholds being unable to adapt to equipment aging and changes in operating conditions, and insufficient threshold adaptability in multi-parameter coupling scenarios, and achieving accurate identification and effective alarm of existing faults. Compared to related solutions, which often suffer from limitations such as fixed thresholds failing to adapt to equipment aging and changes in operating conditions, insufficient threshold adaptability in multi-parameter coupled scenarios, and the tendency for invalid and duplicate alarms to overwhelm critical information, this application addresses these limitations by constructing a standard behavioral baseline and generating anomaly confidence levels. This effectively filters invalid alarms caused by instantaneous sensor fluctuations and configuration errors, preventing critical alarms from being overwhelmed by massive amounts of redundant information. By generating parameter dependency graphs and conducting collaborative analysis with anomaly confidence levels, it overcomes the limitations of single-parameter detection, achieving precise location of abnormal data. Furthermore, by introducing dynamic alarm thresholds, it overcomes the shortcomings of fixed thresholds in adapting to equipment aging and changes in operating conditions, maintaining threshold adaptability in multi-parameter coupled scenarios. This solves the current technical problem of poor fault identification performance, transforming traditional coarse-grained alarms based on fixed rules into precise alarms based on dynamic analysis and collaborative mechanisms.

[0028] It should be noted that the executing entity in the first embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, or other electronic device, or a system, application, or program capable of implementing the above functions. The first embodiment and the following embodiments will be described using a fault determination system as an example.

[0029] All actions involving the acquisition of signals, information, or data in this application are carried out in accordance with the relevant data protection laws and policies of the country where the application is located, and with the authorization of the owner of the relevant device.

[0030] Based on this, embodiments of this application provide a fault determination method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the fault determination method of this application.

[0031] In this embodiment, the fault determination method includes steps S01 to S04: Step S01: Collect the equipment operation data of the device under test, construct a standard behavior baseline based on the standard operation data in the equipment operation data, and compare the equipment operation data with the standard behavior baseline to determine the anomaly confidence level of the equipment operation data; It should be noted that the device under test refers to the physical or logical entity included in the monitoring scope, including various IT equipment, industrial equipment, and infrastructure equipment such as servers, network devices, cooling systems, and battery packs. Device operation data refers to the raw state parameters collected from the device under test, which may include indicators such as voltage, current, temperature, and load rate, covering multi-dimensional information such as the device's operating status, environmental conditions, and workload. Standard operating data is a set of device operation data samples collected during historical periods when the device under test is fault-free and operating stably, capable of characterizing the normal behavioral characteristics of the device. The standard behavior baseline is a standard reference model built based on the standard operating data using algorithms such as clustering (e.g., DBSCAN (Density-Based Spatial Clustering of Applications with Noise)) to characterize the normal operating mode of the device under test. It defines the reasonable value range and fluctuation pattern of each operating parameter of the device under test under normal conditions. Anomaly confidence is a quantitative indicator obtained by comparing the device operation data with the standard behavior baseline, used to characterize the degree to which the current data deviates from the normal pattern. The higher the confidence value, the greater the probability that the data is abnormal.

[0032] Additionally, it's worth noting that device operation data can be collected through a distributed architecture that aggregates data from edge nodes and the cloud. First, the system supports access from core devices such as IT equipment, industrial equipment, and infrastructure equipment. It is compatible with multiple protocols, including SNMP (Simple Network Management Protocol version), Modbus RTU / TCP (Modbus is an industrial communication protocol, RTU is a remote terminal unit, a binary transmission mode, and TCP is a transmission control protocol, an Ethernet-based implementation), and the data sampling frequency is configurable. The collected parameters cover indicators such as voltage, current, and temperature to ensure the comprehensiveness and accuracy of the data source. Subsequently, the locally deployed edge computing gateway performs data preprocessing operations, using Kalman filtering to remove sensor noise, uniformly converting the data format, and removing outliers based on statistical principles (such as the 3σ principle) to filter out transient fluctuations. Simultaneously, edge nodes provide local caching functionality, caching data when the link is interrupted and automatically retransmitting it upon recovery. It also supports rapid local alarms for emergency faults, with response latency controlled within milliseconds. During data transmission, TCP+SSL (Secure Sockets Layer) / TLS (Transport Layer Security) encrypted transmission protocols are used to ensure security, and bandwidth adaptive capability is provided. When the network bandwidth is lower than the preset bandwidth threshold (e.g., 1Mbps), the data is automatically compressed to balance transmission efficiency and stability.

[0033] For example, when constructing a standard behavior baseline, firstly, standard operating data samples of the device under test in a fault-free and stable operating state are selected from historical operating data. Clustering algorithms are then used to perform cluster analysis on these samples, forming multiple data clusters representing the normal behavior patterns of the device under test. The boundaries and density distribution of each data cluster together constitute the standard behavior baseline. Real-time collected device operating data is used as input, and the minimum distance or multidimensional deviation between the data and each data cluster in the standard behavior baseline is calculated. Statistical methods or clustering algorithms can be used to assess the degree of data anomaly, and a comprehensive anomaly confidence score is generated. For example, a density-based clustering algorithm is used to calculate the minimum distance between the device operating data and each data cluster, and to determine whether the device operating data falls within the density reachable range of any normal data cluster. If the distance between the device operating data and all normal data clusters is large (e.g., deviation exceeding 5%-15%), it indicates that it cannot be represented by existing normal patterns, and the clustering algorithm outputs a high anomaly score.

[0034] Additionally, it should be noted that data cleaning is required before comparing equipment operation data to obtain standardized data. The specific steps of data cleaning may include: using linear interpolation for periodic data and neighbor-filling for non-periodic data to handle missing values; combining the Z-score (standard score) algorithm and the Isolation Forest algorithm to filter outliers; and using Min-Max normalization to eliminate the influence of different parameters' dimensions.

[0035] Understandably, step S01, by constructing a standard behavioral baseline and comparing it with real-time data, determines the anomaly confidence level, thus solving the technical problem that traditional alarm systems rely on fixed thresholds and have difficulty distinguishing between instantaneous sensor fluctuations and real anomalies, and achieving a quantitative assessment of the severity of anomalies.

[0036] Step S02: Extract the data dependencies between equipment operation data and generate a parameter dependency graph based on the data dependencies; It should be noted that data dependency refers to the logical relationships between different parameters that influence and change together during the operation of the device under test. For example, when the CPU temperature of a server increases, its fan speed will increase accordingly. Parameter dependency graphs are a network of relationships formed by structuring all data dependencies mined from the device's operating data. They are used to display the mutual influence paths and correlation strengths between various operating parameters within the device under test.

[0037] For example, association rule algorithms are used to analyze preprocessed standardized data to uncover potential relationships between different parameters. For instance, the Apriori association rule algorithm is used to identify frequent combinations of parameters by calculating their support and confidence. For example, when "server CPU temperature exceeds the threshold" and "fan speed is abnormally low" occur simultaneously, they form a data dependency relationship. All uncovered data dependencies are then structured, with parameters as nodes and dependencies as edges, to construct a parameter dependency graph. For example, in a cooling system, a chain of associations such as "computer room temperature → air conditioning cooling capacity → compressor power → condenser pressure" can be formed, providing association constraints for subsequent anomaly localization.

[0038] Understandably, step S02, by extracting the dependencies between data and generating a parameter dependency graph, solves the problems of difficulty in locating the root cause of faults through single-parameter analysis and the lack of correlation analysis, thus constructing the correlation logic between parameters. Compared to the simple judgment based on isolated parameters in existing technologies, the above steps provide quantitative basis and correlation constraints for subsequent accurate identification of abnormal data.

[0039] Step S03: Determine the abnormal data in the device to be tested based on the parameter dependency graph and the anomaly confidence level; It should be noted that anomalous data refers to a subset of device operating data that, after anomaly detection and correlation analysis, is identified as deviating from normal behavior patterns and conforming to parameter dependency constraints. This subset represents data objects with potential problems. Fault alarm information is structured information generated based on anomalous data to indicate that a fault has occurred. It may include attributes such as fault type, scope of impact, and urgency. An occurred fault is an actual abnormal state currently existing in the device under test, such as a server CPU (Central Processing Unit) temperature continuously exceeding limits, network link interruption, or battery voltage below a safe threshold, confirmed by the fault alarm information.

[0040] In one feasible implementation, step S03 includes steps A01 to A02: Step A01: Use the anomaly confidence level as a weighting factor to perform correlation mining on the equipment operation data, and filter out target data objects whose anomaly confidence level is higher than the preset confidence level threshold from the equipment operation data; It should be noted that the weighting factor guides the association mining algorithm to prioritize data objects with a higher probability of anomalies. The preset confidence threshold is a critical value used to filter out outlier data. The target data object is a subset of data whose anomaly confidence meets the preset threshold condition; this subset is the core object of subsequent refined analysis.

[0041] Step A02: Using the data dependencies in the parameter dependency graph as constraints, perform cluster analysis on the target data objects to generate abnormal data in the device to be detected.

[0042] It's important to note that constraints are restrictive rules in cluster analysis, essentially representing the data dependencies contained in the parameter dependency graph. These constraints ensure that the clustering process only occurs within the range of parameters with genuine correlations, avoiding meaningless cross-parameter clustering. Cluster analysis, based on density-based clustering algorithms and guided by constraints, is a data grouping process that aggregates data points with similar anomalous characteristics from a target data object into several clusters. Cluster analysis generates a set of clusters, each representing a group of parameter combinations with common anomalous characteristics. This result represents the final identification of anomalous data in the device to be inspected.

[0043] For example, in server runtime data, only data points with an abnormal CPU temperature confidence level exceeding a threshold are selected for subsequent processing. This solves the problem of computational redundancy caused by the indiscriminate mining of all data in traditional methods, and achieves efficient allocation of computing resources. When the parameter dependency graph indicates a strong dependency between "CPU temperature" and "fan speed," the clustering algorithm only clusters the target data objects within this constraint, avoiding invalid clustering across parameter types.

[0044] Understandably, step S03, which uses parameter dependency graphs and anomaly confidence to collaboratively determine anomalous data, solves the technical problem of inaccurate fault location caused by the isolation and inability to link multiple algorithm results in existing solutions, and achieves effective integration of anomaly detection results and correlation analysis results.

[0045] Step S04: Obtain the dynamic alarm threshold of the device under test, generate fault alarm information based on the dynamic alarm threshold and abnormal data, and output it.

[0046] It should be noted that the dynamic alarm threshold is an adaptive threshold calculated by combining the equipment's operating condition characteristics and aging data, used to adapt to changes in the state of the equipment under test.

[0047] In one feasible implementation, step S04, the step of obtaining the dynamic alarm threshold of the device under test, includes steps A11 to A13: Step A11: Obtain the operating characteristics and aging data of the equipment under test; It should be noted that operating condition characteristics are dynamic parameters reflecting the current operating status and environmental conditions of the equipment under test, and may include dimensions such as operating condition stability, environmental change rate, and business load level. Aging data are multi-dimensional static parameters reflecting the performance degradation of the equipment under test during use, and may include equipment design life, actual operating years, equipment material type, historical average operating load rate, and environmental temperature and humidity correction factors.

[0048] For example, the operating conditions of the equipment under test are monitored in real time, and real-time operating data, environmental data, and business load data are collected every five minutes. Operating condition characteristics such as stability, environmental change rate, and business load are calculated through a sliding window. At the same time, aging data such as the design life, actual service life, material coefficient, average operating load rate, and environmental temperature and humidity correction coefficient of the equipment under test are acquired.

[0049] Step A12: Calculate the equipment aging coefficient of the device under test based on the aging data, and generate the operating condition adaptation coefficient of the device under test based on the operating condition characteristics and the aging data. It should be noted that the equipment aging coefficient is a quantitative indicator calculated based on aging data, used to characterize the degree of performance degradation of the equipment under test relative to its initial state. The operating condition adaptation coefficient is a dynamic adjustment factor output after joint analysis of operating condition characteristics and aging data, used to reflect the degree of adaptation that the threshold should undergo under the current operating conditions.

[0050] For example, a multi-dimensional factor can be introduced to calculate the equipment aging coefficient. These factors may include: equipment design life, actual operating years, equipment material coefficient (0.8-1.0 for metal, 1.0-1.2 for plastic, and 0.9-1.1 for composite materials), average operating load rate (1.2 for monthly average load rate >80%, 1.0 for 50%-80%, and 0.8 for <50%), and environmental temperature and humidity correction coefficient (1.1 for temperature >35℃ or humidity >80%, 1.0 for normal range, and 0.9 for low temperature and low humidity). The calculation formula can be:

[0051] in, The aging factor of the equipment. For the design life of the equipment, The actual number of years of operation. For equipment material coefficients, This represents the average operating load rate. This is a correction factor for ambient temperature and humidity. , , , Each indicator corresponds to a weight, preferably... , , , .

[0052] Additionally, it should be noted that the operating condition adaptation coefficient can be generated based on a preset coefficient generation model. This model can generate the operating condition adaptation coefficient of the device under test based on operating condition features and aging data. The preset coefficient generation model can be built based on the XGBoost (eXtreme Gradient Boosting) model, employing a gradient boosting tree architecture. It uses operating condition features and aging data as input features and the operating condition adaptation coefficient as the output target. During the model training phase, historical feature data of the device under test (including historically collected operating condition features and aging data) is collected. Adaptation coefficient labels are obtained through manual annotation or simulation. Mean squared error is used as the loss function. Preferably, the number of trees can be set to 100, the maximum depth to 6, and the learning rate to 0.1. The model is iteratively trained until convergence. Real-time collected operating condition features and aging data are input into the model, and the operating condition adaptation coefficient is output through weighted fusion of multiple decision trees.

[0053] Step A13: Generate the dynamic alarm threshold of the device under test based on the working condition adaptation coefficient and the equipment aging coefficient.

[0054] It should be noted that the preset benchmark threshold is multiplied by the equipment aging coefficient and the operating condition adaptation coefficient to calculate the dynamic alarm threshold. After the calculation is completed, the configuration is updated in real time through the API (Application Programming Interface), and the alarm situation is counted at preset clock intervals (e.g., 10 minutes). The rationality of the threshold is verified based on the false alarm rate and the missed alarm rate, and the fluctuation range is adjusted accordingly to optimize the model.

[0055] Additionally, it should be noted that different abnormal data correspond to different preset benchmark thresholds. By applying the equipment aging coefficient and operating condition adaptation coefficient based on the preset benchmark thresholds, the comparison thresholds for the equipment under test under aging and different operating conditions can be determined, thereby adapting to the current aging and / or operating condition scenarios and improving the accuracy of the comparison.

[0056] Additionally, it should be noted that during the startup phase of the device under test, the dynamic alarm threshold is automatically increased by the first preset percentage (e.g., 10%); during the maintenance window of the device under test, the threshold is relaxed by the second preset percentage (e.g., 20%); and in the event of a sudden failure of the device under test, the threshold is temporarily invalidated, directly triggering an emergency alarm.

[0057] For example, the generation of fault alarm information can be referenced in Table 1: Table 1

[0058] The alarm criteria are determined based on abnormal data and dynamic alarm thresholds to obtain corresponding fault alarm information. This information may include alarm level, response time requirement, notification method, and processing flow. Dynamic alarm thresholds correspond to alarm levels. For example, if the dynamic alarm threshold for abnormal data is 80%~100%, the corresponding alarm level is an emergency alarm. In this case, the fault may affect core business operations, leading to business interruption. Correspondingly, the fault alarm information includes: [Alarm Level: Emergency Alarm; Response Time Requirement: ≤5 minutes; Notification Method: Pop-up window in the operations and maintenance platform, SMS, telephone (3 retries), and instant message push in the operations and maintenance group; Processing Flow: Automatic fault isolation by the system; Operations and maintenance personnel respond within 5 minutes and arrive on-site within 30 minutes; Progress updated every 10 minutes].

[0059] It is understandable that step S04 obtains the dynamic alarm threshold, and generates and outputs fault alarm information in combination with abnormal data, which solves the technical problem that the fixed threshold judgment method is difficult to adapt to equipment aging and changes in operating conditions, and the threshold adaptability is insufficient in multi-parameter coupling scenarios.

[0060] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The fault determination method also includes steps S11-S12: Step S11: Determine the fault risk value of the device under test based on the abnormal data; It should be noted that the fault risk value is a quantitative indicator generated based on fault information identified from abnormal data. It represents the probability or risk level of the equipment under test failing in the future.

[0061] In one feasible implementation, step S11, which involves determining the fault risk value of the device under test based on abnormal data, includes steps B01 to B03: Step B01: Identify the fault information of the device under test based on abnormal data, extract the fault type from the fault information, select the target prediction model corresponding to the fault type from each preset fault prediction model to perform fault prediction, and generate fault prediction results. It should be noted that fault information is a description of the abnormal state of equipment extracted from abnormal data, used to characterize the abnormal phenomena that have occurred. Fault type refers to the result of classifying fault information, used to distinguish the characteristics and correlation patterns of faults, such as linear trend faults, multi-parameter correlation faults, or nonlinear coupling faults. The preset fault prediction model is a set of prediction models used to handle specific types of faults. The target prediction model is a specific prediction model selected from the preset fault prediction model set based on the current fault type. The fault prediction result is a quantitative prediction value output by the target prediction model after analyzing the abnormal data; it can be a future parameter change trend or the probability of fault occurrence, and can include a first fault prediction result, a second fault prediction result, and a third fault prediction result.

[0062] For example, the steps of identifying fault information of the device under test based on abnormal data and extracting fault types from the fault information may include: performing multi-dimensional time-series data feature analysis on the abnormal data, combining the parameter dependency graph generated by correlation analysis, identifying the correspondence between abnormal parameters and device functional modules, and obtaining fault information. For example, "server CPU temperature is consistently higher than the baseline value and fan speed does not increase synchronously" is identified as fault information of "decreased performance of the heat dissipation subsystem". Subsequently, based on the characteristics and causal mechanisms of the fault information, it is classified into a preset fault type. For example, if the fault parameter shows a monotonically increasing trend over time, it is classified as a linear fault; if the fault parameter shows a periodic change, it is classified as a periodic fault, such as battery voltage decreasing month by month; if the fault manifests as an imbalance between multiple parameters, such as an abnormal correlation between CPU temperature and fan speed and server room temperature, it is classified as a multi-parameter linear fault; if the fault involves multi-component coupling or the data shows non-stationary and non-periodic fluctuations, such as intermittent access errors of server memory chips, it is classified as a non-linear fault.

[0063] In one feasible implementation, the fault prediction result includes at least one of a first fault prediction result, a second fault prediction result, and a third fault prediction result. In step B01, a target prediction model corresponding to the fault type is selected from each preset fault prediction model to perform fault prediction. The step of generating the fault prediction result includes at least one of steps B011 to B013: Step B011: When the fault type includes linear faults and / or periodic faults, analyze the faults with linear trends and periodicity in the abnormal data based on the first preset fault prediction model to generate the first fault prediction result. It should be noted that linear faults refer to fault parameters that exhibit a monotonically increasing or decreasing pattern over time, such as the gradual decrease in battery voltage over usage time; periodic faults refer to fault parameters that exhibit a regular fluctuating pattern, such as the periodic change in the degree of clogging of an air conditioning filter with the changing seasons. The first preset fault prediction model is a time-series model used to process data with both linear trends and periodic characteristics. The first fault prediction result refers to the predicted value of the future parameter change trend output by the first preset fault prediction model, such as predicting that the battery voltage will drop to a critical threshold in the next 48 hours.

[0064] For example, a time-series prediction model is constructed based on historical standard operating data. This model adopts an Autoregressive Integrated Moving Average (ARIMA) architecture. The difference order is determined through a stationarity test, and the autoregressive and moving average orders are determined using autocorrelation and partial autocorrelation functions. After determining the model order, maximum likelihood estimation is used to train the model parameters. During training, the model learns the linear variation and periodic patterns of the parameters over time. Taking battery voltage degradation faults as an example, this model identifies the monthly linear decline trend based on historical voltage data and fits daily periodic fluctuations, ultimately outputting the predicted voltage value and degradation trend for a preset future period (e.g., 24 to 72 hours), achieving forward-looking prediction of this type of fault.

[0065] Step B012: When the fault type includes multi-parameter linear faults, analyze the faults caused by multi-parameter linear correlation in the abnormal data based on the second preset fault prediction model, and generate the second fault prediction result. It should be noted that multi-parameter linear failures are caused by an imbalance in the linear correlation between multiple parameters. For example, there is a linear correlation between abnormal server CPU temperature and fan speed, as well as data center temperature. Multi-parameter linear correlation refers to the linear statistical relationship between multiple parameters, which can be measured by the correlation coefficient. The second preset failure prediction model is a regression model used to analyze multi-parameter linear correlations. The second failure prediction result refers to the predicted parameter changes output by the second preset failure prediction model and an analysis of the degree of influence of each parameter. For example, predicting that the CPU temperature will rise to a specific value and identifying fan speed as the main influencing factor.

[0066] For example, a correlation prediction model is constructed based on a multiple linear regression architecture. During model construction, firstly, key feature parameters with a strong linear relationship to the target parameter are selected through correlation analysis. Then, using historical standard operating data, the regression coefficients of each feature parameter are estimated using the least squares method to complete model training. Taking server CPU temperature failure as an example, this model uses fan speed and server room temperature as feature parameters. By learning the historical correlation patterns between these three parameters and CPU temperature, when a decreasing trend in fan speed is detected, the model can predict the resulting increasing trend in CPU temperature, providing early warning of potential high-temperature failures.

[0067] Step B013: When the fault type includes nonlinear faults, analyze the faults with nonlinear relationships in the abnormal data based on the third preset fault prediction model, and generate the third fault prediction result.

[0068] It should be noted that nonlinear faults refer to fault parameters exhibiting non-stationary, non-periodic, or highly complex coupled change patterns, such as intermittent access errors in server memory chips or the wear process of CNC machine tool spindle bearings. The third preset fault prediction model is a recurrent neural network model used to capture long-term dependencies and nonlinear characteristics of data. The third fault prediction result refers to the predicted probability of future fault occurrence output by the third preset fault prediction model, such as predicting the probability of spindle bearing wear failure within a preset time period (e.g., 36 hours).

[0069] For example, a nonlinear prediction model can be constructed based on a recurrent neural network architecture, specifically using a Long Short-Term Memory (LSTM) network structure. During model construction, time-series data is converted into supervised learning samples using a sliding window method to determine the time step parameter. The model includes an input layer, an LSTM layer, and a fully connected output layer, where the LSTM layer learns long-term dependencies in the data through a gating mechanism. During training, the backpropagation algorithm is used to optimize the network weight parameters, enabling the model to capture the nonlinear variation patterns under multi-component coupling. Taking the wear failure of a CNC machine tool spindle bearing as an example, this model integrates time-series data of multiple parameters such as vibration, temperature, and load, learns the nonlinear coupling relationships between parameters, and finally outputs the predicted failure probability value within a preset future period (e.g., 1 to 3 hours), achieving accurate early warning for this type of complex failure.

[0070] Step B02: Obtain the dynamic factors of the fault prediction results, and determine the dynamic weights of the fault prediction results based on the dynamic factors. It should be noted that dynamic factors are multi-dimensional quantitative indicators used to evaluate the reliability and suitability of each fault prediction result, including model performance factors, fault type matching factors, and data quality factors. Dynamic weights are fusion coefficients of each fault prediction result calculated based on dynamic factors, used to reflect the relative importance of different prediction results during the fusion process.

[0071] In one feasible implementation, the dynamic factors include model performance factors, fault type matching factors, and data quality factors, and step B02 includes steps B021 to B024: Step B021: Determine the model performance factor based on the performance of each preset fault prediction model within a preset time period. It should be noted that the preset time period is a time window used to evaluate the predictive performance of each preset fault prediction model, such as the past 12 hours of operation. The accumulated prediction results and actual feedback data within this time period together form the basis for model performance evaluation. Performance refers to the comprehensive measure of the prediction accuracy of each preset fault prediction model within the preset time period, which may include two core indicators: prediction precision and recall. The model performance factor is a quantitative coefficient calculated based on the model's performance within the preset time period, used to characterize the model's recent prediction reliability.

[0072] For example, the performance of each preset fault prediction model is statistically analyzed within a preset time period. The preset time period adopts a sliding window mechanism, and the window length can be configured according to actual needs. For each preset fault prediction model, its prediction accuracy and recall within the window are calculated, and then a comprehensive score is calculated as a model performance factor. The calculation formula can be:

[0073] in, This is a model performance factor used to quantify the predictive reliability of each preset fault prediction model. To improve prediction accuracy, This refers to the recall rate.

[0074] Step B022: Determine the fault type matching factor based on the matching degree between the abnormal data and each preset fault prediction model; It should be noted that the matching degree is the degree of similarity between the feature distribution of abnormal data and the fault types adapted to each preset fault prediction model. The fault type matching degree factor is a quantitative coefficient calculated based on this matching degree. For example, when using the term frequency-inverse document frequency algorithm to analyze the degree of matching between the current data features and the fault types adapted to the model, for abnormal data showing linear trend characteristics, the matching degree factor of its time series model is higher, which can be 0.9, while the matching degree factor of the nonlinear model is relatively lower, which can be 0.6.

[0075] For example, feature vectors of abnormal data are extracted, and the similarity between the feature vectors and the fault type features adapted to each preset fault prediction model is calculated. The similarity calculation can be implemented using the term frequency-inverse document frequency algorithm. Taking abnormal battery voltage decay as an example, its feature vector has a high degree of matching with the linear trend fault type, so the matching factor with the time series prediction model approaches the upper limit; while if the abnormal data shows multi-parameter linkage characteristics, the matching factor with the regression prediction model is higher.

[0076] Step B023: Determine the data quality factor based on the completeness and stability of the outlier data; It's important to note that completeness refers to the degree of missing data in outliers, used to measure the completeness of data collection; a lower missing rate indicates higher completeness. Stationarity refers to the time-series stability of outlier data, determined by methods such as unit root tests to identify trends or periodic changes. The data quality factor is a quantitative coefficient calculated based on both completeness and stationarity, used to characterize the degree to which the input data supports the prediction results. For example, when the input data is complete and the test results are stationary, the data quality factor is 1.0; the factor value decreases accordingly for every 10% increase in the missing rate or when the data exhibits non-stationary characteristics.

[0077] For example, a completeness assessment is performed on the outlier dataset by calculating the proportion of missing values; completeness is negatively correlated with the proportion of missing values. Simultaneously, a stationarity test is conducted, using the Augmented Dickey-Fuller (ADF) test to determine the stationarity of the data sequence. The stationarity value can be binary or continuous. Taking a particular outlier dataset as an example, if its proportion of missing values ​​is low and it passes the stationarity test, the data quality factor tends to approach its upper limit; if the data is severely missing or exhibits non-stationary characteristics, the data quality factor decreases accordingly.

[0078] Step B024: Input the model performance factor, fault type matching factor, and data quality factor into the preset meta-model to generate dynamic weights for the fault prediction results.

[0079] It should be noted that the model performance factors, fault type matching factors, and data quality factors are standardized before being input into the meta-model. The meta-model employs a lightweight logistic regression architecture to determine the mapping relationship between dynamic factors and weights. During the training of the meta-model, historical prediction data is used as samples, and the prediction results of each base model and the actual occurrence of faults are used as labels. The model parameters are optimized through maximum likelihood estimation, enabling the meta-model to learn the mapping relationship between factors and optimal weights. After model training is completed, incremental updates are performed based on the latest prediction feedback at a first preset interval (e.g., 30 minutes). When consecutive prediction deviations occur, the corresponding model weights are automatically reduced. The model is retrained using full historical data at a second preset interval (e.g., one month), achieving continuous optimization and adaptive evolution of the meta-model.

[0080] Step B03: Based on the dynamic weighted fusion of fault prediction results, generate fault risk values.

[0081] For example, the dynamic weights and the corresponding fault prediction results are weighted and summed, and the summation result is mapped to a preset risk value range to obtain a normalized fault risk value.

[0082] In this embodiment, by identifying the fault type and selecting the corresponding prediction model, the problem of low prediction accuracy caused by the lack of matching and adaptation algorithms for different fault types in the existing solution is solved. The accurate correspondence between fault prediction and fault characteristics is achieved. By obtaining dynamic factors and determining dynamic weights, the problem of fixed weight fusion being unable to adapt to model performance fluctuations and changes in operating conditions is solved. Dynamic quantitative evaluation of the importance of prediction results is achieved. Based on the dynamic weight fusion of each prediction result to generate a fault risk value, the problem of isolated output of multiple algorithm results and difficulty in comprehensively evaluating fault risk is solved. The advantages of each prediction model are effectively integrated.

[0083] Step S12: Generate early warning information based on the fault risk value, indicating that the device under test will fail within a preset time interval in the future.

[0084] It should be noted that the fault warning information is a predictive output generated based on the fault risk value and dynamic alarm threshold. It is used to issue a warning before the fault actually occurs. It can include structured content such as risk level, future preset time interval (i.e., the time period in which the fault is expected to occur in the future) and suggested handling measures.

[0085] For example, the warning level is determined based on the fault risk value and the scope of fault impact in the fault alarm information. For instance, warnings are divided into three levels: Level 1 warnings (risk value > 90% and affecting core business) require immediate handling; Level 2 warnings (risk value 80%-90% or affecting non-core business) require handling within the first time period (e.g., 24 hours); and Level 3 warnings (risk value 70%-80% and no business impact) require attention within the second time period (e.g., 48 hours). The warning trigger delay is ≤ 1 minute, with the second time period being longer than the first. Based on the warning level, a corresponding multi-channel notification method is selected for warning notification, which may include pop-ups on the operations and maintenance platform, instant messaging push notifications, SMS, telephone, and email. Level 1 warnings utilize a multi-channel notification method and include a retry and backup responsible person switching mechanism.

[0086] Furthermore, fault features can be extracted from fault alarm information, matched with a historical fault case knowledge base using a cosine similarity algorithm, and combined with real-time operating condition optimization schemes to generate a structured solution that includes fault cause analysis, handling steps, required resources, risk warnings, and verification methods, which is then output along with the fault warning information. Simultaneously, the fault handling progress is tracked, and the effectiveness of equipment parameter verification is continuously monitored after the fault warning is handled. Within a preset period (e.g., one month), the accuracy of the warning, the timeliness of handling, and the fault recurrence rate are reviewed to optimize the model and knowledge base.

[0087] In this embodiment, fault risk values ​​are determined based on abnormal data, which solves the technical problem that existing prediction schemes do not match and adapt algorithms for different fault types, resulting in low prediction accuracy. It realizes the quantitative assessment of potential fault risks and generates early warning information within a preset time interval based on the fault risk values. This solves the technical problem that traditional methods cannot achieve a balance between massive data and real-time response and have insufficient prediction timeliness. It realizes the forward-looking prediction and timely warning of impending faults, effectively improving the accuracy and timeliness of fault prediction and solving the problem of poor current fault prediction performance.

[0088] For example, to aid in understanding the technical concept or principles of this application, please refer to Figure 3 Figure 3 shows the system architecture of the fault determination method, which is divided into five layers: data source layer, data acquisition layer, intelligent processing layer, decision execution layer, and output layer. The data source layer covers IT equipment, industrial equipment, and infrastructure equipment, and is compatible with protocols such as SNMP / Modbus / MQTT (Message Queuing Telemetry Transport, a lightweight IoT messaging protocol). The data acquisition layer first performs preprocessing at edge nodes, including Kalman filtering, format conversion, and outlier removal. Then, data is transmitted via encrypted transmission and bandwidth adaptation (e.g., TCP+SSL / TLS, 50% compression rate), followed by cloud aggregation and local caching, providing 24-hour caching capability. The intelligent processing layer consists of three parts: a data analysis engine for cleaning, correlation, trend analysis, and anomaly detection, using Spark Streaming (Apache Spark). The system employs a multi-algorithm fusion prediction approach, combining ARIMA, regression, LSTM, and weighted fusion to achieve early warnings. The decision execution layer is responsible for four-level alarm response (e.g., emergency, important, general, alert), three-level warning push (multi-channel notification and retry mechanism), and intelligent solution generation (based on knowledge base and closed-loop management). Finally, the output layer provides accurate alarms, fault warnings, and structured solutions, enabling a shift from passive to proactive operation and maintenance.

[0089] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the fault determination method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0090] This application also provides a fault determination system; please refer to... Figure 4 The fault determination system includes: The baseline comparison module 10 is used to collect the equipment operation data of the device under test, construct a standard behavior baseline based on the standard operation data in the equipment operation data, and compare the equipment operation data with the standard behavior baseline to determine the anomaly confidence level of the equipment operation data. The graph generation module 20 is used to extract the data dependencies between equipment operation data and generate a parameter dependency graph based on the data dependencies. Anomaly determination module 30 is used to determine abnormal data in the device under test based on parameter dependency graph and anomaly confidence. The fault alarm module 40 is used to obtain the dynamic alarm threshold of the device under test, generate fault alarm information based on the dynamic alarm threshold and abnormal data, and output it.

[0091] The fault determination system provided in this application, employing the fault determination method in the above embodiments, can solve the technical problem of poor fault identification effect. Compared with the prior art, the beneficial effects of the fault determination system provided in this application are the same as those of the fault determination method provided in the above embodiments, and other technical features of the fault determination system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0092] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the fault determination method in Embodiment 1 above.

[0093] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, and PADs (Portable Application Description: Tablet computers), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0094] like Figure 5As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0095] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0096] The electronic device provided in this application, employing the fault determination method in the above embodiments, can solve the technical problem of poor fault identification effect. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the fault determination method provided in the above embodiments, and other technical features of the electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0097] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0099] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the fault determination method in the above embodiments.

[0100] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0101] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0102] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by an electronic device, the fault-determining device performs the following actions: collects equipment operation data of the device under test; constructs a standard behavior baseline based on standard operation data within the equipment operation data; compares the equipment operation data with the standard behavior baseline to determine the anomaly confidence level of the equipment operation data; extracts data dependencies between the equipment operation data; generates a parameter dependency graph based on the data dependencies; determines abnormal data in the device under test based on the parameter dependency graph and the anomaly confidence level; obtains the dynamic alarm threshold of the device under test; and generates and outputs fault alarm information based on the dynamic alarm threshold and the abnormal data.

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

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

[0105] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0106] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described fault determination method, thereby solving the technical problem of poor fault identification performance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the fault determination method provided in the above embodiments, and will not be repeated here.

[0107] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the fault determination method described above.

[0108] The computer program product provided in this application can solve the technical problem of poor fault identification effect. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the fault determination method provided in the above embodiments, and will not be repeated here.

[0109] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A fault determination method, characterized in that, The fault determination method includes: Collect equipment operation data of the device under test, construct a standard behavior baseline based on the standard operation data in the equipment operation data, and compare the equipment operation data with the standard behavior baseline to determine the anomaly confidence level of the equipment operation data; Extract the data dependencies between the device operation data, and generate a parameter dependency graph based on the data dependencies; Abnormal data in the device to be detected are determined based on the parameter dependency graph and the anomaly confidence level. Obtain the dynamic alarm threshold of the device under test, generate fault alarm information based on the dynamic alarm threshold and the abnormal data, and output it.

2. The fault determination method as described in claim 1, characterized in that, The step of determining the abnormal data in the device to be detected based on the parameter dependency graph and the anomaly confidence score includes: The abnormal confidence level is used as a weighting factor to perform correlation mining on the equipment operation data, and target data objects with abnormal confidence levels higher than a preset confidence threshold are selected from the equipment operation data. Using the data dependencies in the parameter dependency graph as constraints, cluster analysis is performed on the target data object to generate abnormal data in the device to be detected.

3. The fault determination method as described in claim 1, characterized in that, The step of obtaining the dynamic alarm threshold of the device under test includes: Acquire the operating characteristics and aging data of the device under test; The aging coefficient of the device under test is calculated based on the aging data, and the operating condition adaptation coefficient of the device under test is generated based on the operating condition characteristics and the aging data. The dynamic alarm threshold of the device under test is generated based on the operating condition adaptation coefficient and the equipment aging coefficient.

4. The fault determination method as described in claim 1, characterized in that, The fault determination method further includes: The fault risk value of the device under test is determined based on the abnormal data. Based on the fault risk value, an early warning message is generated indicating that the device under test will fail within a preset time interval in the future.

5. The fault determination method as described in claim 4, characterized in that, The step of determining the fault risk value of the device under test based on the abnormal data includes: Based on the abnormal data, identify the fault information of the device under test, extract the fault type from the fault information, select the target prediction model corresponding to the fault type from each preset fault prediction model to perform fault prediction, and generate fault prediction results. Obtain the dynamic factors of the fault prediction results, and determine the dynamic weights of the fault prediction results based on the dynamic factors. Based on the dynamic weights, the fault prediction results are fused to generate a fault risk value.

6. The fault determination method as described in claim 5, characterized in that, The fault prediction result includes at least one of the first fault prediction result, the second fault prediction result, and the third fault prediction result; The step of selecting a target prediction model corresponding to the fault type from various preset fault prediction models to perform fault prediction and generate fault prediction results includes at least one of the following: When the fault type includes linear faults and / or periodic faults, the faults with linear trends and periodicity in the abnormal data are analyzed based on the first preset fault prediction model to generate a first fault prediction result. When the fault type includes multi-parameter linear faults, the faults caused by multi-parameter linear correlations in the abnormal data are analyzed based on the second preset fault prediction model to generate a second fault prediction result. When the fault type includes nonlinear faults, the faults with nonlinear relationships in the abnormal data are analyzed based on the third preset fault prediction model to generate a third fault prediction result.

7. The fault determination method as described in claim 5, characterized in that, The dynamic factors include model performance factors, fault type matching factors, and data quality factors. The step of obtaining the dynamic factors of the fault prediction result and determining the dynamic weights of the fault prediction result based on the dynamic factors includes: The model performance factor is determined based on the performance of each preset fault prediction model within a preset time period. The fault type matching factor is determined based on the matching degree between the abnormal data and each preset fault prediction model. The data quality factor is determined based on the completeness and stability of the abnormal data. The model performance factor, the fault type matching factor, and the data quality factor are input into a preset meta-model to generate dynamic weights for the fault prediction results.

8. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the fault determination method as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the fault determination method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the fault determination method as described in any one of claims 1 to 7.