Computer system and method for the dynamic construction and online deployment of an operation-centric first-principles process model for predictive analytics

Computer-implemented methods and systems construct a calibrated operation-centric first-principles model suitable for online deployment to monitor, predict, and control real-time plant operations. The methods and systems identify a plant-wide first-principles model configured for offline use and select a modeled operating unit contained in the plant-wide model. The methods and systems convert the plant-wide model to an operation-centric first-principles model of the selected modeled operating unit. The methods and systems recalibrate the operation-centric model to function using real-time measurements collected by physical instruments of the operating unit at the plant. The recalibration may include reconciling flow and temperature, estimating feed compositions, and tuning liquid and vapor traffic flow in the model. The methods and systems deploy the operation-centric model to calculate KPIs (Key Performance Indicators) using real-time measurements. A processor employs the KPIs and automatically predicts and controls behavior of the physical operating unit at the plant.

BACKGROUND

In the process industry, safe and sustainable plant operations, low economic cost, and high operational efficiency have long been goals of performing asset optimization. Process models can serve an important function in assisting plant engineers and operators in optimizing plants operations to meet such desirable goals. The use of process models to drive the complex decision-making required in the process industry is well established. Process models offer many advantages in this complex decision-making, such as helping to organize and structure the vast quantity of plant data being processed, directly relating system outputs to system inputs, offering transparency in functionality, and maintaining explicit representations of their domain.

Most process models can be grouped into one of two major classes: (1) empirical (black-box) models that are usually derived from plant measurements, and (2) first-principles models that encapsulate fundamental physical, chemical, and thermodynamic principles and laws. First-principles models possess many advantages over black-box models. For example, first-principles models are more rigorous, have more predictive power, better handle nonlinearities in the modeled process, and are more reliable in extrapolating into regions beyond their original scope of model construction.

In spite of their many advantages, first-principles models have not been widely used in the process industry to drive the real-time decision making required to operate a plant. Rather, most first-principles models are typically developed for offline uses, such as process design and rating. First-principles models developed for such offline uses are often ill-suited for online use. For example, these offline models are not structured to support easy calibration, lack instrumentation information, and do not reflect the control or operating objectives of the plant operations, as required for online model use. For further example, these offline models are not aligned with the physical dimensions of the actual (physical) plant equipment that they represent, are not designed for multiple modes of operation, and are not amenable to quick solutions by a modeling algorithm, as also required for online model use.

In the process industry, one type of online application that may use a first-principles model is real-time optimization (RTO). In this application, the focus is typically on plant-wide operations, and the goal is usually to make process adjustments that enable the whole plant to reach an optimal steady-state. For this application, a first-principle model may be suitable because the resolution needed for the application is relatively low since a wide operating range is required for the application. In contrast, for an operation-centric (single unit operations) application, a first-principles model is typically not suitable because the application requires high fidelity to provide accurate predictions of various properties of the plant process and real-time operational transparency of the plant process. Additionally, a first-principles model is typically not suitable for an operation-centric application because such application requires a model to closely match plant measurements in real-time and be scalable for both hydraulic and thermodynamic calibrations. The numerous requirements for online and operation-centric modeling applications make using a first-principles model for these applications a challenge in the process industry.

SUMMARY OF THE INVENTION

Embodiments of the present invention address the challenges of using a first-principles model for online and operation-centric applications in the process industry. The embodiments are directed to automatically constructing, calibrating, and deploying online a first-principles model for use in operation-centric applications. The embodiments begin with a first-principles model (source model) encompassing a wide process scope (e.g., plant-wide scope) and developed for offline purposes, such as design or rating of the plant process. The embodiments dynamically transform this source model of wide process scope into a resulting calibrated operation-centric first-principles model (of operating unit scope). The calibrated operation-centric model is configured for a single operating unit (e.g., a distillation column, heat exchanger, reactor, and the like) of a plant and functional for online deployment to drive real-time decision making in operating the plant. In this way, plant operations (maintenance and control thereof) are automated with minimal to no human intervention at times.

The calibration performed by the embodiments to transform the source model includes flow and temperature reconciliations. These reconciliations enable the resulting operation-centric model to be driven by plant measurements collected from physical flow and temperature instruments of the operating unit at the plant. In this way, these reconciliations enable the operation-centric model to support real-time performance monitoring, predictive analytics, and automated controlling of the plant. The calibration performed by the embodiments on the operation-centric model further includes building a feed estimator used to estimate compositions of feed streams entering the modeled operating unit. An example of an operating unit of the plant included in the embodiments is a distillation column. The performance of the distillation column (and other similar operating units) is governed by the internal liquid and vapor flows within the distillation column. For the distillation column, the calibration performed by the embodiments on the operation-centric model further includes tuning the hydraulic model of the operation-centric model.

The embodiments deploy the calibrated operation-centric model online, where the operation-centric model calculates key process indicators (KPIs) for the modeled operating unit in real time. The deployed and calibrated unit process model calculates KPIs used to monitor, predict, and control the real-time operations of the modeled operating units. For the example of a distillation column operating unit, the operation-centric model calculates KPIs related to flows, temperatures, pressures, impurities of product streams, flooding percentage, vapor flowrate of critical states within the column, liquid flowrate of critical stages within the column, the overall mass balance of the column, and the temperatures at different column stages. Using the calculated KPIs, the embodiments provide accurate and real-time process information to plant control systems and personnel (e.g., plant operators, plant engineers, and the like) to enable real-time performance monitoring, predicting, and controlling of the plant operations.

Example embodiments are directed to computer systems, methods, and program products for generating an online unit process (operation-centric) model. The computer systems comprise at least one processor and memory with computer code instructions stored thereon. The memory is operatively coupled to the processor such that, when executed by the processor, the computer code instructions cause the computer system to implement a model converter, a model calibrator, and a deployment engine. In some embodiments, the computer code instructions further cause the computer system to implement the model calibrator to include a dataset creator, a flow reconciliation module, a temperature reconciliation module, a feed-estimator builder, and a hydraulic model. The computer program products comprises a non-transitory computer-readable storage medium having code instructions stored thereon. The storage medium is operatively coupled to a processor, such that, when executed by the processor, the computer code instructions cause the processor to generate the online unit process model.

The computer methods, systems (via the model converter), and program products identify a plant-wide process model of an industrial plant. The plant-wide process model is configured to perform offline operations of the industrial plant. In example embodiments, the plant-wide process model is a first-principles model. The computer methods, systems, and program products select a modeled operating unit contained in the plant-wide process model. The selected modeled operating unit corresponds to a physical operating unit at the industrial plant, such as a distillation column.

The computer methods, systems, and program products convert the plant-wide process model to a unit process (operation-centric) model of the modeled operating unit. In example embodiments, the converted plant-wide process model is a first-principles model. In some embodiments, the computer methods, systems, and program products convert the plant-wide process model by removing variables and equations unrelated to the selected modeled operating unit. In these embodiments, the computer methods, systems, and program products next update the plant-wide process model to replace the specification of the selected modeled operating unit with standard specification for the modeled operating unit, and converts its calculation basis to a standard form. In these embodiments, the computer methods, systems, and program products then reconfigure the process variables of the selected modeled operating unit. In some of the embodiments, the computer methods, systems, and program products reconfigure the process variables by identifying manipulated variables (MVs) and output variables (OVs) of the selected modeled operating unit and mapping each identified MV and OV to at least one instrument tag. In these embodiments, the computer methods, systems, and program products further define control loops of the selected modeled operating unit. The defined control loops identify the operating objectives of the selected modeled operating unit. In some embodiments, the computer methods, systems (via the model calibrator), and program products apply the unit process model to generate a rule engine that provides a user prescriptive guidance (e.g., via an alert score) on an event of the physical operating unit.

