Learn Automation with MINATA #80: Handing Over an Automation System — So the Team Can Run, Diagnose and Maintain It

Handing Over an Automation System: So the Team Can Run, Diagnose and Maintain It

An automation system is only truly finished when the operating team can run it safely, recognise when something is abnormal, recover correctly, and know who to call once they reach the limit of what they may do. A machine that ran during the acceptance meeting is a necessary condition of handover, not a sufficient one.

The minimum handover file

Handover needs documentation that can be used, not documentation that looks good at signing. The minimum usually holds:

As-built electrical and pneumatic drawings, the I/O list and the bill of materials.
Software and backups with versions, together with the parameter and recipe register.
Accounts and access rights per procedure, and the network map.
Equipment manuals, the acceptance file and the punch list.
The maintenance schedule and guidance for the faults that occur most often.

Each file needs a location, an owner and a revision, so whoever comes next finds the current version.

Training is part of the handover

Training is not demonstrating the Start button. The operating shift needs modes, permissives, alarms and the start, stop and restart procedures. The maintenance team needs the lock-out procedure, loop checks, backup and restore, how to replace equipment, and the limit of what they may do — where they act themselves, and where they call engineering or the manufacturer.

Handover is for the long run

The end goal is that the team on site can run, diagnose and maintain the machine without guessing. A frequent fault belongs in a checklist and in an alarm that carries its guidance, not in word of mouth. Every change after handover keeps the same discipline: describe the reason, assess the effect, back up before the change, retest what it touches, and store the new version.

A worked engineering situation

When a machine group is handed over, the team supplies the as-built set, versioned software backups, the parameter and recipe register and the maintenance schedule; trains the operating shift on the real screens and checklists; and shows maintenance how to back up and restore, and where their limit lies. Some weeks later, when a device has to be replaced, the site team does it from the documentation instead of calling the builder for every small task.

The document list, the training content and the change procedure all follow the contract and the plant's operating requirements.

Common mistakes

Treating one successful run as a completed handover.
Files without version or owner, so the current one cannot be found.
Training that demonstrates Start and skips modes, alarms and recovery.
Never stating the limit of what maintenance may do.
Changes after handover with no backup, no retest and no new version.

Handover checklist

[ ] As-built, backups, parameters, manuals and the acceptance file are complete.
[ ] Every file has a location, an owner and a revision.
[ ] Operator training covers modes, permissives, alarms and start, stop and restart.
[ ] Maintenance training covers lock-out, loop checks, backup and restore, and limits.
[ ] The change procedure after handover is agreed.

Handing over for the long run is where this whole series has been heading: understand the system, verify it with evidence, and leave it so the people who come next can run, diagnose and maintain it safely.

Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation

Previous — #79: FAT and SAT evidence: https://minatavn.com/en/blog/automation-79-fat-sat-evidence

View all MINATA technical articles