Patent ID: 12217198

DETAILED DESCRIPTION

A description of example embodiments follows.

Embodiments consistent with principles of the invention are directed at a new method for schedule reconciliation in the process industry. These embodiments provide a unique and novel way to reconcile past schedules automatically based on specific details about the schedule and the measured plant data for a given reconciliation horizon, as well as historical scheduling patterns and user actions related to reconciliation activities in the past. The invention can be compared to any methodology or tool schedulers use for reconciling their schedules. However, there is no specific tool or published methodology that is explicitly used for reconciliation purposes. In the industry, reconciliation calculations are mostly done manually by schedulers on a trial-and-error basis. These reconciliation activities include (but are not limited to) reconciling the specific attributes (such as start and stop time, rate, etc.) of past events (such as receipts, transfers and shipments) with present information (such as inventory positions, unit operations, etc.). These activities are required in order to establish a realistic and accurate starting point for scheduling all future plant activities. Although schedulers can use experience to identify likely adjustments, significant manual effort is required in this iterative process. Embodiments consistent with principles of the invention is unique as it provides a comprehensive tool that builds a rigorous optimization model especially tailored towards the schedule reconciliation problem and guides its solution towards better results by combining process modeling and optimization principles with historical precedence that aims to capture the schedulers' experience gained over time.

Using historical schedules and past user actions corresponding to reconciliation, machine learning (ML) and statistical models are trained to learn what type of schedules can be considered standard as well as predict actions the scheduler would take to reconcile any schedule. These learnings gained by the models can be applied to improve the optimization model by reducing the feasible space or adjusting the objective function to drive towards a more practical, reliable solution.

Additionally, the tool includes a component that processes the noisy tank inventory data obtained from the historian to transform it into piece-wise linear trends. The trends are then utilized by the tool to infer details about the operational activities and improve the optimization model.

FIG.1illustrates a process control (or more generally a process modeling and simulation) method and system100in which principles of the present invention may be incorporated. Briefly, an industrial plant (chemical processing plant, refinery, or the like)120performs chemical processes of interest124. Non-limiting examples include pharmaceuticals production, petroleum refining, polymer processing, and so on. Plant equipment includes distillation columns, various kinds of reactors and reactor tanks, evaporators, pipe systems, valves, heaters, etc. by way of illustration and not limitation. Plant data102represents inputs (feed amounts, values of certain variables, etc.) and outputs (products, residuals, physical operating characteristics/conditions, etc.) of the chemical process124. A controller122employs model process control to configure and maintain settings132(i.e., parameter values, temperature selection, pressure settings, flow rate, other values of variables representing physical characteristics) operating the plant equipment in carrying out the subject chemical process124.

The model process control is based on models (of the subject chemical process) generated by process modeling system130. In embodiments of the present invention, the process modeling system130employs a reconciliation module140to reconcile past schedules with the plant data102. Using the reconciliation data for modeling optimization150, the process modeling system generates a reconciled process schedule to set setting132for deployment in the plant120.

This invention has multiple modules for model building and solution, each consisting of a different data management, machine learning or optimization technology. Together, these modules form a decision-making support framework that is used to reconcile the schedules.

FIG.2Ashows the overall workflow200for an embodiment of a reconciliation module140ofFIG.1consistent with principles of the invention. The starting point of the reconciliation algorithm is an existing initial scheduling model205in a refinery scheduling software, such as Aspen™ Petroleum Scheduler (APS).FIG.2Bshows an alternative workflow202for another embodiment of a reconciliation module140consistent with principles of the invention. The workflow202includes the general workflow200ofFIG.2A, but further includes modules that use dynamic optimization and historical scheduling data.

Starting with an initial scheduling model205that needs to be reconciled, the user imports actual current plant data to reconcile against at the Import Plant Data Module210. The user configures the current plant data to import and can choose to read tank inventory levels, compositions, properties, and stream flowrates. In some embodiments consistent with principles of the invention, the current plant data may be imported either from an Excel file or from a process data historian. While an Excel file may provide data for a discrete set of time stamps, connecting to a historian allows importing data stored in the historian for the given reconciliation time window.FIG.3shows sample plant data that can be imported through an Excel file300. Here the first row contains the baseline time for which the plant data is being provided. The figure contains inventory volume, API gravity, sulfur and material composition (i.e. Amenam, Etame, and Rabi Blend by composition volume) data for three tanks named T-001, T-002 and T-003.

