Process control based on dual mode model

Abstract

The disclosed systems and techniques enable a model-based controller to operate in a dual-mode, where the controller is capable of operating in both (i) a constrained solution mode and (ii) an unconstrained solution mode. The dual-mode operation improves control because it operates using the constrained solution mode when possible (constrained solutions are generally capable of achieving superior control), and uses the unconstrained solution mode when it is not possible to use the constrained solution mode (e.g., when it is not possible to form a constrained solution in the available time). This can achieve superior control compared to a typical model predictive control (MPC) controller.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to using model-based predictive control, and more specifically, to using a dual-mode operation that simultaneously generates constrained and unconstrained solutions for an optimization problem. BACKGROUND

[0002] Distributed process control systems, like those used in a power generation, chemical, petroleum, or other process, typically include one or more process controllers communicatively coupled to one or more process control devices via a process control network.

[0003] The process control devices perform functions within the process or plant, such as opening or closing valves, starting and stopping devices, and measuring process parameters. Exemplary process control devices include valves, valve positioners, switches, and transmitters (e.g., devices including sensors to measure a process parameter; and transmitters to transmit the sensed process parameter).

[0004] The process controllers typically receive signals indicative of process measurements acquired by the process control devices (or other information related to the process control devices), and execute a controller application that implements a control strategy stored in the controller to generate control signals to control the process control devices based on the received information. In this way, the controllers and the process control devices implement a control strategy that adjusts the operation of the process plant or a portion thereof based on feedback from the process. and The process controllers typically receive signals indicative of process measurements acquired by the process control devices (or other information related to the process control devices), and execute a controller application that implements a control strategy stored in the controller to generate control signals to control the process control devices based on the received information. In this way, the controllers and the process control devices implement a control strategy that adjusts the operation of the process plant or a portion thereof based on feedback from the process.

[0005] The execution of the control modules causes the process controllers to send control signals to the process control devices over communication links or signal paths, thereby controlling the operation of at least a portion of the process plant or system (e.g., controlling at least a portion of one or more industrial processes running or being executed within the plant or system). For example, a first group of controllers and field devices can control a first portion of a process controlled by the process plant or system, while a second group of controllers and field devices can control a second portion of the process.

[0006] The network formed by the one or more controllers, the field devices communicatively coupled to the one or more controllers, and the intermediate nodes facilitating communications between the controllers and the field devices can be referred to as an "I / O network" or "I / O subsystem."

[0007] Information from (multiple) I / O networks can be made available via data highways or communication networks (“process control networks”) to one or more other hardware devices (e.g., operator workstations, personal computers or computing devices, handheld devices, data history repositories, report generators, centralized databases, or other centralized management computing devices), which are typically located in control rooms or other locations in harsh field environments far from the plant, such as in the back-end environment of a process plant.

[0008] Information transmitted through a process control network enables operators or maintenance personnel to perform desired functions related to the process via one or more hardware devices connected to the network. These hardware devices can run applications that allow operators to, for example, change settings of process control routines(s), modify the operation of control modules within process controllers or intelligent field devices, view the current status of the process or the status of specific equipment in the process plant, view alarms generated by field devices and process controllers, simulate process operation for personnel training or testing process control software, diagnose problems or hardware failures in the process plant, etc. The process control network or high-speed data channel used by the hardware devices, controllers, and field devices can include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0009] As an example, the DeltaV sold by Emerson TM Control system and Ovation TM Each distributed control system (DCS) comprises multiple applications, which are stored and executed by different devices located at different locations within the process plant. Configuration applications residing in one or more workstations or computing devices in the back-end environment of the process control system or plant enable users to create or modify process control modules and download these modules to the dedicated distributed system via high-speed data channels. Typically, these control modules consist of interconnected functional blocks, which are objects in an object-oriented programming protocol. These objects (i) perform functions in the control scheme based on their inputs, and (ii) provide outputs to other functional blocks in the control scheme. Configuration applications also allow configuration designers to create or modify operator interfaces, view data displayed to operators using these interfaces, and enable operators to change settings in process control routines, such as setpoints.

[0010] Each dedicated controller (and in some cases one or more field devices) stores and executes a respective controller application that runs control modules assigned and downloaded thereto to implement the actual process control functionality. A viewing application, which can be executed on one or more operator workstations (or on one or more remote computing devices that are communicatively coupled to the operator workstations and to the data highway), receives data from the controller application(s) via the data highway, and uses user interfaces to display that data to process control system designers, operators, or users, and can provide any of a number of different views (e.g., operator view, engineer view, technician view, etc.). A data historian application, which is typically stored and executed on a data historian device that collects and stores some or all of the data provided across the data highway, and a configuration database application, which can be run on another computer attached to the data highway, stores current process control routine configurations and data related thereto. Alternatively, the configuration database can be located in the same workstation as the configuration application.

[0011] In addition to process controllers, I / O cards, and field devices, a typical process control system also includes a number of other support devices that are necessary or relevant to process operation. These additional devices include, for example, power equipment, power generation and distribution equipment, rotating equipment (e.g., turbines, etc.), which are located in many places throughout a typical plant.

[0012] With respect to process controllers, controllers can generally be divided into two categories: traditional controllers (e.g., PID controllers) and model-based controllers (e.g., MPC controllers). Each of these types of controllers can control a process, which can be characterized as having one or more process outputs (e.g., flow, pressure, temperature, composition, humidity, opacity, density measurements, etc.) and one or more process inputs (e.g., valve position, flow rate, etc.). Model-based controllers have advantages over traditional controllers, such as PID controllers, because they can perform more effective control when controlling complex processes. This can be due, at least in part, to the ability of model-based controllers to predict future states of the process being controlled.

[0013] Traditional controllers generally operate based on feedback (i.e., a measured value of a controlled variable) and a desired value of a process output (i.e., a setpoint) to manipulate a process input (which can be referred to as a “manipulated variable”) to change a process output (which can be referred to as a “controlled variable” or simply a “process variable”).

[0014] By way of comparison, model-based controllers such as described herein (e.g., model predictive controllers or MPCs) have advantages over traditional controllers such as PID controllers in that model-based controllers can predict future states of a process based on a process model that represents the dynamic relationship between inputs and outputs of the process being controlled. That is, model-based controllers can implement control based not only on feedback of process outputs and desired values, but also on predicted future values of process outputs that the process controller predicts or anticipates based on the process model and measurements of the process outputs. As a result, model-based controllers can take into account potential future events in ways that traditional controllers cannot, and for complex processes with significant multivariable interactions (e.g., where a change in a single manipulated variable or process output affects the value(s) of multiple other process outputs).

[0015] Despite the many desirable performance features that model-based controllers provide, the process control industry has been slow to fully adopt model-based control technology. This limited adoption can be attributed, at least in part, to the fact that model-based controllers typically require accurate process models to implement effective control of a process. Unfortunately, process characteristics often change over time. If a model-based controller continues to use an old process model for a changed process, the performance of the model-based controller can quickly degrade due to process model mismatch (i.e., the characteristics of the process model do not match the characteristics of the process being modeled). To avoid this performance degradation, process model mismatch typically needs to be corrected.

[0016] Typically, model-based controllers correct process model mismatch by generating a new process model during a model identification or generation process such that the new process model matches the current characteristics of the process. Unfortunately, model generation can be problematic because model generation typically involves interrupting normal control of the process. As noted above, the process models used by model-based controllers typically represent the dynamic relationships between inputs and outputs of the process being controlled. Traditionally, these dynamic relationships are captured during a model generation process that involves (i) introducing a known disturbance or upset to the process by changing one or more manipulated variables, and (ii) observing how the process reacts to the change in manipulated variables. When the process completes its response to the change in manipulated variables and reaches a steady state, the controller can generate a process model based on the relationship between the change in manipulated variables and the observed process response. The controller can then resume normal control using the new (and possibly more accurate) process model.

[0017] Unfortunately, model generation often involves interrupting normal control of the process to introduce the known disturbance described previously, which can be problematic. In particular, interrupting normal control often has a negative impact on the operation of the process and can result in waste of material or time. In some cases, model generation can be very time consuming, thereby amplifying this negative impact. For example, for some slow processes, model generation can take a long time, where process variables can take minutes, hours, or even days to reach a setpoint or final steady state value. Furthermore, model-based controllers can require frequent model regeneration because the characteristics of the process often change over time due to equipment failure or degradation, atmospheric changes, raw material changes, etc. In summary, the process control industry has been slow to fully embrace model-based control techniques because the model generation process (which traditionally involves interrupting normal operation, introducing a disturbance, observing the process response until the process reaches a steady state, and generating a model based on the observed values) can take a long time and can therefore interfere with normal operational objectives.

[0018] In any event, even setting aside the problem of process model mismatch, the adoption of model-based controllers is limited because it is difficult to form accurate predictions over a finite time frame. Generally speaking, process controllers are configured to send controller outputs to field devices at fairly regular time intervals (e.g., every few seconds to every few minutes). In an ideal situation, a model-based controller would make accurate predictions of the future over multiple time intervals. However, because it can be challenging to form these accurate and precise predictions over a given time interval (particularly for complex processes that include multiple interacting inputs and outputs), the advantages that might otherwise be gained by implementing model-based control can be reduced or excluded. As a result, process plants often rely on traditional control techniques rather than model-based control techniques.

[0019] Note that the above description of background describes aspects within the scope of what the inventors regard as related art. None of the above background descriptions, including any aspects thereof, is specifically admitted as prior art against the presently named inventors. SUMMARY

[0020] The disclosed systems and techniques implement a dual-mode operation for a model-based controller, where the controller is capable of operating in both (i) a constrained solution mode, and (ii) an unconstrained solution mode. The dual-mode operation improves control because it is able to operate using the constrained solution mode when possible (the constrained solution mode generally implements superior control), and uses the unconstrained solution mode when it is not possible to use the constrained solution mode (e.g., when it is not possible to form a constrained solution in the available time). This enables superior control compared to a typical model predictive control (MPC) controller.

[0021] In embodiments, including any one or more of: (A) performing, via a process controller coupled to one or more field devices, model-based control of a process represented by a set of process variables (PVs) including (i) a set of manipulated variables (MVs) adjustable by the process controller via the one or more field devices, and (ii) a set of controlled variables (CVs) each dependent on one or more of the MVs; (B) initiating, by the process controller at a beginning of a scan cycle, a scan to obtain a current set of measured values of the CVs; (C) performing, prior to an end of the scan cycle, a dual-mode operation including selecting, from a process model and a set of constraints on the PVs, a current move schedule for the set of MVs to be executed by the process controller; and (D) performing, prior to the end of the scan cycle, control of the process by setting the set of MVs to a set of values included in the current move schedule by sending a set of controller outputs carrying the set of values to the field devices to cause the field devices to drive the set of MVs to the set of values. Performing the dual-mode operation can include: (i) (i) using the current set of measured values of the set of CVs as model inputs to the process model, initiating generation of both: (a) an unconstrained solution including a set of unbounded move schedules that are not bounded by the set of constraints, and (b) a constrained solution including a set of bounded move schedules that avoid violating any of the set of constraints. Performing the dual-mode operation can further include: (ii) when the constrained solution is generated prior to the end of the scan cycle: selecting a first move schedule from the set of bounded move schedules of the constrained solution as the current move schedule; and (iii) when the constrained solution is not generated prior to the end of the scan cycle: selecting a first move schedule from the set of unbounded move schedules of the unconstrained solution as the current move schedule.

[0022] In an embodiment, a method includes any one or more of: (A) executing a dual-mode model-based process controller configured to control one or more field devices in a process control environment; (B) initiating, by the model-based controller, a scan to obtain a current set of values for a set of process variables (PVs), the current set of values representing a current state of the controlled process, the process variables including a plurality of controlled variables (CVs) and a plurality of manipulated variables (MVs); (C) generating, with the process model, an unconstrained solution to an optimization problem, using the process model, generating a series of move plans for the plurality of MVs to achieve a predetermined target regardless of whether any of the series of move plans violates any of a set of constraints on the PVs, such that a value for each MV in each of the series of move plans is not bounded by the set of constraints; (D) initiating, with the process model, generation of a constrained solution to the optimization problem.

[0023] Initiating generation of the constrained solution can include any one or more of: (i) storing the unconstrained solution as a candidate solution; (ii) bounding a first MV from the plurality of MVs by analyzing the candidate solution to: (a) identify a first violation of a constraint and determine that the first MV caused the first violation; and (b) calculate an allowed range for the first MV based on one or more values for the first MV included in move plans scheduled prior to the first violation. Generating the constrained solution can also include: (iii) bounding remaining MVs from the plurality of MVs by generating, in an iterative manner, modified candidate solutions that include a series of move plans modified for each of the remaining MVs, such that each modified candidate solution keeps the previously bounded MVs within the calculated allowed ranges and such that each subsequent modified candidate solution includes one fewer unbounded MV than a previous modified candidate solution, wherein the remaining MVs are bounded in an order that is based on which of the remaining MVs first violates a constraint for each modified candidate solution; and / or (iv) after each of the plurality of MVs has been bounded such that a most recently modified candidate solution includes a final series of move plans that does not violate any of the set of constraints, finally determining the constrained solution by storing the most recently modified candidate solution as the constrained solution; (E) when a scan period expires prior to the constrained solution being finally determined: (i) in a first move plan of the unconstrained solution, modifying any values that violate any of the set of constraints to achieve a bounded first move plan that does not violate any of the set of constraints, and (ii) using the bounded first move plan of the unconstrained solution for a set of controller outputs to control the one or more field devices in accordance with the bounded first move plan; and (F) when the constrained solution is finally determined prior to the scan period expiring, using a first move plan of the constrained solution for the set of controller outputs to control the one or more field devices in accordance with the bounded first move plan.

[0024] Note that the summary of the application has been provided to introduce a series of concepts that are further described in the detailed description below. As explained in the detailed description, certain embodiments can include features and advantages that are not described in the summary and certain embodiments can omit one or more features or advantages described in the summary. BRIEF DESCRIPTION OF DRAWINGS

[0025] According to embodiments, each of the drawings described below depicts one or more aspects of the disclosed system(s) or method(s). The DETAILED DESCRIPTION refers to the accompanying drawings in which the

[0026] Figure 1 is a block diagram of a process control system including a controller having a dual-mode model-based control (DMMC) block that can be implemented to control a process.

[0027] Figure 2 An exemplary PID control routine is shown that is unable to implement predictive control or any of the corresponding benefits associated with dual-mode model control provided by the DMMC block. Figure 1

[0028] Figure 3 is a diagram depicting an exemplary model-based control operation that can be implemented by the controller shown in Figure 1 has many benefits over traditional feedback control techniques, such as those related to the control loop shown in Figure 2

[0029] Figure 4 is an exemplary schematic diagram of a dual-mode model-based control loop also shown in Figure 1

[0030] Figure 5 An exemplary method for implementing dual-mode model-based control is illustrated.

[0031] Figure 6 An exemplary method for implementing an unconstrained solution is illustrated.

[0032] Figure 7 An exemplary method for implementing a constrained solution is illustrated. DETAILED DESCRIPTION

[0033] ​​​The disclosed systems and techniques implement a dual-mode operation for a model-based controller, where the controller is capable of operating in both (i) a constrained solution mode and (ii) an unconstrained solution mode. The dual-mode operation improves control because it is able to operate using the constrained solution mode when possible (the constrained solution mode is generally capable of achieving superior control), and is able to use the unconstrained solution mode when it is not possible to use the constrained solution mode (e.g., when a constrained solution cannot be formed in the available time). This can achieve superior control compared to a typical model predictive control (MPC) controller.

[0034] Example process control environment

[0035] Such as Figure 1 The process control system 10 shown can be used to implement the dual-mode model-based control techniques described herein to control a process. The controlled process can be any suitable process, and can be said to have one or more "process outputs" that characterize a state of the process (e.g., tank level, flow rate, material temperature, etc.) and one or more "process inputs" (e.g., states of various environmental conditions and actuators, manipulation of which can cause the process outputs to change).

[0036] In this example, the process control system 10 includes a process controller 11 connected to a data historian 12 and one or more host workstations or computers 13 (which can be any type of personal computer, workstation, etc.) each having a display screen 14. The controller 11 is also connected to field devices 15-22 via input / output (I / O) cards 26 and 28. The data historian 12 can be any desired type of data collection unit having any desired type of memory and any desired or known software, hardware or firmware for storing data. In Figure 1 In this example, the controller 11 communicates with the field devices 15-22 using a wired communication network and communication scheme.

[0037] Typically, field devices 15-22 can be any type of device (e.g., sensors, valves, transmitters, positioners, etc.), while I / O cards 26 and 28 can be any type of I / O device conforming to any desired communication or controller protocol. Controller 11 includes a processor 23 that implements or supervises one or more process control routines (or any modules, blocks, or subroutines thereof) stored in memory 24. Generally, controller 11 communicates with devices 15-22, host computer 13, and data history database 12 to control the process in any desired manner. Furthermore, controller 11 implements control strategies or schemes using portions commonly referred to as function blocks, where each function block is an object or other part (e.g., a subroutine) of an overall control routine that operates in conjunction with other function blocks (via communication called a link) to implement a process control loop within process control system 10. Function blocks typically perform one of the following: an input function (e.g., an input function associated with a transmitter, sensor, or other process parameter measuring device), a control function (e.g., a control function associated with a control routine that executes control techniques such as PID, MPC, or fuzzy logic), or an output function that controls the operation of a device (e.g., a valve), to perform a physical function within the process control system 10. Of course, hybrid function blocks and other types of function blocks exist and can be used herein. As described below, function blocks can be stored in the controller 11 or other devices and executed by them.

[0038] Exemplary single-loop control loops 32 and 34

[0039] like Figure 1 As shown in the exploded block 30, the controller 11 may include multiple single-loop control routines, exemplified as control routines 32 and 34, and, if desired, may implement one or more high-level control loops, exemplified as control loop 36. Each such control loop is typically referred to as a control module. Single-loop control routines 32 and 34 are illustrated as performing single-loop control using single-input / single-output fuzzy logic control blocks and single-input / single-output PID control blocks, respectively connected to appropriate analog input (AI) and analog output (AO) function blocks, which may be associated with process control devices (e.g., valves), measuring devices (e.g., temperature and pressure transmitters), or any other devices within the process control system 10.

[0040] Exemplary advanced control loop 36 and dual-mode model control

[0041] The high-level control loop 36 is illustrated as including a dual-mode model-based control (DMMC) block or routine 38 that is input communicatively connected to one or more AI function blocks and output communicatively connected to one or more AO function blocks, although the inputs and outputs of the DMMC block 38 can be connected to any other desired function blocks or control elements to receive other types of inputs and provide other types of control outputs (e.g., DI blocks, DO blocks, etc.).

[0042] The DMMC block 38 can implement the dual-mode model-based control techniques described herein. More generally, the DMMC block 38 can implement any type of multi-input, multi-output control scheme, and / or can implement a process model-based control routine, and thus can constitute or include a model predictive control (MPC) block, a neural network modeling or control block, a multivariable fuzzy logic control block, a real-time optimizer block, etc.

[0043] It will be appreciated that, Figure 1 The illustrated function blocks (including the DMMC block 38) can be executed by the independent controller 11, or can alternatively be located in and executed by any other processing device or control element of the process control system 10 (e.g., one of the workstations 13 or one of the field devices 19-22). As an example, the field devices 21 and 22, which can be transmitters and valves, respectively, can execute control elements for implementing control routines, and thus include processing and other components for executing portions of the control routines, e.g., one or more function blocks. More specifically, the field device 21 can have a memory 39A for storing logic and data associated with an analog input block, while the field device 22 can include an actuator with a memory 39B for storing logic and data associated with a PID, MPC, or other control block that communicates with an analog output (AO) block, as Figure 1 The illustrated.

[0044] As noted above, the controller 11 can execute the DMMC block 38 to perform dual-mode model-based control. The process controlled by the dual-mode controller 11 (sometimes simply referred to as the “controller 11”) can be characterized by a set of process variables or PVs. The PVs can include: (i) manipulated variables or MVs (e.g., valve positions) that are manipulated by the controller 11 via controller outputs; (ii) controlled variables or CVs that are indirectly controlled by adjusting the MVs (e.g., water tank temperature is controlled by adjusting the valve position of a cold water inlet valve); (iii) auxiliary variables or AVs that can be indirectly affected by changes in the CVs or MVs (e.g., water tank level); and (iv) disturbance variables or DVs (e.g., ambient temperature of a room that can slightly affect the water tank temperature). Generally speaking, when implementing model-based control (in either the constrained solution mode or the unconstrained solution mode), the controller 11 uses all of the CV measurements to simultaneously calculate all of the MVs.

[0045] In one embodiment, the controller 11 operates according to a scan period k (e.g., 1 minute). At each instant k (e.g., every minute), the controller 11 receives controller inputs with measured PVs (e.g., CVs and / or AVs). Based on the current measurements, the controller relies on a process model to predict future values of the PVs and forms a "move plan" for the MVs to help drive the CVs and / or AVs to desired values. At the end of the scan period, the controller 11 sends the MV values in the move plan to field devices (e.g., valve actuators) via control signals or controller outputs. The controller 11 then receives the measured PVs again and repeats the process.

[0046] As described herein, a "move plan" refers to a set of values for a set of MVs that will be implemented by the controller 11 at the end of each scan period. Whether in a constrained solution mode or an unconstrained solution mode, the controller 11 can calculate a series of move plans that extend into the future during each scan period. Generally, a "bounded move plan" includes a set of MVs that will not cause any immediate constraint violations (i.e., MV values do not violate any MV constraints, and the predicted responses of the corresponding CVs or AVs will not immediately violate constraints). On the other hand, an "unbounded move plan" has been generated without regard for constraints and thus can include MV values that violate MV constraints or cause constraint violations (e.g., constraint violations of CVs or AVs). Note that future move plans after the first move plan are not typically executed because the controller 11 typically recalculates a series of move plans at each scan as part of the calculation of the optimal solution.

[0047] "Optimization" is performed by finding a "solution" for a "target function". Generally, a "target function" is a formula that can be solved to determine any useful metric (e.g., typically a profit). An example target function can be the formula "Profit = 24x + 20y", where x is a first type of widget and y is a second type of widget. Depending on the nature of the target function, an optimal solution can be found by minimizing or maximizing the target function (in the preceding example, the target would be to maximize the profit). Identifying the optimal solution involves evaluating numerous candidate solutions.

[0048] As described herein, a "solution" to an optimization problem or objective function refers to a solution formed by an optimizer algorithm or routine, which can be implemented by the controller 11 or a computing device in communication with the controller 11. The "solution" can be characterized as a set of target values for the set of PVs at the process's steady state operating point at the end of the controller's control or prediction horizon, and a set of values for the PVs (e.g., for MVs, CVs, and AVs) at each controller scan or controller interval between the process's current state and the end of the horizon. The "prediction horizon" represents the number of future scans that the optimizer evaluates, while the "control horizon" represents the number of scans for which the optimizer predicts output MV values; in other words, the control horizon represents the number of assumed "move plans" for the MVs to be evaluated.

[0049] As an example, if the prediction horizon is 10 and the control horizon is 5, then the solution can include a set of 10 target values for the PVs (including 5 move plans to be implemented in the next 5 scans, where each move plan includes a set of values for the MVs). Regardless, the controller 11 can form one or sometimes both of a "unconstrained solution" and a "constrained solution."

[0050] During unconstrained solution optimization, the controller 11 generates controller outputs (transmits MV values to field devices) based on a first move plan included in the unconstrained solution. The controller 11 can form the unconstrained solution by feeding the following to the optimizer: (i) a pre-generated process model (typically generated offline), which was generated at the time of generation to model the process; (ii) current process variable values; and (iii) one or more control objectives. The optimizer identifies a solution to the objective function to reach steady state values for the process variables, and target values for the process variables at each of a plurality of "moves" to be performed by the controller 11. The controller 11 then identifies a first "move plan" (including a set of desired values for the manipulated variables) from the solution, and "bounds" the set of desired values in the first move plan if any of the values violate a constraint or would result in a violation of a constraint (e.g., a constraint on a CV or AV). The controller 11 can then send controller output signals carrying the "bounded" values of the first move plan to field devices to implement control of the process.

[0051] By comparison, constrained solution optimization can provide better control when conditions are suitable. During constrained solution optimization, the controller 11 generates controller outputs by (i) forming a process model in real-time when possible; and (ii) feeding the optimizer: (a) the current process model with current process variable values; (b) control targets; (c) constraints on all process variables (e.g., all CVs, AVs, MVs, and DVs). The optimizer forms a constrained solution (e.g., including target CVs, AVs, and MVs for each scan period) by first computing an unconstrained solution. The optimizer then identifies the first MV that is constrained in time (i.e., finds the earliest MV constraint violation) in a series of move plans. The allowable portion of the move plan for that MV is then imposed on the problem. Next, the controller 11 recomputes the unconstrained solution using the remaining MVs, and the process is repeated until all MVs are constrained or the unconstrained solution does not violate any constraints. Using this iterative process, a set of controller outputs will be identified that do not result in constraint violations. This process is computationally intensive, particularly compared to the unconstrained solution mode where the controller 11 computes a relatively simple solution that requires a relatively short online execution time.

[0052] Constrained solution optimization has at least two advantageous features. First, a control matrix or model can be generated online at each control period. All dependent variables (e.g., CVs and AVs) are included in the dynamic matrix of the move calculation. At each control period, the error penalty (PE) for each dependent variable is adjusted. If a CV is far from a limit, its PE can be set to zero to effectively remove it from the dynamic control problem. Conversely, if a CV is close to a limit, the full value of the PE can be used. In this way, the dynamic move calculation at each control period can include only those CVs that are close to their limits, and can exclude those CVs that are far from their limits.

[0053] A second advantage is the enforcement of MV constraints on future move plans. This prevents the controller 11 from planning moves that cannot be achieved. As previously described, the general approach is to first compute an unconstrained MV solution. The second step is to find the first MV that is constrained in time (look for the earliest MV constraint violation). The allowable portion of the move plan for that MV is then imposed on the problem. Next, the unconstrained solution using the remaining MVs is computed, and the process is repeated until all MVs are constrained or the unconstrained solution does not violate any constraints.

[0054] The dual-mode controller 11 can operate in both modes simultaneously. First, a constrained solution can be obtained through a series of full move plans until the end of the prediction or control horizon, where all relevant PVs are constrained throughout the series of move plans. The MV values in the first move plan in the constrained solution can be used for controller output. Second, an unconstrained solution can be obtained, and the controller 11 can modify the MV values in the first move plan as needed to avoid violating constraints.

[0055] Generally, an "output selector" of the controller 11 can select the first MV move plan from the constrained solution or the unconstrained solution at the end of the control scan. The first priority is generally the constrained solution. However, if the constrained solution has not been completed or finalized before the end of the controller scan, the controller 11 uses the first move plan of the unconstrained solution and adjusts the first move plan of the unconstrained solution as needed to avoid violating any constraints.

[0056] Note that although the techniques described herein are referred to as "dual-mode," it should be understood that the controller 11 can be considered to implement "tri-mode" control. In other words, the controller 11 can form that the controller output MV values can be determined from three different first move plans. First, at the end of the controller scan, the controller 11 can select MV values from the first move plan of the constrained solution (if available). Second, if the constrained solution is not ready, the controller 11 can select the first move plan from the unconstrained solution. Third, if the unconstrained solution is also not available, the controller 11 can select MV values for controller output that are calculated from a pre-generated controller matrix.

[0057] Example PID control loop

[0058] Figure 2 An example PID control routine 200 is shown that, when implemented by the controller 11, does not enable predictive control or any corresponding benefits associated with the dual-mode model control provided by the DMMC module 38.

[0059] As used herein, "predictive control" refers to a technique of process control in which the value of one or more MV outputs by the controller (e.g., via control signals sent to field devices) takes into account future values for one or more PVs (e.g., one or more CVs that are responsive to the MVs). As noted above, the routine 200 does not enable predictive control.

[0060] The control loop 200 can be similar to Figure 1Control loops 32 and 34 are shown. It is worth noting that control routine / loop 200 does not rely on predictive control or model-based control. Because DMMC block 38 relies on predictive control, it can provide more accurate and improved performance relative to control routine 200.

[0061] At a high level, control routine 200 controls process 201 by attempting to drive a controlled variable (CV) (e.g., tank level) to a specific setpoint. Control routine 200 receives a setpoint (SP) or desired value 212 for CV, measures the actual value 214 of CV, calculates the error or difference 216 between SP and the measured CV value, and then calculates a command or controller output (e.g., based on a proportional factor 218, an integral factor 220, a derivative factor 222, or a sum of some combination thereof) for the CV response (e.g., manipulated variable (MV) 226) (e.g., tank inlet valve position). The controller can send the value 226 (e.g., actuator position) to the appropriate MV (e.g., actuator) via AO block 208 to drive CV 232 (e.g., temperature, level, or flow rate) to the SP value 212. As shown, CV 232 in process 201 may be affected by one or more parameters outside the direct control of loop 200. These parameters may be referred to as disturbance variables (DV) 236.

[0062] As shown in the figure, control routine 200 includes four blocks: Analog Input (AI) block 202, AI block 204, control block 206, and AO block 208. Depending on the implementation, AI blocks 202 and 204 may represent analog signals received by the controller executing routine 200 or by an I / O card coupled to that controller (e.g., from a field device). For example, AI block 204 may be bound to a first Device Signal Tag (DST) identifying a specific AI I / O channel at a first I / O card, and the value provided by AI block 204 can therefore be the value of a signal on a specific AI I / O channel (e.g., a 4-20 mA signal representing the measured flow rate provided by a flow transmitter field device). Similarly, AO block 208 may represent analog signals that will be sent by the controller executing routine 200 via an I / O channel (e.g., to a field device) or to an I / O card coupled to the controller. For illustration, AO block 208 may be bound to a second DST identifying a specific AO I / O channel at a second I / O card. Therefore, the value fed to AO block 208 can enable the second I / O card to drive a signal on a specific AO I / O channel based on the value received at AO block 208 (for example, the value can enable the second I / O card to drive a 4-20mA signal to the valve field device via the AO I / O channel to control the valve position).

[0063] Figure 1The DMMC block 38 shown in the middle can similarly receive inputs from one or more input blocks (e.g., AI or DI blocks), which can provide the DMMC block 38 with values carried by signals received by the controller 11 via I / O channels bound to the blocks and coupling the controller 11 to field devices. In some cases, the input blocks can be "manual" blocks that enable a user to input values (e.g., SPs for particular CVs) that can be provided to the DMMC block 38 and the controller 11 as inputs.

[0064] In addition, the DMMC block 38 and the controller 11 can provide output values to one or more output blocks (e.g., AO or DO blocks), which can enable the controller 11 to send output signals carrying the output values to field devices via I / O channels bound to the blocks.

[0065] Example model control chart and control loop

[0066] Figure 3 is a diagram 300 depicting an exemplary model-based control operation that can be implemented by the controller 11 in association with a control loop 200 such as that shown in Figure 2 This control operation has a number of advantages over conventional feedback control techniques associated with control loops 200 such as that shown in Figure 4 is an exemplary schematic diagram 400 of a dual-mode model-based control loop 36 according to an embodiment.

[0067] The diagram 300 depicts an exemplary model-based control operation

[0068] As shown in Figure 3 When implementing a model-based controller, the controller 11 performs a controller scan at each time instance or scan time k. The time between scans can be referred to as a "scan period," "scan time," or "control interval." The scan time can be adjusted by a user and can be any suitable value depending on the requirements of the controlled process. For example, the scan time can be 0.01 seconds, 0.1 seconds, 1 second, 10 seconds, 1 minute, 10 minutes, 1 hour, 10 hours, or any suitable value within this range.

[0069] The "prediction horizon" P implemented by the DMMC block 38 represents the number of steps or scans that the DMMC block 38 evaluates into the future. The "control horizon" M implemented by the DMMC block 38 represents the number of move plans (i.e., sets of moves for controlled MVs) to be optimized at each control interval. Thus, if P = 10 and M = 2, the DMMC block 38 optimizes for 2 MV move plans based on predictions (and evaluations) related to responses of relevant CVs for the next 10 scans. Each of the prediction horizon and the control horizon can be manually set or adjusted by a user.

[0070] In the illustrated example, at each scan k, the controller 11 outputs a value u of the MV and measures a value y of the CV affected by the MV and in which a SP or target exists. In some cases, multiple MVs and CVs can be controlled and evaluated.

[0071] For illustration, consider an example in which there are 12 MVs, there are 10 CVs, there are 10 prediction horizons, and there are 4 control horizons. At each scan, the DMMC block 38 relies on the optimizer to determine a set of steady state process variables that best satisfy the objective function 403 (e.g., representing an optimal operating point), including a set of target CVs and a set of MVs to achieve those target CVs, thereby implementing a series of move plans (consistent with the prediction and control horizons) to achieve the desired steady state values.

[0072] More specifically (and consistent with the same example), the DMMC block 38 can form four move plans that would theoretically be executed in the next four scans (as described below, typically only the first move plan is executed, as the series of move plans is recalculated each scan). Each move plan includes 12 values of the MV (e.g., u1-u12). The DMMC block 38 feeds each move plan to the process model 105 to predict how the PVs (e.g., CVs and / or AVs) would respond to each move plan. The effects of the four move plans can be evaluated for the next 10 scans (as the prediction horizon is 10).

[0073] Example block diagram 400 of DMMC block 36

[0074] Figure 4 An example of a high level control loop 36 including the DMMC block 38 is schematically illustrated in accordance with an embodiment. Depending on the embodiment, the DMMC block 38 can have additional or alternative inputs or outputs.

[0075] As shown, the DMMC block 38 is implemented as an MPC routine to simultaneously control multiple CVs of the process 104 based on measurements taken of those CVs and provided back to the DMMC block 38. In an embodiment, the DMMC block 38 can be used to implement a dynamic matrix control (DMC) control technique. The control routine 116 of the DMMC block 38 can interact with the optimizer 401 to identify variable targets and values, and the optimizer 401 can in turn be configured to form an optimal (e.g., maximum or minimum) solution of the objective function 403.

[0076] As Figure 4 shown, the DMMC block 38 produces a move plan that includes values of a set of MVs that are provided to other functional blocks (e.g., the process model 105, the optimizer 401, etc.). Figure 4These function blocks, in turn, are connected to the process inputs of the process 104 (not shown). The DMMC block 38 can include or implement any standard model-based predictive control routine or procedure, typically having the same number of inputs as outputs, although this requirement is not necessary. The DMMC block 38 receives as inputs a set of N CVs (which can have defined constraint limits and can have defined set values) and AVs (which can have only defined constraint limits). The CVs and AVs typically constitute a vector of values, as measured in the process 104. A line having vector values is typically represented in a graph by a hash line drawn through it.

[0077] The DMMC block 38 can also receive as inputs a set of DVs, which are known or anticipated changes or disturbances provided to the process 104 at some future time, and a set of target control and auxiliary variables (CVTs) and (AVTs), denoted as set points (SPs) provided, for example, from an optimizer 401. These targets can represent a portion of a solution (e.g., a series of move plans) aimed at reaching an optimal steady-state plant operating point (e.g., represented by a set of steady-state process variable targets) until the end of the control or prediction horizon.

[0078] The optimizer 401 can be any suitable optimizer that solves an optimization problem by generating a solution to an objective function (OF) 403 (e.g., a linear programming (LP) optimizer, a quadratic programming optimizer, etc.).

[0079] At a high level, an optimization problem is a problem in which an optimizer algorithm (e.g., 401) evaluates or solves an objective function (e.g., profit = 24x + 20y, where x = first type of widget, y = second type of widget) to identify an optimal solution to the objective function (e.g., a solution or x and y values that result in the greatest profit). Depending on the scenario, the optimizer 401 can form an unconstrained solution (i.e., a solution that does not take into account constraints) or a constrained solution (i.e., a solution that takes into account constraints on one or more variables (e.g., a limit on total material used; a limit on total time spent on production; a limit on certain valve ranges; etc.)). A solution that violates one or more variable constraints can be referred to as an “infeasible solution.”

[0080] In general, the objective function 403 can specify a cost or a benefit associated with each of a number of control variables, auxiliary variables, and manipulated variables. To solve the OF 403, the optimizer 401 sets control variable target values (CVTs), auxiliary variable target values (AVTs), and manipulated variable target values (MVTs) over a series of move plans to reach steady-state target values for the CVs and AVs. The final steady-state target values included in the solution can be referred to as steady-state control variables (CVSS) and steady-state auxiliary variables (AVSS), and can represent an optimal operating point that maximizes or minimizes the objective function 403.

[0081] A sequence of process variable targets (e.g., MVs, CVs, or AVs) can be referred to as a "solution" computed by the optimizer 401. Each set of MVTs computed for a particular scan period can be referred to as a "move plan." In other words, a solution can include a sequence of move plans (e.g., sets of target values for MVs) and corresponding CVTs and AVTs, where each move plan and corresponding set of CVTs / AVTs corresponds to a different control scan in the sequence of control scans. At each scan time, the process can be said to have an operating point represented by the predicted or target values CVT, AVT, and / or MVT.

[0082] A move plan is generated or selected under the assumption that it will be implemented in a sequence of scans or controller intervals (e.g., a first move plan at time k, a second move plan at time k+1, etc.). At any given time, a move plan can be said to result in an "operating point," which is characterized by the values of the PVs (e.g., CVs, AVs, and / or MVs) at the time in question. An operating point is a "steady state" operating point, where most of the PVs change little (if at all) over a given time period. An operating point can be in an "unsteady state" if one or more PVs change dramatically over a time period.

[0083] In any case, a solution (e.g., MVTs, CVTs, and AVTs for each move plan in a sequence of move plans) can be fed to the control algorithm 116, which can then compute the next actual move plan to be executed. Although the MV values of the next actual move plan to be implemented by the routine 116 and controller 11 can be the same as or similar to the MVTs of the next move plan computed by the optimizer 401, there can sometimes be a difference. For example, if a first move plan from the optimizer 401 includes MVTs for a given MV that results in a constraint violation (e.g., a constraint violation for a CV, MV, or AV), the routine 116 can adjust the value of the given MV so that the constraint is no longer violated (this can occur when the DMMC block 38 computes a constraint solution). On the other hand, when the optimizer 401 computes a constraint solution, the MVTs in the first move plan (or any subsequent move plans related thereto) typically do not result in a constraint violation. Thus, the values in the move plans implemented by the routine 116 and controller 11 typically match the MVTs of the first move plan formed by the optimizer 401.

[0084] The objective function 403 can be selected from a plurality of potential pre-stored objective functions, each of which can mathematically represent a different way of defining optimal operation of the process 104. For example, one of the pre-stored objective functions can be configured to maximize the profitability of the plant, another one of the objective functions can be configured to minimize the use of a particular raw material that is in short supply, and yet another one of the objective functions can be configured to maximize the quality of the product manufactured in the process 104. In general, the objective function used uses the cost or benefit associated with each move of the control variables, the auxiliary variables, and the manipulated variables to determine the optimal process operation point within the set of acceptable points defined by the set points or ranges of the control variables CV and the limits of the auxiliary variables AV and the manipulated variables MV. Of course, any desired objective function can be used in place of or in addition to those described herein, including objective functions that optimize each of a number of aspects such as the use of raw materials, profitability, etc. to some degree.

[0085] To select the objective function, the user or operator can provide an indication of the objective function 403 to be used by selecting the objective function 403 on an operator or user terminal. Of course, the user or operator can change the objective function used during process operation. If desired, a default objective function can be used in the absence of the user providing or selecting an objective function.

[0086] Returning to the optimizer 401, in addition to the objective function 403, the optimizer 401 can receive as input a set of control variable set points (which are typically operator-specified set points of the control variables CV of the process 104 and can be changed by the operator or other user) and a range and weight or priority associated with each control variable CV. The optimizer 401 can additionally or alternatively receive a set of range or constraint limits and a set of weights or priorities for auxiliary variables AV or a set of limits for manipulated variables MV used to control the process 104. The optimizer 401 can take these constraints into account when forming a constrained solution, but can ignore them when forming an unconstrained solution.

