Dual-mode model-based control of processes

Abstract

To avoid a sudden reduction in performance caused by mismatching of process models.SOLUTION: The disclosed systems and techniques enable dual mode operation for model-based controllers in which the controllers are capable of operating in both (i) a constrained solution mode, and (ii) an unconstrained solution mode. The dual mode operation improves control because it enables the use of constrained solution mode operation when possible (constrained solution mode often enables superior control) and enables the use of unconstrained solution mode when constrained solution mode is not possible (e.g., when it is impossible to develop the constrained solution with the time available). This enables superior control when compared to typical model predictive control (MPC) controllers.SELECTED DRAWING: None

Description

[Technical field]

[0001] The present disclosure relates generally to utilizing model-based predictive control, and more specifically, to utilizing dual operating modes that simultaneously generate constrained and unconstrained solutions to an optimization problem. [Background technology]

[0002] A distributed process control system, such as a distributed or scalable process control system such as those used in power generation, chemical, petroleum, or other processes, typically includes one or more process controllers communicatively coupled to each other via a process control network, to at least one host or operator workstation, and to one or more instrumentation or field devices via analog, digital, or combined analog / digital buses.

[0003] Field devices perform functions within a process or plant, such as opening and closing valves, switching devices on and off, and measuring process parameters. Examples of field devices include valves, valve positioners, switches, and transmitters (e.g., devices that include sensors for measuring temperature, pressure, or flow, and transmitters for transmitting the sensed temperature, pressure, and flow).

[0004] A process controller, typically located within a plant environment, executes a controller application that executes different control modules that receive signals indicative of process measurements made by (or other information regarding) the field devices and, for example, make process control decisions and generate control signals based on the received information, and interface with control modules or blocks implemented in smart field devices (e.g., HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices).

[0005] Execution of the control modules causes the process controller to send control signals over communication links or signal paths to the field devices to thereby control the operation of at least a portion of a process plant or system (e.g., control at least a portion of one or more industrial processes running or executing within the plant or system). For example, a first set of controller(s) and field devices may control a first portion of a process being controlled by the process plant or system, and a second set of controller(s) and field devices may control a second portion of the process.

[0006] A network formed by one or more controllers, field devices communicatively connected to the one or more controllers, and intermediate nodes that facilitate communication between the controllers and the field devices may be referred to as an "I / O network" or "I / O subsystem."

[0007] Information from the I / O network(s) may be available via a data highway or communication network to one or more other hardware devices, such as operator workstations, personal computers or computing devices, handheld devices, data historians, report generators, centralized databases, or other centralized management computing devices that are typically located in a control room or other location away from the harsher field environment of the plant, e.g., in the back-end environment of a process plant.

[0008] Information communicated over a process control network enables an operator or maintenance personnel to perform desired functions with respect to a process via one or more hardware devices connected to the network. These hardware devices may execute applications that allow, for example, an operator to change settings of process control routine(s), modify the operation of control modules in a process controller or smart field device, view the current state of a process or the status of specific devices in a process plant, view alarms generated by field devices and process controllers, simulate the operation of a process for purposes of training personnel or testing process control software, diagnose problems or hardware failures in a process plant, etc. The process control network or data highway utilized by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0009] As an example, the DeltaV™ control system and the Ovation™ distributed control system (DCS) sold by Emerson each include multiple applications stored in and executed by different devices located at various locations within a process plant. Configuration applications resident in one or more workstations or computing devices within the back-end environment of the process control system or plant allow users to create or modify process control modules and download these process control modules over a data highway to a dedicated distributed controller. Typically, these control modules are composed of communicatively interconnected function blocks that are objects in an object-oriented programming protocol that (i) perform functions within a control scheme based on inputs to the function block, and (ii) provide outputs to other function blocks in the control scheme. The configuration application may also enable the configuration designer to create or modify operator interfaces that are used by the visibility application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines.

[0010] Each dedicated controller (and possibly one or more field devices) stores and executes a respective controller application that executes the control modules assigned to and downloaded thereto to implement the actual process control functions. A visibility application may execute on one or more operator workstations (or one or more remote computing devices communicatively connected to the operator workstations and the data highway) and may receive data over the data highway from the controller applications and display this data to a process control system designer, operator, or user using a user interface to provide any of several different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided over the data highway, while a configuration database application may execute on an even more remote computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.

[0011] In addition to the process controllers, I / O cards, and field devices, a typical process control system includes many other support devices necessary or related to the operation of the process. These additional devices include, for example, power equipment, power generation and distribution equipment, rotating equipment such as turbines, which are located in many locations within a typical plant.

[0012] With respect to process controllers, controllers can be broadly categorized into two categories: conventional controllers (such as PID controllers) and model-based controllers (such as MPC controllers). Each of these types of controllers can control a process, which may be characterized as having one or more process outputs (e.g., flow rate, 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 conventional controllers, such as PID controllers, because model-based controllers can implement more effective control than conventional controllers when controlling complex processes. This may 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 typically manipulate process inputs (which may be called "manipulated variables") to change the process output (which may be called the "controlled variable" or simply the "process variable") based on feedback (i.e., measured values ​​of the controlled variables) and a desired value for the process output (i.e., set point).

[0014] In comparison, model-based controllers (e.g., model predictive controllers or MPCs) as described herein have advantages over traditional controllers such as PID controllers in that the model-based controller can predict future states of a process based on a process model that represents the dynamic relationship between the process inputs and the process outputs of the process being controlled. That is, the model-based controller can implement control based not only on feedback and desired values ​​of the process outputs, but also on predicted future values ​​of the process outputs, which the controller predicts or looks forward to based on the process model and measurements of the process outputs. Thus, model-based controllers can consider potential future events in a manner not possible with traditional controllers, and can be particularly effective in controlling complex processes with significant multivariable interactions (e.g., when a change in a single manipulated variable or process output affects the value(s) of multiple other process outputs).

[0015] While model-based controllers provide many desirable performance characteristics, 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 the 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 rapidly 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, the process model mismatch generally needs to be corrected.

[0016] Typically, model-based controllers correct process model inconsistencies by generating a new process model during a model identification or generation procedure, so that the new process model matches the current characteristics of the process. Unfortunately, model generation can be problematic because it often involves interrupting normal control of the process. As noted above, the process models used by model-based controllers generally represent the dynamic relationships between the inputs and outputs of the process being controlled. Traditionally, these dynamic relationships are captured during a model generation procedure, which involves (i) introducing known disturbances or perturbations to the process by changing one or more manipulated variables, and (ii) observing how the process responds to the changes to the manipulated variables. Once the process has finished responding to the changes in the manipulated variables and reached a steady state, the controller can generate a process model based on the relationships between the changes in the manipulated variables and the observed process response. The controller can then resume normal control utilizing the new (and possibly more accurate) process model.

[0017] Unfortunately, model generation often involves interrupting the normal control of the process to introduce known disturbances as mentioned above, which can be problematic. In particular, interrupting normal control typically has a detrimental effect on the operation of the process, which can result in wasted materials or time. In some cases, this detrimental effect can be amplified by the very time-consuming generation of the model. For example, model generation can take a very long time for certain slow processes, where the process variables may take minutes, hours, or even days to reach their setpoint or final resting value. Furthermore, model-based controllers may require frequent model regeneration because process characteristics often change over time due to equipment failure or degradation, atmospheric changes, raw material changes, etc. In short, the process control industry has been slow to fully embrace model-based control because the model generation process (which traditionally involves interrupting normal operation, introducing disturbances, observing the process response until the process reaches steady state, and generating a model based on compliance) can take a long time, which can result in interference with normal operating objectives.

[0018] In any case, model-based controllers have seen limited adoption because, aside from issues with process model mismatch, it can be difficult to develop precise and accurate predictions within a limited time frame. Generally speaking, process controllers are configured to send controller outputs to field devices at very regular intervals (e.g., every few seconds to every few minutes). Ideally, model-based controllers develop accurate predictions through several intervals into the future. However, due to the fact that developing these precise and accurate predictions within a given time interval can be difficult (especially for complex processes with multiple interacting inputs and outputs), the benefits that might otherwise be obtained by implementing model-based control are reduced or negated. As a result, process plants often rely on traditional control techniques rather than model-based control techniques.

[0019] It should be noted that this Background Description provides a context to facilitate understanding and appreciation of the Detailed Description that follows. The work of the presently named inventors to the extent described in this Background section (as well as aspects of the Background Description that may not otherwise be considered prior art at the time of filing) are not admitted expressly or impliedly as prior art to the present disclosure. Summary of the Invention

[0020] The disclosed systems and techniques enable dual modes of operation for model-based controllers where the controller can operate in both (i) a constrained solution mode and (ii) an unconstrained solution mode. The dual modes of operation improve control by allowing the use of constrained solution mode operation when possible (the constrained solution mode often allows for superior control) and the use of the unconstrained solution mode when the constrained solution mode is not possible (e.g., when it is not possible to develop a constrained solution in the available time). This allows for superior control when compared to typical model predictive control (MPC) controllers.

[0021] In one embodiment, the method includes any one or more of: (A) implementing, 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), the set 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 MVs in the set of MVs; (B) initiating a scan by the process controller at a start of a scan period to obtain a current set of measurements of the CVs; (C) implementing a dual mode of operation, the dual mode including selecting, before the scan period ends, a current move plan to be implemented by the process controller for the set of MVs according to the process model and a set of constraints for the PVs; and (D) implementing control of the process before the scan period ends by setting the set of MVs to the set of values ​​included within the current move plan by sending a set of controller outputs having a set of values ​​to the field devices to cause the field devices to drive the set of MVs to the set of values. Implementing the dual mode of operation may include (i) using the current set of measurements of the set of CVs as model input for the process model to initiate generation of both (a) an unconstrained solution including a set of unconstrained move plans that are not constrained by the set of constraints, and (b) a constrained solution including a set of constrained move plans that avoid violating any of the set of constraints. Implementing the dual mode of operation may further include (ii) selecting a first move plan from the set of constrained move plans of the constrained solution as a current move plan when a constrained solution is generated before the end of the scanning period, and (iii) selecting a first move plan from the set of unconstrained move plans of the unconstrained solution as a current move plan when a constrained solution is not generated before the end of the scanning period.

