HMI screens: what the operator needs to see

On a stopped machine, the operator needs answers to a specific situation: what stopped the sequence, what the system is waiting for and which mode is active. A large collection of tags does not provide those answers by itself. Start an HMI revision with actual tasks at the station rather than choosing new icons, colours and visual effects.

Make the machine state clear

The operator should identify the machine, mode, current step and active recipe without navigating through several screens. Distinguish running, waiting, stopped and not ready. Automatic describes a mode, but does not explain whether the sequence is processing a part, waiting for material or paused. When a condition is missing, show that condition rather than relying on a stationary equipment graphic.

Use names consistent with drawings and the language used on the shop floor. Device numbers help maintenance, but a code alone may not explain an issue to an operator. Add a short description. Keep frequent operating information on the main view and technical detail in a predictable place. Basic controls should not move between similar screens, and alarms should remain accessible.

Use colour consistently

Agree a small set of colours and their meanings. An alarm, warning, active state and actionable control should be distinguishable. Avoid a normal-running display in which every object has a strong colour. An actual abnormal condition then becomes harder to spot. This is a matter of consistent signalling, not a requirement to replace the entire visual style of an existing panel.

Do not communicate status through colour alone. Include text, a symbol or a clear description change. Check the display on the intended panel, under the station's lighting and from the operator's working position. Small text and thin lines can look acceptable on an engineering monitor but be difficult to read at the machine. The target device needs its own review.

Give alarms context and priority

Identify the device and the condition that was not met. Machine fault does not distinguish communication loss, missing position feedback and an unfinished sequence step. Assign priority according to consequence and required response, rather than the order in which alarms were added. Where many messages follow one event, help users locate the initiating alarm. Relevant timestamps include occurrence, clearance and acknowledgment.

Acknowledging an alarm does not remove its cause. The display should distinguish active alarms, cleared alarms and those awaiting acknowledgment according to the project's rules. A global reset button is not enough to explain machine state. Any suggested action must follow the operating procedure and must not encourage bypassing interlocks or safeguards.

Keep operating and service tasks distinct

An operating view supports routine process work. Diagnostics can bring together the start condition, command, feedback and waiting time. Permission to change parameters should reflect the user's responsibility. Hiding a control deep in a menu is not access protection. Make it clear which values are read-only measurements and which are adjustable settings.

Use trends when a history explains a problem, such as an unstable measurement or delayed response. Include units, a readable scale and the time range. Not every tag needs a chart. When communication is lost, identify unavailable or stale values. Displaying the last received number as if it were current can mislead the operator.

Recipes and consequential actions

Distinguish a value entered on the panel from the value accepted by the PLC. Show whether a change was applied, rejected or is pending. Define permitted ranges, units and when a new recipe takes effect. Check panel reconnection behaviour. An unconfirmed write should not look like a successfully changed process setting.

Use a meaningful confirmation for actions with significant consequences, such as replacing a saved recipe. Describe what will happen. Identical confirmation prompts for routine tasks encourage automatic dismissal. A dialog is not a machine safety function. In HMI and SCADA development, agree these behaviours alongside the PLC interface and the operators' working procedures.

Verify through real tasks

Before a revision, collect existing screenshots and examples of operating difficulties. During acceptance, walk through normal operation, a missing start condition, an alarm, recipe selection and communication loss. Observe whether the operator finds the correct view without a programmer's help. Record unclear messages and unnecessary navigation. Those are specific improvements to make, even when the new screen already looks tidy.