HMI faceplate design: motor, valve and PID loop
A faceplate is the panel that opens when an operator clicks an object on a process screen. The screen shows the state of every motor and valve at a glance; the faceplate shows everything about one of them and is where the operator gives commands. A good faceplate answers three questions in two seconds: what state is it in, why, and what can I do about it.
In short
- Header: tag, description and the same state image the process screen uses.
- Body: mode, commands, values, then interlocks and alarms, in that order, always in the same place.
- One layout per object type: every motor looks like every other motor.
- Say why: when a command is blocked, show the missing permissive instead of a dead button.
- Tuning and maintenance live on a second tab, away from the operator's main view.
What a faceplate is for
A process screen has to stay calm: grey equipment, colour only for states and alarms, no numbers that are not needed. That leaves no room for a start button, a setpoint field or a list of interlocks on every object. The faceplate solves it by moving the detail one click away. The operator selects an object, the faceplate opens over the screen, the operator acts, and it closes. This is the same idea as the detail level in the screen hierarchy, applied to a single object.
Two consequences follow. First, the faceplate must be predictable: nobody should have to read it to find the Start button. Second, it must be honest: it shows the real state reported by the field, not the command that was sent.
Anatomy of a faceplate
Whatever the object, the same five zones appear from top to bottom. Keep their order fixed across your whole project:
- Header. Tag, description and the state image. Use the same image the object has on the process screen, so the operator recognises it instantly. A close button, always in the same corner.
- Mode. Auto, manual, local. The active mode is filled; the others are outlined. Changing mode is a command like any other.
- Commands. Start and stop, open and close, or setpoint entry. Only the commands that are allowed in the current mode are enabled.
- Interlocks and permissives. The conditions that must be true before the object can run, each with its own status dot. This is the zone operators miss most when it is absent.
- Alarms and links. The active alarms for this object with their priority, and a row of links to the trend, the parameters and the maintenance data.
What goes on each type of faceplate
Motor, pump and fan
The nine states of the motor state list are the starting point. On top of the zones above, add the running feedback (for example speed or current) when the project measures it. The start command is blocked while an interlock is missing: grey the button and list the missing condition in the interlock zone.
On/off valve
Open and close commands, the position feedback from both limit switches (open, closed), and a state for the case where neither is made: travelling, or stuck. If the valve has a fail-safe position, say it in the header. See the valve symbols guide for the state images.
Modulating valve and PID loop
| Item | What to show |
|---|---|
| PV | The process value, with its unit, large and in the same place on every loop. |
| SP | The setpoint, editable only in auto or cascade. Show the allowed range and reject values outside it. |
| OUT | The controller output as a percentage, editable only in manual. |
| Mode | Manual, auto, cascade. The active one filled. |
| Bar or mini trend | PV, SP and OUT over the last minutes, so the operator sees the trend of the loop without leaving the faceplate. |
| Alarms | High and low limits with the active ones highlighted. |
Put the tuning parameters on a second tab. They are for the person commissioning the loop, not for the operator on shift, and an accidental change to them can destabilise the process.
Rules that keep every faceplate readable
- One faceplate per object type, reused for every instance. The operator learns the motor faceplate once. Ten variations of it are ten things to learn.
- Same position, same order. Mode on the same line, commands below it, alarms at the bottom. Muscle memory beats clever layout.
- Show feedback, not the command. A running motor is green because the contactor and the speed feedback say so, not because the Start button was pressed. If they disagree, show the "no feedback" state.
- Colour only for state and alarm. Buttons are neutral. Reserve green, yellow, orange and red for what they mean, as in the calm palette.
- Dangerous commands need a deliberate action. A confirmation, a hold-to-act or a two-step command, depending on what the command can damage. Routine commands should not need a confirmation, or operators learn to click through them all.
- Do not hide the object. The faceplate should open close to the object that was clicked and not cover the equipment it controls or the alarm banner.
- Size for the screen and the user. Text of at least 14 px, and buttons large enough to hit with a gloved finger on a touch panel.
- Log what the operator does. Commands and setpoint changes are normally recorded with the time and the user. Plan for it from the start.
Building them in practice
Every HMI platform has its own way of making a reusable popup or object type, and the vocabulary changes from one to another. The design above does not depend on it: draw one faceplate per object type, bind it to the tags of the instance that was clicked, and open it from every instance on the process screens. The integration guides cover the import steps for the common platforms.
The header image is the one piece you draw once and reuse. In the Symbol Builder you can draw the object and export one image per state in a ZIP, so the header of the faceplate and the object on the process screen are literally the same image. Changing a colour later changes both.
Draw the state images for your faceplates
Draw a motor, valve or pump once and export every state (stopped, starting, running, no feedback, manual, disabled, fault) as PNG or SVG. The builder is free to use, no account needed to draw; downloads need a free account, 5 a month on Free.
Open the builder → Read the 9 motor states →Frequently asked questions
What is an HMI faceplate?
The panel that opens when an operator clicks an object on a process screen, such as a motor, a valve or a PID loop. It shows the full status of that object (state, mode, values, interlocks, alarms) and holds its commands. The process screen shows state at a glance; the faceplate is where the operator acts.
What should a motor faceplate show?
The tag and description, the current state using the same image as the process screen, the mode (auto, manual, local), the start and stop commands, the reason a start is blocked when a permissive is missing, the active alarms with priority, and links to the trend and maintenance data.
What should a PID loop faceplate show?
The process value, the setpoint and the output side by side, the mode (manual, auto, cascade), the active alarms, and a bar or small trend with the three values over the last minutes. Tuning goes on a second tab.
Does ISA-101 require faceplates?
No. ISA-101 does not prescribe a faceplate layout; it asks for consistency. The same kind of object should look and behave the same everywhere. Defining the faceplates is normally part of the project's HMI style guide.
How do I build a faceplate in my HMI software?
Each platform has its own mechanism for reusable popups or object types. The design rules are the same: one faceplate per object type, bound to the tags of the clicked instance, opened from every instance. The state images for the header can be exported from the Symbol Builder.
Keep reading
- HMI screen hierarchy — where the faceplate sits among the display levels.
- The 9 motor states every HMI should show — the states the faceplate header displays.
- Alarm management — how alarm priority is shown on screen.
- The calm HMI colour palette — what colour means on a faceplate.
- HMI platform guides — importing symbols into your software.
- Ask the community — a faceplate layout you want a second opinion on.