Using Fieldbus in your HMI

Fieldbus brings an enormous amount of new information into the host system. Most of the time, we think in terms of its usefulness in asset (I&C) management and instrument/device diagnostics. But some of the new information available through digitally integrated field devices is useful to your operators who are managing the process 24/7.

It is important to have an idea of what variables those might be before embarking on a large project. What comes “canned” from your systems vendor or HMI supplier may be too much of “all things for all people.” For example, the stock faceplate for my DCS layers the same piece of data a half-dozen times, each with the decimal point in a different place, and turns on visibility based on the “decimal point” attribute of that piece of data. We chose to do without that query (where’s the decimal point?) entirely, and show all PID outputs to one significant figure (xxx.x). This saves a little processing time and allows us to choose a more interesting piece of data to bring in.

One piece of data your operators are almost sure to like, is the “readback” value of a control valve’s AO block. This represents the actual position of the valve stem (0%-100%, to as many decimal places as you like) as seen by the valve’s smart positioner. We show this value for every fieldbus or HART-capable control valve in the plant.
We show the “requested” position (the output of the PID block) as well as the “actual” position on controller faceplates. This makes it easy for operators to spot a sticky or sluggish valve or overzealous positioner tuning. Many times, an operator wants to make fine adjustments, and this “readback” signal lets her see if a move of a few tenths of a percent actually translates to valve steam movement.

You can use the option “Use PV for BKCAL_OUT” in Foundation fieldbus AO blocks, which makes the sensed stem position a “published” or deterministic variable.

Every Foundation fieldbus function block and transducer block has a “mode,” which must be set correctly for a loop or even an indication to function, and every block mode has an attributes “target” (where someone/something asked the block to be) as well as an “actual” (the mode it’s “actually” in). If all is well, blocks go to their target mode within a scan.

In most transducer blocks, the “manual” or out-of-service mode will result in the associated function block going to “IMAN” or “Initialization Manual.” In the case of an input, this might cause its AI (analog input) to stay in “OOS” or out-of-service, and the PID function block to be stuck in manual. An output block or “AO” mode of anything but “cascade” will cause its upstream PID also to go to “IMAN.” For this reason, we equip fieldbus controller faceplates with an alert that says, “check target mode” whenever the “actual” mode is stuck somewhere other than the “target” set by the operator.

It may not take much effort to set up one’s subpictures to display the main categories of “uncertain” and “bad.” We do this for variables coming from FF devices and default to a “blank” status indication if the measurement status is “good.” There is a great deal of “granularity” in the status message, and distilling that information can be worthwhile. For example, some transmitters set the measurement status to a specific “uncertain” status if they have detected a plugged impulse line.

Finally, some innovative end users have figured out how to depict all their fieldbus segments on HMI graphics, and display some of the key measurements (e.g., case temperature) and communication statistics in real time. In this way, they have done away with “paper” loop diagrams. The graphics are useful to the instrument tech who can easily see what other devices are on a given segment, or to  operators when they have concerns about the “health” of a segment.

Email me if you’ve found some cool and useful fieldbus data to help your operators.