System and method for predicting manufacturing process risk

Abstract

To provide a system and a method for use in preferably predicting a manufacturing process risk.SOLUTION: The present disclosure provides a system, a method, and a computer program product for use in predicting and detecting an abnormality in a subsystem of a system. An exemplary method includes (a) determining multiple first tags which signify the operating performance of the subsystem. The tags may be acquired from (i) multiple sensors within the subsystem and (ii) multiple sensors within the system, which are not incorporated in the subsystem. The method further includes (b) manipulating the measured values of the multiple first tags using an auto-encoder that is trained to generate estimates of the multiple first tags on the basis of history values of the multiple first tags, (c) determining whether differences between the measured values and the estimates satisfy a threshold, and (d), when the differences satisfy the threshold, allowing the subsystem to transmit an alert signifying that incurring an abnormality is predicted.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] (cross reference) This application claims priority to U.S. Provisional Patent Application No. 62 / 899,081, filed September 11, 2019, which is incorporated by reference in its entirety. [Background technology]

[0002] Manufacturers may rely on a framework of scheduled and reactive maintenance to manage their operating assets, which can result in lost revenue from deferred production, excessive costs associated with unplanned maintenance actions, reduced asset life, poor product quality, and worker safety risks associated with increased on-site exposure. Summary of the Invention [Means for solving the problem]

[0003] The present disclosure provides systems, methods, and computer program products for predicting and detecting anomalies in systems or subsystems of a processing pipeline and improving the reliability of the processing pipeline. The processing pipeline may be, for example, an oil and gas processing pipeline including drilling assets, refining assets, and pipeline assets (e.g., pumps, compressors, heat exchangers, and valves). A system for predicting and detecting anomalies as described herein can be implemented on one or more computers in one or more locations. The computer can store instructions that, upon execution, cause the computer to predict anomalies in subsystems of the system.

[0004] The system can determine a first plurality of tags indicative of the subsystem's operational performance. The first plurality of tags can include time series data from sensors within the subsystem. The first plurality of tags can additionally include time series data from sensors within the system that are not within the subsystem but are nevertheless indicative of the subsystem's operational performance. 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 correlated with the subsystem. The system can identify the first plurality of tags using one or more machine learning methods. For example, the system can use a clustering algorithm to identify the first plurality of tags from all of the tags in the system. Determining the first plurality of tags can be considered a feature selection operation.

[0005] The system can process measurements of the first plurality of tags using an autoencoder. The autoencoder can have an encoder configured to generate a reduced-dimensionality or compressed output from the measurements. The autoencoder can also have a decoder configured to generate estimates of the first plurality of tags from the reduced-dimensionality or compressed output. The autoencoder can be trained based on historical values of the first plurality of tags.

[0006] The system can determine whether a difference exists between the measurements of the first plurality of tags provided to the autoencoder and the estimates of the first plurality of tags generated by the autoencoder. If the measurements and estimates are identical 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 measurements and estimates 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.

[0007] While many manufacturing entities rely on scheduled or reactive maintenance to manage their operational assets, the system described above can accurately predict and detect failures and anomalies in processing pipelines before they occur by using data from hundreds to thousands of sensors and identifying correlations within that data. Because steps within a process can be highly interdependent, the correlations identified by the system described herein can be useful in identifying anomalies. In addition, the system can use machine learning models that can be retrained based on new failure events, improving prediction and detection accuracy over time. Finally, the system can predict failures and detect anomalies at the asset, system, or subsystem level, which can enable users to quickly perform scheduled maintenance on processing pipelines, maintain safety, extend asset life, produce higher-quality products, and avoid costly downtime.

[0008] The present disclosure may additionally provide applications and user interfaces that allow a user, for example, an operations manager or engineer, to interact with and view the output of the systems described above. The applications and user interfaces may also allow the user to monitor, control, and perform predictive maintenance on assets in the processing pipeline.

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

[0010] In one aspect, the present disclosure provides a method for predicting an anomaly in a subsystem of a system. The method may include determining a first plurality of tags indicative of the subsystem's operational performance. Each tag of the first plurality of tags may include a data sequence, and the first plurality of tags may be 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. The method may further include processing measurements of the first plurality of tags using an autoencoder by (1) generating a condensed representation of the measurements and (2) decoding the condensed representation of the measurements into estimated values of the first plurality of tags, the autoencoder being trained based on historical values of the first plurality of tags. The method may further include determining whether a difference between the measurements and the estimated values satisfies a threshold, and if the difference satisfies the threshold, transmitting an alert indicating that the subsystem is predicted to experience an anomaly.

[0011] In some implementations, (a) includes using an unsupervised learning algorithm to process data from sensors in the system to generate a plurality of groups of tags, the plurality of groups of tags including a first plurality of tags that are indicative of operational performance of a subsystem. In some implementations, each tag of the first plurality of tags is correlated with the operational performance of at least one other tag of the first plurality of tags or the subsystem. In some implementations, the unsupervised learning algorithm is a clustering algorithm. The clustering algorithm may be a k-means clustering algorithm, a cosine similarity algorithm, a topological data analysis algorithm, or hierarchical density-based spatial clustering for applications with noise (HDB-SCAN).

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

[0013] In some implementations, the method further includes applying a weighting process to each of the measurements and the estimates prior to (c).

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

[0015] In some implementations, the method further includes determining whether a difference between the individual tag measurement value and the individual tag estimate satisfies a tag threshold, and transmitting an alert if the difference satisfies the tag threshold.

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

[0017] In some implementations, the historical data includes data series collected during periods when no failures occurred within the subsystem.

[0018] In some implementations, the system comprises multiple subsystems.

[0019] In some implementations, the measurements of the first plurality of tags include a data series collected during a predetermined lookback horizon. In some implementations, the method further includes dynamically adjusting the lookback horizon.

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

[0021] In some implementations, the alert comprises an email or text message. In some implementations, the alert can comprise a notification within a mobile or web application. In some implementations, the mobile or web application is configured to allow a user to implement one or more corrective actions related to the subsystem.

