High-performance HMIs: Designs to improve operator effectiveness
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.
Audience member: If we acknowledge the customer of the HMI is the operator, should there be a Level 0 for economics?
Hollifield: When creating a Level 1, we like to ask the facility manager to show us his or her monthly report. Things important to the business are what get reported, and we find they are usually things the operator can affect. But in an existing HMI, they are usually nowhere in there at all. If it’s important to the management, and affected by the operator, then it should be on a Level 1 or Level 2 somewhere.
Fitzpatrick: I think one of the difficulties of having level numbers is the implication you need all four. Depending on your level on instrumentation, often it’s not true, so you end up with awkward, sparse graphics just to follow the rules, which is not the intent.
Moderator: What about navigation?
England: I’m not a proponent of clicking on something on a Level 1 overview screen to navigate, even though you can use yoking techniques to open it up in other windows. I think the best approach is to put good navigation tools together so it is intuitive and embed your alarm navigation within your normal navigation. Then it becomes as simple as follow-the-blinking-light. When you are responsible for a multimillion-dollar piece of process equipment, follow-the-blinking-light is a very handy tool. There are various methodologies to include navigation, including tabbed displays, buttons, dropdowns, etc.
Fitzpatrick: I agree. Generally, if you give operators follow-the-blinking-light functionality, they are going to break your fingers if you try and take it away.
Hollifield: Every DCS has different navigation paradigms embedded into it. There’s an expression, "Dance with the one who brung ya." In general, you want to follow the features embedded in your DCS, because they work well.
Moderator: Change zones and faceplates have been popular interaction mechanisms for many years. Are there superior interaction models?
England: Direct data entry. Why are we using faceplates? Ask your DCS vendor. If you remember old panelboards, you know why. It looks exactly the same. There is this paradigm where we have been using these faceplates because of the industry evolution. Why?
Robertson: It’s kind of like a car dashboard-everyone knows it.
Fitzpatrick: But why force the operator to change focus?
Hollifield: I like the faceplate paradigm because in our book we’re presenting general principles you can apply to most DCS platforms. My complaint is when I go to a control room, if I click on something, the faceplate appears, and where does it appear? Right in the middle of the screen, on top of what they are trying to do. So the first thing the operator has to do is move it out of the way. It’s possible to cause the faceplate to appear where you want it, and we say put a reserved area about the size of the faceplate and make it appear there. Direct entry can be a great thing, but it currently requires you to code certain elements individually. Those may not survive a DCS upgrade. So with faceplates, you know they are going to survive when the vendor upgrades versions. If you want direct entry objects on your graphics, assume you’ll have to hard-code everything. Again, it’s "Dance with the one who brung ya."
England: I’m pushing for a direct data entry paradigm. Some DCS vendors make it easy, some don’t. If it is easy, then why not do it? Ultimately, it goes back to a more simplistic design: click what you want to change.
Moderator: How does the use of trending support overall goals of the operator interface?
Hollifield: I believe in embedded trends. If an operator calls up a graphic, and it is something he or she should see in a trend form, then the trend should already be there. There is massive failure in the trend-on-demand paradigm where you believe you can pick anything on the screen and hit one button and get a trend. You might be 15 to 20 clicks away from a trend-on-demand display showing a useful time and range, and then it disappears as soon as you change the screen. The best operators rely heavily on trends, so you want them permanently on the graphic.
England: One of the things I want to mention is the trend overview screen and the concept of picking what you put on it. I call them key leading indicators. Not KPIs, but key leading indicators. Conceptually, you are trying to show the tail wagging the dog. You want the operators to notice something going off normal before it ever gets into an alarm condition, and trends are one of the most powerful tools. How you select what you trend, and how you select ranges is something I think really deserves a lot more attention. One quick example is a tower level. Usually an operator will identify level as the most important thing on the tower. However, level is not what we’re going to trend. We’re going to trend outflow, which is going to show some kind of deviation in mass balance much more quickly than any kind of pattern on level. To me, trends are hugely powerful, generally underutilized, and a key leading indicator concept worthy of more promotion in our industries.
Hollifield: One small criticism: We have a trend overview, but with key leading indicators, it’s not necessarily clear if the trended value is in a "good" range. But there are techniques you can use even on trends. For example, you can add color-coded bars beside the trend, which show the normal range for each colored trace, along with alarm ranges and interlock ranges. This isn’t part of the trend, but a separate element is jammed up next to it. Don’t make operators memorize where all those things should be.
England: This goes back to my point about key leading indicators. What’s good? When you look into trying to keep situational awareness, and looking at what you picked for key leading indicators, a lot times a key leading indicator is good from 0% to 100%. We opted to go for the more simplistic approach on this and haven’t used any color bars for our trends. I think the best solution really depends on the situation and factors including number of pieces of glass, industry, etc.
Hollifield: I completely agree. Different techniques are better for different situations.
Moderator: How does HP-HMI support safe plant operation?
Fitzpatrick: By providing operators an awareness of what good looks like, but also where the safe limits are. Fundamentally, it goes back to the right information to the right people at the right time.
Hollifield: In one test we did, operators using HP-HMI were significantly better at spotting abnormal situations, even before alarms occurred, and dealing with those abnormal situations in a shorter amount of time than with traditional graphics. The faster you deal with an abnormal situation, the less severe it is and the quicker you are back within the normal bounds. Both of those are very important for good operation.
England: We’ve found the effort you put into your startup and shutdown graphics, the special use, Level 4 type of graphics, is well worth it. Some argue against developing those graphics, claiming it takes a lot of effort for something used so infrequently. However, if you don’t make the effort, I guarantee any money saved by not spending those engineering hours up front will be lost probably within four hours of any incident. One of the most important things is to carve out time and effort to develop these special, situational graphics like shutdown assessment, and first-out capture. It helps operators assess what happened. Did everything trip safe? What have we got to do to restart it? Using a very procedural set of screens can help get back on track, so they don’t have to go to 12 graphics.
Moderator: How do you measure success of an HP-HMI implementation? Is it art or science? Is it even measurable?
Robertson: The important things to look at are the KPIs. Did the plant process improve? Here are decreases in plant deviations, and here are increases in efficiency.
England: From an operating perspective, it’s seeing the number of phone calls go down. For both an operations supervisor and a control engineer, if you’ve done the HMI investment right, you won’t get those phone calls during abnormal situations. You’ve successfully presented all the information and the operators can take care of it. When they do have to call about an incident, they should be able to call with a very short description of what the problem is and help make quick decisions.
Hollifield: We have a good case study with a major power generation company. After implementing HP-HMI, they’re saving money because every plant now has 75 to 85 graphics, not 300 to 500. They have total standardization now, and they are proving benefits with incident history. If you ask what’s going on, they have a bunch of anecdotes about incident and upset avoidance. They are also saving money on console licenses, screen licenses, and engineering effort.
Robertson: At a higher level, there are plenty of university studies and Department of Defense studies. There is definitely science making the case for the main principles behind HP-HMI.
Fitzpatrick: I think it is important to do some assessment before and after. Conduct operator interviews, do some questionnaires, and then come back a few weeks later to review the results. Support builds up as people start to recognize benefits.
Moderator: What are some common objections to HP-HMI projects?
Hollifield: Besides "We’ve always done it this way," one of them is "It would take months to retrain all of our operators to use a different HMI." We buried that misconception in a test we did where the operators had one hour of experience with the new HMI, and they ran quite well. There is a lot of inertia as well.
Audience member: Did you ever put them side-by-side, during the transition?
Hollifield: We ran a group of operators through a variety of situations using their high-fidelity simulator for one hour. One group used their existing graphics, and then used a new HP-HMI they had never seen before. The other group did the same in reverse order. We had very detailed comparisons on how they did on those scenarios, and training was not an issue. Throwing training up as an obstacle is a way to avoid doing something you may not want to do for other reasons, but it is not a valid issue.
Fitzpatrick: The Center for Operator Performance is doing some interesting work in alarm management and HMIs. They have created some scenarios where they take college students who know nothing about industry and run them through simulations, and they have some interesting results. They are repeating these scenarios with operators to try and extract what impact training or experience had.
Moderator: With all of the varied information sources on HP-HMI, the Abnormal Situation Management Consortium, the Center for Operator Performance, various books and publications, the upcoming ISA standard, and so on, how do we decide what is important and make your way through such a mound of data?
Hollifield: You’re right, there is a growing list of standards and guidelines, including EEMUA 201, API 1165, and all sorts of other things. There’s horrible stuff out there and there’s good stuff. Get it, read it, see what makes sense to you.
Fitzpatrick: With ISA101, the first pass is a standard with the minimum acceptable requirements. We are planning a series of technical reports as a follow-up including more best-practice recommendations. In ISA101, we did try and review everything we could find out there and pull in the best, though when you write standards you learn to live with disappointment. So wait for the technical reports, but hopefully the ISA101 standard will be one used.
Moderator: In closing, do you have anything else you’d like to add?
Fitzpatrick: Don’t let the mountain in front of you stop you from getting started. Pick off something manageable, start playing with different approaches, and see what works for you. There’s no silver bullet, and there’s no single best overview approach. It really depends on the process and what’s important to the operators.
Robertson: When trying to figure out what makes for an HP-HMI, we can get entrenched in the things we’ve learned, or think we’ve learned. Stay in touch with your operators and your process. Keep doing stuff that works, and don’t do stuff that doesn’t work. It sounds simple, but people forget to do it.
England: Remember the concept of situational awareness. You want to have the most effective HMI possible, and you want to present data so it can support the right mental model, reflecting the information your operators are managing in the process. Put yourself inside the process and keep thinking like the process. If you focus the right way, this advice and other reference material should help you move in the right direction.
Hollifield: A lot of people worry about throwing everything they have away and starting from scratch. You don’t have to. What you currently have is probably the basis for your Level 3 graphics. You need those Level 3s, so you don’t want to get rid of them. What most people do not have are the graphics necessary to give situational awareness, the ones for Level 1 and Level 2. We’re talking about maybe 20 graphics. Any company can afford to create 20 new graphics. Put your toe in the water with just an overview, a few Level 2s, and a few abnormal situation graphics. Don’t treat it like it’s a big monster.
For more information, visit:
The 2015 ISA Process Control and Safety Symposium will be Nov. 9-11, 2015, in Houston.
- High-performance HMI strategies can improve operator effectiveness and situational awareness.
- Concepts of what those qualities look like in practice vary a great deal based on what guidelines are being implemented.
- These participants have all been involved in actual implementations which have shaped their comments.