Background of recommendations for operational management and asset failure prevention

Abstract

A method for performing fault prediction operations for an industrial process is disclosed. The method may include collecting a physical sensor data set and generating a virtual sensor data set by applying a physics-based model to a subset of the physical sensor data set. The method may also include identifying a first set of features from the physical sensor data set and the virtual sensor data set. The method may further include using a first set of machine training models applied to the first set of features to identify a set of anomaly detection scores, a first set of contributors to the set of anomaly detection scores, and a second set of features having feature importance scores equal to or greater than a threshold. The method may include generating at least one fault prediction model based on the first set of machine training models, and applying the at least one fault prediction model to the physical sensor data set and the virtual sensor data set to calculate a likelihood score for a predicted fault of the asset.

Description

Technical Field

[0001] The present disclosure generally relates to automated fault prediction in industrial systems.

Background Art

[0002] Automated fault prediction can be relevant to many complex industrial systems in a number of different industrial contexts (e.g., industries). For example, different industrial contexts can include, without limitation, manufacturing, entertainment (e.g., theme parks), hospitals, airports, utilities, mining, oil and gas, warehouses, and transportation systems. Two major fault types can be defined by how far a fault is from its symptoms in terms of the time of the fault. Short-term fault types can relate to symptoms and faults that are close in time (e.g., within hours or days). For example, an overloading fault on a conveyor belt can be a short-term fault type associated with symptoms that are close in time. Long-term fault types can relate to symptoms that are far from the fault in terms of time (e.g., weeks, months, or years). Long-term fault types of system component faults often progress slowly and chronically and can have broader negative impacts such as a shutdown of the entire system including the component with the fault. For example, long-term faults can include component faults due to damage and cracks in a dam or metal fatigue.

[0003] Failures in industrial systems, while rare, can incur significant (or substantial) financial costs (e.g., operational, maintenance, repair, logistics), reputational costs (e.g., marketing, market share, sales, quality), human resource costs (e.g., scheduling, skill sets), and / or liability costs (e.g., safety, health). Some industrial systems may not have fault detection processes in place. In other industrial systems, fault detection is performed manually based on domain knowledge derived from real-time sensor data. Manual fault prediction and / or detection can present challenges when dealing with high-frequency data (e.g., vibration sensor data, IoT data).

[0004] Even when faults can be detected and / or predicted, they may have already occurred or be very close to occurring, making repair or recovery too late. Therefore, faults must be predicted at a time when operators or technicians have sufficient time to respond to, repair, or prevent further faults. Proactive fault prediction can facilitate fault avoidance and mitigate the losses and / or negative impacts resulting from faults.

[0005] In some embodiments, fault data can be costly to collect, and in some cases, no fault data may be collected at all, or the fault data may be inaccurate, incomplete, and / or unreliable. This presents challenges in building supervised solutions that rely on fault data as labels. Therefore, below, a system is presented that collects and uses appropriate data to predict one or more short-term or long-term faults in time to reduce or avoid predicted faults and associated costs. In some embodiments, the system may further identify a set of root causes of a fault and use the root causes as further information to facilitate fault diagnosis and take action to repair or avoid the fault. In some embodiments, root cause analysis may be performed by the system without manual inspection of components or visualization of sensor data and metrics (for example, because manual inspection can be time-consuming, costly, and / or error-prone). In some embodiments, a set of root causes is a set of root causes identified at the sensor data level (e.g., data collected regarding temperature, vibration levels, or several other measurable / monitored characteristics associated with the fault). [Overview of the Initiative] [Means for solving the problem]

[0006] The exemplary implementations described herein include innovative methods. The method may include collecting sets of physical sensor data. The method may further include generating sets of virtual sensor data by applying a physical-based model to a subset of the sets of physical sensor data. The method may also include identifying a first set of features from the sets of physical and virtual sensor data by performing at least one sampling operation, aggregation operation, or feature derivation operation on the sets of physical and virtual sensor data based on an optimized sampling rate or optimized aggregation statistics. The method may further include identifying a set of anomaly detection scores, a first set of contributors to the sets of anomaly detection scores, and a second set of features having feature importance scores greater than or equal to a threshold, using a first set of machine-trained models applied to the first set of features. The method may further include generating at least one fault prediction model based on the first set of machine-trained models. The method may also include applying at least one fault prediction model to the sets of physical and virtual sensor data to calculate a likelihood score for predicted faults of an asset.

[0007] The exemplary implementations described herein include an innovative computer-readable medium for storing computer-executable code. The computer-executable code may include instructions for collecting sets of physical sensor data. The computer-executable code may also include instructions for generating sets of virtual sensor data by applying a physical-based model to a subset of the sets of physical sensor data. The computer-executable code may further include instructions for identifying a first set of features from the sets of physical and virtual sensor data by performing at least one sampling, aggregation, or feature derivation operation on the sets of physical and virtual sensor data based on an optimized sampling rate or a set of optimized aggregation statistics. The computer-executable code may also include instructions for identifying a set of anomaly detection scores, a first set of contributors to the sets of anomaly detection scores, and a second set of features having feature importance scores greater than or equal to a threshold, using a first set of machine-trained models applied to the first set of features. The computer-executable code may also include instructions for generating at least one fault prediction model based on the first set of machine-trained models. The computer-executable code may further include instructions for applying at least one failure prediction model to sets of physical sensor data and sets of virtual sensor data in order to calculate likelihood scores for predicted failures of the asset.

[0008] The exemplary implementations described herein include innovative devices. The devices may include memory and at least one processor configured to collect sets of physical sensor data. At least one processor may also be configured to generate sets of virtual sensor data by applying a physical-based model to a subset of the sets of physical sensor data. At least one processor may further be configured to identify a first set of features from the sets of physical and virtual sensor data by performing at least one sampling, aggregation, or feature derivation operation on the sets of physical and virtual sensor data based on an optimized sampling rate or optimized aggregation statistics. At least one processor may also be configured to identify a set of anomaly detection scores, a first set of contributors to the sets of anomaly detection scores, and a second set of features having feature importance scores greater than or equal to a threshold, using a first set of machine-trained models applied to the first set of features. At least one processor may also be configured to generate at least one fault prediction model based on the first set of machine-trained models. At least one processor may be further configured to apply at least one failure prediction model to a set of physical sensor data and a set of virtual sensor data in order to calculate a likelihood score for a predicted failure of an asset. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 shows the basic concepts of the circular economy as relating to several aspects of this disclosure.

[0010] [Figure 2A] Figure 2A shows the components of a physical-based model relating to several aspects of this disclosure.

[0011] [Figure 2B] Figure 2B shows a feature engineering module relating to several aspects of this disclosure.

[0012] [Figure 3] FIG. 3 is a flowchart showing an exemplary workflow for optimizing at least one of a sampling rate and aggregation statistics according to some aspects of the present disclosure.

[0013] [Figure 4] FIG. 4 is a diagram showing a set of components of an implementation form of an anomaly detection module (e.g., an unsupervised anomaly detection model, etc.) according to some aspects of the present disclosure.

[0014] [Figure 5] FIG. 5 is a diagram showing a set of operations related to short-term fault prediction.

[0015] [Figure 6] FIG. 6 is a diagram showing a set of operations related to the generation of a long-term fault prediction score for identifying and predicting potential long-term faults according to some aspects of the present disclosure.

[0016] [Figure 7] FIG. 7 is a diagram showing a set of operations for identifying a set of root causes related to short-term faults according to some aspects of the present disclosure.

[0017] [Figure 8] FIG. 8 is a flowchart showing a set of operations for identifying a set of contributing factors related to long-term faults in assets in one or more asset classes according to some aspects of the present disclosure.

[0018] [Figure 9] [[ID=�8]]FIG. 9 is a flowchart showing a system for performing fault prediction operations for an industrial process.

[0019] [Figure 10] FIG. 10 is a flowchart showing a method for identifying a set of root causes (e.g., contributing factors) for fault prediction according to some aspects of the present disclosure.

[0020] [Figure 11] FIG. 11 shows an exemplary computing environment having an exemplary computer device suitable for use in some exemplary implementations. **DETAILED DESCRIPTION OF THE INVENTION**

[0021] The following detailed description shows the details of the drawings and implementation examples of this application. Reference numerals and descriptions of redundant elements between the drawings are omitted for clarity. The terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automated" may include a fully automated implementation or a semi-automated implementation that includes user or administrator control over certain aspects of the implementation, depending on the desired implementation of those skilled in the art practicing the implementation forms of this application. The selection can be made by the user via a user interface or other input means, or implemented by a desired algorithm. The implementation examples described herein can be used alone or in combination, and the functions of the implementation examples can be implemented by any means according to the desired implementation form.

[0022] In this disclosure, systems, devices, and methods are presented that address the problems of automated prediction of failures (short-term and long-term failures) and identification of the root causes of predicted failures in industrial systems with unlabeled high-frequency sensor data.

[0023] This disclosure presents systems, apparatus, and methods for providing techniques for fault prediction operations for industrial processes. For example, the method may include collecting sets of physical sensor data. The method may further include generating sets of virtual sensor data by applying a physical-based model to a subset of the sets of physical sensor data. The method may also include identifying a first set of features from the sets of physical and virtual sensor data by performing at least one sampling, aggregation, or feature derivation operation on the sets of physical and virtual sensor data based on an optimized sampling rate or optimized aggregation statistics. The method may further include identifying a set of anomaly detection scores, a first set of contributing factors (e.g., root causes) to the sets of anomaly detection scores, and a second set of features having feature importance scores above a threshold, using a first set of machine training models applied to the first set of features. The method may also include generating at least one fault prediction model based on the first set of machine training models. The method may further include applying at least one failure prediction model to a set of physical sensor data and a set of virtual sensor data in order to calculate a likelihood score for the predicted failure of the asset.

[0024] In some embodiments, the systems, apparatus, and methods described herein may address both short-term and long-term failure prediction and the derivation of the root causes of predicted failures in order to mitigate or avoid negative impacts before failure occurs. Several key benefits may exist for failure prediction and prevention solutions. In some embodiments, failure prediction and prevention solutions can reduce unplanned downtime and operational delays while increasing productivity, output, and operational efficiency. In some embodiments, failure prediction and prevention solutions can optimize yield and increase margins / profits.

