Method or non-transitory computer-readable medium for automated real-time detection, prediction, and prevention of rare faults in industrial systems using unlabeled sensor data

Abstract

Example implementations described herein are directed to managing a system including a plurality of devices providing unlabeled sensor data, which may include performing feature extraction on unlabeled sensor data to generate a plurality of features; performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, where the fault detection model is generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning; and providing the extracted features and fault detection labels to the fault prediction model to generate a fault prediction and a sequence of features.

Description

[Technical field]

[0001] The present disclosure relates generally to industrial systems, and more particularly to automated real-time detection, prediction, and prevention of rare faults in industrial systems using unlabeled sensor data. [Background technology]

[0002] Industrial systems as described herein include most industries that operate complex systems, including, but are not limited to, manufacturing, theme parks, hospitals, airports, public facilities, mining, oil and gas, warehousing, and transportation systems.

[0003] Two main categories of faults are defined by how far apart the fault is in terms of time from the symptom of the fault to the failure. An early type of fault includes symptoms and failures that are close in time, such as an overload fault on a conveyor belt. A slow (or chronic) type of fault includes symptoms that are long in the past (or much earlier than the fault). This type of fault usually has wider adverse effects and can shut down the entire system. Such types of faults can include breaks or cracks in a dam, or fractures due to metal fatigue.

[0004] Although failures in complex systems are rare, the costs of such failures can be enormous in terms of financial costs (e.g., operations, maintenance, repairs, logistics, etc.), reputational costs (e.g., marketing, market share, sales, quality, etc.), personnel costs (e.g., scheduling, skill sets, etc.), and liability costs (e.g., safety, health, etc.). Summary of the Invention [Means for solving the problem]

[0005] The implementations described herein target early types of failures where the failure occurs within a short time window from the symptom, which may range from minutes to hours depending on the actual problem in a particular industrial system.

[0006] Some problems (limitations and limitations) of prior art systems and methods are discussed below, and the implementation examples described herein introduce techniques to solve those problems.

[0007] In prior art implementations involving unsupervised learning tasks, data science practitioners typically must build one model each time, manually inspect the results, and evaluate the model based on the results. Model-based feature selection is not available for prior art unsupervised learning tasks. Furthermore, data science practitioners typically must manually explain the results. The manual work involved in unsupervised learning tasks is typically time-consuming, error-prone, and subjective. There is a need to provide general-purpose techniques for automating model evaluation, feature selection, and explainable artificial intelligence (AI) for unsupervised learning tasks.

[0008] Prior art implementations rely heavily on accurate historical fault data. However, serious historical faults are rare, and accurate historical fault data is usually not available for several reasons. For example, historical faults may not be collected because there may be no or limited processes set up to collect fault data, and fault data may not be manually processed, detected, and identified due to the large volume of Internet of Things (IoT) data. Furthermore, historical faults collected may not be accurate because there is no standard process to effectively and efficiently detect and classify both common and rare events. Furthermore, manual processes for collecting faults by labeling sensor data based on domain knowledge are inaccurate, inconsistent, unreliable, and time-consuming. Thus, there is a need for an automated and standard process or technique for accurately, effectively, and efficiently detecting and collecting faults in industrial systems.

[0009] Prior art fault prediction solutions do not perform well for rare fault events in the required response time (or lead time). The reasons include inability to determine the optimal window for collecting features / evidences and faults or inability to identify the correct signals that can predict faults. In addition, since industrial systems are usually run under normal conditions and faults are usually rare events, it may be difficult to capture the limited amount of fault patterns and therefore difficult to predict such faults. Furthermore, prior art implementations may not be able to build the correct relationship of the time order between normal cases and rare fault events and may not be able to capture the sequence pattern of the rare fault course. Therefore, there is a need for an optimal feature window given a limited amount of fault data in the optimal fault window and a method that can identify the correct signals for fault prediction in the optimal feature window in the required response time so that the correct relationship between normal cases and rare faults and the rare fault course can be built.

[0010] In prior art implementations, failure prevention is typically performed manually based on domain knowledge, and such prevention is subjective, time-consuming, and error-prone. Therefore, there is a need for a standard approach to identify the root causes of predicted failures, automate recommendations for repairing failures by incorporating domain knowledge, and optimize alert suppression to reduce alert fatigue.

[0011] Due to the enormous adverse impact of failures in industrial systems, the solutions proposed herein aim to detect, predict, and prevent such failures in order to mitigate or avoid adverse impacts. From the failure prevention solutions described herein, implementations can reduce unplanned downtime and operational delays while increasing productivity, output, and operational effectiveness, optimize yield and increase margins / profits, maintain production consistency and product quality, reduce unplanned costs for logistics, maintenance scheduling, labor, and repair costs, reduce damage to assets and the entire industrial system, and reduce accidents to operators and improve operator health and safety. The proposed solutions generally benefit operators, supervisors / managers, maintenance technicians, SMEs / domain experts, etc.

[0012] Aspects of the disclosure may include a method for a system having a plurality of devices providing unlabeled sensor data, the method including performing feature extraction on the unlabeled sensor data to generate a plurality of features, performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, where the fault detection model is generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning, and providing the extracted features and the fault detection labels to the fault prediction model to generate a fault prediction and a sequence of features.

[0013] Aspects of the disclosure may include a computer program storing instructions for managing a system having a plurality of devices providing unlabeled sensor data, the instructions including performing feature extraction on the unlabeled sensor data to generate a plurality of features, performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, the fault detection model being generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning, and providing the extracted features and the fault detection labels to the fault prediction model to generate a fault prediction and a sequence of features. The computer program may be stored on a non-transitory computer readable medium and may be executed by one or more processors.

[0014] Aspects of the disclosure may include a system having a plurality of devices providing unlabeled sensor data, the system including: means for performing feature extraction on the unlabeled sensor data to generate a plurality of features; means for performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, the fault detection model being generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning; and means for providing the extracted features and the fault detection labels to the fault prediction model to generate a fault prediction and a sequence of features.

[0015] Aspects of the disclosure may include a management device for a system having a plurality of devices providing unlabeled sensor data, the management device including a processor configured to: perform feature extraction on the unlabeled sensor data to generate a plurality of features; perform fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, the fault detection model being generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning; and provide the extracted features and the fault detection labels to the fault prediction model to generate a fault prediction and a sequence of features.

[0016] Aspects of the disclosure may include a method for a system having a plurality of devices providing unlabeled sensor data, the method including performing feature extraction on the unlabeled data to generate a plurality of features; executing a machine learning framework that converts an unsupervised learning task into a supervised learning task by applying supervised machine learning to unsupervised machine learning models generated from the unsupervised machine learning, the method including performing unsupervised machine learning to generate unsupervised machine learning models based on the features; performing supervised machine learning on results of each of the unsupervised machine learning models to generate supervised ensemble machine learning models, each of the supervised ensemble machine learning models corresponding to a respective one of the unsupervised machine learning models; selecting certain of the unsupervised machine learning models based on evaluating results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models; selecting features based on results of the evaluation of the unsupervised learning models; and converting selected ones of the unsupervised learning models into supervised learning models to facilitate explainable artificial intelligence (AI).

[0017] Aspects of the disclosure may include a computer program for a system having a plurality of devices providing unlabeled data, the computer program having instructions including: performing feature extraction on the unlabeled data to generate a plurality of features; executing a machine learning framework that converts an unsupervised learning task into a supervised learning task by applying supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning, the computer program having instructions including performing unsupervised machine learning to generate an unsupervised machine learning model based on the features; performing supervised machine learning on the results of each of the unsupervised machine learning models to generate a supervised ensemble machine learning model, each of the supervised ensemble machine learning models corresponding to each of the unsupervised machine learning models; selecting certain of the unsupervised machine learning models based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models; selecting features based on the evaluation results of the unsupervised learning models; and converting selected ones of the unsupervised learning models into supervised learning models to facilitate explainable artificial intelligence (AI). The computer program may be stored on a non-transitory computer-readable medium and may be executed by one or more processors.

[0018] Aspects of the disclosure may include a system having a plurality of devices providing unlabeled data, the system including: means for performing feature extraction on the unlabeled data to generate a plurality of features; means for executing a machine learning framework that converts an unsupervised learning task into a supervised learning task by applying supervised machine learning to unsupervised machine learning models generated from the unsupervised machine learning, where executing the machine learning framework includes performing unsupervised machine learning to generate unsupervised machine learning models based on the features; means for performing supervised machine learning on results of each of the unsupervised machine learning models to generate supervised ensemble machine learning models, each of the supervised ensemble machine learning models corresponding to a respective one of the unsupervised machine learning models; means for selecting certain of the unsupervised machine learning models based on evaluating results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models; means for selecting features based on results of the evaluation of the unsupervised learning models; and means for converting selected ones of the unsupervised learning models into supervised learning models to facilitate explainable artificial intelligence (AI).

