A complex DCS dilemma | Control Global

Operating on refinery fuel gas, the temperature control loop for a fired furnace had to respond to drastic changes in BTU (heating value of the fuel) during plant start-up. The hydrocarbons in the blender tank varied from near natural gas to fuel gas rich in higher BTU fuels, including ethane, propane and hydrogen. This was the case when a particular control loop nearly burned its fired furnace.

When the measured temperature exceeded the measurement range, the controller was supposed to automatically switch to “shed mode,” which was the default behavior of the distributed control system (DCS) proportional-integral-derivative (PID) control block. During the busy start, no one noticed that the controller mode had switched to “manual” and was maintaining its last output – enough fuel to keep the temperature rising.

The PID loop of everyday, real DCS has been improved over the years, largely at the behest of large process plant end users who want options such as setpoint tracking in manual mode and bumpless transfer for cascade loops. One of these improvements is mode shutdown. Users don't want their loops to react to a detectably bad feedback signal. If the thermocouple has failed and the 4-20 mA (milliampere) transmitter is high-regulated, they don't necessarily want the PID to drastically shut off the fuel supply. With such analog signals, some percentage above 20 mA or below 4 mA is interpreted as bad, and the PID option can be set to shutdown mode—downgrade to manual—when such a condition is detected. This is a viable strategy, especially if you want to protect operations from interference from faulty instruments.

It's the law of unintended consequences, revisited. A wise process manager told a newly minted chemical engineer that every improvement he made would have another, probably unforeseen, negative consequence. “No good deed goes unpunished,” you might say. This is also the case when we add numerous options and settings to a microprocessor-based algorithm. They all have a purpose, probably a good one, but if you don't know why and where, you may not discover them until after the fact.

Having been around for the first iterations of fieldbus function blocks, I remember a time when a measurement would go beyond its configured full scale value and the measurement would continue – exactly – until the sensor or transmitter reached its physical limits. This was a huge advantage for start-ups and scale-ups where process people could misjudge the likely range of a flow or pressure, for example. But somehow, somewhere, the idea took hold that exceeding the configured full scale value should flag the measurement as uncertain – even though there was nothing uncertain about it. You could still rely on the signal being flagged as erroneous when the transmitter or sensor reached its full scale value. I think lawyers or insurance people were to blame.

What hasn't changed is an option in the PID block, “Use Unsafe as Good,” which is disabled by default. So PID blocks now default to manual mode when full scale (or zero scale) is exceeded. If you're swapping out a 1999 device for a 2024 model, you'll want to make sure this box is checked.

In the early days of this technology, all the engineers who wanted such features were dedicated and present at factory acceptance testing, commissioning, and launches. They knew the clever optimizations in the blockware and might be on hand if one setting or another caused confusing behavior. Whoever is left after these veterans move on or retire is often stuck with confusing behavior for which there is no clear solution. 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 like “use uncertain as good”? While it doesn't sound logical, it is desirable, especially if the controller variable enters the system as a digitally integrated “real” number.

In our digital world, we should use all the means at our disposal to ensure the safety, stability and reliability of controls. However, everyone who clicks a mouse should be trained in all options, including all the pitfalls that will eventually arise.