The computer methods, systems (via the model calibrator), and program products next recalibrate the unit process model to enable the unit process model to perform based on real-time measurements collected by instruments of the physical operating unit. In some embodiments, the computer methods, systems (via the dataset creator of the model calibrator), and program products create a dataset based on plant data retrieved from a real-time plant historian. The created dataset comprises a subset of the plant data collected at steady-state during a calibrated time horizon.

In some embodiments, the computer methods, systems (via the flow reconciliation module of the model calibrator), and program products reconcile modeled flow in the unit process model, which enables the unit process model to perform using measurements collected by physical flow instruments at the industrial plant. In some embodiments, the computer methods, systems (via the temperature reconciliation module of the model calibrator), and program products also reconcile modeled temperature in the unit process model, which enables the unit process model to perform using measurements collected by physical temperature instruments at the industrial plant. In these embodiments, the computer methods, systems (via the feed-estimator builder of the model calibrator) next build a feed estimator that enables the unit process model to estimate compositions of feed streams entering the selected operating unit. In some embodiments, if the selected modeled operating unit is a distillation column, the computer methods, systems (via the hydraulic model turner of the model calibrator) further tune a hydraulic model that represents internal liquid and vapor traffic flow of the distillation column in the unit process model.

In example embodiments, the computer methods, systems, and program products reconcile the modeled flow and modeled temperature by selecting expected errors in the respective physical instruments and dividing the plant data of the dataset into a training set and a test set. In these example embodiments, the computer methods, systems, and program products next generate optimization models for each data point in the training set and solve the optimization models to determine calibration parameters for the modeled flow or modeled temperature. In these example embodiments, the computer methods, systems, and program products then generate simulation models for each data point in the test set and solve the generated simulation models to determine quality of the determined calibration parameters. The calibration parameters of the modeled flow in these example embodiments may include flow offsets that represent the difference between measured flow by the physical flow instrument and flow calculated by the unit process model. Further, the calibration parameters of the modeled temperature in these example embodiments may include an efficiency parameter that represents degree of separation between measured temperature by the physical temperature instrument and temperature calculated by the unit process model, and an aeration parameter that represents whether measured pressure drop across the physical operating unit matches pressure drop calculated by the unit process unit.

The computer methods, systems (via the deployment engine), and program products then deploy the calibrated unit process model online in a plant process. To do so, the computer methods, systems, and program products calculate key process indicators (KPIs) based on real-time measurements collected by the instruments of the physical operating unit. The KPIs are used to monitor, predict, and control operational behavior of the physical operating unit at the industrial plant. In some example embodiments, the computer methods, systems, and program products deploy the unit process model by generating a dynamically executable version of the unit process model, which creates variables that link real-time measurements by the instruments of the physical operating unit to corresponding values calculated by the unit process model. The computer methods, systems, and program products next retrieve real-time measurements of the physical operating unit to set the linked variables associated with real-time measurements in the model. The computer methods, systems, and program products then solve the dynamically executable version of the unit process model, which sets linked variables associated to calculated model values and determines values for KPIs of the modeled operating unit. The computer methods, systems, and program products write the determined KPIs to a real-time historian for access by plant computers configured to predict and control the physical operating unit based on the KPIs. The computer methods, systems, and program products communicate with a control system computer to control the physical operating unit according to the predicted operational behavior of the physical operating unit.

DETAILED DESCRIPTION OF THE INVENTION

Over the last three decades, significant efforts have been expended to deploy first-principles models online for uses such as real-time optimization and advanced process control (APC). Previous approaches to deploying first-principles models for such uses required manual, lengthy, and expensive model configuration and always involved expert intervention. These previous approaches often required weeks to months of time by a seasoned process engineer (expert) to build, calibrate, and deploy a first-principles model for use in a plant process. Thus, implementing a first-principles model online (particularly for operation-centric applications) with minimal effort is an important goal of plant operators and engineers.

Embodiments of the present invention are directed to computer methods, systems, and program products that provide several advantages in implementing first-principles models over previous approaches. For example, these embodiments encompass better technology that enables building, calibrating, and online deploying of the model, support improved workflows in the model, automate best practices in the model, and assist in management of the model over its entire lifecycle. Further, these embodiments do not require that an online first-principles model be constructed as a new model, but rather enables the creation of the model from an existing offline process model of a different scope. This leveraging of existing offline models is important in the process industry because many plants have invested tremendously in developing large collections of existing process models for different offline purposes.

System for Building, Calibrating, and Deploying Unit Process Model

FIG. 1is a block diagram depicting a computer system100configured to build, calibrate, and deploy online a unit process (operation-centric) model in embodiments of the present invention. The computer system100is configured within the network infrastructure of an industrial, chemical, or other such plant. The computer system100includes one or more computers (e.g., application servers) configured to execute a model converter140, a model calibrator150, and a deployment engine160. The computer system100also includes a user interface (e.g., graphical user interface)110configured on a display device, and a centralized data store (databases)130coupled to a data server135. The computer system further includes a distributed control system170configured with an instrumentation, control, and operation computer175communicatively coupled to instrument devices180A-1801, such as sensors, meters, probes, valves, actuators, gages, heaters, and the like, that physically measure and control an operating unit at the plant. The user interface110, centralized data store130(via data server135), model converter140, model calibrator150, deployment engine160, and distributed control system175are communicatively coupled within the computer system100via a plant network120.

The computer system100is configured to dynamically build, calibrate, and deploy online a unit process model that drives real-time decision making regarding a physical operating unit at an industrial, chemical, or other such plant. The model converter140of the computer system100builds the online unit process model from a plant-wide process model (source model). The source model may be a first-principles process model of the plant-wide operations. To build the unit process model, the model converter140displays to the user on the user interface110(via the plant network120) an option to select a source model. For example, the model converter140may provide a field on the user interface110for the user to specify a source model. For another example, the model converter140may retrieve a list of source models by querying the centralized data store130or another reachable location within the plant network120. The model converter140may then display the list of source models on the user interface110in a format that enables the user to select one of the source models. The selected source model may be configured in the form of a flowsheet, or other structured format, which includes unit operations of the modeled process and the material, energy, and information flow among the unit operations.

After the user selects a source model, the model converter140displays to the user on the user interface110the modeled operating units (unit operations) contained in the source model, such as a distillation column, heat exchanger, reactor, and the like. Each modeled operating unit corresponds to a physical operating unit at the plant. To do so, the model converter140may read the selected source model from the centralized data store130or another reachable location within the plant network120. The model converter140may then display the modeled operating units of the read source model on the user interface110in a format that enables the user to select an operating unit of interest. The model converter140may also display the operating units within the read source model on the user interface110in a graphical representation, list representation, spreadsheet representation, or other such representation depicting the dependencies between the unit operations.