[0019] Aspects of the disclosure may include a management device for a system having a plurality of devices providing unlabeled data, the management device including a processor configured to: perform feature extraction on the unlabeled data to generate a plurality of features; execute a machine learning framework that converts an unsupervised learning task into a supervised learning task by applying supervised machine learning to unsupervised machine learning models generated from the unsupervised machine learning, the execution including performing unsupervised machine learning to generate unsupervised machine learning models based on the features; perform supervised machine learning on results of each of the unsupervised machine learning models to generate supervised ensemble machine learning models, each of the supervised ensemble machine learning models corresponding to a respective one of the unsupervised machine learning models; select certain of the unsupervised machine learning models based on evaluating results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models; select features based on results of the evaluation of the unsupervised learning models; and convert selected ones of the unsupervised learning models into supervised learning models to facilitate explainable artificial intelligence (AI). [Brief description of the drawings]

[0020] [Figure 1] A solution architecture for detecting, predicting, and preventing rare failures in industrial systems according to one example implementation is presented.

[0021] [Diagram 2] 1 illustrates an example workflow for model selection according to one implementation.

[0022] [Diagram 3] We present an example implementation for training, selecting, and ensembling supervised learning models.

[0023] [Figure 4] 1 illustrates an example of a feature window for extracting features and faults according to one implementation.

[0024] [Diagram 5] We present an implementation example of a multi-layer long short-term memory (LSTM) autoencoder.

[0025] [Figure 6] We present a multi-layer LSTM architecture for fault prediction with an example implementation.

[0026] [Figure 7A] 1 shows an example for determining features (or key factors) for failure prediction according to one implementation.

[0027] [Figure 7B] 1 illustrates an example of a flow diagram when there are alerts with the same asset and failure mode according to one implementation.

[0028] [Figure 7C] 1 illustrates an example of a flow diagram when there are no alerts with the same asset and failure mode, according to one implementation.

[0029] [Figure 8] 1 illustrates a system including multiple systems with connected sensors and a management device, according to one implementation.

[0030] [Figure 9] 1 illustrates an example computing environment having an example computing device suitable for use with some implementations. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] The following detailed description shows details of the drawings and implementation examples of the present application. Reference numbers and descriptions of redundant elements between the drawings are omitted for clarity. The terms used throughout the description are shown by way of example and are not intended to be limiting. For example, the use of the term "automatic" may include a fully automatic implementation or a semi-automatic implementation including user or administrator control over certain aspects of the implementation, depending on the desired implementation of the person skilled in the art practicing the implementation of the present application. The selection may be made by a user through a user interface or other input means, or may be implemented by a desired algorithm. The implementations described herein may be utilized alone or in combination, and the functionality of the implementations may be implemented by any means depending on the desired implementation.

[0032] To address the problems of the prior art, implementations include several techniques such as:

[0033] Solving unsupervised learning tasks using supervised learning techniques: The example implementation includes comprehensive techniques for automating model evaluation, feature selection, and explainable AI typically available in supervised learning models to solve unsupervised learning tasks.

[0034] Fault Detection: The example implementation leverages the introduced generic framework and solution architecture to automate the manual process to accurately, efficiently, and effectively detect faults using anomaly detection models and apply supervised learning techniques (feature selection, model selection, and explainable AI) to optimize and explain the anomaly detection models.

[0035] Fault Prediction: The implementation introduces a technique to derive signals / features within an optimal feature window and predict rare faults within the optimal fault window given a required response time by using both the derived features and past faults.

[0036] Failure prevention: The example implementation introduces techniques to identify the root causes of predicted failures, automate recommendations for repairing failures by incorporating domain knowledge, and suppress alerts through an optimized data-driven approach.

[0037] FIG. 1 illustrates a solution architecture for detecting, predicting, and preventing rare failures in industrial systems, according to one example implementation.

[0038] Sensor Data 100: Time series data from multiple sensors is collected and serves as the input in this solution. The time series data is unlabeled, meaning that no manual process is required to label or tag the sensor data to indicate whether each data point corresponds to a fault or not.

[0039] Fault detection 110 includes the following components configured to detect faults based on input sensor data: Feature engineering 111 is used to derive features / signals used to build fault detection and fault prediction models. This component includes three subcomponents: sensor selection, feature extraction, and feature selection. Fault detection 112 is configured to utilize anomaly detection techniques to detect rare faults in the industrial system. The detected rare faults are used as targets to build a fault prediction model. The detected historical rare faults are also used to form features to build a fault prediction model.

[0040] The fault prediction 120 includes the following components configured to predict faults using the features and the detected faults: The feature transformer 121 converts the features from the feature engineering module and the detected faults into a format consumable by a long short-term memory (LSTM) autoencoder and an LSTM fault prediction module. The derived features from the feature engineering component 111 and the detected rare faults are encoded using an autoencoder 122 to remove redundant information in the time series data. The encoded features preserve the signal in the time series data and are used to build a fault prediction model. The fault prediction module 123 includes a deep recurrent neural network (RNN) model with an LSTM network architecture that is used to build a fault prediction model with the encoded features (as features), the original features (as targets), and the detected faults (as targets). The predicted faults 124 are one output of the fault prediction module 123 represented as a score to indicate the likelihood of a fault. The predicted features 125 are another output of the fault prediction module 123, which is a set of features having the same format as the output of the feature engineering module 111. The detected faults 126 are the output of applying a fault detection model to the predicted features 125 to generate a detected fault score. The ensemble faults 127 ensembles the output of the predicted faults 124 and the detected faults 126 to form a single fault score. Various ensembling techniques can be used. For example, an average of the predicted faults 124 and the detected faults 126 can be used as a single fault score.

[0041] Failure prevention 130 includes the following components configured to identify root causes, automate remediation recommendations, and suppress alerts: Root cause analysis 131 is performed to automatically determine the root cause of the predicted failure. Remediation recommendations 132 are configured to automatically generate remediation actions for the predicted failure by incorporating domain knowledge. In an example implementation, an alert is generated to notify an operator so that the operator can remediate or avoid the failure based on the root cause of the failure. Alert suppression 133 is configured to suppress alerts to avoid flooding the operator's alert queue, and such suppression is performed by automated data-driven optimization techniques. Alert 134 is the final output of the solution and includes the predicted failure score, root cause, and remediation recommendation.

[0042] Below, we discuss each component in the solution architecture in detail. First, we describe a general framework and solution architecture for solving unsupervised learning tasks by using supervised learning techniques. This framework forms the basis of the entire solution.

[0043] As described herein, a generic framework and solution architecture for solving unsupervised learning tasks by using supervised learning techniques is described. Unsupervised learning tasks mean that the data does not contain target or label information. Unsupervised learning tasks may include clustering, anomaly detection, etc. Supervised learning techniques include hyperparameter optimization, feature selection, and model selection with explainable AI.

[0044] Figure 2 shows an example workflow for model selection according to one implementation. The solution architecture for applying supervised learning model selection techniques to select the best unsupervised learning model, how the ensemble model works, and finally the rationale behind this solution architecture are described with respect to Figure 2.

[0045] First, given a dataset and an unsupervised learning problem, the implementation finds the best unsupervised learning model for the given problem and dataset. The first step is to derive features from the given dataset, which is done by the feature engineering module 111.

[0046] Next, as shown at 300, several unsupervised learning model algorithms are manually selected, and several parameter sets for each model algorithm are also manually selected. Each combination of model algorithm and parameter set is used to build a model for the features derived from the feature engineering step, as shown in FIG. 2. However, due to the nature of the unsupervised learning task, there are no ground truth facts available to measure how the model performs. Some unsupervised learning models, such as clustering models, may have some metrics specific to the clustering algorithm that can be used to measure the performance of the model. However, such metrics are not general enough to apply to all unsupervised learning models.

[0047] Implementations include a generic solution for evaluating how models perform by stacking supervised learning models 301 on top of unsupervised learning models. For each unsupervised learning model, the unsupervised learning model is applied to features or data points to obtain unsupervised results. Such unsupervised results may include which cluster each data point belongs to for a clustering problem, or whether a data point indicates an anomaly for an anomaly detection problem, etc.

[0048] Such results and features become the input of a supervised ensemble model, where features from the unsupervised learning model are used as features for the supervised learning model, and results from the unsupervised learning model are used as targets for the supervised learning model. The supervised ensemble model can be evaluated by comparing the targets (results from the unsupervised learning model) with the predicted results from the supervised ensemble model. Based on such evaluation results, it can be identified which supervised ensemble model can provide the best evaluation results.