[0022] In one embodiment, the method includes any one or more of: (A) implementing a dual mode model-based process controller configured to control one or more field devices in a process control environment; (B) initiating a scan by the model-based controller to obtain a set of current values ​​for a set of process variables (PVs), where the set of current values ​​represents 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 an unconstrained solution to the optimization problem utilizing the process model by generating, using the process model, a series of move plans for a plurality of MVs to achieve a predetermined objective, such that values ​​for each MV in each of the series of move plans are not limited by the set of constraints, regardless of whether any of the series of move plans violates any of a set of constraints for the PVs; and (D) initiating generation of a constrained solution to the optimization problem utilizing the process model.

[0023] Initiating generation of the constrained solution may include any one or more of: (i) storing the unconstrained solution as a candidate solution; and (ii) constraining the first MV from the plurality of MVs by analyzing the candidate solutions to (a) identify a first violation of the constraint and determine that a first MV caused the first violation; and (b) calculating a tolerance for the first MV based on one or more values ​​for the first MV included in the scheduled movement plan before the first violation. Generating the constrained solution may further include (iii) constraining the remaining MVs from the multiple MVs by iteratively generating modified candidate solutions including a modified set of movement plans for each remaining MV such that each modified candidate solution maintains the previously constrained MV within the calculated tolerance range and each successive modified candidate solution includes one less unconstrained MV than the previous modified candidate solution, where the remaining MVs are constrained in an order based on which of the remaining MVs first violates a constraint for each modified candidate solution; and (iv) determining the constrained solution by storing the last modified candidate solution as a constrained solution after each of the multiple MVs has been constrained to include a final set of movement plans that do not violate any of the set of constraints. The method may further include any one or more of: (E) when the scan period expires before a constrained solution is determined, (i) modifying any values ​​in the first movement plan for the unconstrained solution that violate any of the set of constraints to achieve a constrained first movement plan that does not violate any of the set of constraints, and (ii) utilizing the constrained first movement plan of the unconstrained solution for the set of controller outputs to control one or more field devices in accordance with the constrained first movement plan; and (F) when the constrained solution is determined before the scan period expires, utilizing the first movement plan of the solution constrained for the set of controller outputs to control one or more field devices in accordance with the constrained first movement plan.

[0024] It should be noted that this summary is provided to introduce a selection of concepts that are further described below in the Detailed Description. As described in the Detailed Description, particular embodiments may include features and advantages that are not described in this Summary, and particular embodiments may omit one or more features or advantages described in this Summary. [Brief description of the drawings]

[0025] Each of the figures described below illustrates one or more aspects of the disclosed system(s) or method(s), according to an embodiment. The detailed description refers to the reference numerals included in the following figures.

[0026] [Figure 1] FIG. 1 is a block diagram of a process control system including a controller having a dual-mode model-based control (DMMC) block that may be implemented to control a process. [Diagram 2] 2 illustrates an example PID control routine that does not enable any of the predictive control or corresponding advantages associated with the dual mode model control provided by the DMMC block shown in FIG. 1 . [Diagram 3] 3 is a graph illustrating an example model-based control operation that may be implemented by the controller shown in FIG. 1, which offers many advantages over conventional feedback control techniques such as that shown in FIG. 2 and associated with the control loop. [Figure 4] FIG. 2 is an exemplary schematic diagram of the dual-mode model-based control loop also shown in FIG. [Diagram 5] 1 illustrates an exemplary method for implementing dual-mode model-based control. [Figure 6] 1 illustrates an exemplary method for implementing an unconstrained solution. [Figure 7] 1 illustrates an exemplary method for implementing a constrained solution. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] The disclosed systems and techniques enable dual modes of operation for model-based controllers where the controller can operate in both (i) a constrained solution mode and (ii) an unconstrained solution mode. The dual modes of operation improve control by allowing the use of constrained solution mode operation when possible (the constrained solution mode often allows for superior control) and the use of the unconstrained solution mode when the constrained solution mode is not possible (e.g., when it is not possible to develop a constrained solution in the available time). This allows for superior control when compared to typical model predictive control (MPC) controllers.

[0028] Exemplary Process Control Environment 1 may be used to implement the dual-model model-based control methods described herein to control a process. The controlled process may be any suitable process and may be said to have one or more "process outputs" (e.g., tank levels, flow rates, material temperatures, etc.) that characterize the state of the process, and one or more "process inputs" (e.g., various environmental conditions and actuator states, operations that may change the process outputs).

[0029] 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 may be of any type, such as personal computers, workstations, etc.), each having a display screen 14. The controller 11 is also connected to the field devices 15-22 via input / output (I / O) cards 26 and 28. The data historian 12 may be any desired type of data collection unit having any desired type of memory for storing data, and any desired or known software, hardware, or firmware. In FIG. 1, the controller 11 is communicatively connected to the field devices 15-22 using a hardwired communication network and communication scheme.

[0030] Generally, the field devices 15-22 may be any type of device, such as sensors, valves, transmitters, positioners, etc., while the I / O cards 26 and 28 may be any type of I / O device conforming to any desired communication or controller protocol. The controller 11 includes a processor 23 that implements or oversees one or more process control routines (or any modules, blocks, or subroutines thereof) stored in a memory 24. Generally speaking, the controller 11 communicates with the devices 15-22, the host computer 13, and the data historian 12 to control a process in any desired manner. Additionally, the controller 11 implements a control strategy or scheme using what are generally referred to as function blocks, each of which is an object or other portion (e.g., a subroutine) of an overall control routine that operates with other function blocks (through communications referred to as links) to implement a process control loop within the process control system 10. A function block typically performs one of the following: an input function, such as associated with a transmitter, sensor, or other process parameter measurement device; a control function, such as associated with a control routine implementing PID, MPC, fuzzy logic, etc., a control technique, or an output function that controls the operation of some device, such as a valve, to perform some physical function within the process control system 10. Of course, hybrid and other types of function blocks exist and may be utilized herein. The function blocks may be stored and executed in the controller 11 or other devices, as described below.

[0031] Single Loop Control Loops 32 and 34 Examples As indicated by enlarged block 30 in FIG. 1, controller 11 may include several single-loop control routines, shown as control routines 32 and 34, and may also implement one or more advanced control loops, shown as control loop 36, if desired. Each such control loop is typically referred to as a control module. Single-loop control routines 32 and 34 are shown to perform 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 that may be associated with process control devices such as valves, measurement devices such as temperature and pressure transmitters, or any other devices within process control system 10.

[0032] An example of advanced control loop 36 and dual mode model control Although the advanced control loop 36 is shown to include a dual-mode model-based control (DMMC) block or routine 38 having inputs communicatively connected to one or more AI function blocks and outputs communicatively connected to one or more AO function blocks, the inputs and outputs of the DMMC block 38 may 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.).

[0033] The DMMC block 38 may implement the dual-mode model-based control techniques described herein. More generally, the DMMC block 38 may implement any type of multi-input, multi-output control scheme and / or may implement a process model-based control routine, and thus may comprise 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.

[0034] It will be understood that the function blocks shown in FIG. 1, including the DMMC block 38, may be executed by the stand-alone controller 11 or, alternatively, may be located within and executed by any other processing device or control element of the process control system 10, such as one of the workstations 13 or one of the field devices 19-22. As an example, the field devices 21 and 22 may be a transmitter and a valve, respectively, and may also execute control elements for implementing control routines and thus may include processing components and other components for executing portions of the control routines, such as one or more function blocks. More specifically, as illustrated in FIG. 1, the field device 21 may have a memory 39A for storing logic and data associated with an analog input block, while the field device 22 may include an actuator having a memory 39B for storing logic and data associated with a PID, MPC, or other control block in communication with an analog output (AO) block.

