The Eye for Plant Operators' Eyes

Best Practices for Operator Interface Make Sure We See What We Need to See

Share Print Related RSS
This article was printed in CONTROL's August 2009 edition.

By Doug Rothenberg

The plant operator has an extremely valuable and important responsibility: managing the real-time performance of a capital enterprise easily worth hundreds of millions of dollars. We ask operators to shoulder the burden of everything that goes wrong during their watch, all without any recognition when nothing does, and precious little—and that mostly blame—when it goes wrong, and they manage to manage. Within their area of responsibility and authority, they must be able to view every control loop, most sensors, most pieces of equipment and most of the supporting utilities, and then adjust as appropriate.

The failure to maintain situational awareness has been present in almost every disaster event that was not the result of a spontaneous, complete surprise. No one wants an accident. But accidents and disasters happen. We now know to a high degree of certainty that they happen because those in charge of ensuring that they don't aren't aware of critical events as they are happening. They fail to know the situation. They are unaware of what is really going on, what is likely to happen, or what isn't happening that they think is. As pointed out in my forthcoming book, Alarm Management for Process Control, from Momentum Press, this situation can be significantly improved by good operator interface design.

Evolution of the Technology

The video display unit seemed to represent a significant step forward when it replaced panel boards. Actually, it was a step forward in technology and a step backward in operator support. But it was the evolution of displays, not their intrinsic faults or limitations, that led us down the wrong early paths. Once the faceplate barrier was broken, so to speak, the world of graphic design opened up. As soon as color made the scene, all of the process control system (PCS) manufacturers started a race to see who could use the most appealing and exciting colors to flash in front of prospective buyers. What was missing from all of this new technology was the the answer to the question of what the video display should do and how best to do it.

Physical Display Architecture

We know that more screens are as necessary as more information is displayed. Figure 1 shows a recommended architecture. There are enough screens so that most tasks, including monitoring, can be viewed at the same time without requiring switching displays on a screen, much like a panel wall. The locations are arranged so that related information is naturally located.

The choice of which resident displays to locate on which screens is made so that those requiring close interactions are center and lower. Note that in Figure 1 the two working screens (1 and 2) are located at the bottom center and right. Here is where the operator would be monitoring specific control points and related variables, or he or she may be intervening to manage an abnormal situation or other event, say by altering a controller setpoint or moving a valve. Close at hand (bottom row at left) would be other screens with advisories to assist the operator. For example, the screen could provide assistance as needed to augment the operator's current activities. This assistance would show procedures, provide relevant background analytical data, alarm diagnostic assistance data and the like.

The screens that provide more global information are located above. As a package, the displays on these screens complement the operator's role of observing and managing. At top left, would be the screen dedicated to the alarm system. The screen at top center provides overview information on how well the process is working. This aids the operator working to ensure the plant doesn't go astray. The operator may also be working on process improvements. The screen that supports improvements is located at upper right.

New Operator Screen Design

What you see here depicts a best practice for graphical operator screens. It was developed based on the work of the authors listed in the sidebar, "More About HMI Best Practices."  Note that color is used only for information—to point out the unusual or abnormal.

  1. Shaded grays are used to delineate the operator's arena of responsibility.
  2. Contextualized icons focus on what's normal and what's not.
  3. A hierarchy of view provides
          a. Critical information only at overview,
          b. Robust details and causality at the secondary view(s),
          c. Support and guidance at the tertiary view(s).

Consequently, what the operator now gets is a powerful tool that focuses attention and encourages efficient navigation to what's he or she needs to see and attend to without the overhead of "clicking to oblivion" that we always find in conventional personal software.

 

It's All About the Bars
In the 1970s, VideoSpec from Foxboro used deviation diagrams to illustrate complex, interrelated situations. These diagrams consist of a series of bars representing production steps, process sequences or the processing order of the plant, from material (or energy) entry into the operator area to exit. The height of each bar shows how far away it is from a proper target—the expected value of the particular attribute needed for long-term, effective production. The beauty of such a display is that, even if this is the first time you have seen one, you can easily spot abnormalities anywhere and everywhere in the plant. For more on how deviation diagrams work, go to the extended version of this story at www.controlglobal.com/0908_HMI_DevDiag.html.

 

Coding Schemes and Icons

Icons are powerful codes meant to be in-your-face obvious. This is the stuff that speeds up understanding and minimizes confusion. Icons both evoke a meaning and confirm that what is evoked is correct. While it might seem to be redundant, such redundancy is important.

