Webinar recap: High Performance–HMI Done Right
We had a great turnout at the High Performance–HMI webinar last week, and we’re glad so many of you could attend. Chad Harper and Lee Swindler were on hand to demonstrate the graphical downfalls of many older human-machine interfaces (HMIs) and discuss the benefits of transitioning to High Performance–HMIs. Thank you to everyone who attended, and especially to those who participated by submitting questions.
If you couldn’t make it, you can watch the webinar here or read on for a recap of what you missed:
The evolution of HMI
The information communicated by the first HMIs wasn’t any different from that of modern-day HMIs, but the way the original HMIs presented it was much simpler. As CRT graphics became more popular, HMI graphics became more complex — and so did the information they displayed. Unfortunately, later versions overcorrected this problem, trading information overload for overly decorative graphics.
Today’s HMIs have cleaned things up significantly, yet many still focus too much on color — often at the expense of clarity. Bright, saturated colors should only be used to indicate abnormal situations, and they should be paired with distinct shapes to indicate alarm states. Of course, shaded varieties paired with textual indication are even better, as colors can mean different things to different people. For example, red indicates an error to process engineers, but in the power industries red means “energized.”
What makes something HP–HMI?
In contrast to clearly defined alarms, other HMI elements should be simple and non-distracting. No 3-D graphics; no scales. Just an easy-to-interpret, informative look at what’s going on. Where there are complex control strategies, there should be pop-up menus that let the operator quickly get to the root of any problems that arise.
Standard libraries are getting better and better, and it’s wise to use the manufacturer’s library to avoid complications further down the road. If you customize or go with a third-party library, you’re on the hook for maintaining up-to-date licensing and re-validating anytime you update your PLC or DCS.
Also, HP–HMIs are structured hierarchically. By layering the information on multiple screens, it’s easier to focus on immediate concerns. Level 1 is generally displayed on a large screen and can indicate trends or a high-level process overview. Level 2 is more detailed; these are the screens that operators look at day-in and day-out. Level 3 is based off of existing P & ID screens and is used to diagnose problems. Additional help menus reside on Level 4. Together they offer comprehensive insight without being overwhelming or distracting.
Benefits of HP–HMI
Due to the critical role they play in allowing early identification of abnormal situations, poor HMIs are often cited as contributing factors in major accidents. Any lag or confusion can cause enough of a delay to put an entire facility at risk. One study showed that by upgrading to HP–HMI, there was a 5x increase in proactive detection of abnormal situations.
Effective implementation of HP–HMI
The keys to effective HP–HMI implementation are to:
• Establish graphics standards before starting
• Use a qualified, independent facilitator
• Involve operators early and often
• Challenge the status quo to drive to an optimized solution
• Perform efficient yet thorough testing prior to commissioning
A good graphics development process always begins with a storyboard workshop where the graphics quantity and navigation layout are optimized to ensure the right information is available with a minimal need for searching. . Once this is determined, Level 2 graphics development can begin, followed by parallel development of Levels 1, 3 and 4. Then testing can begin.
At this point, the “picture” has already been fully vetted and reviewed during development. As long as you’ve included the operators throughout the process, there should be no changes to the picture at this point. The test system should duplicate the live system as closely as possible, and you should perform a database comparison between legacy and new graphics to identify discrepancies. If possible, final testing should be side-by-side with the legacy graphics.