66df137a492640077baaa9e3 Shutterstock 1423704578

A complex DCS quandary

Sept. 9, 2024
How PID loops were enhanced, and why it’s beneficial but confusing

Running on refinery fuel gas, the temperature control loop for a fired heater needed to react to dramatic changes in BTU value (the heating value of fuel) as the plant started up. The hydrocarbons in the mix drum varied from near-natural gas to fuel gas that was rich in higher BTU fuels, including ethane, propane and hydrogen. Such was the case when a particular control loop nearly burnt its fired heater.

When the measured temperature went off-scale high, the controller was supposed to automatically switch to “shed mode,” which was the default behavior of the distributed control systems (DCS) proportional-integral derivative (PID) control block. In the busy startup, no one noticed the controller mode had gone to “manual” and was holding its last output—enough fuel to keep the temperature rising.

Get your subscription to Control's tri-weekly newsletter.

The PID loop of the everyday bona fide DCS has been enhanced over the years, largely at the behest of large process plant end-users, who desire options such as setpoint tracking in manual mode and bumpless transfer for cascade loops. One of these enhancements is mode shedding. Users don’t want their loops to react to a detectably bad feedback signal. If the thermocouple failed and the 4-20 mA (milliamp) transmitter pegged upscale, they don’t necessarily want the PID to dramatically cut the fuel off. For such analog signals, some percentage above 20 mA or below 4 mA is interpreted as bad, and the PID option can be set to shed mode—degrade to manual—If such a condition is detected. It’s a viable strategy, especially if you seek to protect operations from upsets caused by faulty instruments.

It's the law of unintended consequences, revisited. A sagacious process supervisor told a newly minted chemical engineer that whatever improvement he was making will have another probably unforeseen negative consequence. “No good deed goes unpunished,” one might also say. So it is, when we add numerous options and settings to a microprocessor-based algorithm. They all have a purpose, probably a virtuous one, but if you don’t know why and where, you might not even find them until after the fact.

Having been around for early iterations of fieldbus function blocks, I recall a time where a measurement would increase beyond its configured full scale and continue reading—accurately—until the sensor or the transmitter reached its physical limits. It was a tremendous benefit for start-ups and scale-ups, where process folks might guess wrong about the likely span of a flow or pressure, for example. But somehow, somewhere, the suggestion took root that exceeding the configured full scale should flag the reading as uncertain—even though there is nothing uncertain about it. You could still rely on the signal to be flagged bad if the transmitter or sensor full scale was reached. I think lawyers or insurance people were to blame.

What didn’t change was an option in the PID block to “use uncertain as good,” which is unchecked by default. So now, by default, PID blocks shed mode to manual whenever full scale (or zero scale) is exceeded. If you exchange a 1999-vintage device for a 2024 model, you should ensure that box is checked.

In the early days of this technology, all engineers who wanted such features were engaged and present for factory acceptance tests, commissioning and startups. They knew about the clever tweaks in the blockware, and might be on hand if one setting or another caused some befuddling behavior. Whoever is left after those veterans move on or retire is often stuck with befuddling behavior with no clear remedy. DCS support roles fall to non-process disciplines like network specialists and active domain administrators. These are valuable skills and roles, but how many know the purpose or even existence of a setting such as “use uncertain as good”? Arguably, it doesn’t sound logical but is desirable, especially when the controller variable is coming to the system as a digitally integrated “real” number.

In our digital world, we should employ all the power at our command to ensure safety, stability and reliability of controls. However, everyone clicking a mouse should be trained in all the options, including all the gotcha moments that will someday arise.

About the Author

John Rezabek | Contributing Editor

John Rezabek is a contributing editor to Control

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.