After the user selects a unit operation, the model converter140converts the source model into a unit process (operation-centric) model of the selected modeled operating unit. The model converter140displays the converted unit process model on the user interface110in a format that enables the user to map key process variables (e.g., manipulated variables, output variables, and the like) to instrument tags for the selected modeled operating unit. The model converter140further displays the converted unit process model on the user interface110in a format that enables the user to configure control loops in the unit process model to indicate the operating objectives of the selected modeled operating unit. The model converter140then stores the converted unit process model structured in computer memory, such as in a configuration file. For example, the model converter140may store the converted unit process model as a configuration file in the centralized data store130or another reachable location within the plant network120.

Once the unit process model is built, the model calibrator150calibrates the unit process model. To perform the calibration, a dataset creator component of the model calibrator150first creates a calibration dataset for use in reconciling the unit process model. The dataset creator provides the user an option at the user interface110to calibrate a time horizon for the dataset. The data creator then retrieves plant data from a real-time plant historian (located at the centralized data store130or another location on the plant network120) in the calibrated time horizon. The data creator (of the model calibrator150) retrieves plant data that corresponds to the mapped instrument tags and selects a subset of the retrieved plant data representing steady-state behavior of the plant process as the calibration dataset.

A flow reconciliation module of the model calibrator150then uses the created dataset to reconcile the modeled flow. The flow reconciliation module calculates flow offsets (calibration parameters) for modeling the product streams entering the modeled operating unit. The calculated flow offsets define the difference between a flow measurement by a flow instrument (e.g., one or more of180A-180E) of the physical operating unit at the plant and a corresponding flow value calculated by the unit process model. The temperature reconciliation module of the model calibrator150similarly uses the created dataset to reconcile the modeled temperature. In the example of the modeled operating unit being a distillation column, the temperature reconciliation module calculates calibration parameters comprising efficiency and aeration parameters of the modeled operating unit. The efficiency parameter represents the degree of separation between a temperature measured by instruments (e.g., one or more of180A-180E) of the physical distillation column at the plant and a corresponding temperature value calculated by the unit process model. The aeration parameter represents whether the measured pressure drop across the distillation column at the plant matches the pressure drop calculated by the unit process model. By reconciling the modeled flow and temperature, the unit process model can perform at steady-state using measurements collected by physical flow and temperature instruments (e.g., one or more of180A-180E) of the physical operating unit at the plant.

A feed-estimator builder of the model calibrator150next builds a feed estimator to estimate the compositions of the feed streams entering the physical operating unit (modeled by the unit process model). The feed-estimator builder updates the created calibration dataset for the unit process model with the estimated feed compositions and again reconciles (flow and temperature) of the unit process model using the updated dataset. If the operating unit is a distillation column (or similar unit), a hydraulic model tuner of the model calibrator150then represents liquid and vapor traffic at each stage of the distillation column. The hydraulic model tuner calculates values for the adjustable parameters (e.g., system foam factor and such) that enables the hydraulic model to accurately predict the zone (e.g., stable operation zone, unstable operation zone, and a problem operation zone) in which a given stage within the distillation column is operating. The model calibrator150may update the stored configuration file of the converted unit process model in the centralized data store130or another reachable location within the plant network120with the calibration parameters.

Once the unit process model is calibrated, the deployment engine160deploys the unit process model online. To do so, the deployment engine160reads the configuration file storing the calibrated unit process model, and associates the configuration file with real-time plant data to dynamically execute the model online. The deployment engine160retrieves the real-time plant data from the real-time plant historian located in the centralized data store130(via the data server135) or another location on the plant network120. The real-time plant data is collected in real-time by the instrumentation, control, and operation computer175from physical instruments (e.g., a subset of108A-108I) of the plant network120and written to the real-time plant historian for retrieval by other plant computers, such as the computer configured with the deployment engine160. The deployment engine160associates the online unit process model to link with the retrieved real-time plant data and solves the online unit process model to compute values for KPIs of interest, which are written to the real-time plant historian130. From the real-time plant historian130, plant computers, such as the instrumentation, control, and operation computer175may access the KPI values to perform real-time monitoring and predictive analytics of the operations of the modeled operating unit. Based on the monitoring and predictive analytics, the instrumentation, control, and operation computer175may program plant instruments (e.g., a subset of108A-108I) to settings that optimize, or otherwise control, operations of the modeled operating unit or other operating units of the plant. The instrumentation, control, and operation computer175may also provide data on the monitoring and predictive analytics to plant operators, or other plant personnel, via the user interface110to take actions to optimize or otherwise control operations of the model operating unit or other operating units of the plant.

Example User Interface Screens

FIGS. 2-4are schematic views depicting example user interface screens200-400employed in embodiments of the present invention. The model converter140may display the example user interface screens200-400to the user as part of the process of building a unit process model.FIG. 2illustrates an example user interface screen200for generating a unit process first-principles model from a source model (plant-wide first-principles process model). The example user interface screen200enables a user to provide a name205for the unit process model and provide a description220related to the unit process model. The example user interface screen200further enables the user to select a source model210for conversion to the unit process model. The example user interface screen200graphically displays the selected source model230, including displaying operating units235,240,245, etc of the source model and the material, energy, and information flows among the operating units235,240,245, etc.

The user may select one of the displayed operating units235,240,245, etc of the displayed source model230for conversion to the unit process model. To do so, the user chooses a label (e.g., T-C1, T-C2, T-C3, and such) associated with the operating unit from the drop down list215. For example, inFIG. 2, the user selects the label T-C3 associated with a distillation column operating unit from the drop down list215. The user interface screen200displays to the user the equipment name225corresponding to the selected operating unit associated with the chosen label. The example user interface screen200provides an option (not shown), such as a button or any other graphical selector, for the user to initiate the conversion of the source model to a unit process model for the selected modeled operating unit.

FIG. 3illustrates an example user interface screen300for mapping instrument tags to key process variables (manipulated variables and output variables) of the operating unit in the generated unit process model. As shown inFIG. 3, the example user interface screen300presents the user the key manipulated variables (Column Pressure, Feed Flowrates [i.e., “TC2SF Flowrate” inFIG. 3], Product Flowrates [i.e., “Distillate Vapor Flowrate” and “Distillate Liquid Flowrate” inFIG. 3], and such) of the distillation column operating unit displayed in the unit process model. The example user interface screen300further provides the user instrument tags (PU-8706, FU-8610, and such) that the user may drag to map to the manipulated variables.

FIG. 4illustrates an example user interface screen400for mapping control loops to the operating unit in the generated unit process model. As shown inFIG. 4, the example user interface screen400presents the user the control loops (Product Composition, Tray Temperature [i.e., “Overhead Composition” and “Bottoms Composition” inFIG. 4], and such) of the distillation column operating unit displayed in the unit process model. The control loops are defined by a pair of process variables (a manipulated variable and a controlled variable) of the operating unit. The example user interface screen300further provides the user instrument tags (PU-8706, FU-8610, and such) that the user may drag to map the control loops to operating objectives of the modeled operation unit.

Method of Building Unit Process Model

FIG. 5is a flow diagram depicting a computer-implemented method500of building a unit process model in embodiments of the present invention. In some embodiments, the model converter140ofFIG. 1executes the method500to build the unit process model. The method500begins at step510.