[0022] 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 be trained based on historical human actions and corresponding responses by the subsystem. In some implementations, the method further includes determining actions to correct the anomaly in the subsystem using rule-based logic based on engineering principles to correlate observed patterns in the tag measurements to known failure mechanisms for processes and equipment in the subsystem.

[0023] In some implementations, the alert includes a numeric risk score indicating the likelihood that an anomaly will occur. The numeric risk score can be based, at least in part, on the magnitude of the difference between the measurements of the first plurality of tags and the estimated values of the first plurality of tags. In some implementations, the alert includes a numeric risk score indicating the likelihood that an anomaly will occur. The numeric risk score can be based, at least in part, on the amount by which the difference exceeds a threshold. In some implementations, the alert includes a list of tags from the first plurality of tags that most contributed to the alert.

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

[0025] Another aspect of the present disclosure provides a system comprising one or more computer processors and a computer memory coupled thereto, the computer memory comprising machine-executable code that, upon execution by the one or more computer processors, implements any of the methods described above or elsewhere herein.

[0026] Additional aspects and advantages of the present disclosure will become readily apparent to those skilled in the art from the following detailed description, in which only illustrative embodiments of the present disclosure are shown and described. As will be realized, the present disclosure is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the present disclosure. Therefore, the drawings and description are to be regarded as illustrative in nature, and not as restrictive. The present invention provides, for example, the following. (Item 1) 1. A method for predicting anomalies in a subsystem of a system, comprising: (a) determining a first plurality of tags indicative of operational performance of the subsystem, each tag of the first plurality of tags including a data sequence, the first plurality of tags being obtained from (i) a plurality of sensors within the subsystem and (ii) a plurality of sensors within the system that are not within the subsystem; (b) processing measurements of the first plurality of tags with an autoencoder by (1) generating condensed representations of the measurements and (2) decoding the condensed representations of the measurements into estimates of the first plurality of tags, the autoencoder being trained based on historical values of the first plurality of tags; and (c) determining whether the difference between the measured value and the estimated value satisfies a threshold; and (d) if the difference satisfies the threshold, transmitting an alert indicating that the subsystem is predicted to experience an anomaly; and A method comprising: (Item 2) 2. The method of claim 1, wherein (a) includes using an unsupervised learning algorithm to process data from sensors in the system to generate a plurality of populations of tags, the plurality of populations of tags including the first plurality of tags indicative of operational performance of the subsystem. (Item 3) Item 3. The method of item 2, wherein each tag of the first plurality of tags is correlated with the operational performance of at least one other tag of the first plurality of tags or the subsystem. (Item 4) 3. The method of claim 2, wherein the unsupervised learning algorithm is a clustering algorithm. (Item 5) Item 5. The method according to item 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 for applications with noise (HDB-SCAN). (Item 6) Item 1, wherein (a) is performed offline. (Item 7) Item 10. The method of item 1, further comprising, prior to (c), applying a weighting process to each of the measured value and the estimated value. (Item 8) Item 10. The method of item 1, further comprising dynamically adjusting the threshold during operation of the system. (Item 9) 2. The method of claim 1, further comprising: determining whether a difference between the measurement value of an individual tag and the estimated value of the individual tag satisfies a tag threshold; and transmitting an alert if the difference satisfies the tag threshold. (Item 10) Item 1. The method according to item 1, wherein the autoencoder is a deep neural network or a support vector machine (SVM). (Item 11) 2. The method of claim 1, wherein the historical data includes a data series collected during a period in which no faults occurred in the subsystem. (Item 12) Item 10. The method of item 1, wherein the system comprises a plurality of subsystems. (Item 13) Item 10. The method of item 1, wherein the measurements of the first plurality of tags include a data series collected during a predetermined lookback horizon. (Item 14) Item 14. The method of item 13, further comprising dynamically adjusting the look-back horizon. (Item 15) 2. The method of claim 1, further comprising generating a risk score for the subsystem based on the magnitude of the difference between the measured values of the first plurality of tags and the estimated values of the first plurality of tags. (Item 16) 2. The method of claim 1, wherein the alert comprises an email or a text message. (Item 17) Item 10. The method of item 1, wherein the alert comprises a notification within a mobile or web application. (Item 18) Item 18. The method of item 17, wherein the mobile or web application is configured to allow a user to implement one or more corrective actions regarding the subsystem. (Item 19) Item 10. The method of item 1, further comprising determining actions to correct the anomaly in the subsystem using a trained machine learning algorithm, the trained machine learning algorithm being trained based on historical actions taken by humans and corresponding responses by the subsystem. (Item 20) 2. The method of claim 1, further comprising determining actions to correct the anomaly in the subsystem using rule-based logic based on engineering principles to correlate observed patterns in tag measurements to known failure mechanisms for processes and equipment in the subsystem. (Item 21) Item 10. The method of item 1, wherein the alert includes a numerical risk score indicating the likelihood that the anomaly will occur, the numerical risk score being based, at least in part, on the magnitude of a difference between the measured values of the first plurality of tags and the estimated values of the first plurality of tags. (Item 22) 10. The method of claim 1, wherein the alert includes a numerical risk score indicating the likelihood that the anomaly will occur, the numerical risk score being based, at least in part, on the amount by which the difference exceeds the threshold. (Item 23) Item 10. The method of item 1, wherein the alert includes a list of tags from the first plurality of tags that contributed most to the alert. (Item 24) 1. A system comprising one or more computers and one or more storage devices, the one or more storage devices storing instructions that, when executed by the one or more computers, cause the one or more computers to: (a) determining a first plurality of tags indicative of operational performance of a subsystem of a system, each tag of the first plurality of tags including a data sequence, the first plurality of tags being obtained from (i) a plurality of sensors within the subsystem and (ii) a plurality of sensors within the system that are not within the subsystem; (b) processing measurements of the first plurality of tags with an autoencoder by (1) generating condensed representations of the measurements and (2) decoding the condensed representations of the measurements into estimates of the first plurality of tags, the autoencoder being trained based on historical values of the first plurality of tags; and (c) determining whether the difference between the measured value and the estimated value satisfies a threshold; and (d) if the difference satisfies the threshold, transmitting an alert indicating that the subsystem is predicted to experience an anomaly; and The system is operable to cause operations to be performed, including: (Item 25) One or more non-transitory computer storage media having instructions stored thereon that, when executed by one or more computers, cause the one or more computers to: (a) determining a first plurality of tags indicative of operational performance of a subsystem of a system, each tag of the first plurality of tags including a data sequence, the first plurality of tags being 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 measurements of the first plurality of tags with an autoencoder by (1) generating condensed representations of the measurements and (2) decoding the condensed representations of the measurements into estimates of the first plurality of tags, the autoencoder being trained based on historical values of the first plurality of tags; and (c) determining whether the difference between the measured value and the estimated value satisfies a threshold; and (d) if the difference satisfies the threshold, transmitting an alert indicating that the subsystem is predicted to experience an anomaly; and

