Modeling and Control

Earlier this year I had the pleasure of putting together a class on process control for a group of new software engineers. In most cases, the individuals had no experience in the process industry and no formal training on process control. I used this opportunity to distill into a two day class the key information that I thought these engineers would need to understand the basics of process control. The class material covers only the basic concepts and terminology that a control engineer should be familiar with in performing his job. The class was taped and turned into a DVD that is distributed internally within Emerson for self-study. I thought it might be helpful to post some of the slides from this basic class on process control since it covers and explains most of the terminology and control concepts you will encounter on this blog

In many of our posts, we assume that the reader is an experienced process or control engineer and is familiar with the technical terms used in the post. However, this may no be true for all the readers. Also, some of the terms such as controller gain may be used in different ways within our industry e.g. proportional band vs proportional gain. If you come across a term that is unfamiliar, then there is a good chance that you will find an explanation of the term in this material.

The class material is organized into the following areas of study:

Introduction Historic Perspective
Field Devices and Wiring
Documentation of Plant Control and Instrumentation
Characterizing the Process, Terminology
Control System Objectives
Manual and Feedback Control
Feedforward Control
Cascade Control
Override Control
Split Range Valve Position and Ratio Control
Test Over Class Material

Most of the material is independent of the control system design or manufacturer. However, the workshops were based on the student having access to a DeltaV control system. The control examples in workshop are based on the Foundation fieldbus function block set and thus should be familiar if you have been working with fieldbus systems. You may find it fun to look over the tests that go with this short course. If you aren’t certain about the correct answer to some of the questions, then you may find it helpful to look deeper into the class material.

When designing a control strategy you may be faced with the challenge of there being an extra degrees of freedom. One of the most common examples is where one control parameter may be maintained at setpoint through the adjustment of two manipulated parameters. Often the solution is to address the control design using split range or valve position control. Through the use of these techniques, the two actuators appear as one actuator to the PID control. However, there are some significant differences in the resolution and dynamic response that may be achieved using either technique. An alternate approach is to implement a strategy that combines the best of split range and valve position control.

I once was responsible for the design of the 400 # header pressure controls for a new power house in a pulp and paper mill. Under normal operating conditions, the header pressure was to be maintained by the turbo-generator extraction to the 400# header. However, if the turbine was to trip or be taken off-line for maintenance, then two pressure reducing valves (normally closed) were to be used to let down steam from the 1475# header to the 400# header. Under a trip condition, it was important that the full dynamic range of the pressure reducing valves be used to make up for the steam that had been supplied by the turbine extraction. This objective could be achieved through the use of split range control. However, if the turbo-generator was to be off-line for an extended period of time for maintenance, then it would be advantageous to provide the precise pressure control that may be achieved by taking advantage of the operating characteristics of valve position control. After some work, I came up with a network that combined the best of split range and valve position control. I commissioned and tested the header controls as the power house was brought on-line. The 400# header control proved to be quite effective and after over 20 years is still in use at the plant- migrated to new controllers.

The work I did on the revised header pressure control strategy was documented in a paper that I wrote and presented shortly after the power house startup, "Improving PRV Pressure Control", ISA 31st Annual Southeaster Conference, April, 1985. The technique was later used within Emerson’s pulp and paper group to address a variety of applications e.g. furnace draft control variable speed ID fan in combination with damper, variable speed pump in combination with a regulating valve for recovery boiler liquor flow control, forced-draft fan control pressure control using a variable speed fan with inlet vanes. Many of these applications were documented by Bill Love, Forney International, in an article “Innovative control technique that improves control rangeability and resolution in paper mill applications”, Tappi Journal, February, 1994.

The tools that are available in most modern control systems are sufficient to implement the network that I originally designed for the header pressure control. The basic network design is shown in the following:

Combining Split Range and Valve Position Control

Also, this material includes an example of how the network may be implemented as a re-usable composite block in DeltaV. Some process examples are iprovided that allow you to compare the dynamic response of this network to that achieved using spilt range control and valve position control. If your control objectives can not befully met by valve position or split range control, then you may want to consider this network for your application.

