Modeling and Control

We could talk about how important communication is for our society and even more importantly our marriage but let’s stick to something we are more interested in as automation engineers particularly since we essentially have no control over politicians and spouses. So let’s talk about communication intervals, control execution intervals, analyzer cycle times, and input scan times.

We tend to think that faster is better but this is not always the case. For example, a bioprocess control engineer recently suggested model predictive control of growth rate in a fermentor would not work because the changes in growth rate were too small. If you consider it is just a matter of time frame, you see a resolution (pun intended). If an analysis was made every hour, the true change in biomass concentration would be small compared to the repeatability of the analysis. The signal to noise ratio for the rate of change of biomass concentration (biomass growth rate) would be poor. However, process control is still possible if the time interval between analysis data points is increased and the result fed to a rate of change calculation described in the article “Full Throttle Batch and Startup Response” in the May 2006 issue of Control. Note that even though this calculation uses a dead time and velocity (rate) limit block, the proper setup of these blocks does not introduce additional dead time. Further details on the configuration and the proper filtering and rate limiting of the process variable before it goes into the dead time block for the rate of change calculation is offered in the following screen print of a module.

Rate of Change Module

The use of a rate of change as the controlled variable is described for PID control of an exothermic reactor in the book A Funny Thing Happened on the Way to the Control Room and for model predictive control of a bioreactor in the book New Directions in Bioprocess Modeling and Control.

Whether we are talking about analyzers, or any sort of digital communication, control, and processing, a dead time is created for unmeasured disturbances from the time interval. The actual dead time to detecting and reacting to an upset depends upon the relative timing of the read (input), write (output), and the upset. If the output is done right after the input, the dead time varies from nearly zero to one time interval for an upset that arrives just before and after the input, respectively. On the average, we can say the upset arrives in the middle of the interval so the average dead time is 1/2 of the time interval. For unsynchronized digital devices, the worst case dead time could be the summation of the time intervals. If the output is done at the end of the time interval, the dead time varies from one to two time intervals for an upset that arrives just before and after the input, respectively. This is the case for chromatographs and other analyzers where the sample is processed and the analysis is ready at the end of the cycle time. Here the average is 1.5 times the time interval (cycle time). The following slide illustrates the concept.

DeadTime from Discrete Devices and Analyzers

Even when dead time is introduced, it has minimal effect on performance for controllers that were detuned since the integrated absolute error for the upset depends on the controller tuning settings. In my Control Talk column in the November 2006 issue of Control magazine, we discussed how an increase in digital time intervals did not have an affect on a controller tuned with a Lambda factor of one until the total dead time exceeded half of the process time constant. Thus, tests on the effect of intervals and cycle times should use different relative timings of the unmeasured disturbance and various tuning settings.

(The above is an excerpt from my Control Talk column in the upcoming December 2006 issue of Control Magazine. Please see the column for a more complete discussion and the latest "Top Ten List").

My first exposure to model predictive control, MPC, was in late 1979 when I attended a meeting called by Bob Otto, ISA Fellow. Bob had just returned from the AIChE 86th Annual National Meeting where he sat in on Charlie Cutler and Ramaker’s presentation of their paper Dynamic matrix control-a computer control algorithm. This landmark work by Shell was the fore runner of modern day model predictive control, MPC. Bob’s assessment was that this technology represented one of the most important developments he had seen in process control. The power of MPC technology comes from the fact that the controller is generated based on a process step response or impulse response model and is designed to minimize the control error over a prediction horizon. Control performance is determined by parameters that specify penalty on error and penalty on move. Soon after Shell’s public announcement of their work on dynamic matrix control, Charlie went on to form the DMC Corporation. Since that time, major suppliers of MPC technology have successful addressed a variety of applications. The wide spread acceptance of MPC technology is well documented in the paper by Professors Joe Qin and Tom Badgwell, A survey of industrial model predictive control technology.

In the early-80’s, Bob Otto lead an initiative within Emerson to explore the feasibility of embedding MPC technology within a distributed control system. This research focused primarily on single loop applications as documented in the paper Development of a Multivariable forward modeling controller by Bob Otto and Kelvin Erickson. Field trails were conducted using a prototype of single loop MPC. One of the technical challenges that prevented general deployment of this technology at that time was the need to provide a robust means of process identification. Also, it was not feasible at that time to embed general MPC in the controller because of the associated CPU and memory requirements.

By the later-90’s, the availability of low cost memory and vastly improved processor performance made it feasible to fully embed MPC technology within the control system. By embedding MPC in the control system, a control system supplier can provide an environment that makes it easier and quicker to engineer and commission MPC applications. Also, by embedding MPC in the controller, it is possible to address applications that require faster control execution e.g. 1sec period of execution. In many cases, embedded MPC control is a valid alternative to the traditional PID based strategies for deadtime compensation, feedforward and override control. If you have no experience with MPC, then some examples of how MPC may be effectively used to replace traditional PID based strategies are contained in the following:

MPC for smaller applications

These examples are based on the DeltaV MPC capability introduced in 2000, DeltaV Predict. This initial capability was targeted at smaller applications (no larger in size than 8x8). The DeltaV advanced control team later developed DeltaV PredictPro to address larger applications (as large as 40x80 in size).

Last week we discussed the effect of disturbance timing on performance. This week we turn our attention to the location and speed of the upset and the Delay/Lag (dead time to time constant) ratio of the process.

Most control text books and papers show a step disturbance on the process output, which is the process measurement. This is the worst case scenario in that the disturbance fully hits the controller before the controller can take any corrective action. The abrupt change in the process measurement can cause a large step and bump in the controller output from gain and rate action, respectively. In some respects, this disturbance location is similar to noise. Conventional Lambda factors (>1.0) do well in helping a controller to not overreact to this disturbance.

Most control literature also tends to focus on a process where the delay (dead time) is comparable in size or larger than the lag (time constant). In these cases, conventional Lambda factors again give good performance and robustness.

I have often heard professors and operators say that a loop is terrible because it has a huge lag (process time constant). This is true for disturbances downstream of the process entering directly into the measurement. For a load upset (e.g. feed, utility, or ambient upset) into the process, the large process time constant (Delay/Lag < < 1.0) can provide incredibly tight control if a much smaller Lambda factor is used (<<1.0).

Most of the important loops I have worked on in the chemical industry (column or vessel composition, pressure, and temperature control), have disturbances on the process input and a Delay/Lag ratio much less than one. The book New Directions in Bioprocess Modeling and Control discusses how the interactive process temperature time constants cause the Delay/Lag ratio to be about 0.2 and how batch composition responses have a Delay/Lag ratio so small they look like they have an integrating process response.

Static mixers used for neutralization have a Delay/Lag ratio about one but the addition of the electrode time constant or signal filter makes the Delay/Lag ratio less than one. Poor reagent piping, injection, and mixing design and a large control valve dead band or resolution limit, can cause the delay to sky rocket. Large Delay/Lag ratios are often a symptom of poor plant/system design for chemical processes. On the other hand, there are processes, such as sheet or web thickness, and analyzers with large cycle times and transportation delays that make the loop very dead time dominant (Delay/Lag >> 1.0).

Feed composition, catalyst activity, metabolic pathway, and ambient temperature disturbances are generally very slow (upset lag of hours). Cooling water and steam disturbances can be faster depending upon system design (upset lag of minutes). Feed flow disturbances are much faster and generally reflect the response from reset action (upset lag of seconds). Step flow changes occur when pumps are turned-on and on-off (isolation valves) are opened.

As the upset slows down (upset lag increases), the peak error (maximum deviation) and integrated absolute error (total error) decreases but the fractional improvement in IAE from more aggressive tuning stays the same for loops with a large process time constant (Delay/Lag < 1.0) or increases for dead time dominant loops (Delay/Lag > 1.0). In a way, the upset lag performs a similar task to the process time constant in terms of slowing down the excursion rate of the process variable.

If there were no upsets, you wouldn't need a controller. You could just set the control valve to a predetermined position.