[0035] As mentioned, the controller 11 can implement the DMMC block 38 to implement dual mode model-based control. A process controlled by the dual mode controller 11 (sometimes simply referred to as "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 the controller output, (ii) controlled variables or CVs (e.g., water tank temperature controlled by adjusting the valve position for a cold water inlet valve), (iii) auxiliary variables or AVs (e.g., water tank levels) that can be indirectly affected by changes in the CVs or MVs, and (iv) disturbance variables or DVs (e.g., the ambient temperature of a room can slightly affect the temperature of the water tank). Generally speaking, when implementing model-based control (in a constrained or unconstrained solution mode), the controller 11 uses all CV measurements to simultaneously calculate all MVs.

[0036] In one embodiment, the controller 11 operates according to a scan period k (e.g., 1 minute). Every instant k (e.g., every minute), the controller 11 receives a controller input conveying the measured PV (e.g., CV and / or AV). Based on the current measurements, the controller relies on a process model to predict future values ​​of the PV and develops a "move plan" for the MV to help drive the CV and / or AV to the desired values. At the end of the scan period, the controller 11 transmits the MV values ​​in the move plan to the field device (e.g., valve actuator) via a control signal or controller output. The controller 11 then receives the measured PV again and repeats the process.

[0037] As described herein, a "movement plan" refers to a set of values ​​for a set of MVs controlled by the controller 11 that are implemented at the end of each scan period. Whether in a constrained or unconstrained solution mode, the controller 11 may compute a set of motion plans that extend into the future during each scan period. Generally speaking, a "constrained motion plan" includes a set of MVs that do not result in any immediate constraint violations (i.e., the MV values ​​do not violate any MV constraints and the corresponding predicted CV or AV responses do not immediately violate constraints). On the other hand, an "unconstrained motion plan" may include MV values ​​that violate MV constraints or result in constraint violations (e.g., CVs and AVs) because they have been generated without considering constraints. Note that future motion plans after the first motion plan are typically not implemented because the controller 11 typically recalculates a set of motion plans for each scan as part of the calculation of the optimal solution.

[0038] "Optimization" occurs by developing a "solution" to an "objective function." Generally speaking, an "objective function" is an equation that can be solved to determine any useful metric (e.g., often profit). An example of an objective function might be the equation "profit=24x+20y," where x is a widget of a first type and y is a widget of a second type. Depending on the nature of the objective function (in the previous example, the goal is to maximize profit), an optimal solution may be found by minimizing or maximizing the objective function. Identifying an optimal solution involves evaluating a large number of candidate solutions.

[0039] As described herein, a "solution" to an optimization problem or objective function refers to a solution developed by an optimization algorithm or routine, which may be implemented by the controller 11 or a computing device in communication with the controller 11. A "solution" may be characterized as a set of target values ​​for a set of PVs at the steady state operating point of the process at the ends of the control or prediction horizon of the controller 11, and a set of values ​​for the PVs (e.g., for the MVs, CVs, and AVs) for each controller scan or controller interval between the current state of the process and the ends of the horizon. The "prediction horizon" represents the number of scans into the future that are evaluated by the optimizer, while the "control horizon" represents the number of scans into the future that MV values ​​are predicted to be output, i.e., the control horizon represents the number of possible "move plans" for the MVs being evaluated.

[0040] As an example, if the prediction horizon is 10 and the control horizon is 5, then the solution may include 10 sets of target values ​​for the PVs (including 5 movement plans to be implemented in the next 5 scans, each movement plan including a set of values ​​for the MVs). In any case, the controller 11 may develop either or both of the "unconstrained solution" and the "constrained solution", sometimes simultaneously.

[0041] During optimization of the unconstrained solution, the controller 11 generates controller outputs (communicating MV values ​​to field devices) based on a first move plan included in the unconstrained solution. The controller 11 can develop the unconstrained solution by feeding the optimizer with: (i) a pre-generated process model (typically generated offline) generated to model the process at the time of generation; (ii) the current process variable values; and (iii) one or more control objectives. The optimizer identifies a solution for an objective function to reach steady-state values ​​for the process variables, as well as target values ​​for the process variables at each of many "moves" implemented 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 "constrains" the set of desired values ​​in the first move plan if any of the values ​​would violate a constraint or result in a violation of a constraint (e.g., of a CV or AV). The controller 11 can then send controller output signals communicating the "constrained" values ​​of the first move plan to the field devices to implement control of the process.

[0042] In comparison, constrained solution optimization can provide superior control when conditions are right. During constrained solution optimization, the controller 11 generates controller outputs by (i) developing a process model in real time when possible, and (ii) feeding the optimizer the following: (a) the current process model with the current process variable values, (b) the control objectives, and (c) the constraints for all process variables (e.g., all CVs, AVs, MVs, and DVs). The optimizer develops a constrained solution (e.g., including target CVs, AVs, and MVs during each scan period) by first computing an unconstrained solution. The optimizer then identifies the first MV in the set of move plans that is constrained in time (i.e., finds the earliest MV constraint violation). An acceptable portion of this MV move plan is then imposed on the problem. The controller 11 then recalculates 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 procedure, a set of controller outputs that do not cause constraint violations is identified. This process is computationally intensive, especially compared to the unconstrained solution mode, during which the controller 11 calculates a relatively simple solution that requires a relatively short online execution time.

[0043] Constrained solution optimization has at least two advantageous features. First, a control matrix or model may be generated online at each control cycle. All dependent variables (e.g., CVs and AVs) are included in the dynamic matrix in the move calculation. An error penalty (PE) for each dependent variable is adjusted at each control cycle. If a CV is far from the limit, its PE may be set to zero, effectively removing it from the dynamic control problem. Conversely, if a CV is close to the limit, the full value of the PE may be used. This may result in the dynamic move calculation at each control cycle including only CVs that are close to the limit and excluding CVs that are far from the limit.

[0044] A second advantage is the enforcement of MV constraints on future movement plans. This prevents the controller 11 from planning movements that it cannot implement. As mentioned, 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 (find the earliest MV constraint violation). An acceptable portion of this MV movement plan is then imposed on the problem. An unconstrained solution using the remaining MVs is then computed, and this process is repeated until either all MVs are constrained or the unconstrained solution does not violate any constraints.

[0045] The dual mode controller 11 can operate in two modes simultaneously. First, a constrained solution may be obtained having a complete sequence of movement plans to the end of the prediction or control range, with all relevant PVs being constrained throughout the entire sequence of movement plans. The MV values ​​in the first movement plan in the constrained solution may be utilized for the controller output. Second, an unconstrained solution may be obtained, with the controller 11 being able to modify the MV values ​​in the first movement plan as necessary to avoid violating the constraints.

[0046] Generally speaking, the "output selector" of the controller 11 can select a first MV movement plan from either the constrained or unconstrained solution at the end of a control scan. The first priority is generally the constrained solution. However, if the constrained solution has not been completed or finalized by the end of the controller scan, the controller 11 will use the first movement plan of the unconstrained solution and adjust the unconstrained first movement plan as necessary to avoid violating any constraints.

[0047] It should be noted that although the techniques described herein are referred to as "dual mode," it is recognized that the controller 11 may also be considered to implement "triple mode" control. That is, the controller 11 may determine the controller output MV values ​​from three separate first movement plans. First, at the end of the controller scan, the controller 11 may select the MV values ​​from the first movement plan of the constrained solution, if available. Second, if the constrained solution is not yet ready, the controller 11 may select the first movement plan from the unconstrained solution. Third, if the unconstrained solution is also not available, the controller 11 may select the MV values ​​of the controller output calculated from the pre-generated controller matrix.

[0048] An example of a PID control loop FIG. 2 illustrates an example PID control routine 200 that, when implemented by the controller 11, does not enable predictive control or any of the corresponding advantages associated with the dual mode model control provided by the DMMC block 38.

[0049] As used herein, "predictive control" refers to a technique of process control in which values ​​for one or more MVs output by a controller (e.g., via control signals sent to field devices) describe future values ​​that are predicted for one or more PVs (e.g., one or more CVs responsive to the MVs). As noted, routine 200 does not enable predictive control.

[0050] Control loop 200 may be similar to control loops 32 and 34 shown in Figure 1. Notably, control routine / loop 200 does not rely on predictive control or model-based control. Because DMMC block 38 relies on predictive control, it may provide more precision and improved performance for control routine 200.

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

[0052] As shown, the control routine 200 includes four blocks, an analog input (AI) block 202, an AI block 204, a control block 206, and an AO block 208. Depending on the implementation, the AI ​​blocks 202 and 204 may represent analog signals received (e.g., from a field device) over an I / O channel by the controller implementing the routine 200 or an I / O card coupled to the controller. For example, the AI ​​block 204 may be limited to a first device signal tag (DST) on a first I / O card that identifies a particular AI I / O channel, and the value provided by the AI ​​block 204 may be consequently driven by the value of a signal on the particular AI I / O channel (e.g., a 4-20 ma signal provided by a flow transmitter field device representing a measured flow rate). Similarly, the AO block 208 may represent an analog signal transmitted (e.g., to a field device) over an I / O channel by the controller implementing the routine 200 or an I / O card coupled to the controller. To illustrate, the AO block 208 may be limited to a second DST that identifies a particular AO I / O channel on a second IO card, such that a value provided to the AO block 208 may cause the second I / O card to drive a signal on a particular AO I / O channel based on the value received at the AO block 208 (e.g., the value may cause the second I / O card to drive a 4-20 ma signal via the AO I / O channel to a valve field device to control the position of a valve).

[0053] 1 may also receive inputs from one or more input blocks (e.g., AI or DI blocks), which may provide values ​​to the DMMC block 38 conveyed by signals received by the controller 11 via I / O channels that are restricted to the block and couple the controller 11 to field devices. In some cases, an input block may be a "manual" block that allows a user to enter a value (e.g., an SP for a particular CV) that can be provided as an input to the DMMC block 38 and the controller 11.

[0054] Additionally, the DMMC block 38 and controller 11 can provide output values ​​to one or more output blocks (e.g., AO or DO blocks), which enables the controller 11 to send output signals conveying the output values ​​to field devices via I / O channels limited to the blocks.

[0055] An example of a model control graph and control loop Figure 3 is a graph 300 illustrating an example model-based control operation that may be implemented by controller 11, which offers many advantages over conventional feedback control techniques, such as that associated with control loop 200 shown in Figure 2. Figure 4 is an example schematic 400 of a dual-mode model-based control loop 36, according to one embodiment.

[0056] Graph 300 illustrating an exemplary model-based control operation As shown in FIG. 3, when implementing a model-based controller, the controller 11 implements a controller scan at every time instance or scan time k. The time between scans may be referred to as a "scan period," "scan time," or "control interval." The scan time may be user adjustable and may be any suitable value depending on the requirements of the controlled process. For example, the scan time may 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.

[0057] The "prediction range" P implemented by the DMMC block 38 represents the number of steps or scans into the future that the DMMC block 38 evaluates. The "control range" M implemented by the DMMC block 38 represents the number of movement plans (i.e., sets of movements for controlled MVs) that are optimized per control interval. So, if P=10 and M=2, the DMMC block 38 optimizes two MV movement plans based on predictions (and evaluations) of the associated CV's response to the next 10 scans. Each of the prediction range and control range may be manually set or adjusted by the user.

[0058] In the example shown, at each scan k, the controller 11 outputs a value u for the MV and measures a value y for the CV that is affected by the MV and in which the SP or target is present. In some cases, multiple MVs and CVs may be controlled and evaluated.

[0059] To illustrate, imagine an example where there are 12 MVs, 10 CVs, 10 forecast ranges, and 4 control ranges. At each scan, the DMMC block 38 relies on an optimizer to determine the set of steady-state process variables that best satisfy an objective function 403 (e.g., representing an optimal operating point), including a set of target CVs and a set of MVs to reach these target CVs, and implements over a series of move plans (consistent with the forecast and control ranges) to reach the desired steady-state values.

[0060] More specifically (and in the same embodiment), the DMMC block 38 may theoretically develop four motion plans that are implemented over the next four scans (typically, only the first motion plan is implemented, since the set of motion plans is recalculated for each scan, as described below). Each motion plan includes 12 values ​​(e.g., u1-u12) for the MVs. The DMMC block 38 feeds each motion plan to the process model 105 to predict how the PVs (e.g., CVs and / or AVs) will respond to each motion plan. The impact of the four motion plans can be evaluated over the next 10 scans (since the prediction range is 10).

[0061] An example of a block diagram 400 of the DMMC block 36 4 illustrates, in accordance with one embodiment, an example of an advanced control loop 36 that includes a DMMC block 38. Depending on the embodiment, the DMMC block 38 may have additional or alternative inputs or outputs.

[0062] As shown, the DMMC block 38 is implemented as an MPC routine for simultaneously controlling multiple CVs of the process 104 based on measurements made on those CVs and returned to the DMMC block 38. In one 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 an optimizer 401 to identify variable targets and values, which can then be configured to develop an optimal (e.g., maximum or minimum) solution to an objective function 403.

[0063] As illustrated in FIG. 4, the DMMC block 38 generates a move plan that includes values ​​for a set of MVs that are provided to other function blocks (not shown in FIG. 4) and then connected to the process inputs of the process 104. The DMMC block 38 can include or implement any standard model-based predictive control routine or procedure, and typically has the same number of inputs as outputs, although that requirement is not essential. The DMMC block 38 receives as inputs a set of N CVs (which may have defined constraint limits and may have defined set points) and AVs (which may only have defined constraint limits). The CVs and AVs typically constitute a vector of values ​​as they are measured within the process 104. Lines with vector values ​​are generally indicated in the diagram with hash lines passing through them.

[0064] The DMMC block 38 may also receive as inputs a set of DVs, which are known or expected changes or disturbances to be provided to the process 104 at some point in the future, as well as set target control and auxiliary variables, (CVT) and (AVT), denoted as set points (SP), provided, for example, from an optimizer 401. These targets may represent part of a solution (e.g., a set of move plans) designed to reach an optimal steady-state plant operating point (e.g., represented by a set of steady-state process variable targets) by the end of a control or prediction horizon.

[0065] Optimizer 401 may be any suitable optimizer (eg, a linear programming (LP) optimizer, a quadratic programming optimizer, etc.) that solves an optimization problem by generating a solution to an objective function (OF) 403.

[0066] Roughly speaking, an optimization problem is one in which an optimizer algorithm (e.g., 401) evaluates or solves an objective function (e.g., profit=24x+20y, where x=a first type of widget, y=a second type of widget) to identify an optimal solution to the objective function (e.g., a solution that results in the greatest profit, or x and y values). Depending on the scenario, the optimizer 401 may develop an unconstrained solution (i.e., a solution that does not consider constraints) or a constrained solution (i.e., a solution that considers constraints in one or more variables, such as limits on total material utilized, limits on total time spent in production, limits on a particular valve range, etc.). A solution that violates constraints in one or more variables may be referred to as an "infeasible solution."

[0067] Generally speaking, the objective function 403 may identify costs or benefits associated with each of several control, auxiliary, and manipulated variables. To solve the OF 403, the optimizer 401 sets control variable targets (CVTs), auxiliary variable targets (AVTs), and manipulated variable targets (MVTs) over a series of move plans to reach steady-state targets for the CVs and AVs. The final steady-state targets included in the solution may be referred to as steady-state control variables (CVSSs) and steady-state auxiliary variables (AVSSs), and may represent optimal operating points that maximize or minimize the objective function 403.

[0068] A set of process variable targets (e.g., MV, CV, or AV) may be referred to as a "solution" calculated by the optimizer 401. Each set of MVTs calculated for a particular scan period may be referred to as a "move plan." Stated another way, a solution may include a set of move plans (e.g., a set of target values ​​for MVs) and corresponding CVTs and AVTs, with each move plan and corresponding CVT / AVT set corresponding to a different one of a series of control scans. At each scan time, the process may be said to have an operating point represented by predicted or target values ​​CVT, AVT, and / or MVT.

[0069] Movement plans are generated or selected to be implemented over a series of scan or controller intervals (e.g., a first movement plan at time k, a second movement plan at time k+1, etc.). At any given time, the movement plan may be thought of as resulting in an "operating point," which may be characterized by values ​​for the PVs (e.g., CV, AV, and / or MV) at the time in question. An operating point is a "steady-state" operating point, where most PVs are changing very little, if at all, over a given period of time. If one or more PVs are changing dramatically over a period of time, the operating point may be "unsteady-state."

[0070] In any case, the solutions (e.g., the MVT, CVT, and AVT of each of the series of movement plans) may be provided to the control algorithm 116, which may then calculate the next actual movement plan to implement. The MV values ​​of the next actual movement plan implemented by the routine 116 and the controller 11 may be the same as or similar to the MVT received for the next movement plan calculated by the optimizer 401, although differences may sometimes exist. For example, if the first movement plan from the optimizer 401 includes an MVT for a given MV that results in a constraint violation (e.g., of the CV, MV, or AV), the routine 116 may adjust the value for the given MV so that the constraint is no longer violated (which may occur when the DMMC block 38 calculates an unconstrained solution). On the other hand, when the optimizer 401 calculates a constrained solution, typically no MVT in the first movement plan (or any subsequent movement plans for that matter) will result in a constraint violation. Thus, the values ​​in the movement plan implemented by routine 116 and controller 11 will likely match the MVT for the first movement plan developed by optimizer 401 .

[0071] The objective function 403 may be selected from a number of potential pre-stored objective functions, each of which may mathematically represent a different way of defining the optimal operation of the process 104. For example, one of the pre-stored objective functions may be configured to maximize plant profits, another one of the objective functions may be configured to minimize the use of a particular raw material that is in scarce, while yet another one of the objective functions may be configured to maximize the quality of the product being manufactured in the process 104. Generally speaking, the objective function utilized uses the costs or profits associated with each movement of the controlled, auxiliary, and manipulated variables to determine an optimal process operating point within a set of acceptable points as defined by the set point values ​​or ranges of the controlled variables CV, and the limits of the auxiliary variables AV and the manipulated variables MV. Of course, any desired objective function may be used in place of or in addition to the objective functions described herein, including objective functions that optimize to some degree each of several concerns, such as raw material usage, profitability, etc.

[0072] To select an objective function, a user or operator may 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 may change the objective function being used during operation of the process. If desired, a default objective function may be used if the user does not provide or select an objective function.

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

[0074] Generally speaking, the auxiliary and manipulated variable ranges define the limits (typically based on the physical characteristics of the plant) for the auxiliary and manipulated variables, while the control variable ranges provide the range within which the control variables may operate for sufficient control of the process. The control and auxiliary variable weights specify the relative importance of the control and auxiliary variables to each other during the optimization process and may be used in some situations to allow the optimizer 401 to generate semi-constrained solutions when attempting to develop a constrained solution when it is not possible to avoid violating all constraints.

[0075] Using any known or standard LP algorithm or technique, the optimizer 401 iterates to determine a set of target manipulated variables MVT (determined from the steady-state gain matrix) for each of a series of move plans (e.g., for the entire control range), which maximizes or minimizes a selected objective function 403. While developing a constrained solution, the optimizer 401 can maximize or minimize the objective function 403 while maintaining process operation that satisfies or is within the control variable CV setpoint range limits, auxiliary variable AV constraint limits, and manipulated variable MV limits. When developing an unconstrained solution, the optimizer 401 can ignore these constraints and limits to develop a theoretical (and potentially infeasible) solution.

[0076] In an exemplary operation, the optimizer 401 determines the most recent change in the manipulated variable values ​​(i.e., determines the current values ​​for 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 the current operation through the control ranges (i.e., determines the MV move plan for the next plan number specified by the control range values), i.e., determines the dynamic operation of the routine 116 during the process of reaching a target or optimal process operating point.

[0077] When developing a constrained solution, generally speaking, the optimizer 401 calculates target manipulated variable values ​​(MVTs) by forcing each of the control and auxiliary variables to their limits. As noted above, in many cases a solution exists where each CV is at a set point (which may initially be treated as an upper bound for the control variables) while each auxiliary variable remains within its respective constraint limit. In this case, the optimizer 401 need only output the determined manipulated variable target MVTs that produce this optimal result for the objective function.

[0078] However, in some cases, a solution (e.g., represented by a set of MVT move plans, each with a corresponding CVT and AVT) cannot be found because some or all of the auxiliary or manipulated variables have hard constraints, and no such solution exists, so all process variables are within their respective constraint limits at all operating points in each scan. In these cases, the optimizer 401 can calculate a semi-constrained solution. For example, as described above, the optimizer 401 can allow the CVs to be relaxed within their specified set point ranges while attempting to find an operating point where the auxiliary variables operate within their respective limits. If no solution exists in this case, the optimizer removes one of the auxiliary variable constraint limits as a limit in the solution, and instead determines an optimal process operating point that ignores the removed auxiliary variable constraint limit. Here, the optimizer 401 selects the auxiliary or controlled variable to remove as a constraint limit based on the respective weights provided to each of the controlled and auxiliary variables (e.g., with the lowest weight or highest priority removed first). The optimizer 401 continues to eliminate auxiliary or control variables based on the provided weights or priorities until it finds an MV solution in which all setpoint ranges for the control variables and bounds for the remaining high priority auxiliary variables are satisfied.

[0079] In any case, the optimizer 401 may provide a set of calculated optimal targets, or set points, or SPs (e.g., CVSS and AVSS) to the DMMC block 38 based on the solution of the objective function 403 to be reached by the end of the prediction horizon or control horizon. The DMMC block 38 may rely on the model 105 / 110 to calculate the target CV and AV (i.e., CVT and AVT) required at each step to reach the SP, and the target MV (MVT) required to obtain the CVT and AVT. In other words, the optimizer 401 utilizes the model(s) 105 / 110 to calculate the target trajectories for the CV, AV, and MV to reach the optimal steady-state operating point.

[0080] The DMMC block 38 uses the SP to create a set of M manipulated variable signals (MVs) in the form of control signals (e.g., controller outputs) and delivers the MV signals to process inputs (e.g., valve actuators) of the process 104. The MV signals are control signals that may be controller outputs or process inputs associated with controlling the operation of valve actuators, burners, pumps, etc., or any other devices that affect the physical operation of the process 104.

[0081] It should be noted that because the DMMC block 38 operates as described above during each controller scan (i.e., a complete solution and set of move plans may be computed for each scan), the target values ​​of the manipulated variables may change from scan to scan even if the SP remains the same, and as a result, the DMMC block 38 may never actually reach any particular one of the set of these target MVs tentatively scheduled for future scans, especially in the presence of noise, unexpected disturbances, changes in the process 104, etc.

[0082] Typically, the DMMC block 38 includes a controlled variable predictive process model 105 (also referred to as a "controller model" or "predictive process model"), which may be any type of model used in any of a variety of different MPC control techniques. For example, the model 105 may be an NxM+D process 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 may be a predictive or first principles model, such as a first order, second order, third order, state space model, convolution process model, or any other type of process model. The controller model 105 may be determined from process perturbation testing using time series analysis techniques that do not require significant underlying modeling work, or may be determined using any other known process modeling techniques, including superimposing a set of one or more linear or nonlinear models.

[0083] In any case, the model 105 takes into account the model discrepancies by generating outputs 107 that define previously calculated predictions for each of the control and auxiliary variables CV and AV. A summer 108 subtracts these predictions for the current time from the actual measurements of the control and auxiliary variables CV and AV at the current time, as sensed or measured within the process 104, to generate an error or correction vector (also known as a set of residuals). The set of residuals, typically referred to as prediction errors, defines a bias or offset error of the model 105 and is used to correct the predictions of the model 105.

[0084] During operation, the process model 105 uses the MV and DV inputs and residuals to predict future control parameters for each of the CV and / or AV over the control range, providing future predicted values ​​of the CV and possibly the AV (in vector form) on line 109. The optimizer 401 may rely on these predictions when evaluating potential values ​​of the MVs in each movement plan.

[0085] Additionally, the process model 105 and / or optimizer 401 can generate the predicted steady state values ​​CVSS and AVSS described above, so that block 105 can make predictions of values ​​for each of the CV and AV at each scan (e.g., based on each movement plan) over time up to the prediction horizon.

[0086] Additionally, the control target block 110 determines a control target vector or set point vector for each of the N target control variables CVT and auxiliary variables AVT provided, for example, by a user or other optimization application. The control target block 110 may include a trajectory filter that defines the manner in which the control and auxiliary variables are driven to their target values ​​over time. Using this filter and the target variables CVT and AVT defined by the set point SP, the control target block 110 generates dynamic control target vectors for each of the control and auxiliary variables that define the change in the target variables CVT and AVT over the period defined by the control horizon time.

[0087] Vector adder 114 then subtracts the future control parameter vector for each of the simulated or predicted control variables CV and auxiliary variables AV on line 109 from the dynamic control vector generated by block 110 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 control algorithm 116, which operates (in cooperation with optimizer 401) to select manipulated variable MV steps that minimize or maximize an objective function 403 (e.g., minimize integrated squared error (ISE) or integrated absolute error (IAE)) over a control range.

[0088] In some embodiments, the algorithm 116 may, if desired, use an N×M control matrix developed from the relationships between the N control and auxiliary variables input to the DMMC block 38 and the M manipulated variables output by the DMMC block 38. More specifically, the MPC control algorithm 116 may have two primary objectives. First, the control algorithm 116 may attempt to minimize the CV control error with minimal MV movement (e.g., within operational constraints when developing a constrained solution). Second, the control algorithm 401 may attempt to obtain an optimal steady-state MV value (MVSS) and a target CV value calculated from the optimal steady-state MV value.

[0089] The state equation for a typical model predictive controller can be expressed as:

number

number

number

[0090] where Q, R, S are penalty weights for the error, controller move, and incremental move, respectively, xk is the model state matrix, yk is the process output, and uk is the controller output. The DMMC block 38 and controller 38 can implement this state equation. Because the Q, R, and S penalty vectors are essentially decoupled, MPC controllers generally do not have a performance trade-off between set point tracking and disturbance rejection (unlike traditional controllers such as PID controllers). However, MPC controllers still need to be tuned for specific multivariable process control objectives. The process model typically matches the internal structure of the MPC controller (e.g., the process state space with a state space MPC formulation), while additional tuning parameters determine the behavior with respect to set point changes and disturbance rejection.

[0091] In any event, the operation of the DMMC block 38 in Figure 4 assumes that new process variable measurements are available during each controller scan or run operation of the model 105, which generates a new set of controlled variable predictions over the time range. In this controller operation, when new process variable measurements for the controlled process variables (CVs) are not available for each new controller scan, the controller will use old process variable data to perform control.

[0092] Exemplary Method 500 for Implementing Dual-Mode Model-Based Control Figure 5 illustrates an example method 500 for implementing dual-mode model-based control, according to one embodiment. Method 500 may be implemented, in whole or in part, by system 10 shown in Figure 1, and more specifically, controller 11 and DMMC block 38 shown in Figures 1 and 4. Method 500 may be stored in memory (e.g., in controller 11 and / or workstation 13) as one or more instructions or routines.

[0093] The method 500 begins when a controller scan period is initiated (block 505). At the start of the scan period, the controller 11 receives a current set of measurements for the set of CVs controlled by the controller 11.

[0094] The controller 11 then begins generating both constrained and unconstrained solutions to the optimization problem or objective function 403 (block 507).

[0095] In block 509, the control scan period ends (or the decision threshold is reached shortly before the end of the scan period).

[0096] In block 510, the controller 11 determines whether the constrained solution has finished evolving. If the constrained solution has finished, the controller 11 implements the constrained solution (block 515). If the constrained solution has not finished, the controller 11 implements the unconstrained solution (block 520). If the unconstrained solution has also not been evolved for some reason, the controller 11 may utilize a pre-generated movement plan (e.g., calculated from a pre-generated controller matrix).

[0097] Exemplary Method 600 for Generating Unconstrained Solutions Figure 6 illustrates an example method 600 for implementing an unconstrained solution, according to one embodiment. Method 600 may be implemented, in whole or in part, by system 10 shown in Figure 1, and more specifically, controller 11 and DMMC block 38 shown in Figures 1 and 4. Method 600 may be stored in memory (e.g., in controller 11 and / or workstation 13) as one or more instructions or routines.

[0098] In block 605, the controller 11 provides the process model, current PV values, such as MV values ​​(e.g., received at the start of a controller scan), predicted PV values, and the control objectives (e.g., objective function 403) to the optimizer 401 to begin the process of generating a solution to the control objectives. In some cases, tuning parameters and / or an error vector (e.g., representing prediction errors) may also be provided to the optimizer.

[0099] In block 607, the optimizer 401 may define one or more optimal MV values ​​for the end of the control horizon, as well as a CV target for the end of the prediction horizon.

[0100] In block 610, the optimizer 401 and / or the controller 11 generate an unconstrained solution to 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. Specifically, the optimizer 401 generates a set of PVs (e.g., CVs, AVs, and / or MVs) for each of a series of scans that lead to an optimal steady-state plant operating point (e.g., represented by a set of steady-state process variable targets) by the end of the control or prediction horizon, as well as a final scan evaluated according to the prediction horizon. For each of the series of scans, the set of MV targets constitutes a movement plan for that particular scan. Generally speaking, and as described elsewhere, the optimizer 401 generates a constrained solution when feasible. When infeasible, slack variables may be used. These may allow some constraint violations to be tolerated for the purpose of generating a solution. In general, the optimizer 401 may be assumed to provide a constrained solution (e.g., when possible / feasible). The controller can use a constrained steady-state solution at the end of the forecast horizon, and the optimizer can evolve a solution that is dynamically constrained (eg, throughout the entire forecast horizon).

[0101] In block 615, the controller 11 identifies a PV constraint (eg, a constraint on the CV, AV, or MV).

[0102] Then, in block 620, the controller 11 evaluates a first movement plan from the set of movement plans included in the unconstrained solution. If any of the MV values ​​in the first movement plan 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 movements, one or more MVs are adjusted until the first movement plan no longer violates the constraints. When the first movement plan no longer violates the constraints, it is considered "bounded" (i.e., bounded by all relevant constraints).

[0103] Note that in this example, the constraint violations predicted to occur after the first movement plan are largely ignored by the controller 11 and optimizer 401. Thus, the "ideal" solution that does not consider the constraints may not be the ideal trajectory of the PV values ​​when the constraints are taken into account (because the prediction assumes a movement that the controller 11 does not actually make). In other words, the value gained by the ability to predict future PV values ​​is somewhat blunted in this particular scenario because the controller 11 may not accurately predict future PV values ​​in light of the fact that the constraints are taken into account by the controller 11 every scan period (e.g., by modifying the values ​​in the first movement plan) when the controller 11 is outputting the MV signal.

[0104] If the controller 11 is utilizing an unconstrained solution (e.g., because a constrained solution was not developed within the scan period), the values ​​in the constrained first move plan are transmitted via one or more controller outputs of the controller 11 to field devices to implement control of the process.

[0105] Exemplary Method 700 for Generating Constrained Solutions Figure 7 illustrates an exemplary method 700 for implementing a constrained solution, according to one embodiment. The method 700 may be implemented, in whole or in part, by the system 10 shown in Figure 1, and more specifically, the controller 11 and the DMMC block 38 shown in Figures 1 and 4. The method 700 may be stored in memory (e.g., in the controller 11 and / or the workstation 13) as one or more instructions or routines.

[0106] In block 705, the controller 11 generates a new process model (e.g., while the process is offline). Typically, the generation of the model occurs by capturing the dynamic relationships between the inputs and outputs of the process being controlled and generating a mathematical model that reflects those dynamic relationships. Traditionally, these dynamic relationships are captured during a model generation procedure that involves (i) introducing known disturbances or perturbations to the process by changing one or more manipulated variables, and (ii) observing how the process responds to the changes to the manipulated variables. Once the process has finished responding to the changes to the manipulated variables and has reached a steady state, the controller 11 can generate a process model based on the relationships between the changes to the manipulated variables and the observed process response. The controller 11 can then resume normal control utilizing the new (and possibly more accurate) process model. In some cases, when implementing the method 700, the controller 11 does not generate a new model. After generating the model, the model may be fed to the optimizer 401.

[0107] In block 707, the controller 11 provides the current PV values ​​(e.g., received at the start of a controller scan), the predicted PV values, the control objective (e.g., the objective function 403), and one or more PV constraints (e.g., CV, MV, and / or AV) to the optimizer 401 to begin the process of generating a solution to the control objective. In some cases, tuning parameters and / or an error vector (e.g., representing the prediction error) may also be provided to the optimizer 401.

[0108] At block 710, the controller 11 generates (e.g., by implementing the steps of method 600) an unconstrained solution including a set of PVs for a series of scans spanning the prediction range. Each set of PVs may include a set of MVs that constitute a "movement plan" to be implemented (at least in theory) by the controller for that particular scan. As described in more detail below, method 700 may utilize the unconstrained solutions as "candidate solutions" that are evaluated for constraint violations and then modified to create successive candidate solutions until a candidate solution is ultimately identified that does not violate any constraints.

[0109] In block 715, the controller 11 analyzes the set of PVs deployed for each future scan (including the motion plan for each scan).

[0110] In block 720, the controller 11 identifies the first movement plan that results in a constraint violation. As an example, the third scheduled movement plan may include an MV value that exceeds an MV constraint or results in another PV that exceeds a constraint (e.g., an MV value of 78% for control valve CV821 exceeds the upper constraint of CV821 at 75% open). If there is no constraint violation, the controller 11 proceeds to block 735 (this may occur especially early in the process if the constraints are particularly few or loose). Generally speaking, a constraint violation exists if any one of the set of constraints associated with the DMMC block 38 is violated.

[0111] In block 725, the controller 11 determines whether all MVs are constrained or limited. Generally speaking, this is only true if the controller 11 iteratively analyzes the updated solution as constraint violations are identified until the point at which no MV values ​​violate the constraints in any of the series of MV plans. If all MVs are constrained or limited, the controller proceeds to block 735 (described in more detail below). If one or more MVs remain unconstrained over the series of movement plans, the controller 11 proceeds to block 730.

[0112] In block 730, the controller 11 provides the allowable portion of the moves before a constraint violation occurs to the optimizer 401. Continuing with the previous example, the first two movement plans are provided to the optimizer 401 along with the other components discussed above.

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

[0114] The controller 11 then performs blocks 715 and 720 (and possibly 725 and 730) again with the revised solution. This iterative process may continue until a revised or candidate solution is generated in which a set of movement plans does not violate any of the constraints.

[0115] In block 735, after the modified unconstrained solution is found to contain no constraint violations or after a constraint violation is found, the controller 11 determines a constrained solution as a result of all MVs being constrained throughout the entire set of movement plans. If the original unconstrained solution does not violate any constraints, it may be used as the constrained solution. In some cases, the original unconstrained violations may only require minor modifications before a constrained solution is determined.

[0116] After the constrained solution is established, the controller 11 can utilize the first movement plan of the constrained solution (assuming there is enough time remaining in the scan period) by generating controller outputs (e.g., to control field devices according to the MV values ​​of the first movement plan) to communicate the values ​​of the first movement plan. There should be no need to change any MV values ​​of the first movement plan, since the entire set of movement plans should not result in any constraint violations.

[0117] Method 700 can be thought of as a way to iteratively constrain MV values ​​that comprise a solution's motion plan. That is, each time a constraint violation is identified in step 720, the next candidate solution assumes the solution's allowable motion plan and, across the set of motion plans, the allowable ranges of each MV previously analyzed for constraint violations. In one embodiment, each successive candidate solution should have one less unconstrained MV for which a constraint violation may be identified.

[0118] Further considerations When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, such as in the RAM or ROM of a computer or processor. It should be noted that while the exemplary systems disclosed herein are disclosed as including software or firmware running on hardware, among other components, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, while the exemplary systems described herein are described as being implemented in software running on a processor of one or more computing devices, one skilled in the art will readily recognize that the examples provided are not the only way to implement such a system.

[0119] With specific reference to methods 500-700, the described functionality may be implemented, in whole or in part, by devices, circuits, or routines of system 10 shown in Figure 1. Each of the described methods may be embodied by a set of circuitry that is permanently or semi-permanently configured (e.g., an ASIC or FPGA) to perform the logical functions of the respective method, or a set of circuitry that is at least temporarily configured (e.g., one or more processors and a set of instructions or routines representing the logical functions and stored in memory) to perform the logical functions of the respective method.

[0120] Although the present invention has been described with reference to specific examples, these are illustrative only and are not intended to be limitations of the present invention, and it will be apparent to one skilled in the art that modifications, specific additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention. Furthermore, while the above text describes detailed descriptions of many different embodiments, it should be understood that the scope of this patent is defined by the terms of the claims set forth at the end of this patent and their equivalents. The detailed description should be construed as merely illustrative and does not describe all possible embodiments, as describing all possible embodiments would be impractical, if not impossible.

[0121] Throughout this specification, multiple instances may 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 may be performed simultaneously in a particular embodiment.

[0122] As used herein, any reference to "one embodiment" or "one embodiment" means that a particular element, feature, 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.

[0123] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements, and may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive or, not an exclusive or. For example, a condition A or B is satisfied by any one of A being true (or present) and B being false (or absent), A being false (or absent) and B being true (or present), and both A and B being true (or present).

[0124] Additionally, the phrase "a 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 "a component is configured for X, Y, or Z" means that the component is configured for X, configured for Y, configured for Z, or configured for some combination of X, Y, and Z.

[0125] Additionally, the use of "a" or "an" is used to describe elements and components of the embodiments herein. This description, and the claims that follow, should be read to include one or at least one. The singular also includes the plural unless it is clear that it does not include the plural.

[0126] In various embodiments, the hardware systems described herein may be implemented mechanically or electronically. For example, a hardware system may include dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC)). A hardware system may also include programmable logic or circuitry that is temporarily configured by software to perform specific operations (e.g., contained within a general-purpose processor or other programmable processor). It will be appreciated that the decision to mechanically implement a hardware system in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may be made based on cost and time considerations.

[0127] Additionally, the claims at the end of this document are not intended to be construed under 35 U.S.C. § 112(f) unless traditional means-plus-function language is expressly recited, such as when the phrase "means for" or "step for" is expressly recited in the claim(s).At least some aspects of the systems and methods described herein are directed to improving computer functionality, as well as improving upon the functionality of conventional computers.

[0128] Common Terms and Phrases Throughout this specification, some of the following terms and phrases are used.

[0129] Communications Link. Unless otherwise specified, a "communications link" or "link" is a path or medium that connects two or more nodes. A link may be a physical link or a logical link. A physical link is the interface or medium or media over which information is transferred and may be wired or wireless in nature. Examples of physical links include (i) wired links, such as a cable with conductors for transmitting electrical energy or fiber optic connections for transmitting light, and (ii) wireless links, such as a wireless electromagnetic signal that conveys information via changes made to one or more properties of an electromagnetic wave.

[0130] As stated, a wireless link may be a wireless electromagnetic signal that conveys information via modifications made to one or more characteristics of an electromagnetic wave(s). The wireless electromagnetic signal may be a microwave or radio wave and may be referred to as a radio frequency or "RF" signal. Unless otherwise stated, the RF signals described may oscillate at a frequency within any one or more bands found in the spectrum from approximately 30 kHz to 3,000 GHz (e.g., 802.11 signals in the 2.4 GHz band). Examples of RF bands include the low frequency ("LF") band from 30 to 300 kHz, the medium frequency ("MF") band from 300 to 3,000 kHz, the high frequency ("HF") band from 3 to 30 MHz, the very high frequency ("VHF") band from 30 to 300 MHz, the extremely high frequency ("UHF") band from 300 to 3,000 MHz, the super high frequency ("SHF") band from 3 to 30 GHz, the millimeter wave frequency ("SHF") band from 30 to 300 GHz, and the extremely high frequency ("THF") band from 300 to 3,000 GHz.