Icons are more than placeholders and announcers of warnings. They also communicate status. Take icons like the thermometer-like icon shown in Figure 2. We call these context icons. They serve as indicator measurements of normalcy or pending abnormal operation. Looking at the left icon in the figure, note that all that is visible is the shape (a temperature), a range (the white vertical box) and the current measurement (the blue bar about halfway up the range). The displayed temperature is within its normal range. In the right icon, our temperature is abnormal. It is clearly too high. First, the normal range box now has all of its abnormal areas identified, from slightly abnormal to grossly so. We see that the current value, again a simple blue bar, is in a red area. Red means trouble. Something is clearly wrong here.  To reinforce this message, the current actual value is displayed against a red background. It all suggests abnormal.

Overview Level

Now, let's put all these elements together. Illustrated in Figure 3 is a best-practice overview level display. Notice that all of the process elements are represented by neutral gray. This is what we expect. Process elements are placeholders. They're only there to show causal relationships and where things are okay or not. Arrangement conveys causality. Color is used for information only. Okay, there is the legacy video inset for the flare camera! It always needs to be in view.

Note the selection of key input variables at the left margin. These are "produced" by others at the enterprise. While not clearly depicted, the graphs of each input variable are contextualized in a manner similar to the icons. Their degree of normalcy significantly affects the production within our operator's area.

Next, we see the entire operator area of responsibility laid out with all key internal variables identified by context-bearing icons. Anything wrong will easily show up. Finally, observe the key product variables at the right margin. If these are okay and the process is okay, there should be confidence that the enterprise is okay. Where things are not, they show up directly and clearly.

 

More about HMI Best Practices
Corbett, D. Legg. Man Machine Interface. Litwin Process Automation, Houston, Texas, 1990.
"Effective Operator Display Guidelines," ASM Consortium, http://www.asmdashboard.com/, 2002.
Hollifield, B., D. Oliver, I. Nimmo and E. Habibi. The High Performance HMI Handbook. PAS. http://www.pas.com/. Houston Tex., 2008
"Human Machine Interface." NAMUR Standard AK 2.9. www.namur.de/ Potsdam, Germany.
"Process Plant Control Desks Utilising Human-Computer Interfaces–A Guide to Design, Operational and Human Interface Issues." Engineering Equipment Materials Users' Association (EEMUA) Publication 201. www.eemua.co.uk/ London, 2002.

 

Do ASM-Style Displays Work?

Sound like good ideas? Luckily, tragic incidents happen rarely, so very few plants that have employed the new designs have had one. With the new design, they are even less likely to see one at all. So we don't have actual case histories to demonstrate this. As a surrogate, carefully designed simulations were prepared and experienced operators used to work them. (See Errington, Jamie and Peter Bullemer, "Advanced Operator Interface," Human Centered Solutions, http://applyhcs.com/: 2008.)

The overall statistics from this test are very encouraging. In general, those using the ASM type displays were twice as fast in managing and almost 40% again more accurate. Even more revealing, those using the ASM displays were four times faster at early event detection.

By combining good human-factors engineering and years of experience with graphic displays, we've made significant strides forward from the big steps backward we made when we abandoned the panel wall. The plant operator gets the tools needed to do the job. 

Dr. Rothenberg is principal of D-Roth Inc., www.d-roth.com, a subject matter expert in alarm management and operator interface development.

 

A Good Content and Design Example
A very good example of the ability to observe and understand complex interrelated situations can be illustrated by a deviation diagram, developed by the Foxboro Company for a product called VideoSpec. (See Figure 4, below). The order of the bars reflects the major production steps, process sequences, or processing order of the plant from material (or energy) entry into the operator area to exit. Time does not appear anywhere on the diagram.
Deviation Diagram
Figure 4
The diagram is a representational construct of the whole of a plant and its relationship within itself and to its operational goals. It is constructed by first listing the major plant processed entities from entry at battery limits (from outside or another portion of the plant) to exit from battery limits. Adjacent bars mean that the entities they represent are functionally (if not physically) closely related in their processing steps. A bar to the left of another bar means that the one before comes before the one after in the normal "flow" of production. For each bar, the height shows how far away it is from a proper target. A "target" is not normally the related controller setpoint. Rather, the target represents the expected value of the particular attribute needed for long-term effective production. Right on target would be a bar of zero height. Values higher than target would be a bar height above zero, values below target would be a bar below zero.
Now we get to the part about what the diagram is intended to illustrate. Even if this is the first time ever looking at one, you can easily spot anywhere and everywhere there is abnormality in the plant. A single or isolated strongly deviating bar (at position 5 for example) means that something is clearly is "wrong," but its effect is strictly localized, for example, a failing transmitter that is not a part of a control loop. Groups of noticeably deviating bars (at positions 25 through 29 in our example) suggest that a broader area of the process is abnormal.
With a glance, the observer has a broad overview of the entire process, and if a good job was done selecting the variables to display, a good understanding of the overall process. It is a simple, yet powerful, visual agent! It's only one of many.

 

Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments