Operator Screens Should Follow the Process

Start with Process Context

The overview should identify the active area, operating mode, current sequence or production state, main flow path, equipment availability, key measurements, and active abnormal conditions. The operator should be able to understand the plant status before opening an equipment faceplate.

A CIP system may need recipe, current step, elapsed or remaining condition, target and actual temperature or conductivity, active flow path, hold reason, and completion status. A pumping station may need wet-well level, active duty pump, standby availability, discharge pressure or flow, and the reason additional pumps are or are not staged. A treatment plant may need area state, tank levels, pump and blower availability, valve path, and alarm summary.

The screen does not need to display every tag at once. It needs to present the information required for the current operating decision.

Present Command, Feedback, and Mode Together

Colour alone is not enough to define equipment state. A pump object should distinguish:

• command requested;
• run feedback proven;
• ready or unavailable;
• local, remote, manual, or automatic mode;
• process permissive blocked;
• electrical or drive trip;
• communication loss;
• maintenance isolation.

A valve should show command, actual end position, movement, timeout, and feedback mismatch. A VFD object may need ready, run, trip, local/remote, speed reference, actual speed, and communication health.

Command and feedback should be visible in the same context so the operator can distinguish a failed command from an intentional stop or blocked start.

Explain Why a Command Is Unavailable

Repeated command attempts are often caused by hidden permissives. The HMI should present the relevant missing conditions for the selected equipment or sequence in clear operating language.

A denied start because the upstream level is low is different from a motor overload trip. A sequence held because a valve is not proven open is different from a communication failure. These conditions require different operator or maintenance actions and should not be reduced to one generic fault indication.

The displayed wording and the PLC condition must come from the same control philosophy. The screen should not invent explanations that are not tied to the actual logic.

Structure Alarms Around Consequence and Action

Alarm text should identify the asset, condition, and useful response without exposing raw programming names. Priority should reflect consequence. A warning, start inhibit, process hold, and protective trip should not be presented as equivalent events.

Where practical, the alarm should link directly to the relevant process area or equipment faceplate. Acknowledgement should not hide an unresolved condition; the visual state should remain clear until the trigger returns to normal or the defined reset condition is met.

Alarm summaries, event history, and trends should help the operator establish sequence: what happened first, what equipment changed state, and what condition remains active.

Define Manual Controls and Command Ownership

Manual mode is required for testing, maintenance, and recovery, but its limits should be visible. The HMI should show which protections remain active, whether manual operation inhibits automatic sequencing, and which command source currently owns the equipment.

Local selector, panel pushbutton, HMI manual, automatic sequence, and SCADA command require a defined priority. The operator should never be uncertain whether a command failed because another source has control.

Bypasses and maintenance overrides should be controlled, time-limited where appropriate, clearly indicated, and included in the alarm or status summary.

Design for Abnormal Conditions

Screens should be reviewed against failure scenarios, not only normal animation. Useful scenarios include:

• missing run or position feedback;
• invalid or failed analogue signal;
• sequence timeout;
• communication loss;
• unavailable duty equipment;
• active standby transfer;
• partially isolated plant;
• power restoration;
• E-stop reset;
• contradictory field feedback.

The review question is whether the operator can identify the affected area, understand the reason, and choose a valid action without searching through multiple unrelated pages.

Verify During FAT and Commissioning

FAT should confirm screen navigation, command permissions, state indications, permissive explanations, alarm priorities, manual-mode boundaries, trend selection, and behaviour during simulated failures. Commissioning confirms the same design with real equipment timing, process response, and operator input.

Changes made on site should preserve the common state model and be reflected in the final HMI, PLC logic, alarm schedule, and operating notes. A screen is complete when it supports correct operation and diagnosis, not when every available tag has been placed on a graphic.

Next steps: Back to Engineering Notes · PLC, HMI & SCADA service · View project references · Discuss Scope