[0131] In some cases, the wireless electromagnetic signal may be an optical signal oscillating at a frequency between approximately 300 GHz and 30 PHz and having a wavelength between approximately 100 nm and 1 mm, which may be (i) an ultraviolet light ("UV") signal having a wavelength in the range of approximately 10 nm to 400 nm and a frequency in the range of approximately 750 THz to 30 PHz, (ii) a visible light signal having a wavelength in the range of approximately 400 nm to 700 nm and a frequency in the range of approximately 430 THz to 750 THz, or (iii) an infrared light ("IR") signal having a wavelength in the range of approximately 700 nm to 1 mm and a frequency in the range of approximately 300 GHz to 430 THz. Unless otherwise specified, the optical signal described may conform to any suitable optical signal protocol or standard, such as the Visible Light Communication (VLC) standard, the Light Fidelity (Li-Fi) standard, the Infrared Data Association (IrDA) standard, the IrSimple standard, etc.

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

[0133] A link may also be referred to as a "communication channel." In wireless communication systems, the term "communication channel" (or simply "channel") generally refers to a particular frequency or frequency band. A carrier signal (or carrier wave) may be transmitted at a particular frequency or within a particular frequency band of a channel. In some cases, multiple signals may be transmitted in a single band / channel. For example, signals may be transmitted simultaneously in a single band / channel, sometimes over different sub-bands or sub-channels. As another example, signals may be transmitted over the same band, sometimes by allocating time slots, with each transmitter and receiver using that band.

