System and method for predicting manufacturing process risks

Abstract

The present disclosure provides systems, methods, and computer program products for predicting and detecting anomalies in a subsystem of a system. An example method can include (a) determining a first plurality of tags indicative of operational performance of the subsystem. The tags can be obtained from (i) a plurality of sensors in the subsystem and (ii) a plurality of sensors in the system not located in the subsystem. The method can further include (b) processing measured values of the first plurality of tags using an autoencoder trained on historical values of the first plurality of tags to generate estimated values of the first plurality of tags; (c) determining whether a difference between the measured values and the estimated values satisfies a threshold; and (d) transmitting an alert indicating that the subsystem is predicted to experience an anomaly if the difference satisfies the threshold.

Description

[0001] CROSS-REFERENCE

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 899,081, filed September 11, 2019, which is incorporated by reference herein in its entirety. BACKGROUND

[0003] Manufacturers can rely on a framework of periodic and reactive maintenance to manage their operating assets. This can result in lost revenue from delayed production, excess costs associated with unplanned maintenance actions, shortened asset life, poor product quality, and personnel safety risks associated with increased exposure on site. SUMMARY

[0004] The present disclosure provides systems, methods, and computer program products for predicting and detecting anomalies in a system or subsystem of a processing pipeline to improve the reliability of the processing pipeline. For example, the processing pipeline can be a petroleum and natural gas processing pipeline that includes drilling assets, refining assets, and pipeline assets (e.g., pumps, compressors, heat exchangers, and valves). The system for predicting and detecting anomalies as described herein can be implemented on one or more computers at one or more locations. The computers can store instructions that, when executed, cause the computers to predict anomalies in a subsystem of the system.

[0005] The system can determine a first plurality of tags indicative of operational performance of the subsystem. The first plurality of tags can include time series data from sensors in the subsystem. The first plurality of tags can additionally include time series data from sensors in the system that are not located in the subsystem but are still indicative of operational performance of the subsystem. For example, the first plurality of tags can be from another subsystem that provides input to the subsystem, receives output from the subsystem, or is otherwise associated with the subsystem. The system can use one or more machine learning methods to identify the first plurality of tags. For example, the system can use a clustering algorithm to identify the first plurality of tags from among all tags in the system. Determining the first plurality of tags can be considered a feature selection operation.

[0006] The system can process the measurements of the first plurality of tags using an autoencoder. The autoencoder can have an encoder configured to generate a reduced dimension or compressed output from the measurements. The autoencoder can additionally have a decoder configured to generate estimated values of the first plurality of tags from the reduced dimension or compressed output. The autoencoder can be trained on historical values of the first plurality of tags.

[0007] The system can determine whether there is a difference between the measured values of the first plurality of labels provided to the autoencoder and the estimated values of the first plurality of labels generated by the autoencoder. If the measured values are the same or similar to the estimated values, the system can determine that the subsystem is not experiencing an anomaly. On the other hand, if the system determines that the difference between the measured values and the estimated values satisfies a threshold, the system can determine that the subsystem is experiencing an anomaly. The system can transmit an alert indicating that the system is experiencing such an anomaly.

[0008] While many manufacturing entities rely on periodic or reactive maintenance to manage operational assets, the system described above can accurately predict failures and detect anomalies in a processing pipeline before the anomaly occurs by using data from hundreds to thousands of sensors and identifying correlations in that data. Because steps in a process can be highly interdependent, the correlations identified by the system described herein can be used to identify anomalies. Moreover, the system can use machine learning models that can be retrained according to new failure events to improve prediction and detection accuracy over time. Finally, the system can predict failures and detect anomalies at an asset, system, or subsystem level, which can enable users to perform predictive maintenance on a processing pipeline quickly to maintain safety, extend asset life, produce higher quality products, and avoid costly downtime.

[0009] The present disclosure can additionally provide applications and user interfaces that enable users (e.g., operations managers or engineers) to interact with and view the outputs of the system described above. The applications and user interfaces can additionally enable users to monitor, control, and perform predictive maintenance on assets in a processing pipeline.

[0010] These applications and user interfaces can provide an end-to-end solution for prioritizing, investigating, and responding to predicted or detected anomalies in a processing pipeline.

[0011] In an aspect, the present disclosure provides a method for predicting an anomaly in a subsystem of a system. The method can include determining a first plurality of labels indicative of operational performance of the subsystem. Each label of the first plurality of labels can include a sequence of data, and the first plurality of labels can be obtained from (i) a plurality of sensors in the subsystem and (ii) a plurality of sensors in the system that are not located in the subsystem. The method can also include processing measured values of the first plurality of labels using an autoencoder by (1) generating a compressed representation of the measured values and (2) decoding the compressed representation of the measured values into estimated values of the first plurality of labels, where the autoencoder has been trained according to historical values of the first plurality of labels. The method can further include determining whether a difference between the measured values and the estimated values satisfies a threshold, and transmitting an alert indicating that the subsystem is predicted to experience an anomaly if the difference satisfies the threshold.

[0012] In some implementations, (a) includes processing data from sensors in the system using an unsupervised learning algorithm to generate a plurality of label groups, the plurality of label groups including a first plurality of labels indicative of operational performance of the subsystem. In some implementations, each label in the first plurality of labels is associated with at least one other label in the first plurality of labels or with the operational performance of the subsystem. In some implementations, the unsupervised learning algorithm is a clustering algorithm. The clustering algorithm can be a K-means clustering algorithm, a cosine similarity algorithm, a topological data analysis algorithm, or a hierarchical density-based spatial clustering of applications with noise (HDB-SCAN).

[0013] In some implementations, (a) is performed offline.

[0014] In some implementations, the method further includes, prior to (c), applying a weight to each of the measured values and the estimated values.

[0015] In some implementations, the method further includes dynamically adjusting the threshold value during operation of the system.

[0016] In some implementations, the method further includes determining whether a difference between the measured values of the respective labels and the estimated values of the respective labels satisfies a label threshold value, and transmitting an alert if the difference satisfies the label threshold value.

[0017] In some implementations, the autoencoder is a deep neural network or a one-class support vector machine (SVM).

[0018] In some implementations, the historical data includes a sequence of data collected over a period of time in which no faults occurred in the subsystem.

[0019] In some implementations, the system includes a plurality of subsystems.

[0020] In some implementations, the measured values of the first plurality of labels include a sequence of data collected during a predetermined backtracking period. In some implementations, the method further includes dynamically adjusting the backtracking period.

[0021] In some implementations, the method further includes generating a risk score for the subsystem based on a magnitude of a difference between the measured values of the first plurality of labels and the estimated values of the first plurality of labels.

[0022] In some implementations, the alert includes an email or a text message. In some implementations, the alert can include a notification in a mobile or web application. In some implementations, the mobile or web application is configured to enable a user to perform one or more corrective actions on the subsystem.