At step520, the method500selects a process model (source model) for an industrial, chemical, or other such plant. In some embodiments, the method500(step520) enables a human or system user to select the source model via the user interface110. In other embodiments, the method500(step520) may automatically select the source model based on programmed criteria, parameters accessed from the centralized data store130, or communication with operating devices (e.g.,175and108A-108I ofFIG. 1) in the plant network120. The selected source model is a first-principles model (encompassing wide plant process scope) developed and configured for offline use, such as for design or rating of the plant operations. The selected model contains operating units (e.g., distillation columns, and the like) of the modeled plant process and the material, energy, and information flows among the operating units. In some embodiments, the process model may include only the key (major) operating units of the plant process.

The method500, at step530, identifies the modeled operating units contained within the source model. Each modeled operating unit corresponds to a physical operating unit at the plant. For example, the method500(step530) may access the selected source model from a centralized data store130or other reachable location in the plant network120to identify its operating units. The method500(step530) may then read, parse, search, or otherwise process the accessed source model to identify the modeled operating units, and corresponding information, of the selected source model. In some embodiments, the method500(step530) may display the operating units to the user on the user interface110, along with an option for selecting one or more of the modeled operating units. For example, the model converter140may present the modeled operating units to the user within a graphical representation of the source model (such as shown inFIG. 2), in a list representation, in a flowsheet representation, or any other structured representation without limitation.

The method500, at step540, selects a modeled operating unit of interest from the identified modeled operating units. In some embodiments, a human or system user may select the modeled operating unit using the selection option (e.g.,215ofFIG. 2) on the user interface110. In other embodiments, the method500(step540) may automatically select the source model based on programmed criteria, parameters stored in the centralized data store130, or communication with operating devices (e.g.,175and108A-108I ofFIG. 1) in the plant network120. Once the method500(step540) selects the operating unit of interest, the method500, at step550, generates an offline version of a unit process model for the selected modeled operating unit.

The method500, at step550, generates an offline unit process model by converting the source model (of wide plant scope) into a model centric to only the selected modeled operating unit. To perform this conversion, the method500(step550) first automatically reduces the scope of the source model to the scope (level) of the selected modeled operating unit by discarding information from the model not directly relevant to the selected modeled operating unit. For example, if there are multiple operating units in the process, the method500(step550) excludes all information (process variables, equations, and the like) pertaining to the other modeled unit operations (i.e., not pertaining to the selected modeled operating unit). Next, the method500(step550) automatically replaces the existing specifications for the selected modeled operating unit with a set of standard specifications for the modeled operating unit. The replaced specifications may include design, operating, pressure, efficiency, and any other such standard specifications for the selected modeled operating unit. The method500(step550) also converts the calculation basis in the source model to a standard calculation form. For example, if the source model is configured in a molar or volumetric basis, the method500(step550) automatically converts the model to a mass basis. The standard specifications and standard calculation form for the selected modeled operating unit may be retrieved from the centralized data store130or other location on the plant network120. Further, if the selected operating unit is a distillation column, the method500(step550) creates internal column sections (calibration variables) in the unit process model to support accurate calibration of the model.

The method500, at step560, maps instrument (production) tags to key process variables of the unit process model. In other embodiments, other methods may be used to map instruments (components) of the modeled operating unit to key process variables in the unit process model. To do so, the method500(step560) retrieves key process variables for the operating unit from the generated unit process model. These process variables comprise two types of process variables: manipulated variables (MVs) and output variables (OVs). The MVs are input variables that need to be set to solve the unit process model. The OVs are output variables of the unit process model that are calculated based on measurements taken by instruments of the physical operating unit. The OVs may include output stream flow variables used to calculate a mass balance around the modeled operating unit, output tray temperature variables that are useful in determining whether the model is an accurate representation of the actual (physical) plant operation, and the like. The method500(step560) also retrieves instrument tags for the modeled operating unit from a plant data historian (e.g., in the centralized data store130) and maps these instrument tags to the retrieved key process variables. In some embodiments, the method500(step560) presents the retrieved instrument tags and process variables to the user on user interface110, and enables the user to position (e.g., drag) the instrument tags to the process variables (such as shown inFIG. 3).

The method500(step560) performs these mappings of instrument tags because the source model being used to seed the configuration of the unit process model is often developed on a theoretical basis. As such, the method500(step560) performs the instrument tag mappings to align the unit process model to the actual physical configuration of the operating unit at the plant. If the source model was developed on an actual basis, the method500may omit step560as the unit process model is already aligned to the actual (physical) operating unit configuration.

The method500, at step570, specifies operating objectives for the modeled operating unit of the unit process model. To do so, the method500(step570) maps instrument (production) tags to control loops that indicate the operating objections of the modeled operating unit. In other embodiments, other methods may be used to map instruments (components) of the modeled operating unit to control loops in the unit process model. Each control loop is defined by a pair of variables: a MV and a controlled variable (CV). The method500(step560) generates a standard set of control loops for the modeled operating unit. The method500further retrieves instrument tags for the modeled operating unit from a plant data historian (e.g., in the centralized data store130) and maps these instrument tags to the generated control loops. The mapping of these instrument tags identifies which control loops are present on the actual operating unit in the plant to indicate the operating objectives of the modeled operating unit. In some embodiments, the method500(step560) presents the retrieved instrument tags and control loops to the user on user interface110, and enables the user to position (e.g., drag) the instrument tags to the control loops (such as shown inFIG. 4).

The method500, at step580, saves the generated unit process model (including mapped process variables and control loops) to a configuration file in memory on the plant network120(e.g., in the centralized data store130). This saved version of the unit process model is referred to as the offline version. The method500of building the unit process model ends at step590.

Method of Calibrating Unit Process Model

FIG. 6Ais a flow diagram depicting a computer-implemented method600of calibrating a unit process model in embodiments of the present invention. The method600may be used to calibrate the unit process model generated by method500ofFIG. 5. In some embodiments, the model calibrator150ofFIG. 1executes the method600to build the unit process model. In the embodiment ofFIG. 6A, the unit process model is a first-principles model. The method600calibrates the unit process model to function online to drive real-time decision making at the plant in relation to the modeled operating unit. As part of the calibration, the method600reconciles components of the unit process model to enable the model to perform online using measurements collected in real-time from physical instrumentation (e.g.,108A-108I ofFIG. 1) at the plant. In this way, the reconciled unit process model can accurately monitor and predict the plant operations related to the operating unit at the plant. The online model, in turn, can output accurate and real-time predictive analytics on the modeled operating unit to plant control systems (e.g., computer175ofFIG. 1) and plant personnel (e.g., plant engineers, operators, and the like).

Create Model Dataset

The method600begins at step605. At step610, the method600reads the configuration file for a unit process model. In some embodiments, the unit process model was generated by method500and the configuration file saved at step580of method500. The method600, at step615, reads (initializes) base feed compositions of the feed streams entering the operating unit modeled by the unit process model. The method600(step615) may read the base feed compositions of the modeled operating unit from the source model that was used to build the unit process model (as described in reference toFIG. 5). The method600(step615) may compute a feed composition range for each key component of the modeled operating unit as a percentage above and below the base feed composition.

