One day, the site’s dual-redundant controllers had enough. One of numerous pairs of controllers had been experiencing ever-decreasing “free time,” with creeping loop additions and the burden of a few iterations of manufacturer “point” upgrades. So the processor free time grew perilously low, until one day they stopped. Operators were staring at “@@@@” where measurements used to be, and no one was sure about the condition of millions of dollars of catalyst in a potentially exothermic, runaway reaction. This was a circumstance where their normally staid controls specialist uttered expletives that would have to be deleted.
The concept of solving control in smart field devices dates back to a day—circa 20 years ago—when built-for-purpose controllers were expensive. Control systems engineers stressed about scaling their design, so the process’s proportion of fast and slow loops could be solved in the fewest number of controllers. Smart devices capable of edge control afforded the idea that when you bought a transmitter and a control valve for a new loop, you were also buying the computing power and capability to solve that loop. It was scalability that happened without changing controller cards to increase processor speed and memory, and often without even adding another I/O card.
Controllers have a lot of other duties besides control. They’re populating the operator’s graphics with the latest measurement updates, passing values to historians and trend packages, and processing operator requests for mode changes and setpoint changes, along with the annunciating, acknowledging, shelving and other functions associated with alarms.
Controllers also have duties keeping current with variables passed from other controllers, and from remote I/O, wireless I/O and serial data coming in via Modbus, Profibus, DeviceNet or other serial protocols. And there’s a time slice associated with self-diagnosis and maintaining the readiness of its redundant companion: somehow it has to solve whether it’s time to tag out and hand over its duties to the standby redundant controller.
This churn goes on 24/7 and possibly for months or years between shutdowns. Oh yeah, we also expect the controller to process online changes and additions to the control scheme without disrupting the process or causing a bump. This is no email and Excel box where an occasional or daily lockup or reboot is taken in stride.
Prior to the spring of 2016, our site had one controller that had been completely devoted to processing serial Modbus I/O. A portion of this I/O was for indicate-only RTD and thermocouple measurements that were wired to a field network of multiplexer or “Mux” boxes. When the Mux vendor announced the platform we had employed for 16 years was in “sunset” status, we replaced 80% of the field network with Rosemount 848T multipoint fieldbus transmitters.
All the DCS had to do was scale the Modbus register integer to a temperature. It was uncomplicated, but it had to be done hundreds of times. With the replacement/upgrade of the Mux, all the analog inputs were relegated to the 848T multipoint temperature transmitter.
We weren’t sure if we’d see any impact on controller loading. The controller still had to pass a value for operator graphics, faceplates, alarming and historization, but no longer needed to do any scaling. Surprisingly, just offloading this simple task to devices and shifting communications from RS-485 Modbus to fieldbus increased that controller’s free time by 20%.
Aging, overloaded controllers, like the pair that froze up a dozen years ago, might get new life from edge control-capable fieldbus devices. Even redeploying simple function blocks has an observable impact, and the effect of solving increasingly complex function blocks like pressure and temperature compensation, signal selectors, averaging, and PID should be proportionately greater.