A small fraction of the control loops in industry are characterized by the process deadtime being dominant i.e. greater than the process time constant. In most cases the source of the process deadtime is associated with transport delay or analyzer sample time for the process measurement. In many cases the loop directly impacts final product and thus can have a significant influence on the process efficiency and product quality. For such a process, the loop response to load disturbances and setpoint changes may be slower than desired since the dominant deadtime limits the amount of reset and gain that may be applied in the loop tuning. One approach that may be taken to improve the control of a deadtime dominant process is to utilize deadtime compensation with the PID. The Smith predictor is one of the best known techniques for deadtime compensation. Also, the Dahlin algorithm has been successfully applied by the pulp and paper industry in the control of deadtime dominant processes such as the paper machine. Having confronted some difficult applications in which process deadtime was a limiting factor in the loop performance, I took some time to look into the different implementations of the Smith predictor and to compare these with the Dahlin algorithm.

Interesting enough, it turns out that mathematically the Dahlin algorithm is identical to a Smith predictor applied to a PI controller if the PI tuning is set in a specific manner. This specific tuning of the PI controller is based on the loop period of execution, process gain, time constant, deadtime and the desired closed loop time constant. Through a sight modification of the Smith predictor, it is possible to extend the use of the Smith predictor to address processes that are characterized by unmeasured disturbances that modify the process gain. Also, it is possible to structure the Smith predictor to allow control to be done using sampled process measurements e.g. composition from a gas chromatograph. These modifications of the Smith predictor are the basis of the Provox deadtime compensation PCA and the DeltaV PID_DEADTIME module template. If you have an interest in this area of control, then the mathematical analysis and derivation of the tuning to provide the response of the Dahlin algorithm using a Smith Predictor and details on the modifications used to extend the applicability of the Smith predictor can be found in the paper Modifying the Smith Predictor for an Application Software Package, T.L. Blevins, ISA National Conference, 1979.

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 .

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.”

As noted in my December 4th posting, the Hart Communication Foundation has adopted the IEEE 802.15.4 physical layer for wireless HART. One of the technical challenges is that the 2.4 GHz spectrum defined by IEEE 802.15.4 is also used by Wi-Fi and Bluetooth devices. Also, some electrical devices found in industry generate noise in this frequency band. Thus, at times it is expected that a transmission will be corrupted. To help minimize the impact of these other devices on communications, the Time Synchronized Mesh Protocol (TSMP) selected for wireless HART uses frequency hopping. Even so, at times it is expected that multiple transmissions of a measurement used in control or multiple communications of control actions to an actuator may be lost. Thus, a few years ago we started looking at the control requirements under these conditions. In particular we examined the behavior during communication loss and after communications are re-established.

When the control measurement is lost, a standard PID may be expected to continue executing and thus could windup because of reset action. This condition might be addressed by changing the actual mode of the PID to manual on detection of a measurement loss. However, with either approach, the reset action taken by the PID under this condition will be disruptive to the control. If derivative action is utilized in the PID, then the abrupt transition in the measured value on recover of transmission may cause a spike in output since the derivate contribution is normally calculated based on the period of execution. However, by modifying the reset and derivative calculation to account for the time since the last measurement update, then it is possible to minimize the impact of loosing multiple measurement transmissions.

The loss of multiple transmissions from the PID to an actuator may also disrupt loop operation. A standard PID under these conditions would continue to takes control action even though these actions have not reached the actuator. Thus, under these conditions, the reset action would wind up and when communications are re-establish you would expect to see a significant bump in the process. However, by using feedback from the actuator in the reset calculation , as defined by the Fieldbus Foundation, then windup under this condition may be avoided.

Details on the PID modifications to account for loss of the control measurement or the path to the actuator are described in detail in a paper that we presented at ISA2006, “Improving PID Control with Unreliable Communications”. An overview of this work is provided in the following presentation:

PID for Unreliable Communications