[0134] Memory and Computer Readable Media. Generally speaking, the phrases "memory" or "memory device" as used herein refer to a system or device that includes a computer readable medium or media ("CRM"). A "CRM" refers to one or more media accessible by an associated computing system for placing, retaining, or retrieving information (e.g., data, computer readable instructions, program modules, applications, routines, etc.). Note that "CRM" refers to media that is non-transitory in nature, and does not refer to intangible transitory signals such as radio waves.

[0135] A CRM may be implemented in any technology, device, or group of devices contained within or in communication with an associated computing system. A CRM includes volatile or non-volatile media, and removable or non-removable media. A CRM may include, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or any other medium that can be used to store information and accessed by a computing system. The CRM is communicatively coupled to a system bus, enabling communication between the CRM and other systems or components coupled to the system bus. In some implementations, the CRM may be coupled to the system bus through 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.

[0136] Network. As used herein, unless otherwise specified, when used in the context of a system(s) or device(s) that communicate information or data, the term "network" refers to a collection of nodes (e.g., devices or systems that can send, receive, or forward information) and links that are connected to enable long-distance communication between the nodes.

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

[0138] For example, a dedicated router may be capable of large volume transmissions, while some nodes may be capable of sending and receiving relatively small amounts of traffic in the same period of time. In addition, connections between nodes on the described networks may have different throughput capabilities and different attenuation characteristics. Fiber optic cables, for example, may be capable of providing orders of magnitude higher bandwidth than wireless links due to differences in the inherent physical limitations of the medium. If desired, each of the described networks may include a network or sub-network, such as a personal area network (PAN), a local area network (LAN), or a wide area network (WAN).