[0087] In general, the ranges of the auxiliary variables and the manipulated variables define the limits of the auxiliary variables and the manipulated variables (typically based on the physical properties of the plant), while the ranges of the control variables provide the range in which the control variables can operate to satisfactorily control the process. The weights of the control variables and the auxiliary variables specify the relative importance of the control variables and the auxiliary variables relative to each other during the optimization process, and in some cases can be used to enable the optimizer 401 to generate a semi-constrained solution if it is not possible to avoid violating all of the constraint conditions when attempting to form a constrained solution.

[0088] Using any known or standard LP algorithm or technique, the optimizer 401 iterates to determine the target manipulated variable MVT set for each of a series of move plans (e.g., for the entire control horizon) that maximizes or minimizes the selected objective function 403. In forming a constrained solution, the optimizer 401 can maximize or minimize the objective function 403 while maintaining process operation within the control variable CV setpoint range limits, the auxiliary variable AV constraint limits, and the manipulated variable MV limits. When forming an unconstrained solution, the optimizer 401 can ignore these constraints and limits to form a theoretical (and possibly infeasible) solution.

[0089] In an exemplary operation, the optimizer 401 determines the latest change in manipulated variable values (i.e., determines the current values of the MVs) and uses the predicted steady state control variables (CVs), auxiliary variables (AVs), and manipulated variables (MVs) to determine the change in process operation from its current operation for the entire control horizon (i.e., to determine the MV move plans for the next number of plans specified by the control horizon value); in other words, to determine the dynamic operation of the routine 116 during the process to reach the target or optimal process operating point.

[0090] In general, when forming a constrained solution, the optimizer 401 will calculate the target manipulated variable values (MVTs) by forcing each of the controlled and auxiliary variables to their limits. As noted above, in many cases, there will be a solution in which each of the CVs are at their setpoints (which can initially be considered as the upper limits of the control variables), while each of the auxiliary variables remain within their respective constraint limits. If this is the case, the optimizer 401 need only output the determined manipulated variable targets MVTs that result in the optimal result of the objective function.

[0091] However, in some cases, due to strict constraints on some or all of the auxiliary variables or manipulated variables, such a solution (e.g., represented by a sequence of MVT move plans, each having a corresponding CVT and AVT) can not be found in which, for each scan, all process variables are within their respective constraint limits at each operating point, as such a solution does not exist. In these cases, the optimizer 401 can compute a semi-constrained solution. For example, as described above, the optimizer 401 can relax the limits on the CVs within their specified setpoint ranges in an attempt to find operating points in which the auxiliary variables operate within their respective limits. If no solution exists in this case, the optimizer can discard one of the auxiliary variable constraint limits as a limit within the solution, and instead, determine the optimal process operating points that ignore the discarded auxiliary variable constraint limit. Here, the optimizer 401 selects which auxiliary variable or control variable to discard as a constraint limit based on the respective weight provided for each of the control variables and auxiliary variables (e.g., discarding the lowest weight or highest priority first). The optimizer 401 continues to discard auxiliary variables or control variables based on the provided weights or priorities of the auxiliary variables or control variables until it finds an MV solution in which all of the setpoint ranges for the control variables and the limits for the remaining higher priority auxiliary variables are satisfied.

[0092] In any case, the optimizer 401 can feed the set of optimal targets or setpoints or SPs (e.g., CVSS and AVSS) that will be reached at the end of the prediction or control horizon, as computed based on solving the objective function 403, to the DMMC block 38. The DMMC block 38 can rely on the model 105 / 110 to compute the target CVs and AVs (i.e., CVTs and AVTs) needed to reach the SPs at each step, and the target MVs (MVTs) needed to achieve the CVTs and AVTs. In other words, the optimizer 401 utilizes the model(s) 105 / 110 to compute target trajectories for the CVs, AVs, and MVs to reach the optimal steady-state operating point.

[0093] The DMMC block 38 uses the SPs to create a set of M manipulated variable signals (MVs) in the form of control signals (e.g., controller outputs) and passes the MV signals to the process inputs (e.g., valve actuators) of the process 104. The MV signals are control signals, which can be controller outputs or process inputs related to controlling the operation of valve actuators, burners, pumps, etc., or any other device that affects the physical operation of the process 104.

[0094] Note that because the DMMC block 38 operates as described above during each controller scan (i.e., because a full solution and a series of move plans can be calculated at each scan), the target values of the manipulated variables can change between each scan even if the SP remains the same, and as a result, the DMMC block 38 can never actually reach any particular target MV in the set of target MVs that are temporarily planned for future scans, especially when there is noise, unexpected disturbances, changes in the process 104, etc.

[0095] Typically, the DMMC block 38 includes a control variable prediction process model 105 (also referred to as a “controller model” or a “predicted process model”), which can be any type of model for any of a variety of different MPC control techniques. For example, the model 105 can be an N by M+D step response matrix (where N is the number of CVs plus the number of AVs; M is the number of MVs; and D is the number of DVs). The model 105 can be a first-order, second-order, third-order, etc. predictive or first-principles model, a state-space model, a convolution process model, or any other type of process model. The controller model 105 can be determined from process upset tests using time series analysis techniques that do not require extensive modeling efforts, or can be determined using any other known process modeling techniques, including those that superimpose one or more linear or nonlinear model sets.

[0096] In any case, the model 105 accounts for model mismatch by producing an output 107 that defines the previously calculated predictions for each of the control variables CV and the auxiliary variables AV. An adder 108 subtracts these predicted values for the current time from actual measured values of the control variables CV and auxiliary variables AV sensed or measured in the process 104 at the current time to produce an error or correction vector (also referred to as a set of residuals). The set of residuals, often referred to as prediction errors, define the bias or offset error of the model 105 and are used to correct the predictions of the model 105.

[0097] During operation, the process model 105 uses the MV and DV inputs and the residuals to predict future control parameters for each of the CVs and / or AVs within the control range, and provides future predicted values of the CVs, and potentially the AVs (in vector form) on a line 109. The optimizer 401 can rely on these predictions when evaluating potential values of the MVs for each move plan.

[0098] In addition, the process model 105 and / or the optimizer 401 can produce the predicted steady-state values CVSS and AVSS discussed above. Thus, the block 105 can predict values for each of the CVs and AVs at each scan (e.g., based on each move plan) for the time to reach the prediction range.

[0099] Further, the control target block 110 determines a control target vector or setpoint vector for each of the N target control variables CVT and auxiliary variables AVT provided to it, for example, by a user or other optimization application. The control target block 110 can include a trajectory filter that defines the manner in which the control variables and auxiliary variables are driven to their target values over time. The control target block 110 uses this filter along with the target variables CVT and AVT defined by the setpoint SP to generate a dynamic control target vector for each control variable and auxiliary variable that defines the variation of the target variables CVT and AVT over a time period defined by the control horizon time.

[0100] The vector summer 114 then subtracts from the dynamic control vectors generated by the block 110 the future control parameter vectors for each of the simulated or predicted control variables CV and simulated or predicted auxiliary variables AV on the line 109 in order to define a future error vector for each of the control variables CV and auxiliary variables AV. The future error vector for each of the control variables CV and auxiliary variables AV is then provided to the control algorithm 116, which operates (in cooperation with the optimizer 401) to select a manipulated variable MV step that minimizes or maximizes the objective function 403 (e.g., minimizes the integrated squared error (ISE) or integrated absolute error (IAE) over the control horizon) within the control horizon.

[0101] In some embodiments, the algorithm 116 can use an N by M control matrix formed from the relationship between the N control variables and auxiliary variables input to the DMMC block 38 and the M manipulated variables output by the DMMC block 38, if desired. More particularly, the MPC control algorithm 116 can have two main purposes. First, the control algorithm 116 can attempt to minimize the CV control error with the least MV movement (e.g., within the operational constraints in forming a constrained solution). Second, the control algorithm 401 can attempt to attain the optimal steady state MV value (MVSS) and the target CV value calculated from the optimal steady state MV value.

[0102] The state equation of a typical model predictive controller can be represented as:

[0103]

[0104]

[0105]

[0106] where Q, R, S are the error, controller move, and incremental move penalty weights, respectively, xkis the model state matrix, ykis the process output, and ukis the controller output. The DMMC block 38 and controller 38 can execute this state equation. Because the Q, R, and S penalty vectors are intrinsically separate, the MPC controller generally does not have a performance tradeoff between setpoint tracking and disturbance rejection (unlike traditional controllers such as PID controllers). However, there is still a need to tune the MPC controller for specific multivariable process control objectives. While the process model generally matches the internal structure of the MPC controller (e.g., the process state space with the state space MPC formulation), additional tuning parameters determine the behavior with respect to setpoint changes and disturbance rejection.

[0107] In any case, Figure 4 The operation of the DMMC block 38 in FIG. 1 assumes that new process variable measurements are available during each controller scan or execution operation of the model 105, which produces a new set of controlled variable predictions over a time horizon. When new process variable measurements of the controlled process variable (CV) are not available at each new controller scan, the operation of the controller will result in the controller performing control using stale process variable data.

[0108] Example method 500 for implementing dual-mode model based control

[0109] Figure 5 An exemplary method 500 for performing dual-mode model based control in accordance with an embodiment is illustrated. The method 500 can be performed, in whole or in part, by the system 10 shown in FIG. 1, and more particularly, by the controller 11 and DMMC block 38 shown in FIGS. 1 and 2. Figure 1 The method 500 can be performed, in whole or in part, by the system 10 shown in FIG. 1, and more particularly, by the controller 11 and DMMC block 38 shown in FIGS. 1 and 2. Figure 1 and Figure 4 The method 500 can be saved as one or more instructions or routines into memory (e.g., at the controller 11 and / or workstation 13).

[0110] The method 500 begins when a controller scan cycle begins (block 505). At the beginning of the scan cycle, the controller 11 receives a current set of measurements for the set of CVs controlled by the controller 11.

[0111] The controller 11 then initiates generation of the constrained and unconstrained solutions of the optimization problem or objective function 403 (block 507).

[0112] At block 509, the control scan cycle ends (or a decision threshold is reached before the scan cycle ends).

