Features Opinion
All about control: Process control and Control in the Field

Original pneumatic process control loops were implemented with Control in the Field. In those days, the analog input (transmitter) and output (valve) needed to be connected by the air line sharing the 3-15 psi signal calibrated to the transmitter signal. As indicated in past columns, Foundation Fieldbus – with its function blocks – has been designed to be able to implement Control in the Field with the constraint that, like pneumatic loops, the input (AI block) and output (AO block) must be on the same physical segment. In effect, the pneumatic air line has to be replaced with the fieldbus segment wire.

Once you have designed your segment to make Control in the Field possible, and you are ready to implement, it’s time to create the necessary associations between the required function blocks and download this to the affected devices. The process of selecting and downloading these blocks is called “configuration.”

As the name function block implies, Foundation Fieldbus was designed from the beginning to enable a wide range of control functions/functionality. To date, a total of 34 different function blocks have been defined with the most common implementations using input blocks, output blocks and the PID block to enable closed-loop regulatory control. Figure 1 shows how these three blocks can be combined to implement a cascade control loop in the field with three devices and minimal use of the Host (Fieldbus terminology for control system), other than to present the data to the operator and as a way to change the process set point.

The blue lines in Figure 1 represent the fast or slave loop, while the black lines show the relationships between the slow/master loop and the slave loop. Dashed lines represent function block links within a device that, therefore, do not require time or bandwidth on the Foundation Fieldbus H1 network. Solid lines require use of the deterministic or scheduled communications component of the protocol for reliable, repeatable control. The deterministic communications will always happen within 1/32,000 of a second resolution.

Communications between function blocks happen as follows:

• The output (OUT parameter) of the analog input block publishes the PV (process variable) to the PID (proportional integral derivative) function block to the IN (input) parameter.

• The PID block then takes the PV reading, compares it against the set point and then calculates the amount of change required for the MV (manipulated parameter) and sends that information to the AO (analog output) function block as a CAS_IN (cascade input) parameter.

• The CAS_IN parameter is then used to drive the valve to its new position.

• Once the change in output has been made, the AO function block updates BKCAL_OUT (back calculation output parameter) and sends the back to the PID function block to confirm the actual position of the valve for the next PID calculation, while also having the benefit of preventing the PID algorithm from going into “windup.” (Windup is when a control algorithm instructs an output device to continue to open or close when it is already fully open or closed. If this condition is not identified by the PID loop, it can become saturated, leading to unstable control.)

• The master or slow loop in the cascade control scheme is contained in the transmitter measuring the associated master loop PV. The links between the AI and PID function blocks are the same as for the fast/slave loop; though this time the communication between these two function blocks is an internal link.

• The output from the master loop is the set point for the slave loop and, hence, is read from the CAS_IN parameter of the associated PID function block. Once again, the PID function block (as the output block of the master loop) needs to inform the AI device of the BKCALC_OUT value to prevent windup.

Control can be executed in the Host, and for more complex control strategies, fieldbus function blocks are not able to perform the necessary calculations. Of course, if the necessary signals are not from the same segment, field-based control is not an option. Unit optimization routines, multivariate calculations and neural or other complex calculations are not suitable for Control in the Field, in part because function blocks do not exist but, more importantly, because of the volume of data and processing power required.

Control in the Field is not the solution or an option for every control loop; however, when feasible, it is a viable way to make effective use of your control system resources by taking a load off of your central controllers and reducing network traffic with no negative impact on your ability to control the process.

I have had many people tell me that they will not implement Control in the Field because they wonder how they will be able to control the process should something happen to the control valve. I simply ask them, “If your control valve is not working well enough to control the process, what are you using to control the process?”

Function blocks are a key differentiating Foundation Fieldbus technology, which, when combined with deterministic communications, make reliable process control possible in the field. Yes, Control in the Field over wire is relatively new, but the concept itself has been around for more than 50 years. And just like the clothes in our closets, everything old becomes new again.

This column originally appeared in the January/February 2012 issue of Manufacturing AUTOMATION.