Check out ControlGlobal.com on Google+
Back in the 1990s, when ISA's SP50 committee was meeting to debate the specifications and features that would become part of the evolving fieldbus digital communication standard, the idea of field devices solving function blocks was adopted. Devices would not just measure something and make a process variable available to a host, or translate an analog output to a valve stem position, they would have the (largely optional) capability to support and solve a whole repertoire of standard function blocks.A function block is an object, a small "app," that performs a very specific duty, with a specified set of inputs, outputs and internal configuration parameters. An analog input block, or "AI," performs the basic I/O chores of translating a raw measurement, say a differential pressure, into a meaningful process variable in engineering units. It has a menu of linearization choices that includes square root extraction and some innate alarming capabilities.
Most of this was nothing new. What was new was that devices became "autonomous"—capable of accepting inputs, solving their blockware and publishing an output—without being poked or polled by a centralized host. They can communicate with other devices and with the host as peers, and are even capable of solving PID for closed-loop control.
[pullquote]The end users who desired this capability were people with process control or a DCS focus, and they saw a move to an entirely vendor-independent, digital, distributed and deterministic control platform as a logical evolution of the systems of that day.
Today, there are still a lot of folks who use fieldbus for I/O only. But, many of the process control specialists who experimented with fieldbus-solved PID have caught on to the vision of the architects of SP50—that fieldbus would become a more robust, truly distributed and innately more reliable platform for rudimentary PID loops. In growing numbers, users are deploying fieldbus, employing this long-dormant capability to not only have fully digital I/O, but also a fully digital and distributed control system, vendor-neutral and independent of the host. Many systems people may never land a wire or lay their hands on a positioner or buy a transmitter, but they realize that the reliability of their control schemes hinges on these devices, no matter where PID is solved. And, if one can also solve PID with improved determinism, speed and integrity, there's nothing to lose and much to gain by exploiting it.
But there will always remain many loops for which control in the field (CIF) isn't an option. Fitting compressor speed controls or complex schemes requiring nonlinear controls, adaptive gain scheduling or complex cascades into the relatively generic repertoire of fieldbus function blocks might be a struggle.
If you're leading a project, you'd like a simple and straightforward bit of guidance to help your consultant/EPC easily choose the logical applications for CIF or control in the host, such as:
- Whenever the output of a PID block is configured to be wired directly to the AO block of a valve, CIF shall be the default choice for solving PID. The PID should be executed in the positioner, allowing the operator to run the block and, hence, the valve in "manual," even when all the other devices in the loop are being serviced.
- HMI faceplates shall use the output of the loop's AI block to display the measured variable, so it remains a live value even when the positioner is being replaced. The device measuring the variable controlled by the PID shall always be on the same segment.
- The remaining loops—cascade masters, for example—may be configured to run in the host with little loss of performance. Any output being controlled by 4-20 mA—for example, most variable-frequency drives—also are sensible choices for being solved in the host.
Exploiting control in the field is never an all-or-nothing proposition. A couple simple guidelines can be employed to help ensure your projects have a logical basis for their application.