[0139] Processor. Various operations of the example methods described herein may be performed, at least in part, by one or more of the described or implicitly disclosed controllers or processors (e.g., controller 11 may include a processor). Generally speaking, the terms "processor" and "microprocessor" are used interchangeably and each refer to a computer processor configured to retrieve and execute instructions stored in a memory.

[0140] By executing these instructions, the disclosed processor(s) can perform various operations or functions defined by the instructions. The disclosed processor(s) may be temporarily configured (e.g., by instructions or software) or may be permanently configured to perform the associated operations or functions depending on the particular embodiment (e.g., processor for application specific integrated circuit or ASIC). Each disclosed processor may be part of a chipset, which may also include, for example, a memory controller or an I / O controller. A chipset is a collection of electronic components in an integrated circuit typically configured to provide I / O and memory management functions, as well as a number of general purpose or special purpose registers, timers, etc. Generally speaking, one or more of the described processors may be communicatively coupled to other components (such as memory devices and I / O devices) via a system bus.

[0141] Certain performance of operations may not only reside within a single machine, but may be distributed among one or more processors deployed across several machines. For example, when a single processor is described as performing a set of operations, it is understood that multiple processors may perform the set of operations in some embodiments according to any desired distribution across the multiple processors. In some embodiments, one or more processors may be located in a single location (e.g., in a home environment, in a work environment, or as a server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0142] Words such as "processing," "computing," "calculating," "determining," "presenting," "displaying," and the like may refer to machine (e.g., computer) operations or processes that manipulate or transform data represented as physical (e.g., electrical, magnetic, or optical) quantities in one or more memories (e.g., volatile memory, nonvolatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0143] Routines. Unless otherwise specified, a "routine," "module," or "application" described in this disclosure refers to a set of computer-readable instructions that may be stored in a CRM. In general, a CRM stores computer-readable code ("code") representing or corresponding to instructions, which is adapted to be executed by a processor to facilitate the functionality described as represented by or associated with the routine or application. Each routine or application may be implemented via a standalone executable file, a suite or bundle of executable files, one or more non-executable files utilized by an executable file or program, or some combination thereof. In some cases, unless otherwise specified, one or more of the routines described may 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.

[0144] Furthermore, unless otherwise specified, each routine or application may be embodied as (i) a stand-alone software program, (ii) a module or submodule of a software program, (iii) a routine or subroutine of a software program, or (iv) a resource that is invoked or accessed by a software program via a "call" that causes the system to perform a task or function associated with the resource. The call may be (i) a "function call" invoked to cause execution of a resource (e.g., a set of instructions) stored in a library accessible by the software program, (ii) a "system call" invoked to cause execution of a system resource (e.g., often executed in a privileged kernel space and executable only by the operating system), (iii) a "remote call" invoked to cause a logical or physical entity having a different address space to execute a resource, or (iv) some combination thereof. As an example, a routine executed by a processor of a device may invoke a "remote call" to cause execution of a resource in (i) a second device (e.g., a server host, an end-user device, a networking device, a peripheral device that communicates with the device, or some other physical device), (ii) a virtual machine on the same or a different device, (iii) a processor (e.g., a CPU or GPU) that is different from the original processor and may be internal or external to the device executing the routine, or (iv) some combination thereof.