[0023] 1. One or more non-transitory computer storage media operable to cause the computer to perform operations including: (Incorporated by reference)

[0027] All publications, patents, and patent applications mentioned herein are 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 that the publications and patents or patent applications incorporated by reference conflict with the disclosure contained herein, it is intended that the present specification supersede and / or supersede any such conflicting material. [Brief explanation of the drawings]

[0028] The novel features of the invention are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present invention will be obtained by reference to the following detailed description and accompanying drawings (also herein "Figure and FIG.") that set forth illustrative embodiments, in which the principles of the invention are utilized.

[0029] [Figure 1] FIG. 1 illustrates diagrammatically a system for predicting and detecting anomalies.

[0030] [Figure 2] FIG. 2 is a flowchart of an exemplary process for predicting subsystem anomalies, generating alerts about the anomalies, generating cases to follow up on the investigation of the anomalies, and issuing work orders to resolve any faults identified during the investigation.

[0031] [Figure 3] FIG. 3 is a flowchart of an exemplary process for predicting anomalies in a subsystem of a system.

[0032] [Figure 4] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 5] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 6] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 7] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 8] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 9] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 10] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 11] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 12] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 13] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 14] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 15] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 16] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 17]4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts. [Figure 18] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts.

[0033] [Figure 19] FIG. 19 diagrammatically illustrates a model that can be used to represent the processing pipeline within the application depicted in FIGS. 4-18.

[0034] [Figure 20] FIG. 20 illustrates a computer system that is programmed or otherwise configured to implement the methods provided herein. DETAILED DESCRIPTION OF THE INVENTION

[0035] Detailed Description While various embodiments of the present invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions may occur to those skilled in the art without departing from the invention. It will be understood that various alternatives to the embodiments of the invention described herein may be employed.

[0036] The term "asset" as used herein generally refers to a single piece of equipment (eg, a valve) in a process pipeline.

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

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

[0039] The term "platform" as used herein generally refers to a large offshore structure for exploring for, extracting, and processing oil and natural gas from beneath the ocean floor.

[0040] The term "plant" as used herein generally refers to a facility where an industrial manufacturing process occurs.

[0041] The term "tag" as used herein generally refers to an individual data series associated with a measurement (eg, pressure, temperature, or flow rate) on an asset.

[0042] The term "cluster" as used herein generally refers to a correlated group of tags that are associated with a single subsystem.

[0043] Each time the term "at least," "greater than," or "greater than or equal to" precedes the first number in a series of two or more numbers, the term "at least," "greater than," or "greater than or equal to" applies to each and every number in the series. 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."

[0044] Each time the term "less than or equal to," "less than," or "less than or equal to" precedes the first number in a series of two or more numbers, the term "less than or equal to," "less than," or "less than or equal to" applies to each and every number in the series. 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."

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

[0046] The system can process measurements of the first plurality of tags using an autoencoder. The autoencoder can have an encoder configured to generate a reduced-dimensional or compressed output from the measurements and a decoder configured to generate estimates of the first plurality of tags. The autoencoder can be trained based on historical values of the first plurality of tags.

[0047] The system can determine whether a discrepancy exists between the measurements of the first plurality of tags provided to the autoencoder and the estimates of the first plurality of tags generated by the autoencoder. If the measurements and estimates are identical 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 measurements and estimates 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, such as an engineer or operations manager, to monitor and investigate the alert, generate a case to track action items related to the alert, and generate work orders to address the malfunction underlying the alert.

[0048] FIG. 1 diagrammatically illustrates a system for predicting and detecting anomalies. The system may have a processing pipeline 100. The processing pipeline 100 may be located within a manufacturing facility, e.g., a plant. Alternatively, the processing pipeline 100 may be distributed among assets in different locations connected by conduits. The processing pipeline 100 may be configured to produce one or more products from one or more raw materials. The processing pipeline 100 may implement a batch, semi-batch, or continuous process. A batch process may be a process that produces a definite quantity of product. A continuous process may be a process that continuously consumes raw materials while producing an indefinite quantity of product.

[0049] The processing pipeline 100 may be an oil and gas processing pipeline. Alternatively, the processing pipeline 100 may be a chemical or material synthesis pipeline (e.g., a pipeline for the synthesis of paint, fertilizer, textiles, rubber, steel, or aluminum), a drug synthesis pipeline, or a food or beverage production pipeline.

[0050] Processing pipeline 100 may include system 111. System 111 may include subsystem 112 and subsystem 116. Each subsystem may include individual components or portions of assets, such as equipment (not depicted) and sensors. One example of a system in an oil and gas processing pipeline is a crude distillation unit. A crude distillation unit may include a coker, a hydrocracker, a catalytic converter, a hydrotreater, a reformer, and a desulfurizer subsystem, each of which may include assets. Although processing pipeline 100 is depicted as including only a single system, processing pipeline 100 may include multiple systems, each with multiple subsystems.

[0051] The sensors in processing pipeline 100 may be sensors that generate time-series data. The sensors may be thermometers, pressure gauges, flow meters, accelerometers, magnetometers, and the like. In addition to such time-series data, the sensors may generate metadata, such as data about the sensor's location within system 111 or subsystems 112 and 166. The sensors may collect data at rates of at least approximately 0.1 Hz, 0.2 Hz, 0.3 Hz, 0.4 Hz, 0.5 Hz, 1 Hz, 5 Hz, 10 Hz, 100 Hz, 1,000 Hz, 10,000 Hz, 100,000 Hz, or more. The sensors in processing pipeline 100 may transmit the time-series data, referred to in this disclosure as "tags," to one or more computing devices that implement anomaly prediction and detection. Although processing pipeline 100 is depicted as having only six sensors, it may have tens of thousands of sensors.

