Basic Principles for High Performance HMIs 2

General Considerations for Displays

There are many graphic design principles common to all displays, regardless of their level in the hierarchy. These common principles are covered in the following sections with examples. In the next chapters, the detailed considerations for content of each display hierarchy are covered.

Use of Color

Color perception is a highly complex topic, about which thousands of pages of research have been written. In industrial HMIs, color is often highly overused and improperly used. For a High Performance HMI, color usage is restricted for very specific reasons having to do with consistency and with drawing attention to important situations. Color choices and usage must be applied consistently throughout the entire graphics hierarchy. Color should never be the sole differentiator of important factors. Color differences should be combined with other distinguishing characteristics such as shape.
Proper use of color is a factor in making graphics easy to use and comprehend. Misuse of color will significantly hinder the operator’s ability to quickly and accurately detect an abnormal situation.
Background Color
It has long been thought that proper display contrast is achieved by a light or dark background, but not in-between. This advice was partially correct, and was influenced by display hardware limitations in the early days of DCS graphics. However, contrast is not everything. High-contrast, bright figures on black backgrounds are fatiguing and uncomfortable to the eye. If that was an effective mechanism for people, then books would have light text on dark paper. It isn’t and they don’t.
The correct guidance is for the background color of a display should be a light gray. This most effectively addresses the problems of glare, contrast, color interference, and fatigue. Control rooms should be brightly lighted (as discussed in a later chapter) and displays should mimic the ease of reading paper documents, rather than being made of brightly glowing lines, objects, and text on dark backgrounds.
Glass CRTs have more problems with glare than LCDs and are rapidly being replaced in control room applications. In addition, the same graphic shown on different hardware may look significantly different.

Color and the Brain
In human perception, color is a special attribute. Color is processed “pre-attentively” meaning there is circuitry deep in our brains picking out color differences. Our attention is automatically drawn to something having color contrast with its background. This is known as the “pop-out” effect. Strongly contrasting color is a powerful tool for directing the operator’s attention – which is why it should be reserved for abnormal situations (such as alarms).

Experimentation with different levels of gray backgrounds and foreground objects in the actual control room and on the correct display hardware can be used to decide upon specific values. Figure 17 is an example illustrating the typical 16 gray-level contrast. A Gray 3 (RGB 221, 221, 221) or Gray 4 (RGB 192, 192, 192) is often a good background choice since they work well with other selections for foreground objects. Gray backgrounds have minimum interference with other color choices.
A screen element, such as Figure 17, can be used to test choices in your actual conditions and by the people who will use the displays. Since printed output differs considerably from screen appearance, it is unreliable for making choices.
Foreground Colors
A minimum number of colors should be used and quite sparingly. HMI graphics are different from other graphic pictures we interact with daily. For example, internet web pages are usually very colorful and animated. This is for a reason; they are competing with all the other web pages for our attention. Typically most of the information on a web page is static, has equal importance, and there are only minor consequences if you overlook a piece of information. This is not the case with DCS graphics.
Process lines and the outlines of vessels and equipment should be dark gray or black, not colored. Emphasis is provided via differences in line thickness, not color.
Color should not be used in an attempt to indicate the type of material (i.e. white is steam, green is demineralized water, pale blue is ethylene, etc.) as it usually cannot be consistently achieved in actual practice (or memorized by the operators) and proves to be a distraction.
Shades of Gray and Contrast

Figure 17: Shades of Gray and Contrast

Bright, intense (saturated) color is used only for quickly drawing the operator’s attention to abnormal conditions and alarms. If the process is running correctly, the screen should display little to no color. All use of color must be standardized and rigorously followed.
Color is perceived poorly in human peripheral vision. Since multiple monitors are normally installed in an operating console, never assume a color change alone will draw an operator’s attention. A graphic behavior, such as blinking, is highly detectable by peripheral vision, but should not be overused. Many control rooms have screens full of constantly blinking data.
Color Blindness
Color-blindness is a common phenomenon and there are several varieties. For this reason, an object’s color is never the only method used to convey important information. The most problematic color pairs are red-green, green-yellow, and white-cyan. The saturation and brightness choices of the specific shades chosen can be adjusted to achieve differentiation on the chosen gray background.
Color is used in conjunction with text, shape, filled/unfilled status, texture, or a similar aspect. This redundant coding of information is one of the primary methods by which color-blindness is addressed.

Standards and Color Conflict

There are a variety of standards (ISO, IEC, ANSI, ISA, API, etc.) applicable to various industries. Some of these standards contain color coding guidance, though not necessarily for screen displays. The unfortunate truth of the matter is the writers of these standards were not necessarily experts in HMI design. Various standards specify totally different uses for the same colors, particularly red and yellow. The purpose of these standards was not to provide guidance on HMI display design for high performance.
Therefore, attempts to design displays reflecting the content of such standards will not produce high-performance results, but instead can result in inconsistency and confusion.

Depicting Lines, Vessels and Static Equipment