[0145] Each routine may be represented by code implemented in any desired language, such as source code (e.g., interpretable for execution or compilable into lower level code), object code, bytecode, machine code, microcode, etc. The code may be written in any suitable programming or scripting language (e.g., C, C++, Java, Actionscript, Objective-C, Javascript, CSS, Python, XML, Swift, Ruby, Elixir, Rust, Scala, etc.).

Claims

1. 1. A method comprising: (A) implementing, via a process controller coupled to one or more field devices, a 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 MVs in the set of MVs; (B) initiating a scan by a process controller at the beginning of a scan period to obtain a current set of measurements of the CV; (C) before the scan period ends, selecting a current move plan to be implemented by the process controller for the set of MVs according to a process model and a set of constraints for the PVs; (i) using the current set of measurements of the set of CVs as model inputs for the process model to begin generating both (a) an unconstrained solution comprising a set of unconstrained move plans that are not constrained by the set of constraints, and (b) a constrained solution comprising a set of constrained move plans that avoid violating any of the set of constraints; (ii) when the constrained solution is generated before the end of the scanning period, selecting a first movement plan from the set of constrained movement plans of the constrained solution as the current movement plan; (iii) when the constrained solution is not generated before the scanning period ends, selecting a first motion plan from the set of unconstrained motion plans of the unconstrained solution as the current motion plan; (D) implementing control of the process before the end of the scan period by sending a set of controller outputs, communicating a set of values ​​for the set of MVs to the field devices and causing the field devices to drive the set of MVs to the set of values ​​for the set of MVs included within the current movement plan.

2. selecting the first movement plan from the set of unconstrained movement plans of the unconstrained solution as the current movement plan includes modifying the first movement plan when any value contained within the first movement plan violates a constraint; 2. The method of claim 1, wherein modifying the first movement plan comprises adjusting the values ​​of the first movement plan that violate the constraints such that the first movement plan no longer results in a constraint violation.

3. the scan period is a first scan period, and the method further comprises: after completion of the first scan period, initiating a next scan at a beginning of a second scan period to obtain a next set of measurements for the CV and again implementing the dual mode of operation to select a second current motion plan for the next scan; (i) using the second current set of measurements of the set of CVs as model inputs for the process model to begin generating both (a) a second unconstrained solution comprising a set of unconstrained move plans that are not constrained by the set of constraints, and (b) a second constrained solution comprising a set of constrained move plans that avoid violating any of the set of constraints; (ii) when the second constrained solution is generated before the second scanning period ends, selecting a first movement plan from the set of constrained movement plans of the second constrained solution as the second current movement plan; (iii) when the second constrained solution is not generated before the second scanning period ends, selecting a first movement plan from the set of unconstrained movement plans of the second unconstrained solution as the second current movement plan.

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

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

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

7. 7. The method of claim 1, wherein initiating generation of the constrained solution comprises starting with the unconstrained solution and iteratively modifying the unconstrained solution to eliminate values ​​that result in constraint violations.

8. 8. The method of claim 1, wherein initiating generation of the constrained solution comprises starting with a set of pre-generated movement plans and iteratively modifying the pre-generated movement plans to eliminate values ​​that result in constraint violations.

9. 1. A system comprising: one or more field devices for monitoring or controlling a process; a process controller communicatively coupled to the one or more field devices and configured to control the process, the process being 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 MVs in the set of MVs; The process controller is configured to implement a dual mode model control operation to select a current move plan to be implemented by the process controller for the set of MVs according to a process model and a set of constraints on the PVs, the process controller comprising: (A) initiating a scan by a process controller at a beginning of a scan period to obtain a current set of measurements of the CV; (B) before the end of the scan period. (i) using the current set of measurements of the set of CVs as model inputs for the process model to begin generating both (a) an unconstrained solution comprising a set of unconstrained move plans that are not constrained by the set of constraints, and (b) a constrained solution comprising a set of constrained move plans that avoid violating any of the set of constraints; (ii) when the constrained solution is generated before the end of the scanning period, selecting a first movement plan from the set of constrained movement plans of the constrained solution as the current movement plan; (iii) when the constrained solution is not generated before the end of the scanning period, selecting a first motion plan from the set of unconstrained motion plans of the unconstrained solution as the current motion plan; (C) implementing control of the process before the end of the scan period by sending a set of controller outputs, communicating a set of values ​​for the set of MVs to the field devices and causing the field devices to drive the set of MVs to the set of values ​​for the set of MVs included within the current movement plan.

10. the process controller is configured to select the first movement plan from the set of unconstrained movement plans of the unconstrained solution as the current movement plan by modifying the first movement plan when any value contained within the first movement plan violates a constraint; 10. The system of claim 9, wherein modifying the first movement plan comprises adjusting the values ​​of the first movement plan that violate the constraints such that the first movement plan no longer results in a constraint violation.

11. the scan period is a first scan period, and the process controller after completion of the first scan period, commencing a next scan at a beginning of a second scan period to obtain a next set of measurements for the CV and again implementing the dual mode model control operation to select a second current motion plan for the next scan; (i) using the second current set of measurements of the set of CVs as model inputs for the process model to begin generating both (a) a second unconstrained solution comprising a set of unconstrained move plans that are not constrained by the set of constraints, and (b) a second constrained solution comprising a set of constrained move plans that avoid violating any of the set of constraints; (ii) when the second constrained solution is generated before the second scanning period ends, selecting a first movement plan from the set of constrained movement plans of the second constrained solution as the second current movement plan; (iii) when the second constrained solution is not generated before the second scanning period ends, selecting a first movement plan from the set of unconstrained movement plans of the second unconstrained solution as the second current movement plan.

12. 12. The system of claim 9, wherein the scan period is a normal scan period that is the same length for each scan.

13. 12. The system of claim 9, wherein the scan duration is configured to vary depending on the scan.

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

15. 15. The system of claim 9, wherein initiating generation of the constrained solution comprises starting with the unconstrained solution and iteratively modifying the unconstrained solution to eliminate values ​​that result in constraint violations.

16. 16. The system of claim 9, wherein initiating generation of the constrained solution comprises starting with a set of pre-generated movement plans and iteratively modifying the pre-generated movement plans to eliminate values ​​that result in constraint violations.

17. 1. A method comprising: (A) implementing a dual mode model-based process controller configured to control one or more field devices in a process control environment; (B) initiating a scan by the dual mode model-based process controller to obtain a set of current values ​​for a set of process variables (PV), the set of current values ​​representing a current state of the controlled process, the process variables including a plurality of controlled variables (CV) and a plurality of manipulated variables (MV); (C) generating an unconstrained solution to the optimization problem utilizing the process model by generating, using the process model, a series of movement plans for the plurality of MVs to achieve a predetermined objective, regardless of whether any of the series of movement plans violates any of the set of constraints for the PVs, such that the value for each MV in each of the series of movement plans is not limited by the set of constraints for the PVs; (D) utilizing the process model to initiate generation of a constrained solution to the optimization problem, (i) storing the unconstrained solution as a candidate solution; (ii) restricting a first MV from the plurality of MVs by analyzing the candidate solutions to: (a) identify a first violation of a constraint and determine that the first MV caused the first violation; and (b) calculate a tolerance range for the first MV based on one or more values ​​for the first MV included in a movement plan scheduled prior to the first violation; (iii) constraining the remaining MVs from the plurality of MVs by iteratively generating revised candidate solutions including a sequence of modified movement plans for each remaining MV such that each revised candidate solution maintains a previously constrained MV within a calculated tolerance range and each successive revised candidate solution includes one less unconstrained MV than the previous revised candidate solution, the remaining MVs being constrained in an order based on which of the remaining MVs first violates a constraint for each revised candidate solution; (iv) after each of the plurality of MVs has been constrained to include a final set of movement plans that do not violate any of the set of constraints for the PVs, finalizing the constrained solution by storing the last revised candidate solution as the constrained solution; (E) when the scan period expires before the constrained solution is determined, (i) modifying a first movement plan for the unconstrained solution by adjusting values ​​included in a first movement plan for the unconstrained solution that violates any of the set of constraints for the PV to achieve a constrained first movement plan that does not violate any of the set of constraints for the PV, and (ii) utilizing the constrained first movement plan of the unconstrained solution for a set of controller outputs to control the one or more field devices in accordance with the constrained first movement plan. (F) when the constrained solution is determined before the scan period expires, utilizing the first movement plan of the constrained solution against the set of controller outputs to control the one or more field devices in accordance with the restricted first movement plan.

18. 18. The method of claim 17, further comprising initiating a second scan by the dual mode model-based process controller to obtain a second set of current values ​​for the set of PVs; generating a second unconstrained solution to the optimization problem using the second set of current values ​​for the set of PVs; initiating generation of a second constrained solution to the optimization problem using the second set of current values ​​for the set of PVs; utilizing the constrained solution to generate a set of control outputs when the constrained solution is established before the second scan period ends; and utilizing the unconstrained solution to generate a set of control outputs when the constrained solution is not established before the second scan period ends.

Images