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

Make Effortless HMI and PLC Modifications from Anywhere

The tiny EZminiWiFi is a godsend for the plant maintenance engineers who need to make a minor modification to the HMI program or, for that matter, the PLC program. It's very easy...

The Benefits of Using American-Made Automation Products

Discover the benefits of American-made automation products, including stable pricing, faster delivery, and innovative features tailored to real-world applications. With superior...

50 Years of Automation Innovation and What to Expect Next

Over the past 50 years, the automation technology landscape has changed dramatically, but many of the underlying industry needs remain unchanged. To learn more about what’s changed...

Manufacturing Marvels Highlights Why EZAutomation Is a Force to Be Reckoned With

Watch EZAutomation's recent feature on the popular FOX Network series "Manufacturing Marvels" and discover what makes them a force to be reckoned with in industrial automation...