3 Things You Didn’t Know About High Performance HMI
The High-Performance HMI is grounded in ASMTM principles. The Honeywell ASM Consortium which I used to be the Program Director and founder did extensive research into HMI graphics practices. At the time, Honeywell was locked into a development path which was not graphics friendly and was before the decision to switch to a Windows-based control system. Researchers wanted to use JAVA type software, but the product line was headed down a different path before the switch. Which limited the Research and Development. However, the researchers came up with concepts that would be more in-line with NASA research and would pave the way for a new generation of graphic design.
Unfortunately, a lot of the principles identified did not get transmitted with the overall theme of the new approach. Developers grasped the concept of gray backgrounds with reduced colors and developed what we refer to as blob graphics!
The best-known thing other than the bland graphics is the ASM graphics recommends a hierarchy rather than the tradition single flat graphics which starts with one P&ID and navigates through the rest of them, making it difficult to make control moves as different instruments that may need to be manipulated together are distributed across several graphics. Plant startups became a nightmare navigating backward and forward across a set of typically 12 graphics.
The High-Performance graphics were not specifically different from the original intent of the ASM graphics but were intend to emphasize a different perspective, instead of focusing on lack of color and light backgrounds, the emphasize was on the operator’s ability to detect, diagnose and respond to abnormal situations.
The first emphasis is on saturation levels of color, making the brightest colors related only to the most critical information on the screen.
The second emphasis was on a true coding system that an operator could easily memorize, such as “RED” only used for the most critical alarms, “YELLOW” for the next priority level alarm, and something like cyan for the third priority. That is three colors, and we recommended that the number of colors and coding should be limited to about 7 things (keep it simple). However, bright red could be used for an unacknowledged alarm and halftone red for an acknowledged alarm which just counts as one of the seven. Other colors can be used but should be used so it is intuitive to the operators what the coding behind the colors are. For example, a lot of operators like the color green to represent open, or running, or energized to be more accurate. However, this green should not be bright as it is relaying normal operation rather than an abnormal event.
The third emphasis is associated with putting data into context showing object like a temperature build to graphically show the Process Value (PV) against the desired setpoint (SP). Then overlaying the normal operating range, then the alarm limits allowing the operator to put the data into context quickly.
To make this even more apparent, some objects have been built so that if the data moves outside the Normal Operating range a number, the PV is also displayed making the object stand out against the other objects that are within normal operating range, focusing the operator’s attention on the abnormal value.