I recently came upon a couple of documents discussing control in field devices, one by Dick Caro (CMC Associates and founding member of the ISA SP50.02 standards committee), and another in the specifications of a major oil company. Both authors estimated that up to 80% of control loops should be solved in field devices.
The plant where I work has been solving about that percentage—roughly 80%—of its closed-loop PID in field devices since the days of Interoperability Test Kit 3—about eight years and counting. During that time, not a single loop has been moved back into the controller, and the plant, which makes industrial intermediates, is more productive and reliable than ever.
If you’re using Foundation fieldbus-capable (FF) field devices, exploiting control in field devices is, at minimum, a “no increased risk” choice, and even a lower-risk choice than control in the host. How so?
Users worry about what happens to the control loop when the field device fails, or gets “sick.” Won’t that loop go to a fault or upset condition? Ironically, the consequences of a device fault with a legacy host are precisely that: With no intelligence, signal status or diagnostic from the field device, the loop goes quickly into the weeds. If the fault happens to be in the final control element, then an upset of some kind would also likely ensue.
In the case of the final element, a field-based loop is certainly no worse. When the loop’s valve positioner decides it needs a nap or just loses power, the loop will experience an upset no matter where the PID is solved. In the former case, the fieldbus loop will fare better. The FF-tested-and-certified PID block is preconfigured to deal with “trouble” on the input side. If that signal goes to “bad, no communications,” the PID will shed to “manual” and hold the last output. If it goes “bad, sensor failure,” it will do the same. Many, if not most, measurement issues are diagnosed and applied to the “status” of the transmitted signal, and all fieldbus PID blocks react in precisely the same way. As a result, the likelihood of a serious process upset is greatly diminished.
A modern DCS equipped to use the diagnostics and signal statuses of FF devices can be expected to be nearly, if not equally, fault-tolerant. So why locate PID to the field?
“Virtual communication relationships” (VCRs) is one reason. This is a component of the chain of publish-and-subscribe deterministic communications that ensures precisely timed control execution. When the DCS is in the loop, at least one additional VCR is needed per loop. This increases the load on the fieldbus link master, and risks exceeding the limit of a given H1 interface card’s capability. Fewer VCRs also means more devices can be accommodated on a given segment.
There are also potential issues with DCS controller cycle times, which typically aren’t made to run in lockstep with each fieldbus segment’s link master. A fieldbus host system can have hundreds of segments, all with different macrocycle times, so a host-based controller needs to either run much slower than the H1 macrocycle or risk unknown latencies. This means loops can’t be tuned as tightly, diminishing the plant’s ability to run close to constraints.
Many users see value in single-loop integrity. I’ve completely pulled Honeywell’s Experion Fieldbus Interface Modules (FIMs) from their card cage. Field-based control went on without a hiccup, and all returned to normal when the cards were re-installed. This is also true of other hosts that support control in field devices.
Finally, if you have an investment in intelligent field devices that can handle 80% of the control in your plant, why put the entire burden on your host? While control capability and capacity are cheaper than they were in the decade when SP50 and FF were conceived, there is still a cost. Users should let hosts churn away at the more demanding advanced control and optimization, and leave the day-to-day, garden-variety PID to the field devices.