In some other embodiments as shown inFIG.2B, an overall workflow202may include a Real-time Optimization Data Processing Module220addresses the need to infer what happened in the recent few hours of operations by using continuous values for key process parameters that vary over time. This time variation can be due to input variability (feed composition and properties for a unit) or can be the results of a continuous degradation of process characteristics over time (such as catalyst deactivation, loss of tray efficiency in distillation, or fouling in heat exchanging). This is important information that cannot come from direct plant observations (measurements) but can be inferred from a dynamic process model that performs reconciliation at a very high frequency (every few minutes). A commercial example of such dynamic optimization and reconciliation system is the Aspen™ GDOT and specifically its Data Reconciliation function.

The Real-time Optimization Data Processing Module220operates under the notion that trends in process production and efficiency data can provide significant insights about the actual values of large subsets of process input and output variables (such as flows or properties) that are not or that cannot be directly measured in real-time (or at a frequency that enables confident scheduling decisions). This inference provides important meta-data information that in conjunction with the plant measurements and the underlying mathematical model can remove or minimize any uncertainty on the initial state of the process. This additional information ensures a robust reconciliation system that ultimately provides the starting point for the scheduling process. It should be noted here that without an accurate starting point for all process variables at any given point in time, making scheduling decisions for future events can be problematic.

The Reconciliation Window Plant Data Processing Module250addresses the need to infer what happened in the recent few hours of operations by using event and inventory information from the reconciliation window. The input to the Reconciliation Window Plant Data Processing Module250is obtained from Import Plant Data Module210and contains tank inventory values at multiple time points while the output contains a set of time points and the effective rate of change in inventory between them for each tank. Typically, the length of the reconciliation window is a few hours, but it can go up to a few days (during weekends for example). Generally, trends in tank inventory data can provide significant insights about flows into or out of tanks. The rate of change in tank inventory values can reveal the effective flowrates into or out of the tank. Additionally, the time points where those rates change indicate the start or stop times of events associated with the tank. The module uses a statistical approach to fit a piece-wise linear trend to the noisy tank inventory data. The linear segments identified by a reconciliation window plant data processing algorithm denote the event durations on the tank. The approach is also able to identify outliers and removes them from analysis. Based on the source of imported data, the data processing module may or may not be triggered. If the imported data comes from a historian, Reconciliation Window Plant Data Processing Module250is used to process the tank inventory values.

The application of the module on a sample dataset is shown inFIG.4. The start and stop times of the events, and the stream flowrates into or out of the tanks inferred in this module are used as inputs to the module that builds the optimization model. These details help the optimizer find a solution that is closer to where the baseline values arrived.

In some embodiments, such as shown inFIG.2B, a Historical Schedule Data Management Module230maintains a record of past scheduling data for the models. Three types of data are stored by this module, namely initial state, projected state and reconciled schedule. As the data stored is specific to the reconciliation workflow, the data can be identified into sets where each set corresponds to a time window that was reconciled. Initial state data contains simulated inventory quantities for all tanks at the beginning of the reconciliation window and events data for the reconciliation window. Events data includes start times, durations, stream flowrates, and parameters like composition, tank fractions etc. based on the type of the event. Projected state data contains the projected plant values for tank inventory quantities, qualities and composition values at the specific baseline times.

Every time the schedule is reconciled, the system saves the versions before and after reconciliation. This ensures that as the scheduler reconciles the schedule and rolls forward, the system maintaining a record of the initial and final states and reconciled schedules. These initial states of the schedule along with the plant data form the input while the corresponding reconciled schedule form the output training data for the ML models described below in connection with the Machine Learning and Statistical Models Module240.

The Machine Learning and Statistical Models Module240processes historical scheduling information to create machine learning (ML) and statistical models, as well as derive statistical insights. The outputs from this module help improve the optimization model by reducing the combinatorically explosive options available (model feasible space) and driving the optimizer towards a solution that better captures the desirable operational activities based on best practices in the past. Statistical results from historical scheduling data provide guidance on key scheduling parameters for the optimizer which are not necessarily specified in the scheduling model.

