Course: Process Control

Topic 8: Advanced Classical Control Architectures

8.1. Cascade Control For Improved Disturbance Rejection

8.1.1. The Cascade Control Architecture

Two popular control strategies for improved disturbance rejection performance

are cascade control and feed forward with feedback trim.
Improved performance comes at a price. Both strategies require that additional
instrumentation be purchased, installed and maintained. Both also require additional
engineering time for strategy design, tuning and implementation.
The cascade architecture offers alluring additional benefits such as the ability to
address multiple disturbances to our process and to improve set point response
performance.
In contrast, the feed forward with feedback trim architecture is designed to
address a single measured disturbance and does not impact set point response
performance in any fashion (explored in a future topic).

The Inner Secondary Loop.

As shown in Fig. 8.1, the traditional feedback contlol loop is in a deshed circle.

Fig. 8.1. Traditional feedback contlol loop is in a deshed circle

Were:
SP2 = inner secondary set point;
CO2 = inner secondary controller output signal;
PV2 = inner secondary measured process variable signal;
D2 = inner disturbance variable (often not measured or available as a signal);
FCE = final control element such as a valve, variable speed pump or
compressor, etc.

The Nested Cascade Architecture.

To construct a cascade architecture, we literally nest the secondary control loop inside
a primary loop as shown in the block diagram below. Note that outer primary PV1 is
our process variable of interest in this implementation. PV1 is the variable we would
be measuring and controlling if we had chosen a traditional single loop architecture
instead of a cascade.

Fig. 8.2. Cascade structure is a contlol loop within a contlol loop

Because we are willing to invest the additional effort and expense to improve
the performance response of PV1, it is reasonable to assume that it is a variable
important to process safety and/or profitability. Otherwise, it does not make sense to
add the complexity of a cascade structure.

Naming Conventions
Like many things in the PID control world, vendor documentation is not
consistent. The most common naming conventions we see for cascade (also called
nested) loops are:
▪ secondary and primary
▪ inner and outer
▪ slave and master
In an attempt at clarity, we are somewhat repetitive in this topic by using labels
like "inner secondary" and "outer primary."

Two PVs, Two Controllers, One Valve

Notice from the block diagrams that the cascade architecture has:
▪ two controllers (an inner secondary and outer primary controller)
▪ two measured process variable sensors (an inner PV2 and outer PV1)
▪ only one final control element (FCE) such as a valve, pump or compressor.
How can we have two controllers but only one FCE? Because as shown in the
diagram above, the controller output signal from the outer primary controller, CO1,
becomes the set point of the inner secondary controller, SP2.
The outer loop literally commands the inner loop by adjusting its set point.
Functionally, the controllers are wired such that SP2 = CO1 (thus, the master and slave
terminology referenced above).
This is actually good news from an implementation viewpoint. If we can install
and maintain an inner secondary sensor at reasonable cost, and if we are using a PLC
or DCS where adding a controller is largely a software selection, then the task of
constructing a cascade control structure may be reasonably straightforward.

Early Warning is Basis for Success

 As shown below, an essential element for success in a cascade design is the
measurement and control of an "early warning" process variable.

Fig. 8.3. Cascade control depends on an “Early warning” variable

In the cascade architecture, inner secondary PV2 serves as this early warning
process variable. Given this, essential design characteristics for selecting PV2 include
that:
▪ it be measurable with a sensor,
▪ the same FCE (e.g., valve) used to manipulate PV1 also manipulates PV2,
▪ the same disturbances that are of concern for PV1 also disrupt PV2, and
▪ PV2 responds before PV1 to disturbances of concern and to FCE
manipulations.
Since PV2 sees the disruption first, it provides our "early warning" that a
disturbance has occurred and is heading toward PV1. The inner secondary controller
can begin corrective action immediately. And since PV2 responds first to final control
element (e.g., valve) manipulations, disturbance rejection can be well underway even
before primary variable PV1 has been substantially impacted by the disturbance.
With such a cascade architecture, the control of the outer primary process
variable PV1 benefits from the corrective actions applied to the upstream early
warning measurement PV2.

Disturbance Must Impact Early Warning Variable PV2

As shown below, even with a cascade structure, there will likely be disturbances
that impact PV1 but do not impact early warning variable PV2.

Fig. 8.4.Outer disturbance D1 do not impact early warning variable PV2

 The inner secondary controller offers no "early action" benefit for these outer
disturbances. They are ultimately addressed by the outer primary controller as the
disturbance moves PV1 from set point.
On a positive note, a proper cascade can improve rejection performance for any
of a host of disturbances that directly impact PV2 before disrupting PV1.

An Illustrative Example
To illustrate the construction and value of a cascade architecture, consider the
liquid level control process shown below [1]. This is a variation on our gravity drained
tanks, so hopefully, the behavior of the process below follows intuitively from our
previous investigations.

Fig. 8.5. Cascade architecture for liquid level control process

As shown above, the tank is essentially a barrel with a hole punched in the
bottom. Liquid enters through a feed valve at the top of the tank. The exit flow is
liquid draining freely by the force of gravity out through the hole in the tank bottom.
The control objective is to maintain liquid level at set point (SP) in spite of
unmeasured disturbances. Given this objective, our measured process variable (PV) is
liquid level in the tank. We measure level with a sensor and transmit the signal to a
level controller (the LC inside the circle in the diagram).
After comparing set point to measurement, the level controller (LC) computes
and transmits a controller output (CO) signal to the feed valve. As the feed valve opens
and closes, the liquid feed rate entering the top of the tank increases and decreases to
raise and lower the liquid level in the tank.
This "measure, compute and act" procedure repeats every loop sample time, T,
as the controller works to maintain tank level at set point.

The Disturbance
The disturbance of concern is the pressure in the main liquid header. As shown
in the diagram above, the header supplies the liquid that feeds our tank. It also supplies
liquid to several other lines flowing to different process units in the plant.
Whenever the flow rate of one of these other lines changes, the header pressure
can be impacted. If several line valves from the main header open at about the same
time, for example, the header pressure will drop until its own control system corrects
the imbalance. If one of the line valves shuts in an emergency action, the header
pressure will momentarily spike.
As the plant moves through the cycles and fluctuations of daily production, the
header pressure rises and falls in an unpredictable fashion. And every time the header
pressure changes, the feed rate to our tank is impacted.

Problem with Single Loop Control

The single loop architecture in the diagram above attempts to achieve our
control objective by adjusting valve position in the liquid feed line. If the measured
level is higher than set point, the controller signals the valve to close by an appropriate
percentage with the expectation that this will decrease feed flow rate accordingly.
But feed flow rate is a function of two variables:
▪ feed valve position, and
▪ the header pressure pushing the liquid through the valve (a disturbance).
To explore this, we conduct some thought experiments [1]:
Thought Experiment #1: Assume that the main header pressure is perfectly
constant over time. As the feed valve opens and closes, the feed flow rate and thus
tank level increases and decreases in a predictable fashion. In this case, a single loop
structure provides acceptable level control performance.
Thought Experiment #2: Assume that our feed valve is set in a fixed position
and the header pressure starts rising. Just like squeezing harder on a spray bottle, the
valve position can remain constant yet the rising pressure will cause the flow rate
through the fixed valve opening to increase.
Thought Experiment #3: Now assume that the header pressure starts to rise at
the same moment that the controller determines that the liquid level in our tank is too
high. The controller can be closing the feed valve, but because header pressure is
rising, the flow rate through the valve can actually be increasing.
As presented in Thought Experiment #3, The changing header pressure (a
disturbance) can cause a contradictory outcome that can confound the controller and
degrade control performance.

A Cascade Control Solution

For high performance disturbance rejection, it is not valve position, but rather,
feed flow rate that must be adjusted to control liquid level [1].
Because header pressure changes, increasing feed flow rate by a precise amount
can sometimes mean opening the valve a lot, opening it a little, and because of the
changing header pressure, perhaps even closing the valve a bit.
Below is a classic level-to-flow cascade architecture. As shown, an inner
secondary sensor measures the feed flow rate. An inner secondary controller receives
this flow measurement and adjusts the feed flow valve.
 Fig. 8.6. A classic level-to-flow cascade architecture

With this cascade structure, if liquid level is too high, the primary level
controller now calls for a decreased liquid feed flow rate rather than simply a decrease
in valve opening. The flow controller then decides whether this means opening or
closing the valve and by how much.
Note in the diagram that, true to a cascade, the level controller output signal
(CO1) becomes the set point for the flow controller (SP2).
Header pressure disturbances are quickly detected and addressed by the
secondary flow controller. This minimizes any disruption caused by changing header
pressure to the benefit of our primary level control process.

The Level-to-Flow Cascade Block Diagram

As shown in the block diagram below, our level-to-flow cascade fits into our
block diagram structure. As required, there are:
▪ Two controllers - the outer primary level controller (LC) and inner secondary feed
flow controller (FC)
▪ Two measured process variable sensors - the outer primary liquid level (PV1) and
inner secondary feed flow rate (PV2)
▪ One final control element (FCE) - the valve in the liquid feed stream

Fig. 8.7. Formal level-to-flow cascade structure

As required for a successful design, the inner secondary flow control loop is
nested inside the primary outer level control loop. That is:
▪ The feed flow rate (PV2) responds before the tank level (PV1) when the header
 pressure disturbs the process or when the feed valve moves.