The following screen prints and excel file compares the performance of different types of tuning for various Delay/Lag ratios for load upsets that enter as process inputs. Lambda tuning does well for dead time dominant processes and can made to do as well as the Simplified Internal Model Control (SIMC) for lag dominated processes by the use of a Lambda equal to the dead time (Lambda factor equal to the Delay/Lag ratio). See our first blog on the Unification of Tuning Methods for more info.

Delay/Lag Ratio Test

Tuning Rules Results

Not discussed here is interaction and noise and how it reduces the desired degree of transfer of variability from the controlled variable (controller PV) to the manipulated variable (controller output). Also, not addressed is what change in the loop gain, delay, and lag (nonlinearity) can occur and does this change in dynamics make the loop too oscillatory. In general there is a trade off between performance and robustness whenever you are tuning a controller. Larger Lambda factors reduce the transfer of variability and improve the robustness of the controller. In summary, to evaluate a control strategy, algorithm, or tuning one should consider:

(1) Desired degree of transfer of variability from controller PV to controller output
(2) Amount of nonlinearity and its affect on variability
(3) Timing of disturbance
(4) Location of disturbance
(5) Speed of disturbance
(6) Delay/Lag ratio

How upsetting is this to dead compensators and model predictive controllers? For answers to this and more, stay tuned.

The tuning of a PID control loop should be based on an accurate knowledge of the control parameter response to a change in the associated manipulated process input. If the process response is determined using values communicated from a controller to a workstation, then these communications may impact the identified process response. For example, the control network may limit access by the workstations to 1 sec samples even thought the PID and its associated IO may be executing in the controller at a much faster rate e.g. 100 msec. Also, the timing associated with values seen at the workstation may vary or be delayed with communication loading i.e. communications jitter. The combined effect of communications sample rate, delay and jitter introduces a degree of uncertainty into the identification of the process response. For very slow processes, the error introduced in the identified process response may have little impact on the calculated tuning. However, for fast responding processes such as liquid pressure and flow loops such uncertainty can lead to unsatisfactory tuning. In general, to provide best tuning in a distributed environment it is necessary to capture the process response at the point of control.

The influence of communication sample rate, delay or jitter may be eliminated by capturing the process dynamic response as part of the function block execution. This approach also naturally allows the process response (control and manipulated parameter) to be collected at the block execution rate. Such functionality may be introduced into a control system as part of the PID block or as a modifier to the PID function block. The concept of a function block modifier is something that Dennis Stevenson and I developed and patented a few years ago. For controller based implementations, function block modifiers may be used to minimize controller memory requirements since the modifier is instantiate and exists only when the loop is being tuned.

When control is done in the field using fieldbus devices, then the sample limitations, communications delay and jitter from the controller to the workstation can be eliminated similar to controller based PID. This can be implemented by designing the autotune block modifier to work with the proxy that represents the field PID in the controller. However, to eliminate the delay and jitter introduced by communications between the field device and the controller, it is necessary to capture the process response at the field device. For example, the latest Emerson fieldbus devices provide this capability. Through the use of these techniques, it is possible to provide tuning support that is independent of where control is done.

If you would like to read more on this topic, then you may find it helpful to get a copy of the paper, Autotuning in Distributed Environment, Blevins, Wojsznis, Thiele, ISA TECN1999 conference. Copies of this paper can be downloaded through the ISA web site. Also, Aadditional information on how to minimize the impact of communications sampling, delay and jitter on PID tuning is contained in the following:

Minimizing Communications Delay/Jitter in PID Tuning

If the total loop dead time was zero, you could set the controller gain as large and the reset time as small as desired. If there were no disturbances, you could simply sequence the controller outputs for startup, transitions, and shutdown. Process dynamics, controller tuning, and loop performance would be a non issue.

I once had a loop with zero dead time. I was studying the performance of my new algorithm for adaptive pH control in an Advanced Control Simulation Language (ACSL) program for my Master’s Thesis. The larger I set the controller gain, the tighter the control I got. I was ecstatic. I was going to become “way famous”. Then the let down - I had inadvertently turned off the dead time function. All I had left for process dynamics was a single time constant. The operating point nonlinearity of pH had no effect because I could stay incredibly close to set point. Since then I have seen tuning studies for a single time constant that beat to death a scenario where all the normal concerns are non existent. I decided to become sensitive to dead time especially since I could reduce my time on a pH startup by reducing dead time.