[0025] In some aspects, failure prediction and prevention solutions can maintain production consistency and product quality. In some aspects, failure prediction and prevention solutions can reduce unplanned costs related to logistics, maintenance scheduling, labor, and repair costs. In some aspects, failure prediction and prevention solutions can reduce damage to assets and the entire industrial system. In some aspects, failure prediction and prevention solutions can reduce accidents to operators and improve operator health and safety. The proposed solutions generally, but not limited to, benefit all entities involved in the industrial system, including operators, supervisors / managers, maintenance technicians, SMEs / domain experts, assets, and the system itself.

[0026] The following describes some of the problems (limitations and constraints) of conventional systems and methods. This specification describes techniques for solving these problems. For example, conventional systems / methods may be heavily reliant on accurate historical failure data. However, accurate historical failure data is usually not available for several reasons. For example, historical failure-related data may not be collected, or may be inaccurate or incomplete; a process for collecting failure data may not exist or may not collect enough data to perform useful analysis; and / or the collected data (e.g., IoT data) may be too voluminous for manual processing, detection, and identification of failure data.

[0027] In addition, in some embodiments, there may be no standard process for effectively and efficiently detecting and classifying both common and rare events. Manual processes for collecting faults by labeling sensor data based on domain knowledge can, in some embodiments, be inaccurate, inconsistent, unreliable, and time-consuming. Processes deployed by industrial system operators to collect fault-related data may, in some embodiments, be insufficient to identify and investigate root causes. In some embodiments, inadequate data collection can often be due to a lack of understanding at the time of data collection regarding how the data may help in identifying root causes. Therefore, in some embodiments, an automated standard process or method is provided for accurately, effectively, and efficiently detecting and collecting faults in industrial systems.

[0028] Conventional fault prediction solutions, in some embodiments, do not perform well in the case of rare fault events, which involve associated lead times (e.g., sufficient lead time to implement solutions to repair or prevent the predicted fault). In some embodiments, fault prediction solutions may not perform well for rare events because sensor data may be heavily biased toward good operating conditions. Due to the rarity of such faults, in some embodiments, it is extremely difficult to build supervised machine learning models with high accuracy and sensitivity. For example, in some embodiments, it may be difficult to determine one or more optimal windows to collect features / evidence related to faults or to identify signals that can be used to predict faults.

[0029] In some embodiments, there may not be enough data to identify patterns from a limited amount of fault data. For example, industrial systems typically operate under normal conditions, and faults are usually rare events, making it difficult to capture patterns for a limited number of faults and therefore difficult to predict such faults. Consequently, in some embodiments, it may be difficult to construct the correct relationship between normal cases and rare fault events in chronological order because it is difficult to capture the sequence patterns of the progression of rare faults. Therefore, a system, apparatus, and / or method may identify the correct signals (e.g., features) for fault prediction within an optimal feature window to provide fault prediction with sufficient lead time to address anticipated faults. A system, apparatus, and / or method may have the ability to construct / identify the correct relationship between normal cases and rare faults, and the progression of rare faults in either short-term or long-term faults.

[0030] Systems, devices, and / or methods may provide automated root cause analysis. Root cause analysis of failures may be performed manually based on domain knowledge and data visualizations, which can be subjective, time-consuming, and prone to errors. In some cases, root causes may be associated with raw sensor data not addressed by the domain knowledge or data visualizations used for manual root cause analysis. Systems, devices, and / or methods may provide automated root cause analysis based on standardized methods to identify the root causes of anticipated failures and output root causes at different levels (including the raw sensor data level).

[0031] In some embodiments, sensor data (e.g., IoT sensor data, vibration data) may be high-frequency data (e.g., 1000Hz to 3000Hz). High-frequency data presents challenges in constructing solutions to fault prediction problems in some embodiments. For example, high-frequency data may be associated with high levels of noise or long or resource-intensive analysis (e.g., computation) times. The sampling frequency or aggregation window may require optimization to accurately predict either short-term or long-term faults. Therefore, the system, apparatus, and / or method may provide a window optimization operation to identify windows and / or aggregate statistics optimized for fault prediction.

[0032] In some embodiments, physical sensor data may not be able to capture all signals that could be useful for monitoring the system due to the harsh environment in which the sensors are installed, the cost of the sensors, and / or the functionality of the sensors. As a result, the collected data may not be sufficient to monitor the health of the system and capture potential risks and failures. In some embodiments, the inability to capture all potentially useful signals can pose a challenge to the development of fault prediction solutions. Therefore, systems, devices, and / or methods may enhance physical sensor data to capture the necessary signals to help the system monitor and develop fault prediction solutions. For example, physical sensor data may be processed by a set of physical-based models to generate virtual sensor data.

[0033] In some embodiments, a system, apparatus, and / or method may implement and / or include several techniques for generating one or more fault prediction models and / or identifying a set of root causes. These techniques may include semi-empirical methods utilizing one or more physical base models and data-driven machine learning models. In some embodiments, a physical-based model may be used to enhance sensor data with further features based on the physics of the system. For example, torque on a system component (e.g., a joint on a robotic arm) may be calculated based on a set of physical data sensors including one or more such sensors associated with an accelerometer (linear or rotary), a force sensor, an IoT motor, or an associated component (e.g., a motor, boom end, etc.). Furthermore, sampling and aggregation optimization methods may be used to sample and aggregate high-frequency data to derive features from the aggregated data.

[0034] The technique may further include one or more unsupervised fault prediction techniques and / or solutions. In some embodiments, the unsupervised fault prediction techniques and / or solutions may be based on sensor data, without relying on historical fault data. For example, an unsupervised ensemble anomaly detection model may be used to derive (1) anomaly scores as labels and / or (2) features of the fault prediction model. The technique and / or solution may further include a supervised surrogate model for the anomaly detection model for feature selection, root cause analysis, and model evaluation.

[0035] In some embodiments, the short-term failure prediction model may be based on ensemble anomaly scores, selected features, and root causes identified using an anomaly detection model, and may use one or more window-based feature derivation techniques to derive aggregated features and predict failures with lead times, for example, by using machine learning such as a deep learning sequence prediction model (such as a long-short-term memory (LSTM) or gated recurrent unit (GRU)). The long-term failure prediction model may, in some embodiments, be based on aggregated ensemble anomaly scores, selected features, and root causes from an asset-specific anomaly detection model within a set of system assets. As a result, the long-term failure prediction model may be constructed based on aggregated features from multiple assets.

[0036] In some embodiments, root cause analysis of short-term and long-term failures may be further performed to identify the root causes of predicted failures (short-term and long-term failures) at different levels. For example, root causes may be identified based on detected anomaly scores, selected sets of features, and sensor data (e.g., physical or virtual sensor data) by using a chain of explainable AI models and aggregation / ranking algorithms.

[0037] Figure 100 is a conceptual element of a solution architecture for semi-empirical unsupervised fault prediction and root cause analysis relating to several aspects of the present disclosure. Figure 100 includes a set of sensor data 110 (e.g., high-frequency data from IoT sensors) collected from multiple physical sensors. The physical sensor data 110 may be provided to a physical-based model 120. The physical-based model 120 may be applied to the physical sensor data (or a subset of the physical sensor data) to generate virtual sensor data (e.g., data that enhances a dataset for fault prediction and root cause analysis). The physical and virtual sensor data may be provided to a feature engineering module 130 to sample and aggregate the sensor data (physical and virtual) and derive new features based on an optimized sampling rate and / or an optimized set of aggregate statistics / characteristics. In some aspects, the feature engineering module 130 may perform optimization functions (e.g., machine learning-based optimization) for one or more of the sampling rate or aggregate statistics / characteristics set before execution. For example, in some embodiments, one of the sampling rate or aggregate statistics / characteristics may be provided by the user based on domain knowledge, while the other of the sampling rate or aggregate statistics / characteristics may be optimized.

[0038] Data generated and / or processed by the feature engineering module 130 may be provided to the anomaly detection module 140. The anomaly detection module 140 may use the data from the feature engineering module 130 to build multiple anomaly detection models and ensembles of anomaly detection models. The anomaly detection module 140 may build multiple anomaly detection models and ensembles of anomaly detection models using machine learning operations in a first learning phase and use them in a second prediction (prediction) phase. The anomaly detection module 140 may use multiple anomaly detection models and ensembles of anomaly detection models to generate an ensemble anomaly score, derive root causes (e.g., relevant physical or virtual sensors) for each data point, and select features through a surrogate supervised model for the ensemble anomaly detection model.

[0039] The data processed by the anomaly detection module 140 may be provided to the short-term failure prediction module 150. The short-term failure prediction module 150 may derive features by lookback feature windowing, or it may use a deep learning sequence prediction model (e.g., LSTM or GRU) to predict failures in advance. Based on the output of the short-term failure prediction module 150, the system may use root cause analysis of the short-term failure module 160 to identify and / or derive a set of root causes. For example, for each predicted failure, the root cause analysis of the short-term failure module 160 may derive the root cause by a chain of explainable AI techniques and ranking / aggregation algorithms.

[0040] Similarly, data processed by the anomaly detection module 140 may be provided to the long-term failure prediction module 170. The long-term failure prediction module 170 may derive features by aggregation techniques based on anomaly scores, root causes, and selected features. The long-term failure prediction module 170 may use at least one further anomaly detection model to identify and predict long-term failures. Based on the output of the long-term failure prediction module 170, the system may use root cause analysis of the long-term failure module 180 to identify and / or derive a set of root causes. In some embodiments, the root cause analysis of the long-term failure module 180 may construct a surrogate supervised model for another anomaly detection module. In some embodiments, for each predicted failure, the root cause analysis of the long-term failure module 180 may use a surrogate supervised model to derive a set of root causes by a chain of explainable AI techniques and ranking / aggregation algorithms.

