When the PLC Fails — and There Is No Backup
We were recently contacted by a company operating a 19-year-old production plant.
The system architecture was typical of its era: a PLC controlling the process, with operator interaction via HMIs and a SCADA platform.
For years, the system had run reliably.
Then one day a fault occurred — and the control panel began flashing red ERR indicators.
We asked the question; “Do you have a verified copy of the control system software?”
There was no offline backup.
No archived project files.
The original system integrator was no longer in business.
If the PLC memory had been corrupted — or if a processor required replacement — the logic that made the plant function would effectively have been lost.
And the PLC was only part of the risk.
It May Not Just Be the PLC
In many legacy installations, the operator interface extends beyond a panel HMI to a full SCADA system running on a dedicated PC or server.
SCADA Platform Risk
If that SCADA platform is:
Running on a legacy operating system (e.g. Windows XP or Windows 7)
Built using discontinued development software
Protected by hardware licence dongles
Supplied by a company that no longer exists then the exposure may be significantly greater than initially assumed.
Unlike PLC hardware — which can often continue running in isolation — SCADA systems depend on operating systems, database engines, network drivers, and third-party components. As these platforms age:
Security updates cease
Replacement hardware cannot replicate the original environment
Development tools become unobtainable
Licence servers disappear
If the original SCADA project files cannot be located — and the development software cannot be reinstalled — recovery can become a lengthy and costly redevelopment exercise, often exceeding the time and budget of a planned migration.
HMI Application Risk
Panel-mounted HMIs present a different, but equally significant, exposure.
Many legacy HMI platforms:
Do not allow full upload of the editable application from the device
Store only runtime versions on the terminal
Require specific development software versions to modify
Depend on proprietary communication drivers
If the original project file is missing, replacing a failed HMI may mean rebuilding every screen, alarm, navigation structure, and data link manually. Even where uploads are technically possible, they may not produce a fully editable or complete engineering file.
Documentation and Drawing Risk
Software is only part of the equation. In many older installations, documentation may be incomplete, outdated, or missing entirely.
Common issues include:
Electrical drawings that no longer reflect site modifications
Undocumented I/O changes
Missing network architecture diagrams
Absence of functional design specifications
No record of alarm philosophy or safety interlocks
Without accurate documentation, recovery becomes investigative rather than procedural. Engineers are required to interpret intent, trace wiring physically, and infer operational logic — increasing both risk and cost.
The HMI and SCADA Recovery Reality
While some PLC platforms, but not all, allow you to upload a program from the processor (with limitations) most HMIs — and many SCADA systems — do not.
In practical terms:
PLC logic may be retrievable — if you are fortunate.
HMI or SCADA applications may not be recoverable in editable form.
Extracted runtime files may be unusable for modification or reuse.
The original development version may no longer exist.
If the original engineering workstation is gone — or software licences have expired — graphical interfaces, alarm structures, trending, and reporting functions may need to be rebuilt entirely.
For a small standalone machine, that may be manageable.
For a full plant SCADA system incorporating:
Multiple process areas
Alarm management
Historical trending
SQL databases
User authentication
Reporting functionality
Network communications
reconstruction becomes a significant engineering AND commercial undertaking.
Rebuilding Without Documentation
When documentation and project files are missing, recovery becomes forensic.
Engineers are left with:
A physical control panel
Field devices wired into I/O usually not clearly defined
Incomplete or outdated electrical drawings
A live process (if operational)
A fragile runtime SCADA environment
Reconstruction may require:
Tracing every physical input and output
Reverse-engineering PLC structures
Manually capturing screen behaviour
Observing process sequences in operation
Interrogating accessible databases
Consulting operators for institutional knowledge
Carefully identifying safety interlocks
At this stage, engineers are not simply rewriting code — they are rediscovering intent.
Why was that interlock sequenced in that way?
Why does that alarm escalate after a defined delay?
Why does that report pull from a specific database field?
Was there a safety function (for machine or personnel) being performed?
Those decisions were made for a reason. Without recorded design rationale, engineers must infer that reasoning cautiously to avoid introducing new risk.
This inevitably increases cost, time and operational exposure.
A Business Continuity Issue — Not Just an Engineering Problem
Loss of PLC, HMI, or SCADA software is not merely a technical inconvenience.
It is a business continuity risk.
If a PLC fails and cannot be restored, production stops.
If a SCADA server fails and cannot be rebuilt, operations may lose:
Process visibility
Control capability
Alarm monitoring
Historical traceability
In regulated environments, this may also affect compliance status and audit readiness.
The commercial consequences can include:
Prolonged downtime
Emergency re-engineering
Unplanned capital expenditure
Contractual penalties
Reputational impact
In almost every case, reactive recovery costs substantially more than proactive lifecycle planning.
Managing Legacy Risk Sensibly
Mitigation does not require immediate wholesale replacement.
It begins with understanding what exists.
A structured legacy automation review should include:
Extraction and verification of PLC backups
Validation of HMI and SCADA project files
Confirmation of firmware, OS, and software versions
Assessment of hardware and software obsolescence
Verification of licence availability
Testing that backups are genuinely restorable
From this foundation, a phased migration strategy can be developed — reducing risk, spreading investment, and avoiding unnecessary disruption.
The objective is not simply technological upgrade. It is removal of single points of failure and restoration of control over your infrastructure.
Questions Every Site Should Be Able to Answer
If you operate legacy automation equipment, you should be confident in answering:
Do we hold verified, restorable PLC backups?
Do we possess the original HMI and SCADA project files?
Can we still install and run the development software?
Is the operating system still supported?
Who will support this system in five years’ time?
If those answers are uncertain, the risk already exists — even if the plant appears stable today, you may only be one error message away from catastrophe.
How Silchester Control Systems Supports Long-Term Control System Resilience
Silchester Control Systems supports industrial and regulated environments operating long-established automation platforms.
Our work includes:
Control system resilience and lifecycle reviews
Secure extraction and validation of PLC, HMI and SCADA backups
Obsolescence and risk assessments
Phased migration and modernisation strategies
Re-engineering of unsupported or undocumented systems
The focus is not simply replacement. It is protecting operational continuity and ensuring automation systems remain supportable for the long term.
Final Thought
Control systems often operate quietly in the background — until they fail.
A PLC program stored nowhere.
An HMI that cannot be uploaded.
A SCADA server running on an unsupported operating system.
A supplier that no longer exists.
Lost or outdated electrical design.
No design or functional documentation
Individually, each may appear manageable.
Collectively, they represent latent operational risk.
A structured technical review today can prevent a far more expensive recovery tomorrow.