▪ The output of the primary controller, CO1, is wired such that it becomes the set
point of the secondary controller, SP2.
▪ Ultimately, level measurement, PV1, is our process variable of primary concern.
Protecting PV1 from header pressure disturbances is the goal of the cascade.

Design and Tuning

The inner secondary and outer primary controllers are from the PID family of
algorithms. We have explored the design and tuning of these controllers in numerous
topics, so as we will see, implementing a cascade builds on many familiar tasks.
There are a number of issues to consider when selecting and tuning the
controllers for a cascade. We explore next an implementation recipe for cascade
control.

8.1.2. An Implementation Recipe for Cascade Control

When improved disturbance rejection performance is our goal, one benefit of a

cascade control (nested loops) architecture over a feed forward strategy is that
implementing a cascade builds upon our existing skills.
The cascade block diagram is presented in the graphic below and discussed in
detail in this topic. As shown, a cascade has two controllers. Implementation is a
familiar task because the procedure is essentially to employ our controller design and
tuning recipe twice in sequence.

Fig. 8.8. The cascade structure is a secondary lop inside a primary loop

The cascade architecture variables listed in the block diagram include:

CO2 = inner secondary controller output signal to the FCE
PV2 = the early warning inner secondary process variable
SP2 = CO1 = inner secondary set point equals the outer primary controller
output
PV1 = outer primary process variable
SP1 = outer primary set point
D2 = disturbances that impact the early warning PV2 before they impact PV1
FCE = final control element (e.g., a valve) is continuously adjustable between
on/open and off/closed, and that impacts PV2 before it impacts PV1.
 Two Bump Tests Required
Two bump tests are required to generate the dynamic process response data
needed to design and tune the two controllers in a cascade implementation [1].
• First the Inner Secondary Controller
A reliable procedure begins with the outer primary controller in manual mode
(open loop) as we apply the design and tuning recipe to the inner secondary controller.
Thus, with our process steady at (or as near as practical to) its design level of
operation (DLO), we generate dynamic CO2 to PV2 process response data with either
a manual mode (open loop) bump test or a more sophisticated SP driven (closed loop)
bump test.
The objective for the inner secondary controller is timely rejection of
disturbances D2 based on the measurement of an "early warning" secondary process
variable PV2. Good disturbance rejection performance is therefore of fundamental
importance for the inner secondary controller.
Yet as shown in the block diagram above and detailed in this section, the output
signal of the outer primary controller becomes a continually updated set point for the
inner secondary controller (SP2 = CO1). Since we expect the inner secondary
controller to respond crisply to these rapidly changing set point commands, it must
also be tuned to provide good SP tracking performance.
In the perfect world, we would balance disturbance rejection and set point
tracking capability for the inner secondary controller. But we cannot shift our attention
to the outer primary controller until we have tested and approved the inner secondary
controller performance.
In production processes with streams comprised of gases, liquids, powders,
slurries and melts, disturbances are often unmeasured and beyond our ability to
manipulate at will. So while we desire to balance disturbance rejection and set point
tracking performance for the inner secondary controller, in practice, SP tracking tests
tend to provide the most direct route to validating inner secondary controller
performance.
• Then the Outer Primary Controller
Once implemented, the inner secondary controller literally becomes part of the
“process” from the outer primary controller’s view.
As a result, any alteration to the inner secondary controller (e.g., tuning
parameter adjustments, algorithm modifications, sample time changes) can change the
process gain, Kp, time constant, Tp, and/or dead time, Өp, of the outer loop CO1 to
PV1 dynamic response behavior. This, in turn, impacts the design and tuning of the
outer primary controller.
Thus, we must design, tune, test, accept and then "lock down" the inner
secondary controller, leaving it in automatic mode with a fixed configuration. Only
then, with our process steady and at (or very near) its DLO, can we proceed with the
second bump test to complete the design and tuning of the outer primary controller.

Minimum Criteria for Success

A successful cascade implementation requires that early warning process
variable PV2 respond before outer primary PV1 both to disturbances of concern (D2)
and to final control element (FCE) manipulations (e.g., a valve) [1].
 Responding first to disturbances means that the inner secondary D2 to PV2
dead time, Өp, must be smaller than the overall D2 to PV1 dead time, or:
Өp (D2 −› PV2) < Өp (D2 −› PV1)
Responding first to FCE manipulations means that the inner secondary CO2 to
PV2 dead time must be smaller than the overall CO2 to PV1 dead time, or:
Өp (CO2 −› PV2) < Өp (CO2 −› PV1)
If these minimum criteria are met, then a cascade control architecture can show
benefit in improving disturbance rejection.

P-Only vs. PI for Inner Secondary Controller

A subtle design issue relates to the choice of control algorithm for the inner
secondary controller [1]. While perhaps not intuitive, an inner secondary P-Only
controller will provide better performance than a PI controller in many cascade
implementations.
• Defining Performance
We focus all assessment of control performance on outer primary process
variable PV1. Performance is "improved" if the cascade structure can more quickly
and efficiently minimize the impact of disturbances D2 on PV1. Given the nature of
the cascade structure, it is assumed that D2 first disrupts PV2 as it travels to PV1.
Since PV2 was selected because of its value as an early warning variable, our
interest in PV2 control performance extends only to its ability to provide protection to
outer primary process variable PV1. We are otherwise unconcerned if PV2 displays
offset, shows a large response overshoot, or any other performance characteristic that
might be considered undesirable in a traditional measured PV.
• Is the Inner Loop "Fast" Relative to the Overall Process?
A cascade architecture with a P-Only controller on the inner secondary loop
will provide improved disturbance rejection performance over that achievable with a
traditional single loop controller if the minimum criteria for success as discussed
above are met.
A PI controller on the inner loop may provide even better performance than P-
Only, but only if the dynamic character of the inner secondary loop is "fast" relative to
that of the overall process.
If the inner secondary loop dynamic character is not sufficiently fast, then a PI
controller on the inner loop, even if properly designed and tuned, will not perform as
well as P-Only. It is even possible that a PI controller could degrade performance to an
extent that the cascade architecture performs worse than a traditional (non-cascade)
single loop controller.
• Why PI controllers Need a "Fast" Inner Loop
At every sample time T, the outer primary controller computes a controller
output signal that is fed as a new set point to the inner secondary controller (CO1 =
SP2). The inner secondary controller continually makes CO2 moves as it works to
keep PV2 equal to the ever-changing SP2.
The cascade will fail if the inner loop cannot keep pace with the rapid-fire
stream of SP2 commands. If the inner secondary controller "falls behind" (or more
specifically, if the CO2 actions induce dynamics in the inner loop that do not settle
quickly relative to the dynamic behavior of the overall process), the benefit of the
early warning PV2 measurement is lost.
A P-Only controller can provide energetic control action when tracking set
points and rejecting disturbances. Its very simplicity can be a useful attribute in a
cascade implementation because a P-Only controller quickly completes its response
actions to any control error (E2 = SP2 – PV2). While P-Only controllers display offset
when operation moves from the DLO, this is not considered a performance problem
for inner secondary PV2.
With two tuning parameters, a PI controller has a greater ability to track set
points and reject disturbances. However, this added sophistication yields a controller
with a greater tendency to "roll" or oscillate. And the ability to eliminate offset,
normally considered a positive attribute for PI controllers, can require a longer series
of control actions that extends how quickly a loop settles.
Thus, a PI controller generally needs more time (a faster inner loop) to exploit
its enhanced capability relative to that of a P-Only controller. If the dynamic nature of
a particular cascade does not provide this time, then an inner-loop P-Only controller is
the proper choice.

The Cascade Implementation Recipe

Below is a generally conservative approach for cascade control implementation
[1]. Note that the recipe assumes that:
▪ Early warning PV2 responds before PV1 both to D2 and CO2 changes as discussed
above in the minimum criteria for cascade success.
▪ A first order plus dead time (FOPDT) model of dynamic process data yields a
process time constant, Tp, that is much larger than the dead time, Өp. This permits
us to focus on the time constant as the marker for "fast" dynamic process behavior.
1) Starting from a steady operation, step, pulse or otherwise perturb CO2
around the design level of operation (DLO). Collect CO2, PV2 and PV1 dynamic data
as the process variables respond. The inner secondary loop can be in automatic (closed
loop) if the controller is sufficiently active to force a clear dynamic response in PV2.
The outer primary loop is normally in manual (open loop).
2) Fit a FOPDT model to the inner secondary process (CO2 −› PV2) data and
another to the overall process (CO2 −› PV1) data, yielding [1]:

Inner Secondary Overall Process

Process Gain (how far) Kp (CO2 −› PV2) Kp (CO2 −› PV1)
Time Constant (how fast) Tp (CO2 −› PV2) Tp (CO2 −› PV1)
Dead Time (how much delay) Өp (CO2 −› PV2) Өp (CO2 −› PV1)

Note from the block diagram at the top of the topic that the inner secondary
process dynamics are contained within the overall process dynamics. Therefore, the
physics of a cascade implies that the time constant and dead time values for the inner
process will not be greater than those of the overall process, or:
Tp (CO2 −› PV2) ≤ Tp (CO2 −› PV1) and
Өp (CO2 −› PV2) ≤ Өp (CO2 −› PV1)
 3) Use the time constants to decide whether the inner secondary dynamics are