Machine learning provides a powerful mechanism to incorporate data into process models. Machine learning algorithms are typically easy to automate and can continuously improve as more data becomes available. In addition, these algorithms are good at handling multi-dimensional data and datasets containing different data types. Machine learning models are used to predict the changes needed to reconcile the schedule based on its current state and the projected state. In order to build these ML models, versions of historical scheduling data in the Historical Schedule Data Management module230are used. These ML models predict the user actions needed to reconcile the schedule based on given state of the schedule and baseline data.

Training data for these ML models would include tank inventory and property values at the beginning of the reconciliation window as well as reconciliation window initial events details as the independent variables. Data related to events modified for reconciliation would be used as dependent variables. Event details would include the rate, quantity, start, and other relevant parameters.

In the Build Optimization Model Module260, a mathematical programming model for the refinery schedule reconciliation problem is developed to ensure that all decisions satisfy the fundamental physical conservations laws (mass, energy, and momentum conservation) as well as the mechanical and engineering constraints of the process for which we need to provide a schedule. The model consists of different types of resources, namely transportation modes, tanks, mixers, splitters and production units, that represent the corresponding resources in the refinery scheduling operations system. Transportation modes are non-inventory resources used for receiving or shipping materials like crude oils and blends. Tanks are the inventory resources where materials are stored. Mixers and splitters are non-inventory resources used for mixing multiple streams into one and splitting a stream into many respectively. Production units are the process units that take input feed streams and produce one or more output product streams. Taking all the resources and their connectivity into account, the set of operations is determined by considering all possible discrete selections of actions in the system and the schedule is represented as a sequence of these operations. The goal is to determine the sequence of operations, i.e. when the operations are performed (time and duration), how many times they are performed, and the flow between resources so as to come up with a reconciled schedule that is aligned with the actual operational activities and leads to the baseline values.

The formulation uses a hybrid discrete-continuous time representation. A non-uniform discrete time period grid based on the initial schedule is used such that the start and end times of all the original events constitute the period boundaries. A pre-determined number of continuous time priority slots are introduced within the periods and are used to assign and sequence the execution of operations. A priority slot denotes a position in the sequence of operations. So, a priority slot with a higher index has a higher priority for scheduling compared to one with a lower index. Continuous time priority slots are required as the start and stop time of operations are unknown and need not correspond to the pre-existing period boundaries. Multiple operations can be assigned to a priority slot. However, the start and stop times of the slots are synchronized. The synchronization is necessary in order to accurately apply cardinality constraints.

The constraints used in the formulation can be divided into two main classes, scheduling constraints and operation constraints. Scheduling constraints model logistics rules and include non-overlapping constraints, cardinality constraints and continuous operation of units. Operation constraints include material balances, flowrate bounds based on pumping capacities and tank capacities. These constraints are applied on priority slots within each period as well as across periods. Additional constraints are used to align the flows at the period level with those at the priority slot level. Following is a description of the equations that may be used in the Build Optimization Model Module260.

Nomenclature

Sets

S slotsW operationsP periodsT tanksSpslots in period pWIn,tinlet operations on tank tWOut,toutlet operations on tank t
Indicess slotoperationt tankp period
VariablesZs,vassignment of operation v to slot sFs,vflow associated with operation v in slot sStts,vstart time of operation v in slot sEnds,vend time of operation v in slot sDurs,vduration of operation v in slot sFRvflowrate of operation v (only for receipts and shipments)Invt,sinventory in tank t at slot sInvt,pinventory in tank t at period p
ParametersH schedule reconciliation horizonFRvminimum flowrate of operation vFRvmaximum flowrate of operation v
Non-Overlapping Constraints:
zs,v1+Zs,v2≤1,v1,v2 ∈W,NOv1,v2=1  (1)

Equation 1 states that if operations v1 and v2, belonging to the set of all operations W, do not overlap (NOv1,v2=1), the operations cannot be simultaneously assigned to slot s. Here zs,v1and Zs,v2are binary assignment variables that determine whether operation v1 and v2 are assigned to slot s or not respectively.