[0113] At block 510, the controller 11 determines whether a constrained solution has been completed formation. If the constrained solution has been completed formation, the controller 11 executes the constrained solution (block 515). If the constrained solution has not been completed formation, the controller 11 executes an unconstrained solution (block 520). If for some reason the unconstrained solution has not been formed, the controller 11 can utilize a pre-generated movement plan (e.g., calculated from a pre-generated controller matrix).

[0114] Example method 600 for generating unconstrained solutions

[0115] Figure 6 An example method 600 for executing an unconstrained solution according to an embodiment is illustrated. The method 600 can be performed, in whole or in part, by the system 10 shown in Figure 1 and more specifically by the controller 11 and DMMC block 38 shown in Figure 1 and Figure 4 The method 600 can be saved into memory (e.g., at the controller 11 and / or workstation 13) as one or more instructions or routines.

[0116] At block 605, the controller 11 feeds the process model, current PV values (e.g., MV values (e.g., received at the start of the controller scan)), predicted PV values, and control objectives (e.g., the objective function 403) to the optimizer 401 in order to start the process of generating a solution to the control objectives. In certain instances, tuning parameters and / or error vectors (e.g., representing prediction errors) can also be fed to the optimizer.

[0117] At block 607, the optimizer 401 can define one or more optimal MV values for the end of the control horizon, as well as CV targets for the end of the prediction horizon.

[0118] At block 610, the optimizer 401 and / or the controller 11 generates an unconstrained solution of the objective function 403. For example, depending on the exact nature of the objective function 403, the optimizer 401 generates a solution that minimizes or maximizes the objective function 403. In particular, the optimizer 401 generates an optimal steady-state plant operating point (e.g., represented by the steady-state process variable target set) at the end of the control range or the prediction range and a set of Pvs (e.g., CVs, AVs, and / or MVs) for each scan in the series of scans, resulting in a final scan that is evaluated according to the prediction range. For each scan in the series of scans, the set of MV targets constitutes a move schedule for that particular scan. In general, and as described elsewhere, the optimizer 401 generates a constrained solution when feasible. When not feasible, slack variables can be used. These can make certain constraints violated acceptable for generating a solution. Typically, it can be assumed that the optimizer 401 provides a constrained solution (e.g., when possible / feasible). The controller can use the steady-state solution that is constrained at the end of the prediction range, and the optimizer can form a solution that is dynamic (e.g., throughout the entire prediction range).

[0119] At block 615, the controller 11 identifies the PV constraints (e.g., constraints on CVs, AVs, or MVs).

[0120] At block 620, the controller 11 then evaluates a first move schedule in the series of move schedules included in the unconstrained solution. If any of the MV values in the first move schedule violate the MV constraints, or if the process model predicts that a CV or AV constraint will be violated in response to one of the MV moves, one or more of the MVs are adjusted until the first move schedule no longer violates the constraints. When the first move schedule no longer violates the constraints, it is considered to be “bounded” (i.e., bounded by all relevant constraints).

[0121] Note that in this example, the controller 11 and the optimizer 401 largely ignore the constraint violations that are anticipated to occur after the first move schedule. Thus, it can be the case that the “ideal” solution that does not take constraints into account can be less than the ideal trajectory of PV values when constraints are taken into account (because the prediction assumes moves that the controller 11 will not actually make in the real world). In other words, the value gained by the ability to predict future PV values is somewhat blunted because, in this particular scenario, the controller 11 can not be able to accurately predict future PV values given the fact that the controller 11 will take constraints into account (e.g., by modifying the values in the first move schedule) at every scan period when the controller 11 is outputting MV signals.

[0122] If the controller 11 is utilizing an unconstrained solution (e.g., because a constrained solution has not been formed within a scan period), the values within the defined first move plan are sent to field devices via one or more controller outputs of the controller 11 to perform control of the process.

[0123] Example method 700 for generating constrained solutions

[0124] Figure 7 An exemplary method 700 for performing a constrained solution according to embodiments is illustrated. The method 700 can be performed, in whole or in part, by the system 10 shown in Figure 1 and more specifically by the controller 11 and DMMC block 38 shown in Figure 1 and Figure 4 The method 700 can be saved to memory (e.g., at the controller 11 and / or workstation 13) as one or more instructions or routines.

[0125] At block 705, the controller 11 generates a new process model (e.g., when the process is offline). Typically, model generation is performed by capturing the dynamic relationships between inputs and outputs of the process being controlled and generating a mathematical model that reflects these dynamic relationships. Traditionally, these dynamic relationships are captured during a model generation process that involves (i) introducing a known disturbance or perturbation into the process by changing one or more manipulated variables, and (ii) observing how the process reacts to the change in the manipulated variable. When the process completes its response to the change in the manipulated variable and reaches a steady state, the controller 11 can generate a process model based on the relationship between the change in the manipulated variable and the observed process response. The controller 11 can then utilize the new (and possibly more accurate) process model to resume normal control. In certain instances, the controller 11 does not generate a new model when performing the method 700. After the model is generated, the model can be fed to the optimizer 401.

[0126] At block 707, the controller 11 feeds the current PV values (e.g., received at the beginning of a controller scan), predicted PV values, control objectives (e.g., the objective function 403), and constraints for one or more PVs (e.g., CVs, MVs, and / or AVs) to the optimizer 401 to begin the process of generating a solution for the control objectives. In certain instances, tuning parameters and / or error vectors (e.g., representing prediction errors) can also be fed to the optimizer 401.

[0127] At block 710, the controller 11 generates an unconstrained solution comprising a set of PVs for a range of scans extending into the future (e.g., by performing the steps of method 600). Each set of PVs can comprise a set of Mvs that constitute a "move plan" to be executed by the controller (at least in theory) for that particular scan. As explained in more detail below, the method 700 can use the unconstrained solution as a "candidate solution" to evaluate constraint violations, then modify it to create successive candidate solutions until a candidate solution is finally identified that does not violate any constraints.

[0128] At block 715, the controller 11 analyzes the set of PVs formed for each future scan (including the move plan for each scan).

[0129] At block 720, the controller 11 identifies a first move plan that causes a constraint violation. As an example, the third scheduled move plan can include an MV value that exceeds an MV constraint, or results in another PV that exceeds a constraint (e.g., the MV value of 78% for control valve CV821 exceeds the upper limit constraint of 75% open for CV821). If there are no constraint violations, the controller 11 proceeds to block 735 (which can occur, especially if the process is relatively early, if the constraints are particularly few or relatively lenient). Generally speaking, there is a constraint violation if any of the set of constraints associated with the DMMC block 38 are violated.

[0130] At block 725, the controller 11 determines whether all Mvs have been constrained or bounded. Generally speaking, this is only true if the controller 11 has iteratively analyzed updated solutions, as constraint violations are identified until no MV values of any of the series of move plans violate a constraint. If all Mvs have been constrained or bounded, the controller proceeds to block 735 (described in more detail below). If one or more Mvs remain unconstrained in the series of move plans, the controller 11 proceeds to block 730.

[0131] At block 730, the controller 11 feeds the allowed portion of the moves to the optimizer 401, prior to the constraint violation occurring. As with the previous example, the first two move plans are fed to the optimizer 401 along with the other previously mentioned portions.

[0132] After block 730, the controller then proceeds to block 710, in which the optimizer 401 generates a modified solution (which can be considered a new candidate solution) that assumes the first two move plans and, for subsequent move plans after the assumed move plans, does not allow the MVs to violate the previously identified constraints. For example, the same as the previous example, the optimizer 401 can generate a solution in which the value of the control valve CV821 never exceeds the upper limit constraint of 75% for any of the move plans in the series of move plans.

[0133] The controller 11 then again executes blocks 715 and 720 (and potentially 725 and 730) with the modified solution. This iterative process can continue until a modified solution or candidate solution is generated in which none of the move plans in the series of move plans violate any constraints.

[0134] At block 735, after finding that the modified unconstrained solution does not include a constraint violation, or after having traversed an entire series of move plans to find that a constraint violation results in all of the MVs being bounded, the controller 11 finally determines the constrained solution. If the original unconstrained solution did not violate any constraints, it can be used as the constrained solution. In some instances, the original unconstrained solution can only need to be slightly modified before the constrained solution is determined.

[0135] After the constrained solution has been finally determined, the controller 11 can utilize the first move plan of the constrained solution by generating a controller output to carry the values of the first move plan (e.g., to control the field devices according to the MV values of the first move plan) if there is enough time remaining in the scan cycle. Since none of the move plans in the entire series resulted in a constraint violation, there is no need to modify any of the MV values of the first move plan.

[0136] The method 700 can be considered a method for iteratively bounding the MV values included in the move plans of a solution. In other words, each time a constraint violation is identified at step 720, the next candidate solution assumes the allowed move plans of that solution and the allowed range of each MV that has previously been analyzed for a constraint violation in the series of move plans. In embodiments, each subsequent candidate solution should have one fewer unbounded MV for which a constraint violation can be identified.

[0137] Additional considerations

[0138] When implemented in software, any of the applications, services, and engines described herein can be stored in any non-transitory, tangible computer-readable medium, such as a disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage device, etc., in a RAM or ROM of a computer or processor, etc. While the example systems disclosed herein are disclosed as including software or firmware executed on hardware, it is noted that such systems are merely illustrative and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components could be implemented by hardware alone (e.g., in a purpose-built machine), or a combination of hardware and software (e.g., via field- programmable gate array(s)), or hardware and firmware (e.g., an ASIC), or software alone (e.g., web-based software running in a machine virtualization environment). While the example systems described herein are described as being implemented in software executed on a processor of one or more computers, those of ordinary skill in the art will recognize that the examples provided are not the only way to implement such a system, and that the examples provided are merely illustrative.

[0139] In particular, with reference to the methods 500-700, the described functionality can be implemented in whole or in part by the devices, circuits, or routines of the system 10 shown in FIG. 1. Each of the described methods can be implemented by a set of circuits that are either permanently or semi-permanently configured (e.g., ASIC or FPGA) to perform the logical functions of the respective method, or at least temporarily configured (e.g., one or more processors and a set of instructions or routines that represent the logical functions of the respective method saved to memory) to perform the logical functions of the respective method. Figure 1