fast enough for a PI controller on the inner loop [1].
Case 1: If the inner secondary process is not at least 3 times faster than the
overall process, it is not fast enough for a PI controller.
• If 3Tp (CO2 −› PV2) > Tp (CO2 −› PV1) => Use P-Only controller
Case 2: If the inner process is 3 to 5 times faster than the overall process, then
P-Only will perform similar to PI control. Use our own preference.
• If 3Tp (CO2 −› PV2) ≤ Tp (CO2 −› PV1) ≤ 5Tp (CO2 −› PV2) => Use
either P-Only or PI controller
Case 3: If the inner process is more than 5 times faster than the overall process,
it is "fast" and a PI controller will provide improved performance.
• If 5Tp (CO2 −› PV2) < Tp (CO2 −› PV1) => Use PI controller
4) When we have determine whether the inner secondary controller should be a
P-Only or PI algorithm, we tune it and test it. Once acceptable performance has been
achieved, leave the inner secondary controller in automatic; it now literally becomes
part of the outer primary process.
5) Select an algorithm with integral action for the outer primary controller (PI,
PID or PID with CO filter) to ensure that offset is eliminated. Tune the primary
controller using the design and tuning recipe. Note that bumping the outer primary
process requires stepping, pulse or otherwise perturbing the set point (SP2) of the inner
secondary controller.
6) With both controllers in automatic, tuning of the cascade is complete.

Cascade Control of the Jacketed Stirred Reactor

Once a cascade control architecture is put in service, we must remember that
every time the inner secondary controller is changed in any way, the outer primary
controller should be reevaluated for performance and retuned as necessary.
We should also be aware that the recipe presented above is a general procedure
intended for broad application. Thus, there will be occasional exceptions to the rules.
We next explore a case study on the cascade control of the jacketed stirred
reactor.

8.1.3. A Cascade Control Architecture for the Jacketed Stirred Reactor

Our control objective for the jacketed stirred reactor process is to minimize the
impact on reactor operation when the temperature of the liquid entering the cooling
jacket changes. We have previously explored the modes of operation and dynamic
CO-to-PV behavior of the reactor. We also have established the performance of a
single loop PI controller and a PID with CO Filter controller in this disturbance
rejection application.
Here we consider a cascade architecture as a means for improving the
disturbance rejection performance in the jacketed stirred reactor.

The Single Loop Jacketed Stirred Reactor

As shown in the process graphic below [1], the reactor exit stream temperature
is controlled by adjusting the flow rate of cooling liquid through an outer shell (or
cooling jacket) surrounding the main vessel.
 Fig. 8.9. Jacketed stirred reactor in automatic mode (Closed loop)

As labeled above for the single loop case:

CO = signal to valve that adjusts cooling jacket liquid flow rate (controller
output, %)
PV = reactor exit stream temperature (measured process variable, oC)
SP = desired reactor exit stream temperature (set point, oC)
D = temperature of cooling liquid entering the jacket (major disturbance, oC)
The control objective is to maintain the reactor exit stream temperature (PV) at
set point (SP) in spite of unmeasured changes in the temperature of cooling liquid
entering the jacket (D).
We measure exit stream temperature with a sensor and transmit the signal to a
temperature controller (the TC inside the circle in the diagram). After comparing SP to
PV, the temperature controller computes and transmits a CO signal to the cooling
jacket liquid flow valve.
As the valve opens and closes, the flow rate of liquid through the jacket
increases and decreases. Like holding a hot frying pan under a water faucet, higher
flow rates of cooling liquid remove more heat. Thus, a higher flow rate of cooling
liquid through the jacket cools the reactor vessel, lowering the reactor exit stream
temperature.

Problems with Single Loop Control

The single loop architecture in the diagram above attempts to achieve our
control objective by adjusting the flow rate of cooling liquid through the jacket.
If the measured temperature is higher than set point, the controller signals the
valve to increase cooling liquid flow by an appropriate percentage with the expectation
that this will decrease reactor exit stream temperature accordingly.
A concern discussed in detail in this section is that the temperature of the
cooling liquid entering the jacket (D) can change, sometimes rather quickly. This can
disrupt reactor operation as reflected in the measured reactor exit stream temperature
PV.
So reactor exit stream temperature PV is a function of two variables:
 ▪ cooling liquid flow rate, and
▪ the temperature of the cooling liquid entering the cooling jacket (D).
To explore this, we conduct some thought experiments [1]:
Thought Experiment #1: Assume that the temperature of the cooling liquid
entering the jacket (D) is constant over time. If the cooling liquid flow rate increases
by a certain amount, the reactor exit stream temperature will decrease in a predictable
fashion (and vice versa). Thus, a single loop structure should provide good
temperature control performance.
Thought Experiment #2: Assume that the temperature of cooling liquid entering
the jacket (D) starts rising over time. A warmer cooling liquid can carry away less heat
from the vessel. If the cooling liquid flow rate is constant through the jacket, the
reactor will experience less cooling and the exit stream temperature will increase.
Thought Experiment #3: Now assume that the temperature of cooling liquid
entering the jacket (D) starts to rise at the same moment that the reactor exit stream
temperature moves above set point. The controller will signal for a cooling liquid flow
rate increase, yet because the cooling liquid temperature is rising, the heat removed
from the reactor vessel can actually decrease. Until further corrective action is taken,
the reactor exit stream temperature can increase.
As presented in Thought Experiment #3, the changing temperature of cooling
liquid entering the jacket (a disturbance) can cause a contradictory outcome that can
confound the controller and degrade control performance.

Cascade Control Improves Disturbance Rejection

As we established in our study of the cascade control architecture, an essential
element for success in a cascade (nested loops) design is the measurement and control
of an "early warning" process variable, PV2, as illustrated in the Fig. 8.2, section 8.1.1.
Since disruptions impact PV2 first, it provides our "early warning" that a
disturbance is heading toward our outer primary process variable, PV1. The inner
secondary controller can begin corrective action immediately. And since PV2 responds
first to valve manipulations, disturbance rejection can begin before PV1 has been
visibly impacted.

A Reactor Cascade Control Architecture

The thought experiments above highlight that it is problematic to control exit
stream temperature by adjusting the cooling liquid flow rate.
An approach with potential for "tighter" control is to adjust the temperature of
the cooling jacket itself. This provides a clear process relationship in that, if we seek a
higher reactor exit stream temperature, we know we want a higher cooling jacket
temperature. If we seek a lower reactor exit stream temperature, we want a lower
cooling jacket temperature.
Because the temperature of cooling liquid entering the jacket changes,
increasing cooling jacket temperature by a precise amount may mean decreasing the
flow rate of cooling liquid a lot, decreasing it a little, and perhaps even increasing the
flow rate a bit.
A "cheap and easy" proxy for the cooling jacket temperature is the temperature
of cooling liquid exiting at the jacket outlet. Hence, we choose this as our inner
secondary process variable, PV2, as we work toward the construction of a nested
cascade control architecture.
Adding a temperature sensor that measures PV2 provides us the early warning
that changes in D, the temperature of cooling liquid entering the jacket, are about to
impact the reactor exit stream temperature, PV1.
The addition of a second temperature controller (TC2) completes construction
of a jacketed reactor control cascade as shown in the graphic below [1].

Fig. 8.10. The jacketed stiired reactor cascade architecture

Now, our inner secondary control loop measures the temperature of cooling
liquid exiting at the jacket outlet (PV2) and sends a signal (CO2) to the valve adjusting
cooling jacket flow rate. The valve increases or decreases the flow rate of cooling
liquid if the jacket temperature needs to fall or rise, respectively.
Our outer loop maintains reactor exit stream temperature (our process variable
of primary interest and concern) as PV1. Note in the graphic above that the controller
output of our primary controller, CO1, becomes the set point of our inner secondary
controller, SP2.
If PV1 needs to rise, the primary controller signals a higher set point for the
jacket temperature (CO1 = SP2). The inner secondary controller then decides if this
means opening or closing the valve and by how much.
Thus, variations in the temperature of cooling liquid entering the jacket (D) are
addressed quickly and directly by the inner secondary loop to the benefit of PV1.
The cascade architecture variables are identified on the above graphic and listed
below:
PV2 = cooling jacket outlet temperature is our "early warning" process variable
o
( C)
CO2 = controller output to valve that adjusts cooling jacket liquid flow rate (%)
SP2 = CO1 = desired cooling jacket outlet temperature (oC)
PV1 = reactor exit stream temperature (oC)
SP1 = desired reactor exit stream temperature (oC)
 D = temperature of cooling liquid entering the jacket (oC)
The inner secondary PV2 (cooling jacket outlet temperature) is a proper early
warning process variable because:
▪ PV2 is measurable with a temperature sensor.
▪ The same valve used to manipulate PV1 also manipulates PV2.
▪ The same disturbance that is of concern for PV1 also disrupts PV2.
▪ PV2 responds before PV1 to the disturbance of concern and to valve
manipulations.

Reactor Cascade Block Diagram

The jacketed stirred reactor block diagram for this nested cascade architecture is
shown below.

Fig. 8.11. The jacketed stiired reactor cascade block diagram

As expected for a nested cascade, this architecture has:

▪ two controllers (an inner secondary and outer primary controller)
▪ two measured process variable sensors (an inner PV2 and outer PV1)
▪ only one valve (to adjust cooling liquid flow rate)

Tuning a Cascade
With a cascade architecture established, we apply our implementation recipe for
cascade control and explore the disturbance rejection capabilities of this structure.

8.1.4. Cascade Disturbance Rejection in the Jacketed Stirred Reactor

