Stan: November's column with George Buckbee, "How to Get the Most Out of Your Software for Loop Tuning" (November 2013), gave a good introduction to loop performance that set us up for the next step: How do we get from loop control performance to process economic performance? Today more than ever, we just can't make things look better. We have to show the impact on the bottom line. Unless automation engineers show the financial gain from process control improvements, this activity will never achieve its potential or get recognition for the value it delivers.
Further, quantifying the effect of better control on plant profitability lets us focus attention on the most important improvements–those that return the biggest benefits.The recognition gained is critical to support for further individual efforts and revitalizing our profession.
Greg: Lewis Gordon, a principal control systems engineer retired from Invensys after 38 years of experience, has submitted some comments on improving loop performance to increase plant profitability. Lew specialized in control applications design, tuning and loop performance monitoring software (ExperTune's PlantTriage). Here are Lew's comments on the column with Buckbee and more details from a subsequent conversation.
Lew: George is absolutely right in saying that improving loop performance is about more than tuning. He mentioned some specific examples, including loops in manual, root causes, interaction, stiction, backlash and faulty instrumentation and/or actuators.
In the case of controllers in manual, this is sometimes not a significant issue. A controller may be in manual simply because it has become obsolete (out of service) or because the current process operating mode does not require it. Certainly a controller that is always in manual is wasting the cost of its installation, as the column makes clear. But installation is a one-time, sunk cost—water under the bridge. As George says, the important questions are why is it in manual now, and what will be the benefit of getting it into auto.
The first issue is where transferring a controller into auto triggers an expanding oscillation, forcing a return to manual, even if only under certain operating conditions. This usually happens because the tuning is so tight that the loop is unstable with the controller in auto. But it is also possible for each of two reciprocally interacting controllers to be stable so long as only one is in auto, but for both to cycle when they are in auto at the same time. Both of these situations do happen, but not often. More significant for the long term are those loops that do not control well enough during process upsets. Often, on difficult-to-control loops, the controllers are in auto, but tuned sluggishly to keep the loop stable under most operating conditions and hold steady state in the absence of upsets. Then manual/operator control is used to handle occasional upsets. So two revealing metrics are the frequency of auto/manual transfers and the frequency of output changes in manual, which most loop performance software also tracks.
Stan: I like the idea of metrics on how often a controller is switched to manual and how often the output is changed. If the output of a controller in manual is not being adjusted by the operator, closed-loop control is probably not that important.
Lew: In either case, retuning such loops can improve control performance, especially during an upset, and reduce operator load. Nevertheless, this improvement is unlikely to have significant economic benefit without changes to the average operating point.
The other examples mentioned certainly exist, and when they are found and corrected, the benefits will be very welcome. Backlash and stiction are almost pervasive. They cause oscillation too, but these situations can be distinguished from gain-driven oscillations because the oscillations they cause are self-limiting. If the deadband and stick-slip are less than 1%, the limit cycle may be more of a nuisance than a significant economic problem (unless they affect one of the variables mentioned in the next paragraph). They do create a maintenance issue because of the associated wear and tear on the valve; however, such cases can go on for months and even years without being addressed because their economic and operational impacts are not large enough to demand a solution. Similarly, instances of faulty instrumentation that have significant effects such as George describes provide surprising and dramatic improvements. However, they are usually singular situations—not really part of a long-term continuous improvement concept, except as gateway events.