High-performance HMIs: Designs to improve operator effectiveness
Users and system designers consider how changing HMI strategy can help make operators better at their job and reduce those confused phone calls.
Editor’s note: This article contains excerpts from a panel discussion held at an ISA Symposium in Houston, October 7, 2014. The symposium chair for the chemical and petroleum industries division (ChemPID) was Chad Harper, senior director of technology at Maverick Technologies. This edited transcript is provided with permission of ISA.
Jeff England – Corporate controls technologist at Marathon Petroleum Company, LP. He has 27 years of experience in automation and has overseen several major HP-HMI implementations.
Bridget Fitzpatrick – Practice lead for HMI, abnormal condition management, and human factors engineering at Wood Group Mustang, and a member of the ISA101 committee.
Bill Hollifield – Principal consultant on HP-HMI at PAS. He is co-author of the High-Performance HMI Handbook, and a member of the ISA-101 committee.
George Robertson – Senior facilities engineer at Chevron with 30 years in the petroleum industry and has recently completed successful HP-HMI projects in the upstream industry.
Moderator: Justin Robinson - Principal engineer and high-performance HMI Subject Matter Expert at Maverick Technologies.
Moderator: What do we mean when we talk about HP (high-performance) HMI?
Robertson: Good HP-human machine interface (HMI) practices keep the operators' situational awareness at a high level, so when a situation occurs, they can actually see what's going on, without hunting through a lot of irrelevant stuff.
England: Real estate people say everything depends on location, location, location. A good human-machine interface (HMI) is all about content, content, content. It's about making sure you invest time and energy to get the right content at the right layer to make it appropriate for the end user.
Fitzpatrick: People seem to get caught up in some basic design details, like colors and form factor, which to me, is just a good HMI. What steps you up into the high-performance category is getting the right information to the right person.
Hollifield: I think it's about showing useable information on the screen, as opposed to raw data. It's about getting away from believing a complex piping and instrumentation drawings (P&ID) on a screen covered with numbers is a good way to represent a process to the operator for maximum situational awareness. But when the discussion comes up, most people think HP-HMI is where you take all the color out and make everything gray-scale. That's not accurate. It's about using color effectively, not getting rid of it.
Moderator: Like you say, color always seems to be a major part of the discussion. What role does it play in display design? Are gray-scale graphics best? What about background colors?
Fitzpatrick: It's a key misconception: Things have to be gray-scale to be high performance. The real discussion is about getting the right contrast so operators can see things easily in natural lighting, and then using color to add meaning and emphasis.
Robertson: Studies have shown that when you have bright, high-contrast objects, they're going to draw your eye and make it harder to find what you are looking for. The use of color and gray-scale graphics is just a tool to keep situational awareness high, and make it easier to identify the things operators need to be worried about right now.
England: I'll take a different twist on the gray-scale part. From my perspective, what we've lost trying to implement ASM guidelines in HP-HMI designs is the human factor issue of fatigue management. Look at ISO standards for lighting and contrast in work environments, and dim lights are not part of the picture. Don't forget, we're actually trying to change the environment. You can improve the effect of lighting in the control room with a good set of screen backgrounds to reduce eye fatigue.
Hollifield: Remember, we started down this path in the early '90s with low-frequency cathode ray tubes (CRTs), which were only capable of black backgrounds with bright saturated colors on top of them. Showing that on a glass CRT creates the worst possible combination to increase glare and reflection problems. So to solve a specific technological limitation, we brought the lights down in control rooms, which got us on this path of black backgrounds and bright colors. We stayed on that path for years and years because of inertia. But if you want operators to be alert at 3:00 a.m., a control room should be brighter than the typical office. Fortunately, now we have high-frequency LCD screens capable of much better schemes, and are no longer constrained by the hardware, but inertia keeps us where we are. When thinking about color, ask yourself, "Does this color help call attention to the abnormal situation?" When an operator looks at the screen, how long does it take to determine if this process is having its best day ever, or is it about to explode? Is anything on it in alarm? Can you tell? Poor color use makes it harder to spot the unusual situation.
Moderator: It seems there are color designations some designers expect to be intuitive, but are applied differently in different contexts. The red/green paring is often used to indicate opposite states, but not always in the same way. Can such a difference be resolved, or should it be eliminated as a practice?
Robertson: If you don't think it's a problem, ask a good colorblind operator. The other way you can convince yourself is to bring in your electrical maintenance guys along with operators, and show them a red motor on the screen. Most electrical guys will say, "It's on and energized. It's dangerous." The operators will say, "It's off. It's stopped." Red/green does not have a universally accepted, intrinsic, on/off definition of the states.
England: Color alone is not enough to define the state. It's much more effective to combine shape with color to designate various messages.
Hollifield: The power industry is the absolute worst about giving up this red/green paradigm, but there are alternatives. A compromise could be to pick a bright saturated red and reserve it only for showing alarms. If you're stuck on using red/green or green/red to designate when things are on/off, be absolutely consistent how you do it, and use a very pale red and a pale green. Just to be clearer still, accompany it with a process value word next to it, "stopped" or "running," so it's redundantly coded. However, the preferred method is a brightness code. Imagine there's a light bulb inside the pump. When it's running, the pump is going to be brighter than the background of the graphic, and when the pump goes off, it's going to be darker than the background. Plus it's going to have a redundantly coded word next to it.
Fitzpatrick: It's one of those things you can't tell somebody; you have to show them.
Moderator: How does the differentiation between information and data drive design decisions in operator interface implementations?
England: I struggle with the terminology on this one. Let's turn information into data, or is it data into information? I can't ever remember which is which. When you are doing effective HMI design, it's all about the content. It's about making sure you've gone through some sort of systematic analysis of your requirements, and trying to get the end user to think in a different way about how he or she is managing the process. Finding resources to help facilitate such concepts has been one of the problems I have seen. One of the interesting approaches we're doing right now is using advanced control experts. Those guys know how to elicit information out of users to become the pertinent things to help manage the process. It's a different mind-set, and we're finding it helpful for pulling this out.
Hollifield: We expect our operators to look at dozens of graphics, with numbers all over them. They build, over time, some sort of mental map as to what is important. Minute by minute they have to ask, "When I look at this number, should I be happy or sad? Is the number in a good place or a bad place?" They have to refer to their mental map minute by minute. Such constant analysis is a very high mental workload. I believe, in the appropriate level in the graphical hierarchy, an analog representation of a number is important. So if you refer to Figure 3, you see analog indicators which include the numbers. But they also include something additional, the blue range, which represents "good" or "normal." By properly using and aligning these, and not scattering them all over a graphic, your eye can quickly scroll across and look at literally dozens of indications and know which ones are in normal range and which ones are not. You can even see the configured alarm range, and when it goes into alarm it changes color and the redundantly coded alarm indicator appears. Situational awareness is the difference between information and raw data. By giving context, we tap into the operators' knowledge of what is normal and what is abnormal, what the alarm ranges are-and we depict those things rather than expecting all operators to have an identical mental model, perfectly memorized.
Audience member: I get the value of trends so we can see where we've been, but I struggle with using only bar charts. I like the blue "good" indication, but it doesn't show how good or what's best. How do you convey the optimum spot in the process?
Hollifield: Experience. Just adding the what-is-good range is about an order of magnitude increase.
Fitzpatrick: One of the things I would normally add to the analog bar would be a flexible what-has-the-range-been-recently bar beside it. Then you can see, "I'm good, but the last 20 minutes I've been outside."
Audience member: I'm concerned about getting away from the P&ID representation on a graphic. This makes it hard for operators to follow the process. They want to see where the flow comes from and where it goes.
Hollifield: There is a place in your hierarchy for the P&ID depiction: It's Level 3. You go to Level 3 when you are diagnosing a problem. It is often very good to understand the physical relationship between what's upstream and downstream of the process, but a Level 1 will not necessarily look like your plant. Your car's instrument panel does not look like a picture of your engine with a bunch of numbers on it. Level 1 should be the most important measurements for everything the operators are responsible for, so they can easily see what's in alarm, what's not, what's normal, and so on.
Robertson: Decision makers tend to not like the Level 1 displays because they don't know the process very well. They want Level 3 displays, and you need Level 3's for training, troubleshooting, and for explaining things to engineers when they wander in. But operators who sit and watch the board 12 hours a day get what they need from Level 1 displays. They know where all the process flows come from and where they go. They know where the pumps and tanks are. But as an engineer, I don't, so I need Level 3.
England: It's not about the numbers; it's about the descriptions behind them. The HP-HMI Handbook talks about Level 1, 2, and 3 as overview, control, and detail. A lot of our consoles are geared towards operators who have multiple complex process units, so the mental model management issue dictates the control graphics have some kind of a PFD, or some land marking. What happens, though, is entropy settles in and operators will paint those pieces of glass with everything they have at their disposal, and will settle on the most helpful things.
Audience member: Is it as simple as Level 1's are on the big screen at the top, and Level 2's, if designed right, are what the operators are sitting and watching day to day if the plant is running fine, and the Level 3's are for the abnormal situations and when I need to look at the details?
Hollifield: You're pretty close. Ask your operators, "What are you responsible for running?" A typical answer might be, "Five reactors, three feed systems, a tank farm, and some miscellaneous items." Well, they've described their Level 2 graphics. A Level 2 is a chunk of the process, logically connected, with probably about 50 to 100 loops in it.
England: One of the misinterpretations of the ASM guidelines is concluding some of the discussion in the overview section is talking about a unit overview. To Bill's point, what they're getting at is a different concept. You're looking for a scope of responsibility overview and then the major steps of the operation the operator is responsible for placed underneath it. If you approach it in such a way for each of your applications, then you have a better hierarchy to help you put critical information in the right context.
Hollifield: We did a proof test of all of these concepts at a major power plant. They have a simulator, and one of the things they do is a manual runback. If the power plant gets in trouble, they need to go to half rates. It is a very complex, manual process requiring about 30 minutes, and if the operator does anything wrong they drop down to zero, which is very bad. Watching the operators do a manual runback, they called up more than 14 graphics in the process. Some of them they have to call up for one tiny thing. There was a lot of navigation, a lot of back and forth, a lot of distraction, and very high stress. So there is another type of graphic, which we call an abnormal situation graphic. We designed two graphics to have everything needed to fully handle the runback. So when you look at a situation, be looking for things where you might create those two graphics containing everything they need to help handle a specific situation. It's not strictly in the hierarchy, but special purpose.