By John Rezabek, Contributing Editor
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 (wheres 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 valves 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 valves 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 its 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 ones 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.