[0041] The following sections provide a detailed description of each component in the solution architecture. The specific methods used in relation to root cause analysis of the feature engineering module 130, anomaly detection module 140, short-term failure prediction module 150, short-term failure module 160, long-term failure prediction module 170, and long-term failure module 180 are described below.

[0042] In some embodiments, sensor data 110 may be collected by IoT sensors installed on a set of assets under consideration and used to collect data for monitoring the health and performance of the assets and the overall system. Various types of sensors are designed to collect various types of data for various industries, various assets, and / or various tasks. In the following description, sensors are generally described by the assumption that the method of data processing is applicable to different types of sensor data with minor adjustments. Some examples of sensors that may be used to collect sensor data 110 may include temperature sensors, pressure sensors, vibration sensors, acoustic sensors, motion sensors, optical sensors, LIDAR sensors, infrared (IR) sensors, acceleration sensors, gas sensors, smoke sensors, humidity sensors, level sensors, image sensors (cameras), proximity sensors, water quality sensors, and / or chemical sensors.

[0043] For a specific target asset, in addition to sensors installed on the target asset, other sensors installed within the system may be used to build a model for the target asset (e.g., anomaly detection model, fault prediction model, and / or root cause model). For example, data collected from a set of sensors installed on the asset or system components upstream of the target asset and / or downstream of the target asset may be used to build a set of fault prediction models and / or may be identified as being related to the root causes of predicted faults. The selection of sensors considered when building different models may, in some embodiments, be based on domain knowledge. In some embodiments, a full set of sensors may be used to generate different models for a specific target asset, and feature detection / selection and root cause analysis may be used to narrow down the set of sensors associated with the trained model (e.g., fault prediction model). For example, data analysis and model-based feature selection may be applied to select sensors associated with fault prediction models.

[0044] Figure 2A is Figure 200 showing components of a physical-based model relating to several embodiments of the present disclosure. In some embodiments, the physical-based model 220 corresponds to the physical-based model 120 in Figure 1. As described above, physical sensors may not capture a complete set of relevant signals and / or metrics to assist in monitoring the health of the system. The inability to capture a complete set of relevant signals and / or metrics may be due to one or more reasons. For example, a physical sensor may not capture a set of expected signals due to physical limitations of the hardware, or a physical sensor may not be able to be installed in harsh environments such as inside a place with high levels of radiation or pressure or temperature outside the range in which the sensor can function.

[0045] In some embodiments, a set of physical sensors may not capture data at the expected frequency. To overcome the limitations of physical sensors, in some embodiments, a software-based method may be used to acquire the expected signal. In some embodiments, the physical-based model 224 may be a representation of laws of nature that inherently incorporate the concepts of time, space, causality, and generalizability. These laws of nature define, in some embodiments, how physical, chemical, biological, and geological processes unfold. In some embodiments, the physical-based model 224 may be a function that acquires multiple inputs (e.g., physical sensor data 222) and generates multiple outputs (e.g., virtual sensor data 226). Inputs may come from predefined profiles at design time (e.g., motion profiles) or from physical sensors (e.g., physical sensor data 222) during operation. Outputs (e.g., virtual sensor data 226) may, in some embodiments, include multiple variables and represent a set of virtual sensors. In some embodiments, a virtual sensor is a type of software-derived information from available information that represents or is associated with data that a corresponding physical device would collect. For example, data collected by a physical accelerometer may be combined with a known mass of the relevant component to calculate the (virtual) output of a virtual force sensor of the relevant component. In some embodiments, virtual sensors and associated virtual data may be used in the same way as data from physical sensors to derive insights and / or build models and / or solutions for downstream tasks.

[0046] The benefits of using virtual sensors may, in some embodiments, include data acquisition and data validation. Data acquisition may include using virtual sensors to collect data (e.g., acquisition signals) that cannot be captured by physical sensors. For example, physical sensors may be unable to capture data due to hardware limitations of the physical sensors or harsh environments incompatible with the installation or functionality of the physical sensors. In some embodiments, if there is not much data available early in the installation of physical sensors, virtual sensors may be used to derive insights and build models. In some embodiments, virtual sensors may generate high-frequency data that a set of physical sensors may be unable to capture. Data validation may also be used in some embodiments to validate physical sensor data when collecting the same or correlated sets of data. For example, virtual sensor data may be used as “expected” values, while physical sensor data may be used as “observed” values, and any discrepancy or difference between them may be used as a signal to detect abnormal behavior or anomalies in the system.

[0047] Through virtual sensors, in some embodiments, physical-based models and machine learning models may be combined in a semi-empirical manner, thereby obtaining the advantages of both domain knowledge (through physical-based models) and data-driven methods (through machine learning models). Physical models are theoretically self-consistent and have demonstrated success in providing experimental predictions. Physical-based models typically perform well during system design. However, during operation, complex system interactions and situations are involved, and theoretical physical-based models based on domain knowledge and simulations may fail to capture the underlying mechanisms, becoming more inaccurate and less sensitive. On the other hand, data-driven methods (when sufficient data is collected) can capture faint signals and patterns within complex systems and derive appropriate insights for decision-making. Physical-based models can complement machine learning models by incorporating domain knowledge into artificial intelligence (AI) and / or machine learning (ML) models, which can be costly to discover based on purely data-driven methods. Figure 2A shows how the physical-based model 224 is applied to the physical sensor data 222 in a time-series format to derive the virtual sensor data 226. In some embodiments, only a subset of the physical sensor data (e.g., a subset of the sensor data 110 in Figure 1) may be used as input physical sensor data 222 to the physical-based model 224. In some embodiments, the physical sensor data 222 may be preprocessed before being supplied to the physical-based model 224. For example, the physical sensor may capture the position of the asset as the asset moves, while the physical-based model may be based on the velocity and acceleration of the asset as the asset moves. Thus, the preprocessing or physical-based model may include first derivatives used to compute the position data and associated velocity data, and may also include second derivatives used to compute the position data and associated acceleration data. Data from both the physical and virtual sensors will be used as input to the next module in the solution architecture (e.g., the feature engineering module 130 in Figure 1).In some embodiments, the physics-based model may be constructed by simulation software and / or tools, or it may be constructed based on domain knowledge.

[0048] Figure 2B is Figure 250 showing a feature engineering module 230 according to some aspects of the present disclosure. In some aspects, the feature engineering module 230 is one implementation of the feature engineering module 130 of Figure 1. In some aspects, some feature engineering techniques may be introduced to derive features from sensor data (e.g., physical or virtual sensor data, high-frequency IoT data, etc.). Figure 250 shows some steps within the feature engineering module 230. Both physical and virtual sensor data may be used to derive features in some aspects.

[0049] Since the sensor data may, in some embodiments, be high-frequency (e.g., 1000 Hz or 3000 Hz) time-series data, there may be downsampling operations to convert the data to lower frequencies and / or aggregation operations to aggregate the data in order to capture useful signals for downstream tasks and / or analysis and to use some techniques to derive features from low-frequency and / or aggregated data. The downsampling and / or aggregation operations may be performed in a sampling and aggregation module 234 that receives the sensor data (e.g., physical and virtual sensor data 232). In some embodiments, the output of the sampling and aggregation module 234 may be provided to a feature derivation module 236 to identify a first set of features 238.

[0050] In some embodiments, the sampling rate and aggregate statistics / characteristics may be determined before performing downsampling and / or aggregation operations for high-frequency sensor data. For example, the sampling rate may be related to the amount of data retained when providing the data to the feature derivation module 236. For example, if the sampling rate is 0.01, 1 percent of the original data will be retained in the resulting data, while if the sampling rate is 0.1, 10 percent of the original data will be retained in the resulting data for feature derivation.

[0051] To compensate for data loss resulting from downsampling operations, in some embodiments, aggregate statistics / characteristics may be provided for the original high-frequency sensor data across each set of time windows. For example, aggregate statistics / characteristics may include, but are not limited to, the minimum value in the time window, the maximum value in the time window, the mean value in the time window, the standard deviation, the value associated with the first percentile, the value associated with the 99th percentile, the value associated with the 25th percentile, the value associated with the 50th percentile, the value associated with the 75th percentile, and trends. For example, when sampling data between 1000 Hz (1000 data points / second) and 1 Hz (1 data point / second), several statistics would be calculated in relation to the 1000 Hz data every second, and such statistics would be provided in the resulting data provided to the feature derivation module 236.

[0052] The sampling rate and aggregate statistics may, in some aspects, be presented based on domain knowledge. However, the presented values ​​may not be optimal for downstream solutions. Therefore, optimization methods for optimizing the sampling rate and aggregate statistics for downstream solutions may be performed before any downsampling or aggregation operations for real-time prediction failures (e.g., during the estimation phase after the model has been trained and root causes have been identified).

[0053] Figure 3 is a flowchart 300 illustrating an exemplary workflow for optimizing the sampling rate and at least one of the aggregate statistics relating to several aspects of the present disclosure. The optimization may be performed by the feature engineering module 130 or 230 (or more specifically, the sampling and aggregation module 234). In 302, a set / list of aggregate statistics may be generated that identifies the statistics and / or characteristics included in the results of the aggregation operation. As described above, the aggregate statistics / characteristics may include, but are not limited to, the minimum value in a time window, the maximum value in a time window, the mean value in a time window, the standard deviation, the value associated with the first percentile, the value associated with the 99th percentile, the value associated with the 25th percentile, the value associated with the 50th percentile, the value associated with the 75th percentile, and trends. The possible space of aggregate statistics and sampling rates may, in some aspects, be explored based on at least one of several optimization methods (e.g., Bayesian optimization, grid search, or random search).

[0054] In 304, the workflow may include randomly selecting a subset of aggregate statistics from a set / list of aggregate statistics generated in 302. Randomly selecting a subset of aggregate statistics from a set / list of aggregate statistics may include generating a random binary value of length N (e.g., an N-bit binary value), where N is the number of elements in the set / list of aggregate statistics such that elements of the set / list of aggregate statistics corresponding to "0" in the N-bit binary value are not included in the randomly selected subset of aggregate statistics, while elements of the set / list of aggregate statistics corresponding to "1" are included in the randomly selected subset of aggregate statistics.