Our control objective for the jacketed stirred reactor is to maintain reactor exit
stream temperature at set point in spite of disturbances caused by a changing cooling
liquid temperature entering the vessel jacket. In previous topics, we have established
the design level of operation for the reactor and explored the performance of a single
loop PI controller and a PID with CO Filter controller in meeting our control objective.
We also have proposed a cascade control architecture for the reactor that offers
potential for improving disturbance rejection performance. We now apply our
proposed architecture following the implementation recipe for cascade control. Our
goal is to demonstrate the implementation procedure, understand the benefits and
drawbacks of the method, and explore cascade disturbance rejection performance for
this process.

The Reactor Cascade Control Architecture

The reactor cascade architecture is shown in in Fig. 8.11,
where:
CO2 = controller output to valve that adjusts cooling jacket liquid flow rate (%)
PV2 = cooling jacket outlet temperature is our "early warning" process variable
(oC)
SP2 = CO1 = desired cooling jacket outlet temperature (oC)
PV1 = reactor exit stream temperature (oC)
SP1 = desired reactor exit stream temperature (oC)
D = temperature of cooling liquid entering the jacket (oC)

Design Level of Operation (DLO)

The details and discussion for our DLO are presented in this topic and are
summarized:
▪ Design PV1 and SP1 = 90 oC with approval for brief dynamic testing of ±2 oC
▪ Design D = 43 oC with occasional spikes up to 50 oC

Minimum Criteria for Success

A successful cascade implementation requires that early warning process
variable PV2 respond before outer primary PV1 both to changes in the jacket cooling
liquid temperature disturbance (D) and to changes in inner secondary controller output
signal CO2. The plots below [1] verify that both of these criteria are met with the
architecture shown in the graphic above.

Fig. 8.12. Verify that PV2 respnds before PV1

Expressed concisely, the plots show that the delay in response (or dead time,
Өp) follows the rule:
Өp (D→PV2) < Өp (D→PV1) and Өp (CO2→PV2) < Өp (CO2→PV1)
Thus, a cascade control architecture should improve disturbance rejection
performance relative to a single loop architecture.
 P-Only vs. PI for Inner Secondary Controller
The cascade implementation recipe first helps us decide if the inner secondary
controller is fast enough for a PI algorithm or if it is better suited for a P-Only
algorithm. The decision is based on the size of the inner secondary time constant
relative to that of the overall process time constant.
To compute these time constants, we need to bump the process and analyze the
dynamic process response data. In this example we choose to place both inner
secondary and outer primary controllers in manual mode (open loop) during the bump
test. An alternative not explored here is to have the inner secondary controller in
automatic mode with tuning sufficiently active to force a clear dynamic response in
PV2.
Following the steps of the cascade implementation recipe [1]:
1) With the process steady at the design level of operation (DLO), we perform
a doublet test, choosing here to move CO2 from 34.3%→39.3%→29.3%→34.3%. We
record both PV2 and PV1 dynamic data as the process responds. We use this "step 1
data set" as we proceed with the implementation recipe.
2) As shown in the plots below [1], we use commercial software to fit a first
order plus dead time (FOPDT) model to the inner secondary process (CO2→PV2)
dynamic data and another to the overall process (CO2→PV1) dynamic data :

Fig. 8.13. Inner secondary and overall process bumps tests

The FOPDT model parameters from these bump tests are summarized [1]:

Inner Secondary Overall Process

(CO2 −› PV2) (CO2 −› PV1)
Process gain, Kp = – 0.57 °C/% – 0.51 °C/%
Time constant, Tp = 2.3 min 2.2 min
Dead time, Өp = 0.25 min 0.81 min

The cascade block diagram implies that the time constant and dead time values
for the inner process are contained within and contribute to the dynamics of the overall
process. Thus, we can surmise that:
Tp (CO2→PV2) ≤ Tp (CO2→PV1) and Өp (CO2→PV2) ≤ Өp (CO2→PV1)
 Yet the values in the table above indicate that this seemingly fundamental
relationship does not hold true for the jacketed stirred reactor. In fact, when using a
FOPDT model approximation of the dynamic response data, the time constant of the
inner secondary process is slightly larger (longer) than that of the overall process.
The process graphic at the top of this topic shows a main reactor vessel with a
large volume of liquid relative to that of the cooling jacket. The function of the cooling
jacket is to remove heat energy to regulate reactor vessel temperature.
It seems logical that because of the volume differences, as long as the liquid
temperature in the large reactor is changing, the temperature of the liquid in the small
cooling jacket must follow. And the liquid in the reactor acts as a heat source because
the chemical reaction inside the vessel generates heat energy faster as reactor
temperature rises (and vice versa).
This intertwined relationship of heat generation and removal combined with
relative sizes of the reactor and jacket offers one physical rationalization as to why the
jacket (inner secondary) Tp might reasonably be longer than that of the vessel (overall
process) Tp.
A simpler explanation is that the sensor used to measure temperature in the
cooling jacket outlet flow was improperly specified at the time of purchase, and
unfortunately, it responds slowly to actual cooling liquid changes. This additional
response time alone could account for the observed behavior.
In any case, the dead time of the overall process is three times that of the inner
secondary controller, and thus, PV2 provides a clear early warning that we can exploit
for a cascade design. So while the simple cascade recipe has limitations that require
our judgment, it provides valuable insights that enable us to proceed.
3) The cascade implementation recipe uses a time constant comparison to
decide whether the inner secondary loop is fast enough for a PI controller. We reach a
true statement with case 1 of the decision tree in step 3 of the recipe. That decision is:
if 3Tp (CO2→PV2) > Tp (CO2→PV1) => Use P-Only controller
or using the parameters in the table above:
if 3(2.3 min) > 2.2 min => Use a P-Only controller.

Inner Secondary Controller

4) Our cascade implementation recipe states that a P-Only algorithm is the best
choice for the inner secondary controller. To explore this decision, we run four trials
and compare P-Only and PI algorithms side-by-side. We are able to use the same "step
1 data set" for the design and tuning of all four of these inner secondary controllers [1]:
TRIAL 1: moderate P-Only
TRIAL 2: aggressive P-Only
TRIAL 3: moderate PI
TRIAL 4: aggressive PI
As listed in the table in step 2 above, a first order plus dead time (FOPDT)
model fit of the "step 1 data set" collected around our design level of operation (DLO)
yields inner secondary FOPDT model parameters:
CO2 −› PV2 model: Kp = – 0.57 °C/%; Tp = 2.3 min; Өp = 0.25 min
Following our controller design and tuning recipe, we use these FOPDT model
parameters in rules and correlations to complete the secondary controller design.
 P-Only Controller design and tuning, including the use of the ITAE tuning
correlation for computing controller gain, Kc, from FOPDT model parameters is
summarized in the example in this topic. Following those details [1]:

P-Only algorithm: CO = CObias + Kc∙e(t)

TRIAL 1: Moderate P-Only

( ) ( )
1 .22 1.22
0. 2 Tp 0. 2 2. 3
Kc= = =−5 .3 %/ °C
Kp Θp −0. 57 0 .25
TRIAL 2: Aggressive P-Only
Kc = 2.5 (Moderate Kc) = 2.5 (–5.3) = – 13.3 %/oC

PI Controller design and tuning, including computing controller gain, Kc, and
reset time, Ti, from FOPDT model parameters is summarized in the example in this
section.
Following those details:
Kc
CO=CObias+Kc e(t )+ ∫ e(t )dt
PI algorithm: Ti
TRIAL 3: Moderate PI
Moderate Tc = the larger of 1·Tp or 8·Өp = larger of 1(2.3 min) or 8(0.25 min)
= 2.3 min
1 Tp 1 1,3
Kc= = =−1 , 6
Kp (Θp+Tc ) -0 . 57 (0 .25+2. 3 ) °C/% and Ti=Tp=2,3 min

TRIAL 4: Aggressive PI
Aggressive Tc = the larger of 0.1·Tp or 0.8·Өp = larger of 0.1(2.3 min) or 0.8(0.25
min) = 0.23 min
1 Tp 1 2,3
Kc= = =−8 , 4
Kp (Θp+Tc ) -0. 57 (0 .25+0 .23 ) °C/% and Ti=Tp=2,3 min
The "step 1 data set" model parameters and the four inner secondary controllers
designed from this data are summarized in the upper half of the table below [1]:

Table 8.1. The "step 1 data set" model parameters

Inner secondary CO2 bump test: from 34.3%→39.3%→29.3%→34.3%
FOPDT CO2→PV2 model: Kp=-0.57°C/%, Tp=2,3 min, Θp= 0.25 min
Trial 1 Trial 2 Trial 3 Trial 4
Inner secondary P-only and PI controllers from above inner FOPDT model
Kc[=] %/°C Moderate P- Aggressive P- Moderate PI Aggressive PI
Ti[=] min only Kc=-0.53 only Kc=-13.3 Kc=-1.5,Ti=2.3 Kc=-8.4,Ti=2.3
Outer primary CO2=SP2 →PV1 models using above inner controllers
Kp[=]°C/% 0.7 0.82 0.90 0.93
Tp[=] min 0.61 0.43 2.2 0.50
Θp[=] min 0.63 0.48 0.82 0.62
 Outer primary PI controllers with moderate tuning using above FOPDT model
Kc[=] %/°C Moderate PI Moderate PI Moderate PI Moderate PI
Ti[=] min Kc=0.15,Ti=0.6 Kc=0.12,Ti=0.43 Kc=0.33,Ti=2.2 Kc=0.10,Ti=0.50

