Written by An industrial HMI should do more than display machine status. During a fault, it should help the operator understand what happened, decide what action is allowed, and return the equipment to a known state safely. Poorly structured screens can increase recovery time, encourage workarounds, and make useful machine data difficult to interpret.
This guide explains how to design an HMI for practical troubleshooting on custom machines, assembly stations, test systems, and automated production equipment.
Start with the operator’s troubleshooting task
HMI design is more effective when it begins with real operating situations rather than a list of available tags. Ask what the user needs to know when the machine stops:
- What part of the process has stopped?
- Which condition caused the stop?
- Is the problem related to a component, a product, a safety device, or an operating sequence?
- What can the operator check without opening the machine or entering a restricted area?
- What action is permitted to restore operation?
Different users may need different levels of information. An operator may need a clear fault message and a guided recovery sequence. A maintenance technician may need input states, actuator feedback, timers, counters, and diagnostic details. A production or quality manager may need status history and cycle information.
These needs do not have to be placed on one crowded screen. A layered interface can present simple information first and make deeper diagnostics available when required.
Build a clear HMI screen structure
A consistent navigation structure reduces the time users spend searching for information. The exact layout depends on the machine, but a practical structure often includes the following levels:
- Overview: machine mode, production state, active alarms, and the current process step.
- Station view: the status of individual workstations, fixtures, cylinders, motors, sensors, and test devices.
- Alarm and event history: active, acknowledged, and previous messages with useful time information.
- Manual or service screens: controlled access to individual movements and component checks.
- Settings and recipes: approved process values, configuration data, and access-controlled adjustments.
The overview screen should answer the question, “What is the machine doing now?” It should not attempt to show every signal. Use a visual hierarchy so that the current state, stopped condition, and required operator action are immediately visible.
For equipment with several stations, the overview can show the process flow and highlight the station that is waiting, blocked, or faulted. This is often more useful than displaying a large collection of animated components without clear status meaning.
Write alarms that explain the problem
An alarm message should describe a condition, not merely repeat a tag name. Messages such as “Sensor fault” or “Axis error” may be technically correct but are often insufficient for recovery.
A more useful alarm identifies the affected function and, where appropriate, the expected condition. For example, a message can indicate that a clamping sensor was not detected after the clamp command, or that a part-present signal was lost during a verification step. The wording should remain concise enough to read quickly.
Separate cause, consequence, and action
Where the HMI allows it, structure diagnostic information into three parts:
- Cause: the condition that prevented the sequence from continuing.
- Consequence: the process step or station that is currently held.
- Action: the permitted checks or reset procedure.
For example, the main alarm may identify a missing confirmation from a fixture sensor. A secondary help area can tell the operator to verify part seating and check for a visible obstruction, provided those checks are safe and within the operator’s responsibilities.
A reset button should not be used as a substitute for explanation. If resetting the same alarm repeatedly does not address the cause, the interface should make that clear and direct the user toward an appropriate escalation path.
Use machine states consistently
Operators should be able to distinguish between normal waiting, production interruption, manual operation, setup, and a safety-related stop. These states should have consistent names and visual treatment throughout the HMI.
Common state categories may include:
- Stopped and ready
- Automatic cycle active
- Waiting for material or operator input
- Blocked by a downstream condition
- Faulted and requiring intervention
- Manual or setup mode
- Safety circuit not satisfied
Do not rely on colour alone. Combine colour with text, symbols, position, or a clear status label so that the meaning remains understandable in different lighting conditions and for users who cannot distinguish every colour variation.
The same state should also be represented consistently in station views, alarm lists, and status indicators. Inconsistent terminology creates uncertainty, especially when several machines or stations are operated together.
Make diagnostics reflect the control system
HMI diagnostics are only useful when the control architecture provides reliable status information. A command signal alone does not prove that an actuator completed its movement. Similarly, an output being energised does not necessarily confirm that a valve, motor, clamp, or tool is functioning as intended.
Where the process requires confirmation, the control logic should distinguish between commands and feedback. The HMI can then show meaningful states such as commanded, moving, confirmed, timed out, or not available.
This requires coordination between the electrical design, PLC program, field devices, and HMI. The selection of the PLC and field equipment should therefore consider diagnostics and maintainability, not only processing capacity or initial hardware cost. Related planning considerations are discussed in how to select a PLC and field equipment for an industrial automation project.
Design manual and service screens with control
Manual screens are valuable for setup, maintenance, and fault investigation, but they should not become an unrestricted collection of movement buttons. Each manual function should have a defined purpose, suitable access control, and clear indication of the conditions required for operation.
Useful design practices include:
- Show the current machine mode and access level on every service screen.
- Display the feedback associated with the selected actuator or device.
- Prevent conflicting commands where simultaneous movement could create a hazard or process problem.
- Use confirmation steps for actions that may release, clamp, move, or otherwise change the machine state.
- Provide a clear route back to automatic operation.
Manual controls must always operate within the machine’s safety concept. An HMI should not be treated as a replacement for physical guarding, safety devices, or the required control functions.
For broader design guidance, connect the HMI structure with the machine’s maintenance strategy. The principles described in designing custom machines for easier maintenance are also relevant to diagnostic access, component identification, and service-oriented information.
Use history without overwhelming the user
Alarm history can help technicians identify recurring conditions, but only if events are recorded and presented meaningfully. Avoid filling the history with repeated messages caused by one underlying event. Where practical, group related notifications or distinguish the primary fault from consequences that follow it.
Useful history details may include:
- Alarm description
- Time and date of occurrence
- Time of acknowledgement or clearance
- Machine or station location
- Relevant part, batch, or cycle reference when the system supports it
Historical data should have a defined purpose. If users cannot interpret or act on the information, more data will not automatically improve troubleshooting. For projects that include commissioning and machine data collection, it is useful to define which events should be recorded and how the information will be reviewed. See why data collection matters during custom machine commissioning for related considerations.
Validate the HMI with realistic faults
Screen review alone is not enough. Test the HMI while simulating or observing realistic conditions: a sensor that does not switch, a part that is incorrectly positioned, a device that reaches a timeout, a communication interruption, or an operator request that is not yet satisfied.
During these checks, ask:
- Can the operator identify the affected station quickly?
- Does the message describe the actual reason for the stop?
- Is the next action clear and safe?
- Does the screen show whether the condition has cleared?
- Can maintenance personnel access the necessary diagnostic information?
- Are recovery steps consistent with the machine sequence?
Record confusing wording, missing feedback, and unnecessary navigation steps. These observations can lead to changes in the PLC logic, sensor selection, mechanical access, or work instructions—not only changes to the screen layout.
Conclusion
A practical industrial HMI turns machine information into usable decisions. The strongest designs begin with operator tasks, use consistent machine states, provide alarms with clear meaning, distinguish commands from feedback, and offer deeper diagnostics without cluttering the main screen.
When HMI design is developed together with controls engineering, machine safety, maintenance, and commissioning activities, troubleshooting becomes more structured. The result is not simply a more attractive interface; it is a clearer connection between machine behaviour and the people responsible for operating and maintaining it.