A PLC and an HMI rarely fail at the same moment. The logic problem shows up as a valve that opens on schedule but at the wrong time; the interface problem shows up as a start button that the operator presses twice because the screen gives no feedback. When the two systems are integrated, those failures arrive mixed together, and a project team that has not planned for them will spend the acceptance window guessing which side of the communication link is at fault. Planning the testing and validation work before integration begins is what separates a controlled commissioning from a debugging session in front of a customer.
The following describes how a project team can structure that work: what to confirm before a single wire is connected, how to stage the tests, what to record, and how acceptance should be signed off. The examples use PowerDe's non-standard automation and steam cleaning equipment projects, where control panels, safety circuits, sensors and operator interfaces are delivered together as one system.
Before integration: agree on what has to be proven
Most integration disputes trace back to a definition that was never written down. Before the PLC program and the HMI screens are built against each other, the team should sit down with the process owner and produce three short documents.
- An I/O list with purpose. Not just address numbers, but what each input and output physically does, what fails safe when power is lost, and which signals are interlocked with safety devices.
- A mode map. Manual, semi-automatic, automatic and maintenance modes, with which HMI screens and which physical controls are active in each. Operators cause a large share of integration faults by working in the wrong mode.
- Alarm and interlock definitions. Every alarm needs a trigger condition, a priority, an operator action and a reset path. A heater that overheats, a tank running dry and a pressure reading that goes out of range must behave differently, and that behaviour has to be defined before it is coded and tested.
For an equipment supplier such as PowerDe's manufacturing automation team, these documents are normal engineering deliverables alongside the electrical schematic and the PLC/HMI program, so a buyer who asks for them early gets them without extra cost.
Stage 1: test the controller alone
Do not connect the HMI to a controller that has not been exercised. The first pass is a bench or panel-level check: each output energises when its logic condition is met, each input is read with the correct polarity, and each interlock does what the document says. Where real machinery is not yet available, simulate the inputs with switches or a test rig.
The point of this stage is to make later faults unambiguous. If the controller has already been proven against its own logic, then when an operator reports that a screen "did not work", the team can look at the interface and the communication link first instead of re-reading the ladder logic.
Stage 2: test the communication link under realistic conditions
Once the HMI is paired with the PLC, the tests shift to the link between them. A connection that works on a bench two metres away can behave differently on a factory floor with long cable runs, variable-frequency drives and motors. The team should deliberately check:
- What the screen shows when the cable is unplugged, and whether an alarm appears rather than a frozen display.
- Whether operator commands sent during a communication interruption are discarded, repeated, or queued, and which of those is the intended behaviour.
- Whether values written from the HMI survive a power loss and restart, or revert to the configured default.
- Whether the display refresh rate is fast enough that the operator can see the machine state actually changing, and whether password and permission levels are enforced at the controller rather than only on the screen.
These are not exotic scenarios. They are the faults that surface weeks after handover as "the machine is unreliable", when the machine itself is fine and the interface behaviour was never specified.
Stage 3: safety interlocks and abnormal conditions
Validation is not a longer version of functional testing. Functional testing asks whether the machine does what it should. Validation asks whether it refuses to do what it should not. On equipment with heaters, pumps, pressure vessels and moving parts, this stage matters more than any other.
A practical approach is to write an abnormal-condition list and work through it with a stopwatch and a notepad. Simulate the sensor fault. Break the circuit. Run the tank low. Trip the emergency stop at different points in a cycle. For every case, record three things: what the controller did, what the HMI displayed, and what the operator would have understood from that display. If the machine stops safely but the screen still shows the pre-fault state, the safety outcome is acceptable and the validation still fails, because the next operator will not know why the line is stopped.
PowerDe's hardware testing services cover this kind of work as a defined scope — control panel and HMI testing, alarm and protection function testing, electrical safety checks and fault reproduction — and the resulting report is written to feed back into design changes rather than to be filed.
Stage 4: run the real process with the real operators
The last stage is the one most often cut for schedule reasons, and it is where the most expensive defects are found. Run the machine through its actual cycle for an extended period with the people who will operate it, not with the engineer who wrote the program. Watch for the things that no bench test exposes: a step that is easy to skip by accident, a screen that buries a control operators need every hour, an alarm that sounds during normal start-up so people learn to ignore it.
Where the equipment is part of a production line, cycle time and stability under continuous load should be measured rather than assumed. Where the equipment carries process media, the same logic applies to the physical side; a PowerDe steam cleaning machine is a good illustration of an integrated system whose control layer has to be validated against its process layer: the operator interface has to make mode selection, heating state and protection status legible while the machine's pressure, temperature and water-supply behaviour is verified separately.
What to record, and what acceptance should look like
A validation plan is only useful if it produces evidence. Three records carry the most value on an automation project:
- A test matrix. Each requirement or interlock on one axis, each test stage on the other, each cell marked pass, fail or not applicable with a reference to the record.
- A defect log with closure. Fault description, cause, fix, who verified the fix, and retest date. An issue closed only by the person who made the change is not closed.
- An acceptance protocol. The list of items that must pass before the customer signs, agreed in advance so that the factory acceptance test is a rehearsal rather than a negotiation.
The team that plans this work early spends less time on it overall. Integration defects found before the machine ships cost an afternoon of rework; the same defect found during on-site commissioning costs a site visit, an idle production window and a customer who has lost confidence in the delivery schedule. For a project team, the cheapest intervention is the one that happens while the I/O list is still a draft.