The method600, at step620, retrieves plant data for calibrating the unit process model from the real-time plant historian, which may be located in the centralized data store130or another location in the plant network120. The method600(step620) queries and retrieves plant data from the plant historian corresponding to the instrument tags mapped to the unit process model (at steps560-570). The method600(step620) retrieves the plant data from the plant historian for a calibrated time horizon (e.g., time horizon selected by a user at user interface110). The method600(step620) further determines the maximum and minimum values (value range) for each MVs of the operating unit from the retrieved plant data.

The method600, at step625, creates a dataset for use in reconciling the unit process model. In some embodiments, a dataset creator component of the model calibrator150may execute steps610-625of method600. To create a functional dataset, the method600(step625) first conditions the plant data of the calibrated time horizon retrieved from the plant historian (step620). In some embodiments, the method600(step625) performs interpolation to condition the plant data, which provides control over the exact time horizon (timestamp) of plant data queries/retrieved from the plant historian. The method600(step625) then performs a rolling average over the interpolated plant data to create the dataset. The created dataset may be used in subsequent steps of method600, both for determination of steady-state regions and model generation.

For each data point of the conditioned plant data, the method600(step625) computes a mass balance around the operating unit and corresponding mass balance error (MBE) in the unit process model. The method600(step625) computes the mass balance as the sum of all outlet mass flow rates minus (−) the sum of the inlet mass flow rate, and computes the MBE as the mass balance normalized by the sum of the inlet flow rates. The method600(step625) then identifies time regions of steady-state behavior within the calibrated time horizon (calibration window). As shown in theFIG. 6B, the method600(step625) examines the statistics of the mass balance error over the calibration window. The method600classifies each data point in the calibration window as potentially existing in a steady-state cluster, if the mass balance error of the data point is within a steady-state band defined by the mass balance average and deviation. For a time region of the time horizon window to be considered as a steady state cluster, it must contain n consecutive data points (where n is a configurable parameter) that have a MBE that falls within Average MBE−standard deviation of MBE<MBE<Average MBE+standard deviation of MBE. The method600(step625) then selects a subset (system configurable parameter) of the data points within the identified steady-state regions to create the dataset. The data points are chosen so that the number of steady-state regions sampled is maximized, with the longest consecutive steady-state time regions being given the highest sampling priority.

Flow Reconciliation

The method600, at step630, uses the created dataset to reconcile the modeled flow in the unit process model. The reconciliation enables the unit process model to perform (be driven) using measurements collected in real-time by physical flow instruments of the modeled operating unit (or other operating unit) at the plant. In some embodiments, a flow reconciliation module of the model calibrator150may execute step630. Flow reconciliation of the unit process (first-principles) model involves calculating calibration parameters for the model, such that the model can be used as an accurate proxy of the modeled operating unit when the plant system is at steady state. The calibration parameters for flow reconciliation are the flow offsets for the product streams entering the operating unit. A flow offset is the difference between the measured flow value by a physical flow instrument of the operating unit at the plant and the flow value calculated by the unit process model (i.e. flow offset value=observed plant value−model predicted value). In order for the method600(step630) to perform flow reconciliation, the feed compositions of these product streams must be known. However, a feed estimator is required to calculate the feed compositions, but a feed estimator can only be built if a reconciled unit process model (first-principles) model is already available. To handle the dependency between flow reconciliation and the building of a feed estimator, the method600initialized the feed compositions from the source model (at step615) prior to performing flow reconciliation.

To calculate calibration parameters (flow offsets) for flow reconciliation, the method600(step630) divides (groups) the data points of the dataset created in step625into a training set and a test set to maximize the range of test and training points over the calibration window. The method600(step630) may maximize the range by use of a steady-state detector that maximizes variations in the steady state clusters determined in step625. The steady-state detector should ideally: (1) maximize the number of unique steady-states utilized for calibration of the model and (2) provide steady-state clusters which span the entire calibration window. The method600(step630) provides logical improvements to a steady-state detector in embodiments of the present invention. To do so, the method600(step630) prioritizes steady-state cluster selection based upon distance between steady-state points. In embodiments, the fraction of points which are used as training points is a system configuration parameter.

The method600(step630) then determines expected errors in the flow instruments of the modeled (physical) operating unit. In some embodiments, a user may configure the expected errors in the flow instrument via user interface110. The method600(step630) next generates first principles models for all the points in the training set in view of the determined expected errors and solves an optimization computation on the first principle model, where the errors between the plant measurements and model variables are minimized. The calibrated parameters of a generated first principles model includes flow offsets between the plant and model variables, as well as, other first principles model parameters (e.g. efficiency in the case of a distillation column model). The method600(step630) repeats the generating/solving of the optimization models for multiple training runs. The method600(step630) calculates the average value of each flow offsets over all of the training runs, and sets the calibration parameters to the calculated average values of the flow offsets.

The method600(step630) next generates simulation models for all the points in the test set in view of the determined expected errors. The generated simulation models incorporate the calibrated parameters found in steps630and635of method600. The method600further solves the generated simulation models (with the calibration parameters fixed) to determine the quality of the calibration parameters (average flow offsets). The generating/solving of the optimization models is repeated for multiple test runs. That is, the test runs, which are executed after the completion of the training runs, use the determined calibration parameters and estimated quality to generate data (model predictions) which are in turn presented to the user (e.g., human or system), along with the actual plant values, so that the user may judge the quality of the calibrated model.

Temperature Reconciliation

The method600, at step635, uses the created dataset (step625) to reconcile the modeled temperature in the unit process model. The reconciliation enables the unit process model to perform (be driven) using measurements collected in real-time by physical temperature instruments of the modeled operating unit (or other operating unit) at the plant. In some embodiments, a temperature reconciliation module of the model calibrator150may execute step635. Temperature reconciliation of the unit process (first-principles) model, similar to flow reconciliation (step630) of the model, involves calculating calibration parameters for the model, such that the model can be used as an accurate proxy of the modeled operating unit when the plant system is at steady state. When the modeled operating unit is a distillation column, the calibration parameters are the efficiency and aeration parameters (variables) for the modeled operating unit. The model600(step635) sets the efficiency parameter as a degree of freedom which is moved by the computational engine during a solve set to minimize errors between the plant measurements and model predictions.

The method600(step635) calculates a value for the aeration parameter that enables the calculated column pressure drop to match the measured pressure drop across the physical distillation column at the plant. The method600(step635) performs the calculation within the first principle model by first introducing a new model variable representing the difference between the model predicted bottom stage pressure and the model predicted top stage pressure (i.e., the model predicted column pressure drop variable). The method600(step635), next, simultaneously changes the specification of the aeration parameter from fixed to calculated, and the specification of the model predicted column pressure drop variable from calculated to fixed. The method600(step635), then, equates the model predicted column pressure drop variable to the observed pressure drop in the plant.

To calculate calibration parameters for temperature reconciliation, the method600(step635) divides (groups) the data points of the dataset created in step625into a training set and a test set. The method600(step635) may maximize the range by use of a steady-state detector that maximizes variations in steady state clusters determined in step625(as shown inFIG. 6B). To do so, the method600(step635) prioritizes steady-state cluster selection based upon distance between steady-state points. The method600(step630) then determines expected errors in the temperature instruments of the modeled (physical) operating unit. In some embodiments, a user may configure the expected errors in the temperature instrument via user interface110. The method600(step635) next generates first principle models for all the points in the training set in view of the determined expected errors. Then method600(step635) solves an optimization computation on the first principle model, where the errors between the plant measurements and model variables are minimized to determine the calibration parameters, including the efficiency and aeration parameters (in the case where the operating unit is a distillation column). The method600(step635) repeats the generating/solving of the optimization models for multiple training runs. The method600(step635) calculates the average value over all of the training runs, and sets the calibration parameters to the calculated average values.

