Most PLC and HMI specification arguments are unwinnable on paper because the people arguing do not yet know what the machine does. The requirement document describes the process as it was intended; the machine behaves as it was built. A prototype is the cheapest way to close that gap before the control programme, the I/O count and the safety wiring are frozen — and it is the reason buyers evaluating manufacturing automation support should expect a candidate supplier to propose one rather than a longer document.
What a prototype is actually for
A prototype is not a smaller version of the machine. It is an apparatus chosen to answer specific integration questions, and the questions come first. For a control project they are usually: how many inputs and outputs are genuinely needed, which signals cross between the machine and the line, what an operator can be trusted to change on the HMI, whether the chosen network handles the cycle without timing out, and how the safety functions behave when production deviates from the sequence in the manual.
Answered late, each of these becomes a change order. Answered on a prototype, they become a line in a document.
Choose the smallest thing that can produce a true answer
Three prototype levels are common, and the choice depends on which risk you are testing. A bench rig — PLC, HMI, a handful of real I/O, one drive and one sensor of each type — tests the control architecture and the programme structure at the lowest cost. A single station or module tests the mechanical action, the sensing and the timing, which is where vision and motion requirements usually prove wrong. A partial line tests the interface between cells, and it is the only level that exposes handshaking and interlock problems.
Buyers should ask the supplier which level they are proposing and why, and refuse the vague middle answer. A prototype that answers no specific question is a cost with no decision attached.
Make the prototype produce evidence, not an impression
- A written list of the questions the prototype must answer, with the pass criterion for each. No list, no prototype.
- Real sensors and real actuators of the type that will be installed, not simulation. Signal behaviour, wiring length and noise are where the surprises are.
- The actual HMI screens, operated by your own staff rather than the integrator's. Every usability requirement that survives this test is one you can trust.
- One deliberate fault injected on purpose: a sensor blocked, an axis faulted, a network link dropped. Watch what the machine does and what the operator sees.
- A record: I/O list as built, tag list, alarm list, and the deviations found against the paper specification.
Let the prototype change the specification, and be paid for it
The value of a prototype is that the specification is wrong somewhere, and that finding it is the point. The output should be a revised control specification signed by both sides before the production build starts. If the contract treats the prototype as a sales gesture rather than a deliverable with acceptance criteria, the findings will not survive into the build.
This is where engineering services have a legitimate role: a supplier offering development, hardware testing and integration work can build the rig that tests the questions you cannot test yourself, and services of this kind are part of what a supplier such as PowerDe lists alongside its automated production line solutions. Set the boundary in writing, though: who owns the programme written on the prototype, who keeps the drawings, and what happens if you take the design to another integrator. Those three clauses decide whether the prototype strengthens your position or locks you in.
Decide what you will not buy until the prototype passes
Before it starts, list the decisions that depend on the outcome — I/O count, network choice, HMI size, safety relay arrangement, the number of axes — and hold them. That single constraint keeps the prototype honest, because a supplier who has already purchased the panel cannot report a finding that changes the panel.
A prototype that changes your requirement document has paid for itself. One that confirms it, and finds nothing, has told you something about the supplier worth knowing as well.