Outer Primary Controller

5) We normally would implement one inner secondary controller and test it for
acceptable performance. Here, we "accept" each of the four trial controllers and turn
our attention to the outer primary loop.
The four inner secondary controllers are thus implemented one after the other in
a series of studies. When in automatic mode, each literally becomes part of the overall
process. And because each is different, we must perform four separate bump tests and
compute four sets of FOPDT model parameters to describe the four different outer
primary (overall) dynamic process behaviors.
Recall that the output of the outer primary controller output, CO1, becomes the
set point of the inner secondary controller, SP2. Thus, bumping CO1 is the same as
bumping SP2 (i.e., CO1=SP2).
With each of the four inner secondary trial controllers in automatic, we choose to
bump CO1=SP2 from 73.4 oC→76.4 oC→70.4 oC→73.4 oC. We again use commercial
software to fit a FOPDT dynamic model to the CO1=SP2 →PV2 dynamic response data sets
as shown in the plots below [1]. The FOPDT model parameters (Kp, Tp, Өp) from each
bump test fit are summarized in the table above.

Fig. 8.14. Outer primary bump testsfor the four trial controllers

We find that industry practitioners, when designing a strategy for an application

as challenging as reactor temperature control, generally seek a moderate response
performance. Integral action will always be included to eliminate offset issues. Thus,
we pair each inner secondary trial controller with a moderately tuned outer primary PI
controller.
Following the identical procedure detailed in trial 3 of step 4 above, we
compute four sets of moderate PI controller tuning parameters (one for each inner
secondary controller). These are listed in the last row of the above table.

Compare Disturbance Rejection Performance

6) With both controllers in automatic, design and implementation of the cascade
is complete. The objective of this cascade is to minimize the disruption to primary
process variable PV1 when disturbance D changes.
The specific D of concern in this study is that the temperature of cooling liquid
entering the jacket, normally at 43 oC, is known to spike occasionally to 50 oC.
The lower trace in the plot below [1] shows disturbance steps (temperature
changes) from 43 oC up to 50 oC and back. There are four trials shown, one for each of
the inner secondary and outer primary controller pairs listed in the table above.
The middle portion of the plot shows the constantly moving inner secondary
SP2=C01 in gold and the ability of early warning PV2 to track this ever-changing set
point in black.
Recall that offset for early warning variable PV2 is not a concern in many
cascade implementations. Here, for example, PV2 is cooling liquid temperature and
cooling liquid is not a product destined for market. So our central focus is on how
control actions based on this early warning variable help us minimize disturbance
disruptions to PV1 and not on how precisely PV2 tracks set point.

Fig. 8.15. Disturbance rejection performance of reactor cascade

Our success is shown on the upper portion of the plot. The outer primary set
point, SP1 (in gold) remains constant throughout the study. Our interest is in the ability
of each of the cascade implementations to maintain reactor exit temperature PV1 at
SP1 in spite of the abrupt disturbance changes.
Some Observations
In general, a more successful (or "better") cascade performance is one where:
▪ there is a smaller maximum deviation from set point during the disturbance, and
▪ PV1 most rapidly returns to and settles out at set point after a disturbance.
 • Trials 2 and 4 both have aggressively tuned inner secondary controllers, and
these two implementations both have the smallest deviations from set point and settle
most rapidly back to SP. This supports the notion that inner secondary controllers
should energetically attack early warning PV2 disruptions for best cascade
performance.
• While an aggressively tuned inner secondary P-Only and PI controller (trials 2
and 4) performed with similar success, the moderately tuned inner secondary PI
controller (trial 3) displayed markedly degraded performance. This high sensitivity to
inner loop PI tuning strengthens the "use P-Only" conclusion made in step 3 of our
cascade implementation recipe.

Comparing Cascade to Single Loop

The central question is whether the extra effort associated with cascade control
provides sufficient payoff in the form of improved disturbance rejection performance.
To the left in the plot below [1] is the performance of our trial 2 cascade
implementation. The performance of an aggressively tuned single loop PI controller in
rejecting the same disturbance is shown to the right.

Fig. 8.16. Cascade vs single loop disturbance rejection performance

The cascade architecture reduces the maximum deviation from SP during the
disturbance from ±2 oC for the single loop controller down to ±0.5 oC for the cascade.
Settling time is shortened from about 10 minutes for the single loop controller down to
about 8 minutes for the cascade.
If the financial return from such improved performance is greater than the cost
to install and maintain the cascade, then choose cascade control.

Set Point Tracking Performance

While not our design objective, presented below is the set point tracking
performance of the four cascade implementations [1]:
 Fig. 8.17. Set point tracking performance of reactor cascade

Cascade control is best suited for improved disturbance rejection. As shown

above, its impact on set point tracking performance is minimal. While one might argue
that our "best" cascade design for disturbance rejection (trial 2) also provides the most
rapid SP tracking response, this same improvement can be obtained with more
aggressive tuning of a single loop PI controller.

8.2. Feed Forward with Feedback Trim For Improved Disturbance

Rejection
8.2.1. The Feed Forward Controller

The most popular architectures for improved disturbance rejection performance

are cascade control and the "feed forward with feedback trim" architecture introduced
below.
Like cascade, feed forward requires that additional instrumentation be
purchased, installed and maintained. Both architectures also require additional
engineering time for strategy design, implementation and tuning.
Cascade control will have a small impact on set point tracking performance
when compared to a traditional single-loop feedback design and this may or may not
be considered beneficial depending on the process application. The feed forward
element of a "feed forward with feedback trim" architecture does not impact set point
tracking performance in any way.

Feed Forward Involves a Measurement, Prediction and Action

Consider that a process change can occur in another part of our plant and an
identifiable series of events then leads that “distant” change to disturb or disrupt our
measured process variable, PV.
The traditional PID controller takes action only when the PV has been moved
from set point, SP, to produce a controller error, e(t) = SP – PV. Thus, disruption to
stable operation is already in progress before a feedback controller first begins to
respond. From this view, a feedback strategy simply starts too late and at best can only
work to minimize the upset as events unfold.
 In contrast, a feed forward controller measures the disturbance, D, while it is
still distant. As shown below, a feed forward element receives the measured D, uses it
to predict an impact on PV, and then computes preemptive control actions,
COfeedforward, that counteract the predicted impact as the disturbance arrives. The
goal is to maintain the process variable at set point (PV = SP) throughout the
disturbance event.

Fig. 8.18. Feed forward with feedback trim architecture

where:
CO = controller output signal
D = measured disturbance variable
e(t) = controller error, SP – PV
FCE = final control element (e.g., valve, variable speed pump or compressor)
PV = measured process variable
SP = set point
To appreciate the additional components associated with a feed forward
controller, we can compare the above to the previously discussed traditional feed back
control loop block diagram.

When to Consider Cascade Control

The cascade architecture requires that an "early warning" secondary measured
process variable, PV2, be identified that is inside (responds before) the primary
measured process variable, PV1. Essential elements for success include that:
▪ PV2 is measurable with a sensor.
▪ The same final control element (FCE) used to manipulate PV1 also
manipulates PV2.
▪ The same disturbances that are of concern for PV1 also disrupt PV2.
▪ PV2 responds before PV1 to disturbances of concern and to FCE
manipulations.
One benefit of a cascade architecture is that it uses two traditional controllers
from the PID family, so implementation is a familiar task that builds upon our existing
skills. Also, cascade control will help improve the rejection of any disturbance that
first disrupts the early warning variable, PV2, prior to impacting the primary process
variable, PV1.

When to Consider Feed Forward with Feedback Trim

Feed forward anticipates the impact of a measured disturbance on the PV and
deploys control actions to counteract the impending disruption in a timely fashion.
This can significantly improve disturbance rejection performance, but only for the
particular disturbance variable being measured.
Feed forward with feedback trim offers a solution for improved disturbance
rejection if no practical secondary process variable, PV2, can be established (i.e., a
process variable cannot be located that is measureable, provides an early warning of
impending disruption, and responds first to FCE manipulations).
Feed forward also has value if our concern is focused on one specific
disturbance that is responsible for repeated, costly disruptions to stable operation. To
provide benefit, the additional measurement must reveal process disturbances before
they arrive at our PV so we have time to compute and deploy preemptive control
actions.

The Feed-Forward-Only Controller

Pure feed-forward-only controllers are rarely found in industrial applications
where the process flow streams are composed of gases, liquids, powders, slurries or
melts. Nevertheless, we explore this idea using a thought experiment on the shell-and-
tube heat exchanger simulation detailed in a previous section and available for
exploration and study in commercial software.
The architecture of a feed-forward-only controller for the heat exchanger is
illustrated below [1]:

Fig. 8.19. The architecture of a feed-forward-only controller for the heat exchanger
 The PV to be controlled is the exit temperature on the tube side of the