The method600(step635) next generates simulation models for all the points in the test set in view of the determined expected errors. The method600further solves the generated simulation models to determine the quality of the calibration parameters. The generating/solving of the optimization models is repeated for multiple test runs. That is, the test runs, which are executed after the completion of the training runs, use the determine calibration parameters to estimate the quality of the results from the optimization model. The generating/solving of the optimization models is repeated for multiple test runs. That is, the test runs, which are executed after the completion of the training runs, use the determined calibration parameters and estimated quality to generate data (model predictions) which are in turn presented to the user (e.g., human or system), along with actual plant values, so that the user may judge the quality of the calibrated model.

The method600, at step640, builds a feed-estimator in the unit process model. In some embodiments, a feed-estimator builder component of the model calibrator150may execute step640. The method600(step640) builds the feed estimator to estimate the compositions of the feed streams entering the physical operating unit (being modeled by the unit process model) at the plant. The method600(step640) uses the reconciled unit process model (output from630-635) to generate a feed-estimator dataset that is used to build the feed estimator. To generate the feed estimator dataset, the method600(step640) uses: (i) the feed composition range for each key operating unit component, as determined in step610, and (ii) the range for each MVs of the operating unit over the calibrated time horizon, as determined in step620.

Step640of method600combines two algorithms (Sobol Sequences and Random Forest) in a novel way. First, the method600(step640) generates a normalized set of unstructured sampling points via the Sobol Sequence Generator algorithm for a multidimensional unit cube with low discrepancy Sobol numbers, see, e.g., S. Joe and F. Y. Kuo,Remark on Algorithm659: Implementing Sobol's quasirandom sequence generator, ACM Trans. Math. Softw. 29, 49-57 (2003), herein incorporated by reference in its entirety. Further, see, e.g., http.//web.maths.unsw.edu.au/˜fkuo/sobol/ (2010), herein incorporated by reference in its entirety, where the cube dimensions are comprised of the feed composition variables and MVs. Embodiments of method600(step640) provide an optimal or nearly optimal placement of sampling points by the Sobol Sequence Generator algorithm, irrespective of the number of points chosen.

The method600(step640) then uses the set of input values to solve the reconciled unit process (first-principle) model generated in steps630-635. The method600(step640) uses each operating point of the above generated Sobol Sequence as input values to solve a different instance of the reconciled unit process (first-principle) model to generated in steps630-635to collect a set of process model predicted output variables (OV) data, where the OVs correspond to model predictions of plant measurements which are mapped by the user. These sets of input values and output values, in aggregate, comprise the feed estimator dataset, which are used to build the Random Forest feed estimator model for the unit process model. The method600, at step645, further estimates feed compositions of the modeled operating unit using the feed-estimator dataset.

To build the Random Forest feed estimator model, the method600(step465) calls the Random Forest Regressor, see, e.g., http://scikit-learn.org/stable/modules/generated/sklearn.ensemble.RandornForestRegressor.html (2010), herein incorporated by reference in its entirety. The method600may compute parameters of the random forest algorithm, e.g., as shown in scikit-learn: machine learning in python, http://dl.acm.org/citation.cfm?id=2078195 (2011), herein incorporated by reference in its entirety, where the input for Random Forest Regressor is the manipulated (MVs) and output variables (OVs) from the process unit operation model. Using these computed parameters, method600(step645) executes the random forest algorithm to estimate the feed compositions of the unit process model based on measurements read at the physical operating unit. In this regard, the method600essentially performs an inverse function to the reconciled unit process (first-principles) model generated at steps630-635over a space that is spanned by low discrepancy Sobol numbers. The method600uses the estimated feed compositions to update the created dataset from step625. The method600, at step560, determines that the reconciliation results are not yet stable, and using the updated dataset, repeats steps630-645until the reconciliations results are stable. Once the method600(step645,560) determines that the reconciliation results are stable, the method600proceeds to step650.

In some embodiments, a feed-estimator builder may encounter a feed composition where the available temperature/pressure/analyzer sensors in a distillation column that are directly affected by changes in the feed composition are smaller than the number of feed components to be estimated. In this situation, the method600(step645) lumps similar feed components before conducting feed estimation. The lumping approach conducts a principal component analytics (PCA) on the sensitivity matrix from the calibrated unit process model that contains the partial derivatives of the sensor values with respect to the feed component values. The distance between the feed components in the PCA analysis provides a quantitative assessment of the degree of similarity. If two feed components are very similar, these components should be lumped. Once the lumping is complete, the feed estimation process can be conducted. Once the feed estimation process is complete in terms of the lumped feed components, the components must be de-lumped in the same ratios as originally provided in the unit process model.

Hydraulic Model Tuning

For a unit process model representing a distillation column operating unit, the method600, at step650, also tunes the hydraulic model of the unit process model. In some embodiments, a hydraulic model tuner component of the model calibrator150may execute step650. The hydraulic model represents the liquid and vapor traffic at each stage of the distillation column. The hydraulic model (as part of the unit process model) is used by the unit process model to determine whether a distillation column is experiencing operating problems, such as entrainment, flooding, or weeping. The stability of the column operation with respect to flooding risk can be quantified through well-established flooding correlations (see, e.g., H. Z. Kister and J. R. Haas,Chem. Eng. Prog.,86(9), page 63 (1990) and J. R Fair.Petro/Chem Eng.,33(10), page 45 (1961), which are herein incorporated by reference in their entirety). These correlations compute a flooding factor (FF) from operation variables (e.g. tray vapor and liquid flow rates) and parameters (e.g. system foaming factor). Based on the calculated values of the hydraulic model flooding factor, the operating region for the distillation column can be divided into three primary zones: a zone of stable operation (FF<80%), a zone of unstable operation (80%≤FF<90%), and a problem zone (in which operating problems are encountered, FF>90%), as shown inFIG. 6C. The liquid and vapor flows of a given stage in the distillation column indicate in which of the three zones a given stage of the column is operating.

The hydraulic model includes a number of adjustable parameters (i.e. system foaming factor) and the method600(step650) tunes the hydraulic model via parameter adjustment. The method600(step650) tunes the hydraulic model by calculating values for the adjustable parameters of the hydraulic model, such as the system foaming factor. The method600(step650) calculates values for the adjustable parameters that enable the hydraulic model to accurately predict the zone in which a given stage within the distillation column is operating.

The following are example steps performed by the method600(step650) for tuning a hydraulic model of the unit process model that represents a distillation column consisting of either trays or packing. First, for each point in the created dataset from step625, the method600(step650) calculates the column profile using the reconciled unit process (first-principles) model output from steps630and635. Next, the method600(step650) identifies the maximum column pressure drop value and corresponding flood percentage value over the calibration time horizon. In some embodiments, these values are configured by a user via the user interface110. In other embodiments, these values are calculated as estimates by the reconciled unit process (first-principles) model output from steps630and635.

