A machine that runs perfectly for the integrator and badly for the customer almost always has the same cause: the knowledge stayed with the person who built it. The PLC program was handed over, the screens were handed over, and the reasoning behind both left with the engineer on the last night of commissioning. Six months later a fault appears, the original integrator is unavailable, and a competent controls engineer spends three days reverse-engineering decisions that were never written down.
A handover package is not a folder of files. It is the material that lets an engineer who has never seen the machine change it safely. Below is the content we suggest requiring in the contract, written as a checklist you can put into a purchase specification.
The source, not just the compiled download
Require the editable project files for the PLC program and for every HMI screen, in the exact software version used, plus the version numbers themselves. A compiled download is not a handover: it lets someone read logic but not maintain it. Also require the license position to be stated — which licences exist, who holds them, and on which machine they are installed. Nothing stops a project faster than discovering that the only editable copy sits on a contractor's laptop under an expiring licence.
Make this an acceptance condition, not a follow-up item. Once the integrator has left site, recovering source has a price and a timeline you do not control.
An address and signal map, from the field to the screen
Provide a list that ties every input and output to its tag, its terminal, its physical device, and the HMI element or alarm that displays it. Include the network layout: which devices sit on which bus, their addresses, and which devices are masters. This is the single most-used document during a fault, and it is the one most often reduced to a vendor drawing that does not match the wiring as built.
Require that the map be issued as-built, signed against the machine, with any deviation from the design drawing marked on it. As-designed documentation describes a machine that does not exist.
A written function description in the customer's language
Each machine function needs a plain description of what it does, when it starts, what it refuses to do, and how it stops. Cover the safety and interlock logic in particular: which conditions stop motion, which are latching, and how a fault is cleared. Interlock reasoning is the part operators and maintenance staff most need and least often receive, because it lives inside function blocks that a reader has no reason to open.
Write it for a shift technician, not for the programmer who wrote it. If the reader cannot answer "why did this stop?", the document has failed regardless of how accurate it is.
A parameter and recipe record with its limits
Every adjustable value should be listed with its name, its normal setting, its allowed range, and what changes if you move it. On equipment with process recipes — temperature, pressure, dwell, force, cycle timing — this list is the difference between a tunable machine and a machine that must be recalled to the builder whenever the product changes. State clearly which parameters an operator may change and which require engineering authority, and state where each recipe is stored.
Where a machine is supplied as part of a automated production line solution, require that each cell's parameter record be issued separately and that the interface between cells be documented in both directions. Cell-level documentation without an interface map leaves the line as a whole unexplainable.
Change control and a version history the customer can read
The package must show what version is loaded on the machine today, and what changed in each previous version. Require a simple log — date, version, description of change, who made it — inside the program itself or in one dated document. Then state the rule for future edits: who may change logic, how a change is tested before release, and how the machine is returned to a known state if the change makes things worse.
Ask for a full backup of the machine's current state, verified by restore rather than by file size. An unreadable backup is not a fallback.
Fault response: alarms mapped to actions
List every alarm with its trigger condition, what the machine does when it fires, and what the operator or technician should do next. A long alarm list without actions is decoration. Where an alarm needs an instrument to diagnose, say which instrument and which test point. Where a fault requires the builder, say so plainly, so a technician does not spend a shift on a fault that was never theirs to clear.
Test this document with your own staff before you accept it: give three technicians three simulated faults and see whether they reach the right action using only the handover pack. That half-hour is the best acceptance test available for any integration project.
Training and a named support route
Include who was trained, on what, and when — plus the material used. Then state how support is obtained: the contact route, the response you can expect, and the cost basis for engineering attendance. For projects delivered under integrated engineering team services, where the team is assembled for a defined scope, this section decides whether the knowledge stays reachable after the scope closes; agree it before mobilisation, not at handover.
Also record the passwords and access levels that exist on the system, and place them in a controlled envelope rather than in the training slides. Access records left in shared material are a safety and security exposure, not an administrative detail.
Acceptance: sign the package, not the machine
Make the handover package part of contractual acceptance. The test is simple and worth insisting on: an engineer of your choosing, with no prior knowledge of the machine, uses only the package to diagnose a planted fault and to change a process parameter. If they cannot do both, the package is incomplete and acceptance has not been met.
If your integration is still being scoped, send us the automation scope, the equipment involved and who will own the line after commissioning at sales@powerde.net, or call +86 13023198376. We will confirm what we hand over, in what form, and which parts stay with your team. See our equipment manufacturing automation services page for the delivery models we run.