[0049] The implementation may then identify which unsupervised learning model corresponds to the best evaluation result, obtain it as the best unsupervised learning model with the best model parameter set at 302, and output that model.

[0050] FIG. 3 illustrates an example implementation of a solution architecture for training, selecting, and ensembling supervised learning models according to an example implementation. Each “ensemble model xx” in FIG. 2 is represented by FIG. 3.

[0051] First, this implementation trains a model: several supervised learning model algorithms are manually selected, and several parameter sets for each model algorithm are also manually selected.

[0052] The implementation then selects a model with hyper-parameter optimization. Several hyper-parameter optimization techniques can be used, including grid search, random search, Bayesian optimization, evolutionary optimization, and reinforcement learning. For illustrative purposes, the grid search technique is described with respect to FIG. 3. For each model algorithm, the process is as follows:

[0053] For each parameter set, a supervised learning model is constructed on the features from the feature engineering 400 and the results from the unsupervised learning model 401. The supervised learning model is evaluated against a predefined evaluation metric and an evaluation score is associated with the model.

[0054] b. By comparing the evaluation scores from models with various parameter sets, the best parameter set is selected for the current model algorithm.

[0055] c. Each model algorithm is associated with a parameter set that gives the best evaluation results.

[0056] The implementation then forms an ensemble model 402. The models from all the model algorithms are ensembled to form the final ensemble model 402. Ensembling is a process for combining or aggregating multiple individually trained models into a single model to make predictions on unknown data. Assuming that the base models are diverse and independent, ensemble techniques help reduce the generalization error of predictions. The implementation can use various ensemble techniques, such as:

[0057] Classification models: Majority voting techniques can be used to ensemble classification models. For each instance, apply each model to the current feature set and obtain a predicted class. Use the most frequently occurring class for the final prediction of the instance.

[0058] Regression Models: There are several techniques for ensembling regression models.

[0059] Averaging over regression models: For each instance, apply each model to the current feature set and obtain a prediction. Then use the average of the predictions from the different models as the final prediction.

[0060] Trimmed average for regression models: For each instance, apply each model to the current feature set and obtain a prediction. Remove the highest and lowest predictions from the models and calculate the average of the remaining predictions. Use the trimmed average for the final prediction.

[0061] Weighted Average over Regression Models: For each instance, apply each model to the current feature set and get a prediction. Assign weights to the predictions based on the estimated accuracy of the model. The more accurate the model, the more weight is assigned to the prediction from the model. Then calculate the average of the weighted predictions and use the weighted average for the final prediction. The weights of the various models need to be normalized so that the sum of the weights is equal to 1.

[0062] To evaluate the unsupervised learning model, u Let f represent an unsupervised learning model, which is a combination of an unsupervised learning model algorithm and a set of parameters. For example, in Figure 2, u can be a combination of the unsupervised model 1 and the parameter set 11. u To evaluate how well it works, the implementation is run on some predefined metrics that can come from model-based metrics or business metrics. u In the prior art, the assessment is typically done manually by looking at each individual case to see if it has been correctly handled by the business knowledge-based model. Such a manual process is time-consuming, error-prone, inconsistent, and subjective.

[0063] Implementation examples include solutions that can efficiently, effectively, and objectively evaluate unsupervised learning models. u The rating is f uThe relationship between the features and the results discovered by the feature engineering can be translated into an evaluation of the relationship between the features and the results discovered by the feature engineering. For this task, a set of supervised learning models is stacked to train a supervised learning model by using the features 400 (FIG. 3) from the feature engineering as the features F and the results 401 from the unsupervised learning model as the targets T. For the set of supervised learning models, several qualitatively different supervised learning model algorithms are first manually selected, and then several parameter sets are selected for each supervised learning model algorithm. At the model algorithm level, a hyperparameter optimization technique can determine the best parameter set for each model algorithm.

[0064] f s Let f be the best model for each supervised learning algorithm. s can be considered as an independent evaluator, and f u gives an evaluation score for f u The same relationship that f finds from F and T s If it is found, the evaluation score is high, otherwise the score is low.

[0065] Supervised learning model f s For each unsupervised learning model f u Evaluation score for f s The model evaluation score of f can be used. s For each target T, u while the predicted value is calculated by f s f is calculated as the closeness between the target and the predicted value. s The evaluation score of the unsupervised learning model f u and the supervised learning model f s It is essential to measure the similarity of the relationship between F and T found by

[0066] At this point, the unsupervised model f u Some supervised learning models for each s Then, for each fs f u The evaluation score of the unsupervised learning model f u The scores are aggregated or ensemble to determine if is a good model.

[0067] f s Because the model algorithms underlying f are diverse and qualitatively different from each other, they give different scores. u There are two cases:

[0068] f s Most of the f u If the relationship between F and T is f u is well captured by f u is considered to be a good model.

[0069] f s Most of the f u If the relationship between F and T is f u is not well captured by f u is considered a bad model.

[0070] In other words, f u Most f s f u We can capture relations in a similar way to how f u can lead to good scores for f u If F reveals a bad relationship with T, most f s captures the relationship in the F and T groups differently, and f u Most f s f u resulting in a bad score.

[0071] To compare various unsupervised learning models, we use a supervised learning model f s is an unsupervised learning model f uA single score is given based on the evaluation score given to u , where K is the number of supervised learning models that yield a score above S. There are several ways to aggregate the evaluation scores, including average, trimmed average, and majority voting. In majority voting, the implementation counts the number of supervised learning models that yield a score above S, where S is a predefined number. In average, the implementation calculates the average of the evaluation scores from the supervised learning models. In trimmed average, the implementation removes the K highest and lowest scores and then calculates the average, where K is a predefined number.

[0072] Each unsupervised model f u Once the evaluation scores are obtained, a final unsupervised learning model can be selected. The final unsupervised learning model can be selected by utilizing a global best model, where the implementation selects the model with the best score across the model algorithms and parameter sets and uses that as the final model. Alternatively, the final unsupervised learning model can be selected by utilizing a local best model, where the implementation first selects the model with the best score for each model algorithm and then ensembles the models from each model algorithm.

[0073] In unsupervised learning models, some basic feature selection techniques for selecting features are available in prior art implementations, including techniques based on correlation analysis and techniques based on feature value variance. However, in general, model evaluations of unsupervised learning models are not available, so advanced model-based feature selection techniques cannot be applied to select features for unsupervised learning models.

[0074] With the implementation of the solution architecture shown in Figures 2 and 3, unsupervised learning models can be evaluated and therefore model-based feature selection techniques can be applied to select features for the unsupervised learning models.

[0075] Given a set of features, by leveraging the solution architecture for evaluating unsupervised models as shown in Figures 2 and 3, we can utilize forward feature selection, backward feature selection, and hybrid feature selection available in supervised learning to select which feature set can provide the best performance.

[0076] To explain the unsupervised learning model, the implementation stacks a supervised model on the unsupervised model. The features of the unsupervised learning model are used as features of the supervised learning model. The results of the unsupervised learning model are used as targets for the supervised model. The implementation then uses techniques from the supervised learning model to explain predictions, i.e. feature importance analysis, root cause analysis, etc.

[0077] Feature importance is usually performed at the model level. Feature importance refers to the technique of assigning a score to each input feature based on how useful and relevant it is in predicting the target variable in supervised learning tasks (i.e., regression and classification tasks). There are techniques for computing feature importance scores. Examples of feature importance scores include statistical correlation scores, coefficients calculated as part of a linear model, scores based on decision trees, and permutation importance scores. Feature importance can provide insight into a dataset, and relative feature importance scores can highlight and identify which features may be most relevant to the target. Such insight can aid in feature selection for a model and improve the model. For example, only the top F features are kept to train the model to avoid noise introduced by less important features.

[0078] On the other hand, root cause analysis (RCA) is usually performed at the instance level; that is, each prediction may have some root cause. There are two broad families of models for RCA: deterministic models and probabilistic models. Deterministic models deal only with the certainty in the known facts or inferences represented in supervised learning models. Probabilistic models can deal with this uncertainty in supervised learning models. Both models can use logic, compiled, classifier, or process model techniques to derive the root cause. Probabilistic models can also build Bayesian networks to derive the root cause. Once the root cause is identified, it can help derive recommendations to fix or avoid potential problems and risks.

[0079] For example, an unsupervised model such as an "isolation forest" model can be utilized to perform anomaly detection on feature data derived from a feature engineering module based on the data. The output of the anomaly detection is an anomaly score for an instance in the feature data. A supervised model such as a "decision tree" model can be used to perform a regression task, where the features for the "decision tree" model are the same as the features for the "isolation forest", and the target for the "decision tree" model is the anomaly score output from the "isolation forest" model. To explain the decision tree, feature importance can be calculated at the model level, and root causes can be identified at the instance level.

