A PLC and HMI integration project usually fails at handover, not at programming. The machine runs on the builder's bench, yet the customer signs off only when the control system matches the written specifications. That is what an acceptance plan is for: it turns vague promises such as "responsive HMI" or "stable PLC control" into clauses both sides can test and sign. For procurement teams, plant engineers and integrators comparing suppliers, the plan is the document that decides whether the project closes on schedule or drifts through endless rework.
The practical question is what such a plan must contain before the purchase order is signed. Seven areas decide the outcome, and each is easier to agree on in advance than to argue about after commissioning.
1. Scope and deliverable list
The plan should name what is being accepted: the PLC program, the HMI screens, the electrical control cabinet, the safety logic, the documentation and the training. State what is not included — third-party instruments, customer-supplied software licences, network changes outside the machine boundary — so no one assumes the other party covers it. In PowerDe's manufacturing automation projects the engineering outputs are listed from the start: process analysis, equipment layout, electrical schematics, the PLC/HMI program, operating instructions and test report. A deliverable list written that way leaves no room for "I thought you were doing that".
2. Functional matrix: one line per function, one test per line
Convert the specification into a table where every required function has a matching verification method. Automatic start, manual mode, recipe handling, alarm handling, interlocks, e-stop response, data logging, recovery after power loss — each line states how it will be demonstrated and what result counts as passing. A matrix is what stops a functionally complete machine from failing acceptance because nobody defined "complete".
3. Control system and interface evidence
Fix the hardware and software versions before integration starts: PLC model and firmware, HMI model and screen size, communication protocol (PROFINET, EtherCAT, Modbus TCP or the vendor's own), address assignment and who owns the network configuration. Record the tag naming convention and screen structure as part of the plan, because maintainers inherit them long after the integrator leaves. Where a vision station or a sensor supplier is involved, agree the interface contract — trigger signals, data format, cycle coupling — in writing.
4. Performance and cycle criteria
Acceptance needs numbers, and numbers have to come from the specification, not from a demo. Cycle time, availability, changeover time, repeatability, throughput over a defined run — state the measurement method, the sample length and the conditions (materials, operators, shift pattern, ambient temperature). A criterion such as "98% availability" is meaningless unless the plan says over how many hours, with which downtime categories counted, and who records them.
5. Safety and alarm behaviour
The plan should cover protective stops, guarding interlocks, restart behaviour after a fault, and the alarm hierarchy: what an operator sees, what a supervisor must acknowledge, what is logged. Safety functions are the part of an integration that must be proven, not assumed, and they should appear as their own test group with an explicit pass rule.
6. Documentation, code ownership and spares
Specify what documentation arrives and in what format: electrical drawings as-built, function descriptions, HMI screen list, backup of the PLC and HMI projects, password and access policy, and the list of supported spare parts. Clarify who owns the source code, whether it is escrowed or handed over, and what the integrator will do when the customer modifies a screen a year later. Projects go wrong at this point more often than in the wiring.
7. Test stages, defect classification and sign-off
Split acceptance into stages — factory acceptance before shipment, on-site commissioning, a final run under production conditions — and state what each stage proves. Classify defects (blocking, major, minor) and attach the consequence: a blocking defect stops sign-off, a minor one is recorded and closed later with a date. Name the two people who sign, and state that sign-off is not valid without the test records attached.
Who writes the plan, and when
The integrator who builds the machine should draft the acceptance plan alongside the design, since they know where the control system can be tested; the customer should review it against their own operating requirements. Writing it after commissioning is the common shortcut, and it produces a document that ratifies what was already built. For non-standard automation, where no catalogue datasheet exists, an acceptance plan is effectively the specification — as manufacturing automation services engagements show, agreeing the process analysis, test criteria and training before manufacturing is what keeps the delivery date fixed.
Common gaps to check before you sign
- No test for recovery after power failure or network loss.
- HMI accepted on look and feel, with no screen list or language scope.
- Cycle time measured on a bench with no material handling attached.
- No named signatories and no definition of what an open defect list means.
- Program backup and passwords promised verbally, never attached to the record.
An acceptance plan that covers those seven areas turns integration risk into a shared, testable checklist. It protects the customer's investment and the integrator's handover, and it gives both a defensible answer when a claim of "not working as specified" appears.