exchanger. To regulate this exit temperature, the CO signal adjusts a valve to
manipulate the flow rate of cooling liquid on the shell side. A side stream of warm
liquid combines with the hot liquid entering the exchanger and acts as a measured
disturbance, D, to our process.
Because there is no feedback of a PV measurement in our controller
architecture, feed-forward-only presents the interesting notion of open loop control. As
such, it does not have a tendency to induce oscillations in the PV as can a poorly tuned
feedback controller.
If we could mathematically describe how each change in D impacts PV
(D→PV) and how each change in CO impacts PV (CO→PV), then we could develop a
math model that predicts what manipulations to make in CO to maintain PV at set
point whenever D changes.
But this would only be true if:
▪ we have perfect understanding of the D→PV and CO→PV dynamic
relationships,
▪ we can describe these perfect dynamic relationships mathematically,
▪ these relationships never change,
▪ there are no other unmeasured disturbances impacting PV, and
▪ set point, SP, is always held constant.
The reality, however, is that with only a single measured D, a predictive model
cannot account for many phenomena that impact the D → PV and CO → PV behavior.
These may include changes in:
the temperature and flow rate of the hot liquid feed that mixes with our warm
▪ disturbance stream on the tube side,
the temperature of the cooling liquid on the shell side,
▪
the ambient temperature surrounding the exchanger that drives heat loss to the
▪ environment,
the shell/tube heat transfer coefficient due to corrosion or fouling, and
▪
valve performance and capability due to wear and component failure.
▪

Since all of the above are unmeasured, a fixed or stationary model cannot
account for them when it computes control action predictions. Installing additional
sensors and enhancing the feed forward model to account for each would improve
performance but would lead to an expensive and complex architecture. And since there
are more potential disturbances and external influences then those listed above, that
still would not be sufficient.
This highlights that feed-forward-only control is problematic and should only
be considered in rare instances. One situation where it may offer value is if a PV
critical to process operation simply cannot be measured or inferred using currently
available technology. Feed-forward-only control, in spite of its weaknesses and
pitfalls, then offers some potential for improved operation.
 Feed Forward with Feedback Trim
The "feed forward with feedback trim" control architecture is the solution
widely employed in industrial practice. It balances the capability of a feed forward
element to take preemptive control actions for one particularly disruptive disturbance
while permitting a traditional feedback control loop to:
reject all other disturbances and external influences that are not measured,
▪
provide set point tracking capability, and
▪
correct for the inevitable simplifying approximations in the predictive model of the
▪ feed forward element that make preemptive disturbance rejection imperfect.
A feed forward with feedback trim control architecture for the heat exchanger
process is shown below [1]:

Fig. 8.20. A feed forward with feedback trim control architecture for the heat
exchanger process

To construct the architecture, a feedback controller is first implemented and

tested following our controller design and tuning recipe as if it were a stand-alone
entity. The feed forward controller is then designed based on our understanding of the
relationship between the D → PV and CO → PV variables. This is generally expressed
as a math function that can range in complexity from a simple multiplier to complex
differential equations.
With the architecture completed, the disturbance flow is measured and passed to
a feed forward element that is essentially a combination disturbance/process model.
The model uses changes in D to predict an impact on PV, and then computes control
actions, COfeedforward to compensate for the predicted impact.

Conceptual Feed Forward with Feedback Trim Diagram

 As shown in the first block diagram above, the COfeedforward control actions
are combined with COfeedback to create an overall control action, COtotal, to send to
the final control element (FCE).
To illustrate the control strategy in a more tangible fashion, we present the feed
forward with feedback trim architecture in a conceptual diagram below:

Fig. 8.21. A feed forward with feedback trim control architecture for the heat
exchanger process: X-a process variable (e.g. level, temperature, preassure, flow);
XT-sensor/transmitter; XC-controller from PID family; f(D)- mat. function;∑-
summing junction

The basis for the feed forward element math function, f(D) = ─ (GD/Gp) shown
in the diagram is discussed in detail in next section.
The more accurate the feed forward math function is in computing control
actions that will counteract changes in the measured disturbance in a timely fashion,
the less impact those disturbances will have on our measured process variable.
Practitioner's note: a potential application of feed forward control exists if
we hear an operator say something like, “Every time event A happens, process
variable X is upset. I can usually help the X controller by switching to manual
mode and moving the controller output.” If the variable associated with event A is
already being measured and logged in the process control system, sufficient data
is likely available to allow the implementation of a feed forward element to our
feedback controller.
Improved disturbance rejection performance comes at a price in terms of
process engineering time for model development and testing, and instrument
engineering time for control logic programming. Like all projects, such investment
decisions are made on the basis of cost and benefit.

8.2.2. Feed Forward Uses Models within the Controller Architecture

Both "feed forward with feedback trim" and cascade control can provide
improved disturbance rejection performance. They have different architectures,
however, and choosing between the two depends on our specific control objective and
the ability to obtain certain process measurements.

Feed Forward and Feedback Trim are Largely Independent

 As illustrated below, the feed forward with feedback trim architecture is
constructed by coupling a feed-forward-only controller to a traditional feedback
controller.
The feed forward controller seeks to reject the impact of one specific
disturbance, D, that is measured before it reaches our primary process variable, PV,
and starts its disruption to stable operation. Typically, this D is one that has been
identified as causing repeated and costly upsets, thus justifying the expense of both
installing a sensor to measure it, and developing and implementing the feed forward
computation element to counteract it (see Fig.8.1).
The feedback controller is designed and tuned like any stand-alone controller
from the PID family of algorithms. The only difference is that it must allow for its
controller output signal, COfeedback, to be combined with a feed forward controller
output signal, COfeedforward, to arrive at a total control action, COtotal.

Feed Forward Element Uses a Process and Disturbance Model

The diagram below shows that the function block element that computes the
feed forward controller output signal, COfeedforward, is constructed by combining a
process model and disturbance model.
The blocks circled with dotted lines below show where data is collected when
developing the process and disturbance models. The feed forward controller does not
include these circled blocks as separate elements in its architecture.

Fig.8.22. Feed forward element is constructed from models of process and disturbance

The process model (CO → PV) in the feed forward element describes or
predicts how each change in CO will impact PV. The disturbance model (D → PV)
describes or predicts how each change in D will impact PV.
In practice, these models can range from simple scaling multipliers (static feed
forward) through sophisticated differential equations (dynamic feed forward).
Sophisticated dynamic models can better describe actual process and disturbance
behaviors, often resulting in improved disturbance rejection performance. Such models
can also be challenging to derive and implement, increasing the time and expense of a
project.
 Dynamic Feed Forward Based on the FOPDT Model
We first develop a general feed forward element using dynamic models
(differential equations). Later, we will explore how we can simplify this general
construction into a static feed forward element. Static feed forward is widely employed
in industrial practice, in part because it can be implemented with an ordinary
multiplying relay that scales the disturbance signal.
A dynamic feed forward element accounts for the "how far" gain, the "how
fast" time constant and the "how much delay" dead time behavior of both the process
(CO → PV) and disturbance (D → PV) relationships.
The simplest differential equation that describes such "how far, how fast, and
with how much delay" behavior for either the process or disturbance dynamics is the
familiar first order plus dead time (FOPDT) model.
● The CO → PV Process Model
Describing the CO → PV process behavior with a FOPDT model is not a new
challenge. For example, we presented all details as we developed the FOPDT dynamic
CO → PV model for the gravity drained tanks process from step test data as:
dPV(t )
1.4 +PV =0. 09 . CO ( t−0 .5 )
dt
Which matches the general FOPDT (first order plus dead time) dynamic model
form:
dPV(t )
Tp +PV =KpCO ( t−Θp )
dt
where for a change in CO, the FOPDT model parameters are:
▪ Kp = process gain (the direction and how far PV will travel)
▪ Tp = process time constant (how fast PV moves after it begins its response)
▪ Өp = process dead time (how much delay before PV first begins to respond)
This equation describes how each change in CO causes PV to respond (CO →
PV) as time, t, passes. Our past modeling experience also includes developing and
documenting FOPDT CO → PV models for the heat exchanger and jacketed reactor
processes.

● The D → PV Disturbance Mode

The procedure used to develop the FOPDT (first order plus dead time) process
models referenced above can be used in an identical fashion to develop a dynamic D
→ PV disturbance model. While we do not show the graphical calculations at this
point, consider the plot below from the gravity drained tanks process [1].
 Fig. 8.23. Disturbance step with constantCO reveals D → PV dynamic behavior
Instead of analyzing a plot where a CO step forces a PV response while D
remains constant, here we would analyze a D step forcing a PV response while CO
remains constant.
We presume that an analogous graphical modeling procedure can be followed
to determine the "how far, how fast, and with how much delay" dynamic D → PV
disturbance model:
dPV(t )
Tp +PV =K D . D ( t−Θp )
dt
where for a step change in D:
▪ KD = disturbance gain (the direction and how far PV will travel)
▪ TD = disturbance time constant (how fast PV moves after it begins its
response)
▪ ӨD = disturbance dead time (how much delay before PV first begins to
respond)
Dynamic Feed Forward as a Thought Experiment
A feed forward element typically performs a model computation every sample
time, T, to address any changes in measured disturbance, D. To help us visualize
events, we discuss this as if it occurs as a two step "prediction and corrective action"
procedure for a single disturbance:
1. The D → PV disturbance model receives a change in the measured value of D and
predicts an open-loop or uncontrolled “impact profile” on PV. This includes a
prediction of how much delay will pass before the disruption first arrives at PV,
the direction PV will travel for this particular D once it begins to respond, and how
fast and how far PV will travel before it settles out at a predicted new steady state.
2. The CO → PV process model then uses this PV impact profile to back-calculate a
series of corrective control actions, COfeedforward. These are CO moves sent to
the final control element (FCE) to cause an "equal but opposite" response in PV
such that it remains at set point, SP, throughout the event. Thus, the CO model
seeks to exactly counteract the disruption profile predicted in step 1. The first CO
actions are delayed as needed so they meet D upon arrival at PV. A series of CO
actions are then deployed to counteract the predicted disruption over the life of the
event.
 Even sophisticated dynamic models are too simple to precisely describe the
