A PLC and an HMI rarely fail at the same moment, yet most integration disagreements start long before commissioning. When maintenance staff cannot tell whether a fault sits in the controller program, the operator panel, or the communication link between them, the result is hours of unplanned troubleshooting. Clear acceptance criteria give controls teams, equipment suppliers, and end users a shared definition of what “finished” means.
Define the boundary each team is accountable for
Start with a written division of responsibility. The controls supplier should specify the PLC tag structure, data types, scan-cycle assumptions, fault codes, and safe states. The HMI integrator should specify screen navigation, alarm presentation, recipe handling, user permissions, and data logging. If the two sides receive the same document, they can identify gaps before hardware arrives.
For multi-vendor lines, include the machine or equipment supplier in the review. Cleaning systems, conveyors, process chambers, and other auxiliary equipment often exchange run, stop, ready, fault, and interlock signals with the main line. A tag list that omits those interactions can pass a single-machine test and still fail when the line starts up.
Specify the communication contract, not only the protocol name
“Modbus TCP” or “PROFINET” is not an acceptance criterion. The document should identify the network topology, IP or device-name scheme, cycle time, timeout behavior, and which device owns each data item. It should also state what happens when the HMI loses its connection to the PLC: whether the process continues, whether a warning remains visible after the operator acknowledges it, and whether the panel displays the last valid value or a clear communication fault.
- Create one master tag sheet that lists each address, data type, units, scaling, access rights, and the system that writes the value.
- Define alarm priorities, alarm wording, acknowledgment rules, and whether the PLC or HMI records the timestamp.
- Specify recipe or parameter ranges so out-of-limit values are rejected consistently by the PLC and the HMI.
- Record the software versions used during acceptance testing, including PLC firmware and HMI runtime.
Make functional tests observable
Each requirement should have one test that another engineer can repeat. A practical statement describes the initial state, the action, and the expected response. For example: “With the machine stopped and guard doors closed, pressing Start on the HMI shall energize the run circuit only after the interlock condition is satisfied; if the interlock is absent, the HMI shall show the corresponding fault and the PLC shall not start the motor.” Vague statements such as “HMI operates normally” cannot be signed off objectively.
Include safety-related interactions in the functional list even when they are handled by dedicated safety devices. The HMI may display a fault, but the acceptance evidence should show that the safety function itself does not depend on an HMI screen remaining available.
Test exception behavior with the same rigor as normal operation
A project can pass nominal operation and still create operational risk. Run the abnormal cases that maintenance teams actually encounter:
- Unplug the HMI Ethernet cable during a recipe change, restore it, and confirm that the process state and alarm record remain consistent.
- Force a sensor fault and verify that the HMI identifies the affected station or device rather than displaying a generic fault.
- Confirm that manual mode cannot bypass interlocks or permission levels intended for automatic operation.
- Restore a PLC program or recipe backup and check that the HMI project and tag database still match the controller.
- Check time synchronization when alarm history and production records must align across controllers and panels.
These tests reduce the chance that a communication fault becomes a silent process fault. They also provide a reusable checklist for future HMI upgrades or PLC replacements.
Tie documentation and training to the acceptance package
Acceptance should cover what the owner receives after sign-off, not only what the machine does on the day of inspection. The package normally includes the final tag sheet, network diagram, alarm list, parameter list, backup files, and the procedure for restoring those files. Training should use the same scenarios used in testing, so operators and maintenance staff learn where to look first when a fault appears.
A short punch list completes the package. Record unresolved items, assign responsibility, and state the evidence required to close each item. This avoids a situation where provisional sign-off turns into an open-ended support arrangement.
Plan for change after handover
Acceptance criteria should anticipate the next revision. Require version numbering for the PLC program, HMI project, and tag sheet. Require a change log that records who changed a parameter, when it changed, and why. For equipment that supports ongoing process improvement—such as PowerDe cleaning equipment used in vehicle-service, industrial maintenance, or facility applications—these records help future integrators understand the baseline before adding counters, alarms, or reporting functions.
Where a supplier offers automated production line solutions, acceptance documentation should also identify the interface points between the line and the plant’s existing controls. That makes later expansion less dependent on the original programmer’s memory.
A practical acceptance workflow
- Convert each user requirement into a numbered, testable statement.
- Review the tag sheet and communication contract with both the PLC and HMI teams.
- Run nominal function tests, interlock tests, and communication-failure tests with witnesses present.
- Record results, software versions, and backup status against each numbered requirement.
- Close punch-list items with documented evidence, then archive the final package for future maintenance work.
When those criteria are agreed before development begins, integration becomes a verification task rather than a negotiation. Teams can concentrate on making the equipment operate predictably, while owners receive a controls system they can maintain after commissioning ends. If your integration team needs a documented review of equipment controls and process requirements, contact PowerDe to discuss the application before the PLC and HMI specifications are frozen.