[0055] In 306, the workflow may include selecting a sampling rate. In 306, the sampling rate may be selected randomly or based on one of the domain knowledge or business requirements. For example, the sampling rate may be selected based on knowledge of asset failures and associated characteristic time scales.

[0056] In 308, the workflow may include performing sampling and aggregation operations on sensor data (e.g., physical sensor data and / or virtual sensor data). The subset of aggregation statistics and sampling rates used to perform sampling and aggregation operations in 308 may, in some embodiments, be a subset of the aggregation statistics selected in 304 and the sampling rates selected in 306. Performing sampling and aggregation operations, as described in relation to the feature engineering module 230 in Figure 2B, may provide data for feature derivation operations performed by the feature derivation module 236.

[0057] The workflow may then include, in 310, building at least one model based on the sampled and aggregated sensor data (and / or any identified features within the first set of identified features). The at least one model may include one or more anomaly detection / scoring models, short-term fault prediction models, or long-term fault prediction models. The model built based on the subset of aggregate statistics selected in 304 and the sampling rate selected in 306 may be evaluated based on several set model performance metrics such as overall accuracy, precision, and recall. In some embodiments, building a model in 310 may include training a machine learning model based on the sampled and aggregated data.

[0058] In 312, the workflow may include determining whether it has reached a set and / or desired number of iterations for selecting the sampling rate and aggregate statistics. The set number of iterations may be based on a grid-based search of the sampling rate-aggregate statistics space or on some other characteristic of the system or model. If the workflow determines in 312 that it has not reached a set and / or desired number of iterations, the process may return to 304 to select a different subset of aggregate statistics.

[0059] However, if the workflow determines that a set and / or desired number of iterations have been met, the workflow may proceed to train a model (e.g., a Gaussian regression model) in 314. The trained model may be a surrogate model based on the results from 310. In some embodiments, the features may be a binary representation of aggregate statistics plus a sampling rate, and the targets may also be performance metrics. The surrogate model may be one of the Gaussian process models or Tree Parzen Estimator (TPE) models for Bayesian optimization. In some embodiments, if the machine learning model for downstream tasks is too complex, a simpler machine model (linear model, tree-based model) may be used as a surrogate for the complex machine learning model.

[0060] In 316, the workflow may include defining acquisition functions to help select an optimized set of features (binary representation of aggregate statistics plus sampling rate) for a Gaussian regression model. In some embodiments, the acquisition function may be the probability of improvement, the expected improvement, the Bayesian expected loss, the upper limit of confidence (UCB), Thompson sampling, or a hybrid of one or more of these. In some embodiments, each different acquisition function may be associated with different trade-offs between exploration and exploitation, and may be selected to minimize the number of feature queries.

[0061] In 318, the workflow may include training one or more machine learning models with the best set of values ​​obtained based on the acquisition features adopted in 316. Training in 318 may include identifying performance metrics and execution time. Based on the output of training one or more components 318, the workflow may determine whether the execution time is greater than or equal to a threshold time. If in 320 the execution time is determined to be greater than or equal to a threshold, in some embodiments the workflow may return in 304 to randomly select a subset of aggregate statistics from a set / list of aggregate statistics. If in 320 the execution time is determined to be less than a threshold, the workflow may further determine in 322 whether one or more criteria for stopping (e.g., stopping criteria) are met. If the workflow determines in 322 that the stopping criteria are not met (e.g., the training performance metrics do not meet a predefined criterion), the last selected best set of features (binary representation of aggregate statistics plus sampling rate) and model performance metrics may be added in 324 to the training dataset for the Gaussian regression model, and the workflow may return in 314 to a further round of training, as illustrated. If the workflow determines in 322 that the termination criteria have been met, the workflow may be terminated. In some embodiments, the criteria may relate to the number of rounds, a model metric, a variance or entropy reduction rate, or other relevant criteria.

[0062] In some embodiments, different algorithms may be used in the optimization process at different stages of the workflow shown in Figure 3. For example, while the optimization method described above relates to Bayesian optimization, in some embodiments, other optimization methods such as grid search and random search may be used. Similarly, while a Gaussian process model may generally be used as a surrogate function for Bayesian optimization, the workflow may use other surrogate functions for specific business / industry problems. As described above, in some embodiments, the workflow may utilize a simpler machine model (e.g., a linear model or a tree-based model) as a surrogate for a complex machine learning model if the machine learning model for the TPE or downstream task is too complex. In addition, different acquisition functions may be implemented in 316, but are not limited to, including hybrids of one or more acquisition functions such as probability of improvement, expected improvement, Bayesian expected loss or UCB, Thompson sampling, and / or acquisition functions. Each different acquisition function may be associated with a trade-off between exploration and exploitation, and a particular acquisition function may be selected to minimize the number of function queries.

[0063] In some embodiments, two phases of optimization may be defined. The first phase may include determining aggregate statistics (e.g., a selected subset of aggregate statistics) and optimizing the sampling rate, while the second phase may include determining the sampling rate in order to optimize the set of aggregate statistics. In each phase, the determined parameter (e.g., the sampling rate or one of the subsets of aggregate statistics) may be determined based on domain knowledge. In some embodiments, the first and second phases may be performed iteratively or in different orders. For example, the sampling rate (or set of possible sampling rates) may be identified based on domain knowledge, and the second phase of optimization may be performed according to the workflow in Figure 3. For example, in the second phase, in 306, the sampling rate may be selected based on the sampling rate or set of sampling rates identified based on domain knowledge. After optimizing a subset of aggregate statistics, the first phase may be performed (e.g., first or i-th) to optimize the sampling rate for the optimized subset of aggregate statistics identified in the second phase. The first and second phases may be iterated to perform a set of "one-dimensional" optimization operations (e.g., only one set of varying parameters) so as to converge to an optimized set of parameters for the sampling rate and aggregate statistics.

[0064] Based on an optimized sampling rate and aggregated statistics, sets of historical sensor data (e.g., physical and / or virtual sensor data) may be sampled and aggregated to generate processed sensor data. The processed sensor data may be used, for example, by feature engineering module 130 or 230 (or feature derivation module 236) to derive a first set of features by applying time series data techniques. The techniques may include, but are not limited to, moving averages, moving variances, and one or more differences associated with the rate of change of values ​​in time series data (e.g., for first or second derivatives).

[0065] In addition, for each time point, feature detection may define a lookback feature window to derive several statistics about the data within the feature window (e.g., in set-off aggregate statistics), and the derived statistics may be used as further features at the current time point (e.g., the derived statistics may be associated with the time point of the improved dataset). The length of the feature window may be determined (at least initially) based on domain knowledge and may be further optimized by optimization techniques (such as grid search, random search, or Bayesian optimization as described above in relation to Figure 3). Such derived features may, in some embodiments, be used together with aggregated data as features of downstream solutions.

[0066] Figure 4 shows a set of components for an implementation of an anomaly detection module 140 (e.g., an unsupervised anomaly detection model) according to some aspects of the present disclosure. The unsupervised anomaly detection model may incorporate (or be based on) a set of features 410 (e.g., corresponding to feature 238). Based on features 410 (e.g., derived by feature engineering module 130 or 230), a set of anomaly detection models 420 (e.g., including a set of anomaly detection models 420-1, 420-2, and 420-K) may, in some aspects, be used to generate a set of anomaly scores 430 (e.g., including a set of anomaly scores 430-1, 430-2, and 430-K) for each time point. In some aspects, the anomaly scores (e.g., anomaly scores 430-1, 430-2, or 430-K) may indicate how likely an anomaly is to occur at each time point. For example, anomaly scores may be defined to be in the range of 0 to 1, with larger values ​​representing a greater likelihood of an anomaly. The set of anomaly scores 430 may, in some embodiments, be used as labels and features for constructing a fault prediction model (e.g., a model associated with the short-term fault prediction module 150 or the long-term fault prediction module 170 in Figure 1). In some embodiments, multiple anomaly detection methods (represented by the anomaly detection models within a set of anomaly detection models 420) may be applied to the features 410 by each of the anomaly detection models within the set of anomaly detection models 420, thereby generating anomaly scores for the set of anomaly scores 430 at each point in time. The set of anomaly scores 430 from multiple models may, in some embodiments, be combined (e.g., into an ensemble anomaly score 440) to remove any bias that may be incorporated into the anomaly detection models within the set of anomaly detection models 420. A supervised surrogate model 450 may be constructed based on the features 410 and the ensemble anomaly score 440 to select features 475, explain the anomaly scores (e.g., using an explainable AI model 460), and evaluate the anomaly detection model.

[0067] A description of the elements and associated workflows of Figures 1, 2, and 4 for performing anomaly detection to generate a set of anomaly scores 430 (or collectively an ensemble anomaly score 440), root causes 480 of the anomaly scores, and selected features 475 is provided below. For example, a feature engineering module 130 or 230 may be used to generate a set of features 410 based on a set of physical sensor data 110 or 222 and / or virtual sensor data 226 generated by a physical base model 120 or 220. In some embodiments, the workflow may include selecting multiple anomaly detection model algorithms (e.g., anomaly detection models within a set of anomaly detection models 420) and applying each selected model algorithm to features 410 (or a subset of features 410) to generate anomaly scores (e.g., anomaly scores 430-1, 430-2, and 430-K) from each model. At each point in time, the anomaly scores 430 generated by the set of anomaly detection models 420 may be combined as a single anomaly score.

[0068] In some embodiments, the workflow may include using the features 410 as features and the ensemble anomaly score 440 as labels to construct a supervised surrogate model 450. The supervised surrogate model 450 and the features 410 may be used to explain each ensemble anomaly score 440 and to derive a set of root causes 480 for the ensemble anomaly score. Each root cause (or contributor, instead) may be identified in some embodiments by a feature or factor name and its weight that contributes to the ensemble anomaly score. In some embodiments, open-source libraries may be used to explain the prediction results of the machine learning model. For example, "ELI5" (https: / / eli5.readthedocs.io / ) and "SHAP" (https: / / shap.readthedocs.io / ) are two open-source libraries that may be used to explain the prediction results of a machine learning model. Such libraries are designed to explain each result each time.