[0052] 1 may have a training subsystem 120. The training subsystem 120 may be configured to train machine learning models to predict and detect anomalies.

[0053] Training subsystem 120 may include a cluster module 122. Cluster module 122 may be configured to train and run a clustering algorithm to determine groups of tags from sensors 113-115 and 117-119 that are indicative of the operational performance of a subsystem in processing pipeline 100. Each group of tags can be correlated with the operational performance of a particular subsystem.

[0054] The clustering algorithm may 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 tags from the processing pipeline 100 based on the physical proximity of their sensors to other sensors and related subsystems. The clustering algorithm may alternatively 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 (each observation belongs to the cluster with the closest mean value). The mean value may serve as a prototype for the cluster. In the context of tags from the processing pipeline 100, a k-means clustering algorithm can generate distinct groups of tags that are correlated with each other. Each group of tags can then be associated with a particular subsystem based on prior knowledge of that subsystem, for example, knowledge of the sensors within the subsystem. The clustering algorithm may alternatively be a variance-based clustering algorithm, such as a Gaussian mixture model or an expectation-maximization algorithm. Examples of other clustering algorithms that the clustering module 122 may implement are a cosine similarity algorithm, a topological data analysis algorithm, and hierarchical density-based spatial clustering for applications with noise (HDB-SCAN).

[0055] The training subsystem 120 may additionally include an autoencoder training module 124. The autoencoder training module 124 may be used to train the autoencoder 132. The autoencoder training module 124 may train the autoencoder 132 based on historical values of tags indicative of the operational performance of a selected subsystem. The historical tags may be tags collected during normal operation of the subsystem, e.g., during a period when no faults occurred within the subsystem. Training the autoencoder 132 based on normal tags may result in the autoencoder 132 having parameters that represent "normal" characteristics. Although FIG. 1 depicts only a single autoencoder, each subsystem in the system may have its own autoencoder that may be trained based on historical values of tags indicative of the operational performance of that particular subsystem.

[0056] The autoencoder 132 may include an encoder 133 that encodes measurements of a first plurality of tags determined to be indicative of the operational performance of a particular subsystem within the processing pipeline 100. The autoencoder 132 may also include a decoder 134 that attempts to reconstruct the measurements. Given measurements representing training data, the autoencoder 132 can generate estimates that are similar to or equivalent to the measurements. However, given anomalous measurements, the autoencoder 132 may produce poor reconstructions.

[0057] The autoencoder 132 may be a neural network. Generally, a neural network may employ multiple layer operations to predict one or more outputs from one or more inputs. A neural network may include one or more hidden layers interposed between an input layer and an output layer. The output of each layer may be used as input to another layer, e.g., the next hidden layer or the output layer. Each layer of a neural network may define one or more transformation operations to be performed on the inputs to the layer. Such transformation operations may be referred to as neurons. The output of a particular neuron may be a weighted sum of the inputs to the neuron, adjusted with a bias and multiplied by an activation function, e.g., a rectified linear unit (ReLU) or a sigmoid function. Training a neural network may involve providing inputs to an untrained neural network to generate a predicted output, comparing the predicted output to an expected output, and updating the weights and biases of the algorithm to account for the difference between the predicted and expected outputs. Specifically, a cost function may be used to calculate the difference between predicted and expected outputs. By calculating the derivative of the cost function with respect to the network's weights and biases, the weights and biases can be iteratively adjusted over multiple cycles to minimize the cost function. Training can be completed once the predicted outputs meet a convergence condition, such as obtaining a small calculated cost.

[0058] Neural networks can be trained using supervised or unsupervised learning processes. In supervised learning, the training inputs to the neural network are labeled, i.e., the training inputs have known outputs. In contrast, in unsupervised learning, the training inputs are unlabeled. While the autoencoder training module 124 can implement an unsupervised learning process to train the autoencoder 132, the inputs to the autoencoder 132 do not need to be labeled because the desired output of the autoencoder 132 is simply the input.

[0059] 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”). The RNN can have recursive connections that can encode dependencies in time-series data. The RNN can include an input layer configured to receive a sequence of time-series inputs, e.g., time-series tags from a sensor in the processing pipeline 100. The RNN can also include one or more hidden recurrent layers that maintain state. For each time step, each hidden recurrent layer can calculate an output and a next state for the layer. The next state can depend on the previous state and the current input. The state can be maintained across time steps, capturing dependencies in the input sequence. Such an RNN can be used to encode time-series features in the processing pipeline 100.

[0060] One example of an RNN is a long short-term memory (LSTM) network, which can be made up of LSTM units. LSTM units can be made up of cells, input gates, output gates, and forget gates. Cells can be responsible for tracking dependencies between elements in an input sequence. Input gates can control the degree to which new values flow into cells, forget gates can control the degree to which values remain in cells, and output gates can control the degree to which values in cells are used to calculate the output activation of the LSTM unit. The activation function of an LSTM gate can be a logistic function.

[0061] After being trained, the inference subsystem 130 may implement an autoencoder 132. If the difference between the measurements of a first plurality of tags provided to the autoencoder 132 and the estimates of the first plurality of tags generated by the autoencoder 132 exceeds a threshold, an anomaly may exist in the subsystem associated with the first plurality of tags. In such a case, the system may transmit an alert to the application 140, which will be described in more detail below.

[0062] The inference subsystem 130 can implement other types of machine learning models. For example, the inference subsystem 130 can implement a machine learning model configured to (i) optimize a threshold at which an anomaly is predicted or detected, (ii) predict a failure mode associated with an anomaly, or (iii) determine a corrective action. The machine learning model can be trained using a supervised, semi-supervised, unsupervised, or reinforcement learning process. Examples of such machine learning models are regression algorithms, decision trees, support vector machines, Bayesian networks, neural networks (e.g., feedforward neural networks, CNNs, RNNs, and the like), clustering algorithms, reinforcement learning algorithms, and the like.