[0080] To calculate feature importance at the model level, one implementation is to calculate the reduction in node impurity weighted by the probability of reaching the node. Node impurity can be measured as the Gini index. The probability of a node can be calculated by dividing the number of samples that reach the node by the total number of samples. The higher the feature importance value, the more important the feature is.

[0081] To find the root cause of a prediction at the instance level, we can traverse the decision tree from the root to the leaves. In the decision tree, each node is associated with a condition such as "sensor_1>0.5", where sensor_1 is a feature in the feature data. If we traverse the decision tree from the root of the tree, we get a list of such conditions, e.g. ["sensor_1>0.5", "sensor_2<0.8", "sensor_11>0.3"]. Such a set of conditions leading to a prediction allows a domain expert to infer what could cause the prediction.

[0082] To select a supervised model for a given unsupervised model, one implementation is to use a supervised learning model algorithm that is similar in nature to the unsupervised learning model algorithm of interest. Another implementation is to use a simpler model for the supervised learning model so that the model is easier to interpret or explain.

[0083] In FIG. 1, fault detection 110 includes two components: feature engineering 111 and fault detection 112. Feature engineering 111 processes raw input data and prepares usable features for subsequent modules. The feature engineering module has three main tasks: sensor selection, feature extraction, and feature selection. In sensor selection, not all sensors are relevant for fault detection. Sensors can be selected by a manual process based on the data and the domain knowledge of the problem, but such a form is time-consuming, error-prone, and constrained by the expertise of the domain experts. Instead, feature selection techniques as presented above can be applied. Each sensor can be considered as a feature, and then the above techniques (forward selection, backward selection, hybrid selection) are applied to select the sensor.

[0084] To extract features, several techniques are performed on the sensor data to extract features from the time series data, and domain knowledge can be incorporated into this process.

[0085] One example of a technique is a moving average. Time series data can change sharply from one time point to the next. Such fluctuations make it difficult for model algorithms to learn patterns in the time series data. One technique is to smooth the time series data before it is consumed by a subsequent model. Smoothing the time series is done by calculating a moving average of the time series data. There are several techniques for calculating a moving average, including the simple moving average (SMA), the exponentially smoothed moving average (EMA), and the weighted moving average (WMA).

[0086] One risk of using moving averages is that by smoothing the values, real anomalies or outliers may be removed. To prevent this, implementations can place more weight on the current data point. Thus, implementations can use weighted moving averages (WMA) and exponentially smoothed moving averages (EMA). Specifically, EMA is a moving average that places more weight and significance on the most recent data points, with the weight exponentially decreasing for points prior to the current point. EMA is a good candidate to use for the moving average calculation task here. Hyperparameters can be tuned in WMA and EMA to achieve the best evaluation results from the later model. Another finding is that industrial disturbances usually persist for a short period of time, which significantly lowers the risk that moving average calculations will remove anomalies and outliers.

[0087] Another example technique is value derivation. Differencing / derivation techniques help to stabilize the mean of a time series by removing changes in the level of the time series, thus eliminating (or reducing) trends and seasonality. The resulting signal is a stationary time series whose properties do not depend on the observation time of the series. Usually, only stationary signals are useful for modeling. Differencing techniques can be first order differencing / derivation, where the change in the value is calculated, or second order differencing / derivation, where the change in the change in the value is calculated. In practice, it is not necessary to go beyond second order differencing to make time series data stationary.

[0088] Differential techniques can be applied to time series data in fault detection tasks. This is because seasonal and trend signals usually do not help the fault detection task, so it is safe and beneficial to remove them and keep only the required stationary signals. In addition to the raw sensor data, based on the raw sensor data, the changes in sensor values ​​(first order derivation / difference) and the changes in the changes in sensor values ​​(second order derivation / difference) are calculated as features. In addition, with domain knowledge, the changes in sensor values ​​indicate a strong signal for detecting faults.

[0089] Feature selection includes automatic feature selection techniques that can be applied to select a subset of features to be used to build the fault detection and prediction model. The feature selection techniques described above for feature selection can be utilized.

[0090] The fault detection module 112 uses the features prepared by the feature engineering module 111 as input and applies anomaly detection to detect anomalies in each data point. Traditionally, one could try and evaluate several anomaly detection models by manually viewing the results. This method is very time consuming and may not find the best model. Instead, an implementation can use the techniques described herein to automatically select the best fault detection model. The unsupervised model xx in FIG. 2 is an anomaly detection model, the unsupervised output xx in FIG. 2 is an anomaly score, and the supervised model xx in FIG. 3 is a regression model. With such customization, one can utilize the techniques described herein to automatically select the best fault detection model.

[0091] The result of an anomaly detection model is an anomaly score that indicates the likelihood or probability that an observed data point is anomalous. Anomaly scores lie in the range [0,1], and the higher the anomaly score, the higher the likelihood or probability that an observed data point is anomalous.

[0092] Given the current sensor readings, the task of the fault prediction 120 is to predict possible future faults. Prior art approaches assume labeled sensor data and use supervised learning techniques to predict faults. However, such approaches do not work very well for several reasons. Prior art approaches cannot determine the optimal window for collecting features / evidence and faults. Prior art approaches cannot identify the correct signals that can predict faults. Prior art approaches cannot identify patterns from a limited amount of fault data. Since industrial systems usually run in normal conditions and faults are usually rare events, it is difficult to capture patterns of a limited amount of faults and therefore difficult to predict such faults. Prior art approaches cannot build the correct relationship between normal cases and rare fault events in the time sequence. Prior art approaches cannot capture the sequence pattern of the rare fault course.

[0093] The following implementation example introduces a method to identify the correct signals for fault prediction in the optimal feature window given a limited amount of fault data and a required response time in the optimal fault window. The implementation example effectively establishes the correct relationship between normal cases and rare faults, and the course of rare faults.

[0094] The feature transformer module 121 transforms the features from the feature engineering module 111 and the detected faults from the fault detection module 112 into a form so that the LSTM autoencoder 122 and the LSTM fault prediction module 123 can use the transformed versions to make predictions about faults.

[0095] FIG. 4 shows an example of feature windows for extracting features and faults according to one implementation. To prepare training data for the later fault prediction model, the implementation needs to prepare both features and targets required by the supervised learning model. The feature windows shown in FIG. 4 are the time windows for acquiring features, and the fault windows are the time windows for obtaining targets (i.e., faults) for the fault prediction model. In the fault prediction task, faults need to be predicted in advance so that the operator has enough time to respond to the potential fault. The lead time window is the time window between the current time (also called "prediction time") and the start time of the fault. This time window is also called the "response time window."

[0096] Figure 4 shows the relationship between the three windows. At the current time, features are collected in the feature window, and faults are collected in the fault window. The end of the feature window and the beginning of the fault window are separated by the lead time window.

[0097] To extract features for fault prediction, the features in the feature window come from two sources: features from feature engineering 111 and past faults from fault detection 112. For each time point in the feature window, there is a combination of features from feature engineering 111 and past faults from fault detection 112. For every time point in the feature window, all these features and past faults are concatenated into a feature vector.

[0098] To extract targets for fault prediction, the faults in the fault window come from two sources: features from feature engineering 111 and past faults from fault detection 112. For each time point in the fault window, there is a combination of features from feature engineering 111 and past faults from fault detection 112. At every time point in the fault window, all the features and past faults are concatenated into a target vector.

[0099] Note that the LSTM sequence prediction model can predict multiple sequences simultaneously, where one type of sequence is the fault sequence and the other type of sequence is the feature sequence, and both sequences can be utilized as described herein.

[0100] Figure 5 shows a multi-layer LSTM autoencoder according to one implementation. To remove redundant information in the time series data, the autoencoder is used to encode the derived features from the feature engineering component 111 and the past faults from the fault detection component 112. The encoded features preserve the signals in the time series data and are used to build a fault prediction model.

[0101] An autoencoder is a multi-layer neural network and may have two components, an encoder and a decoder, as shown in Figure 5. To train the following neural network for an autoencoder, an implementation may train layer E1 as a layer D L i.e., set it equal to the feature that needs to be encoded. Then, the number of hidden units in each layer of the encoder is decreased until the number of hidden units is the size of the encoded feature. Then, the number of hidden units in each layer of the decoder is increased until the number of units is the size of the original feature. Once the neural network is trained, the encoder component can be used to encode the features.

[0102] Figure 6 shows a multi-layer LSTM architecture for fault prediction 123 according to one implementation example. A deep recurrent neural network (RNN) model with LSTM network architecture is used to build a fault prediction model with encoded features as features and original features and detected faults as targets. In particular, Figure 6 shows a network architecture for an LSTM model where the input layer represents the encoded features, the output layer includes the original features and detected faults, and the hidden layer can be multiple layers depending on the data.