While the process pictorial elements are typically overused, it is important to design them correctly when they are used.
Process Lines
Process lines should be dark gray or black.
Thickness, not color, is used to differentiate their significance.
Main process lines should be 3 pixels in width; secondary process lines should be 1 pixel. Use arrows sparingly to indicate flow direction on primary lines.
There should be no more than two or three line types (such as solid, dotted, dashed) and a similar number of line thicknesses.
Process Vessels
The tendency in the past has been to create life like graphics with 3D vessel and a great amount of detail around static data. This is counterproductive.
Vessels should be depicted as 2 dimensional, not 3 dimensional.
The interior of the vessel should be uniformly shaded, without gradients, and be the same as the background color.
The vessel should be outlined in a thin line of black or dark gray.
The vessel’s representative shape shall be shown, but without much detail.
The size of the vessel shall be relative to the process importance of the vessel and also relate to its physical size (when practical).
There should be no animation associated with vessel internals.
Vessels should not be shown as cut-away drawings showing detailed unchanging internals.
Process Flow
Process flow should be depicted consistently.
Flow should generally be from left to right.
Vapors generally flow up and liquids down, although compressors and pumps affect this depiction.
Process lines should enter and leave the screen in consistent ways. Entry and exit points which are also navigation targets should be consistently presented and differentiated from non-navigation link labels (See Figure 18)..
Some places have carried the gray-scale principle too far and created extremely low-contrast graphics (Figure 7-19). Such “blob graphics” are not recommended. The key is to provide easy visibility of elements, but to reserve emphasis for abnormal situations.
3D vs. 2D Vessels and Lines

Figure 18: 3D vs. 2D Vessels and Lines

 Low-Contrast “Blob Graphic” Elements

Figure 19: Low-Contrast “Blob Graphic” Elements

Depicting Text

The display of static text on-screen should follow several principles:
The amount of text should be minimized, but not eliminated. A graphic screen is not an instruction manual or a training document. Nor should it be a puzzle. Use text to identify different items when their placement or shape does not make their identity obvious.
Text should generally be a dark gray, not black.
All display screen lettering should be in non-serif fonts. We know, printed books and magazines use serif fonts (such as you are reading now) because they make reading easier and faster. However, books and magazines typically have at least four times the resolution of a CRT or LCD screen display. Depicting serif fonts on such displays actually makes the text less readable.
Use larger, highly visible text to identify duplicated equipment, such as multiple reactors, furnaces, compressors, and so forth. When a screen shows only one furnace out of several, it is extremely important to be clear on which furnace is being depicted.
For isolated words, titles, short labels, and equipment designations (particularly for a “non-word” term like HYDRO SEP), all uppercase lettering is preferred. For other uses, mixed-case lettering is much more legible.
Ensure consistency with abbreviations; make sure to maintain a master list and glossary of them.
There are many formulae and calculation methodologies for determining the proper size of text based on screen size, angle, placement, pixel density, and other factors. From a typical viewing distance of 24 inches, ANSI recommends text heights of a minimum 2.8mm, nominal of 3.5mm, with a maximum of 4.1mm. As in so many things, simpler is better. As a check to these values, create some mockup graphics with various sizes of text, and insure your operators (particularly your “more experienced” ones) can read them.
Operators like to have all the information in front of them. In response, many existing graphics have sacrificed clarity and reduced text size too much in order to cram more data (not necessarily information!) onto a single display.

Depicting Values

The display of live values on the screen should be shown in a different way than static text.
The choice of a bold, dark blue is a good choice for the gray background and differentiates live values from static text (see Figure 7-20).
Leading zeros are not displayed, except on fractional values (e.g., 0.27). Values are shown only to the precision needed by the operator.
In tables, align numbers on the decimal point.. In a High Performance display, tables of numbers are not generally recommended.
When needed, the units of measurement are displayed in lower contrast text adjacent to or near the value.
Tagnames should not be shown on the screen by default. It should never be necessary for an operator to have to type in a tagname in the entire HMI. It is a typical DCS functionality that the selection of a live value provides access to a faceplace-type mechanism where many further details of the reading (including the tagname) are provided. In some cases, it may be desirable to provide a toggle command by which the values on the screen have their tagnames appear and disappear. This is not advisable as a default because it can pose significant layout problems.
When items are “selected”, that status should be indicated. Surrounding the selected item with a white outline is a good practice.
Action or status messages should be short, simple, and specific. For example:
“Backwash complete. Filter cycle is restarted.”
“Open Valve 16A for batch to proceed.”
“Quality Parameter <xxx> exceeded in current analysis.”
Values and Faceplate Pop-ups

Figure 20: Values and Faceplate Pop-ups

Depicting Vessel Levels

There are several methods for analog indication of vessel levels. The object is to depict the level without undue emphasis or distraction. Indication of any alarm limits is also recommended, such as with the small marks on the rightmost example in Figure 21. The overall height of the level bar depicted should correspond with the physical range of the instrument as installed on the vessel.
Moving analog indicator-type elements can also be used for tank level indication. For some equipment, a trend line is the best method for depicting levels.
Example Practices for Vessel Levels

Figure 21: Example Practices for Vessel Levels

Depicting Alarm Behavior