Control textbooks and studies tend to focus on set point responses ignoring unmeasured disturbances at the process input (e.g. load upsets). Special algorithms can be designed and tuned to prove a point. This may work well in simulations, aerospace, and hydraulic systems where dead time is either negligible or predicted/compensated and the servo response rules, but the real world of industrial process control isn’t so kind.

The variety and variability of the sources of dead time and disturbances in process control is quite impressive. The following lists are just some major sources that come to mind.

Sources of Disturbances

1) Limit cycles (split ranged point discontinuity, resolution, and cascade dead band)
2) Interaction between loops
3) Slow secondary loops (cascade control)
4) Design limits (equipment operating limits)
5) Low residence times (e.g. undersized feed, recycle, surge, and waste tanks)
6) Manual procedures and manual valves
7) Field switches (e.g. on-off level control)
8) Activity (catalytic and metabolic)
9) Ambient conditions
10) Interlocks and sequences
11) Raw materials
12) Recycle streams
13) Startups, shutdowns, and product transitions
14) Fouling (e.g. process coatings) and frosting (e.g. crystal accumulations)
15) Parallel trains
16) Undersized cooling towers
17) Bored board operators
18) Shift change
19) Initiatives
20) Goal reviews

My worst experiences have been with undersized recycle, surge, and waste tanks. The residence time (volume divided by throughput rate), which is the process time constant, is so low there is not enough filtering of the changes in stream composition. Also, the level control on these tanks is forced to jockey the feeds to downstream operations to keep the tank from overflowing or running dry. Plants tend to avoid putting in the bigger tank to save money and reduce inventories when they need to debottleneck or push a process.

Sources of Dead Time

1) Discrete execution and communication interval
2) Analyzer cycle time (e.g. chromatograph)
3) Transportation delay (e.g. sample line)
4) Mixing delay (e.g. agitator, eductor, and sparger)
5) Injection delay (e.g. back filled dip tube)
6) Resolution limit (e.g. VSD, control valve)
7) Dead band (e.g. VSD, control valve)
8) Instrument time constants in series (e.g. sensor and signal filter lag)
9) Process time constants in series (e.g. thermal lags and residence times)
10) Lab samples (e.g. sample hold, processing, and analysis time)

Dead time is often inversely proportional to a rate and therefore a function of test conditions. The dead time from transportation delays, sample lines, sensor lags, and residence times in series is inversely proportional to flow rate. Mixing dead time is inversely proportional to agitator pumping rate or eductor flow rate. The dead time from dead band and resolution limits is inversely proportional to the rate of change of the signal (e.g. rate of change of process variable for measurement resolution limits and rate of change of controller output for valve dead band and stick-slip). The time it takes a measurement to get out of its resolution limit or noise band can be significant for level or temperature and depends upon how fast the process is driven to change and hence the step size in the controller output or set point. The dead time for control valves becomes just the summation of the pre-stroke dead time, discrete processing, and communication interval (all usually small) if the step in controller output is larger than the valve dead band or resolution limit. The dead time effect of dead band and resolution limits unfortunately does show up for unmeasured load upsets at the process input.

My intention is now to avoid any further dead time or disturbances to an evaluation of dead time compensators and model predictive control so check here next week for more fun than control engineers should be allowed to have with advanced control.

The PID is by far the most common feedback control technique used in the process industry. Thus, during the development of DeltaV we placed a special emphasis on the features that should be included in the PID block. There were differences in the PID implementation of the two control system manufactured by Emerson at that time, Provox and RS3. For example, Provox uses the series form of the PID and the standard form of the PID (also know as the ISA form) is used in the RS3 control system. Also, there were some differences in the features supported by the PID and in its implementation. As we looked at the PID in other control systems of competing manufacturers, we noticed similar differences in the PID form, features, and implementation. In some cases, the manufacturers included multiple PID blocks within their system to support multiple forms of the PID and to provide different levels of capability. As part of this background investigation, we reviewed a draft copy of EnTech’s Automatic Controller Dynamic Specification that Bill Bialkowski had sent me earlier that year for comment. This specification contained ideas that influenced some of the features that we included in the PID.