Cardinality Constraints:
Σv∈W′zs,v≤NW′(2)
Σv∈W′zs,v≥NW′,zs,v1,v1∈W′(3)

Equations 2 and 3 represent cardinality constraints on subsets of operations. Equation 2 states that the sum of assignment variables of the subset of operations for a slot is less than the maximum number of operations (NW′) that can happen simultaneously from within the subset W′. Equation 3 states that if any of the operations within the subset W′ is assigned to a slot, a minimum number of operations (NW′) must be assigned.

Continuous Operation:
ΣsDurs,v=H(4)

Equation 4 states that the sum of the durations of all priority slots for an operation v equals the length of the reconciliation horizon. This constraint is applied for operations that are required to be performed continuously.

Timing Constraints:
0≤Stts,v≤Zs,v′Stts,v(5)
0≤Ends,v≤Zs,v′Ends,v(6)
0≤Durs,v≤Zs,v′Durs,v(7)
Ends,v=Stts,v+Durs,v(8)

The timing constraints define the relationship between start time, end time and duration of slots for and operation v within periods. The upper bounds on these variables equal the length of the period corresponding to the slots.

Flowrate Constraints:
FRv′Durs,v≤Fs,v<=FRv′Durs,v(9)

Equation 9 enforces the bounds on flow values Fs,vbased on the flowrate limits for operation specified in the model.
Fs,v=FRv′Durs,v(10)

Equation 10 is added only for the subset of operations corresponding to receipts and shipments. It used to enforce a uniform flowrate for the duration of the event. Here FRvrepresents the reconciled flowrate of the receipt or shipment event.

Material Balance:
Invt,s=Invt,s−1+Σv∈WInFs,v−Σv∈WOutFs,v(11)
Invt,p=Invt,p−1Σv∈WInFp,v−Σv∈WoutFp,v(12)
Σs∈SpFs,v=Fp,v(13)

Equations 11 and 12 enforce total material balances at the slot and period levels respectively. Inventory level of any tank t at a slot or period is equated to the level in the previous period plus flows due to inlet operations on the tank during the slot or period minus flows due to outlet operations in the slot or period. In order to align the two material balances, sum of flows in slots for a period is equated to the flow in the period using equation 13. Similar balances for each material are enforced to obtain composition balances.

Based on the results obtained from the Reconciliation Window Plant Data Processing Module250and the Machine Learning and Statistical Models Module240, additional constraints may be introduced. The additional hard constraints reduce the feasible space for the problem while soft constraints allow adding terms to the objective function so as to drive the solution.

All the variables of the model are initialized based on a simulation of the original schedule. As mentioned earlier, the period grid is obtained from the start and stop times of the events in the initial schedule. For each period, the first slot is assigned during initialization. The remaining slots are left unassigned.

The presence of bilinear terms in the composition balances and the uniform flowrate constraints leads to a mixed integer nonlinear programming (MINLP) formulation. This is solved using a nonlinear optimization solver, such as the AspenTech's proprietary Aspen XSLP.

The objective is to minimize a weighted sum of multiple types of penalties. Some of these penalties are specifically useful because there can be multiple solutions available that achieve the same baseline values. Penalties are applied on deviation from the following.

Baseline values: Baseline values are the projected plant data values obtained from plant data. Since the objective of this workflow is to match the baseline values, any difference between the schedule values and the baseline values is penalized. This is the main driver for the optimization.

Initial schedule: Deviation from initial schedule (or original schedule) is penalized as it is favorable for the reconciled schedule to not be too different from the initial schedule. The initial schedule serves as the instructions to be carried out for operations. Actual operations deviate from a schedule only if necessary.

Data processing results: If the data processing step is used, differences between schedule values and those obtained from the data processing step are penalized.

Statistical and ML insights: These are based on careful analysis of historical scheduling data for the refinery and reflect how operations have been carried out in the past.

The result of this module is a Solution file that contains all the variables of the optimization model with their optimal values.

The Reconcile Schedule Module270module manages updating the schedule as well as maintaining a record of the schedule prior to the update. Storing a snapshot of the original version is necessary so that the information can be utilized in the future, specifically for building machine learning and statistical models.