In this presentation, the performance of a standard PID is compared to a modified PID. The modified PID uses actuator feedback and the time since last good communication in the reset and rate calculations. The modified PID provides a significant control improvement over the standard PID for the conditions that were considered in these tests.

One of the foundation pieces of measurement and control as utilized by the process industry is the concept of mode. The mode of a measurement inputs to a control system may be used to indicate if the associated device is in or out-of-service. For a control or output function in a control system, the plant operator typically uses mode to select the source of the setpoint or output. In some cases, mode may also be used to indicate if a calculation function is in or out-of-service. Thus, the IEC61804 international standard, Function Blocks for Process Control, specifies that all measurement, control and output function blocks must contain a mode parameter.

Mode has traditionally been defined in different ways by manufacturers of control systems and field devices. One of the things that the ISA SP50 User Layer Committee realized was that a consistent definition of mode is required to achieve control system interoperability with field devices. Therefore, the technical report produced by this committee defined the mode parameter. The mode parameter structure proposed by the SP50 committee was adopted with minor changes by the Fieldbus Foundation’s function block team. As an integral part of the interoperability test performed by the Fieldbus Foundation, the mode parameter implementation is verified to be consistent with this Function Block specification.

The mode parameter support by Foundation fieldbus function blocks consists of four attributes rather than a single target attribute found in some traditional control systems.

 Target mode attribute
 Actual mode attribute
 Permitted mode attribute
 Normal mode attribute

The plant operator uses the target mode attribute to select the desired mode of operation. The target mode selections defined by the specification are;Out-of-Service (O/S), Automatic (Auto), Manual (Man), Cascade (Cas), Remote Cascade (Rcas), and Remote Output (Rout). In the past, different terms have been used by manufacturers for some of the target mode enumerations. For example, Cascade mode is the equivalent to Remote Setpoint (RSP) in some traditional systems. Remote Setpoint and Remote Output are referred to as Supervisory and DDC mode respectively.

Based on the status of inputs to a function block and other conditions that impact block operation, it may not be possible for the block to operate in the requested mode. For example, if the output track input to a control block is active, then the block will not continue to operate as request e.g. Automatic mode. The actual mode attribute is used to reflect the mode of operation that can be achieved. Thus, the actual mode attribute is calculation by the block each execution. Two actual modes are defined that may not be selected as the target mode.

 Local Override (LO) mode – the block track input is active.
 Initialization Manual (IMAN) mode – the downstream path to the process is broken.

Since a control application may only require a few of the target modes supported by a device, the user may configure what operation modes are appropriate for his application through the permitted mode attribute. When this is done, the function block limits the target modes to those that are permitted. Similarly, the mode the operator should choose during normal plant operation is configured in the block using the Normal mode attribute. Even though this parameter is not utilized by the function block, it may be useful to other applications, such as an operator station to flag loops that are not running in the normal mode of operation.

One the challenges that the Fieldbus Foundation function block specification team addressed was how to define target mode to support both single knob (Man, Auto, Cas, RCas, Rout) vs. dual knob interfaces (Auto/Man + Cas/Rcas/Rout). By defining the Target mode attribute (bitstring) to use multiple bits for each target mode selection (including bits to indicate previous mode) it is possible to support both type of interfaces. Because of this capability, it is easier for legacy systems that use a dual knob interface to support the installation of fieldbus devices. Some modern control systems have adapted the Fieldbus Foundation’s definition of mode. In these systems, the mode parameter is used in a consistent manner independent of whether the associated function block resides in a field device or in the controller.

Many control systems have traditionally provided some capability to limit the rate of change in a setpoint value used in control. When a setpoint change exceeds this rate of change limit, then the rate limited value is use in control. Thus, the full setpoint change is not immediately seen in control until the rate limited value catches up to the target setpoint. Setpoint rate limiting can be a very useful feature especially in batch control since it allows large step changes in setpoint to be made without causing an upset in the process operation. Thus, when the Fieldbus Foundation function block team reviewed the features that should be supports by the PID block, we decided to include setpoint rate limiting. Also, we included this feature in the Analog Output, AO, function block.