The method600(step650) then determines a virtual operating point for the hydraulic model based on the maximum column pressure drop. The method600(step650) calculates the virtual operating point as follows. First, the method600(step650) uses a least squares regression to equate the column pressure drop to the square of tray vapor flow rate. This results in obtaining the following equation: DP=aV2+b, where DP is the column pressure drop, V is the tray vapor flow rate, and a and b are parameters determined by the linear regression. Second, the method600(step650) uses the obtained equation, and the maximum column pressure drop configured by the user via the user interface110, to calculate a corresponding maximum value of V. Third, the method600(step650) uses the model calculated ratio of vapor flow rate to liquid flow rate, which is obtained from the model output of steps630and635, and assuming that vapor to liquid flow rate ratio (V/L) is constant, computes a maximum liquid flow rate (Lmax). Fourth, the method600(step650) then, utilizes the hydraulic correlations from the hydraulic model, manipulates the hydraulic model parameters (e.g. system foaming factor, and such) so that the operating point, (Lmax, Vmax), has a flooding factor value equivalent to the user specified flood factor (configured via the user interface110).

The method600adjusts the hydraulic model parameters (e.g., system foaming factor) based on a flooding curve of the distillation column (or other such representation), as shown inFIG. 6C, until the identified flood percentage value intersects with the determined virtual operating point and all the points in the created dataset from step625fall within the zone of stable operation. In this manner, the method600calculates (tunes) the stable operation, unstable operation, and runaway flooding zones of the hydraulic model.

The method600, step655, then saves the calibration results (from steps610-650) into a process unit configuration file in memory on the plant network120(e.g., in the centralized data store130). The method600of calibrating the unit process model ends at step655. At the completion of method600, the unit process (first-principles) model is configured for online use (real-time monitoring and predicting of plant operations) driven by physical plant measurements.

Method of Deploying Unit Process Model

FIG. 7is a flow diagram depicting a computer-implemented method700of deploying a unit process model in embodiments of the present invention, for example by deployment module160as implemented. The method700begins at step710. The method700, at step720, reads the configuration file storing the calibrated unit process model, and associates the configuration file with real-time plant data to dynamically execute the model online. In some embodiments, the configuration file was retrieved as the saved configured file generated by the build method500and calibration method600. The method700(step720), first connects the variables in the unit process model to their respective mapped instrument tags (as provided in steps560-570ofFIG. 5). The method700, at step730, next retrieves measured plant data from the real-time plant historian, which may be located at the centralized plant data store130, and conditions (i.e., interpolates and averages) the retrieved data. The measured plant data corresponds to the mapped instrument tags from method500, steps560-570.

The method700, at step740, then generates a dynamically executable version of the online unit process model. To do so, the method700(step740) creates a block of variables (a measurement block) for each mapped instrument tag, and uses the variable block to link the measured plant data for the mapped instruments to calculations by the model for the mapped instruments. Each measurement block provides three variables: a variable to hold the measured value of the real-time plant data, a variable to hold the model calculated result, and a variable that represents the difference or offset between the measured plant value and model calculated value. The offsets for a subset of the measurement blocks are used as tuning factors to ensure the model closely mirrors the actual (physical) operations in the plant. For each material stream out of the unit, the method700(step740) also creates an analyzer block to systematize the bookkeeping of stream variables of the modeled operating unit. The method700may further create one or more calculator blocks to expand the scope of the unit process model beyond what is integral to the model.

The calculator blocks are utilized by the method700(step740) for the following example functions. First, the method700utilizes the calculator blocks as an algebraic combination of process variables (e.g., computing a combined stream flow rate as the sum of stream flow rates that exist in the physical plant, calculating the pressure drop across the column from the top and bottom tray values, and such). The method700also utilizes the calculator blocks for basis conversion of process variables (e.g., converting a concentration variable from molar to mass, and such). The method700further utilizes the calculator blocks for setting model variables to be consistent with plant measurements (e.g., setting the model feed flow rate to match the value observed in the plant, and such).

To generate the dynamically executable version of the online unit process model, the method700, at step740, next sets the correct specifications for the variables of the model, so that the model is square (i.e., number of equations equals the number of unknown variables). The method700(step740) then retrieves the real-time values of the plant data from the real-time plant historian to correctly set the fixed variables (i.e., MVs) of the model. The method700(step740) further sets the values of the calibration parameters of the model determined via execution of method600(i.e., calibrated parameters from the flow and temperature steps635and640ofFIG. 6A). The method700(step740) also sets the solver parameters to values (e.g., default values) conducive to quick solution. The method700(step740) then determines if the unit is at steady-steady state and estimates the compositions of the feed stock (using feed stock estimator of step640) to complete the dynamically executable version of the online unit process model. The method700considers the modeled unit to be at steady-state if its current mass balance error is within a steady-state band defined by the mass balance average and deviation observed during calibration (as described in reference to method600).

Using the retrieved and conditioned data from step730, the method700, step750, solves the dynamically executable version of the online unit process model to compute values for KPIs of interest for the operating unit. The computed values for the KPIs of interest may include one process variable measurement (e.g., product impurities, condenser/reboiler duties, and such), a calculated index from measurements of one or more process variables using a pre-defined formula (e.g., tray index corresponding to the column tray that has the highest computed flood factor), and the like. See U.S. patent application Ser. No. 15/141,701, herein incorporated by reference in its entirety, for examples of computing KPI values.

The method700, step760, writes the computed KPI values to a real-time plant historian, which may be located a centralized data store130or other location on the plant network120. From the real-time plant historian, plant systems (e.g., instrumentation, control, and operation computer175ofFIG. 1) and plant personnel (e.g., plant operators) may access and employ the KPI values to perform real-time performance monitoring and predictive analytics (e.g., informing the user via interface110of an incipient flooding event for a distillation column) on the operations of the modeled operating unit. If the operating unit modeled by the unit process model is a distillation column, the method also predicts the column hydraulics (e.g., using hydraulic model tuned in step650) and generate a stability diagram for execution of the unit process model. The method700ends at step770.

Generating a Rule Engine

A rule engine may be generated for predictive insight and prescriptive guidance in embodiments of the present invention. A rule engine refers to a combination of one or more models in conjunction with domain specific logic. For example, the rule engine may receive as input a possible combination of user input (e.g., via a user interface as shown inFIG. 8B), first principles model predictions (which, in some embodiments, are calculated by models generated by method500) and plant tag data. The rule engine may be utilized to predict a multitude of events, including types of events comprising: (i) discrepancies between plant measurements taken by physical instruments and first principles model predictions and (ii) imminent undesirable operating events. Based on a predicted event, the rule engine can issue an alert of the event, as well as, suggestions for corrective actions. The former example event type (i.e., discrepancies between plant measurements and first principle model predictions) can be utilized to inform the user that the first principles model is no longer properly calibrated for the current asset operation or that drifts in the physical instruments may be occurring, indicating the need for re-calibration of the physical instruments.