The module reads the solution file obtained from the previous module and applies the results to update the schedule. It contains logic to translate the variable names to the different parameters of the events. Accordingly, it updates existing events with adjusted start time, stop time and flowrate. The logic also creates new tank-to-tank transfers if needed. Receipts, shipments or crude runs are not created or deleted. However, a receipt or shipment event may be moved out of the reconciliation window. In case the original event has to be moved such that it occurs only partially within the reconciliation window, it is moved to the desired time and split at the reconciliation window end time. As mentioned above with respect to the Historical Schedule Data Management Module230, after the schedule is reconciled, the reconciled schedule and the initial schedule are stored275when the user accepts the changes280.

Data Processing

Using example data,FIG.4illustrates how a data processing module250ofFIGS.2A and2Bworks on noisy plant data to calculate boundaries of events on a tank. A given schedule of events on a tank was used for this illustrative case study and noisy synthetic tank inventory data corresponding to the schedule was used. The x-axis shows the time in minutes while the y-axis shows the tank inventory in thousands of barrels (Mbbls). The dots450in the figure represent the noisy plant data for tank inventory values. The solid lines410a-frepresent the event boundaries calculated by the reconciliation window plant data processing algorithm while the dashed lines420a-fare the known event boundaries based on the given schedule. The calculated event boundaries410a-fobtained from the algorithm are close to the original420a-f. Additionally, the algorithm automatically ignores the one outlier455that was introduced in the dataset. The results from this step provide a good estimate of the net flowrate into or out of the tank in each time interval. In some instances, the deviation (shown as430a-f) between the calculated event boundary and the known event boundary is virtually non-existent (430brepresenting the deviation between410band420b). In other instances, the deviation is relatively pronounced (430frepresenting the deviation between410fand420f). A penalty against deviation from the net flowrate is added to the optimization model for the respective time intervals. It is to be noted that the event boundaries and net flowrates calculated using the algorithm are not used as hard constraints in the optimization model.

Receipts Analysis

FIG.5shows the analysis of receipt events and displays how they are clustered into separate regions of specific gravity, namely light, medium and heavy, using kernel density estimates, and how the destination tanks are assigned into those different clusters. The x-axis represents the specific gravity of the receipt and the y-axis represents the kernel density estimate. The colored crosses represent the different tanks as shown in the legend. A different clustering technique can be applied to consider multiple properties as well. This analysis provides information about the most likely destination tanks based on the composition of a crude receipt. This is an example of an unsupervised ML technique that is used to understand the receipt events better and subsequently help of the optimizer choose the right destination tanks.

FIG.6shows a mapping of the different crudes in the model, identified by the row headers, with the tanks, identified by the column headers. The values in a row represent the percentage of crude receipt events containing the row crude that are sent to the respective column tank. As shown in the figure, the mapping reveals a very distinct tank assignment for most of the crudes, with some crudes, highlighted in green, being assigned to a single tank. While the previous approach uses the bulk properties of crude receipts to determine tank assignments, this provides a more direct approach. The clustering approach using bulk properties complements this technique and becomes particularly useful when crude-to-tank mapping does not reveal definitive tank assignments.

Crude Runs Analysis

FIG.7shows the different ranges of tank fractions used in the crude run events in the past schedules. The 3 plots show the fractions corresponding to events for 3 different crude units in the model. The plot for SUC3 provides a very clear indication regarding the use of tanks for the specific crude unit. For instance, Tank T-003 (fraction range represented by Frac003) is the predominant tank used for feeding the tower while Tank T-004 (fraction range represented by Frac004) is never used. Similarly, Tank T-003 is never used for SUC1 while very rarely used for SUC2 in small fractions. These insights regarding limits on tank fractions for crude runs are translated into soft constraints for the optimization problem.

On carrying out association rule mining on tank fractions data for the crude runs associated with the distillation tower SUC3, the combination of Tank T-003 and Tank T-005 has lift greater than 1 and support values close to 1. Lift greater than 1 indicates that the two tank fractions are substitutes of each other, as observed inFIG.8, which illustrates tank association analysis in crude runs over time. Such insights derived from association rule mining provide additional information about how the schedules have been generated in the past and are translated into soft constraints for the optimization problem.