In the end we included in the PID design what we considered to be the best PID features found in industrial control systems. We set a goal of incorporating this functionality in one function block. The core parameters of the block were based on the PID definition in the Fieldbus Foundation Function Block Specification. By taking this approach, the names and data types of the basic PID parameters were consistent with the PID parameters included in Foundation fieldbus devices. Also, the units of the PID parameters were selected to be consistent with those defined by the fieldbus Foundation function block specification. The fieldbus Foundation function block specification does not specify the form of the PID. Thus, we were free to choose the form of the PID. However, rather than selecting one form of the PID algorithm, the block was structured to allow the user to select Series or Standard form using the FORM parameter.

A key decision in the PID design was the method used to realize the reset component. In our investigation, we noted that were significant differences in the approach that major manufactures have taken in their reset implementation. Thus, we examine the dynamic behavior of the most common designs (including that of Provox and RS3) in cascade strategies and under the conditions of override and downstream limit conditions. Based on this analysis, the external-reset feedback technique was selected for the reset implementation. This approach fits especially well into a system that is designed around the Foundation fieldbus block design. For example, in a cascade control strategy, the standard block options allow the PV of the downstream block to be automatically provided through the connection to the BKCAL_IN parameter. Thus, this value is available to the PID for use in the reset calculation independent of whether the downstream block is in the same controller, another controller or a fieldbus device.

One of the key points of the Entech specification was that the user should be able to independently select whether proportional and derivation action are based on PV or error. Thus, based on this input, we included the STRUCTURE parameter in the PID to allow the user to independently select whether proportional and derivative act on PV or error. In addition, as one of the STRUCTURE selections, we allow the user to specify the fraction of PV or error that is used in proportional and derivative action. Through this added selection it possible to achieve the same response provided by a two-degree of freedom controller and thus eliminating the need to choose whether to tune a loop for best response for setpoint or load disturbance.

If you are interested in learning more about the features that we selected to include in the PID block, then more information can be found in the white paper Key Features of the DeltaV PID Function Block .

When replacing an existing control system, the startup of the new system can often be made much smoother by re-using the PID tuning that has been established over the years with the existing system. If you are lucky, the form of the PID and units of the tuning parameters of the old and new systems match and you can just re-enter the tuning values directly into the new control system. However, the form of the PID and the units of the PID tuning parameters often vary between manufacturers and thus it may be necessary to convert the tuning values before they can be used in the new control system. If you find the PID form and units of the tuning parameter for the old and new control systems do not match, then you will need to convert the tuning parameter values to obtain the same dynamic response in the new control system.

If the converted loops only use PI control i.e. derivative (rate) gain = 0, then whether the form of the PID is series or standard will have no impact on the tuning. The tuning of the standard and series PID (for the same dynamic response) vary only when derivative (rate) is used in control. When derivative action has been used in the older system, then it is always possible to convert series tuning to the equivalent tuning for the standard form of the PID.

The conversion of existing tuning should always take in account for the units of the tuning parameters. Examples of unit variations you may encounter in commercial products are:

Proportional Gain: %/% or Proportional Band
Integral (reset): repeats/min, repeats/sec, min/repeat, second/repeat
Derivation(rate): minute, second

Accounting for difference in gain units can be done independent of the form of the PID. Conversion between two commonly used units may be done as following:

Proportional Gain (%/%) = 100/Proportional Band

If the form of the PID in the old and new system is the same or derivative action is not used in the loop, then it is only necessary to consider the units of the tuning parameters. For example, if the reset unit used in the older system is repeats/min and the new system reset unit is min/repeat, then the reset value for the new system is just the reciprocal of the old reset value:

Reset (min/repeat) = 1/Reset (repeats/min)

Often you may find it will save time to create a spread sheet to do the calculations needed to convert tuning parameters. For example, the following spreadsheet was created to support conversion from series form with units of Gain(%/%), Reset (repeats/min), Rate(min) to either standard or series from where the units are Gain(%/%), Reset (second/repeat), Rate(sec)