To make it easier to configure setpoint rate limiting, the limit value was defined to be in engineering units per second. One question that we had to address was whether the rate limit should apply to both increases and decreases in setpoint. In some control systems that support setpoint rate limiting, only one rate limit value is configured and this applies both to increases and decreases in setpoint. However, there are applications where setpoint rate limiting is only required in one direction. For example, the rate of increases in feed to a reactor may be limited by how fast the cooling system can respond but there may be no limits on how quickly the feed may be decreased. In some cases a physical limitation may place a limit on how quickly a setpoint change may be implemented. Thus, in the Foundation Fieldbus PID, the setpoint rate limits for a setpoint increase and decrease may be independently defined in the function block configuration. You may disable setpoint rate limiting in either direction by setting the associated rate limit value to zero(0).

One important consideration in the design of rate limiting was whether setpoint rate limiting should apply when the PID block is in Cascade mode i.e. when the setpoint is provided by another function block rather than the operator. For example, in a cascade control strategy, the PID associated with the secondary loop would normally operate in Cascade mode and its setpoint would be supplied by the PID in the primary loop. In cascade control strategies, the introduction of non-linearity behavior such as setpoint rate limiting in downstream blocks can complicate the commissioning of the upper level loop. Thus, the function block specification states that PID setpoint rate limiting should be disabled when the block is in Cascade mode. If an application requires that rate limiting be enforces on how quickly a valve may open or close, then this may be done using the setpoint rate limits provided in the Analog output , AO, block that is part of the loop. The setpoint rate limits of the AO block apply in both the Automatic (Auto) and Cascade (Cas) modes.

If the user defines setpoint rate limiting in the AO block , then when a change in setpoint becomes rate limited the AO block is required to reflect this high or low limit condition in the status provided with the BKCAL_OUT that is wired to the BKCAL_IN of the upstream PID. Also, the BKCAL_OUT value is required to be the rate limited setpoint value. Thus, the upstream PID of the cascade may take action to prevent the reset from winding up when the downstream block can not fully respond to the requested change in setpoint. For example, when the PID BKCAL_IN indicates a limit condition, then the manufacturer may design the PID to clamp the reset contribution in the direction of the limit condition. Alternatively, the manufacturer may design the PID to use external reset i.e. to use the BKCAL_IN value i.e. the limited setpoint valve in the calculation of the reset contribution.

In the Foundation Fieldbus specification, the PID and AO setpoint value after rate limiting is an internal “working setpoint” value. To make it easy to indicate to an operator when rate limiting is active, some manufactures have added the working setpoint value as a visible parameter of the PID and AO blocks. The application of setpoint rate limiting in the PID block and the AO block is illustrated in the following example.

PID and AO Setpoint Rate Limiting Examples

If you are interested in learning more about this capability, then a model and detailed description of setpoint limiting can be found in the Fieldbus Foundation function block specification – Parts 1 & 2.

A buffet of techniques that is free to boot (Texas Talk) is available as an E-Book on my Control Insights website.

http://www.easydeltav.com/controlinsights/controltechniques/default.asp

While the title is Continuous Control Techniques for Distributed Control Systems, the techniques are applicable to batch processes and in fact were based in some cases on batch loops. It follows in the foot steps of my first free E-Book A Funny Thing Happened on the Way to the Control Room. While I emphasize technical detail more than humor in the latest E-Book, I still tried to present and conceptualize the techniques in a friendly and interesting way.

If you are a mature adult (e.g. old person) like me, you probably remember the days of analog computing modules and the fun and games of scaling potentiometer for engineering units and sorting through a maze of wiring. I can’t even talk about the days of pneumatic modules, bellows, links, and levers. Even with a broad line of computing modules such as lead-lags and signal characterizers besides the multiplier-dividers and summer-subtractors, you were “awfully limited”. I was going to say “pretty limited” but there was nothing pretty about the installation. One of the many problems with a total hardware solution was the design had to be frozen in time because of footprint, wiring, delivery, and installation requirements. Continuous improvement was difficult at best.