[0069] In some embodiments, a supervised surrogate model may be used to select important features (e.g., via a model-based feature selection module 470). In some embodiments, the model-based feature selection module 470 may use one or more feature selection techniques, such as forward selection, backward selection, or model-based feature selection (based on feature importance techniques). For example, a set of features may be associated with a calculated importance score indicating the magnitude of its contribution to at least one model used in the workflow (e.g., an anomaly detection module 140 which may be associated with the data and model shown in Figure 4. Thus, in some embodiments, the output of the anomaly detection module 140 may include one or more selected features 475 identified by the individual anomaly scores 430 (or ensemble anomaly scores 440), the root cause of the anomaly scores (identified by an explainable AI model 460), and / or the model-based feature selection module 470).

[0070] In some embodiments, sensor data is collected at least to predict short-term failures. Short-term failures may, according to the design, occur over short time periods such as a few hours or a few days. Some examples of short-term failures may include system operation failures and / or minor mechanical or electrical failures. In some embodiments, the anomaly detection module 140 may generate selected key features based on a set of historical sensor data, as well as an ensemble anomaly score, a set of root causes (e.g., contributing factors). Figure 5 is a figure 500 showing a set of operations associated with short-term failure prediction. The set of operations may include a first subset of operations for model building / training (e.g., operations 502, 504, 506, and 508) and a second subset of operations for estimation / prediction based on a model using a trained model on data collected in real time (or near real time) (e.g., operations 510, 512, and 514). In some embodiments, the system may generate in 502 one or more individual anomaly scores (or ensemble anomaly scores), root causes (contributing factors) of the anomaly scores (identified by an explainable AI model), and / or selected features identified by the model-based feature selection module 470.

[0071] In 504, the system may define a set of parameters associated with one or more lookback feature windows and / or lead time windows to derive features for each point in time, based on the anomaly score, root cause, and features. The set of parameters associated with one or more lookback feature windows and / or lead time windows may be defined based on domain knowledge or optimized based on several optimization algorithms such as grid search and random search. The set of parameters for the lookback feature window and lead time window may include the duration of the lookback feature window in time from the present and the separation in time between the present and the potential failure time (i.e., lead time feature window). In some embodiments, such parameters may be based on the expected type of failure and the desired lead time to identify the potential failure in order to give the user sufficient time to deal with the expected failure (e.g., preparing replacement parts, performing maintenance, or otherwise mitigating or avoiding the failure).

[0072] Based on a lookback feature window and / or lead time window and associated parameters, the system may derive features in 506 to construct a short-term failure prediction model. For example, based on a lookback feature window and associated parameters, the system may derive features in 506 to construct a short-term failure prediction model by calculating and / or identifying one or more selected features, ensemble anomaly scores, and their root causes within a defined lookback feature window. The selected features, ensemble anomaly scores, and their root causes within a particular defined lookback feature window may, in some embodiments, be concatenated in chronological order (e.g., time point) and used as features for generating, training, or validating a short-term failure prediction model. In some embodiments, feature derivation may also include aggregation functions based on a selected subset of aggregate statistics. The selected aggregate statistics may, in some aspects, include the minimum value in the time window, the maximum value in the time window, the mean value in the time window, the standard deviation, the value associated with the 1st percentile, the value associated with the 99th percentile, the value associated with the 25th percentile, the value associated with the 50th percentile, the value associated with the 75th percentile, and the trend, and may be selected as described above in relation to Figure 3.

[0073] The lead time window may be further used in 506 to generate ensemble anomaly scores for the association of the lead time window (and lookback window) with associated time points. The generated set of ensemble anomaly scores may be used as a set of target data for subsequent training operations to build / train a short-term failure prediction model. For example, in some embodiments, the system may define a look-ahead lead time window for each time point and use the lead time window and associated ensemble anomaly scores as targets (e.g., ground truth) for building a short-term failure prediction model. In some embodiments, the anomaly scores are continuous values, and using continuous values ​​as prediction targets mitigates problems associated with rare failures in the classification method.

[0074] In 508, the system may construct a short-term fault prediction model by a time series sequence prediction model (or train it using machine learning operations). In some embodiments, a deep learning recurrent neural network (RNN) model (e.g., LSTM, GRU) may be used to construct and / or train the short-term fault prediction model. In some embodiments, other methods such as autoregressive integrated moving average (ARIMA) or other suitable machine learning methods may be used. The construction of the short-term fault prediction model in 508 may represent the completion of the first model construction / training subset of the operation.

[0075] In the operation of the system, the system calculated a predictive fault score of 1 or more based on data collected by physical sensors and, in some embodiments, virtual sensor data, in 510. In some embodiments, the predictive fault score may be converted to a categorical fault risk level in 512. The categorical fault risk levels may include low-risk, intermediate-risk, and high-risk levels, which may be more understandable to a user attempting to determine whether action should be taken based on the predictive fault score. The conversion may be based on a set of thresholds for the predictive fault score associated with different risk levels. For example, when defining three different risk levels, the low-risk level may be associated with risk having a predictive fault score of less than 0.2, the intermediate-risk level may be associated with a predictive fault score of 0.2 to a maximum of 0.6, and the high-risk level may be associated with a predictive fault score of 0.6 or higher. In different embodiments, different numbers of categories may be used, and labels may indicate recommended actions, such as low, intermediate, and risk levels in the previous example, and may be replaced and / or labeled as “Actions should not be taken,” “Monitor operational status,” and “Repair / replace.” Accordingly, in 514, the predicted failure score and / or category risk level may be reported to the user.

[0076] In some embodiments, sensor data is collected at least to predict long-term failures. Long-term failures may occur over long periods of time, such as weeks, months, or even years. Some examples of long-term failures include major mechanical failures and major electrical failures. Checking systems to identify potential long-term failures can help avoid significant losses in terms of both assets and human safety. Figure 600 illustrates a set of operations related to generating a long-term failure prediction score to identify and predict potential long-term failures according to some embodiments of this disclosure.

[0077] In 602, a separate set of anomaly detection operations may be performed for each asset in a set of assets associated with long-term failure prediction of a system or subsystem within a larger system. The set of operations may include anomaly detection operations performed in 602. In some embodiments, the first set of anomaly detection operations 602A may be performed based on sensor data, as described in relation to operation 502 in Figure 5. The output of the anomaly detection operations performed in 602 includes an ensemble anomaly score, the root cause of the ensemble anomaly score, and selected features.

[0078] As described above in relation to Figure 5, for each asset in a set of multiple assets (tens to thousands of assets), one or more selected features, an ensemble anomaly score, and their root causes may be derived within a defined time window. Aggregate statistics similar to those described above in relation to Figure 5 may be generated for each of multiple timescales. Aggregate statistics across multiple timescales may, in some embodiments, be concatenated per asset. The anomaly detection operation performed in 602 may further include obtaining physical design data for each asset in 602B, which may, in some embodiments, but not limited to, predicted asset lifetime, asset material, asset type, asset model, or other relevant physical attributes.

[0079] In 604, the system may perform feature engineering operations, including aggregation operations, across the data within a lookback feature window for each of several assets, in order to derive a set of features and root causes (contributing factors). For example, for each asset and each set of defined time windows, the system may, in 604, calculate one or more of the mean anomaly score, the variance of the anomaly score, or other aggregation statistics, as described above. In some embodiments, the aggregation may reduce the "dimensionality" of the problem being modeled for long-term failure prediction and, by considering components of the system or subsystem, generate a failure prediction score that reflects or takes into account redundancy within the system or subsystem.

[0080] In 606, the anomaly detection operation for an ensemble of multiple models may be determined based on the output of feature engineering. Feature engineering in 604 may generate a second set of system-level (aggregated) features, a set of system-level ensemble anomaly scores, and a set of system-level root causes (contributing factors to the anomaly scores generated by the detection models). Based on the second set of system-level (aggregated) features, the set of system-level ensemble anomaly scores, and the set of system-level root causes, a system-level anomaly detection model (or an ensemble of multiple anomaly detection models) may be applied in 606 to generate a long-term fault prediction score 608. The long-term fault prediction score 608 may include sets of scores associated with different time axes. As described in relation to Figure 5, the long-term prediction score may be categorized to allow for a more intuitive interpretation of the calculated long-term fault prediction score.

[0081] When a short-term failure is predicted by the model, the system may be able to derive the root cause of the failure to help diagnose and repair the short-term failure. Figure 7 is Figure 700, which shows a set of operations for identifying a set of root causes associated with a short-term failure (root cause analysis of predicted short-term failures 701) according to some aspects of the present disclosure. Figure 8 is Figure 800, which shows a set of operations for identifying a set of root causes associated with a long-term failure (for example, root cause analysis of predicted long-term failures 801) according to some aspects of the present disclosure. The operations and elements in Figures 7 and 8 overlap considerably, so the common elements will be described together below. Figure 700 shows that for each predicted failure represented by a predicted failure score 702 associated with a failure prediction model 704 (generated as described in relation to Figure 5), the explainable AI model-failure prediction module 706 may identify a first set of features ("first set of features" 708) based on the failure prediction model 704 and the predicted failure score 702. In some embodiments, the first feature set 708 may be a set of features identified as important features that contribute most to the predicted failure score, such features include the root causes 480 of the anomaly score and selected features 475. Important features may be identified based on relative importance (e.g., a predefined number of features having the greatest impact on or contribution to the predicted failure score) or absolute importance (e.g., based on a threshold associated with a measure of contribution to the predicted failure score 702). Thus, in some embodiments, each feature is associated with a feature importance score indicating the degree to which it contributes to the predicted failure score.

[0082] The explainable AI model-fault prediction module 706 may identify the detected anomaly score 710 (e.g., anomaly score 430 or ensemble anomaly score 440) as a key feature of the respective predicted fault score 702. The detected anomaly score 710 and the supervised surrogate model-detection 712 (e.g., corresponding to supervised surrogate model 450) may be provided to the explainable AI model-fault detection module 714 to derive a second set of key features (i.e., a second feature set 716). For features in the first feature set 708, each feature may be associated with a feature importance score indicating the extent to which it contributes to the detected fault score.