[0103] LSTM models excel in fault prediction in several aspects. First, by incorporating both the derived features from the sensor and the detected past faults, the LSTM fault prediction model can build the correct relationship between normal cases and rare fault events in the time sequence, capturing the sequence pattern of the rare fault progression. Second, LSTM is good at capturing the relationship between two events in time series data, even if those two events are quite far from each other. This is done by the inherent structure of the hidden units, which is designed to solve the vanishing gradient problem along time. As a result, it can better capture and resolve the constraints caused by the "lead time window". Third, LSTM models can output several predictions simultaneously, which allows the prediction of multiple sequences (both sequences of features and sequences of faults) simultaneously.

[0104] The output of the model includes a continuous fault score that can avoid problems caused by rare faults in the system. By targeting the model with the continuous fault score, a regression model can be built. Otherwise, when binary values ​​0 are used for normal and 1 for fault, there will be very few "1"s in the data. Such imbalanced data is difficult to train to find patterns of faults in classification problems.

[0105] To directly predict failures, one output of the failure prediction module 123 is a failure score indicating the likelihood of failure, as shown in Figure 1. This failure score is provided as predicted failure 124.

[0106] The implementation first determines the predicted features and then detects faults. As shown in FIG. 1, the other output of the fault prediction module 123 is a set of predicted features 125. The set of predicted features 125 has the same format as the output of the feature engineering module 111. A fault detection component can be applied to this set of features to generate a fault score that indicates the likelihood of a fault. The fault score is provided as a detected fault 126.

[0107] The ensemble faults 127 includes ensembling the predicted faults 124 and the detected faults 126 to form a single fault score. Various ensembling techniques can be used. For example, an average of the predicted faults 124 and the detected faults 126 can be used as the single fault score. Other options can be a weighted average, a maximum, or a minimum depending on the desired implementation.

[0108] Implementations may also be configured to aggregate the faults. Because the fault prediction model may predict multiple faults within a fault window, implementations may aggregate the faults within the fault window to obtain a single fault score for the entire fault window. The fault score may include taking a simple average, exponentially smoothed average, weighted average, trimmed average, maximum, or minimum of all fault scores within the fault window and using that as the final fault score.

[0109] The reason for using a fault window is that the predicted fault score can change dramatically from one time point to the next. Predicting multiple faults within a time window and aggregating them can smooth the predicted score, thereby preventing outlier predictions.

[0110] Regarding hyperparameter optimization, the implementation optimizes the hyperparameters of the model. In the autoencoder and LSTM impairment models, there are many hyperparameters that must be optimized. Such hyperparameters include, but are not limited to, the number of hidden layers, the number of hidden units in each layer, the learning rate, the optimization method, and the momentum rate. Several hyperparameter optimization techniques can be applied: grid search, random search, Bayesian optimization, evolutionary optimization, and reinforcement learning.

[0111] The implementation can also be configured to optimize the window sizes. In the failure prediction model, there are three windows: feature window, lead time window, and failure window. The sizes of these windows can also be optimized. A grid search or random search can be applied to optimize the sizes of these windows.

[0112] After predicting a failure, the implementation can identify the root cause(s) of the failure at 131 and recommend remedial actions at 132. An alert is then generated to inform an operator that a failure may be imminent. However, depending on the failure threshold, too many failure alerts may be generated, flooding the operator's job queue and introducing "alert fatigue" issues. Therefore, it becomes beneficial to throttle alert generation at 133.

[0113] Regarding root cause analysis 131, for each predicted failure, an operator needs to know what may cause the failure so that they can act to mitigate or avoid the potential failure. Identifying the root cause of a prediction corresponds to interpreting the prediction in the machine learning domain, and several techniques and tools exist for such a task. For example, a prior art explainable AI package can help identify the key features that cause the prediction. The key features can have a positive impact on the prediction and a negative impact on the prediction. Such a package can output the top P positive key features and the top M negative key features. Such a package can be utilized to identify the root cause of the predicted failure.

[0114] Figure 7A shows an example for determining features (or key drivers) for a predicted failure according to one implementation. To show how explainable AI works, the implementation uses the flow in Figure 7A. The flow in Figure 7A introduces a simple approach to discovering key features that trigger a prediction.

[0115] At 701, the flow obtains a feature importance weight for each feature from a predictive model. At 702, for each prediction, the flow obtains the value of each feature. At 703, the flow multiplies each feature's value and weight to obtain its individual contribution to the prediction. At 704, the flow ranks the individual contributions. At 705, the flow outputs each feature with its weight, value, and contribution.

[0116] With regard to automating the generation of repair recommendations 132, after the root cause of each prediction is identified, recommended repair steps are provided to avoid potential failures. This step requires domain knowledge to further cluster multiple root causes (or multiple symptoms) into failure modes, and based on the failure modes, repair steps can be generated and recommended to an operator.

[0117] Business rules can be automated to cluster root causes into failure modes and generate repair recommendations for each failure mode. Machine learning models can also be built by leveraging business rules to help cluster or classify failures into failure modes.

[0118] Regarding alert suppression and prioritization 133, alerts can be generated for predicted failures. An alert is represented as a tuple with six elements such as (alert time, asset, failure score, failure mode, recommendation for repair, alert display flag). An alert is uniquely identified by an asset and failure mode. Due to the cost of handling each failure, not all predicted failures should trigger an alert and be displayed to the operator. The "alert display flag" indicates whether an alert should be generated and displayed to the customer. Generating alerts at the right time and frequency is crucial to repair failures and control the cost of handling alerts. Thus, the implementation suppresses some alerts to control the volume of alerts and solve the "alert fatigue" problem.

[0119] Some alerts may be urgent and others not, so there is a need to prioritize the alerts to direct operators to urgent alerts first.

[0120] Below, we describe an algorithm for optimizing the generation of first alerts through a data-driven approach as well as an approach for suppressing and prioritizing alerts.

[0121] To optimize the generation of the first alert, there are three parameters that control when the first alert is generated: · T: Threshold of predicted fault score. If the predicted fault is above the threshold, it is predicted as fault, otherwise it is predicted as normal. · N and E: Generate the first alert after the appearance of N predicted failures in time period E.

[0122] To optimize these three parameters, the following cost-sensitive optimization algorithm is used to find optimal values ​​for T, N, and E, as described below.

[0123] To formulate the optimization problem, the target function and constraints are defined as follows:

[0124] To define cost, let C be the cost incurred by an incorrect prediction. An incorrect prediction can be: False positive: The model predicts a failure when there is no actual failure. We call the cost associated with each false positive instance the “false positive cost.” False negative: There is a real failure, but the model does not predict the failure. We call the cost associated with each false negative instance the “false negative cost.”

[0125] The "false negative cost" is usually larger than the "false positive cost", but it depends on the problem to determine how much larger the "false negative cost" is than the "false positive cost". To solve the optimization problem, the "false negative cost" and the "false positive cost" are determined from domain knowledge.

[0126] Depending on whether we consider the severity or the likelihood of the predicted failures, we can define a cost function for the optimization problem as follows: -Does not take into account the severity or likelihood of predicted damage C = number of false positive instances · cost of false positives + number of false negative instances · cost of false negatives Consider the severity or likelihood of the predicted damage C = Σ(predicted outage score · cost of false positives) + Σ((1 - predicted outage score) · cost of false negatives)

[0127] Based on the definition of the cost function, the optimization problem can be formulated as follows:

[0128] Target function: Minimize(Cost)

[0129] Subject to: 0 <T<=T max , 0 <N<=N max , 0 <E<=E max , where T max , N max , and E max is predetermined based on domain knowledge.

[0130] Historical data is utilized to solve the optimization problem. From the historical data, the number of false positive and false negative instances can be counted given various parameter values ​​of T, N, and E. The historical data required for this task includes predicted fault scores and confirmed faults. Confirmed faults usually result from the recognition or rejection of predicted faults by an operator.

[0131] In the absence of confirmed faults, the detected faults can be used by applying a fault detection component to the sensor values. One way to calculate the cost is as follows: for each combination of T, N, and E, count the number of false positive instances and the number of negative instances, and then calculate the cost. The goal is to find the combination of T, N, and E that results in the minimum cost. This approach is also called grid search, and it can take a long time to optimize the problem. Other optimization approaches can be used. For example, a random search or Bayesian optimization can be applied to solve this problem.

[0132] To suppress and prioritize alerts, two decisions need to be made given a predicted failure: whether to generate an alert and the urgency of the alert. Then, the optimal T, N, and E found based on historical data are utilized and an algorithm is implemented to suppress and prioritize the alerts generated in the industrial system.

