Your HMI Breadcrumb Should Follow the Plant, Not the Project Tree

Night shift had two chilled water pump popups open side by side. Both titled Pump Detail, both stopped, both with a Start button. The operator meant to bring up the duty pump. The standby ran.

Nothing on either screen was wrong. Neither screen said which pump it was.

You do not fix that as a graphics problem. You fix it as a navigation problem.

Navigation is an operating control

HMI navigation decides where the operator believes they are, which equipment they believe they are commanding, and how many seconds it takes them to get back to the operating picture during an upset. A breadcrumb and an area label are how you write that belief down on the screen.

Three questions need a standing answer:

• Which site, area, line, or cell am I looking at?
• Which equipment is selected?
• Where does this button go, and what scope does this command affect?

The third one is the one projects skip.

ISA-101's four levels are the breadcrumb skeleton

ISA-101.01-2015 Human Machine Interfaces for Process Automation Systems splits operating displays into four levels: Level 1 area overview, Level 2 unit control, Level 3 unit detail, Level 4 diagnostic and support displays. A breadcrumb is really one line stating the operator's coordinates inside that hierarchy.

ISA-101 also makes an HMI Style Guide a project deliverable — write down how displays are drawn and how you move between them. Few projects put the navigation rules in it. Skip it and every screen's back button behaves a little differently, and the operator ends up memorising the differences.

Follow the process hierarchy, not the folder tree

Operators do not think in HMI project folders. They think in process areas and equipment names.

Plant 1 > Utilities > Chilled Water > CHW Pump 02

This is the same screen, and it is no help:

Main Menu > Pumps > Detail Screen > Object 17

The first tells the operator where they are in the process. The second exposes the HMI implementation.

Match the names to the tags, the alarm messages, the work procedures, and the field nameplates. If the alarm reads UTIL-CHW-P02 Trip and the detail screen is titled Pump B, the technician you called out at 3 a.m. asks twice.

Manage the length too. I clip the visible path to about 40 characters and cut from the top of the hierarchy, never from the area and asset names. A breadcrumb too long to read is the same as no breadcrumb.

A detail screen has to state its own identity

Faceplates and popups are where context disappears. Any screen that can send a command should show, at minimum:

• equipment tag or asset name
• area or line name
• current mode and running state
• the scope the command applies to
• the way back to the source overview
• an active trip summary or alarm count, where it matters

Put the identifier in the title. CHW Pump 02 - Detail is safer than Pump Detail. How a popup receives its parameter and proves its own target is a separate job, covered in context passing for reusable faceplates.

Response time belongs in this section too. If a detail screen does not open within about 1 s, the operator clicks again. Now two popups are stacked and there is no telling which asset is on top.

Broad commands need their scope in the label

Reset, Start, and Acknowledge carry no scope on their own. If the screen does not say whether it is one motor or a whole line, the operator guesses.

Action scope	Better label
One motor	Reset CHW-P02
One skid	Reset Skid A Faults
One area	Acknowledge Utilities Alarms
One line	Start Line 3 Conveyor Sequence

For area-wide commands the label is not enough — restrict who can press it. That 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 confirmation dialog should repeat the real target rather than ending at Are you sure?.

If the alarm does not reach the screen, the response procedure exists only on paper

ISA-18.2-2016 is built on the premise that every alarm has a defined operator response. On an HMI where clicking the alarm banner drops the operator on a default asset because the parameter never got passed, that response does not actually happen. The operator reads the wrong trend and decides from it.

So during commissioning, do not test alarm-to-detail navigation on one asset and move on. Mix in copied equipment, equipment in another area, and equipment with a long name.

Do not leave dead-end screens

A dead-end screen carries useful detail but no fast path back to the operating picture. It usually appears when a diagnostic page is bolted on late. Build that Level 4 screen under an engineering folder, wire its back button relative to that folder, and the operator gets thrown out into a configuration menu. Define return targets by process position, not folder position.

Five things to check:

1. Every detail screen returns directly to its area overview.
2. An alarm or trend jump preserves the selected equipment context.
3. A popup opened from a popup still shows the final equipment identity.
4. The alarm summary is reachable from any operating screen.
5. Navigation state survives a refresh or client reconnect, where the platform supports it.

Run it as a scenario: start at an alarm, look at the related trend, open the equipment detail, come back to the area overview. Stop them partway and ask which area they are in. No answer within 2 seconds means the breadcrumb is not doing its job. Having to remember the path is worse.

Check copied screens for links and labels separately

Most HMI projects are built by copying screens. That is efficient, and it copies the navigation defects along with everything else when parameters are not handled.

• Breadcrumb still shows the previous area name.
• Back button returns to a different line overview.
• Popup title has a static equipment name baked in.
• Alarm jump opens the right template with the wrong parameter.
• Trend button opens a default pen group instead of the selected asset.
• Command confirmation shows a generic object name.

The fastest test is to open the same template for two different assets at once. If you cannot tell the two apart at a glance, the labels are short of something. Making the elements inside the screen readable in the first place is in the faceplate design checklist.

Before handover

• Can an operator name the current area within 2 seconds?
• Does every command-capable screen show the exact target asset?
• Do alarm, trend, and faceplate jumps preserve context?
• Are copied screens free of stale labels and wrong return links?
• Are broad-scope commands labelled with their real scope?
• Can operators reach the process overview without browser history or a hidden menu?

Paging through a screen list at FAT will not surface navigation quality. Put the real movement paths on the punch list early.

Next time you are in front of an HMI, ignore the values and read only the title and the breadcrumb. If the area and the asset are not both there within two lines, the operator is currently filling that in from memory.