Some years ago, there was a process plant where a fired heater had to undergo extensive repairs after being damaged by excessively high temperatures. The subsequent investigation revealed that the host controller had failed. It had ceased executing control algorithms and updating the I/O.
The problem arose because all of the controller's conventional analog I/O cards had been set to "hold last value" when communications ceased. Since they hadn't lost power, they did just that, including the outputs wired to the heater's fuel control valves, whose last position was enough to overheat the furnace before the problem could be addressed.
Nowadays, we're usually required to provide "independent protection layers" when a basic control system malfunction can initiate a hazardous condition. When it's the root cause, one can't take any credit for the basic controls as a "protection layer." But some engineers wonder, why invoke a demand on the safety instrumented system (SIS) if the DCS can be configured to prevent it? In the conventional/analog world, we might configure our I/O to fail to the "no power" state, which in turn would drive actuated valves to their "fail" positions. The plant or unit still shuts down, but we avoid a demand on the SIS.
It's unlikely this "safeguard" can reduce the required SIL. And, the choice one would make for optimizing robustness—hold last position—arguably only results in a hazardous condition in one-third of the scenarios. That is, the process could stay put—maintain steady state—or equally likely drift further from the trip setpoints. So what if two-thirds of the time we trip for no reason? Have we designed a safer plant, or is tripping the plant unnecessarily creating more hazards than we were aiming to prevent?
Read Also: They'll Make a Better Software Fool
When I posed the problem to consultant, author and certified ISA 84 SIS expert Ed Marszal, president of Kenexis Consulting, he commented, "Personally, I would set all controllers to hold the last valid output value. This will minimize disruptions to the plant to only situations where there is an actual demand. Overall, this should be the safest and most cost-effective approach."
Unnecessary trips send our processes into the ditch when no hazard is impending. We may tell ourselves "it's fail-safe," but sudden shutdowns and the ensuing start-ups create increased and uncommon stresses on personnel and equipment, and the less-practiced procedures produce greater risks for error and injury.
If I vent the steam system at the height of winter, maybe I've avoided lifting a safety valve. But when the crew is out for a week thawing the plant out, their question will be, "This is safer for who?" We have to weigh whether any fail-safe "feature" results in a verifiably safer facility, and not mechanically default to what on the surface appears to be a "conservative" choice.
Foundtion fieldbus function blocks are part of our basic control system, and our basic controls should prevent demands on the SIS by precise and robust control, not by trying to be "SIS Lite."
So when we're exploiting the parameters fieldbus function blocks provide to configure fail-safe behaviors, we should do so selectively and judiciously. Chances are, a stable plant where spurious trips are rare is safer than one that's routinely requiring a winch to get it out of the weeds and back on the road.