[0133] The implementation maintains a queue Q for storing alerts. Alerts may be processed by an operator, and processed alerts have three outcomes: "acknowledged", "rejected", or "resolved". Or, an alert may not yet be processed ("unprocessed"). "Resolved" alerts are removed from Q. "Rejected" alerts may be kept in Q or removed from Q, depending on business rules.

[0134] Each alert can be represented as a 6-element tuple. Within Q, multiple alerts with the same asset and failure mode values ​​are aggregated together as an "alert group". For the remaining elements in the tuple: - "Alert Time" is maintained as a list to store all alert times for each alert group. "Problem scores" is maintained as a list to store all the problem scores for each alert group. "Repair Recommendation" is determined by "asset" and "failure mode", so "Repair Recommendation" has a single value per alert group. "Alert display flag" is maintained as a list for storing all alert display flags for each alert group.

[0135] Alerts can be ordered in descending order by their urgency. The urgency of an alert can be expressed in several levels: low, medium, high. Since the urgency is at the "asset" and "failure mode" level, the level of urgency is kept as a single value per alert group.

[0136] Depending on the desired implementation, several factors can be used to determine the level of urgency for each alert group, such as asset criticality, aggregated failure score, failure mode, time and cost of repair, total number of times alerts are generated, number of times alerts are generated divided by the duration due to the first alert and last alert.

[0137] Using these factors, a rule-based algorithm can be designed to determine the level of urgency of an alert group based on domain knowledge. Alternatively, knowing the levels of urgency of some existing alert groups, a supervised learning classification model can be built to predict the level of urgency, where the features include all the factors listed above and the target is the level of urgency. The alert groups in the queue are ordered by the level of urgency, and the alerts within each alert group are ordered by the first alert time of the alerts.

[0138] When there is a new predicted failure, the implementation can get its failure score and failure mode. Then the implementation checks whether there is an alert in Q with the same asset and failure mode.

[0139] FIG. 7B shows an example of a flow diagram when there are alert groups with the same asset and failure mode according to one implementation. At 711, the flow adds the alert time of the alert to the alert time list of the alert groups in Q. At 712, the flow adds the fault score of the alert to the fault score list of the alert groups in Q. At 713, the flow adds the alert display flag of the alert to the alert display flag list of the alert groups in Q. At 714, the flow recalculates and updates the urgency level of the alert groups and reorders the alert groups in Q. At 715, the flow suppresses the alert depending on whether the alert has already been generated. The implementation knows if an alert has been generated by checking the "alert display flag".

[0140] At 716, if an alert has not yet been generated, the flow checks whether more than N alerts occur within a period of E (N and E are determined as above). If the answer is yes, generate an alert, else do not generate an alert. At 717, if an alert has already been generated, the flow checks whether the period between the trigger time of the last alert and the current time exceeds a predefined alert display time window. If so, the flow triggers an alert. The flow sets the trigger time of the last alert to the current time. Else do not generate an alert. The predefined alert display time window is a parameter set by the operator based on domain knowledge.

[0141] FIG. 7C shows an example of a flow diagram when there are no alert groups with the same asset and failure mode, according to an example implementation. At 721, the flow creates an alert group entry (i.e., alert time list, asset, failure score list, failure mode, repair recommendation, alert display flag list, and level of urgency), where the level of urgency is "low" by default. At 722, the flow adds the alert time of the alert to the alert time list of the alert groups in Q. At 723, the flow adds the failure score of the alert to the failure score list of the alert groups in Q. At 724, the flow adds the alert display flag of the alert to the alert display flag list of the alert groups in Q. At 725, the flow calculates and updates the level of urgency of the alert groups, and reorders the alert groups based on the level of urgency in Q.

[0142] If an alert in Q expires, i.e., if the alert is present in the alert group for longer than the predefined expiration period without any updates, it is removed from the alert group. If there are no alerts for an alert group, the entire alert group is removed from Q. The predefined expiration period is a parameter set by the operator based on domain knowledge.

[0143] The implementations described herein may be applied to various systems, such as an end-to-end solution. Fault detection, prediction, and prevention may be provided as a solution suite for industrial faults. The end-to-end solution may be provided as an analytics solution core suite as part of the solution core product. Fault detection may be provided as an analytics solution core as part of the solution core product. Fault detection may also be provided as a solution core for automatically labeling data. Fault prediction may be provided as an analytics solution core as part of the solution core product. Alert suppression may be provided as an analytics solution core as part of the solution core product. Root cause identification and remediation recommendations may be provided as an analytics solution core as part of the solution core product.

[0144] Similarly, implementations may include standalone machine learning libraries. The frameworks and solution architectures for solving unsupervised learning tasks using supervised learning techniques may be provided as standalone machine learning libraries that aid in solving unsupervised learning tasks.

[0145] 8 illustrates a system including multiple systems with connected sensors and a management device according to one implementation. One or more systems 801-1, 801-2, 801-3, and 801-4 with connected sensors are communicatively coupled to a network 800. The network 800 is connected to a management device 802. The management device 802 facilitates functionality for an Internet of Things (IoT) gateway or other manufacturing management system. The management device 802 manages a database 803. The database 803 includes historical data collected from sensors of the systems 801-1, 801-2, 801-3, and 801-4. The historical data may include labeled and unlabeled data received from the systems 801-1, 801-2, 801-3, and 801-4. In an alternative implementation, data from the sensors of systems 801-1, 801-2, 801-3, 801-4 can be stored in a central repository or database, such as a proprietary database that captures data from an enterprise resource planning system, etc. The management device 802 can access or retrieve data from the central repository or database. Such systems can include robotic arms with sensors, turbines with sensors, lathes with sensors, etc., depending on the desired implementation.

[0146] FIG. 9 illustrates an example computing environment that includes an example computing device suitable for use with some implementations, such as management device 802 illustrated in FIG.

[0147] A computing device 905 in computing environment 900 may include one or more processing units, cores, or processors 910, memory 915 (e.g., RAM, ROM, etc.), internal storage 920 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or I / O interface 925, any of which may be coupled to a communication mechanism or bus 930 to communicate information or may be embedded in the computing device 905. The I / O interface 925 may also be configured to receive images from a camera or provide images to a projector or display, depending on the desired implementation.

[0148] The computing device 905 may be communicatively coupled to an input / user interface 935 and an output device / interface 940. Either or both of the input / user interface 935 and the output device / interface 940 may be wired or wireless interfaces and may be removable. The input / user interface 935 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch screen interface, keyboard, pointing / cursor control, microphone, camera, Braille, motion sensor, optical reader, etc.). The output device / interface 940 may include a display, television, monitor, printer, speaker, Braille, etc. In some implementations, the input / user interface 935 and the output device / interface 940 may be embedded in the computing device 905 or may be physically coupled to the computing device 905. In other implementations, other computing devices may function as or provide the functionality of the input / user interface 935 and the output device / interface 940 for the computing device 905.

[0149] Examples of computing devices 905 may include, but are not limited to, highly mobile devices (e.g., smart phones, devices in vehicles and other machines, devices carried by humans and animals, etc.), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, etc.), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions, radios with one or more processors embedded and / or coupled thereto, etc.).

[0150] Computing device 905 may be communicatively coupled (e.g., via I / O interface 925) to external storage 945 and to a network 950 for communicating with any number of networked components, devices, and systems, including one or more computing devices of the same or different configurations. Computing device 905, or any connected computing device, may function, provide services, or be referred to as a server, client, thin server, general purpose machine, special purpose machine, or another label.

[0151] I / O interface 925 may include, but is not limited to, wired and / or wireless interfaces using any communication or I / O protocol or standard (e.g., Ethernet, 802.11x, Universal System Bus, WiMax, modem, cellular network protocols, etc.) to exchange information with at least all connected components, devices, and networks in computing environment 900. Network 950 may be any network or combination of networks (e.g., the Internet, a local area network, a wide area network, a telephone network, a cellular network, a satellite network, etc.).

[0152] The computing device 905 can use and / or communicate using computer usable or computer readable media, including transitory and non-transitory media. Transitory media include transmission media (e.g., metallic cables, optical fibers), signals, carrier waves, etc. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

[0153] In some example computing environments, a computing device 905 may be used to implement techniques, methods, applications, processes, or computer-executable instructions. The computer-executable instructions may be retrieved from a transitory medium and stored on and retrieved from a non-transitory medium. The executable instructions may be from one or more of any programming, scripting, and machine language (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, etc.).

[0154] The processor 910 can execute under any operating system (OS) (not shown) in a native or virtual environment. One or more applications can be implemented. Here, the device includes a logic unit 960, an application programming interface (API) unit 965, an input unit 970, an output unit 975, and an inter-unit communication mechanism 995 for the various units to communicate with each other, for the units to communicate with the OS, and for the units to communicate with other applications (not shown). The described units and elements can be modified in terms of design, function, configuration, or implementation, and are not limited to the description given.