behavior of real processes. So although a feed forward element can dramatically
reduce the impact of a disturbance on our PV, it will not provide a perfect "prediction
and corrective action" disturbance rejection.
To account for model inaccuracies, the feed forward signal is combined with
traditional feedback control action, COfeedback, to create a total controller output,
COtotal. Whether it be a P-Only, PI, PID or PID w/ CO Filter algorithm, the feedback
controller plays the important role of:
minimizing the impact of disturbance variables other than D that can disrupt the PV,
▪
providing set point tracking capability to the overall strategy, and
▪
correcting for the simplifying approximations used in constructing the feed forward
▪ computation element that ultimately makes it imperfect in its actions.

The Sign of COfeedforward Requires Careful Attention

Notice in the block diagram above that COfeedforward is added as:
COtotal = COfeedback + COfeedforward
We write the equation this way because it is consistent with typical vendor
documentation and standard piping/process & instrumentation diagrams (P&IDs).
The "plus" sign in the equation above requires our careful attention. To
understand the caution, consider a case where the D → PV disturbance model predicts
that D will cause the PV to move up in a certain fashion or pattern over a period of
time. According to our thought experiment above, the CO → PV process model must
compute feed forward CO actions that cause the PV to move down in an identical
pattern.
But the sign of both the process gain, Kp, and disturbance gain, K D, together
determine whether we need to send an increasing or decreasing signal to the FCE to
compensate for a particular D. If Kp and K D are both positive or both negative, for
example, then as a disturbance D moves up, the COfeedforward signal must move
down to compensate. If Kp and K D are of opposite sign, then D and COfeedforward
move in the same direction to counteract each other.
We show a standard "plus" sign in the equation above. But the computed feed
forward signal, COfeedforward, will be positive or negative depending on the signs of
the process and disturbance gains as just described. This ensures that the impact of the
disturbance and the compensation from the feed forward element move in opposite
directions to provide improved disturbance rejection performance.

Dynamic Feed Forward in Math

Suppose we define a generic process model, Gp, and generic disturbance model,
GD, as:
Gp = generic CO → PV process model (describing how a CO change will
impact PV)
GD = generic D → PV disturbance model (describing how a D change will
impact PV)
 We allow Gp and GD to have forms that can range from simple to the
sophisticated.
For example, they can both be pure gain values Kp and K D and nothing more.
They can be full FOPDT differential equations that include Kp, Tp and Өp, and KD,
TD and ӨD. One or the other (or both) can be non-self regulating (integrating), or
perhaps self regulating but second or third order.
Leaving the exact form of the models undefined for now, we develop our feed
forward element with the following steps:
1) Our generic CO → PV process model, Gp, allows us to compute a PV
response to changes in CO as:
PV = Gp·CO
With the generic model approach, we can rearrange the above to compute
controller output actions that would reproduce a known or specified PV as:
CO = (1/Gp)·PV
2) Our generic D → PV disturbance model, GD, lets us compute a PV response
to changes in D as:
PV = GD·D
3) Following the logic in the above thought experiment, we use the D → PV
model of step 2 to predict an impact profile on PV for any measured disturbance D:
PVimpact = GD·D
4) We then use our rearranged equation of step 1 to back-calculate a series of
corrective feed forward control signals that will move PV in a pattern that is opposite
(and thus negative in sign) to the predicted PV impact profile from Step 3:
COfeedforward = ─ (1/Gp)·PVimpact
5) We finish by substituting the "PVimpact = G D·D" equation of step 3 into the
COfeedforward equation of step 4:
COfeedforward = ─ (1/Gp)·(GD·D)
and rearrange to arrive at our final feed forward computational element
composed of a disturbance model divided by a process model:
COfeedforward = ─ (GD/Gp)·D
Note: Above is a math argument that we hope seems reasonable and easy to
follow.
But please be aware that for such manipulations to be proper, all variables
and equations must first be mapped into the Laplace domain using Laplace
transforms. The ease with which complex equations can be manipulated in the
Laplace domain is a major reason control theorists use it for their derivations.
So, to be mathematically correct, we must first cast all variables and
models into the Laplace domain as:
PV(s) = Gp(s)·CO(s) when the disturbance is constant
and
PV(s) = GD(s)·D(s) when the controller output signal is constant
where the Laplace domain models Gp(s) and G D(s) are called transfer
functions.
At the end of our derivation, our final feed forward computational element
should be expressed as:
COfeedforward(s) = ─ [GD(s)/Gp(s)]·D(s)
 Thus, while we had omitted important details, our feed forward equation is
indeed correct and we will use it going forward. We will continue to downplay the
complexities of the math for now as we focus on methods of use to industry
practitioners.

Conceptual Feed Forward with Feedback Trim Diagram

We now have the basis for why we express the feed forward element math
function, f(D) = ─ (GD/Gp) as shown in our generalize feed forward with feedback
trim conceptual diagram in Fig. 8.21.

Implementation and Testing of Feed Forward with Feedback Trim

We next explore the widely used and surprisingly powerful static feed forward
controller. We will discover the ease with which we can develop such an architecture,
and also explore some of the limitations of this simplified approach.

8.2.3. Static Feed Forward and Disturbance Rejection in the Jacketed

Reactor
As discussed in previous sections, the purpose of the feed forward controller of
the feed forward with feedback trim architecture is to reduce the impact of one specific
disturbance, D, on our primary process variable, PV. An additional sensor must be
located upstream in our process so we have a disturbance measurement that provides
warning of impending disruption. The feed forward element uses this D measurement
signal to compute and implement corrective control actions so the disturbance has
minimal impact on stable operation.
Here we build on the mathematical foundation of this previous material as we
explore the popular and surprisingly powerful static feed forward computational
element for this disturbance rejection architecture.

Static Feed Forward Uses the Simplest Model Form

If we define a generic process model, Gp, and generic disturbance model, GD,
as:
Gp = generic CO → PV process model (describing how a CO change will
impact PV)
GD = generic D → PV disturbance model (describing how a D change will
impact PV)
then we can show details to derive a general feed forward computational
element as a ratio of the disturbance model divided by the process model:
COfeedforward = − (GD/Gp)·D
Models Gp and GD can range from the simple to the sophisticated. With static
feed forward, we limit Gp and GD to their constant "which direction and how far" gain
values:
Gp = Kp (the CO → PV process gain)
GD = KD (the D → PV disturbance gain)
And the static feed forward element is thus a simple gain ratio multiplier:
COfeedforward = − (KD/Kp)·D (static feed forward element)
 The static feed forward controller does not consider how the controller output to
process variable (CO → PV) dynamic behavior differs from the disturbance to process
variable (D → PV) dynamic behavior.
▪ We do not account for the size of the process time constant, Tp, relative to the
disturbance time constant, TD. As a consequence, we cannot compute and deploy a
series of corrective control actions over time to match how fast the disturbance event
is causing the PV to move up or down.
▪ We do not consider the size of the process dead time, Өp, relative to the disturbance
dead time, ӨD. Thus, we cannot delay the implementation of corrective actions to
coordinate their arrival with the start of the disturbance disruption on PV.
For processes where the CO → PV dynamic behavior is very similar to the D →
PV dynamic behavior, like many liquid level processes for example, static feed
forward will perform virtually the same as a fully dynamic feed forward controller in
rejecting our measured disturbance.
Visualizing the action of this static feed forward element as a two step
"prediction and corrective action" procedure for a single disturbance:
1. The D → PV disturbance gain, KD, receives a change in D and predicts the total
final impact on PV. The computation can only account for information contained
in KD, which includes the direction and how far PV will ultimately travel in
response to the measured D before it settles out at a new steady state.
2. The CO → PV process gain, Kp, then uses this disturbance impact prediction of
"which direction and how far" to back-calculate one CO move as a corrective
control action, COfeedforward. This COfeedforward move is sent immediately to
the final control element (FCE) to cause an "equal but opposite" response in PV.

Limited in Capability but (Reasonably) Easy to Implement

The static feed forward element makes one complete and final corrective action
for every measured change in D. It does not delay the feed forward signal so it will
meet the D impact when it arrives at PV. It does not compute and deploy a series of
CO actions to try and counteract a predicted disruption pattern over an event life.
Even with this limited performance capability, the benefit of the static form that
makes it popular with industry practitioners is that it is reasonably straightforward to
implement in a production environment.
As shown below [1], we can construct a static feed forward element with:
▪ a sensor/transmitter to measure disturbance D
▪ a scaling relay that multiplies signal D by our static feed forward ratio, (−
KD/Kp)
▪ a summing junction that adds COfeedforward to COfeedback to produce
COtotal
 Fig. 8.24. Static feed forward with feedback trim conceptual diagram: X-a process
variable (e.g. level, temperature, preassure, flow); XT-sensor/transmitter; XC-
controller from PID family; XY-scaling relaj with bias; ∑-summing junction

COfeedforward is Normally Zero

An important implementation issue is that COfeedforward should equal zero
when D is at its design level of operation (DLO) value. Thus, the D used in our
calculations is actually the disturbance signal from the sensor/transmitter (Dmeasured)
that has been shifted or biased by the design level of operation disturbance value
(DDLO), or:
D = Dmeasured − DDLO
With this definition, both D and COfeedforward will be zero when the
disturbance is at its normal or expected value. Such a biasing capability is included
with most all commercial scaling relay function blocks.

