Documentation, Handover and Lifecycle
Schematics and tags, program backups, spares, training, change control, obsolescence and a troubleshooting table.
The documents
| Document | Why it matters |
|---|---|
| Electrical schematics | Show every circuit with unique references, terminal numbers and cross-references; the main tool for fault finding |
| I/O list and network diagram | Shows what every signal is, where it lands, and every device’s address and settings |
| Panel layout and bill of materials | Enables spares, repairs and copies |
| Program backups and version history | Lets you restore a controller after a failure and see what changed |
| Functional description and operating manual | Explains the modes, sequences, alarms and recovery from faults |
| Risk assessment and safety validation | The legal evidence that the machine is safe (see Machine Safety Systems) |
| Test records | FAT, SAT and safety validation evidence (see Testing, Commissioning and Acceptance) |
| Spare parts list | Identifies parts to hold on site |
| Maintenance plan and manuals | What to do and when; the manufacturers’ manuals |
| Declaration of conformity and certificates | The CE or UKCA file, component certificates, calibration certificates |
Worked example: the size of a handover package
| Item | Size |
|---|---|
| Schematics (PDF and CAD) | 38 MB |
| PLC, HMI and drive backups | 420 MB |
| Manuals and datasheets | 1 650 MB |
| Test records and photographs | 310 MB |
| Network configuration and passwords (encrypted) | 4 MB |
| Total | 2.4 GB |
The package fits on a memory stick and in a cloud folder; what matters is that it is complete, current and findable. Give it an index, a version and a date, and tell the customer where the master copy is. Put the passwords and licenses in a sealed envelope or a secure store, never in an email.
Names, tags and reference designations
Every device needs one name that is used everywhere: on the schematic, the panel label, the I/O list, the PLC program, the HMI and the spare-parts list. Choose a convention at the start (ISA-5.1 for instruments, IEC 81346 for reference designations, or the customer’s own) and keep to it.
| Example | Meaning |
|---|---|
=A1+B2-K1 | Motor starter contactor in area 1, panel 2 |
PT-101 | Pressure transmitter in loop 101 (ISA-5.1) |
M_301_Run | PLC tag: conveyor 301 motor run command |
- Make names meaningful but short, with a fixed pattern (area, type, number), no spaces, and a table of the abbreviations.
- Never reuse a name for a different device, and never rename without updating every document (see the I/O list in Requirements, Specification and Project Stages).
- Label the real thing: a name on a drawing that is not on the device is useless at 2 am.
- Cross-reference the schematic pages (each relay coil points to its contacts) so that a fault can be followed without searching.
As-built drawings
During commissioning the machine changes: a wire moves, a device is replaced, a setting changes. Update the drawings to the as-built state before handover. A set of drawings that does not match the machine is worse than none, because people trust it.
Worked example: the effort of updating
A set of 86 schematic sheets that needs a quarter of an hour of checking and marking up per sheet takes 21.5 hours. Even if only 3 % of the sheets have an error, 86 × 0.03 = 3 sheets are wrong: each is a future wasted hour in a breakdown. Mark up the drawing at the time of the change, (a red pen on the working set), and update the master on the same day; do not leave it for the end.
- Revision control: every drawing has a revision, a date and a description of the change; revision 3 is not the same as revision 2.
- Keep the editable files (the CAD project, not only PDFs) and tell the customer where they are.
- Walk the machine with the drawings before handover and check a sample against it.
Program backups and versions
- Back up every programmable device: PLC, HMI, drives, safety controller, network switches, vision systems, robots, with the version of the engineering software (see HMI, Alarms, Data and Cybersecurity).
- Name backups with a version and a date, for example
LabelLine3_PLC_v2.4.1_2026-10-31; keep a short change log with each version saying what changed and why. - Use version control (Git for text-based sources, or the controller vendor’s tool) and keep the master off the machine.
- Compare the running program with the backup at each visit: a difference means somebody changed something without telling anyone.
- Keep the passwords and license files with the backups in a secure place.
- Test a restore on a spare device or in simulation at least once.
Spare parts
Which spares to hold depends on how likely a part is to fail while you wait for a replacement, and what the wait costs. For a part with a failure rate λ, a group of N parts and a lead time t, the expected number of failures while waiting is m = N λ t, and the chance of k failures follows the Poisson distribution.
Worked example: how many spares?
The lead time for a replacement is 4 weeks (672 hours). The table gives the expected failures in that time, the chance of at least one, and the number of spares needed to cover 99 % of cases:
| Part | Installed | Expected failures in the lead time | Chance of at least one | Spares for 99 % | Cover |
|---|---|---|---|---|---|
| Relays and contactors | 60 | 0.202 | 18.3 % | 2 | 99.9 % |
| 24 V power supply | 2 | 0.013 | 1.3 % | 1 | 100.0 % |
| PLC I/O cards | 16 | 0.043 | 4.2 % | 1 | 99.9 % |
| Drives (4 kW) | 2 | 0.016 | 1.6 % | 1 | 100.0 % |
| Proximity sensors | 48 | 0.258 | 22.7 % | 2 | 99.8 % |
- The relays and the sensors have the most installed units but a low chance of any failing in a month; one or two spares each is plenty. The drives are few but costly, with a higher failure rate: the cost of a failure matters as much as its chance.
- A drive costing $900 whose failure stops a $2 000 an hour line: the yearly chance that one of the two fails is about 14.4 %. Waiting 72 hours (a three-day delivery from a distributor) for a replacement costs about $144 000 per failure; with a spare, 3 hours cost $6 000. A $900 spare saves $138 000 each time it is used: it pays for itself on the first failure.
- Spares by cost of failure: hold on site anything that stops the line and has a long lead time (drives, PLC modules, the HMI, special sensors); hold at the supplier or a distributor what can be bought in a day.
- Keep the spares where they can be found, labeled, with the settings or a copy of the configuration, and replace each one used.
Training and handover
Worked example: a training plan
| Group | People | Course length | Total |
|---|---|---|---|
| Operators | 12 | 8 h | 96 person-hours |
| Maintenance technicians | 4 | 24 h | 96 person-hours |
| Controls engineers | 2 | 40 h | 80 person-hours |
| Supervisors | 3 | 4 h | 12 person-hours |
| Total | 284 person-hours |
The operators’ training is short and practical, repeated for each shift; the maintenance and controls engineers’ training takes days. Budget it in the project: without it, the first fault falls to the integrator’s phone.
- Train on the machine and with the real documents; include a fault-finding exercise.
- Hand over in a meeting: walk through the documents, the backups, the spares, the passwords and the warranty, and sign the handover record.
- Plan the support: who to call, the response time, the remote access (see HMI, Alarms, Data and Cybersecurity) and the cost after the warranty.
- Collect the first weeks’ problems in a list and review it with the operators; it is the best input to the first improvement.
Maintenance planning
Worked example: the maintenance load
| Interval | Tasks | Minutes per task |
|---|---|---|
| Each shift | 6 | 5 |
| Weekly | 9 | 10 |
| Monthly | 14 | 20 |
| Yearly | 18 | 90 |
On a machine that runs 3 shifts on 250 days, these tasks add up to about 533 hours a year of planned maintenance. Compare that with the downtime pareto of the machine: the planned tasks should address the top causes, not just the ones that are easy to write down.
| Cause of stops | Minutes in a week | Share | Cumulative |
|---|---|---|---|
| Jam at the infeed | 46 min | 35 % | 35 % |
| Sensor dirty or misaligned | 31 min | 24 % | 59 % |
| Label roll change | 22 min | 17 % | 76 % |
| Other | 11 min | 8 % | 85 % |
| Drive fault | 9 min | 7 % | 92 % |
| Network dropout | 6 min | 5 % | 96 % |
| Operator error | 5 min | 4 % | 100 % |
The first three causes make 76 % of the stops: a pareto of the logged stops shows where a fix pays (see Data Logging for logging them). A better sensor mount or a cleaning routine may remove more downtime than a faster drive.
- Preventive tasks: clean filters and fans, check terminal torque with a thermal camera, test the safety devices (see Machine Safety Systems), check the battery of the PLC and the backup.
- Predictive tasks: temperature, vibration and current trends of drives and motors, panel temperature and the 24 V supply voltage (see Panel Layout, Heat and Enclosures).
- Keep a maintenance log of every intervention and every fault, with the cause.
Lifecycle, obsolescence and upgrades
A machine lives for 15 to 25 years, and its control parts for less. The cost over the life is far more than the price of buying it, and the controller is the part most likely to become unobtainable.
Worked example: the cost of owning a machine
A machine that costs $250 000 to build, maintained at 4 % of its price a year over 15 years, costs $150 000 to maintain, and one controls upgrade of about 25 % of the price ($62 500) during its life: a total of $462 500. The purchase is only 54 % of the cost of ownership. Choose parts, documentation and suppliers for the life, not only for the day of delivery.
| Age (years) | Failure rate of an aging part | Relative to a young one |
|---|---|---|
| 1 | 5.0 per million hours | 1.0 × |
| 5 | 5.0 per million hours | 1.0 × |
| 10 | 5.0 per million hours | 1.0 × |
| 15 | 38.0 per million hours | 7.6 × |
Failure rates rise in old age (the part of the “bathtub curve”): after ten years the example part fails 1.5 times more often with each extra year. Plan replacement before the failures climb, not after.
- Watch the product lifecycle status of the controller, drives and HMI: “active”, “mature”, “limited”, “discontinued”. A last-time-buy notice gives a window to stock spares: for the I/O cards, 60 modules is a lot; decide by the life you need.
- Choose open standards (IEC 61131-3, OPC UA, Ethernet) over proprietary links where a long life matters.
- Upgrade deliberately: a controller replacement is a project, with its own specification, test and safety re-validation (see Requirements, Specification and Project Stages).
- Change control: every change after handover (a program edit, a new sensor, a changed limit) is requested, assessed, approved, tested, documented and backed up. For safety functions, the validation is repeated.
- Record the end of life too: safe disposal of batteries, capacitors and refrigerants.
Troubleshooting integration problems
| Symptom | Likely cause | Try |
|---|---|---|
| Random stops or resets that nobody can reproduce | Loose terminal, noise, supply sagging, overheating | Check terminal torque; log the 24 V rail; check shields and routing; check the enclosure temperature (see Wiring, Cables and Voltage Drop, Grounding, Shielding and Noise, Panel Layout, Heat and Enclosures) |
| Network device drops out | Duplicate IP, bad cable or connector, noise, switch loop | Check the address list and port statistics; swap the cable; separate it from drive cables. See Industrial Communication |
| Analog reading is noisy | Poor shielding or grounding, a ground loop, a drive nearby | Check shield termination, use isolated inputs or signal conditioners, reroute (see Grounding, Shielding and Noise) |
| Drive trips nuisance faults | Long motor cable, wrong motor data, EMC, supply fault | Add output reactors, check parameters, check the filter and earthing |
| PLC output LED on, device off | Field wiring open, blown output fuse, load supply off | Measure at the terminals; check the output group supply and fuses |
| It worked at the FAT, fails on site | Different supply, longer cables, new interference, sensors at different distances | Compare conditions; recheck supply quality, earthing and sensor mounting |
| Machine behaves differently after a power cut | Retentive and non-retentive memory not planned | Define start-up conditions and test power loss in mid-sequence (see Power Distribution and the Control Supply) |
| A protective device trips on start-up | Inrush, wrong characteristic, the supply too weak | Check the trip curve against the start (see Power Distribution and the Control Supply) |
| Panel runs hot | Blocked filter, failed fan, a new load, a hot ambient | Measure the temperature; clean the filter; re-do the heat budget (see Panel Layout, Heat and Enclosures) |
| Safety circuit will not reset | A device not in the safe state, a contactor feedback open, a wiring fault | Use the safety relay’s diagnostic LEDs; check each device in turn; never bridge a safety contact |
| Alarm flood after a trip | No first-out logic, no suppression by state | Rationalize the alarms (see HMI, Alarms, Data and Cybersecurity) |
| Nobody can find the right drawing | Unclear revision, no master copy | Control the documents (above); mark up and update at once |
Related
- System Integration: the overview of this guide.
- Requirements, Specification and Project Stages: the specification and I/O list that the documents grow from.
- Testing, Commissioning and Acceptance: the test records for the handover package.
- HMI, Alarms, Data and Cybersecurity: backups, change control and cybersecurity.
- Data Logging and PLC and Logic Control.
FAQ
What should be in a handover package?
As-built schematics and layouts, the I/O list and network diagram, backups of every programmable device with versions, manuals and datasheets, the operating and maintenance instructions, test records and safety validation, the spare-parts list, certificates and passwords stored securely.
How do I decide which spares to hold?
Hold what stops the line and has a long lead time; compute the chance of failure in the lead time and the cost of waiting. A spare of a costly part that stops the line often pays for itself on the first failure.
How often should the program be backed up?
After every change and at regular intervals, with a version and a date; keep copies off the machine and test a restore.
When should a controller be replaced?
Before the lifecycle status is “discontinued” and spares run out, or when failures rise. Treat it as a project with its own specification, testing and safety re-validation.
References
- IEC 82045 and IEC 61082 (document management and preparation of electrotechnical documents); IEC 81346 (reference designations); ISA-5.1 (instrument symbols and identification).
- IEC 60300 (dependability management) and ISO 55000 (asset management); Smith, D. J., Reliability, Maintainability and Risk, Butterworth-Heinemann (spares and availability).
- The controller, drive and HMI manufacturers’ lifecycle policies and last-time-buy notices.
Last reviewed: October 2026. Failure rates, costs and times are typical and illustrative: use your own data.