A Simplified and Integrated Approach
to Model Predictive Control Implementation
Vasiliki Tzovla
Fisher-Rosemount Systems
Austin, Texas 78759, USA
Ashish Mehta
Fisher-Rosemount Systems
Austin, Texas 78759, USA
KEYWORDS
Model Predictive Control, Function Block, Multivariable Process Control
ABSTRACT
In many cases the benefits of Model Predictive Control are not achieved due to its traditionally complex
nature and narrow application. This paper describes a new approach that simplifies Model Predictive
Control’s implementation and usability. Model Predictive Control (MPC) implementation is represented
as a function block and by using state-of-the-art techniques, the commissioning process becomes fast
and easy, and the entire process of collecting and pre-processing data, creating a model, generating MPC
definition, verifying the model and downloading the generated model and MPC definition to run in a
controller, are fully automated. The paper also details features of convenience such as graphical
presentation of the MPC block inputs and outputs, model visualization, model editing capabilities,
model verification and simulation before putting the control online.
INTRODUCTION
The Model Predictive Control (MPC) technique, pioneered by the DMC[1] and IDCOM[2] algorithms
in the 1970s, has recently been widely received by both the academic community and the industry. This
can be attributed to the fact that it is perhaps the most general way of posing the process control problem
in the time domain. Generally speaking, it is often difficult to adequately control multiple-input
multiple-output (MIMO) processes, processes with constraints and/or disturbances, processes with
associated complex dynamics, using conventional PID based approaches such as feed forward control,
decoupling, override control, and so on. Since MPC is ideally suited to such processes, it appears that
there is considerable interest in applying it to process control. However, there are both theoretical and
practical difficulties related to its traditionally complex nature and huge costs. In this paper we present
an approach that simplifies the commissioning and implementation of a model based predictive
controller by minimizing its conventional intricacies.
MPC is a multiple-input/multiple-output control strategy in which the effects of changing each of a
number of process inputs on each of a number of process outputs is measured and these measured
responses are then used to create a model of the process. The process model is inverted mathematically
and used as a multiple-input/multiple-output controller to control the process outputs based on changes
made to the process inputs. Figure 1 shows the basic structure used to implement this strategy. A model
is used to predict the future plant outputs, based on past and current values and on the proposed optimal
1
Copyright 2000 Instrument Society of America. All rights reserved
future control actions. The optimizer calculates these actions taking into account the cost function as
well as the constraints. The main ideas appearing in a predictive controller are [3]:

Explicit use of a model to predict process output at future time instants (control horizon)
Reference
Trajectory
Past I/O
Predicted
Outputs
Model
_ +
Future
Inputs
Future
Errors
Optimizer
Cost
Function
Constraints
Figure 1: Basic Structure of MPC