Example Conversion of PID Tuning

How can we get rid of dead time in our loops so we can be rich and famous by Friday? PID controllers with dead time compensation are reported to eliminate dead time in terms of a controller seeing the effect of changes in its controller output. For set point changes where all the controller needs to be concerned with is how its output responds to a new set point, the results are impressive for an exact knowledge of the process dead time. However, for unmeasured load disturbances at the process input, the only way to eliminate dead time other than an improvement in the plant or control system design is to accelerate the control system to the speed of light. So unless you have Scotty and Warp Drive on the Starship Enterprise, you are stuck with the dead time from the process equipment, piping, control valves, instrumentation, and digital devices. A dead time compensator can offer some improvement in load rejection by facilitating more aggressive tuning of the PID but with a considerable risk of oscillations from an inaccurate dead time.

If you don’t have time for the details or just want to cut to the chase, here are the recommendations

(1) First improve the PID controller tuning before even considering dead time compensation. Setting Lambda equal to the maximum dead time (Lambda factor equal to the maximum dead time to time constant ratio) is effective for load disturbances at the process input if there are no extenuating circumstances.

(2) Add feedforward control whenever it is possible to measure or infer load disturbances at the process input.

(3) If there is economic justification for further improvement and the dead time can be updated within 25% accuracy for varying operating conditions, trial test and closely monitor a PID with delayed external reset for low dead time to time constant ratios.

(4) For loops with high dead time to time constant ratios, multiple manipulated variables, interactions, or constraints, consider model predictive control.

The ultimate performance achievable in terms of load disturbance rejection depends upon the dead time. In the “Theory” section of Chapter 2 of Advanced Control Unleashed equations are developed that show the minimum peak error is proportional to the dead time and the minimum integrated error is proportional to the dead time squared for unmeasured load upsets. How close the actual performance of a control loop comes to this ultimate performance depends upon PID structure, tuning, and enhancements. This blog focuses on the effect of variations in dead time on the performance and robustness of dead time compensation as an enhancement and Lambda as a tuning rule for disturbance rejection. The two predominant methods of dead time compensation studied here are the Smith Predictor PID and the PID with a delayed external reset.

The Smith Predictor was extensively documented in the 1970s. It provides a new controlled variable that is the response of the process variable to its controller output without dead time. It requires entry of three parameters commonly known as process gain, dead time, and time constant. The Smith Predictor uses these parameters to create models of the process from the controller output. In its most documented form, the Smith predictor subtracts a model of the process with dead time from a model of the process without dead time and adds the net result to the measured process variable to create a new controlled variable. If the model is perfect, the new controlled variable has zero dead time in terms of the controller seeing the effect of its own controller output. Since the maximum allowable controller gain is inversely proportional to dead time, the controller gain can theoretically be increased without limit for a perfect model provided you ignore extenuating circumstances, such as loop interaction, measurement noise, and final element dead band and resolution. One of the practical issues with the Smith Predictor is that the new controlled variable of the PID is no longer the actual process variable. The original process variable must be restored for the operator interface to the PID. Also, performance monitoring or trending must look at the original process variable rather than the new controlled variable used by the PID. Terry Blevins proposed in the 1979 ISA paper “Modifying the Smith Predictor for an Application Software Package” a multiplicative and additive correction of the process variable to deal with changes in the slope (gain) and intercept (bias), respectively in the process model.

The PID with a delayed external reset was informally presented in the 1980s and published in the early 1990s. It simply consists of putting a dead time (DT) block in the external reset. This method only requires that a single parameter commonly known as process dead time be entered as the dead time in the DT block. Terry Blevins documented in the early 1990s how the Smith Predictor for a particular Lambda tuning reduces to this PID with a delayed external reset.