[0155] In some implementations, when information or instructions to execute are received by the API unit 965, they may be communicated to one or more other units (e.g., logic unit 960, input unit 970, output unit 975). In some implementations described above, the logic unit 960 may be configured in some cases to control information flow between units and direct services provided by the API unit 965, input unit 970, and output unit 975. For example, the flow of one or more processes or implementations may be controlled by the logic unit 960 alone or in combination with the API unit 965. The input unit 970 may be configured to obtain inputs for the calculations described in the implementations, and the output unit 975 may be configured to provide outputs based on the calculations described in the implementations.

[0156] The processor(s) 910 may be configured to: perform feature extraction on the unlabeled sensor data to generate a plurality of features, as shown at 100 and 111 in FIG. 1 ; perform fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, as shown at 112 in FIG. 1 , where the fault detection model is generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from unsupervised machine learning, as shown in FIGS. 2 and 3 ; and provide the extracted features and the fault detection labels to the fault prediction model to generate a fault prediction and a sequence of features, as shown at 123-125 in FIG. 1 .

[0157] The processor(s) 910 may be configured to generate the fault detection models from applying supervised machine learning to the unsupervised machine learning models generated from the unsupervised machine learning by performing unsupervised machine learning to generate unsupervised machine learning models based on the features, performing supervised machine learning on results of each of the unsupervised machine learning models to generate supervised ensemble machine learning models, each of the supervised ensemble machine learning models corresponding to a respective one of the unsupervised machine learning models, and selecting one of the unsupervised machine learning models as the fault detection model based on evaluating results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models, as shown in FIGS. 2 and 3 .

[0158] The processor(s) 910 may be configured to generate a fault prediction model, as shown in FIGS. 4 and 5 , including extracting features from an optimized feature window from the historical sensor data, determining an optimized fault window and a lead time window based on the faults from the historical sensor data, encoding the features using a long short-term memory (LSTM) autoencoder, training an LSTM sequence prediction model configured to learn patterns in the feature sequence from the feature window to derive faults within the fault window, providing the LSTM sequence prediction model as a fault prediction model, and ensembling faults from the detected faults from the fault detection model and predicted faults from the fault prediction model, where the fault prediction is an ensemble fault from the detected faults and the predicted faults.

[0159] The processor(s) 910 can be configured to provide and execute a failure prevention process to determine root causes of failures and suppress alerts, as shown at 130 in Figure 1, where the failure prevention process determines root causes of failures and suppresses alerts by identifying root causes of ensemble failures and automating recommendations regarding repairs to address the ensemble failures, generating alerts from the ensemble failures, performing an alert suppression process using cost-sensitive optimization techniques to suppress some of the alerts based on a level of urgency, and providing the remainder of the alerts to one or more operators of the multiple systems, as shown at 130-134 in Figure 1 and as shown in Figures 7B and 7C.

[0160] The processor(s) 910 may be configured to execute processes for controlling one or more of the multiple systems based on the remediation recommendations. As an example, the processor(s) 910 may be configured to control one or more of the multiple systems to shut down, reboot, trigger various andon lights associated with the systems, etc. based on the predicted failures and recommendations for remediating the failures. Such implementations may be modified based on the underlying systems and depending on the desired implementation.

[0161] The processor(s) 910 may be configured to execute a machine learning framework that converts an unsupervised learning task into a supervised learning task by performing feature extraction on the unlabeled data to generate a plurality of features, and applying supervised machine learning to the unsupervised machine learning models generated from the unsupervised machine learning, as shown in Figures 2, 3, and 7A. Here, executing the machine learning framework may be configured to perform unsupervised machine learning to generate unsupervised machine learning models based on the features, perform supervised machine learning on the results of each of the unsupervised machine learning models to generate supervised ensemble machine learning models, each of the supervised ensemble machine learning models corresponding to each of the unsupervised machine learning models, select some of the unsupervised machine learning models based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models, select features based on the evaluation results of the unsupervised learning models, and convert the selected ones of the unsupervised learning models into supervised learning models to facilitate explainable artificial intelligence (AI). Unsupervised learning typically does not have techniques for explaining the models. To facilitate explainable AI to explain the unsupervised learning models, implementations convert selected ones of the unsupervised learning models into supervised learning models, whereby features of the unsupervised learning models are used as features of the supervised learning models. The results of the unsupervised learning models are used as targets for the supervised models. Implementations then explain predictions using techniques of the supervised learning models, such as feature importance analysis, root cause analysis 131, as shown in FIG. 7A, depending on the desired implementation, to facilitate explainable AI.

[0162] Some portions of the detailed description have been presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the substance of their innovations to others skilled in the art. An algorithm is a sequence of defined steps leading to a desired end state or result. In one implementation, the steps performed require physical manipulations of tangible quantities to achieve a tangible result.

[0163] Unless otherwise specified, as is apparent from the description, the description utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," and the like throughout the description will be understood to include the actions and processes of a computer system or other information processing device that manipulates and converts data represented as physical (electronic) quantities in the registers and memory of the computer system into other data similarly represented as physical quantities in the memory or registers of the computer system, or other information storage, transmission, or display device.

[0164] The implementations may also relate to an apparatus for performing the operations of the present specification. The apparatus may be specially constructed for the required purposes, or may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer-readable medium, such as a computer-readable storage medium or a computer-readable signal medium. The computer-readable storage medium may include tangible media, such as, but not limited to, optical disks, magnetic disks, read-only memories, random access memories, solid-state devices and drives, or any other type of tangible or non-transitory medium suitable for storing electronic information. The computer-readable signal medium may include media such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. The computer programs may include pure software implementations that include instructions to perform the operations of the desired implementation.

[0165] Various general-purpose systems may be used with the programs and modules according to the examples herein, or it may prove convenient to construct more specialized apparatus to perform the desired method steps. Additionally, the implementations are not described with reference to a particular programming language. It will be appreciated that a variety of programming languages ​​can be used to implement the techniques of the implementations described herein. Instructions in the programming language may be executed by one or more processing devices, such as a central processing unit (CPU), processor, or controller.

[0166] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the implementations can be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software). Such instructions, when executed by a processor, cause the processor to perform a method for performing the implementation of the present application. Furthermore, some implementations of the present application can be performed exclusively in hardware, while other implementations can be performed exclusively in software. Furthermore, the various functions described can be performed in a single unit, or distributed among several components in any number of ways. When performed by software, the method can be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If necessary, the instructions can be stored on the medium in compressed and / or encrypted format.

