HMI Faceplate Design Checklist

Purpose of a faceplate

An HMI faceplate is the operator's compact working view for one device, control loop, or equipment object. It should answer the routine questions without forcing the operator to leave the current process display:

What is the current state?
Is the device available to run?
Who or what is controlling it?
What command can be issued now?
Why is it not responding?
What alarms, interlocks, or permissives are active?

A good faceplate is not just a smaller detail screen. It is a repeatable operating tool. Pumps, valves, motors, drives, control loops, and skids should follow common patterns so the operator does not relearn the interface for every asset.

Start with the operating modes

Before drawing the faceplate, list the modes that matter in the control system. Typical examples include manual, auto, cascade, remote, local, maintenance, out of service, and simulation. The exact words should match the project standards and controller logic.

For each mode, define:

Who can change the mode.
Which commands are allowed.
Whether the PLC, HMI, package controller, or field station owns control.
How the faceplate shows that ownership.
What happens on communication loss or bad quality.

Avoid mode labels that are visually present but not actionable. If a mode cannot be changed from the HMI, show it as status, not as a button. If a command will be rejected by the controller, either disable it with a reason or show the blocking condition near the command.

Separate status, command, and configuration

Faceplates become confusing when status values, operator commands, engineering settings, and diagnostics are mixed together. A useful layout is:

The header should show the tag or equipment name, description, current state, alarm summary, and data quality. The description should be readable enough for shift personnel, not only the engineering tag name.

Main operating area

The main area should contain the normal commands and feedback. For a motor this may be start, stop, running, stopped, faulted, and permissive status. For a valve it may be open, close, opened feedback, closed feedback, travel fault, and command source. For a PID loop it may be process variable, setpoint, output, mode, and tuning access if permitted.

Detail or diagnostic area

Diagnostics should explain abnormal conditions: interlocks, permissives, device faults, communication status, trip source, command mismatch, feedback mismatch, or field/local state. This area is often more valuable than another decorative symbol.

Configuration area

Limits, scaling, delay timers, alarm setpoints, and tuning parameters should be protected by role and clearly separated from operating commands. If the project allows online changes, show the current value, engineering units, allowed range, and change confirmation behavior.

Make command behavior explicit

Operators need to know what will happen when they press a button. Command buttons should have clear labels and should not change meaning based on hidden state. If the same control sometimes starts a motor and sometimes resets a trip, split it into separate controls unless there is a strong reason not to.

For each command, define the required feedback:

Does the command latch or pulse?
Is there a command-in-progress indication?
What confirms success?
What timeout creates a fault or mismatch?
Is a confirmation dialog required?
Is the command blocked by mode, security, permissive, or interlock?

Confirmation dialogs should be used for commands with operational consequence, not for every routine action. Excessive confirmations train operators to click through them. A better design is to make the command context clear and reserve confirmation for starts, stops, resets, bypasses, mode transfers, and setpoint changes that could affect production or equipment.

Show permissives and interlocks in a useful way

A faceplate should not only say "not ready." It should show why. Permissives and interlocks are most useful when they are grouped and readable:

Permissive not made: prevents starting or opening.
Interlock active: forces stop, close, trip, or inhibit.
Fault active: device or controller fault requires reset or maintenance.
Local control: field device is not accepting remote commands.
Communication bad: status is uncertain and commands may be blocked.

Use plain descriptions where possible. A line such as "Suction pressure low" is more useful than only showing P_104_LO_PERM. Keep the tag available for maintenance and engineering, but do not make operators decode internal names during an upset.

Handle bad quality and stale data

A faceplate must make data quality visible. If a value is bad, uncertain, stale, substituted, or simulated, the operator should not have to infer that from a frozen number. For critical status points, show a clear quality indication and define command behavior when quality is bad.

Common practical rules:

Do not show stale analog values as normal live values.
Do not hide communication loss inside a diagnostic tab only.
Do not allow a bad feedback signal to look like a valid stopped or closed state.
Mark simulation and forced values clearly.
Trend or timestamp important changing values when troubleshooting requires sequence.

Quality handling should be tested during commissioning by disconnecting or simulating representative signals, not only by checking normal operation.

Keep alarm interaction simple

If alarms are shown in the faceplate, include only alarms relevant to that object and make their state clear: active unacknowledged, active acknowledged, returned unacknowledged, or normal. The faceplate should not replace the alarm summary, but it should help the operator connect the alarm to the device condition.

Useful faceplate alarm features include:

Current active alarms for the object.
Alarm acknowledge if allowed by project standard.
Alarm disable, shelve, or suppress state if the system supports it.
Link to the alarm help, cause, consequence, and response text.

Be careful with alarm bypass or suppression controls. They should be role protected, logged, and visually obvious while active.

Use consistent units and formatting

Every analog value needs engineering units, decimal precision, and range behavior. Do not rely on memory or a nearby label on another display. If a value is a percentage, say whether it is valve position, controller output, speed reference, load, or level.

Formatting should match the real control precision. Showing a tank level as 63.28491 % usually adds noise. Showing pressure with no decimals may hide meaningful movement. Use the resolution that supports operation and troubleshooting.

Commission the faceplate like control logic

Faceplates should be tested with the PLC or simulator, not reviewed only as static screens. A basic commissioning checklist:

Verify every state indication from real or simulated feedback.
Verify each command in each allowed and blocked mode.
Confirm local/remote behavior.
Confirm permissive and interlock messages.
Confirm alarm states and acknowledgement behavior.
Confirm bad quality, communication loss, and stale data indication.
Confirm role-based access for configuration and bypass functions.
Confirm values, units, scaling, and decimal precision.
Confirm navigation from overview to faceplate and from faceplate to detail/trend.

Record issues against the object template, not only against one screen instance. A template defect repeated across one hundred valves is still one defect pattern, but it can create one hundred operating problems.

Practical rule

A faceplate is finished when an operator can determine control ownership, issue valid commands, understand blocked commands, and identify abnormal conditions without opening three other displays. If the faceplate only looks consistent but does not explain the equipment state, keep working on it.