[0083] To identify the set of root causes associated with long-term failure 834, the input to the explainable AI model-failure prediction module 808 differs slightly from the input to the explainable AI model-failure prediction module 706. The operation to identify the set of root causes associated with long-term failure 834 may also include constructing a supervised surrogate model-prediction 806 for the long-term failure prediction model 804 (the supervised surrogate function therein is described above in relation to Figure 4), by featuring the long-term failure prediction model 804 and using the anomaly score from the long-term failure prediction model 804 as a target.

[0084] For each predicted failure, the explainable AI model-failure prediction module 808 may process the supervised surrogate model-prediction 806 and the predicted long-term failure score 802 to identify the key features that contribute most to the predicted long-term failure score 802. Each feature in the first feature set 810 may, in some embodiments, be associated with a feature importance score indicating the extent to which it contributes to the predicted long-term failure score 802. The operation may include identifying the detected anomaly score 812 and the supervised surrogate model-detection 814 associated with the identified first feature set 810, and using the explainable AI model-anomaly detection module 816 to identify a second set of key features (second feature set 818). Each feature in the first feature set 810 and the second feature set 818 may, in some embodiments, be associated with a feature importance score indicating the extent to which it contributes to the detected failure score.

[0085] Subsequent operations involve considerable overlap between short-term and long-term root cause analysis, based on the understanding that the features and sensor characteristics identified using the following operations may differ due to different underlying systems and / or components being analyzed (e.g., components related to small-scale versus large-scale failures).

[0086] The feature aggregation and ranking module 718(820) merges features from a first feature set 708(810) and a second feature set 716(818) into a single set and sorts the features based on their feature importance scores. In some embodiments, merging removes redundant features such that features appearing in both the first feature set 708(810) and the second feature set 716(818) are represented only once in the merged list. For example, the feature importance score in the second feature set 716(818) may be calculated by multiplying the feature importance score from the explainable AI model-fault prediction module 706(808) by the feature importance score from the explainable AI model-anomaly detection module 714(816). In some embodiments, if there are overlapping features in the first feature set 708(810) and the second feature set 716(818), the system may merge the overlapping features by using aggregated feature importance scores having aggregate statistics, which may include, but are not limited to, the sum of feature importance scores, the maximum feature importance score, and the average feature importance score. The feature aggregation and ranking module 718(820) may sort the features in the merged list based on the feature importance scores in descending order.

[0087] For each feature in the result set described above, the system may map the feature to one or more physical or virtual sensors via a module for mapping features to sensors 720(822). For features that map directly to physical sensors, a first set of physical sensors (first physical sensor set 722(824)) may be identified. For features that map to a set of virtual sensors 724(826), further mapping may be performed by a module for mapping virtual sensors to physical sensors 726(828) to identify a second set of physical sensors associated with the feature (second physical sensor set 728(830)). The sensor aggregation and ranking module 730(832) may then perform merging and ranking operations on the first physical sensor set 722(824) and the second physical sensor set 728(830), where each physical sensor is associated with an importance score based on the corresponding feature. Similar to feature aggregation and ranking, aggregating identified sets of physical sensors may involve merging the importance scores of physical sensors corresponding to multiple features, for example, based on the sum of sensor importance scores, the maximum sensor importance score, and the average sensor importance score of 1 or more.

[0088] The physical sensors in the aggregated list may also be ranked by the sensor aggregation and ranking module 730(832). The ranked list may include sets of physical sensors and corresponding weights indicating the magnitude of their contribution to the ensemble anomaly score, sorted in descending order. The list may then be provided as sets of root causes for the predicted failures 732(834). In some embodiments, a first feature set 708(810), a second feature set 716(818), and a set of virtual sensors 724(826) may also be output to provide the user with insights for further operation.

[0089] While the above description relates to sensor data of non-operating components of the system, the method may, in some embodiments, be extended to use data about the operator to improve fault prediction if such data is available. In some embodiments, the operator may include a human, a robot, or a motion profile. In some embodiments, the operator's role is important in the operation of the machine or system, and their performance directly affects the system's performance, which may be measured as production yield, fault rate, or user experience, and thus better predictive accuracy can be provided when the operator's role is considered. Specifically, in the case of fault rate, when data about the operator is collected, these can be used as further features for constructing anomaly detection models, fault prediction models, and long-term fault prediction models. In some embodiments, the operator's data may include, but are not limited to, one or more of the following: operation trajectories (e.g., position, velocity, and acceleration), years of experience of the operator, performance metrics of the operator, or demographic attributes of the operator.

[0090] Figure 9 is a flowchart illustrating method 900 for a system that performs fault prediction operations in an industrial process. The method may be performed by a set of one or more computing units and associated processing units associated with an industrial system, which includes a set of components and a set of sensors for monitoring the components of the system. In 910, the system may collect (or acquire) a set of physical sensor data. In some embodiments, the set of physical sensor data may include a set of high-frequency data sampled by a sampling operation. The set of physical sensor data may include sensor data from one or more of the following: temperature sensors, pressure sensors, vibration sensors, acoustic sensors, motion sensors, optical sensors, LIDAR sensors, IR sensors, acceleration sensors, gas sensors, smoke sensors, humidity sensors, level sensors, image sensors (cameras), proximity sensors, water quality sensors, and / or chemical sensors. For example, referring to Figure 1, sensor data 110 may be acquired from a set of physical sensors that monitor the state or characteristics of the components of the system.

[0091] In 920, the system may generate sets of virtual sensor data by applying a physical-based model to a subset of sets of physical sensor data. In some embodiments, the virtual sensor is a type of software-derived information from available information that represents or is associated with data that a corresponding physical device would collect. For example, referring to Figures 1 and 2A, a physical-based model 120 or 220 (including physical-based model 224) may acquire physical sensor data 110 or 222 and generate sets of virtual sensor data 226 based on the physical-based model (e.g., physical-based model 224). In some embodiments, the physical-based model 224 may be a representation of laws of nature that essentially incorporate the concepts of time, space, causality, and generalizability. These laws of nature, in some embodiments, define how physical, chemical, biological, and geological processes unfold. In some embodiments, the physical-based model 224 may be a function that acquires multiple inputs (e.g., physical sensor data 222) and generates multiple outputs (e.g., virtual sensor data 226). Inputs may come from predefined profiles (such as motion profiles) during design or from physical sensors (e.g., physical sensor data 222) during operation. Outputs (e.g., virtual sensor data 226) may, in some embodiments, include multiple variables and represent a set of virtual sensors.

[0092] In 930, the system may identify a first set of features from a set of physical sensor data and a set of virtual sensor data by performing at least one sampling, aggregation, or feature derivation operation on the set of physical sensor data and the set of virtual sensor data, based on an optimized sampling rate or optimized aggregation statistics. In some embodiments, the set of physical sensor data may include a set of high-frequency data, and the optimized sampling rate may be associated with the sampling operation to reduce the amount of data. For example, referring to Figures 2B and 4, the feature engineering module 230 may generate a set of features 238 or 410 using one or more sampling and aggregation modules 234 and / or feature derivation modules 236 applied to the sensor data 232. As described in relation to Figure 3, the optimized sampling rate and / or optimized aggregation statistics may be based on one or more optimization algorithms. For example, at least one of the optimized sampling rate or optimized aggregation statistics may be calculated using one or more Bayesian optimization, grid search, or random search in some embodiments. As described above, in some embodiments, the first optimized sampling rate or optimized aggregate statistic is calculated based on domain knowledge, and the second optimized sampling rate or optimized aggregate statistic is calculated based on one or more of Bayesian optimization, grid search, or random search. In some embodiments, optimizing the first and second optimized sampling rates or optimized aggregate statistics involves cycling between or iterating over these optimizations based on the results of previous optimizations, as described in relation to Figure 3. In some embodiments, the optimized sampling and aggregation operations may be implemented by a first set of machine-trained models, such as being trained by the method described above in relation to Figure 3.

[0093] In 940, the system may identify a set of anomaly detection scores, a first set of contributors to the set of anomaly detection scores, and a second set of features having feature importance scores greater than or equal to a threshold, based on a machine-trained model (e.g., a trained sampling and aggregation model that may correspond to an anomaly detection model) applied to a first set of features. In some embodiments, the first set of machine-trained models may include a set of anomaly detection modules that generate sets of anomaly detection scores in some embodiments. In some embodiments, the set of anomaly detection models may be trained based on a set of physical sensor data collected in 910 and a set of virtual sensor data generated in 920. For example, referring to Figure 4, the system may identify (1) a set of anomaly detection scores 430 (e.g., anomaly scores 430-1, 430-2, and 430-K or collectively the ensemble anomaly score 440) as a first set of contributing factors 480 to the anomaly scores (e.g., a first set of contributing factors to the set of anomaly detection scores), and (3) selected features 475 (e.g., a second set of features having feature importance scores above a threshold) based on a set of anomaly detection models 420 applied to features 410, an ensemble anomaly score 440, a supervised surrogate model 450, an explainable AI model 460, and a model-based feature selection 470.

[0094] In 950, the system may generate at least one failure prediction model based on a first set of features and a first set of machine-trained models. In some embodiments, the at least one failure prediction model may include at least one short-term failure prediction model based on (1) a set of anomaly detection scores, (2) sampling and / or aggregation operations, or (3) machine learning operations applied to the first set of identified features. In some embodiments, the machine learning operations used to build and / or train the short-term failure predictions may include one or more deep learning RNN models (e.g., LSTM, GRU), ARIMA, or other suitable machine learning models. In some embodiments, the at least one short-term failure prediction model may include short-term failure prediction models generated for each individual asset in a set of assets related to the system. For example, referring to Figure 5, the system may generate (e.g., build / train) a short-term fault prediction mode at 508 based on (1) an operation 502 based on a set of anomaly detection models, (2) an operation 504 based on a set of parameter optimization operations, and (3) an operation 506 based on a set of feature derivation and transformation operations.