Reconcile Schedule

FIG.9Ashows the Gantt chart for a sample initial schedule. This represents the crude scheduling part of the refinery and has 4 tanks (T-101 to T-104) that receive crudes through a dock, 3 tanks (T-201 to T-203) that receive crudes from a pipeline and 4 feed tanks (T-301-T-304) feeding 2 crude units. Transfers happen from the marine and pipeline tanks to the feed tanks. A 4-day schedule from Friday to Monday is shown here. This corresponds to the scenario where the schedule has to be reconciled on a Monday morning after the scheduling instructions were given on the Friday before the weekend. Differences between schedule values and the imported plan values are displayed inFIG.10A. There are 3 alerts corresponding to the differences in tank volume inventory values for T-102, T-103 and T-301.

The Gantt chart corresponding to the reconciled schedule is displayed inFIG.9B. Although it is very similar to the one displayed inFIG.9A, there are a couple of changes that were made to achieve the baseline values. Firstly, the transfer event from tanks T-103 to T-301 has been deleted. Secondly, the event rate for the receipt event Marlim has been increased from 120 Mbbl/day to approximately 132 Mbbl/day, as indicated in the event details inFIGS.11A and11B. Also, since the reconciliation window is only until 12:00 am on 4th January, the receipt Marlim is split at that time. The matching plant and schedule values for the reconciled schedule are shown inFIG.10B.

Computer Support

FIG.12illustrates a computer network or similar digital processing environment in which process controllers (generally interfaces)122and process modeling systems130embodying 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.13is a diagram of the internal structure of a computer (e.g., client processor/device50or server computers60) in the computer system ofFIG.12. 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.13). Memory90provides volatile storage for computer software instructions92and data94used to implement an embodiment of the present invention (e.g., hybrid model building methods and systems100,500,700, supporting machine learning models, first principles models, libraries, hybrid models116,516,716, and related data structures and constructs detailed above). Disk storage95provides non-volatile storage for computer software instructions92and data94used to implement an embodiment of the present invention. Central processor unit84is also attached to system bus79and provides for the execution of computer instructions.

In one embodiment, the processor routines92and data94are a computer program product (generally referenced92), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM's, CD-ROM's, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system. Computer program product92can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. In other embodiments, the invention programs are a computer program propagated signal product107embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)). Such carrier medium or signals provide at least a portion of the software instructions for the present invention routines/program92.

In alternate embodiments, the propagated signal is an analog carrier wave or digital signal carried on the propagated medium. For example, the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network. In one embodiment, the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer. In another embodiment, the computer readable medium of computer program product92is a propagation medium that the computer system50may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagation medium, as described above for computer program propagated signal product.

Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium and the like.

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.

The teachings of all patents, published applications and references cited herein are incorporated by reference in their entirety.

While example embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the embodiments encompassed by the appended claims.

Computer-based methods and systems in process control, modeling, and simulation use a combination of first principles models and machine learning models to benefit where either model is lacking. In one example, input values (measurements) are adjusted by first principles techniques, and the adjusted values are used to train and generate a machine learning model of the chemical process of interest. In another example, a machine learning model represents the residual (delta) between a first principles model prediction and empirical/observed physical phenomena. Different machine learning models address different physical phenomena. A collection of residual machine learning models improves the accuracy of a first principles model of a chemical process of interest by correcting respective physical phenomena predictions. In yet another example, a machine learning model uses as input, measured values from the chemical process of interest. A first principles simulation model uses the process input data and machine learning predictions of parameters corresponding to specific phenomena. An error correction module determines the error between the simulated results and measured process output values (i.e., plant data). The determined error is used to further train the machine learning model improving predictions that are utilized by the first principles simulator.

Although the forgoing describes and details process control as one application technology area of embodiments of the present invention, there are other technology areas of utilization of Applicant's hybrid models and modeling method/system disclosed herein. Embodiments enable improvement in the performance of the chemical process of interest, such as by: enabling a process engineer to better troubleshoot the chemical process, enabling debottlenecking a portion of the chemical process at the industrial plant, and optimizing (online or offline) performance of the chemical process at the subject industrial plant. Embodiments include process modeling systems, process model simulation systems, and the like.