[0063] As mentioned above, the system of FIG. 1 may additionally include application 140. Application 140 may be a mobile application or a web application. Application 140 can be used on any type of computing device, e.g., a desktop or laptop computer, an electronic tablet, a mobile device, or the like. Users, e.g., engineers and operations managers, can use application 140 to review alerts and predicted failure modes generated by inference subsystem 130, generate cases to track investigations of anomalies, and generate work orders to address any malfunctions underlying the alerts. Application 140 will be described in more detail with reference to subsequent figures.

[0064] The system and its components of FIG. 1 can be implemented on one or more computing devices. The computing device can be a server, a desktop or laptop computer, an electronic tablet, a mobile device, or the like. The computing device can be located in one or more locations. The computing device can have a general-purpose processor, a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like. The computing device can additionally have memory, such as dynamic or static random-access memory, read-only memory, flash memory, a hard drive, or the like. The memory can be configured to store instructions that, upon execution, cause the computing device to implement the functionality of the training subsystem 120, the inference subsystem 130, or the application 140. The computing device can additionally have a network communication device. The network communication device can enable the computing devices to communicate with each other and any number of user devices, such as user devices running the application 140, over a network. For example, the inference engine 130 can transmit alerts, predicted failure modes, and the like to a user device launching the application 140. The network can be a wired or wireless network. For example, the network can be an optical fiber network, an Ethernet network, a satellite network, a cellular network, a Wi-Fi network, a Bluetooth network, or the like. In other implementations, the computing device can be several distributed computing devices accessible through the Internet. Such computing devices can be considered cloud computing devices.

[0065] 2 is a flowchart of an exemplary process for predicting subsystem anomalies, generating alerts about the anomalies, generating cases to follow up on the investigation of the anomalies, and issuing work orders to resolve any faults identified during the investigation. This process can be performed by one or more users using one or more computer systems and applications at one or more locations, such as application 140 of FIG. 1.

[0066] 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. A qualitative prediction can be a prediction that an anomaly will occur within a specified time period. A quantitative prediction can be a numerical risk score indicating the 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. Operation 210 will be described in more detail with reference to FIG. 3.

[0067] The system can then transmit 220 an alert to applications on any number of user devices indicating that the subsystem is experiencing or will experience an anomaly. The alert identifies the affected system and subsystem and can 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 the basis for further investigation by users using the application.

[0068] Finally, using the application, users can analyze alerts, investigate anomalies, and generate and manage cases and work orders to resolve them (230).

[0069] In one example, a user can assign an alert to an authorized reviewer. The reviewer may be an engineer or an operations manager. The reviewer can provide feedback regarding the predicted failure mode. The feedback can be a text comment. Alternatively, or in addition, the reviewer can reject or approve 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 may assume that the predicted failure mode is correct. Once the reviewer provides feedback, the system can then automatically generate a case that tracks all actions taken regarding the alert.

[0070] Cases may be distinct from alerts. The purpose of a case may be to track activity, coordinate across users, and enable collaboration. Cases may have a one-to-one or one-to-many relationship with alerts; that is, multiple related alerts may be addressed using a single case. Cases may enable collaboration through the tagging of other users and through comments and uploaded files that are available for editing or viewing by all users associated with the case. The application may allow users to take the following actions on a case: (1) assign the case and underlying alerts to a reviewer, (2) add comments to the case, (3) tag another user, (4) provide feedback regarding predicted failure modes, (5) generate associated work orders, and (6) close or reopen the case.

[0071] After providing feedback regarding the predicted failure mode, the reviewer can investigate the alert using alert analysis tools within the application, which will be described in more detail with reference to subsequent figures. Briefly, the reviewer can review specific tags to identify the root cause of the alert, e.g., a defective component. The reviewer can record comments about their findings, which can become part of the case history. Based on the results of their investigation, the reviewer can generate a work order. Once the work order is completed, the application can automatically close the alert and the case.

[0072] The data collected during operation 230 can be used to train a machine learning algorithm to predict appropriate corrective actions for the detected anomalies. For example, the specific predicted anomalies, the tags that cause the predicted anomalies, and the corresponding failure modes selected by the user can serve as tagged data for training a supervised machine learning algorithm. As more training data is collected over time and incorporated into the algorithm, the performance of the algorithm can improve.

[0073] 3 is a flowchart of an exemplary process for predicting anomalies in a subsystem of a system. The process of FIG. 3 can be implemented by one or more computer systems in one or more locations. For example, the training subsystem 120 and the inference subsystem 130 of FIG. 1 can implement the process of FIG. 3.

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

[0075] The system can use one or more machine learning algorithms to determine tags that are indicative of the operational performance of a subsystem. For example, the system can use a clustering algorithm, such as a k-means clustering algorithm, to process all tags in the system and generate distinct groups of tags that include a first plurality of tags. Tags within each distinct group can be correlated with each other or with the operational performance of a selected subsystem. Operation 310 can be considered a feature selection operation. Operation 310 can be performed offline, i.e., prior to implementing the system in a processing pipeline.

[0076] In a second operation, the system can use an autoencoder to process measurements of a first plurality of tags (i.e., tags determined to be indicative of subsystem operation) (320). The measurements can be limited to a predetermined lookback horizon. The predetermined lookback horizon can be at least approximately 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 more. The system can dynamically adjust the lookback horizon to optimize the accuracy of the anomaly prediction. If the lookback horizon is too long, the measurements may contain irrelevant data. If the lookback horizon is too short, the measurements may lack important contextual information. The system can use any of the machine learning methods described in this disclosure to optimize the lookback horizon.

[0077] The autoencoder can include an encoder configured to generate a reduced-dimensional or compressed output of measurements of the first plurality of tags. The autoencoder can also include a decoder configured to generate estimates of the first plurality of tags from the reduced-dimensional or compressed output. The autoencoder can be a deep neural network, such as a feedforward neural network, a convolutional neural network, a recurrent neural network, or the like. The autoencoder can be trained based on 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 when the subsystem did not experience anomalies. Training the autoencoder based on normal historical values can result in the autoencoder having parameters representative of "normal" characteristics. When provided with measurements representing the historical values used for training, the autoencoder can generate estimates similar to or equivalent to the measurements. However, when provided with anomalous measurements, the autoencoder may produce poor estimates.