I was lucky enough to part of a beta test of one of the first distributed control systems that had a powerful set of functions some of which I wish I had in newer systems today. I spent the next 10 years exploiting as much as possible these functions in a series of challenging applications many of which are documented in the 2 E-Books and on this web site. I could go straight from conceptualization to implementation. The only limit was my imagination.

My next E-Book will be Biochemical Measurement and Control! No way! Way!

Enjoy.

When does feedforward control do more harm than good? Are there smart techniques to deal with these situations so feedforward is not permanently disabled in a PID controller?

If the feedforward correction arrives too soon, there can be an inverse response where the initial reaction seen in the controlled variable is in the opposite direction of the effect of the disturbance. This causes the feedback controller to make a move in the wrong direction. The solution is to add a delay to the feedforward signal so its correction arrives at the same time or a little bit later than the disturbance at a common point in the process. If the feedforward arrives way too late (after the feedback controller has returned the controlled variable back to set point), the feedforward creates a second disturbance. If the lateness is due to a lag in the feedforward path, a lead-lag can be added to the feedforward signal for dynamic compensation. If the lateness is due to a transportation delay or dead time in the feedforward path, the delay or dead time must be reduced by making changes to the process or the feedforward measurement choice or location.

Excessive feedforward measurement noise can show up as an increase in variability of the controlled variable. A simple fix is to add a filter to the feedforward signal with the filter time set to keep the fluctuations from the feedforward noise in the controller output within the resolution limit of the control valve. If the feedforward measurement is below its low rangeability limit, its signal can become bizarre. This is a common problem with flow measurements. The best solution is to use a better sensor and transmitter technology and scale range, but given you are stuck with the situation, the feedforward action can be programmatically turned off when too erratic. Sometimes flow controller set points instead of flow measurements are used to get around flow measurement noise and erratic behavior.

A more interesting problem is when unmeasured disturbances have caused a deviation in controlled variable that is in the same direction as the feedforward correction. Here a smarter technique would programmatically turn off the feedforward when its correction would make the existing control error worse. Next week I will propose some ways to predict this scenario.

It is important that the turning “off and on” of the feedforward action be bumpless, automatic, and tested. A dead band in the trigger for “off and on” is advisable. Finally, model predictive control inherently deals with many of these issues through its use of disturbance variables.

Maybe I have just been unlucky or maybe the plants I worked in were as stressed as the typical project schedule these days but often for column temperature, boiler level control, and neutralizer pH, feedforward control didn’t live up to expectations. The problem was abusive unmeasured disturbances. The feedforward signal is often flow, which doesn’t tell the whole story. If there were only flow disturbances, life sure would be simple.

Consider a distillation column with a feedforward of feed flow corrected by a tray temperature controller output that manipulates steam flow. For an increase in feed flow, the feedforward initiates an increase in steam. Seems great but what if the tray temperature is rising because of a change in feed concentration Adding steam adds to the rate of rise of temperature toward a possible product spec limit plus wasting steam.

Consider a boiler drum with a feedforward of steam flow corrected by a drum level controller that manipulates feed water flow. For an increase in steam flow, the feedforward initiates an increase in feed water flow. Technically sound but what if the drop in drum pressure causes a swell from the expansion of bubbles that is headed for the high drum level trip point set to prevent liquid carry over into the steam header. Adding hot feed water adds to rate of rise of level and the possibility of boiler shutdown.

Consider a neutralizer with a feedforward of acid waste flow corrected by a pH controller that manipulates a basic reagent flow. For an increase in waste flow, the feedforward initiates an increase in base flow. Seems smart but what if the pH is rising because of a decrease in acid concentration in the feed. Adding base adds to the rate of rise of pH toward a possible environmental limit plus wasting reagent.

