Reducing PLC recovery risk across 12 production lines
Reduced PLC recovery risk across 12 production lines.
A UK food manufacturer was running 12 production lines with no centralised record of PLC software versions. Engineers carried knowledge in their heads. When a key engineer left, the site was exposed. Nobody knew which version of the code was live on four of the lines.
ECS conducted a full OT asset survey across the site, establishing a Command Centre baseline for all 12 lines. Every PLC, HMI and drive was catalogued with its current software version and supporting documentation. A change-logging process was implemented so that any future modification was captured against the asset record rather than living on an engineer's laptop.
Within three months, every device had a version history. The next time a PLC fault occurred on Line 7, the ECS engineer had the current software loaded before the session started, turning what had previously been a discovery exercise into a straightforward fix.
The situation
Twelve production lines, built up over more than a decade, each commissioned by a different machine builder. No single record of what software was running where.
The site had operated this way for years without incident, which is precisely the problem. The risk was invisible until the moment it mattered.
Why undocumented PLC estates fail quietly
Undocumented automation doesn’t cause problems day to day. It causes them at the worst possible moment: when a line is down, when a key engineer is unavailable, or when an auditor asks a question nobody can answer.
In this case the trigger was a departure. A senior controls engineer left, and with him went the working knowledge of which code revision was live on four of the twelve lines. Nothing broke immediately. But the site was now one fault away from a lengthy, expensive discovery process.
What ECS did
The work split into three stages: survey, baseline, and process.
The survey catalogued every device on the automation estate, covering PLCs, HMIs, drives and networked instruments, recording make, model, firmware and the software revision actually running, rather than the revision someone believed was running.
The baseline loaded that record into Command Centre, giving the site a single reference point with revision history attached to each asset.
The process was the part that made it stick. Without a change-logging routine, an asset register is accurate on the day it’s built and decaying from then on.
The result
Three months in, every device had a documented version history.
The value showed itself on the next fault. A PLC issue on Line 7 would previously have started with an hour of working out which code was live and finding a copy of it. Instead, the ECS engineer opened the session with the correct software already loaded.
This case study describes a real ECS engagement, anonymised at the customer's request. Figures are as recorded by ECS at the time of delivery. Client name and precise site location are withheld.
This work was delivered through Command Centre. Talk to an engineer about your site.