[0078] 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, this may indicate that the operational performance of the subsystem is normal, e.g., the subsystem is not experiencing an anomaly, the subsystem is operating within normal parameters, or the subsystem is producing a quality product. On the other hand, if the system determines that the difference does satisfy the threshold, this may indicate that the subsystem is experiencing an anomaly.

[0079] In some cases, the system may apply weighting to the tag measurements and estimates prior to determining whether the difference satisfies a threshold. The system may do so because some tags may be more highly correlated with the subsystem's operational performance than others. The system may apply greater weighting to such tags than to tags that are less highly correlated with the subsystem's operational performance.

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

[0081] In a fourth operation, the system may transmit an alert indicating that the system is experiencing an anomaly if the difference satisfies a threshold (340). The alert may additionally include a numeric risk score. The numeric risk score may indicate the severity of the predicted anomaly. The numeric risk score may be based, at least in part, on (i) the 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) the amount by which the difference exceeds a threshold. The alert may additionally include a list of tags that contributed to the alert, the amount each tag contributed, and the tag's values over a lookback window. The alert may also include a predicted failure mode associated with the alert. The system may predict such failure mode using, for example, a machine learning classifier or any of the other machine learning methods described herein.

[0082] The alert can be an email or a text message. Alternatively, or in addition, the alert can be a notification within a mobile or web application, such as application 140 of FIG. 1. The alert can specify a quantitative risk score associated with the alert, a risk threshold, the systems and subsystems associated with the alert, and the date and time the alert was generated. As will be explained in more detail in subsequent figures, the application can be configured to allow the user to conduct an investigation of the alert.

[0083] In some cases, in addition to determining whether the differences between the measurements of the first plurality of tags and the estimated values of the first plurality of tags collectively satisfy a threshold, the system may also determine whether the differences between individual measurements and estimates satisfy individual thresholds for the corresponding tags, and if so, transmit an alert indicating so, which may alert a user to irregular data points that may not yet cause an anomaly. (User Interface)

[0084] 4-18 illustrate the user interface of the application, which may allow a user to investigate alerts and generate and manage cases and word orders associated with such alerts.

[0085] 4 shows the home screen of the application. The home screen can display key performance indicators ("KPIs") related to the processing pipeline being monitored. The KPIs can include open (e.g., unresolved) alerts, unplanned subsystem events, maintenance costs against the maintenance budget, and total plant uptime, all over a selected period of time. The home screen can display in graphs the open alerts, unplanned subsystem events, and total plant uptime as a function of time.

[0086] The home screen may additionally display a grid showing the highest priority alerts in the processing pipeline. Each row in the grid may correspond to a different alert. The inference subsystem 130 of FIG. 1 may generate and transmit alerts to applications by implementing the process of FIG. 3. Columns in the grid may indicate each alert's name, originating subsystem, qualitative risk score (e.g., low, medium, or high), numeric risk score, date and time of occurrence, and status (e.g., case generated, unprocessed, etc.). The numeric risk score may range, for example, from 0 to 100, with 100 indicating the highest risk anomaly. The numeric risk score may be color-coded to indicate the predicted severity of the corresponding anomaly. For example, the most severe anomalies may have a red risk score, while less severe anomalies may have a yellow risk score.

[0087] The home screen may additionally display a stacked bar graph showing the systems in the processing pipeline causing the most alerts. The alerts within each bar may be color-coded to show the number of alerts in each bar within each qualitative risk category (e.g., low, medium, or high). The stacked bar graph may be configured to show the systems in the processing pipeline causing the most alerts within yesterday, last week, last month, last three months, last six months, last year, or more.

[0088] The home screen may additionally display a grid showing the highest priority cases in the processing pipeline. Each row in the grid may correspond to a different case. The application or a user may raise a case in response to an alert. Columns in the grid may show each case's name, originating subsystem, priority, status (e.g., in review, assigned, etc.), assignee (e.g., person assigned to resolve the case), creation date, and last activity date. Cases may be assigned priority by the assignee. Alternatively, the application may automatically assign priorities to cases based on a number of factors. For example, the application may 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.

[0089] The grid described above can be sorted alphabetically or numerically by any column.

[0090] The home screen may additionally have a navigation bar that may allow the user to navigate to the alerts screen, the cases screen, the systems screen, the analysis screen, and the settings screen.

[0091] Figure 5 shows the Alerts screen. A user can open the Alerts screen by selecting the Alerts icon in the navigation bar. The Alerts screen can allow a user to search and filter processing pipelines within a processing pipeline. A 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 a processing pipeline.

[0092] The alerts screen can have an overview window that can display the total number of alerts for the user or in the processing pipeline. The overview window can also display the number of high-risk, medium-risk, and low-risk alerts.

[0093] The alerts screen can have a search bar. The search bar can allow a user to search for alerts by keyword. The alerts screen can also have a filtering window. The filtering window can allow a user to filter the alerts returned as a result of a keyword search. A user can filter alerts by status (e.g., open, case generated, or closed), triggered date, originating system or subsystem, or qualitative risk category of the alert.

[0094] The alerts screen can display a grid of alerts that meet the search and filtering criteria. Each row in the grid can correspond to a different alert. Columns in the grid can indicate each alert's name, originating subsystem, qualitative risk score (e.g., low, medium, or high), numeric risk score, date and time of occurrence, and status (e.g., case generated, pending, etc.).

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

[0096] The alert details screen may display a grid of tags contributing to the alert. Each row in the grid may correspond to a different tag. Columns in the grid may show the name of each tag (e.g., temperature, pressure, vibration, etc.), the amount each tag contributes to the alert, and the value of each tag when the alert was generated. A user can expand each tag to reveal data quality and threshold alerts associated with the tag. A data quality alert may indicate that data from a sensor associated with the tag has been lost or corrupted. A threshold alert may indicate that a data value from a sensor associated with the tag exceeds a threshold.

