How to Keep a Reusable HMI Faceplate From Commanding the Wrong Pump

Three weeks into commissioning, an operator opened the P-102 popup, pressed start, and P-101 ran. The graphic was fine. The P-102 button on the overview screen had been copied from P-101 and still passed P101 as its parameter. The popup header carried no equipment ID, and both pumps were stopped, so every displayed value looked identical. There was no way for the operator to catch it.

Reusing one motor faceplate across 80 motors means a single wrong parameter picks one of 79 wrong targets. None of that is a graphics problem.

ISA-101.01-2015 organizes HMI displays into a hierarchy, from Level 1 plant overviews down to Level 4 detail and diagnostic displays. A faceplate popup hangs off the bottom of that hierarchy — but how context travels down it is left to the project's HMI style guide, and most projects never write that part down.

Pin down five things before drawing anything:

What object or tag prefix is passed in.
Which display name the operator sees.
Which commands are allowed from this popup.
Which alarm sources and trend pens belong here.
What happens when the context is blank, stale, or invalid.

The text on the button that opened the popup is not evidence. The popup has to know its own technical target and prove it on screen.

Pick exactly one stable equipment key

An equipment ID like P101, a tag prefix like Area01_Line02_P101, an object path in the SCADA tag model — any of them works. Picking one and having the whole project use only that one is what matters.

A usable key is:

Stable across display text changes.
Unique within the project.
Mappable to tag names, alarm sources, and historian points.
Independent of the HMI's current language.
Not built from a screen coordinate or a temporary row number.

The operator label is Feed Pump 101 today and becomes P-101 Feed Pump at the next documentation cleanup. If that edit breaks the popup binding, the design was wrong.

Make the header prove the target

The P-101/P-102 incident above needed one header line to not happen. Fix the equipment ID, description, area, and current mode at the top of the popup. It is not decoration; it is the operator's last check before pressing anything.

Field	Reason
Equipment ID	Confirms the technical target
Description	Lets operators recognize the physical asset
Area or line	Prevents confusion between similar units
Current mode	Shows whether local, remote, manual, or auto applies
Communication quality	Says whether the values can be trusted
Permission state	Explains why a command button is disabled

If the title only says "Motor Detail", the operator infers the target from surrounding screens. Do not make people infer during alarm response. How to make state readable inside the popup itself is covered separately in the faceplate design checklist.

Indicator binding and command binding are different jobs

The common approach is to take a tag prefix and derive every indicator and command tag by string concatenation. For indicators, fine. For commands, no.

The problem with concatenation is that it fails silently by succeeding. P101 + _StartCmd names a tag that exists, and that tag starts a real pump. The popup raises nothing.

Validate a command button before it is live:

The command tag exists in the equipment registry for this equipment type — not merely that a string was formed.
The command is allowed in the current mode.
The logged-in user holds the required role. This is what IEC 62443-3-3 SR 2.1 (Authorization enforcement) asks for, and on an HMI it usually lands at the level of individual buttons.
The equipment is not interlocked, permissive-failed, or in local control. Follow the same rules as permissive and interlock display.
The feedback tag you will check afterward comes from the same equipment key.

A bad parameter must fail closed. Blocking the command and showing an engineering error beats sending start to whatever tag name the string happened to form, every time.

Tell a broken binding apart from bad quality

This is the part that gets flattened most often in the field. A popup with a broken binding and a real device with a dead link look the same on screen: zeros and grey buttons. Operators read it as the second one. A stopped pump.

The quality code separates them.

OPC UA puts severity in the top two bits of the StatusCode (Part 4, StatusCode). code & 0xC0000000 equal to 0x00000000 is Good, 0x40000000 is Uncertain, 0x80000000 is Bad. Bind to a node that does not exist and the server answers Bad_NodeIdUnknown. Lose the link to a node that does exist and you get Bad_NotConnected, or, depending on the server, the last value with Uncertain_LastUsableValue. Different causes, different thing to tell the operator.
Classic OPC DA does the same with the top two bits of the quality byte: 0xC0 is Good, 0x40 is Uncertain, 0x00 is Bad.

So split the popup's failure text. Blank key, or a key the registry does not know, reads as "configuration error". Tag present but quality Bad reads as "communication fault". Either way no values, but a different person gets called. Folding quality into the tag layer itself is covered in handling tag quality codes.

Alarm and trend links are where context betrays you

Context errors rarely show up in live values — any pump's values look plausible. They show up in the links.

From a pump popup, open the alarm detail and confirm only that pump's alarm sources are filtered.
Open the trend link and confirm the PV, output, mode, and feedback pens all belong to the same asset.
Confirm the equipment filter survives a shelve. In the ISA-18.2-2016 alarm state model, shelved is an operator-initiated temporary state, normally with an automatic unshelve timer; it must not read on screen like suppressed-by-design or out-of-service.
Confirm a popup opened from the alarm banner uses the same equipment key as the alarm source.

Hand-maintaining popup, alarm, and trend mappings separately means one rationalization pass pulls them apart. Generate all three from one equipment registry.

Some HMI platforms reuse an already-open popup window and only swap the parameters. Whatever binding does not get swapped stays behind.

Open P-101, then immediately open P-102. Values, commands, alarm link, and trend link must all change together. If any of them lags, that platform needs a single-instance rule enforced.
Leave a popup open and navigate to another area screen. Is the target still unambiguous from the header alone?
Take an open popup through a comms loss and recovery. What a PLC restart does to command state is its own problem, covered in command reset after a PLC restart.
If runtime language switching exists, switch language with the popup open. If display text was being used as a key, this is where it collapses.

The eight-case matrix to run before copying

Run this before the popup pattern gets copied across the project. Eight cases, about twenty minutes. Cheaper than fixing it after it lands on 80 units.

Test case	Expected result
Valid motor key	Correct status, commands, alarm link, trend link
Valid valve key	Only valve-specific fields and commands appear
Blank key	"Configuration error", no commands
Key not in registry	"Configuration error", no commands
User without the role	Values visible, commands disabled with a reason
Local mode	Remote commands disabled
Tag with Bad quality	"Communication fault", commands blocked per site standard
Launched from alarm banner	Popup target matches the alarm source

Screenshot one good case and one failed case. Six months later, when someone asks why a button is grey, you can answer "HMI bug" or "working interlock" in five seconds.

Five mistakes that keep coming back

Passing display text as the key. Display text changes for language, readability, and naming cleanup. Use it in the header, never in a binding.

Letting each screen build parameters its own way. Different concatenation rules per overview screen means faceplates behave differently by area. This is exactly why ISA-101 makes the style guide a project deliverable.

Hiding the reason a command is disabled. A grey button with no reason generates phone calls. Put a short reason next to it: Local mode, No start permissive, User role required, Bad feedback quality.

Assuming alarm names match tag names. After rationalization or a system migration, alarm source names routinely diverge from tag names. Check the mapping table instead of deriving it from a string rule.

Not launching popups after a tag import. A bulk import can break one parameter column while live values still look correct. That is how you end up with a popup where only the alarm link or the command target is wrong.

Next time you have a faceplate open, ignore the values and compare the equipment ID in the header against the tag name the command button actually writes. More projects than you would expect have those two out of step. Keeping the operator oriented while moving between screens is the other half of this, in breadcrumbs and area context.

A popup is an interface contract, not a screen