Static Feed Forward and the Jacketed Reactor Process

We have previously explored the modes of operation and dynamic CO −› PV
behavior of the jacketed stirred reactor process. We also have established the
performance of a single loop PI controller, a PID with CO Filter controller and a
cascade control implementation when our control objective is to minimize the impact
of a disturbance caused by a change in the temperature of the liquid entering the
cooling jacket.
Here we explore the design, implementation and performance of a static feed
forward with feedback trim architecture for this same disturbance rejection objective.

Limitations of the Single Loop Architecture

The control objective is to maintain the reactor exit stream temperature (PV) at
set point (SP) in spite of changes in the temperature of cooling liquid entering the
jacket (D) by adjusting controller output (CO) signals to the cooling liquid flow valve.
The nature of this process and the performance limitations of a single loop
architecture as shown in Fig. 8.9 have been detailed section 8.1.3.

A Feed Forward with Feedback Trim Reactor Architecture

Below is the jacketed stirred reactor process with a feed forward with feedback
trim controller architecture [1].
 Fig. 8.25. Jacketed stirred reactor with a feed forward with feedback trim mode

The loop architecture from this commercial software simulation shows that D is
measured, scaled and transmitted as COfeedforward to the controller. There it is
combined with the traditional feedback signal to produce the COtotal sent to the
cooling jacket flow valve. This is a simplified representation of the same feed forward
with feedback trim conceptual diagram shown earlier in this topic.

Design Level of Operation (DLO)

The details and discussion of the DLO used in our previous disturbance
rejection studies for the jacketed stirred reactor are presented in a previous topic and
are summarized:
▪ Design PV and SP = 90 oC with approval for brief dynamic testing of ±2 oC
▪ Design D = 43 oC with occasional spikes up to 50 oC
We note that D moves between 43 oC and 50 oC. We seek a single DLO value
that lets us conveniently compare results from two different design methods explored
below.
We choose here a DDLO as the average value of (43+50)/2 = 46.5 oC and
acknowledge that other choices (such as simply using 43 oC) are reasonable. As long
as we are consistent in our methodology, the conclusions we draw when comparing the
two methods will remain unchanged.
When D = 46.5 oC and CO = 40%, then our measured process variable settles at
the design value of PV = 90 oC. This relationship between the three variables explains
the DLO values indicated on the plots that follow.

Design Method 1: Compute KD/Kp From Historic Data

Below [1] is a trend from our data historian showing approximately three hours
of operation from the jacketed reactor process under PI control. No feed forward
controller is active. The set point (SP) is constant and a number of disturbance events
force the PV from SP. All variables are near our DLO as described above.
 Fig. 8.26. KD/Kp from operating data while under feedback control

If we recall the definition that Kp = ΔPV/ΔCO and KD = ΔPV/ΔD, then for our
static feed forward design:

COfeedforward = − (KD/Kp)·D
= − [(ΔPV/ΔD)/(ΔPV/ΔCO)]·D
= − [(ΔCO/ΔD)]·D

With this last equation, our design challenge is reduced to finding a disturbance
change that lasts long enough for the controller output response to settle. If this event
occurs reasonably close to our DLO, then we can directly compute our gain ratio feed
forward element by measuring the disturbance and controller output changes from a
plot.
▪ About the Feedback Controller
The plot shows disturbance rejection performance when the process is using a
PI controller tuned for an aggressive response action. The details of the design, tuning
and testing of this process and controller combination are presented in a previous
sections.
Note that with this "measure from a plot" approach of Method 1, the process
can be controlled by any algorithm from the PID family, though integral action must
be included to return the PV to SP (eliminate offset) after a disturbance. Also, our
feedback controller tuning can range from conservative (sluggish) through an
aggressive (active) response without affecting the applicability of the method.
Our interest is limited to finding a ΔD disturbance event with a corresponding
ΔCO controller output signal response that lasts long enough for the PV to be returned
to SP. Then as shown above, the ΔD and ΔCO relationship can be measured directly
from the plot data.
▪ Accounting for Negative Feedback
 If we are using automatic mode (closed loop) data as shown in the plot above,
we must account for the negative feedback of our controller in our calculations. A
controller always takes action that moves the CO signal in a direction that counteracts
the developing controller error. Thus, when using automatic mode (closed loop) data
as above, we must consider that a negative sign has been introduced into the signal
relationship.
On the plot above, we have labeled a ΔD disturbance change with
corresponding ΔCO controller output signal response. We introduce the sign change
from negative feedback of our controller and compute [1]:

COfeedforward = − [(ΔCO/ΔD)]·D·(−1 for negative feedback)

= [(14%)/(7 oC)]·D
= [2 %/oC]·D

Design Method 2: Perform Two Independent Bump Tests

To validate that a feed forward gain ratio of 2 %/ oC is a reasonable number as
determined from automatic mode (closed loop) data, here we perform two independent
step tests, compute individual values for KD and Kp, and then compare the ratio results
to Method 1.
This approach is largely academic because the challenges of steadying a real
process and then stepping individual parameters in such a perfect fashion is unrealistic
in the chaotic world of most production environments. This exercise holds value,
however, because it provides an alternate route that confirms the results presented in
Method 1.
We follow the established procedure for computing a process gain, Kp, from a
manual mode (open loop) step test response plot. That is, we set our disturbance
parameter at DDLO, set the controller output at a constant CO value and wait until the
PV is steady. We then step CO to force a PV response that is centered around our
DLO.
Such a step response plot is shown below [1] for the jacketed stirred reactor.
We measure and compute Kp = ΔPV/ΔCO = − 0.4 oC/% as indicated on the plot.

Fig. 8.27. Kp from Open loop process step response at the DLO
 We repeat the procedure to compute a disturbance gain, K D, from an open loop
step response plot. Here, we set our CO signal at the DLO value of 40%, set the
disturbance parameter at a constant D value and wait until the PV is steady. We then
step D to force a PV response that is again centered around our DLO.
Such a disturbance step response plot is shown below [1]. We measure and
compute KD = ΔPV/ΔD = 0.8 oC/oC as labeled on the plot.

Fig. 8.28. KD from Open loop process step response at the DLO

With values for Kp and KD, we compute our gain ratio feed forward multiplier.
Since we are in manual mode (open loop), we need not account for any sign change
due to negative feedback in our calculation [1].

COfeedforward = − (KD/Kp)·D
= − [(0.8 oC/oC)/(− 0.4 oC/%)]·D
= [2 %/oC]·D

Thus, with careful testing using a consistent and repeatable commercial process
simulation, we observe that the practical approach of Method 1 provides the same
results as the academic approach of Method 2.

Implement and Test

The all-important question we now consider is whether the extra effort
associated with designing and implementing a "static feed forward with feedback trim"
architecture provides sufficient payoff in the form of improved disturbance rejection
performance.
To the left in the plot below [1] is the performance of a dependent, ideal PI
controller with aggressive tuning values for controller gain Kc = − 3.1 %/ oC and reset
time Ti = 2.2 min as detailed in this section.
 Fig. 8.29. PI vs “PI static feed forward”in Jacketed stirred reactor

To the right in the plot above is the disturbance rejection performance of our
static feed forward with feedback trim architecture. The feed forward gain ratio
multiplier used is the 2 %/oC as determined by two different methods described earlier
in this topic. The feedback controller remains the aggressively tuned PI algorithm as
described above.
The static feed forward controller makes one complete preemptive corrective
CO action whenever a change in D is detected as noted in the plot above. There is no
delay of the feed forward signal based on relative dead time considerations, and there
is no series of CO actions computed and deployed based on relative time constant
considerations.
Nevertheless, the static feed forward controller is able to reduce the maximum
deviation from SP during a disturbance event to half of its original value. The settling
time is also reduced, though less dramatically. Like any control project, the operations
staff must determine if this represents a sufficient payback for the effort and expenses
required.
Practitioner's note: Our decision to add feed forward to a feedback control
loop is driven by the character of the disturbance and its effect on our PV. If the
controller can react more quickly than the D can change, feed forward is not
likely to significantly improve control. However, if the disturbance changes
rapidly and fairly often, feed forward control can be a powerful tool to stabilize
our process.

No Impact on Set Point Tracking Performance

While not our design objective, presented below is the set point tracking
performance of the single loop PI controller compared to that of the static feed forward
with feedback trim architecture [1]. The same aggressive PI tuning values used above
are maintained for this study.
 Fig. 8.30. Set point tracking performance unaffected feed forward

Feed forward with feedback trim is designed for the improved rejection of one
measured disturbance. As shown above, a feed forward controller has no impact on set
point tracking performance when the disturbance is constant. This makes sense since
the computed COfeedforward signal does not change unless D changes. Indeed, with
no change in the measured disturbance, both architectures provide identical
performance.

References
1. Practical Process Control. Proven Methods and Best Practices for Automatic PID Control.
http://www.controlguru.com/pages/table.html
2. Coleman Brosilow, Babu Joseph. Techniques of model-based control. Prentice Hall,2002.
3. Shamsuzzoha, M., Lee, M. IMC-PID controller design for improved disturbance rejection,
Ind. Eng. Chem. Res., 46, No. 7, 2007, pp. 2077-2091.
4. Tutorial on IMCTUNE software. http://www.bgu.ac.il/chem_eng/pages/Courses/