Process HMI Design & Situation Awareness

A human-machine interface is successful when an operator can answer three questions quickly: What is abnormal? Why is it happening? What action is available and safe? A mimic that faithfully reproduces every pipe, valve, and tag may still fail those questions. The HMI is an operational decision surface, not an electronic P&ID and not a showcase for animation.

Begin with tasks and operating scenarios #

Before drawing a display, inventory the work it must support:

• start, stop, change grade, and change operating mode;
• maintain targets and recognize developing deviation;
• diagnose a disturbance and respond to alarms;
• place equipment in or out of service;
• coordinate handover, maintenance, bypasses, and abnormal operation;
• verify whether a command actually reached the process.

For each scenario, identify the required process relationships, response time, decisions, controls, procedures, and failure evidence. This prevents a controller's tag hierarchy from becoming the display hierarchy by accident.

Display hierarchy supplies progressively narrower context #

The overview is not a wall of small versions of every lower-level display. It compresses the plant into operationally meaningful indicators and trends. Navigation should preserve location and make the return path obvious; alarms and links should take the operator to the correct context without creating a second, incompatible map of the plant.

Encode meaning before decoration #

Normal operation should be visually quiet enough that deviations stand out. Use position, shape, text, line style, and value together; do not make color the only carrier of state. Reserve high-salience color and motion for conditions that require attention, and use a consistent palette defined in the site's HMI philosophy and style guide.

Color conventions are not universal facts. Red might mean alarm, stopped equipment, closed valve, or energized circuit in different inherited systems. The site must define one meaning per context, test it for color-vision deficiencies and ambient conditions, and avoid using the same treatment for incompatible meanings.

Scales must communicate the useful operating range and the alarm or constraint context. A bar graph spanning the full instrument range can make a critical process excursion look tiny. Conversely, a truncated scale that exaggerates harmless noise can create false urgency. The scale choice is part of the operating model.

Present the complete control relationship #

A loop display should distinguish:

• process value and its engineering unit;
• setpoint and whether it is local, remote, tracked, or limited;
• controller mode and actual mode authority;
• controller output and output limits;
• manipulated-element command and measured feedback;
• active constraints, interlocks, bypasses, and bad quality.

For a valve, command = 70% is not proof of position = 70%, and position is not proof of expected flow. For a motor, an issued start command is not running feedback. The visual design should make command, accepted state, physical feedback, and process effect traceable without opening four unrelated popups.

Commands are transactions with consequences #

A control interaction has at least four states: requested, accepted or rejected, in progress, and completed or failed. Displaying the button's selected appearance immediately after a click can falsely imply completion. The HMI should show the authoritative controller/equipment state and, when relevant, the reason a command is unavailable or rejected.

Confirmation is useful for consequential, infrequent, or hard-to-reverse actions. Requiring the same generic confirmation for every routine adjustment trains automatic clicking and adds delay. Stronger patterns include selecting the target explicitly, showing the current and proposed value with units, requiring authorization for privileged actions, and displaying the preconditions or consequences near the decision.

Setpoint entry needs range and format validation, unit visibility, source/authority indication, and a clear distinction between typed-but-not-applied and accepted values. A permissive failure should explain which condition blocks the action; a greyed-out control with no reason forces the operator to guess.

Data quality and time are visible states #

Every important value has more than a number. The HMI needs a defined presentation for:

• bad or uncertain source quality;
• stale communication or an old source timestamp;
• substituted, simulated, manually entered, or forced values;
• out-of-range or clipped values;
• maintenance, bypass, inhibited, or out-of-service states.

Do not replace a bad value with zero or the last good value while rendering it as live. Retaining the last value may help preserve context, but it must be visibly marked with its quality and age. Otherwise a frozen measurement can look reassuring while the process continues to move.

Alarms belong in process context #

The alarm banner supports recognition and ordering; it is not the complete diagnostic view. Alarm priority, state, acknowledgement, shelving, and return-to-normal semantics must match the alarm philosophy. Selecting an alarm should reveal the relevant process relationship, likely cause, consequence, operator action, and procedure—not merely a tag detail popup.

The HMI must also avoid turning every non-alarm status into alarm-colored decoration. When normal status, maintenance warnings, permissive failures, and alarms all use the same high-salience treatment, the alarm system loses its signal.

Trends are working instruments #

A useful trend has legible units and scales, source identity, time range and timezone, quality gaps, and markers for relevant events or setpoint/mode changes. Pens should be distinguishable by more than color. Fixed, comparable scales help pattern recognition; operator-adjustable scaling is valuable for diagnosis but should make the changed scale obvious.

Historical interpolation must not invent certainty across missing or bad data. Stepped states, discrete values, and continuously varying analog values require different rendering. The client should distinguish raw values from aggregates and identify the interval represented by each point.

Lifecycle and validation #

ISA-101 treats HMI design as a lifecycle. A site philosophy defines principles and governance; a style guide defines reusable visual and interaction rules; a toolkit implements consistent components; display design applies them to operating tasks. Testing continues through implementation, commissioning, operation, change management, and periodic audit.

Validate representative scenarios with operators:

1. locate a developing deviation from the overview;
2. navigate to its cause without losing plant context;
3. identify the correct action and its prerequisites;
4. issue the command and verify actual effect;
5. recognize stale/bad/substituted data;
6. handle alarm flood, communication loss, and mode transitions;
7. recover after an incorrect entry without ambiguity.

Measure errors, missed cues, navigation paths, and decision quality—not only whether every screen opened.

Review checklist #

• Is every display tied to defined operator tasks and scenarios?
• Does the hierarchy move from abnormal location to cause to actionable detail?
• Are deviation, priority, quality, mode, and authority encoded consistently and redundantly?
• Can the operator distinguish request, controller state, physical feedback, and process effect?
• Are stale, bad, substituted, forced, and bypassed states unmistakable?
• Are alarm, trend, navigation, and command semantics governed and tested as one system?