HMI Color and Shape Semantics for Operator Screens

Color is a state language, not decoration

HMI colors should tell the operator what needs attention. They should not mainly show brand colors, pipe material, or a designer's preference. In a control room, color competes with alarms, abnormal equipment states, trend pens, mode indicators, and quality warnings.

If every pump is bright green, every pipe is saturated blue, and every tank is filled with gradients, there is little visual space left for the one abnormal condition that matters. A useful HMI color standard starts with a quiet normal state and reserves strong color for state changes that need recognition.

Define meanings before drawing screens

Agree on meanings before building hundreds of symbols. Otherwise copied objects slowly develop different behavior.

A simple state table is enough for many projects:

Visual state	Meaning	Example use
Neutral gray	Normal, available, no attention needed	Static equipment body
Muted green	Running or energized	Pump running indicator
Amber	Warning, degraded, or operator attention soon	High temperature warning
Red	Trip, shutdown, alarm, or immediate attention	Motor fault or safety trip
Blue	Manual, remote, or selected state if site standard uses it	Manual mode marker
Purple or magenta	Bypass, override, simulation, or maintenance	Interlock bypass active
Hatched or outlined	Bad quality, stale, unknown, or not communicating	Invalid instrument value

The exact colors can follow the site standard. The important part is one meaning per visual treatment. Do not use red for both a stopped pump and a faulted pump unless text clearly separates the states.

Do not rely on color alone

Operators work with different monitors, dim lighting, remote clients, color vision differences, and printed screenshots. Color should be paired with text, shape, position, or icon behavior.

Good combinations:

• FAULT text plus red outline, not only a red fill;
• diagonal hatch plus BAD QUALITY tooltip for invalid values;
• hand icon or MAN label for manual mode;
• bypass icon plus BYPASSED text near the affected permissive;
• alarm list priority shown with color, priority text, and sound rule.

If a grayscale screenshot hides the meaning, the display is too dependent on color.

Keep alarm color separate from process color

Alarm colors should stand out because they represent operator action. Do not spend red and amber on normal process decoration.

Common problem examples:

• A hot-water line is always red, so high-temperature alarm highlighting disappears.
• A stopped pump is red, so a faulted pump looks like a normal stopped standby pump.
• A tank level fill uses bright colors, so high-high alarm border is hard to see.
• A trend pen color matches an alarm banner color and confuses review discussions.

For most modern HMI styles, equipment bodies and pipes stay low-saturation. Dynamic states use small, consistent indicators. Alarms then have enough contrast when they appear.

Make composite states explicit

A device can be running, in manual, bypassed, and communication-bad at the same time. If the symbol has only one color slot, one state will hide another.

Decide state precedence and separate channels:

1. Communication quality or stale data must be visible even if the last value was normal.
2. Active trip or alarm must not be hidden by run state.
3. Bypass or override must remain visible across screen navigation.
4. Manual or local mode should be visible near commands.
5. Selected or hovered state should not look like an alarm.

A practical pump symbol may use a gray body, a small running indicator, an alarm border, a bypass badge, and a quality hatch. That is clearer than changing the whole pump to one of ten colors.

Test the screen with abnormal scenarios

Reviewing a normal-state screenshot is not enough. Test the display with realistic combinations.

Suggested checks:

• one pump running normally, one stopped available, one faulted, one communication-bad;
• transmitter high alarm with bad-quality fallback;
• valve in manual while a command is disabled by an interlock;
• bypassed trip with related alarms suppressed;
• alarm flood view where priority color, active state, and acknowledgement state must all remain visible;
• remote client or browser theme different from the engineering workstation.

Ask an operator to identify what is abnormal without opening the tag database. If the answer depends on knowing the color convention by memory, add text or shape.

Common failure modes

Stopped and faulted look the same. A stopped standby motor is a normal process state. A faulted motor is an abnormal condition. Use separate text, border, or icon behavior.

Bad quality is invisible. The last good value keeps its normal color after communication is lost. Add stale age, quality marker, hatch, or broken value display.

Maintenance bypass blends into manual mode. Both states may be blue or both may show a hand icon. Bypass needs its own treatment because it changes protection behavior.

Copied symbols use different colors. One area uses amber for warning and another uses amber for manual. Put state colors in a shared style library and test templates after edits.

Dark mode breaks contrast. Some colors that worked on a light background become unreadable on a dark client. Test the actual runtime theme and monitor brightness.

Commissioning checklist

Before handover, check the color and shape standard like any other control standard.

• State table exists and is approved by operations and engineering.
• Alarm, warning, manual, bypass, bad quality, and selected states have separate visual treatments.
• Grayscale screenshots still show the main abnormal states.
• At least one repeated equipment template is tested with all major states forced or simulated.
• Trend pen colors do not conflict with alarm priority colors where possible.
• The Korean and English screen labels describe the same state if the project is multilingual.
• The standard is stored with the HMI project, not only in a slide deck.

Good HMI color use is boring during normal operation. That is the point. The screen should become visually loud only when the process or control system needs attention.