[0095] In some embodiments, at least one failure prediction model may include at least one long-term failure prediction model. Generating at least one long-term failure prediction model may, in some embodiments, be further based on a second set of machine training models. The second set of machine training models may, in some embodiments, be based on a first set of machine training models. For example, referring to Figure 6, the system may generate at least one long-term failure prediction model based on a further set of anomaly detection models (e.g., a second set of machine training models) applied in 606 to a set of data generated based on a first set of machine training models, which is applied in 602 to each of a plurality of assets.

[0096] In 960, the system may apply at least one failure prediction model to a set of physical sensor data and a set of virtual sensor data in order to calculate a likelihood score for the predicted failure of an asset. Further operations that may be performed are indicated by the letter "A".

[0097] Figure 10 is a flowchart illustrating a method 1000 for identifying a set of root causes (e.g., contributing factors) for failure prediction, relating to some aspects of the present disclosure. As indicated by the letter "A", the method in Figure 10 may be performed after operations described in relation to the method shown in Figure 9. In some aspects, the method 1000 is performed by a root cause analysis module (e.g., root cause analysis for the short-term failure module 160 or root cause analysis for the long-term failure module 180 in Figure 1). In 1010, the root cause analysis module may, in some aspects, identify a set of contributing features for at least one failure prediction model by applying a first explanatory model for at least one failure prediction model to a set of predicted failure scores and a second explanatory model for a first set of machine training models. In some aspects, the term contributing features may refer to abstract features identified by a model in the system, while the term contributing factors may relate to physical components of the system identified as contributing to the failure prediction model. For example, referring to Figures 7 and 8, the explainable AI model-fault prediction module 706 (or 808) may obtain a set of predicted short-term (or long-term) fault scores 702 (or 802) in order to identify a first set of features 708 (810) associated with detected anomaly scores 710 (812). The explainable AI model-fault detection module 714 (816) may also be used to identify a second set of features 716 (818). The first set of features 708 (810) and the second set of features 716 (818) together may constitute a set of contributors for at least one fault prediction model.

[0098] In 1020, the root cause analysis module may, in some embodiments, calculate a second importance score for each contributing feature within a set of contributing features. The calculated second importance score reflects, in some embodiments, a contribution to one or more fault prediction scores or anomaly scores. For example, referring to Figures 7 and 8, the explainable AI model-fault prediction module 706 (or 808) and the explainable AI model-anomaly detection module 714 (816) may calculate or output weights associated with each contributing feature. The root cause analysis module (e.g., root cause analysis of predicted short-term faults 701 or root cause analysis of predicted long-term faults 801) may generate a list of associated features with corresponding weights, and the feature aggregation and ranking module 718 (or 820) may generate a ranked list of features and aggregated weights (e.g., features contributing to multiple anomaly scores and / or predictions).

[0099] In 1030, the root cause analysis module may, in some embodiments, map each contributing feature within a set of contributing features to one or more contributing physical sensors. The mapping may include mapping features to physical sensors and mapping features to virtual sensors. In addition, the mapping of each contributing feature within a set of contributing features to one or more contributing physical sensors may also include mapping virtual sensors to one or more physical sensors. For example, referring to Figures 7 and 8, a module that maps features to sensor 720 (822) may map contributing factors within a first set of factors to the set of physical sensors 722 (824) and 728 (830) via an intermediate mapping to a set of virtual sensors 724 (826) which is subsequently mapped to a set of physical sensors 728 (830).

[0100] In 1040, the root cause analysis module may, in some embodiments, calculate a third importance score for each of one or more contributing physical sensors based on a second importance score of at least one contributing feature within a set of contributing features mapped to the physical sensor among the one or more contributing physical sensors. In some embodiments, the calculation of the third importance score may be based on aggregating weights associated with the same physical sensor based on different features or mappings. For example, referring to Figures 7 and 8, the sensor aggregation and ranking module 730(832) may perform a merge operation on a first set of physical sensors 722(824) and a second set of physical sensors 728(830), where each physical sensor is associated with an importance score based on one or more corresponding features. Similar to feature aggregation and ranking, aggregating a set of identified physical sensors may involve merging the importance scores of physical sensors corresponding to multiple features based, for example, on the sum of sensor importance scores, the maximum sensor importance score, and one or more of the average sensor importance scores.

[0101] Finally, in 1050, the root cause analysis module may, in some embodiments, identify a subset of contributing physical sensors from one or more contributing physical sensors as a second set of contributing factors for at least one fault prediction model, based on a third importance score. For example, referring to Figures 7 and 8, the sensor aggregation and ranking module 730(832) may perform a ranking operation on a merged list of contributing factors based on a first set of physical sensors 722(824) and a second set of physical sensors 728(830). The physical sensors in the aggregated list may be ranked by the sensor aggregation and ranking module 730(832). The ranked list may include sets of physical sensors and corresponding weights indicating the magnitude of their contribution to the ensemble anomaly score, sorted in descending order.

[0102] As presented in this disclosure, the system may provide one or more of the following benefits: For example, the above disclosure introduces an automated, unsupervised, data-driven solution for fault / failure control in industrial systems for one or more short-term faults (in hours or days) or long-term faults (in weeks, months or years). The above disclosure provides a solution that can predict faults and identify their root causes with some lead time, allowing operators / technicians sufficient time to respond and to have further root cause information to facilitate fault diagnosis. The above disclosure reduces or eliminates the need for (manual) labeled data. In some embodiments, the disclosure relates to performing the above operations on historical sensor data, while historical fault data may be optional in some embodiments. The disclosure also introduces a semi-empirical approach through a combination of physical-based and machine learning models, and optimization strategies for sampling rates and aggregate statistics for high-frequency sensor data.

[0103] In some embodiments, the proposed anomaly prediction method works well for predicting rare, prior failure events with advanced deep learning sequence prediction power and continuous values. This disclosure also relates to the root causes of failures predicted through a chain of explainable AI techniques and aggregation / ranking algorithms at several levels (detected anomaly score level, feature level, and raw sensor data level).

[0104] Figure 11 shows an exemplary computing environment having exemplary computer equipment suitable for use in several exemplary implementations. The computer equipment 1105 within the computing environment 1100 may include one or more processing units, cores, or processors 1110, memory 1115 (e.g., RAM, ROM, and / or similar), internal storage 1120 (e.g., magnetic, optical, solid-state storage, and / or organic) and / or an I / O interface 1125, any of which may be connected on a communication mechanism or bus 1130 for transmitting information, or may be incorporated within the computer equipment 1105. The I / O interface 1125 may also be configured to receive images from a camera or provide images to a projector or display, depending on the desired implementation.

[0105] The computer device 1105 may be communicatively connected to the input / user interface 1135 and the output device / interface 1140. One or both of the input / user interface 1135 and the output device / interface 1140 may be wired or wireless interfaces and may be detachable. The input / user interface 1135 may include any physical or virtual device, component, sensor, or interface that can be used to provide input (e.g., buttons, touchscreen interfaces, keyboards, pointing / cursor controls, microphones, cameras, Brailles, motion sensors, accelerometers, optical readers, and / or similar). The output device / interface 1140 may include displays, televisions, monitors, printers, speakers, Brailles, or similar. In some exemplary implementations, the input / user interface 1135 and the output device / interface 1140 may be integrated with or physically connected to the computer device 1105. In other exemplary implementations, other computer devices may function as or provide input / user interfaces 1135 and output devices / interfaces 1140 for computer device 1105.

[0106] Examples of computer devices 1105 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles or other machines, devices carried by humans and animals, and similar devices), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and similar devices), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions, radios, and similar devices having one or more processors built in and / or connected thereto).

[0107] Computer device 1105 may be communicably connected (for example, via I / O interface 1125) to external storage 1145 and network 1150 for communication with any number of network-connected components, devices, and systems, including one or more computer devices of the same or different configurations. Computer device 1105 or any connected computer device may function as, provide, or be referred to as a server, client, thin server, general-purpose machine, special-purpose machine, or other labeled function.

[0108] The IO interface 1125 may include, but is not limited to, wired and / or wireless interfaces that use any communication or IO protocol or standard (e.g., Ethernet, 902.11x, Universal Serial Bus, WiMAX, modem, cellular network protocol, and similar) to communicate information to and from at least all connected components, devices, and networks within the computing environment 1100. The network 1150 may be any network or combination of networks (e.g., the Internet, local area network, wide area network, telephone network, cellular network, satellite network, and similar).

[0109] The computer device 1105 may use and / or communicate using computer-usable or computer-readable media, including temporary and non-temporary media. Temporary media include transmission media (e.g., metal cables, optical fibers), signals, carrier waves, and similar entities. Non-temporary media include magnetic media (e.g., disks and tapes), optical media (e.g., CD-ROMs, digital video discs, Blu-ray discs), solid-state media (e.g., RAM, ROMs, flash memory, solid-state storage), and other non-volatile storage or memory.

[0110] The computer device 1105 may be used to implement techniques, methods, applications, processes, or computer executable instructions in several exemplary computing environments. Computer executable instructions may be obtained from temporary media and stored on and retrieved from non-temporary media. Executable instructions may originate from one or more arbitrary programming, scripting, and machine languages ​​(e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).

[0111] The processor 1110 may run under any operating system (OS) (not shown) in a native or virtual environment. One or more applications may be deployed with the OS and other applications (not shown), including a logic unit 1160, an application programming interface (API) unit 1165, an input unit 1170, an output unit 1175, and an inter-unit communication mechanism 1196 for different units to communicate with each other. The units and elements described may be modified in design, function, configuration, or implementation, and are not limited to the description provided. The processor 1110 may be in the form of a hardware processor, such as a central processing unit (CPU), or a combination of hardware and software units.

[0112] In some exemplary implementations, information or execution instructions, upon being received by the API unit 1165, may be transmitted to one or more other units (e.g., logic unit 1160, input unit 1170, output unit 1175). In some cases, the logic unit 1160 may be configured to control the flow of information between units and to control the services provided by the API unit 116, input unit 1170, and output unit 1175 in some exemplary implementations described above. For example, the flow of one or more processes or implementations may be controlled by the logic unit 1160 alone or in conjunction with the API unit 1165. The input unit 1170 may be configured to take input for a computation described in the exemplary implementation, and the output unit 1175 may be configured to provide output based on the computation described in the exemplary implementation.