[0140] While the application has been described with reference to particular examples, these examples are merely illustrative and not limiting of the application, as it will be apparent to those of ordinary skill in the art that numerous modifications, some of which have been suggested already, can be made without departing from the spirit and scope of the application. Additionally, while the foregoing text sets forth a detailed description of numerous different embodiments of the application, it should be understood that the scope of the application is defined by the words of the claims set forth above and equivalents thereof, and no limitation or embodiments that are not recited within the claims should be understood as limiting the scope of the application. The detailed description is to be interpreted as an example only and not in a limiting sense, as it is understood that modifications can be made to the detailed description, including by way of equivalents not foreseen at the time of the disclosure.

[0141] Throughout this specification, plural instances can implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations can be performed concurrently, and nothing depends on necessarily performing the operations in the order illustrated.

[0142] ​As used herein, any reference to “one embodiment” or “an embodiment” means that a particular element, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

[0143] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0144] Also, the phrase “wherein the system includes at least one of X, Y or Z” means that the system includes X, Y, Z, or some combination thereof. Similarly, the phrase “wherein the component is configured to perform X, Y or Z” means that the component is configured to perform X, Y, Z, or some combination thereof.

[0145] In addition, use of “a” or “an” are employed to describe elements and components of the embodiments herein. This description should be understood to form the use of one or at least one. Singular articles also include plural forms, unless explicitly stated otherwise.

[0146] In various embodiments, the hardware systems described herein can be implemented by mechanical means, or by electronic means, or by a combination of both. For example, the hardware system can include dedicated circuitry or logic (e.g., as an application-specific processor, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), to perform certain operations) that is permanently configured to perform certain operations. The hardware system can also include programmable logic or circuitry (e.g., as encompassed in a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the

[0147] Furthermore, the patent claims at the beginning of the specifications are not intended to be construed according to 35 U.S.C. § 112(f) unless a conventional "means-plus-function" claim element is explicitly recited, e.g., "a means for" or "step for" language is explicitly recited in the claim(s). At least some aspects of the systems and methods described herein are directed to improvements in computer functionality and improvements in the functioning of conventional computers.

[0148] General terms and phrases

[0149] Throughout this specification, a number of terms and phrases are used.

[0150] Communication link. Unless otherwise stated, a "communication link" or "link" is a path or medium connecting two or more nodes. A link can be a physical link or a logical link. A physical link is an interface(s) or medium over which information is transmitted and can be wired or wireless in nature. Exemplary physical links include (i) wired links, such as a cable with conductors for transmitting electrical energy or an optical fiber link for transmitting light, and (ii) wireless links, such as a wireless electromagnetic signal with information by altering one or more characteristics of an electromagnetic wave.

[0151] As noted above, a wireless link can be a wireless electromagnetic signal that carries information by altering one or more characteristics of an electromagnetic wave. The wireless electromagnetic signal can be a microwave or radio wave and can be referred to as a radio frequency or "RF" signal. Unless otherwise stated, the described RF signals can oscillate at frequencies within any one or more of the bands found in the frequency spectrum between about 30 kHz and 3,000 GHz (e.g., an 802.11 signal in the 2.4 GHz band). Exemplary RF bands include the low frequency ("LF") band of 30-300 kHz, the medium frequency ("MF") band of 300-3000 kHz, the high frequency ("HF") band of 3-30 MHz, the very high frequency ("VHF") band of 30-300 MHz, the ultra high frequency ("UHF") band of 300-3000 MHz, the super high frequency ("SHF") band of 3-30 GHz, the extremely high frequency ("SHF") band of 30-300 GHz, and the terahertz band of 300-3000 GHz.

[0152] In some cases, the wireless electromagnetic signals can be optical signals oscillating at frequencies of about 300 GHz to 30 PHz, wavelengths of about 100 nm to 1 mm, which can be: (i) ultraviolet ("UV") signals having wavelengths of about in the range of 10 nm - 400 nm and frequencies of about in the range of 750 THz - 30 PHz; (ii) visible light signals having wavelengths of about in the range of 400 nm - 700 nm and frequencies of about in the range of 430 THz - 750 THz, or (iii) infrared ("IR") signals having wavelengths of about in the range of 700 nm - 1 mm and frequencies of about in the range of 300 GHz - 430 THz. Unless otherwise noted, the described optical signals can comply with any suitable optical signal protocol or standard, such as a visible light communication (VLC) standard, a light fidelity (Li-Fi) standard, an infrared data association (IrDA) standard, an IrSimple standard, etc.

[0153] A logical link between two or more nodes represents an abstraction of the underlying physical links or intermediate nodes connecting the two or more nodes. For example, two or more nodes can be logically coupled via a logical link. The logical link can be established via any combination of physical links and intermediate nodes (e.g., routers, switches, or other networking equipment).

[0154] Links are sometimes referred to as "communication channels." In wireless communication systems, the term "communication channel" (or just "channel") generally refers to a particular frequency or frequency band. Carrier signals can be communicated at a particular frequency or within a particular frequency band of a channel. In some cases, multiple signals can be communicated on a single frequency band / channel. For example, sometimes signals can be simultaneously transmitted on a single frequency band / channel via different sub-bands or sub-channels. As another example, sometimes signals can be transmitted via the same frequency band by allocating time slots of the frequency band for use by respective transmitters and receivers.

[0155] Memory and computer-readable media. Generally speaking, the phrase "memory" or "memory device," as used herein, refers to a system or device that includes one or more computer-readable media ("CRM"). A "CRM" refers to one or more media storing information (e.g., data, computer-readable instructions, program modules, applications, routines, etc.) that can be accessed by a relevant computing system for reading, writing, or both. Note that a "CRM" refers to media that is non-transitory in nature and does not refer to non-physical, transitory signals, such as radio waves.

[0156] The CRM can be implemented in any technology, device, or group of devices, including in or in communication with the relevant computing system. The CRM can include volatile or nonvolatile media, and removable or non-removable media. The CRM can include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store information and that can be accessed by the computing system. The CRM can be communicatively coupled to the system bus, such that the CRM is able to communicate with other systems or components coupled to the system bus. In some embodiments, the CRM can be coupled to the system bus via a memory interface (e.g., a memory controller). The memory interface is a circuit that manages the flow of data between the CRM and the system bus.

[0157] Network. As used herein, unless otherwise indicated, the term “network” when used in the context of a system or device that communicates information or data refers to a collection of nodes (e.g., devices or systems capable of sending, receiving, or forwarding information) and links connecting to enable telecommunication between nodes.

[0158] Depending on the embodiment, and unless otherwise specified, each of the described networks can include dedicated routers, switches, or hubs responsible for forwarding directed traffic between nodes, and optionally, dedicated devices responsible for configuring and managing the network. Some or all of the nodes in the described networks can also be adapted to function as routers in order to direct traffic sent between other network devices. The nodes of the described networks can be connected to each other in a wired or wireless manner, and can have different routing and transport capabilities.

[0159] For example, dedicated routers can be capable of high volume transmissions, while certain nodes can be capable of sending and receiving relatively little traffic within the same time period. Additionally, connections between nodes on the described networks can have different throughput capabilities and different attenuation characteristics. For example, optical cables can provide several orders of magnitude higher bandwidth than wireless links due to differences in physical limitations inherent to the medium. If desired, each of the described networks can include networks or subnetworks, such as personal area networks (PANs), local area networks (LANs), or wide area networks (WANs).

[0160] Processor. The various operations of example methods described herein can be performed, at least partially, by one or more controllers or processors that are described or implicitly disclosed (e.g., controller 11 can include a processor). Generally, the term “processor” and “microprocessor” are used interchangeably, each referring to a computer processor configured to fetch and execute instructions stored in memory.

[0161] By executing these instructions, the disclosed processors can perform various operations or functions defined by the instructions. Depending on the particular embodiment, the disclosed processors can be temporarily configured (e.g., by instructions or software) or permanently configured (e.g., for a special-purpose integrated circuit or ASIC) to perform the relevant operations or functions. Each disclosed processor can be part of a chip set, which can also include, for example, memory controllers or I / O controllers. A chip set is a set of electronic components, typically integrated circuits, that are configured to provide I / O and memory management functions as well as a number of general purpose or special purpose registers, timers, etc. Generally, one or more of the described processors can be communicatively coupled to other components (e.g., memory devices and I / O devices) via a system bus.

[0162] The performance of certain of the operations can be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some embodiments, the one or more processors can be located in a single location (e.g., within a home environment, an office environment, or as a server farm), while in other embodiments the processors can be distributed across many locations.

[0163] Words such as“process,”“computing,”“calculate,”“determine,”“present,”“display,” and the like can refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms a physical (e.g., electronic, magnetic, or optical) quantity within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof) registers, or other machine component, receiving, storing, transmitting, or displaying information.

[0164] Routines. Unless otherwise specified, a“routine,”“module,” or“application” described in the present disclosure refers to a set of computer-readable instructions that can be stored on a CRM. Generally, the CRM stores computer-readable code (“code”) representing or corresponding to the instructions, and the code is adapted to be executed by a processor to facilitate the functions described as being represented by or associated with the routine or application. Each routine or application can be implemented via a standalone executable file, a suite or bundle of executable files, one or more non-executable files used in conjunction with an executable file or program, or some combination thereof. In some cases, one or more of the described routines can be hard-coded into one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other hardware or firmware elements, unless otherwise specified.

[0165] Further, unless otherwise specified, each routine or application can be embodied by: (i) a standalone software program, (ii) a module or sub-module of a software program, (iii) a routine or sub-routine of a software program, or (iv) a resource that the software program invokes or accesses through an "invocation" such that the system implements a task or function associated with the resource. The invocation can be (i) a "function call" invoked to cause execution of a resource (e.g., a set of instructions) stored in a library accessible to the software program; (ii) a "system call" invoked to cause a system resource to execute (e.g., typically running in privileged kernel space and only executable by the operating system); (iii) a "remote call" invoked to cause a logical or physical entity having a different address space to execute the resource; or (iv) some combination thereof. As an example, a routine executed by a processor of a device can invoke a "remote call" to cause execution at (i) a second device (e.g., a server host, an end user device, a networked device, a peripheral device in communication with the device, or some other physical device); (ii) a virtual machine on the same or a different device; (iii) a processor (e.g., CPU or GPU) different from the original processor and possibly internal or external to the device executing the routine; or (iv) some combination thereof.