[0097] The alert details screen may additionally display the most common failure modes associated with the alert and assist the user in resolving the alert.

[0098] FIG. 7 shows a cases screen. The cases screen can allow users 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. Additionally, in some situations, there may not be a one-to-one correspondence between alerts and cases. For example, one case may be used to resolve many related alerts.

[0099] The Cases screen can be similar in form to the Alerts screen. The Cases screen can allow a user to search and filter cases in the processing pipeline. A user can view their own cases (e.g., cases assigned to them, cases they are collaborating on, or cases in which they are mentioned) or all cases in the processing pipeline.

[0100] The case screen may have a search bar. The search bar may allow a user to search for cases by keyword. The case screen may also have a filtering window. The filtering window may allow a user to filter the cases returned as a result of a keyword search. A user may filter cases by status (e.g., unassigned, assigned, under review, closed), date created, originating system or subsystem, or assignee.

[0101] The Cases screen can display a grid of cases that meet search and filtering criteria. Each row in the grid can correspond to a different case. Columns in the grid can indicate each case's name, originating subsystem, status, assignee, and the date and nature of the last action taken on the case (e.g., assigned case, comments added, attachments uploaded, priority changed, etc.).

[0102] Figure 8 shows a case details screen, which can provide a collaboration and research workspace for users to work on a particular case.

[0103] The case details 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., as manually defined by the user when the case is started), the status of the case (e.g., alerts open, case created, work order created, work order completed, case closed), and collaborators on the case (e.g., the case owner and other users who have mentioned or commented on the case). The overview window can also have action buttons configured to allow the user to create a work order for the case, close the case, or edit the case priority.

[0104] The case details screen can also display a grid of actions associated with the case. Each row in the grid can correspond to a different action. Each row can indicate the collaborator who took the action, a summary of the action, a list of attachments (e.g., marked-up schematics, photos of subsystems associated with the case, etc.), and the time the action was taken.

[0105] The case details screen may additionally display an alert summary window. The alert summary window may show the top three tags that contributed to the alert, the systems or subsystems that may be at risk as a result of the alert, the date the alert was generated, a quantitative risk score for the alert, and a list of suggested failure modes typically associated with that type of alert. The list of suggested failure modes may be configured to allow the user to approve or disapprove the suggested failure modes, provide feedback on the suggested failure modes, or add new failure modes from a drop-down list.

[0106] Figure 9 shows the Subsystem Analysis tab of the Subsystem Detail screen. The Subsystem Detail screen can provide the user with functionality to focus on a single subsystem within a processing pipeline or facility. The Subsystem Detail screen can display the subsystem's quantitative risk score over time, historical alerts, cases, and work orders associated with the system.

[0107] The Subsystem Analysis tab can display a grid of tags that contribute to the quantitative risk score for the subsystem. Each row in the grid can correspond to a different tag. Columns in the grid can show each tag's minimum, maximum, and average contribution to the quantitative risk score over a selected time period, as well as the tag's most recent measurement.

[0108] The Subsystem Analysis tab can additionally display a chart showing the contribution of the top three tags to the subsystem's quantitative risk score over time. A filtering window adjacent to the chart can allow the user to select the tags that are displayed in the chart. For example, the user can specify which tags should be displayed and the time period for which they should be displayed.

[0109] FIG. 10 shows the Cases tab of the Subsystem Detail screen. Although not depicted, the Subsystem Detail screen may additionally have an Alerts tab and a Word Order tab. These tabs may allow a user to search, filter, and view cases, alerts, and work orders for a particular subsystem. These tabs may be similar to the previously described screens, except that the cases, alerts, and word orders are limited to the particular subsystem.

[0110] 11 shows the Clusters tab of the Subsystem Details screen, which can display tags that have been identified by the system as being associated with the subsystem quantitative risk score, for example, by implementing the unsupervised clustering method described with reference to FIG.

[0111] 12 shows the Subsystem Diagram tab of the Subsystem Detail screen. The Subsystem Diagram tab can show a schematic diagram of the subsystem. The schematic diagram can be static, e.g., an image, or it can be dynamic, e.g., an interactive model with traversable links.

[0112] Figure 13 shows the Systems screen of an application. The Systems screen can provide users of the application with a consolidated view of all systems in the processing pipeline. The Systems screen can include a grid that displays each system in a separate row. Columns in the grid can show each system's quantitative risk score, the number of active alerts per system, the number of open cases per system, and the system's location.

[0113] The summary window in the systems screen can additionally show the number of systems or subsystems that have alerts.

[0114] Figure 14 shows the Subsystems tab of the System Details screen. The Subsystems tab can show more detailed information about the subsystems within the system, including each subsystem's (i) quantitative risk score, number of active alerts, number of open cases, and the last activity for that subsystem (e.g., alert created, case opened, alert closed, case closed, work order created, etc.).

[0115] 15 shows the Subsystem Alerts tab of the System Details screen, which can show more detailed information about alerts within the various subsystems of the system.

[0116] 16 shows the Subsystem Instances tab of the System Details screen, which may show more detailed information about the instances associated with the various subsystems of the system.

[0117] 17 shows the Work Orders tab of the System Details screen, which can show more detailed information about the work orders associated with the various subsystems of the system.

[0118] 18 shows a data analysis screen for an application. The data analysis screen can provide the user with the functionality to plot any metric or time within the application case, such as tags, subsystem quantitative risk scores, system quantitative risk scores, or the like.

[0119] FIG. 19 diagrammatically illustrates a model that may be used to represent a processing pipeline within an application. Models can be abstract representations of various materials, assets, processes, data, and the like. Models can be arranged in a hierarchical manner. For example, multiple process step models can be arranged in series or 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 models and data models can represent the inputs and outputs of a process step or manufacturing process model, respectively. A model can be defined by fields and functions, the values of which can define the particular materials, assets, processes, and data that the model represents. (Computer Systems)