[0023] In some implementations, the method further includes determining actions to correct the anomaly in the subsystem using a trained machine learning algorithm. The trained machine learning algorithm can have been trained from historical human actions and corresponding responses of the subsystem. In some implementations, the method further includes determining actions to correct the anomaly in the subsystem using an engineering principles-based rules-based logic to correlate observed patterns in the tag measurements with known failure mechanisms of processes and equipment in the subsystem.

[0024] In some implementations, the alert includes a numerical risk score indicating a likelihood of the anomaly occurring. The numerical risk score can be based at least in part on a magnitude of the difference between the measured values of the first plurality of tags and the estimated values of the first plurality of tags. In some implementations, the alert includes a numerical risk score indicating a likelihood of the anomaly occurring. The numerical risk score can be based at least in part on a degree to which the difference exceeds a threshold. In some implementations, the alert includes a list of tags in the first plurality of tags that contribute most to the alert.

[0025] Another aspect of the disclosure provides a non-transitory computer-readable medium comprising machine executable code that, when executed by one or more computer processors, implements any of the methods above or elsewhere herein.

[0026] Another aspect of the disclosure provides a system comprising one or more computer processors and computer memory coupled with the same. The computer memory comprises machine executable code that, when executed by the one or more computer processors, implements any of the methods above or elsewhere herein.

[0027] Other aspects and advantages of the disclosure will become readily apparent to those skilled in the art and the technical field upon review of the following detailed description, the appended claims and the drawings. As will be realized, the disclosure is capable of other different obvious aspects and can be practiced with other similar embodiments without departing from the disclosure. Accordingly, the drawings and descriptions should be regarded as illustrative in nature and not restrictive.

[0028] INCORPORATION BY REFERENCE

[0029] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. To the extent there is a contradiction between the disclosure herein and that of any such incorporated publication, patent or patent application, the present specification shall control. BRIEF DESCRIPTION OF DRAWINGS

[0030] The novel features of the application are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present application will be obtained by reference to the following detailed description that sets forth illustrative

[0031] FIG. 1 schematically illustrates a system for predicting and detecting anomalies;

[0032] FIG. 2 is a flowchart of an example process for predicting subsystem anomalies, generating anomaly alerts, generating cases to track anomaly investigations, and issuing work orders to resolve any faults identified during investigations;

[0033] FIG. 3 is a flowchart of an example process for predicting anomalies in a subsystem of a system;

[0034] FIG. 4 to FIG. 18 shows a user interface of an application that can enable a user to investigate alerts and generate and manage cases and work orders associated with such alerts;

[0035] FIG. 19 schematically illustrates a model that can be used to represent FIG. 4 to FIG. 18 the processing pipelines in the applications depicted in

[0036] FIG. 20 shows a computer system programmed or otherwise configured to implement the methods provided herein. DETAILED DESCRIPTION

[0037] While various embodiments of the application have been shown and described herein, it will be appreciated that such embodiments are merely illustrative of the many possible variations, modifications and alternatives. It should be understood that various alternative implementations of the embodiments described herein can be employed.

[0038] As used herein, the term "asset" generally refers to a single piece of equipment (e.g., a valve) in a processing pipeline.

[0039] As used herein, the term "system" generally refers to a collection of subsystems that perform chemical reactions or physical operations on materials in a manufacturing process. The relationships between systems can be linear.

[0040] As used herein, the term "subsystem" generally refers to a collection of assets or a collection of smaller subsystems that perform chemical reactions or physical operations on materials in a process. The relationships between subsystems can be linear or hierarchical.

[0041] As used herein, the term "platform" generally refers to a large offshore structure used to explore, produce, and process oil and gas from beneath the seabed.

[0042] As used herein, the term "plant" generally refers to a facility in which industrial manufacturing processes are performed.

[0043] As used herein, the term "tag" generally refers to a single data sequence associated with a measurement (e.g., pressure, temperature, or flow rate) of an asset.

[0044] As used herein, the term "cluster" generally refers to a group of related tags associated with a single subsystem.

[0045] Whenever the term "at least," "greater than," or "greater than or equal to" precedes the first numerical value in a series of two or more numerical values, the term "at least," "greater than," or "greater than or equal to" applies to each of the numerical values in that series of numerical values. For example, greater than or equal to 1, 2, or 3 is equivalent to greater than or equal to 1, greater than or equal to 2, or greater than or equal to 3.

[0046] Whenever the term "not greater than," "less than," or "less than or equal to" precedes the first numerical value in a series of two or more numerical values, the term "not greater than," "less than," or "less than or equal to" applies to each of the numerical values in that series of numerical values. For example, less than or equal to 3, 2, or 1 is equivalent to less than or equal to 3, less than or equal to 2, or less than or equal to 1.

[0047] The present disclosure provides systems, methods, and computer program products for predicting and detecting anomalies in a system or subsystem of a processing pipeline to improve the reliability of the processing pipeline. An example system as described herein can determine a first plurality of tags indicative of operational performance of a subsystem. The first plurality of tags can be time series data from sensors in the subsystem and sensors not in the subsystem but still indicative of operational performance of the subsystem. For example, the system can determine that the first plurality of tags is indicative of operational performance of the subsystem by using a clustering algorithm. Determining the tags can be considered a feature selection operation.

[0048] The system can process the measurements of the first plurality of tags using an autoencoder. The autoencoder can have an encoder configured to generate a reduced dimension or compressed output from the measurements and a decoder configured to generate estimated values of the first plurality of tags. The autoencoder can be trained from historical values of the first plurality of tags.

[0049] The system can determine whether there is a difference between the measured values of the first plurality of tags provided to the autoencoder and the estimated values of the first plurality of tags generated by the autoencoder. If the measured values and the estimated values are the same or similar, the system can determine that the subsystem is not experiencing an anomaly. On the other hand, if the system determines that the difference between the measured values and the estimated values satisfies a threshold, the system can determine that the subsystem is experiencing an anomaly. The system can transmit an alert to one or more computing devices having an application (e.g., a web application, a mobile application, or a dedicated software program) indicating that the system is experiencing such an anomaly. The application can enable a user (e.g., an engineer or an operations manager) to monitor and investigate the alert, generate a case to track action items on the alert, and generate a work order to resolve the fault behind the alert.

[0050] FIG. 1 A system for predicting and detecting anomalies is schematically illustrated. The system can have a process pipeline 100. The process pipeline 100 can be located in a manufacturing facility, e.g., a factory. Alternatively, the process pipeline 100 can be distributed among assets at different locations connected by a pipeline. The process pipeline 100 can be configured to produce one or more products from one or more raw materials. The process pipeline 100 can implement batch processing, semi-batch processing, or continuous processing. Batch processing can be a process that produces a quantified product. Continuous processing can be a process that produces a non-quantified product while continuously consuming raw materials.

[0051] The process pipeline 100 can be a petroleum and natural gas process pipeline. Alternatively, the process pipeline 100 can be a chemical or material synthesis pipeline (e.g., a pipeline for synthesizing paint, fertilizer, textiles, rubber, steel, or aluminum), a pharmaceutical synthesis pipeline, or a food or beverage production pipeline.

[0052] The process pipeline 100 can have a system 111. The system 111 can have a subsystem 112 and a subsystem 116. Each subsystem can have assets, e.g., individual components or equipment pieces (not shown), and sensors. An example of a system in a petroleum and natural gas process pipeline is a crude distillation unit. The crude distillation unit can include cokers, hydrocrackers, catalytic converters, hydroprocessors, reformers, and desulfurizers subsystems, and each subsystem can have assets. Although the process pipeline 100 is depicted as having only a single system, the process pipeline 100 can have multiple systems, each system having multiple subsystems.

[0053] The sensors in the processing pipeline 100 can be sensors that generate time series data. The sensors can be thermometers, barometers, flow meters, accelerometers, magnetometers, etc. In addition to such time series data, the sensors can generate metadata, e.g., data about the location of the sensor within the system 111 or the subsystems 112 and 166. The sensors are capable of collecting data at a rate of at least about 0.1 Hz, 0.2 Hz, 0.3 Hz, 0.4 Hz, 0.5 Hz, 1 Hz, 5 Hz, 10 Hz, 100 Hz, 1000 Hz, 10000 Hz, 100000 Hz, or higher. The sensors in the processing pipeline 100 can transmit the time series data (referred to in this disclosure as “labels”) to one or more computing devices that implement anomaly prediction and detection. Although the processing pipeline 100 is depicted as having only six sensors, it can have as many as tens of thousands of sensors.

[0054] FIG. 1 The system of FIG. 1 can have a training subsystem 120. The training subsystem 120 can be configured for training machine learning models to predict and detect anomalies.

[0055] The training subsystem 120 can have a clustering module 122. The clustering module 122 can be configured for training and executing clustering algorithms to determine groups of labels from the sensors 113-115 and 117-119 that are indicative of the operational performance of the subsystems in the processing pipeline 100. Each group of labels can be associated with the operational performance of a particular subsystem.

[0056] The clustering algorithm can be a hierarchical clustering algorithm. A hierarchical clustering algorithm is a clustering algorithm that clusters objects based on their proximity to other objects. For example, a hierarchical clustering algorithm can cluster a tag from the processing pipeline 100 based on its physical proximity to other sensors and to related subsystems. Alternatively, the clustering algorithm can be a centroid-based clustering algorithm, such as a K-means clustering algorithm. A K-means clustering algorithm can partition n observations into k clusters, where each observation belongs to the cluster with the nearest mean. The mean can serve as a prototype for the cluster. In the context of tags from the processing pipeline 100, a K-means clustering algorithm can generate different groups of tags that are related to each other. Thereafter, each group of tags can be associated with a particular subsystem based on prior knowledge about the subsystem, such as knowledge about sensors in the subsystem. Alternatively, the clustering algorithm can be a distribution-based clustering algorithm, such as a Gaussian mixture model or an expectation-maximization algorithm. Examples of other clustering algorithms that the clustering module 122 can implement are a cosine similarity algorithm, a topological data analysis algorithm, and a hierarchical density-based clustering of applications with noise (HDB-SCAN).

[0057] The training subsystem 120 can additionally have an autoencoder training module 124. The autoencoder training module 124 can be used to train the autoencoder 132. The autoencoder training module 124 can train the autoencoder 132 according to historical values of tags that are indicative of the operational performance of the selected subsystem. The historical tags can be tags collected during normal operation of the subsystem, such as during a time period in which no faults occurred in the subsystem. Training the autoencoder 132 according to normal tags can result in the autoencoder 132 having parameters that represent “normal” features. While FIG. 1 Only a single autoencoder is depicted, but each subsystem in the system can have its own autoencoder that can be trained according to historical values of tags that are indicative of the operational performance of that particular subsystem.

[0058] The autoencoder 132 can have an encoder 133 that encodes the measured values of the first plurality of tags that are determined to be indicative of the operational performance of a particular subsystem in the processing pipeline 100. The autoencoder 132 can also have a decoder 134 that attempts to reconstruct the measured values. Given measured values that represent training data, the autoencoder 132 can generate estimated values that are similar or equivalent to the measured values. However, given anomalous measured values, the autoencoder 132 can produce poor reconstructions.

[0059] The autoencoder 132 can be a neural network. Generally, a neural network can employ multiple layers of operations to predict one or more outputs from one or more inputs. The neural network can include one or more hidden layers between an input layer and an output layer. The output of each layer can be used as input to another layer, e.g., a next hidden layer or the output layer. Each layer of the neural network can specify one or more transformation operations to be performed on the input to that layer. Such a transformation operation can be referred to as a neuron. The output of a particular neuron can be a weighted sum of the inputs to that neuron, adjusted with a bias and multiplied by an activation function, e.g., a rectified linear unit (ReLU) or sigmoid function. Training a neural network can involve providing an untrained neural network with inputs to generate predicted outputs, comparing the predicted outputs to expected outputs, and updating the weights and biases of the algorithm to take into account the difference between the predicted outputs and the expected outputs. In particular, a cost function can be used to compute the difference between the predicted outputs and the expected outputs. By computing the derivative of the cost function with respect to the weights and biases of the network, the weights and biases can be iteratively adjusted over multiple cycles to minimize the cost function. Training can be complete when the predicted outputs satisfy a convergence condition, e.g., achieve a small amount of computational cost.

[0060] The neural network can be trained using a supervised or unsupervised learning process. In supervised learning, the training inputs to the neural network are labeled. That is, the training inputs have known outputs. In contrast, in unsupervised learning, the training inputs are unlabeled. The autoencoder training module 124 can implement an unsupervised learning process to train the autoencoder 132; the inputs to the autoencoder 132 need not be labeled because the expected output of the autoencoder 132 is simply the input.

[0061] The autoencoder 132 can be a feedforward neural network, i.e., a neural network with only forward connections between neurons. Alternatively, the autoencoder 132 can be a recurrent neural network (“RNN”). An RNN can have recurrent connections that can encode dependencies in time series data. An RNN can include an input layer configured to receive a series of time series inputs, e.g., time series labels from sensors in the processing pipeline 100. The RNN can also include one or more hidden recurrent layers that maintain a state. At each time step, each hidden recurrent layer can compute an output of the layer and a next state. The next state can depend on the previous state and the current input. The state can be maintained across time steps and can capture dependencies in the series of inputs. Such an RNN can be used to encode time series features of the processing pipeline 100.

[0062] One example of an RNN is a long short-term memory network (LSTM), which can be composed of LSTM cells. An LSTM cell can be composed of a cell, an input gate, an output gate, and a forget gate. The cell can be responsible for keeping track of dependencies between elements in an input series. The input gate can control the extent to which new values flow into the cell, the forget gate can control the extent to which values remain in the cell, and the output gate can control the extent to which values in the cell are used to compute an output activation of the LSTM cell. The activation function of the LSTM gates can be a logistic function.

[0063] The inference subsystem 130 can implement the autoencoder 132 after it is trained. If the difference between the measured values of the first plurality of tags provided to the autoencoder 132 and the estimated values of the first plurality of tags generated by the autoencoder 132 exceeds a threshold, there can be an anomaly in the subsystem associated with the first plurality of tags. In such a case, the system can transmit an alert to the application 140, which will be described in more detail below.

[0064] The inference subsystem 130 can implement other types of machine learning models. For example, the inference subsystem 130 can implement machine learning models configured to: (i) optimize a threshold for predicting or detecting anomalies; (ii) predict a failure mode associated with an anomaly; or (iii) determine a corrective action. The machine learning models can be trained using supervised, semi-supervised, unsupervised, or reinforcement learning processes. Examples of such machine learning models are regression algorithms, decision trees, support vector machines, Bayesian networks, neural networks (e.g., feed-forward neural networks, CNNs, RNNs, etc.), clustering algorithms, reinforcement learning algorithms, etc.

[0065] As described above, FIG. 1 The system of FIG. 1 can additionally include an application 140. The application 140 can be a mobile application or a web application. The application 140 can be used on any type of computing device, e.g., on a desktop or laptop computer, an electronic tablet, a mobile device, etc. Users (e.g., engineers and operations managers) can use the application 140 to view alerts and predicted failure modes generated by the inference subsystem 130, generate cases to track investigations of anomalies, and create work orders to resolve any failures behind the alerts. The application 140 will be described in more detail with reference to the subsequent figures.

[0066] FIG. 1The systems and components thereof can be implemented on one or more computing devices. The computing devices can be servers, desktop or laptop computers, electronic tablet computers, mobile devices, etc. The computing devices can be located in one or more locations. The computing devices can have general purpose processors, graphics processing units (GPUs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc. The computing devices can additionally have memory, e.g., dynamic or static random access memory, read only memory, flash memory, hard drives, etc. The memory can be configured to store instructions that, when executed, cause the computing devices to implement the functions of the training subsystem 120, the inference subsystem 130, or the application 140. The computing devices can additionally have network communication devices. The network communication devices can enable the computing devices to communicate with each other over a network and with any number of user devices, e.g., user devices running the application 140. For example, the inference engine 130 can transmit alerts, predicted failure modes, etc. to user devices running the application 140. The network can be a wired or wireless network. For example, the network can be a fiber optic network, an Ethernet network , a satellite network, a cellular network, , a Bluetooth network, etc. In other implementations, the computing devices can be several distributed computing devices accessible over the Internet. Such computing devices can be considered cloud computing devices.

[0067] FIG. 2 is a flowchart of an example process for predicting a subsystem anomaly, generating an anomaly alert, generating a case to track an investigation of the anomaly, and issuing a work order to resolve any faults identified during the investigation. The process can be performed by a system of one or more computers in one or more locations and one or more users using an application, e.g., the application 140. FIG. 1

[0068] First, the system can predict or detect an anomaly in a subsystem (210). The prediction can be a qualitative prediction, a quantitative prediction, or both. The qualitative prediction can be a prediction that an anomaly will occur within a specified time period. The quantitative prediction can be a numerical risk score that indicates a likelihood that an anomaly will occur within a specified time period. The prediction can additionally include one or more predicted failure modes associated with the anomaly. The operation 210 will be described in more detail. FIG. 3

[0069] ​​Next, the system can transmit an alert to the application on any number of user devices indicating that a subsystem is experiencing or will experience an anomaly (220). The alert can identify the affected system and subsystem, and include a qualitative or quantitative prediction, a predicted failure mode, and tags that contributed to the predicted or detected anomaly. The alert can serve as a basis for further investigation by the user using the application.

[0070] Finally, using the application, the user can analyze the alert and create and manage cases and work orders to investigate and resolve the anomaly (230).

[0071] In one example, the user can assign the alert to an authorized reviewer. The reviewer can be an engineer or operations manager. The reviewer can provide feedback regarding the predicted failure mode. The feedback can be a text comment. Alternatively or additionally, the reviewer can reject or accept the predicted failure mode, or select one or more new failure modes from a drop-down menu. If the user does not provide feedback regarding the predicted failure mode, the application can assume that the predicted failure mode is correct. When the reviewer provides feedback, the system can automatically create a case that subsequently tracks all actions taken against the alert.

[0072] The case can be distinct from the alert. The purpose of the case can be to track activities, coordinate across users, and enable collaboration. The case can have a one-to-one or one-to-many relationship with the alert. That is, in some cases, multiple related alerts can be resolved through one case. The case can enable collaboration by tagging other users and by comments and uploaded files that are available for editing or viewing by all users associated with the case. The application can enable the user to take the following actions on the case: (1) assign the case and the underlying alert to a reviewer; (2) add a comment to the case; (3) tag another user; (4) provide feedback regarding the predicted failure mode; (5) create an associated work order; (5) close or reopen the case.

[0073] After providing feedback regarding the predicted failure mode, the reviewer can investigate the alert using an alert analysis tool in the application, which will be described in greater detail with reference to the subsequent figures. Briefly, the reviewer can examine specific tags to identify the root cause of the alert, e.g., a defective component. The reviewer can record a comment regarding its findings, which can become part of the case history. Based on the results of its investigation, the reviewer can create a work order. When the work order is complete, the application can automatically close the alert and the case.

[0074] The data collected during operation 230 can be used to train a machine learning algorithm to predict appropriate corrective actions for detected anomalies. For example, a particular predicted anomaly, the label that caused the predicted anomaly, and the corresponding failure mode selected by the user can serve as labeled data for training a supervised machine learning algorithm. As more and more training data is collected and incorporated into the algorithm over time, the performance of the algorithm can improve.

[0075] FIG. 3 is a flowchart of an example process for predicting anomalies in a subsystem of a system. FIG. 3 The process of can be performed by a system of one or more computers in one or more locations. For example, FIG. 1 The training subsystem 120 and the inference subsystem 130 of can perform FIG. 3 The process of.

[0076] In a first operation, the system can determine a first plurality of labels indicative of operational performance of a subsystem (310). The labels in the first plurality of labels can be time series data from (i) sensors in the subsystem and (ii) sensors in the system that are not located in the subsystem but still indicative of operational performance of the subsystem. For example, the labels can be from another subsystem that provides input to the subsystem, receives output from the subsystem, or is otherwise associated with the subsystem.

[0077] The system can determine the labels indicative of operational performance of the subsystem using one or more machine learning algorithms. For example, the system can process all of the labels in the system using a clustering algorithm (e.g., a K-means clustering algorithm) to generate different groups of labels, including the first plurality of labels. The labels in each different group can be correlated with each other or associated with selecting operational performance of the subsystem. Operation 310 can be considered a feature selection operation. Operation 310 can be performed offline, i.e., before implementing the system in a processing pipeline.

[0078] In a second operation, the system can process measurements of the first plurality of labels (i.e., the labels determined to be indicative of operational performance of the subsystem) using an autoencoder (320). The measurements can be limited to a predetermined backtracking period. The predetermined backtracking period can be at least about 1 second, 2 seconds, 3 seconds, 4 seconds, 5 seconds, 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, 30 minutes, 1 hour, 5 hours, 10 hours, 15 hours, 20 hours, 1 day, 5 days, 10 days, or longer. The system can dynamically adjust the backtracking period to optimize the accuracy of anomaly prediction. If the backtracking period is too long, the measurements can contain irrelevant data. If the backtracking period is too short, the measurements can lack important contextual information. The system can use any of the machine learning methods described in this disclosure to optimize the backtracking period.

[0079] The autoencoder can have an encoder configured to generate a reduced dimension or compressed output of the measurements of the first plurality of tags. The autoencoder can additionally have a decoder configured to generate estimated values of the first plurality of tags from the reduced dimension or compressed output. The autoencoder can be a deep neural network, e.g., a feedforward neural network, a convolutional neural network, a recurrent neural network, etc. The autoencoder can be trained according to historical values of the first plurality of tags. In some cases, the historical values can be collected during normal operation of the subsystem, e.g., during a period of time in which the subsystem is not experiencing an anomaly. Training the autoencoder according to normal historical values can cause the autoencoder to have parameters that are representative of “normal” characteristics. Given measurements that are representative of the historical values used for training, the autoencoder can generate estimated values that are similar or equivalent to the measurements. However, given abnormal measurements, the autoencoder can produce poor estimates.

[0080] In a third operation, the system can determine whether a difference between the measurements of the first plurality of tags and the estimated values of the first plurality of tags satisfies a threshold (330). If the system determines that the difference does not satisfy the threshold, it can be an indication that the operational performance of the subsystem is normal, e.g., that the subsystem is not experiencing an anomaly, that the subsystem is operating within normal parameters, or that the subsystem is producing quality products. On the other hand, if the system determines that the difference does satisfy the threshold, it can be an indication that the subsystem is experiencing an anomaly.

[0081] In some cases, the system can apply weights to the measurements and estimated values of the tags before determining whether the difference satisfies the threshold. The system can do so because some tags can have a higher correlation to the operational performance of the subsystem than other tags. The system can apply greater weights to such tags than to tags that have a lower correlation to the operational performance of the subsystem.

[0082] The system can dynamically adjust the threshold as new data becomes available and new anomalies occur during operation of the system. For example, if the system predicts or detects one or more anomalies that are classified as false positives by a user, the system can lower the threshold. On the other hand, if the system fails to predict or detect an anomaly, the system can raise the threshold. The system can use any of the machine learning methods described herein to optimize the threshold.

[0083] In a fourth operation, if the difference satisfies the threshold, the system can transmit an alert indicating that the system is experiencing an anomaly (340). The alert can additionally include a numerical risk score. The numerical risk score can indicate a severity of the predicted anomaly. The numerical risk score can be based at least in part on (i) a magnitude of the difference between the measured values of the first plurality of tags and the estimated values of the first plurality of tags; or (ii) a degree to which the difference exceeds the threshold. The alert can additionally include a list of tags that contributed to the alert, a degree of contribution of each tag, and values of the tags in the backtracking window. The alert can additionally include a predicted failure mode associated with the alert. For example, the system can use a machine learning classifier or any other machine learning method described herein to predict such failure modes.

[0084] The alert can be an email or a text message. Alternatively or additionally, the alert can be a notification in a mobile or web application (e.g., the application 140) of the system. The alert can specify a quantitative risk score associated with the alert, a risk threshold, systems and subsystems associated with the alert, and a date and time at which the alert was generated. As will be described in greater detail in subsequent figures, the application can be configured to enable a user to investigate the alert. FIG. 1

[0085] In some cases, in addition to determining whether the difference between the measured values of the first plurality of tags and the estimated values of the first plurality of tags satisfies the threshold overall, the system can determine whether the difference between individual measured values and estimated values satisfies individual thresholds for corresponding tags, and if so, transmit an alert indicating such. This can alert the user to irregular data points that can not have raised an anomaly.

[0086] User Interface

[0087] FIG. 4 to FIG. 18 A user interface of an application that can enable a user to investigate alerts, as well as generate and manage cases and work orders associated with such alerts is shown.

[0088] FIG. 4 A home screen of the application is shown. The home screen can display key performance indicators (“KPIs”) related to the process pipeline being monitored. The KPIs can include a total number of open (e.g., unresolved) alerts, unplanned subsystem events, maintenance spend relative to a maintenance budget, and plant uptime over a selected time period. The home screen can display the total number of open alerts, unplanned subsystem events, and plant uptime as a function of time in a chart.

[0089] ​The home screen can additionally display a grid showing the highest priority alerts in the processing pipeline. Each row in the grid can correspond to a different alert. FIG. 1 The inference subsystem 130 can generate alerts and transmit the alerts to the application by performing FIG. 3 the processes of

[0090] The home screen can additionally display a stacked bar chart showing the systems in the processing pipeline that are causing the most alerts. The alerts in each bar can be color coded to show the number of bars in each qualitative risk category (e.g., low, medium, or high). The stacked bar chart can be configured to show the systems in the processing pipeline that are causing the most alerts over the last day, week, month, three months, six months, year, or longer.

[0091] The home screen can additionally display a grid showing the highest priority cases in the processing pipeline. Each row in the grid can correspond to a different case. The application or a user can generate a case in response to an alert. The columns in the grid can show the name of each case, the originating subsystem, the priority, the status (e.g., under review, assigned, etc.), the assignee (e.g., the person assigned to resolve the case), the date of creation, and the date of last activity. The user can assign a priority to the case. Alternatively, the application can automatically assign a priority to the case based on a number of factors. For example, the application can consider the importance of the underlying subsystem to the processing pipeline, the severity of the anomaly, and the estimated cost and time to resolve the anomaly.

[0092] The above grids can be sorted according to any column in alphabetical or numerical order.

[0093] The home screen can additionally have a navigation bar that can allow the user to navigate to an alerts screen, a cases screen, a systems screen, an analytics screen, and a settings screen.

[0094] FIG. 5 An alerts screen is shown. The user can open the alerts screen by selecting the alerts icon in the navigation bar. The alerts screen can enable the user to search and filter alerts in the processing pipeline. The user can view their own alerts (e.g., alerts assigned to the user, alerts the user is collaborating on, or alerts in which the user is mentioned) or all alerts in the processing pipeline.

[0095] The alerts screen can have an overview window. The overview window can display the total number of alerts for the user or in the process pipeline. The overview window can additionally display the number of high, medium, and low risk alerts.

[0096] The alerts screen can have a search bar. The search bar can enable the user to search for alerts by keyword. The alerts screen can also have a filter window. The filter window can enable the user to filter alerts returned as keyword search results. The user can filter alerts by status (e.g., open, case created, or closed), trigger date, source system or subsystem, or qualitative risk category of the alert.

[0097] The alerts screen can display a grid of alerts that meet the search and filter criteria. Each row in the grid can correspond to a different alert. Columns in the grid can show the name of each alert, the source subsystem, the qualitative risk score (e.g., low, medium, or high), the numerical risk score, the date and time of generation, and the status (e.g., case created, open, etc.).

[0098] FIG. 6 An alerts details screen is shown. The alerts details screen can display more detailed information about a particular alert. The alerts details screen can have an overview window that displays the name of the alert, its source subsystem, its qualitative risk score, its current and over time quantitative risk scores, the date it was triggered, and its status (e.g., new). The overview window can additionally have a button configured to generate a case or work order when selected by the user.

[0099] The alerts details screen can display a grid of tags that contributed to the alert. Each row in the grid can correspond to a different tag. Columns in the grid can show the name of each tag (e.g., temperature, pressure, vibration, etc.), the degree to which each tag contributed to the alert, and the value of each tag when the alert was generated. The user can expand each tag to reveal the data quality alerts and threshold alerts associated with the tag. The data quality alerts can indicate that data from the sensor associated with the tag is missing or damaged. The threshold alerts can indicate that the value of data from the sensor associated with the tag exceeded a threshold.

[0100] The alerts details screen can additionally display the most common failure modes associated with the alert to help the user resolve the alert.

[0101] FIG. 7A case screen is shown. The case screen can enable a user to search and filter cases in the processing pipeline. Cases can be distinct from alerts in that cases can support collaboration and traceability of investigations, while alerts can simply be a method of notification. Moreover, in some cases, there can not be a one-to-one correspondence between alerts and cases. For example, one case can be used to resolve many related alerts.

[0102] The case screen can be similar in form to the alert screen. The case screen can enable a user to search and filter cases in the processing pipeline. The user can view their own cases (e.g., cases assigned to the user, cases in which the user is collaborating, or cases in which the user is mentioned) or all cases in the processing pipeline.

[0103] The case screen can have a search bar. The search bar can enable a user to search for cases by keyword. The case screen can also have a filter window. The filter window can enable a user to filter cases returned as a result of a keyword search. The user can filter cases by status (e.g., unassigned, assigned, review, closed), date of creation, source system or subsystem, or assignee.

[0104] The case screen can display a grid of cases that satisfy the search and filter criteria. Each row in the grid can correspond to a different case. Columns in the grid can show the name of each case, the source subsystem, the status, the assignee, and the date and content of the last activity on the case (e.g., the case was assigned, a comment was added, an attachment was uploaded, the priority was changed, etc.).

[0105] FIG. 8 A case detail screen is shown. The case detail screen can provide a user with a collaboration and investigation workspace to work on a particular case.

[0106] The case detail screen can display an overview window. The overview window can show the name of the case, the systems and subsystems associated with the case, the date of the last activity on the case, the priority of the case (e.g., manually defined by a user when the case was opened), the status of the case (e.g., alert opened, case created, work order created, work order completed, case closed), and the collaborators on the case (e.g., the case owner and other users mentioned in the case or commenting on the case). The overview window can also have action buttons configured to enable a user to create a work order for the case, close the case, or edit the priority of the case.

[0107] The case detail screen can additionally display a grid of actions associated with the case. Each row in the grid can correspond to a different action. Each row can show the collaborator who took the action, an action summary, a list of attachments (e.g., a labeled schematic, a photo of the subsystem associated with the case, etc.), and the time the action was taken.

[0108] The case details screen can additionally display an alarm summary window. The alarm summary window can show the top three tags contributing to the alarm, the systems or subsystems potentially at risk due to the alarm, the alarm's generation date, the alarm's quantitative risk score, and a list of suggested failure modes typically associated with this type of alarm. The list of suggested failure modes can be configured to allow users to accept or reject suggested failure modes, provide feedback on suggested failure modes, or add new failure modes from the drop-down list.

[0109] FIG. 9 The Subsystem Analysis tab of the Subsystem Details screen is shown. The Subsystem Details screen provides users with the ability to focus on individual subsystems within a production line or facility. It can display quantitative risk scores, historical alerts, cases, and associated work orders for the subsystem over time.

[0110] The Subsystem Analysis tab displays a grid of labels that contribute to the quantitative risk score of the subsystem. Each row in the grid corresponds to a different label. Columns in the grid show the minimum, maximum, and average contribution of each label to the quantitative risk score over a selected time period, as well as the most recent measurement of the label.

[0111] The Subsystem Analysis tab can additionally display a chart showing the contribution of the top three labels to the subsystem's quantitative risk score over time. A filter window adjacent to the chart allows users to select which labels are displayed in the chart. For example, users can specify which labels to display and the time period for which they are displayed.

[0112] FIG. 10 The Cases tab of the subsystem details screen is shown. Although not depicted, the subsystem details screen may additionally have Alarms and Work Orders tabs. These tabs allow users to search, filter, and display cases, alarms, and work orders for specific subsystems. These tabs can be similar to the previous screen, except that cases, alarms, and work orders are limited to specific subsystems.

[0113] FIG. 11 The Clustering tab of the subsystem details screen is displayed. The Clustering tab can display data that has been processed by the system, for example, through a reference... FIG. 3 The unsupervised clustering method described is labeled with a tag associated with the quantitative risk score of the subsystem.

[0114] FIG. 12 The Subsystem Diagram tab is displayed on the Subsystem Details screen. The Subsystem Diagram tab can display a diagram of the subsystem. This diagram can be static, such as an image; or it can be dynamic, such as an interactive model with traversable links.

[0115] FIG. 13 A system screen for the application is shown. The system screen can provide a user of the application with an integrated view of all systems in the processing pipeline. The system screen can include a grid that displays each system in a separate row. Columns in the grid can show a quantitative risk score for each system, a number of active alerts for each system, a number of open cases for each system, and a location of the system.

[0116] A summary window in the system screen can additionally show a number of systems or subsystems with alerts.

[0117] FIG. 14 A subsystems tab of the system details screen is shown. The subsystems tab can show more detailed information about the subsystems in the system, including (i) a quantitative risk score, a number of active alerts, a number of open cases, and a last activity (e.g., alert creation, case opening, alert resolution, case resolution, work order creation, etc.) for each subsystem.

[0118] FIG. 15 A subsystem alerts tab of the system details screen is shown. The subsystem alerts tab can show more detailed information about alerts in the various subsystems of the system.

[0119] FIG. 16 A subsystem cases tab of the system details screen is shown. The subsystem cases tab can show more detailed information about cases associated with the various subsystems of the system.

[0120] FIG. 17 A work orders tab of the system details screen is shown. The work orders tab can show more detailed information about work orders associated with the various subsystems of the system.

[0121] FIG. 18 A data analysis screen for the application is shown. The data analysis screen can provide a user with the ability to plot any metric or time within the application instance, e.g., tag, subsystem quantitative risk score, system quantitative risk score, etc.

[0122] FIG. 19A model that can be used to represent a processing pipeline in an application is schematically illustrated. The model can be an abstract representation of various materials, assets, processes, data, etc. The model can be arranged in a hierarchical manner. For example, multiple process step models can be arranged in series or in parallel to represent a manufacturing process. As another example, asset models can be combined together to represent a subsystem, and subsystem models can be combined together to represent a system. Material and data models can represent inputs and outputs, respectively, of a process step or manufacturing process model. The model can be defined by fields and functions. Values of the fields and functions can specify particular materials, assets, processes, and data that the model represents.

[0123] Computer System

[0124] The present disclosure provides a computer system programmed to implement the methods of the present disclosure. FIG. 20 A computer system 2001 is shown that is programmed or otherwise configured to implement the system of FIG. 1 The computer system 2001 can be an electronic device of a user or a computer system located remotely with respect to the electronic device. The electronic device can be a mobile electronic device.

[0125] The computer system 2001 includes a central processing unit (CPU, also "processor" and "computer processor" herein) 2005, which can be a single core or multiple core processor, and which can be a multithreaded processor. The computer system 2001 also includes memory or memory location 2010 (e.g., random-access memory, read-only memory, flash memory), electronic storage unit 2015 (e.g., hard disk), communication interface 2020 (e.g., network adapter) for communicating with one or more other systems, and peripheral devices 2025, such as cache, other memory, data storage, and / or electronic display adapters. The memory 2010, storage unit 2015, interface 2020, and peripheral devices 2025 are in communication with the CPU 2005 through a communication bus (solid lines), such as a motherboard. The storage unit 2015 can be a data storage unit (or data repository) for storing data. The computer system 2001 can be operatively coupled to a computer network ("network") 2030 with the aid of the communication interface 2020. The network 2030 can be the Internet, an internet and / or an extranet, or an intranet and / or extranet that in turn can include links to and from a

[0126] The CPU 2005 can execute a sequence of machine-readable instructions, which can be embodied in a program or software. The instructions can be stored in a memory location, such as the memory 2010. The instructions can be directed to the CPU 2005, which can subsequently program or otherwise configure the CPU 2005 to implement methods of the present disclosure. Examples of operations performed by the CPU 2005 can include fetch, decode, execute, and writeback.

[0127] The CPU 2005 can be part of a circuit, such as an integrated circuit. One or more other components of the system 2001 can be included in the circuit. In some cases, the circuit is an application specific integrated circuit (ASIC).

[0128] The storage unit 2015 can store files, such as drivers, libraries and saved programs. The storage unit 2015 can store user data, e.g., user preferences and user programs. The computer system 2001 in some cases can include one or more additional data storage units that are external to the computer system 2001, such as located on a remote server that is in communication with the computer system 2001 through an in- house or Internet network.

[0129] The computer system 2001 can communicate with one or more remote computer systems through the network 2030. For instance, the computer system 2001 can communicate with a remote computer system to access application 140. Examples of remote computer systems include personal computers running applications, servers hosting web pages, mobile phones or other handheld devices running software applications, and the like. FIG. 1 The user can access the computer system 2001 via the network 2030.

[0130] Methods as described herein can be implemented by way of machine (e.g., computer processor) executable code stored on an electronic storage location of the computer system 2001, such as, for example, on the memory 2010 or electronic storage unit 2015. The machine executable or machine readable code can be provided in the form of software. During use, the code can be executed by the processor 2005. In some cases, the code can be retrieved from the storage unit 2015 and stored on the memory 2010 for ready access by the processor 2005. In some cases, electronic storage unit 2015 can be precluded, and machine-executable instructions are stored on memory 2010.

[0131] ​​​​The code can be pre-compiled and configured for use with a machine having a processor adapted to execute the code, or can be compiled during runtime. The code can be provided in a programming language that can be selected to enable the code to be executed in a pre-compiled or compiled fashion.

[0132] Aspects of the systems and methods provided herein, such as computer system 2001, can be embodied in programming. Various aspects of the technology can be thought of as “products” or “articles of manufacture” typically in the form of machine (or processor) executable code and / or associated data that is carried on or embodied in a type of machine readable medium. Machine-executable code can be stored on an electronic storage unit, such as memory (e.g., read-only memory, random-access memory, flash memory) or a hard disk. “Storage” type media can include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape, magnetic

[0133] Hence, a computer readable medium, such as a computer executable code, can take many forms, including but not limited to, a tangible storage medium, a carrier wave medium or physical transmission medium. Non-volatile storage media include, for example, optical or magnetic disks, such as any of the storage devices in any computer(s) etc., such as can be used to implement databases, etc. shown in the drawings. Volatile storage media include dynamic memory, such as the main memory of such a computer platform. Tangible transmission media include coaxial cables; copper wire and fiber optic cables including the wires that comprise bus(es) within computer systems. Carrier-wave transmission media can take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media therefore include, for example: floppy diskettes, flexible disks, hard disks, magnetic tapes, any other magnetic medium, CD-ROM, DVD or DVD-ROM, any other optical medium, punch cards, any other physical storage medium with patterns of holes, RAM, ROM, PROM and EPROM, FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, cables or links transporting such carrier waves, or any other medium from which a computer can read programming code and / or data. Many of these forms of computer readable media can be involved in carrying one or more sequences of one or more instructions to a processor for execution.

[0134] The computer system 2001 can include or be in communication with an electronic display 2035, which can comprise a user interface (UI) 2040 for providing, for example, a reference FIG. 4 to FIG. 18 to the described applications. Examples of UIs include, without limitation, a graphical user interface (GUI) and web-based user interface.

[0135] The methods and systems of this disclosure can be implemented by one or more algorithms. The algorithms can be implemented in software when executed by the central processing unit 2005. The algorithm may, for example, be an algorithm that implements a process for predicting anomalies in a subsystem of a system. FIG. 3

[0136] ​While preferred embodiments of the application have been shown and described herein, it will be understood by those skilled in the art that such embodiments have been presented by way of example only. The present application is not intended to be limited to the specific examples presented herein. Although the application has been described with reference to the preceding description, the description and drawings of the embodiments herein are not meant to limit the application in any way. Many changes, modifications, variations, and alternatives can now be thought of by those skilled in the art without departing from the application. Further, it is intended that all such alternatives, modifications, variations, and equivalents be included herein. It will be appreciated that various alternatives to the embodiments of the application described herein can be employed in practicing the application. It is intended that the application encompass any and all such alternatives, modifications, and variations. It is intended that the scope of the application be limited only by the claims appended hereto.

Claims

1. A method for predicting an anomaly in a subsystem of a system, comprising: (a) determining a first plurality of tags indicative of an operational performance of the subsystem, wherein each tag of the first plurality of tags comprises a sequence of data, and wherein the first plurality of tags is obtained from (i) a plurality of sensors in the subsystem and (ii) a plurality of sensors in the system that are not located in the subsystem; (b) processing measurements of the first plurality of tags using an autoencoder by (1) generating a compressed representation of the measurements and (2) decoding the compressed representation of the measurements into estimates of the first plurality of tags, wherein the autoencoder has been trained according to historical values of the first plurality of tags; (c) determining whether a difference between the measurements and the estimates satisfies a threshold; and (d) transmitting an alert indicative that the subsystem is predicted to experience an anomaly if the difference satisfies the threshold, wherein the autoencoder is trained based on a dataset comprising historical values representative of normal operation of the subsystem, and wherein the autoencoder is trained such that the estimates of the first plurality of tags are similar or equivalent to the measurements when the first plurality of tags are captured during normal operation of the subsystem and the estimates of the first plurality of tags are poor estimates of the measurements when the first plurality of tags are captured during abnormal operation of the subsystem.

2. The method of claim 1, wherein (a) comprises processing data from sensors in the system using an unsupervised learning algorithm to generate a plurality of groups of tags, the plurality of groups of tags including the first plurality of tags indicative of the operational performance of the subsystem.

3. The method of claim 2, wherein each tag of the first plurality of tags is associated with at least one other tag of the first plurality of tags or with the operational performance of the subsystem.

4. The method of claim 2, wherein the unsupervised learning algorithm is a clustering algorithm.

5. The method of claim 4, wherein the clustering algorithm is a K-means clustering algorithm, a cosine similarity algorithm, a topological data analysis algorithm, or a hierarchical density-based spatial clustering of applications with noise (HDB-SCAN).

6. The method of claim 1, wherein (a) is performed offline.

7. The method of claim 1, further comprising, prior to (c), applying a weight to each of the measurements and the estimates.

8. The method of claim 1, further comprising dynamically adjusting the threshold during operation of the system.

9. The method of claim 1, further comprising determining whether a difference between the measurements of a respective tag and the estimates of the respective tag satisfies a tag threshold, and transmitting the alert if the difference satisfies the tag threshold.

10. The method of claim 1, wherein the autoencoder is a deep neural network or a support vector machine (SVM).

11. The method of claim 1, wherein the historical values comprise a sequence of data collected over a period of time in which no faults occurred in the subsystem.

12. The method of claim 1, wherein the system comprises a plurality of subsystems.

13. The method of claim 1, wherein the measured values of the first plurality of tags comprise a sequence of data collected during a predetermined lookback period.

14. The method of claim 13, further comprising dynamically adjusting the predetermined lookback period.

15. The method of claim 1, further comprising generating a risk score for the subsystem based on a magnitude of the difference between the measured values of the first plurality of tags and the estimated values of the first plurality of tags.

16. The method of claim 1, wherein the alert comprises an email or a text message.

17. The method of claim 1, wherein the alert comprises a notification in a mobile or web application.

18. The method of claim 17, wherein the mobile or web application is configured to enable a user to perform one or more corrective actions on the subsystem.

19. The method of claim 1, further comprising determining an action to correct the anomaly in the subsystem using a trained machine learning algorithm, wherein the trained machine learning algorithm has been trained on historical human actions and corresponding responses of the subsystem.

20. The method of claim 1, further comprising determining an action to correct the anomaly in the subsystem using an engineering principles-based rules-based logic to correlate patterns observed in tag measurements with known failure mechanisms of processes and equipment in the subsystem.

21. The method of claim 1, wherein the alert comprises a numerical risk score indicating a likelihood of the anomaly occurring, wherein the numerical risk score is based at least in part on a magnitude of the difference between the measured values of the first plurality of tags and the estimated values of the first plurality of tags.

22. The method of claim 1, wherein the alert comprises a numerical risk score indicating a likelihood of the anomaly occurring, wherein the numerical risk score is based at least in part on an extent to which the difference exceeds the threshold.

23. The method of claim 1, wherein the alert comprises a list of tags in the first plurality of tags that contribute most to the alert.

24. A system comprising one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising: (a) determining a first plurality of tags indicative of operational performance of a subsystem of a system, wherein each tag in the first plurality of tags comprises a sequence of data, and wherein the first plurality of tags is obtained from (i) a plurality of sensors in the subsystem and (ii) a plurality of sensors in the system that are not located in the subsystem; (b) processing the measurements using an autoencoder by (1) generating a compressed representation of the measurements of the first plurality of tags and (2) decoding the compressed representation of the measurements into estimated values of the first plurality of tags, wherein the autoencoder has been trained on historical values of the first plurality of tags; (c) determining whether a difference between the measurements and the estimated values satisfies a threshold; and (d) transmitting an alert indicating that the subsystem is expected to experience an anomaly if the difference satisfies the threshold, wherein the autoencoder is trained based on a dataset comprising historical values representative of normal operation of the subsystem, and wherein the autoencoder is trained such that the estimated values of the first plurality of tags are similar to or equivalent to the measurements when the first plurality of tags are captured during normal operation of the subsystem and the estimated values of the first plurality of tags are poor estimates of the measurements when the first plurality of tags are captured during abnormal operation of the subsystem.

25. One or more non-transitory computer storage media storing instructions that are operable, when executed by one or more computers, to cause the one or more computers to perform operations comprising: (a) determining a first plurality of tags indicative of performance of operation of a subsystem of a system, wherein each tag of the first plurality of tags comprises a sequence of data, and wherein the first plurality of tags is obtained from (i) a plurality of sensors in the subsystem and (ii) a plurality of sensors in the system that are not in the subsystem; (b) processing the measurements using an autoencoder by (1) generating a compressed representation of the measurements of the first plurality of tags and (2) decoding the compressed representation of the measurements into estimated values of the first plurality of tags, wherein the autoencoder has been trained on historical values of the first plurality of tags; (c) determining whether a difference between the measurements and the estimated values satisfies a threshold; and (d) transmitting an alert indicating that the subsystem is expected to experience an anomaly if the difference satisfies the threshold, wherein the autoencoder is trained based on a dataset comprising historical values representative of normal operation of the subsystem, and wherein the autoencoder is trained such that the estimated values of the first plurality of tags are similar to or equivalent to the measurements when the first plurality of tags are captured during normal operation of the subsystem and the estimated values of the first plurality of tags are poor estimates of the measurements when the first plurality of tags are captured during abnormal operation of the subsystem.

Images