Start the plan with the equipment list, not the software
Before a single ladder logic block is written, list every device that will sit on the network: each PLC CPU, I/O rack, drive, HMI panel, sensor that reports through the bus, and any instrument the integrator expects to read. Next to each device write the interface it actually uses — EtherNet/IP, PROFINET, Modbus RTU over RS-485, a hardwired digital signal, or an analogue 4–20 mA loop. Two-thirds of integration arguments on site trace back to this list being written after the design freeze instead of before it.
For a machine built to a buyer's own requirement rather than a catalogue model, that list belongs in the same document as the functional description. Customized steam cleaning equipment is specified this way, because the control scope of a custom build is different every time: one unit may need a battery charge state read from a battery pack, another may need a fixed 220 V unit's heater contactor and protection functions supervised by the PLC.
Define the I/O and signal table line by line
The test plan should carry a signal table with one row per signal and the following columns filled in: signal name, direction, voltage or signal type, the module or port it lands on, the PLC tag it maps to, the HMI object it is displayed on, and the acceptance method. "Start button" is not an acceptance method. "Apply 24 V to input I0.1, PLC moves to Running state, HMI start button shows active within 200 ms" is.
Two categories are routinely left out of the table and discovered at commissioning:
- Safety and protection signals. A steam machine sold with leakage, short-circuit, high-temperature, high-voltage, water-shortage and high-voltage-explosion protection needs one test row per protection function, not one row for "protections". Each row states how the condition is produced on the bench and what the PLC and the HMI must do when it appears.
- Utility conditions. Supply voltage, earthing quality and inlet-water connection have to be verified against the site supply. On the fixed PowerDe HW02 steam cleaner the data sheet gives the working voltage and the tap-water inlet with a 4-point internal-tooth joint, so the integration test plan can specify those two checks in advance rather than leaving them to the electrician's judgement.
Write the communication test as a separate section
I/O works and the panel still shows stale data more often than any other single fault, so the plan needs its own communication block:
- Address and device-name assignment recorded on paper, with the cable route for each port. On a switch-based network, note which port each device is patched into.
- Scan and update behaviour: how the HMI reacts when the PLC stops responding, and how the PLC reacts when a drive or remote instrument drops off the bus. The expected behaviour has to be a written line — "valve outputs go to the safe state listed in the signal table and a visible alarm appears on the HMI".
- Polling load for serial links. Where instruments sit on Modbus RTU, the plan should say which master polls them and at what interval, because two masters on one RS-485 trunk will corrupt each other, and nobody hears about it until the HMI freezes mid-shift.
- A recorded result for each link — device name, address, observed state on disconnect — rather than a signature saying "communication ok".
Separate HMI testing from PLC testing
A useful plan tests the HMI as an interface in its own right. Per screen, record: which tags the screen writes to, which tags it reads, what happens if an operator enters an out-of-range value, and whether the password levels actually restrict the actions they claim to. Recipe and parameter screens deserve a dedicated row: change a setpoint on the panel, confirm the PLC stores it, power-cycle the machine, and confirm the value is still there. A lost recipe at power-up is invisible until someone rebuilds the whole configuration at 6 a.m.
Alarms get tested the same way. Each alarm should have a trigger method, a text that names the affected device, and a defined operator response. Alarm text that says "error" tells the operator nothing and cannot be verified against anything.
Plan the sequence: bench, cold, hot, and duty cycle
Order matters, and the plan should state it. A practical sequence for machine-level integration:
- Point-to-point check with power off, confirming each wire lands where the signal table says it does.
- Power-up with actuators disconnected, watching outputs in forced mode against the tag table.
- Interlock and protection runs with the machine unloaded, using the trigger methods written in the plan.
- Full function runs with the process running — for a cleaning machine, dry-steam and wet-steam modes operated separately, plus any vacuum function, so the PLC is seen handling mode switching rather than one mode alone.
- A duty-cycle run long enough to expose thermal and memory problems, followed by a restart from a simulated power loss.
The last item catches faults nothing else finds: a program that loses its state after a stop, a counter that resets when it should hold, a heater that re-energises on restart without an operator command. Where published data does not say how long a battery-powered machine runs between charges, the plan puts "runtime under the intended duty cycle" on the list as a measured result, not an assumed figure.
Cover documentation and handover in the same plan
A test plan that ends at "all tests passed" leaves the buyer unable to support the machine. The plan should require, as deliverables: the as-built I/O list and signal table, the tag list shared between PLC and HMI, the alarm list, a backup of both programs in an editable format, and the password scheme in writing. Handover training is scheduled against those documents, not against memory.
If a project needs an outside group to own this part of the work — the change list, the test method and the acceptance document — an integrated engineering team takes them as defined deliverables, and a hardware testing pass sits inside the development loop rather than after it.
The short version of a good plan
A test plan for PLC and HMI integration that holds up on site answers five questions in writing: what devices are on the network and how they are wired; what every signal does and how its behaviour is verified; what happens the moment any link fails; who is allowed to touch which screen; and what documents leave the site with the machine. Every one of those answers is cheaper to write before the panel is energised than to argue about in front of a stopped line.
To review a control specification, an integration scope, or a machine built to your own requirement, contact Shenzhen PowerDe Automation Precision Equipment at sales@powerde.net.