Any value in alarm must be shown clearly and consistently. There are a variety of methods, some clearly better than others. The following principles apply:
Color is related to alarm priority. Every alarm priority has its own color which is used for nothing else, on any graphic, than to depict alarm-related behavior.
Unacknowledged alarms should be distinguished from acknowledged alarms. The most common method is the flashing of the alarm indicator for the unacknowledged condition.
If more than one alarm is in effect on a value, the highest priority alarm should be indicated.
Graphics should not be “hard-coded” with alarm behavior for points; the behavior should be consistent based on the current configuration of a point’s alarm and should change if the configuration changes.

Alarm Priorities

It is a well-known best practice for process alarms to utilize a primarily three-priority system. For full details on the proper selection and distribution of alarm priority, see the references section for The Alarm Management Handbook.
If possible, diagnostic-type alarms should be segregated from the primary three priorities. Diagnostic alarms are those indicating instrument malfunctions not solvable by the operator and generally requiring maintenance attention. If the DCS is capable of a fourth annunciated priority, then diagnostic alarms for which the only operator response is the writing of a maintenance work order should be segregated into the fourth priority.
Suggested colors for a recommended 4-priority system are:
Priority 1 – (Highest); Red
Priority 2 – (2nd Highest); Yellow
Priority 3 – (3rd Highest); Orange
Priority 4 – (Reserved for Diagnostic Alarms); Magenta
Via prototype testing, ensure the colors chosen are easily distinguishable on your particular display hardware. Printouts will appear different than LCDs or CRTs.

Alarm Indication Methods

The following figures show several alarm indication methods with their advantages and disadvantages. The third method is the one recommended.
Method 1:
Method 1 – Solid Color Blocks Behind the Process Value (Not Recommended)

Figure 22: Method 1 – Solid Color Blocks Behind the Process Value (Not Recommended)

The color stands out and draws attention to the value in alarm.
For the unacknowledged condition, flashing of the solid block and not the value ensures the value is always visible.
Color combinations can be problematic – consider the red-blue combination for Priority 1.
The alarm priority is shown only by color and is not redundantly coded, thus the color-blindness issue is involved.
Method 2:
Method 2 – Color Outlines Around the Process Value (Not Recommended)

Figure 23: Method 2 – Color Outlines Around the Process Value (Not Recommended)

The color stands out and draws attention to the value in alarm, although the decreased area of colored space provides a lesser effect.
For the unacknowledged condition, flashing of the Outline block and not the value, ensures the value is always visible.
The color combination problem in the method #1 is addressed.
The alarm priority is still shown only by color and is not redundantly coded, thus the color-blindness issue is still unsolved.
Method 3:
Method 3 (Recommended) – The Separate

Figure 24: Method 3 (Recommended) – The Separate
Alarm Indicator Element

In this method, a new alarm indication element appears and disappears with the activation of the alarm condition..
The color stands out and draws attention to the value in alarm with adequate visibility.
For the unacknowledged condition, flashing of the entire element does not affect the visibility of the process value.
There is no color combination problem.
Placement of the indicator is flexible and can be anywhere near the value (although a consistent placement is preferred).
The priority of the alarm is redundantly coded by alarm indicator shape, color, and priority number.
All these methods share one disadvantage: the specific type of alarm is not shown. Unless it is obvious from the operator’s inspection of the process variable, a click to bring up the faceplate may be needed to determine the specific alarm.
Alarm Suppression Indicator

Figure 25: Alarm Suppression Indicator

It is also recommended for any alarm suppression in effect on a point be shown on the graphic as well. The above method works well.
Method 4:
Method 4 – The Separate Alarm Indicator Element with Alarm Type (Not Recommended)

Figure 26: Method 4 – The Separate Alarm Indicator Element with Alarm Type (Not Recommended)

In this method, an attempt is made to code alarm type into the separate alarm indication element. This method seems acceptable, but has significant problems in actual practice.
Includes the addition of alarm type display. Alarm types can include:
High Value    HI-HI Value       HI-HI-HI Value
Low Value    LO-LO Value     LO-LO-LO Value
Rate of Change Positive       Rate of Change Negative
Deviation Above Setpoint    Deviation Below Setpoint
High Controller Output        Low Controller Output
Bad Value Diagnostic          Range Diagnostic
This has all the same advantages as method #3 as well.
For any given value, a dozen or more alarm types may be available on a typical DCS. (This is part of the overall problem of alarm management.) The coding of these types can begin to occupy a lot of space. Attempts to save space can yield very cryptic abbreviations for alarm type. It is additionally possible for a value to have more than one type of alarm in effect at the same time (for instance, high value, plus high rate of change). Attempts to show these multiple alarms or to arrange the depiction in some sort of hierarchy pose significant practical difficulties.
There is simply far too much information available in a DCS, even about a single value or alarm, to attempt to show it all on a single graphic indication. Many attempts have been made and they generally result in over-crowded and confusing displays. The principle of disclosing progressive amounts of detail, as needed, addresses the issue in an improved way.
It is never recommended for the color of the value itself to change based upon an alarm. While often the “easiest” path, this is a poor practice.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top