Calculation of a control sequence minimizing a certain objective function
Receding strategy, so that at each instant the horizon is displaced towards the future, which involves
the application of the first control signal of the sequence calculated at each step.
Model predictive control presents distinct advantages over other control methods. It can be used for a
variety of processes, from those with relatively simple dynamics to more complex ones, including those
with long delay times. By design, it handles the multivariable case, including compensation for
measurable disturbances in a feed-forward control fashion, as well as a systematic treatment of
constraints. It intrinsically compensates for dead times and is also very useful when future references are
known. The resulting controller is implemented easily as a linear control law. Added to that is the
intuitive approach and ease of tuning, making it extremely attractive to plant operators. Although these
features have led to an increased interest with a number of reported applications to control problems,
MPC has not yet reached in industry the popularity that its potential suggests. One of the reasons is that
its implementation requires mathematical complexities (for example, the derivation of the control law is
more complex than that for classical PID) which are not a problem for the research community but
represent a drawback for control engineers in practice.
TRADITIONAL MPC ENVIRONMENT
Traditionally, to create an MPC for a process, a process expert (typically an outside consultant) was
employed, who would first come to the plant and observe the plant or process operation over a period of
time. After choosing the appropriate process inputs and outputs for the model predictive controller, the
expert worked with the plant operators to deliver a series of input waveforms (for example, in the form
of a pseudo-random sequence of step waveforms) to each of the inputs and to measure the effect of the
inputs on each of the chosen process outputs. This collected input-output data was then fed to an off-line
system, which in some cases would be off-site at the expert’s facility. After screening and preprocessing the data, the off-line system is used to create a model of the process. The model is then
inverted or used in other known manners to create an MPC for the process. However, even at this stage
2
Copyright 2000 Instrument Society of America. All rights reserved
the model and controller are not directly usable, as it has to be inserted into the process control system,
which would generally require extensive programming by the process engineers to deliver each of the
specified controller inputs (i.e., process outputs) to the model predictive controller and to have the model
predictive controller deliver each of the controller outputs (i.e., process inputs) to the appropriate place
in the control system to perform control. Since the controller is created by an off-line system, its
Altered Process
Legend:
Data Collection
a) Traditional Approach
Model / Controller Generation
MPC Configuration/Integration
Simulation, Training, Online
Altered Process
b) Simplified Approach
Time
Figure 2: Traditional and Simplified MPC Implementation Life Cycle 
integration also requires the use of special graphics, user interfaces and displays (typically more third
party software and associated training) for the operator to be able to use it. In many cases, this
complexity results in the configuration of a specialized engineering/advanced control workstation layer
on top of the normal control system with limited access to plant operators. There may also be potentially
long down times for integrating MPC into the existing control system. As can be seen this entire process
is time consuming, generally requires expert intervention, and can be very expensive. In fact, it could
take several months and cost hundreds of thousands of dollars to create a single MPC for a process.
Maintenance costs escalate with such specialized application layers that might need periodic expert
intervention. Unfortunately, even then, changes in the process such as those caused by aging of process
equipment can render the created model to be obsolete or mismatched, which means that the entire
process has to be repeated to create another MPC. The traditional MPC implementation cycle is shown
in Figure 2a.
SIMPLIFIED APPROACH
In order to make available the inherent advantages of model predictive control, we have developed an
approach that simplifies the complete life cycle of an MPC implementation. While maintaining the core
technology and functionality of MPC, this methodology automates the data collection, control
generation and commissioning process. This makes it extremely easy and intuitive for the typical plant
engineer/operator to apply his process knowledge in the implementation of MPC, with little or no
understanding of its mathematical complexities. The entire process of generating the controller is
3
Copyright 2000 Instrument Society of America. All rights reserved
embedded in the application instead of layering it on top of the control system as in traditional
approaches. The process followed in MPC development and maintenance is illustrated in Figure 3.
Decision is made to
improve unit control
using MPC
Step 1
Create Module containing
MPC Block, Download
Step 2
MPC I/O automatically
assigned to Historian
Step 3
Step 4
Step 5
Data
Historian
Step 6
Step 7
Identify Model
and generate
MPC Control
Checkout using
Simulation block
Download control to
workstation, use
simulation, train
Plant testing – change
process over normal
range of operation
If Regeneration
Needed
Download control to
controller, commission
and monitor operation
Figure 3. Steps in MPC Implementation
This represents inverting the flow path of traditional implementation techniques so that data collection
and screening follow (not precede) configuration and download to the application controller or device
that will implement MPC. This is followed by model creation, editing and verification, and inversion of
the model to generate the control law that is downloaded to the controlling device for online execution.
This implementation cycle is shown in Figure 2b in direct comparison with traditional methods.
The implemented control strategy uses what are commonly referred to as function blocks (in the
Fieldbus control paradigm [4]), wherein each function block is a part (e.g., a subroutine) of an overall
control routine and operates in conjunction with other function blocks to implement control loops within
the process control system. Function blocks typically perform one of an input function (transmitter,
sensor, etc.), a control function (PID, fuzzy logic, etc.) or an output function (e.g., a valve). It must
however be noted that the control routines may take any form, including software, firmware, hardware,
etc. Similarly, the control strategy or control loops/modules could be designed and implemented using
conventions other than function blocks, such as ladder logic, sequential function charts, etc. or using any
desired programming language or paradigm. MPC development is integrated as part of the control
strategy, obviating the need for off-line mathematical data processing packages, or development of
interfacing layers between the process control system and the MPC application. Furthermore, this
approach takes advantage of the ease of use and flexibility that software based graphical user interface
4
Copyright 2000 Instrument Society of America. All rights reserved
(GUI) techniques offer. By automating the commissioning/implementation of the model predictive
control strategy, the following advantages are passed on to the user:

Ease of use and maintainability – minimize engineering with no expert intervention.
TT
Draft
Gas
Flow
Cold
End
PT
TT
Lime
Mud
AT
Hot
End
ID
Fan
FC
F
F
C
C
C
FT
FT
SC
Hot End Temperature
(Controlled)
Gas Flow
(Manipulated)
ID Fan Speed
(Manipulated)
Lime Kiln
Process
Lime Mud Flow
(Optimized)
Cold End Temperature
(Controlled)
Hood Draft
(Constraint)
O2 for Combustion
(Constraint)
Figure 4. Lime Kiln Process and Instrumentation




Automated features – intuitive graphical user interface.
Automatic compensation for process interaction, measurable load disturbances and constraints.
Increase in Efficiency – significant time and cost savings.
MPC from user (plant operator) perspective – does not require deep theoretical understanding.
IMPLEMENTATION
Figure 4 shows a typical lime kiln process and instrumentation for the recausticizing area of a pulp mill.
The process has 3 inputs and 4 outputs, where gas and ID fan speed are to be manipulated to control the
material and exit gas temperatures at the hot and cold end of the kiln. Constraints on gas and ID fan
speed adjustment are set by limits on O2 and hood draft respectively. The lime mud flow throughput is
to be maximized within the constraints of the ID fan speed limits. The traditional control strategy for this
process becomes quite complex as shown in Figure 5a. A total of six PID controllers, three control
selectors, nine math and dynamic elements would be required. A decoupling network addresses the
interaction between the hot and cold end temperature controls, overrides on gas flow and ID fan speed
adjustment provide for constraints on O2 and draft, and throughput is maximized based on the ID fan
being the limiting factor on production. In this section we step through the generation of a model
predictive controller for this example process using the new methodology.
Configuring the MPC Function Block: Once a decision is taken to improve or provide control by
implementing an MPC procedure (Step 1 of Figure 3), the process is initiated. An MPC control block is
5
Copyright 2000 Instrument Society of America. All rights reserved
created having the desired inputs and outputs connected to process outputs and inputs respectively.
Each MPC block generally has three kinds of inputs: controlled parameter inputs which are the process
variables that are to be maintained at a set point, constrained inputs which are the process variables that
Draft Override
Controller
L/L
DT
+
+
L/L
>
Cold End
Temperature
Controller
DT
O2 Override
Controller
L/L
ID Fan Speed
Override
DT
Hot End
Temperature
Controller
+
Throughput
Control
<
Gas Flow
<
ID Fan Speed
Lime Kiln
Process
Lime Mud Flow
Figure 5a. Traditional PID based control Strategy for Lime Kiln of Figure 4
Hot End Temp
Cold End Temp
ID Fan Speed
Gas Flow
Mud Flow
Lime Kiln
Process
O2
Draft
Figure 5b: Equivalent Control Strategy using a single MPC function block
Note:
For simplicity, PID controllers associated with gas and mud flow are not shown.
Block also shows throughput optimization
6
Copyright 2000 Instrument Society of America. All rights reserved
Data Slices to
be ignored
Start Time
End Time
Figure 6. Trend Display of MPC block data for model identification
are constrained to a particular limit or range based on, for example, physical limitations on the process,
and process disturbance inputs, which are other process variables, such as process inputs that when
altered, cause changes to the controlled parameters. Disturbance parameter inputs are used to foresee
and limit changes to the controlled parameters in a feed forward fashion. Other inputs, such as feedback
from a device may also be provided to the MPC block. Similarly, the outputs of the block may be
connected to control any desired process variable including control loop inputs, device control inputs,
etc. By allowing an extensible number of block parameters, it is possible to create MPC for a diversity
of processes. In the case of optimizing unit throughput, the throughput variable is identified as a control
parameter input, and directly reflects the input that needs to be manipulated to maximize throughput.
Properties such as engineering units, ranges and limits of the parameters are configurable. Such a
function block is described in more detail in [5]. Once configured, the control module (comprising the
MPC and interconnecting blocks) is downloaded to the controlling device. Thereafter, Step 3 of Figure 3
is automated as the block inputs/outputs are automatically assigned to historical data collection. Figure
5b shows a single MPC function block implementing the equivalent control strategy for the lime kiln
process.
Data Collection/Retrieval: For a model based strategy, it is imperative that the data used to generate the
process model be representative of the normal operation of the plant. Collection of such data is typically
the most time consuming processes in traditional implementations. We have automated this process by
implementing a waveform generator in the function block that is designed to cause the process to
operate over the different ranges of inputs expected. The embedded application directly connects to the
downloaded MPC block, such that the existing control strategy may continue to be used while data is
collected. The application display presents the block input-output data in the form of trends (Figure 6).
The user initiates the automated testing procedure by entering the parameters necessary to design the
waveform, such as the approximate response time of the process, the step size of the amplitude of the
waveforms to be delivered to the process inputs, etc. A series of different sets of pulses with the same
7
Copyright 2000 Instrument Society of America. All rights reserved
Figure 7. Process Model Display for Lime Kiln Block
Left Pane – Different models in a directory structure, Right Pane – Response curves for selected model
amplitudes but pseudo-random lengths is delivered to each of the manipulated process inputs and the
effect on the process outputs is observed on the trend display. Not only does data have to be collected,
but it also needs to be screened to check for outliers or other erroneous data, or if it was generated under
any abnormal circumstances and is not representative of the process. The trend display contains the
auto-scaled MPC inputs and outputs in a reasonable time. The start and end time for data to be
considered for process identification is defined by selecting and dragging time bars or data windows
across the trend. If part of the time between the start and end bar is not representative of normal plant
operation, the user can lasso this section of time to select data values to be ignored during identification.
This way the engineer has complete flexibility and control over the selection of data that should be used
for identification in a fairly straightforward and intuitive manner.
Model/Control generation: Model creation and control law derivation comprise the mathematically most
intensive requirements of MPC definition. By making this process transparent to the normal user, this
can be reduced to a one step operation (Step 5, Figure 3). A single button click reads in the selected data,
pre-processes it (removes mean, auto-scales to percent, etc.), creates the dynamic process model and
generates a control matrix by inverting the process model. The identification and control law generation
routines may take on any form, such as a mathematical algorithm, a series of response curves, etc. Step
response modeling using FIR (Finite Impulse Response) and ARX (Auto Regressive) identification
techniques, and a least squares controller minimizing the squared error of controlled variables and
controller output [6], were used for the results presented here. In the application, the screened data is fed
to a modeling routine that generates a dynamic step response model, complete with gains, deadtimes,
and time-constants, for each input-output pair of the MPC block. The response curves may be displayed
in varying degrees of detail, from an overview of the step responses as in Figure 7 to the detailed view
of individual responses for closer examination. In case of a problem in determining either the process
model or the controller, the application indicates possible causes in the modeling and controller
8
Copyright 2000 Instrument Society of America. All rights reserved
generation routine such as insufficient data, erroneous configuration, etc. The model is validated by
computing the root mean squared error between the model prediction and the actual data, and heuristic
checks relying on the availability of both the FIR and ARX responses. Since the model may not be
satisfactory, the generated controller is not directly downloaded into the controlling device. Download
has to be initiated by the operator. Another desired functionality is the capability to compare models and
generate control from different models. Therefore, the process models for a particular MPC block are
automatically saved on creation, and remain in the database until they are explicitly deleted. Model
creation and controller generation can also be carried out as distinct steps, wherein for control derivation
the user can select from a list of models created for that process.
Advanced Options: More experienced users or users with a good knowledge of the process may want to
examine or edit the identified process model. For this purpose, we feel the need to distinguish between a
normal and an expert user. Model editing and verification before control generation facilitate creation of
the most suitable model. A user with a good understanding of the process can manipulate the step
response curve in order to create an altered response model. This can be done either numerically, say by
changing the response parameters such as the time constants, deadtimes and gains, or graphically, by
selecting new beginning or ending points, changing the points on the curve or the slope of the curve, etc.
The fidelity of the model is examined by verifying the predicted outputs against the actual process
outputs in a trend display. Root mean square error is also calculated.
Similarly, the application incorporates expert selectable parameters for control generation from a given
process model. The advanced user may, for example, specify parameters related to the aggressiveness or
robustness of the control, such as the horizon of the MPC control block, the penalties on moves of the
manipulated variables, the penalties on errors in the controlled variables, and so on. In such a case the
generated control matrix reflects the desired characteristics.
Simulation: Once control parameters are generated it is desirable to test the control logic coefficients
against a simulation of the process before actually running it on the real process. This may also be useful
in choosing between different controllers. In the application, this has been realized by providing an MPC
Simulate function block that is configured in a manner similar to the MPC block. The user assigns a
model identified in Step 5 (Figure 3) to a simulation block, provided the configuration of the simulation
block is consistent with the MPC block for which the model was generated. To test control operation,
the simulation block may be communicatively connected to the MPC block. In a different scenario, the
process simulation block may be created using an altered version of the determined process model (by
creating an altered process model) to reflect changes in the process in the course of the life cycle of the
plant. In this case, connection to the MPC block simulates controller operation in the presence of
changes thereby determining the performance of the controller in the presence of model mismatch and
‘what-if’ scenarios. Further, a simulation block developed from the process model may be run in
conjunction with the process and may be used to create virtual process outputs to be used as inputs for
the control block, say in the case of sensor failure.
Comparison of the simulated process outputs with the actual process outputs determines the
process/process-model mismatch and may be useful for controller tuning. The simulation functionality
also provides an environment to train operators on the application of MPC. As for the MPC block, the
simulation block is embedded into the application for ease of use.
9
Copyright 2000 Instrument Society of America. All rights reserved
CONCLUSIONS
The design and implementation of a new and simplified approach to the commissioning and
development of model predictive controllers has been presented. By embedding the MPC function block
in the process control system, and automating the controller development, the benefits of MPC
techniques can be easily applied to a variety of processes without the overheads incurred in traditional
implementations. A GUI based application maintains the underlying MPC technology, while minimizing
the engineering effort and making the implementation process extremely easy and intuitive. Since the
functionality is implemented in the same format as other control blocks within the control system,
integration and operation are fairly straightforward, thereby minimizing downtime. A simulation
environment is provided as part of the application. It is intended that MPC be used extensively to
provide better control than complex PID strategies. Using an example we demonstrate how the
presented novel approach can be used towards realizing this objective. In the future we would be
addressing the adaptive control case in the same paradigm.
REFERENCES
1. Cutler, C. R. and Ramaker, B. L., “Dynamic matrix Control – a computer control algorithm”, AIChE
Annual Meeting, 1979, Houston, TX.
2. Richalet, J., Rault, A., Testud, J. L. and Papon, J., “Algorithmic control of industrial processes”,
Proceedings of the 4th IFAC Symposium on Identification and System Parameter Estimation,
pp.1119-1167, 1976.
3. Camacho, E. F. and Bordons, C., “Model Predictive Control in the Process Industry”, 1995,
Springer-Verlag, London, Great Britain.
4. US Patent Application, Fisher File No: 59-11211, Blevins, T., Wojsznis, W., Tzovla, V. and Thiele,
D., “Integrated Advanced Control Blocks in Process Control Systems”.
5. Thiele, Dirk, “Benefits and challenges of implementing model predictive control as a function
block”, to appear in Proceedings of ISA Expo/2000, 21-24 August 2000, New Orleans, LA.
6. Wojsznis, W. K., Blevins, T. L. and Nixon, M., “Easy Robust Optimal Predictive Controller”, to
appear in Proceedings of ISA Expo/2000, 21-24 August 2000, New Orleans, LA.
10
Copyright 2000 Instrument Society of America. All rights reserved