For a distillation column, a specific embodiment of the latter example event type (i.e., imminent undesirable operating events) is column flooding. Flooding is defined as “the excessive accumulation of liquid inside the [distillation] column” (see, e.g., Kister et al., “Distillation Operation(Mechanical-Engineering), Book-mart Press, Inc., pg. 376 (1990), herein incorporated by reference in its entirety). The symptoms of flooding can include undesirable operating conditions that include loss of separation, which can be detected by rises in impurities as well as decreases in column tray temperature differentials. The symptoms of flooding may also include excessive pressure drop across the column or section of the column and sharp rises in column differential pressure. The loss of column separation due to column flooding can result in the production of off-specification materials, motivating the need to predict the onset of flooding and provide prescriptive guidance to avoid a flooding scenario. The rule engine facilitates notifying the user of a column flooding event type based on these symptoms.

FIG. 8Ais a flow diagram depicting a computer-implemented method of generating a rule engine for prescriptive guidance in embodiments of the present invention. The method800, at step805, builds the rule engine composed of one or more black-box (non-first principles) models (also referred to as alert models) which generate one or more alert scores that are consumed by the rule engine. The method800(step805) builds the alert models to receive model inputs that may include user input, first principles model predictions (in some embodiments calculated by models generated in method500), and plant tag data to generate the one or more alert scores. In some embodiments, the alert models calculate the one or more alert scores by utilizing the following functional form, where each model input i has its own coefficient, constant, and exponent rule engine parameters.
If mini<=(Xi−Constanti)<=maxi:
Score=Sum(Coeffi*(Xi−Constanti){circumflex over ( )}Exponenti)
Else:
Score=0

The rule engine, once built, examines each of the generated one or more alert scores to determine if the respective alert score crosses an alert threshold value. If an alert score crosses an alert threshold, then the rule engine may execute a series of events, including the prompting of an alert to the user via the user interface ofFIG. 8B, as well as, calculation of prescriptive guidance presented to the user.

The method800, at step810, builds a capacity alert model as one of the alert (black-box) models of the rule engine. The alert models that generate alert scores for the rule engine may be general for use respective to many process units180(e.g., models that generate alert scores for instrumentation error) or specific for use respective to a particular unit180operation type. An alert model specific to a particular unit operation may be constructed from domain knowledge. An example alert specific to a distillation column is a capacity alert which can be used to warn a user of an incipient flooding event. The method800(step810) builds a capacity alert model (that generates a capacity alert score) based on various model inputs. First, method800(step805) may build the capacity alert model based on prediction by a first principles model of the column flooding factor at one or more specified trays of the distillation column. A high prediction value indicates an increased probability of column flooding, as further described in the above “Hydraulic Model Tuning” section. The method800(steps805and810) may obtain the prediction of the first principles model by use of the calibrated model built by method500ofFIG. 5.

Second, method800(step810) may build the capacity alert model based on quantification of the resemblance of a sharp rising behavior in one or more column section differential pressures measured at the plant over time. Third, method800(step810) may build the capacity alert model based on quantification of the resemblance of a falling behavior in one or more column section differential temperatures (DTs) measured at the plant over time. The method800(step810) may obtain these quantifications (sharp rising and falling behavior) through various techniques, including by using trending, which performs linear regression of time series data to obtain the best-fit slope of the data as a function of time. The method800(step810) may also obtain these quantifications (sharp rising and falling behavior) using pattern recognition through applying a dynamic time warping algorithm to quantify how closely a section of time series data matches a pre-specified pattern (see, e.g., Rakthanmanon,Searching and Mining Trillions of Time Series Subsequences under Dynamic Time Warping,18thACM SIGKDD Converence on Knowledge discovery and Data Mining, Aug. 12-16, 2010, herein incorporated by reference in its entirety). Fourth, method800(step810) may build the capacity alert model based on current value of one or more column section differential pressures (DPs) measured at the plant.

The method800, at step815, tunes the parameters of the rule engine. The ability of the rule engine to predict undesirable events associated with a unit operation requires appropriate determination of the parameters for the rule engine models (e.g., alert models). The method800, step815, uses the approach of heuristics to tune the rule engine model parameters. In the case of a capacity alert model for a distillation column, the method800(step815) enables users to provide operational context (normal or flooding). The method800(step815) then calculates rule engine model parameters (alert parameters) that provide the best probability of alerting the user that a flooding event may occur during incipient flood. The method800(step815) tunes the alert parameters using two components: an objective function and a solver that is capable of minimizing the objective function. The objective function being defined (by a human user or computer-implemented system) with multiple objectives as follows. First, the objective function is defined to prevent the model alert score from crossing the alerting threshold during normal operation (i.e., prevent a false positive). Second, the objective function is defined to ensure that the model alert score crosses the alerting threshold during abnormal operation windows. Third, the objective function is defined to create separation between the mean values of the model scores between normal and abnormal time windows.

The method800, at step820, determines prescriptive guidance from execution of the rule engine built and tuned in steps805-815. When the rule engine determines that an alert score threshold is not met, the rule engine executes logic (based upon provided domain knowledge) to provide a user with prescriptive guidance in the form of an actionable item. In the example of a capacity alert model for a distillation column, upon an alert triggering, the rule engine considers at least the following actionable items: (1) reduction of column reflux flow rate and (2) reduction of feed flow rate for one or more feed streams.

The rule engine applies criteria for determining the prescriptive guidance in response to not meeting the alert score threshold. In the example of the capacity alert model, the rule engine applies impurity specification limits provided by a user (e.g., via the user interface screen ofFIG. 8B), along with predictions by a first principles model about the sensitivity of the column product impurities in regard to flow rates of column reflux and one or more feed streams, to current product stream impurity levels. For example, the rule engine determines if the current product stream impurity levels violate the user specified limit. The rule engine also determines if the first principle model (in some embodiments generated by method600) predicts an impurity specification violation based on a differential move in the reflux flow rate (size of move may be a configurable parameter in the user interface ofFIG. 8B). If the rule engine determines a violation, the rule engine provides prescriptive guidance (e.g., via the user interface screen ofFIG. 8B) advising the user to reduce the one or more feed flow rates, instead of reducing the distillation column reflux rate.

Digital Processing Environment

FIG. 9illustrates a computer network or similar digital processing environment in which the present invention may be implemented.

Client computer(s)/devices50and server computer(s)60provide processing, storage, and input/output devices executing application programs and the like. Client computer(s)/devices50can also be linked through communications network70to other computing devices, including other client devices/processes50and server computer(s)60. Communications network70can be part of a remote access network, a global network (e.g., the Internet), cloud computing servers or service, a worldwide collection of computers, Local area or Wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable.

FIG. 10is a diagram of the internal structure of a computer (e.g., client processor/device50or server computers60) in the computer system ofFIG. 9. Each computer50,60contains system bus79, where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. Bus79is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to system bus79is I/O device interface82for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer50,60. Network interface86allows the computer to connect to various other devices attached to a network (e.g., network70ofFIG. 9). Memory90provides volatile storage for computer software instructions92and data94used to implement an embodiment of the present invention (e.g., user interface and working procedure code100,200,300,400,500,600,700,800detailed above inFIGS. 1-8B). Disk storage95provides non-volatile storage for computer software instructions92and data94used to implement an embodiment of the present invention. Data94may include the off-line model, the process model flowsheet, the data historian entries/tags/mappings, the first-principles model, associated reconciliation dataset, hydraulic model, rule engine, and so forth as previously discussed. Central processor unit84is also attached to system bus79and provides for the execution of computer instructions.

In other embodiments, the program product92may be implemented as a so called Software as a Service (SaaS), or other installation or communication supporting end-users.