HMI Permissive and Interlock Display Checklist

Why permissive displays deserve design time

Operators do not only need a start button. They need to know why the start button is not available. A motor, valve, burner, pump, robot cell, or transfer sequence may depend on many permissives and interlocks. If the HMI hides those conditions behind one gray button, every failed start becomes a radio call to maintenance.

A good permissive display answers three questions quickly:

Is the equipment allowed to start now?
If not, which condition is blocking it?
Did a condition trip after the equipment was already running?

The details matter because permissives, interlocks, inhibits, bypasses, and alarms are related but not identical.

Use clear words for different control concepts

Many projects use the same color or label for several different ideas. That makes troubleshooting slow. Define the terms in the project and use them consistently.

A practical distinction is:

Permissive: a condition required before a command may start.
Interlock: a protective condition that can stop or prevent operation.
Trip: an interlock action that stopped equipment or sequence execution.
Inhibit: a configured condition that prevents an action from being attempted.
Bypass: a deliberate override of a condition, usually controlled by permission and logging.
Ready: the combined result that says a command can be accepted.

The HMI should not show all of these as the same red light. A missing permissive before start is not the same event as a running pump tripped by low suction pressure.

Show the combined status and the individual reasons

For normal operation, the operator needs one clear summary: Ready, Not Ready, Running, Stopped, Tripped, Local, Maintenance, or Disabled. For troubleshooting, the operator needs the individual reasons underneath.

A useful equipment faceplate usually includes:

Command availability: start allowed, stop allowed, reset allowed.
Current mode: auto, manual, local, remote, maintenance.
Active blocking conditions.
Active trip conditions.
Bypassed or inhibited conditions.
First-out cause, if the controller provides one.
Timestamp of the latest trip or reset.

Do not force the operator to open the PLC program to find the one false bit in a long rung. The HMI can expose the same logic in a safer, more readable way.

Separate pre-start checks from running trips

Some conditions matter only before start. Others must be true while running. Mixing them in one list creates noise.

Examples of pre-start permissives:

Control mode is remote.
Safety system is healthy.
Downstream equipment is ready.
Valve is confirmed in the required position.
No active maintenance lockout.
Required utility pressure is available.

Examples of running interlocks:

Motor overload.
Low suction pressure after start delay.
High discharge pressure.
Conveyor jam detected.
Valve failed to reach commanded position.
Communication loss to a required device.

A pump may be allowed to start with suction pressure low for a short priming delay, then trip if pressure does not recover. The display should make that timing visible enough that operators do not call it random.

First-out is worth implementing

When a sequence stops, many bad conditions may appear at once. A downstream valve closes, pressure falls, flow stops, and a motor feedback drops. Without first-out capture, the HMI shows a wall of red and nobody knows which condition happened first.

First-out logic records the first condition that caused the trip or sequence abort. It does not replace the active condition list. It gives the starting point for troubleshooting.

For field use, show:

First-out text.
First-out timestamp from the controller or SCADA event time.
Current active interlocks.
Reset requirement.
Whether first-out is retained until reset.

If the PLC scan captures first-out, document the priority and latching behavior. If SCADA calculates it from alarms, be honest about timestamp resolution and network delay.

Display bypasses as operating risk, not as decoration

Bypasses are sometimes necessary during commissioning or maintenance. They are also easy to forget. A bypassed permissive should be obvious without making the screen unreadable.

Minimum HMI behavior for bypasses:

Show a bypass summary on the equipment faceplate.
Show which exact condition is bypassed.
Require an appropriate role or key switch for changes.
Log who changed it and when.
Make bypass state survive screen navigation and client restart.
Consider a timeout or shift handover review for temporary bypasses.

Avoid hiding bypasses only on an engineering page. If a pump is running with a low-flow interlock bypassed, the operator should not need to know a secret screen path to notice it.

Color and text choices

Color alone is not enough. Operators may use different monitors, dim control rooms, remote clients, or printed screenshots. Pair color with text and shape.

A simple convention works well:

Green or neutral: satisfied condition.
Amber: not satisfied but not tripped, such as a missing start permissive.
Red: active trip or safety-related stop condition.
Blue or outlined: bypassed, inhibited, or forced condition, depending on site standard.
Gray: unavailable, disabled, or no data.

Use exact condition text. "Not Ready" is a summary. "Discharge valve not open" is a reason. "Interlock 12" is a maintenance clue at best and a poor operator message.

Data quality belongs on the same display

A missing interlock signal can be more dangerous than an active interlock. If the HMI receives bad quality from an OPC UA server, remote I/O rack, safety gateway, or PLC communication link, the permissive display should show that uncertainty.

Important quality cases:

Signal is bad or stale.
Device is in local mode and command feedback may not follow SCADA.
Safety controller communication is lost.
Remote rack is faulted.
The condition is forced in the PLC.
The HMI value is substituted or simulated.

Do not show a bad-quality permissive as simply satisfied or not satisfied. Unknown should be visible as unknown.

Commissioning checks

During factory acceptance or site commissioning, test the display with real logic changes, not only by looking at static screens.

Useful checks:

Toggle each permissive false and confirm the correct text appears.
Start equipment, create a running interlock, and confirm trip text and first-out behavior.
Confirm command buttons disable for the right reason.
Confirm reset clears latched trip text only when the controller clears it.
Confirm bypass indication appears on the main faceplate.
Confirm alarm, historian, and event records use the same naming as the faceplate.
Confirm redundant HMI clients show the same state after restart.

The goal is not a pretty list of bits. The goal is a screen that shortens the time between "it will not start" and the real cause.

What to put in the project standard

For repeated equipment, make permissive and interlock displays part of the HMI template standard. Define naming, colors, first-out behavior, bypass indication, and data quality handling once. Then test every template instance against the same rules.

A small amount of display discipline prevents a common operations problem: every motor faceplate looks similar, but each one explains failures in a different way. Consistency is what lets operators move from one area to another without relearning the control logic every time.