[0113] The processor 1110 may be configured to collect sets of physical sensor data. The processor 1110 may also be configured to generate sets of virtual sensor data by applying a physical-based model to a subset of the sets of physical sensor data. The processor 1110 may be further configured to identify a first set of features from the sets of physical sensor data and virtual sensor data by performing at least one sampling, aggregation, or feature derivation operation on the sets of physical sensor data and virtual sensor data based on an optimized sampling rate or optimized aggregation statistics. The processor 1110 may be further configured to identify a set of anomaly detection scores, a first set of contributors to the sets of anomaly detection scores, and a first set of features having feature importance scores greater than or equal to a threshold, using a first set of machine-trained models applied to the first set of features. The processor 1110 may be further configured to generate at least one fault prediction model based on the first set of machine-trained models. The processor 1110 may also be configured to apply at least one failure prediction model to sets of physical sensor data and sets of virtual sensor data in order to calculate likelihood scores for predicted failures of an asset. The processor 1110 may also be configured to identify sets of contributors to at least one failure prediction model by applying a first explanatory model for at least one failure prediction model to sets of predicted failure scores and a second explanatory model for a first set of machine training models. The processor 1110 may also be configured to calculate a second importance score for each contributing feature in the set of contributing features. The processor 1110 may also be configured to map each contributing feature in the set of contributing features to one or more contributing physical sensors. For each of the one or more contributing physical sensors, the processor 1110 may also be configured to calculate a third importance score based on the second importance score of at least one contributing feature in the set of contributing features mapped to that physical sensor among the one or more contributing physical sensors.The processor 1110 may also be configured to identify a subset of contributing physical sensors from among one or more contributing physical sensors as a second set of contributing factors for at least one fault prediction model, based on a third importance score.

[0114] Some parts of the detailed explanation have been presented concerning algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are means used by those skilled in data processing technology to convey the essence of the innovation to others skilled in the art. An algorithm is a set of predefined steps that produce a desired end state or result. In one implementation example, the steps performed require the physical manipulation of tangible quantities to achieve a specific result.

[0115] Unless otherwise specified, explanations that use terms such as “processing,” “computing,” “calculating,” “determining,” and “displaying” throughout the explanation, as is evident from the explanation, should be understood to include actions and processes of a computer system or other information processing device that manipulate data represented as physical (electronic) quantities in the registers and memory of a computer system and convert it into other data similarly represented as physical quantities in the memory or registers of a computer system, or in other information storage, transmission, or display devices.

[0116] Implementation examples may also relate to apparatus for performing the operations described herein. Such apparatus may be specifically constructed for a required purpose and may include one or more general-purpose computers that are selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in computer-readable media such as computer-readable storage media or computer-readable signal media. Computer-readable storage media may include, but are not limited to, tangible media such as optical disks, magnetic disks, read-only memory, random-access memory, solid-state devices and drives, or any other type of tangible or non-temporary media suitable for storing electronic information. Computer-readable signal media may include media such as carrier waves. The algorithms and representations presented herein are not specific to any particular computer or other apparatus. Computer programs may include pure software implementations containing instructions for performing the operations in a desired implementation form.

[0117] Various general-purpose systems may be used with the programs and modules illustrated herein, or it may be convenient to construct more specialized devices for performing desired method steps. Furthermore, the implementation examples do not describe any particular programming language. It will be understood that various programming languages ​​may be used to implement the teachings of the implementation examples described herein. Instructions in a programming language may be executed by one or more processing units, such as a central processing unit (CPU), processor, or controller.

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

[0119] Furthermore, other implementations of the Application will become apparent to those skilled in the art by examining this Specification and practicing the Techniques of the Application. Various aspects and / or components of the implementations described herein may be used individually or in any combination. This Specification and the implementations are intended to be considered merely as examples, and the true scope and spirit of the Application are indicated by the appended claims.

Claims

1. A method performed by at least one processor, The aforementioned at least one processor collects a set of physical sensor data, The at least one processor generates a set of virtual sensor data by applying a physical-based model to a subset of the set of physical sensor data, The at least one processor identifies a first set of features from the set of physical sensor data and the set of virtual sensor data by performing at least one sampling operation, aggregation operation, or feature derivation operation on the set of physical sensor data and the set of virtual sensor data based on an optimized sampling rate or optimized aggregation statistics. The at least one processor uses a first set of machine-trained models applied to the first set of features to identify a set of anomaly detection scores, a first set of contributing factors to the set of anomaly detection scores, and a second set of features having feature importance scores that are above a threshold. The at least one processor generates at least one fault prediction model based on the first set of machine training models, The at least one processor applies the at least one failure prediction model to the set of physical sensor data and the set of virtual sensor data in order to calculate a likelihood score for the predicted failure of the asset. A method that includes this.

2. The method according to claim 1, further comprising the at least one processor identifying a second set of contributors to the at least one failure prediction model by applying a first explanatory model for the at least one failure prediction model to a set of predicted failure scores generated by the at least one failure prediction model.

3. The second set of contributing factors includes a set of contributing physical sensors, and the at least one processor identifies the second set of contributing factors. Identifying a set of contributing features of the at least one failure prediction model by applying the first explanatory model for the at least one failure prediction model to the set of predicted failure scores and applying the second explanatory model for the first set of machine-trained models, To calculate a second importance score for each contributing feature within the aforementioned set of contributing features, Mapping each contributing feature within the set of contributing features to one or more sensors within the set of contributing physical sensors, For each physical sensor in the set of contributing physical sensors, a third importance score is calculated based on the second importance score of at least one contributing feature in the set of contributing features mapped to the physical sensor in the set of contributing physical sensors. The method according to claim 2, including the method described in claim 2.

4. The method according to claim 1, wherein the set of physical sensor data includes a set of high-frequency data sampled by the sampling operation.

5. The method according to claim 1, wherein the first set of machine training models includes a set of anomaly detection models.

6. The method according to claim 5, wherein the set of anomaly detection models is trained based on the set of physical sensor data and the set of virtual sensor data.

7. The method according to claim 1, wherein the at least one failure prediction model includes at least one short-term failure prediction model based on machine learning operations applied to a set of anomaly detection scores, a first set of contributing factors to the set of anomaly detection scores, and a second set of features generated by the first set of machine training models.

8. The method according to claim 7, wherein the at least one short-term failure prediction model includes a short-term failure prediction model generated for each individual asset.

9. The method according to claim 1, wherein the at least one failure prediction model includes at least one long-term failure prediction model, and generating the at least one long-term failure prediction model is further based on a second set of machine training models, the second set of machine training models is based on a first set of machine training models.

10. The method according to claim 1, wherein at least one of the optimized sampling rate or the optimized aggregate statistics is calculated using one or more of Bayesian optimization, grid search, or random search.

11. The method according to claim 1, wherein the first optimized sampling rate or optimized aggregate statistic is calculated based on domain knowledge, and the second optimized sampling rate or optimized aggregate statistic is calculated based on one or more of Bayesian optimization, grid search, or random search.

12. Memory and When the program stored in the aforementioned memory is executed, Collecting sets of physical sensor data, By applying a physics-based model to a subset of the aforementioned set of physical sensor data, a set of virtual sensor data is generated. Based on an optimized sampling rate or optimized aggregation statistics, a first set of features is identified from the set of physical sensor data and the set of virtual sensor data by performing at least one sampling operation, aggregation operation, or feature derivation operation on the set of physical sensor data and the set of virtual sensor data. Using a first set of machine-trained models applied to the first set of features, identify a set of anomaly detection scores, a first set of contributing factors to the set of anomaly detection scores, and a second set of features having feature importance scores above a threshold. Based on the first set of machine training models, generate at least one failure prediction model, To calculate the likelihood score for predicted failures of an asset, the at least one failure prediction model is applied to the set of physical sensor data and the set of virtual sensor data. A set of processors coupled to the memory, configured to perform the following: A device that includes this.

13. The aforementioned at least one processor is Identifying a set of contributing features of the at least one failure prediction model by applying a first explanatory model for the at least one failure prediction model to a set of predicted failure scores and a second explanatory model for the first set of machine training models, To calculate a second importance score for each contributing feature within the aforementioned set of contributing features, Mapping each contributing feature within the set of contributing features to one or more contributing physical sensors, For each of the one or more contributing physical sensors, a third importance score is calculated based on the second importance score of at least one contributing feature within the set of contributing features mapped to the physical sensor among the one or more contributing physical sensors. Based on the third importance score, a subset of contributing physical sensors from the one or more contributing physical sensors is identified as a second set of contributing factors for the at least one fault prediction model. The apparatus according to claim 12, further configured to perform the following:

14. The apparatus according to claim 12, wherein the set of physical sensor data includes a set of high-frequency data sampled by the sampling operation.

15. The apparatus according to claim 12, wherein the first set of machine training models includes a set of anomaly detection models.

16. The apparatus according to claim 15, wherein the set of anomaly detection models is trained based on the set of physical sensor data and the set of virtual sensor data.

17. The apparatus according to claim 12, wherein the at least one failure prediction model includes at least one short-term failure prediction model based on machine learning operations applied to a set of anomaly detection scores, a first set of contributing factors to the set of anomaly detection scores, and a second set of features generated by the first set of machine training models.

18. The apparatus according to claim 17, wherein the at least one short-term failure prediction model includes a short-term failure prediction model generated for each individual asset.

19. The apparatus according to claim 12, wherein the at least one failure prediction model includes at least one long-term failure prediction model, and generating the at least one long-term failure prediction model is further based on a second set of machine training models, the second set of machine training models is based on a first set of machine training models.

20. The apparatus according to claim 12, wherein at least one of the optimized sampling rate or the optimized aggregate statistic is calculated using one or more of Bayesian optimization, grid search, or random search, the first of the optimized sampling rate or the optimized aggregate statistic is calculated based on domain knowledge, and the second of the optimized sampling rate or the optimized aggregate statistic is calculated based on one or more of Bayesian optimization, grid search, or random search.

Images