Like the P-Only controller, the Proportional-Integral (PI) algorithm computes and transmits a controller output (CO) signal every sample time, T, to the final control element (e.g., valve, variable speed pump). The computed CO from the PI algorithm is influenced by the controller tuning parameters and the controller error, e(t).
PI controllers have two tuning parameters to adjust. While this makes them more challenging to tune than a P-Only controller, they are not as complex as the three parameter PID controller.
Integral action enables PI controllers to eliminate offset, a major weakness of a P-only controller. Thus, PI controllers provide a balance of complexity and capability that makes them by far the most widely used algorithm in process control applications.
The PI Algorithm
While different vendors cast what is essentially the same algorithm in different forms, here we explore what is variously described as the dependent, ideal, continuous, position form:
Where:
CO = controller output signal (the wire out)
CObias = controller bias or null value; set by bumpless transfer as explained below
e(t) = current controller error, defined as SP - PV
SP = set point
PV = measured process variable (the wire in)
Kc = controller gain, a tuning parameter
Ti = reset time, a tuning parameter
The first two terms to the right of the equal sign are identical to the P-Only controller referenced at the top of this article.
The integral mode of the controller is the last term of the equation. Its function is to integrate or continually sum the controller error, e(t), over time.
Some things we should know about the reset time tuning parameter, Ti:
▪ It provides a separate weight to the integral term so the influence of integral action can be independently adjusted.
▪ It is in the denominator so smaller values provide a larger weight to (i.e. increase the influence of) the integral term.
▪ It has units of time so it is always positive.
Function of the Proportional Term
As with the P-Only controller, the proportional term of the PI controller, Kc·e(t), adds or subtracts from CObias based on the size of controller error e(t) at each time t.
As e(t) grows or shrinks, the amount added to CObias grows or shrinks immediately and proportionately. The past history and current trajectory of the controller error have no influence on the proportional term computation.
The plot below illustrates this idea for a set point response. The error used in the proportional calculation is shown on the plot:
▪ At time t = 25 min, e(25) = 60-56 = 4
▪ At time t = 40 min, e(40) = 60-62 = -2
Recalling that controller error e(t) = SP - PV, rather than viewing PV and SP as separate traces as we do above, we can compute and plot e(t) at each point in time t.
Below is the identical data to that above only it is recast as a plot of e(t) itself. Notice that in the plot above, PV = SP = 50 for the first 10 min, while in the error plot below, e(t) = 0 for the same time period.
This plot is useful as it helps us visualize how controller error continually changes size and sign as time passes.
Function of the Integral Term
While the proportional term considers the current size of e(t) only at the time of the controller calculation, the integral term considers the history of the error, or how long and how far the measured process variable has been from the set point over time.
Integration is a continual summing. Integration of error over time means that we sum up the complete controller error history up to the present time, starting from when the controller was first switched to automatic.
Controller error is e(t) = SP - PV. In the plot below, the integral sum of error is computed as the shaded areas between the SP and PV traces.
Each box in the plot has an integral sum of 20 (2 high by 10 wide). If we count the number of boxes (including fractions of boxes) contained in the shaded areas, we can compute the integral sum of error.
So when the PV first crosses the set point at around t = 32, the integral sum has grown to about 135. We write the integral term of the PI controller as:
Since it is controller error that drives the calculation, we get a direct view the situation from a controller error plot as shown below:
Note that the integral of each shaded portion has the same sign as the error. Since the integral sum starts accumulating when the controller is first put in automatic, the total integral sum grows as long as e(t) is positive and shrinks when it is negative.
At time t = 60 min on the plots, the integral sum is 135 - 34 = 101. The response is largely settled out at t = 90 min, and the integral sum is then 135 - 34 7 = 108.
Integral Action Eliminates Offset
The previous sentence makes a subtle yet very important observation. The response is largely complete at time t = 90 min, yet the integral sum of all error is not zero.
In this example, the integral sum has a final or residual value of 108. It is this residual value that enables integral action of the PI controller to eliminate offset.
As discussed in a previous article, most processes under P-only control experience offset during normal operation. Offset is a sustained value for controller error (i.e., PV does not equal SP at steady state).
We recognize from the P-Only controller:
that CO will always equal CObias unless we add or subtract something from it.
The only way we have something to add or subtract from CObias in the P-Only equation above is if e(t) is not zero. It e(t) is not steady at zero, then PV does not equal SP and we have offset.
However, with the PI controller:
we now know that the integral sum of error can have a final or residual value after a response is complete. This is important because it means that e(t) can be zero, yet we can still have something to add or subtract from CObias to form the final controller output, CO.
So as long as there is any error (as long as e(t) is not zero), the integral term will grow or shrink in size to impact CO. The changes in CO will only cease when PV equals SP (when e(t) = 0) for a sustained period of time.
At that point, the integral term can have a residual value as just discussed. This residual value from integration, when added to CObias, essentially creates a new overall bias value that corresponds to the new level of operation.
In effect, integral action continually resets the bias value to eliminate offset as operating level changes.
Challenges of PI Control
There are challenges in employing the PI algorithm:
▪ The two tuning parameters interact with each other and their influence must be balanced by the designer.
▪ The integral term tends to increase the oscillatory or rolling behavior of the process response.
Because the two tuning parameters interact with each other, it can be challenging to arrive at "best" tuning values. The value and importance of our design and tuning recipe increases as the controller becomes more complex.
Initializing the Controller for Bumpless Transfer
When we switch any controller from manual mode to automatic (from open loop to closed loop), we want the result to be uneventful. That is, we do not want the switchover to cause abrupt control actions that impact or disrupt our process
We achieve this desired outcome at switchover by initializing the controller integral sum of error to zero. Also, the set point and controller bias value are initialized by setting:
▪ SP equal to the current PV
▪ CObias equal to the current CO
With the integral sum of error set to zero, there is nothing to add or subtract from CObias that would cause a sudden change in the current controller output. With the set point equal to the measured process variable, there is no error to drive a change in our CO. And with the controller bias set to our current CO value, we are prepared by default to maintain current operation.
Thus, when we switch from manual mode to automatic, we have "bumpless transfer" with no surprises. This is a result everyone appreciates.
Reset Time Versus Reset Rate
Different vendors cast their control algorithms in slightly different forms. Some use proportional band rather than controller gain. Also, some use reset rate, Tr, instead of reset time. These are simply the inverse of each other:
Tr = 1/Ti
No matter how the tuning parameters are expressed, the PI algorithms are all equally capable.
But it is critical to know your manufacturer before you start tuning your controller because parameter values must be matched to your particular algorithm form. Commercial software for controller design and tuning will automatically address this problem for you.
Implementing a PI controller
We explore PI controller design, tuning and implementation on the heat exchanger in this article and the gravity drained tanks in this article.
A controller seeks to maintain the measured process variable (PV) at set point (SP) in spite of unplanned and unmeasured disturbances. Since e(t) = SP - PV, this is equivalent to saying that a controller seeks to maintain controller error, e(t), equal to zero.
A controller repeats a measurement-computation-action procedure at every loop sample time, T. Starting at the far right of the control loop block diagram above:
- A sensor measures a temperature, pressure, concentration or other property of interest from our process.
- The sensor signal is transmitted to the controller. The pathway from sensor to controller might include: a transducer, an amplifier, a scaling element, quantization, a signal filter, a multiplexer, and other operations that can add delay and change the size, sign, and/or units of the measurement.
- After all electronic and digital operations, the result terminates at our controller as the "wire in" measured process variable (PV) signal.
- This "wire in" process variable is subtracted from set point in the controller to compute error, e(t) = SP - PV, which is then used in an algorithm (examples here and here) to compute a controller output (CO) signal.
- The computed CO signal is transmitted on the "wire out" from the controller on a path to the final control element (FCE).
- Similar to the measurement path, the signal from the controller to FCE might include filtering, scaling, linearization, amplification, multiplexing, transducing and other operations that can add delay and change the size, sign, and/or units of our original CO signal.
- After any electronic and digital operations, the signal reaches the valve, pump, compressor or other FCE, causing a change in the manipulated variable (a liquid or gas stream flow rate, for example).
- The change in the manipulated variable causes a change in our temperature, pressure, concentration or other process property of interest, all with the goal of making e(t) = 0.
The steps of the controller design and tuning recipe include: bumping the CO signal to generate CO to PV dynamic process data, approximating this test data with a first order plus dead time (FOPDT) model, and then using the model parameters in rules and correlations to complete the controller design and tuning.
The recipe provides a proven basis for controller design and tuning that avoids wasteful and expensive trial-and-error experiments. But for success, controller design and tuning must be based on process data as the controller sees it.
The controller only knows about the state of the process from the PV signal arriving on the "wire in" after all operations in the signal path from the sensor. It can only impact the state of the process with the CO signal it sends on the "wire out" before any such operations are made in the path to the final control element.
As indicated in the diagram at the top of this article, the proper signals that describe our complete "process" from the controller's view is the "wire out" CO and the "wire in" PV.
Complete the Circuit
Sometimes we find ourselves unable to proceed with an orderly controller design and tuning. Perhaps our controller interface does not make it convenient to directly record process data. Maybe we find a vendor's documentation to be so poorly written as to be all but worthless. There are a host of complications that can hinder progress.
Being resourceful, we may be tempted to move the project forward by using portable instrumentation. It seems reasonable to collect, say, temperature in a vessel during a bump test by inserting a spare thermocouple into the liquid. Or maybe we feel we can be more precise by standing right at the valve and using a portable signal generator to bump the process rather than doing so from a remote control panel.
As shown below, such an approach cuts out or short circuits the complete control loop pathway. External or portable instrumentation will not be recording the actual CO or PV as the controller sees it, and the data will not be appropriate for controller design or tuning.
Every Item Counts
The illustration above is extreme in that it shows many items that are not included in the control loop. But please recognize that it can be problematic to leave out even a single step in the complete signal pathway.
A simple scaling element that multiplies the signal by a constant value, for example, may seem reasonably unimportant to the overall loop dynamics. But this alone can change the size and even the sign of Kp, thus having dramatic impact on best tuning and final controller performance.
From a controller's view, the complete loop goes from "wire out" to "wire in" as shown below.
Every item in the loop counts. Always use the complete CO to PV data for process control analysis, design and tuning.
Pay Attention to Units
As detailed in this related article, signals can appear in a control loop in electronic units (e.g., volts, mA), in engineering units (e.g. oC, Lb/hr), as percent of scale (e.g., 0% to 100%), or as discrete or digital counts (e.g. 0 to 4095 counts).
It is critical that we remain aware of the units of a signal when working with a particular instrument or device. All values entered and computations performed must be consistent with the form of the data at that point in the loop.
Beyond the theory and methods discussed in this e-book, such "accounting confusion" can be one of the biggest challenges for the process control practitioner.
Processes with streams comprised of gases, liquids, powders, slurries and melts tend to exhibit variations in behavior as operating level changes. This, in fact, is the very nature of a nonlinear process. For this reason, our recipe for controller design and tuning begins by specifying our design level of operation.
Controller Design and Tuning Recipe:
- Establish the design level of operation (DLO), which is the normal or expected values for set point and major disturbances.
- Bump the process and collect controller output (CO) to process variable (PV) dynamic process data around this design level.
- Approximate the process data behavior with a first order plus dead time (FOPDT) dynamic model.
- Use the model parameters from step 3 in rules and correlations to complete the controller design and tuning.
The dynamic behavior of the gravity drained tanks process is reasonably intuitive. Increase or decrease the inlet flow rate into the upper tank and the liquid level in the lower tank rises or falls in response.
One challenge this process presents is that its dynamic behavior is nonlinear. That is, the process gain, Kp; time constant, Tp; and/or dead time, Өp; changes as operating level changes. This is evident in the open loop response plot below.
As shown above, the CO is stepped in equal increments, yet the response behavior of the PV changes as the level in the tank rises. The consequence of nonlinear behavior is that a controller designed to give desirable performance at one operating level may not give desirable performance at another level.
Nonlinear Behavior of the Heat Exchanger
Nonlinear process behavior has important implications for controller design and tuning. Consider, for example, our heat exchanger process under PI control.
When tuned for a moderate response as shown in the first set point step from 140 °C to 155 °C in the plot below, the process variable (PV) responds in a manner consistent with our design goals. That is, the PV moves to the new set point (SP) reasonably quickly but does not overshoot the set point.
The consequence of a nonlinear process character is apparent as the set point steps continue to higher temperatures. In the third set point step from 170 °C to 185 °C, the same controller that had given a desired moderate performance now produces a PV response with a clear overshoot and some oscillation.
Such a change in performance with operating level may be tolerable in some applications and unacceptable in others. As we discuss in this article, "best" performance is something we judge for ourselves based on the goals of production, capabilities of the process, impact on down stream units and the desires of management
Nonlinear behavior should not catch us by surprise. It is something we can know about our process in advance. And this is why we should choose a design level of operation as a first step in our controller design and tuning procedure.
Step 1: Establish the Design Level of Operation (DLO)
Because, as shown in the examples above, processes have process gain, Kp; time constant, Tp; and/or dead time, Өp values that change as operating level changes, and these FOPDT model parameter values are used to complete the controller design and tuning procedure, it is important that dynamic process test data be collected at a pre-determined level of operation.
Defining this design level of operation (DLO) includes specifying where we expect the set point (SP) and measured process variable (PV) to be during normal operation, and the range of values the SP and PV might typically assume. This way we know where to explore the dynamic process behavior during controller design and tuning.
The DLO also considers our major disturbances (D). We should know the normal or typical values for our major disturbances. And we should be reasonably confident that the disturbances are quiet so we may proceed with a bump test to generate and record dynamic process data.
Step 2. Collect Dynamic Process Data Around the DLO
The next step in our recipe is to collect dynamic process data as near as practical to our design level of operation. We do this with a bump test, where we step or pulse the CO and collect data as the PV responds.
It is important to wait until the CO, PV and D have settled out and are as near to constant values as is possible for our particular operation before we start a bump test. The point of bumping a process is to learn about the cause and effect relationship between the CO and PV.
With the process at steady state, we are starting with a clean slate. As the PV responds to the CO bumps, the dynamic cause and effect behavior is isolated and evident in the data. On a practical note, be sure the data capture routine is enabled before the initial bump is implemented so all relevant data is collected.
Two popular open loop (manual mode) methods are the step test and the doublet test.
For either method, the CO must be moved far enough and fast enough to force a response in the PV that dominates the measurement noise.
Also, our bump should move the PV both above and below the DLO during testing. With data from each side of the DLO, the model (step 3) will be able to average out the nonlinear effects as discussed above.
- Step Test
- Doublet Test
Step 3: Fit a FOPDT dynamic model to Process Data
In fitting a first order plus dead time (FOPDT) model, we approximate those essential features of the dynamic process behavior that are fundamental to control. We need not understand differential equations to appreciate the articles on on this site, but for completeness, the first order plus dead time (FOPDT) dynamic model has the form:
Where:
PV(t) = measured process variable as a function of time
CO(t - Өp) = controller output signal as a function of time and shifted by Өp
Өp = process dead time
t = time
When the FOPDT dynamic model is fit to process data, the results describe how PV will respond to a change in CO via the model parameters. In particular:
- Process gain, Kp, describes the direction and how far PV will travel,
- Time constant, Tp, states how fast PV moves after it begins its response,
- Dead time, Өp, is the delay from when CO changes until when PV begins to respond.
Step 4: Use the model parameters to complete the design and tuning
In step 4, the three FOPDT model parameters are used in correlations to compute controller tuning values. For example, the chart below lists internal model control (IMC) tuning correlations for the PI controller and dependent ideal PID controller, and dependent ideal PID with CO filter forms:
The closed loop time constant, Tc, in the IMC correlations is used to specify the desired speed or quickness of our controller in responding to a set point change or rejecting a disturbance. The closed loop time constant is computed:
- aggressive performance: Tc is the larger of 0.1·Tp or 0.8·Өp
- moderate performance: Tc is the larger of 1·Tp or 8·Өp
- conservative performance: Tc is the larger of 10·Tp or 80·Өp
The FOPDT dynamic model of step 3 also provides us the information we need to decide other controller design issues, including:
- Controller Action
- Loop Sample Time, T
- Dead Time Problems
- Model Based Control