The results presented here show that for a perfect model and the same controller tuning the PID with a delayed external reset performed better for processes with a small dead time to time constant ratio (time constant dominant), whereas the Smith Predictor performed better for processes with a large dead time to time constant ratio (dead time dominant). The Smith Predictor did not do as well for small dead time to time constant ratios because the control error seen in the controlled variable by the PID is much smaller than the actual control error in the process variable. In both cases, the improvement was not as impressive as the improvement gained from setting Lambda equal to the dead time rather than the time constant. Surprisingly the improvement in load disturbance rejection from dead time compensation was greater for processes with small dead time to time constant ratios. This goes against the conventional wisdom that the best opportunity for dead time compensation is for dead time dominant loops. The results can be explained in terms of the ultimate limit for performance of dead time dominant loops being lower. The reduction in the peak excursion from more aggressive tuning settings is negligible for dead time dominant processes because the peak error is essentially the open loop error.

Another startling result was how quickly a Smith Predictor erupted into rapidly growing oscillations in the controller output when the model dead time was more than twice the actual process dead time. The fast full scale oscillations in the controller output resembled on-off control. While it is relatively well known that dead time compensators are sensitive to model mismatch, the effect was expected to be gradual and thought to be more in terms of a model dead time being too small. The concern for rapid deterioration for a model dead time being too large was raised in Good Tuning – a Pocket Guide and was documented for model predictive control in Models Unleashed. While a PID with delayed external reset is also adversely affected by a dead time mismatch in both directions, this PID develops a small amplitude high frequency dither rather than a full scale oscillation in controller output for an excessively high model dead time. The consequence is less severe and may be adequately handled by the addition of a small dither filter inserted in the PID controller output, but this was not tested.

PID controller tuning for self-regulating processes without extenuating circumstances can develop oscillations when the identified (model) process dead time is too small. PID controllers with dead time compensation and model predictive controllers can develop oscillations when the identified (model) dead time is too large as well as too small.

In order to get the performance benefit from dead time compensation, the PID must be tuned more aggressively. In other words, a PID with dead time compensation will perform the same as a PID without dead time compensation if they are tuned the same. While the improvement in integrated absolute error (IAE) for load upsets from more aggressive tuning (higher controller gain and lower reset time) can be accurately estimated for a regular PID, the equation does not work well for a dead time compensator. Furthermore, a dead time compensator soon reaches a point of diminishing returns. For example, the improvement in load rejection of a Smith Predictor from a controller gain that is quadrupled may not be noticeable whereas for a regular PID, it normally results in a four fold reduction in IAE. It is important to remember there is a tradeoff between performance and robustness for any feedback controller in that as you make controller tuning more aggressive to improve load rejection you make the controller more sensitive to changes in the process gain, dead time, or time constant.

A nonlinear gain from the installed characteristic of a control valve has been widely discussed. However, the nonlinearity of the process gain of the temperature or composition response is the inverse and consequently the combined effect is less than documented when these loops directly manipulate a control valve. The variability of dead time is often larger than the variability of the process gain or time constant because the dead time is inversely proportional to a rate (e.g. flow rate or pumping rate or rate of change of a signal) and has many different sources (e.g. valve deadband or resolution, piping transportation delay, mixing delay, process lags in series, sensor lags, signal filters, and discrete communication or scan intervals). Thus, it is problematic to compute the dead time accurately enough to get the benefit of a dead time compensator.

In all of the following test results AC1 is always an uncompensated PID with Lambda equal to the process time constant (lag), which is equivalent to a Lambda factor of one.

The first set of test results illustrates the effect of different tuning. Here AC2 is an uncompensated PID with Lambda equal to the process dead time (delay), which is equivalent to a Lambda factor set equal to the dead time to time constant ratio.

Tuning Rule Test 1

The second set of test results shows how well a Smith Predictor can do. Here AC2 is a Smith Predictor PID with the gain doubled and the reset time halved after Lambda has again been set equal to the process dead time. In other words, this AC2 has twice the proportional and integral action of the uncompensated AC2 in the first set of test results.

Smith Predictor Test 2

The third set of test results shows how well a PID with a delayed external reset can do. Here AC2 is a PID with delayed external reset with the gain doubled and the reset time halved after Lambda has again been set equal to the process dead time. In other words, this AC2 has twice the proportional and integral action of the uncompensated AC2 in the first set of test results.

Delay Comp Test 3

For discussion of the test results and configuration, request from me a copy of the Advanced Application Note 003 titled “Compensation of Dead Time in PID Controllers.”