A smart technique would preemptively correct the feedforward signal by subtracting a signal that is the rate of rise of the filtered rate limited controlled variable multiplied by an adjustable factor. Here, the correction for a positive rate of change only occurs when the controlled variable is above the set point plus some noise band. The correction for a negative rate of change only occurs when the controlled variable is below the set point minus some noise band. In each case, the feed forward is corrected to help deal with an unmeasured upset. If the controlled variable is near the set point, the controlled variable is lined out, or the unmeasured upset is driving the controlled variable back to set point, the feedforward correction is zero. The adjustable factor like the feed forward gain can be initialized based on first principles (e.g. material, component, and energy balances). Note that the above scenario is for a reverse controller and a direct feed forward action.

Concentration and temperature measurements of the feed may help make the feedforward signal calculation inherently smarter and reduce the number and size of unmeasured disturbances. But, there can be extenuating circumstances. For example, cold feed water would cause bubbles to collapse and the inverse response that might counteract steam flow induced shrink or swell. Also, a pH feedforward based on a pH measurement of the incoming waste may do more harm than good because the electrode error and failure rate in low or high pH streams is larger and error in reagent demand greater because the titration curve is flatter. Testing is always a must before putting even the best idea online.

In many of the plants I worked in the production capacity had been increased over the years by a series of debottlenecking projects. Unfortunately the surge tanks volumes were not increased probably because of a lack of understanding of dynamics. Consequently, unit operations upstream and downstream of the surge tank had to be decreased because of high and low levels, respectively. Also, abrupt changes in the surge tank’s discharge flow which are unavoidable as these level limits are approached were disruptive to nearly every type of unit operation.

If batch units or continuous units that are going up and down are dumping into a surge tank, you have a tough scenario to achieve both maximum availability of the surge volume and maximum smoothing of the outlet flow by feedback control alone. Notch gain and error squared level controllers can help but are difficult to tune. Also, low controller gains cause slow oscillations from reset action unless the reset time is also increased so that the product of the reset time and controller gain stays above a minimum. The fact that a low PI controller gain for an integrating process, such as level, can cause oscillations is not well recognized. For more details on this source of oscillations see the equation on page 109 of Good Tuning - A Pocket Guide (2nd Edition) and Equation 3-3j on page 81 of New Directions in Bioprocess Modeling and Control published by ISA. These equations are consistent once you consider the maximum integrating process gain is the inverse of the fastest full scale ramp time.

One solution is to add a velocity limited feedforward. For a surge tank level controller that manipulates the tank’s discharge flow, the total flow of all units that are dumping into surge tanks is a feedforward signal to set the discharge flow. If the flow engineering units are consistent and there is cascade control of level to discharge flow the feedforward gain is one. The big question is what is the velocity or rate limiting needed to spread the disturbance from batch and on-off operations over the available surge volume.

A material balance and dimensions of the tank can be used to compute the velocity or rate limit on a first principle basis. The attached file shows the calculation and implementation in a graphic representation of a Function Sequence Table (FST). Furthermore, the calculation offers continuous directional adaptation of the velocity or rate limit. The only adjustment is to set a filter time for the feedforward measurement that is equal to the normal time that the feedforward flow could be zero. For a single batch operation upstream, this time would be the batch cycle time plus the normal time between batches. For more info on this technique see Appendix B - Batch to Continuous Transition in Advanced Control Unleashed published by ISA.

BatchToContinuousTransition

One of the simplest and easiest techniques to evaluate and implement is set point feed forward. The maximum feedforward gain is the inverse of the process gain. You just need to make sure the process gain is converted to the same units used for the feedforward gain and only a fraction of the maximum is used as the actual feedforward gain to allow for nonlinearities, errors, and PID action. New adaptive controllers such as DeltaV Insight can find and schedule the process gains and hence the set point feedforward.

If the controller gain is large (> 1.0) and the controller structure has proportional action on error, set point feed forward has little value because there is already a sizeable step in controller output from a set point change. However, large dead times can cause low controller gains. Here, set point feedforward can get you to a set point much faster, which can be useful for loop set points driven by batch, cascade, or advanced control.