[0120] The present disclosure provides a computer system 2001 programmed to implement the methods of the present disclosure. Figure 20 shows a computer system 2001 programmed or otherwise configured to implement the system of Figure 1. The computer system 2001 can be a user's electronic device or a computer system located remotely relative to the electronic device. The electronic device can be a mobile electronic device.

[0121] Computer system 2001 includes a central processing unit (CPU, also referred to herein as "processor" and "computer processor") 2005, which can be a single-core or multi-core processor, or multiple processors for parallel processing. Computer system 2001 also includes memory or memory locations 2010 (e.g., random access memory, read-only memory, flash memory), an electronic storage unit 2015 (e.g., a hard disk), a communication interface 2020 (e.g., a network adapter) for communicating with one or more other systems, and peripheral devices 2025, such as cache, other memory, data storage devices, and / or electronic display adapters. Memory 2010, storage unit 2015, interface 2020, and peripheral devices 2025 communicate with CPU 2005 through a communication bus (solid lines) such as a motherboard. The storage unit 2015 may be a data storage unit (or data repository) for storing data. The computer system 2001 may be operatively coupled to a computer network ("network") 2030 with the aid of the communication interface 2020. The network 2030 may be the Internet, an intranet and / or an extranet, or an intranet and / or an extranet in communication with the Internet. The network 2030, in some cases, is a telecommunications and / or data network. The network 2030 may include one or more computer servers, which may enable distributed computing such as cloud computing. The network 2030 may, in some cases, implement a peer-to-peer network, which may enable devices coupled to the computer system 2001 to act as clients or servers with the aid of the computer system 2001.

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

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

[0124] The storage unit 2015 may store files such as drivers, libraries, and saved programs. The storage unit 2015 may store user data, such as user preferences and user programs. The computer system 2001 may, in some cases, include one or more additional data storage units external to the computer system 2001, such as located on a remote server that communicates with the computer system 2001 through an intranet or the Internet.

[0125] Computer system 2001 can communicate with one or more remote computer systems through network 2030. For example, computer system 2001 can communicate with a user's remote computer system (e.g., a user device running application 140 of FIG. 1 ). Examples of remote computer systems include a personal computer (e.g., a portable PC), a slate or tablet PC (e.g., an Apple® iPad®, a Samsung® Galaxy Tab), a telephone, a smartphone (e.g., an Apple® iPhone®, an Android-enabled device, a Blackberry®), or a personal digital assistant. A user can access computer system 2001 via network 2030.

[0126] Methods as described herein can be implemented using machine (e.g., computer processor) executable code stored on electronic storage locations of computer system 2001, such as, for example, 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 processor 2005. In some cases, the code can be read from storage unit 2015 and stored on memory 2010 for rapid access by processor 2005. In some situations, electronic storage unit 2015 can be omitted and machine-executable instructions are stored on memory 2010.

[0127] The code can be pre-compiled and configured for use with a machine having a processor adapted to execute the code, or it can be compiled during run-time. The code can be supplied in a programming language that can be selected to allow the code to be executed in a pre-compiled or immediately compiled manner.

[0128] Aspects of the systems and methods provided herein, such as computer system 2001, can be embodied in programming. Various aspects of the present technology may be considered a "product" or "article of manufacture," typically in the form of machine (or processor)-executable code and / or associated data carried on or embodied in some type of machine-readable medium. The 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. A "storage" type medium may include any or all of the tangible memory of a computer, processor, or equivalent, or its associated modules, such as various semiconductor memories, tape drives, disk drives, and the like, which may provide non-transitory storage at any time for software programming. All or portions of the software may be communicated from time to time over the Internet or various other telecommunications networks. Such communication may, for example, enable loading of the software from one computer or processor to another, e.g., from a management server or host computer to an application server computer platform. Thus, other types of media that may bear software elements include optical, electrical, and electromagnetic waves, such as those used across physical interfaces between local devices, through wired and optical fixed networks, and via various air links. Physical elements that carry such waves, such as wired or wireless links, optical links, or the like, may also be considered media bearing software. As used herein, unless limited to non-transitory tangible "storage" media, terms such as computer or machine "readable medium" refer to any medium that participates in providing instructions to a processor for execution.

[0129] Thus, a machine-readable medium such as a computer-executable code may take many forms, including, but not limited to, a tangible storage medium, a carrier wave medium, or a physical transmission medium. Non-volatile storage media include optical or magnetic disks, such as any of the storage devices in any computer or equivalent, such as those that may be used to implement the databases, etc., shown in the figures. 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 optics, including the wires that comprise a bus within a computer system. Carrier wave transmission media may 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 thus include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, DVDs or DVD-ROMs, any other optical media, punch cards, paper tape, any other physical storage media with patterns of holes, RAM, ROM, PROMs and EPROMs, FLASH-EPROMs, any other memory chips or cartridges, carrier waves that transmit data or instructions, cables or links that transmit such carrier waves, or any other medium from which a computer may read programming code and / or data. Many of these forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

[0130] The computer system 2001 may include or communicate with an electronic display 2035 that includes a user interface (UI) 2040 for presenting applications, such as those described with reference to Figures 4-18. Examples of a UI include, but are not limited to, a graphical user interface (GUI) and a web-based user interface.

[0131] The methods and systems of the present disclosure can be implemented using one or more algorithms. The algorithms can be implemented using software for execution by the central processing unit 2005. The algorithms can be, for example, algorithms that implement the process of FIG. 3 for predicting anomalies in a subsystem of the system.

[0132] While preferred embodiments of the present invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. It is not intended that the present invention be limited by the specific examples provided herein. While the present invention has been described with reference to the foregoing specification, the descriptions and illustrations of the embodiments herein are not meant to be construed in a limiting sense. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the invention. Furthermore, it is to be understood that all aspects of the present invention are not limited to the specific depictions, configurations, or relative proportions set forth herein, which depend upon a variety of conditions and variables. It is to be understood that various alternatives to the embodiments of the present invention described herein may be employed in practicing the present invention. It is therefore contemplated that the present invention also covers any such alternatives, modifications, variations, or equivalents. It is intended that the following claims define the scope of the invention, and that methods and structures within the scope of these claims and their equivalents be covered thereby.

Claims

[Claim 1] The invention described in this specification.

Images