[0167] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the techniques of the present application. Various aspects and / or components of the described implementations may be used alone or in any combination. It is intended that the specification and implementations be considered as examples only, with a true scope and spirit of the present application being indicated by the following claims. (Appendix 1) 1. A method for a system including a plurality of devices providing unlabeled sensor data, comprising: performing feature extraction on the unlabeled sensor data to generate a plurality of features; performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, the fault detection model being generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from unsupervised machine learning; and providing the extracted features and the fault detection labels to a fault prediction model to generate a fault prediction and a sequence of features; A method comprising: (Appendix 2) The machine learning framework includes: performing the unsupervised machine learning to generate the unsupervised machine learning model based on the features; performing supervised machine learning on the results of each of the unsupervised machine learning models to generate a supervised ensemble machine learning model, each of the supervised ensemble machine learning models corresponding to each of the unsupervised machine learning models; and selecting one of the unsupervised machine learning models as the fault detection model based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models. The method described in (Supplementary Note 1), further comprising: generating the fault detection model by applying the supervised machine learning to the unsupervised machine learning model generated from the unsupervised machine learning. (Appendix 3) extracting features from an optimized feature window from the historical sensor data; determining an optimized fault window and a lead time window based on the faults from the historical sensor data; encoding the features using a long short-term memory (LSTM) autoencoder; training an LSTM sequence prediction model configured to learn patterns in a sequence of features from the feature window to derive impairments in the impairment window; providing the LSTM sequence prediction model as the impairment prediction model; and Ensembling faults consisting of detected faults from the fault detection model and predicted faults from the fault prediction model, the fault prediction being an ensemble fault from the detected faults and the predicted faults. The method of claim 1, further comprising generating the failure prediction model, (Appendix 4) providing a fault prevention process for determining a root cause of a fault and suppressing alerts, the fault prevention process comprising: identifying the root cause of an ensemble failure and automating remediation recommendations to address the ensemble failure; generating an alert from the ensemble fault; performing an alert suppression process using cost-sensitive optimization techniques to suppress certain of the alerts based on a level of urgency; and providing the remainder of the alerts to one or more operators of the plurality of systems; The method of claim 1, further comprising determining the root cause of the failure and suppressing the alert by: (Appendix 5) The method of claim 4, further comprising executing a process for controlling one or more of the plurality of systems based on the remediation recommendation. (Appendix 6) 1. A method for a system including a plurality of devices providing unlabeled data, comprising: performing feature extraction on the unlabeled data to generate a plurality of features; Executing a machine learning framework that converts an unsupervised learning task into a supervised learning task by applying supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning and executing the machine learning framework comprises: performing the unsupervised machine learning to generate the unsupervised machine learning model based on the features; performing supervised machine learning on the results of each of the unsupervised machine learning models to generate a supervised ensemble machine learning model, each of the supervised ensemble machine learning models corresponding to a respective one of the unsupervised machine learning models; selecting one of the unsupervised machine learning models based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models; selecting features based on the results of the evaluation of the unsupervised learning model; and Converting selected ones of said unsupervised learning models into supervised learning models to facilitate explainable artificial intelligence (AI). A method comprising: (Appendix 7) 1. A non-transitory computer readable medium storing instructions for managing a system including a plurality of devices providing label-free sensor data, the instructions comprising: performing feature extraction on the unlabeled sensor data to generate a plurality of features; performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, the fault detection model being generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from unsupervised machine learning; and providing the extracted features and the fault detection labels to a fault prediction model to generate a sequence of fault predictions and features; A non-transitory computer readable medium comprising: (Appendix 8) The machine learning framework includes: performing the unsupervised machine learning to generate the unsupervised machine learning model based on the features; performing supervised machine learning on the results of each of the unsupervised machine learning models to generate a supervised ensemble machine learning model, each of the supervised ensemble machine learning models corresponding to each of the unsupervised machine learning models; and selecting one of the unsupervised machine learning models as the fault detection model based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models. The non-transitory computer-readable medium of claim 7, further comprising: applying the supervised machine learning to the unsupervised machine learning model generated from the unsupervised machine learning to generate the fault detection model. (Appendix 9) The instructions further include generating the fault prediction model, the generating the fault prediction model comprising: extracting features from an optimized feature window from the historical sensor data; determining an optimized fault window and a lead time window based on the faults from the historical sensor data; encoding the features using a long short-term memory (LSTM) autoencoder; training an LSTM sequence prediction model configured to learn patterns in a sequence of features from the feature window to derive impairments in the impairment window; providing the LSTM sequence prediction model as the impairment prediction model; and Ensembling faults consisting of detected faults from the fault detection model and predicted faults from the fault prediction model, the fault prediction being an ensemble fault from the detected faults and the predicted faults. A non-transitory computer-readable medium as described in (Appendix 7), comprising: (Appendix 10) The instructions further include providing a fault prevention process for determining a root cause of a fault and suppressing alerts, the fault prevention process comprising: identifying the root cause of an ensemble failure and automating remediation recommendations to address the ensemble failure; generating an alert from the ensemble fault; performing an alert suppression process using cost-sensitive optimization techniques to suppress certain of the alerts based on a level of urgency; and providing the remainder of the alerts to one or more operators of the plurality of systems; (Appendix 7) for determining the root cause of the failure and suppressing the alert by Non-transitory computer-readable medium. (Appendix 11) The instructions include: The non-transient control method according to (Appendix 10) further includes executing a process for controlling the number of A computer readable medium.

Claims

1. 1. A method performed by a system including a plurality of devices providing unlabeled sensor data, comprising: performing feature extraction on the unlabeled sensor data to generate a plurality of features; performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, the fault detection model being generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from unsupervised machine learning; and providing the extracted features and the fault detection labels to a fault prediction model to generate a sequence of fault predictions and features; A method comprising:

2. The machine learning framework includes: performing the unsupervised machine learning to generate the unsupervised machine learning model based on the features; performing supervised machine learning on the results of each of the unsupervised machine learning models to generate a supervised ensemble machine learning model, each of the supervised ensemble machine learning models corresponding to each of the unsupervised machine learning models; To carry out, and selecting one of the unsupervised machine learning models as the fault detection model based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models.

2. The method of claim 1 , further comprising: generating the fault detection model from applying the supervised machine learning to the unsupervised machine learning model generated from the unsupervised machine learning by:

3. extracting features from an optimized feature window from the historical sensor data; determining an optimized fault window and a lead time window based on the faults from the historical sensor data; encoding the features using a long short-term memory (LSTM) autoencoder; training an LSTM sequence prediction model configured to learn patterns in a sequence of features from the feature window to derive impairments in the impairment window; providing the LSTM sequence prediction model as the fault prediction model; and Ensembling faults consisting of detected faults from the fault detection model and predicted faults from the fault prediction model, the fault prediction being an ensemble fault from the detected faults and the predicted faults. The method of claim 1 , further comprising generating the failure prediction model comprising:

4. providing a fault prevention process for determining a root cause of a fault and suppressing alerts, the fault prevention process comprising: identifying the root cause of an ensemble failure and automating remediation recommendations to address the ensemble failure; generating an alert from the ensemble fault; performing an alert suppression process using cost-sensitive optimization techniques to suppress certain of the alerts based on a level of urgency; and 2. The method of claim 1, further comprising determining the root cause of the fault and suppressing the alert by providing a remainder of the alert to one or more operators of the plurality of devices.

5. The method of claim 4 , further comprising executing a process for controlling one or more of the plurality of devices based on the remediation recommendation.

6. 1. A method performed by a system including a plurality of devices providing unlabeled data, comprising: performing feature extraction on the unlabeled data to generate a plurality of features; Executing a machine learning framework that converts an unsupervised learning task into a supervised learning task by applying supervised machine learning to an unsupervised machine learning model generated from the unsupervised machine learning and executing the machine learning framework comprises: performing the unsupervised machine learning to generate the unsupervised machine learning model based on the features; performing supervised machine learning on the results of each of the unsupervised machine learning models to generate a supervised ensemble machine learning model, each of the supervised ensemble machine learning models corresponding to a respective one of the unsupervised machine learning models; selecting one of the unsupervised machine learning models based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models; selecting features based on results of the evaluation of the unsupervised learning model; and Converting selected ones of the unsupervised learning models into supervised learning models to facilitate explainable artificial intelligence (AI). A method comprising:

7. 1. A non-transitory computer-readable medium storing instructions for managing a system including a plurality of devices providing label-free sensor data, the non-transitory computer-readable medium comprising: The instructions include: performing feature extraction on the unlabeled sensor data to generate a plurality of features; performing fault detection by processing the plurality of features with a fault detection model to generate fault detection labels, the fault detection model being generated from a machine learning framework that applies supervised machine learning to an unsupervised machine learning model generated from unsupervised machine learning; and providing the extracted features and the fault detection labels to a fault prediction model to generate a sequence of fault predictions and features; A non-transitory computer-readable medium for causing a program to execute the program.

8. The machine learning framework includes: performing the unsupervised machine learning to generate the unsupervised machine learning model based on the features; performing supervised machine learning on the results of each of the unsupervised machine learning models to generate a supervised ensemble machine learning model, each of the supervised ensemble machine learning models corresponding to each of the unsupervised machine learning models; and selecting one of the unsupervised machine learning models as the fault detection model based on evaluating the results of the unsupervised machine learning models against predictions generated by the supervised ensemble machine learning models.

8. The non-transitory computer-readable medium of claim 7, further comprising: generating the fault detection model from applying the supervised machine learning to the unsupervised machine learning model generated from the unsupervised machine learning.

9. The instructions are further for causing the system to generate the fault prediction model; The generating of the failure prediction model comprises: extracting features from an optimized feature window from the historical sensor data; determining an optimized fault window and a lead time window based on the faults from the historical sensor data; encoding the features using a long short-term memory (LSTM) autoencoder; training an LSTM sequence prediction model configured to learn patterns in a sequence of features from the feature window to derive impairments in the impairment window; providing the LSTM sequence prediction model as the fault prediction model; and Ensembling faults consisting of detected faults from the fault detection model and predicted faults from the fault prediction model, the fault prediction being an ensemble fault from the detected faults and the predicted faults.

8. The non-transitory computer-readable medium of claim 7, comprising:

10. The instructions are further for causing the system to provide a failure prevention process for determining root causes of failures and suppressing alerts; The damage prevention process comprises: identifying the root cause of an ensemble failure and automating remediation recommendations to address the ensemble failure; generating an alert from the ensemble fault; Cost-sensitive optimization to suppress some of the alerts based on their level of urgency. performing an alert suppression process using optimization techniques; and providing the remainder of the alerts to one or more operators of the plurality of devices; 8. The non-transitory computer-readable medium of claim 7, further comprising:

11. 11. The non-transitory computer-readable medium of claim 10, wherein the instructions are further for causing the system to execute a process for controlling one or more of the plurality of devices based on the remediation recommendation.

Images