[0166] Each routine can be represented by code implemented in any desired language of implementation, such as source code (e.g., interpretable or compilable to lower level code), object code, byte code, machine code, microcode, etc. Any suitable programming or scripting language can be used, such as C, C++, Java, Actionscript, Objective-C, Javascript, CSS, Python, XML, Swift, Ruby, Elixir, Rus, Scala, or other languages.

Claims

1. A method comprising: (A) performing model-based control of a process represented by a set of process variables (PVs) including (i) a set of manipulated variables (MVs) adjustable by a process controller via one or more field devices, and (ii) a set of controlled variables (CVs) each dependent on one or more of the set of manipulated variables (MVs), via the process controller coupled to the one or more field devices; (B) at a beginning of a scan cycle, initiating a scan by the process controller to obtain a current set of measured values of the controlled variables (CVs); (C) prior to an end of the scan cycle, performing a dual-mode operation including selecting, in accordance with a process model and a set of constraints on the process variables (PVs), a current move plan for the set of manipulated variables (MVs) to be executed by the process controller, including: (i) using the current set of measured values of the set of controlled variables (CVs) as model inputs to the process model, initiating generation of: (a) an unconstrained solution including a series of unbounded move plans not bounded by the set of constraints, and (b) a constrained solution including a series of bounded move plans that avoid violating any of the set of constraints; (ii) when the constrained solution is generated prior to the end of the scan cycle: selecting a first move plan from the series of bounded move plans of the constrained solution as the current move plan; and (iii) when the constrained solution is not generated prior to the end of the scan cycle: selecting a first move plan from the series of unbounded move plans of the unconstrained solution as the current move plan; and (D) prior to the end of the scan cycle, performing control of the process by setting the set of manipulated variables (MVs) to a set of values included in the current move plan via the steps of: sending a set of controller outputs carrying the set of values to the field devices to cause the field devices to drive the set of manipulated variables (MVs) to the set of values.

2. The method of claim 1, wherein, Selecting the first move plan from the series of unbounded move plans of the unconstrained solution as the current move plan includes, when any value included in the first move plan violates a constraint, modifying the first move plan so that the first move plan no longer causes a constraint violation.

3. The method of claim 1, wherein, The scan period is a first scan period, wherein the method further comprises: after the first scan period ends, initiating a next scan at the beginning of a second scan period to obtain a next set of measurement values of the controlled variables (CVs), and again performing a dual-mode operation to select a second current move schedule for the next scan, including: (i) using a second current set of measurement values of the controlled variables (CVs) as model inputs to the process model, initiating generation of: (a) a second unconstrained solution including a series of unbounded move schedules that are not bounded by the set of constraints, and (b) a second constrained solution including a series of bounded move schedules that avoid violating any of the set of constraints; (ii) when the second constrained solution is generated before the second scan period ends: selecting a first move schedule from the series of bounded move schedules of the second constrained solution as the second current move schedule; and (iii) when the second constrained solution is not generated before the second scan period ends: selecting a first move schedule from the series of unbounded move schedules of the second unconstrained solution as the second current move schedule.

4. The method of claim 1, wherein, The scan period is a regular scan period, which is the same length at each scan.

5. The method of claim 1, wherein, The scan period is configured to vary according to the scan.

6. The method of claim 1, wherein, The one or more field devices include a control valve actuator, and wherein at least one of the manipulated variables (MVs) is a variable representing valve position.

7. The method of claim 1, wherein, Initiating generation of the constrained solution includes: starting from the unconstrained solution, and iteratively modifying the unconstrained solution to exclude values that cause constraint violations.

8. The method of claim 1, wherein, Initiating generation of the constrained solution includes: starting from a pre-generated series of move schedules, and iteratively modifying the pre-generated move schedules to exclude values that cause constraint violations.

9. A system comprising: one or more field devices for monitoring or controlling a process; and a process controller communicatively coupled to the one or more field devices and configured to control the process, wherein the process is represented by a set of process variables (PVs) including (i) a set of manipulated variables (MVs) adjustable by the process controller via the one or more field devices, and (ii) a set of controlled variables (CVs) each dependent on one or more of the set of manipulated variables (MVs); wherein the process controller is configured to perform a dual-mode model control operation to select, from a process model and a set of constraints on the process variables (PVs), a current move plan for the set of manipulated variables (MVs) to be executed by the process controller, wherein the process controller is configured to: (A) at a beginning of a scan cycle, initiate a scan by the process controller to obtain a current set of measured values of the controlled variables (CVs); (B) before an end of the scan cycle: (i) using the current set of measured values of the set of controlled variables (CVs) as model inputs to the process model, initiate generation of: (a) an unconstrained solution including a set of unbounded move plans not bounded by the set of constraints, and (b) a constrained solution including a set of bounded move plans that avoid violating any of the set of constraints; (ii) when the constrained solution is generated before the end of the scan cycle: select a first move plan from the set of bounded move plans of the constrained solution as the current move plan; and (iii) when the constrained solution is not generated before the end of the scan cycle: select a first move plan from the set of unbounded move plans of the unconstrained solution as the current move plan; and (C) before the end of the scan cycle, perform control of the process by setting the set of manipulated variables (MVs) to a set of values included in the current move plan via sending a set of controller outputs carrying the set of values to the field devices to cause the field devices to drive the set of manipulated variables (MVs) to the set of values.

10. The system of claim 9, wherein, the process controller is configured to select the first move plan from the set of unbounded move plans of the unconstrained solution as the current move plan by modifying the first move plan when any value included in the first move plan violates a constraint so that the first move plan no longer causes a constraint violation.

11. The system of claim 9, wherein, The scan period is a first scan period, wherein the process controller is further configured to: after the first scan period ends, initiate a next scan at a beginning of a second scan period to obtain a next set of measurement values of the controlled variable (CV), and again perform the dual-mode operation to select a second current move schedule for the next scan, including: (i) using a second current set of measurement values of the controlled variable (CV) set as model inputs to the process model, initiate generation of: (a) a second unconstrained solution including a set of unbounded move schedules that are not bounded by the constraint set, and (b) a second constrained solution including a set of bounded move schedules that avoid violating any of the constraint set; (ii) when the second constrained solution is generated before the second scan period ends: select a first move schedule from the set of bounded move schedules of the second constrained solution as the second current move schedule; and (iii) when a second constrained solution is not generated before the second scan period ends: select a first move schedule from the set of unbounded move schedules of the second unconstrained solution as the second current move schedule.

12. The system of claim 9, wherein, The scan period is a regular scan period, which is the same length at each scan.

13. The system of claim 9, wherein, The scan period is configured to vary according to the scan.

14. The system of claim 9, wherein, The one or more field devices include a control valve actuator, and wherein at least one of the manipulated variables (MV) is a variable representing valve position.

15. The system of claim 9, wherein, Initiating generation of the constrained solution includes: starting from the unconstrained solution, and iteratively modifying the unconstrained solution to exclude values that cause constraint violations.

16. The system of claim 9, wherein, Initiating generation of the constrained solution includes: starting from a pre-generated set of move schedules, and iteratively modifying the pre-generated move schedules to exclude values that cause constraint violations.

17. A method comprising: (A) performing a dual-mode model-based process controller configured to control one or more field devices in a process control environment; (B) initiating, by the model-based controller, a scan to obtain a current set of values for a set of process variables (PVs) representing a current state of a controlled process, the process variables including a plurality of controlled variables (CVs) and a plurality of manipulated variables (MVs); (C) generating, by the process model, an unconstrained solution to an optimization problem using the process model to generate a series of move plans for the plurality of manipulated variables (MVs) to achieve a predetermined target without regard to whether any of the series of move plans violates any of a set of constraints on the process variables (PVs) such that a value of each manipulated variable (MV) in each move plan in the series of move plans is not bounded by the set of constraints; (D) initiating, by the process model, generation of a constrained solution to the optimization problem by: (i) storing the unconstrained solution as a candidate solution; (ii) bounding, from the plurality of manipulated variables (MVs), a first manipulated variable (MV) by analyzing the candidate solution to: (a) identify a first violation of a constraint and determine that the first manipulated variable (MV) caused the first violation; and (b) calculate an allowable range for the first manipulated variable (MV) based on one or more values of the first manipulated variable (MV) included in a move plan scheduled prior to the first violation; (iii) bounding, from the plurality of manipulated variables (MVs), remaining manipulated variables (MVs) by generating, in an iterative manner, modified candidate solutions including a series of move plans modified for each remaining manipulated variable (MV) such that each modified candidate solution keeps previously bounded manipulated variables (MVs) within the calculated allowable range and such that each subsequent modified candidate solution includes one less unbounded manipulated variable (MV) than a previous modified candidate solution, wherein the remaining manipulated variables (MVs) are bounded in an order that is based on which of the remaining manipulated variables (MVs) first violates a constraint for each modified candidate solution; and (iv) after each of the plurality of manipulated variables (MVs) has been defined such that the most recently modified candidate solution includes a final set of move plans that do not violate any of the set of constraints, finalizing the constrained solution by storing the most recently modified candidate solution as the constrained solution; (E) when a scan period expires before the constrained solution is finalized: (i) in a first move plan without a constraint solution, modifying any values that violate any of the set of constraints to achieve a defined first move plan that does not violate any of the set of constraints, and (ii) using the defined first move plan without a constraint solution for a set of controller outputs to control the one or more field devices according to the defined first move plan; and (F) when the constrained solution is finalized before the scan period expires, using a first move plan of the constrained solution for the set of controller outputs to control the one or more field devices according to the defined first move plan.

18. The method of claim 17, further comprising: initiating a second scan by the model-based controller to obtain a second current set of values of the set of process variables (PVs); using the second current set of values of the set of process variables (PVs) to generate a second unconstrained solution of the optimization problem; using the second current set of values of the set of process variables (PVs) to initiate generation of a second constrained solution of the optimization problem; when the constrained solution is finalized before the end of a second scan period, using the constrained solution to generate a set of control outputs; and when the constrained solution is not finalized before the end of the second scan period, using the unconstrained solution to generate the set of control outputs.

Images