The short answer
Legacy Systems
Every utility has controllers older than the people maintaining them: SLC 500 and PLC-5 systems, MicroLogix stations, Modicon 984 and Quantum racks, GE 90-30 systems, DirectLOGIC bricks, and others, running processes that have not needed to change. They fail in predictable ways: a battery dies and the program goes with it, a module fails and the spare turns out to be dead too, the software will not install on a current laptop, the network they use has no modern equivalent, and nobody left knows how they work. Keeping them running is a program of backups, spares that are tested, software kept alive on virtual machines, batteries on a schedule, and documentation recovered while it can be; migrating them is a project planned around the process, phased by area, with the I/O wiring preserved wherever a conversion system exists. The controllers also predate any idea of security, which makes isolation the only protection they have.
Key points
- Back up every legacy program now, with the software that can read it, and store the software and its license with the backup.
- Batteries hold the program on many legacy controllers; a schedule and a spare battery beat a rewrite.
- A spare that has never been tested is a hope; test spares in a bench rack and keep the test record.
- Legacy controllers have no security; isolate them behind a firewall and do not connect them to anything they do not need.
- Migrate by area, preserve the field wiring with conversion systems where they exist, and run old and new in parallel where the process allows.
What is still out there
| Family | Software | Network | Typical risk |
|---|---|---|---|
| PLC-5 | RSLogix 5 | Data Highway Plus, remote I/O | Software and operating system compatibility; module spares; battery |
| SLC 500 | RSLogix 500 | DH-485, Data Highway Plus, Ethernet on some processors | Battery; software licensing; processor spares |
| MicroLogix | RSLogix 500 or Micro | Serial, Ethernet on some | Very common at remote sites; battery on some; end of life announced |
| Modicon 984, Quantum | Modsoft, ProWORX, Concept, Unity | Modbus Plus, Modbus, Ethernet | Software generations; Modbus Plus hardware; conversion to M580 |
| GE 90-30, 90-70 | Logicmaster, Proficy Machine Edition | Genius, SNP, Ethernet | Software lineage; module spares; migration to newer families |
| DirectLOGIC | DirectSOFT | Serial, Ethernet on some | Retiring; migration to Do-more or Productivity |
| Siemens S5, S7-300 | STEP 5, STEP 7 classic | PROFIBUS | Software on old operating systems; phase-out |
The ways they fail
- The battery
- Most legacy processors hold the program and retentive data in battery-backed memory. The battery lasts a few years, the low battery indicator is ignored or never wired to an alarm, and a power outage erases the program. Some processors have an EEPROM or a memory module that restores the program on power-up if it was written; many never were.
- The spare
- A processor bought as a spare fifteen years ago has its own dead battery and possibly a failed component. A spare that was never powered has never been tested.
- The software
- The programming software was licensed to a computer that no longer exists, runs on an operating system that no longer installs, and communicates through a serial or proprietary interface that no current laptop has.
- The network
- A proprietary network with no new hardware; a failed interface card is a plant with no SCADA.
- The knowledge
- The integrator is gone, the documentation is a printout in a drawer, and the program has no comments.
Keeping them running
- 1
Inventory
Every legacy controller, its family, its firmware, its software version, its network, its battery type, and the date of the last backup, in the asset inventory.
- 2
Back up
Upload every program with the correct software and save it with the software installer, the license information, and a description of the communication cable and driver. Print the program too; a printout is the backup that survives every format change.
- 3
Batteries
Replace on the manufacturer interval, with power applied where the procedure allows, and wire the low battery output to a SCADA alarm.
- 4
Non-volatile copies
Where the processor supports an EEPROM, a memory module, or a card, write the program to it and set the processor to load from it on power-up.
- 5
Spares
Test every spare in a bench rack once a year: power it, load the program, exercise the I/O. Replace the battery in the spare.
- 6
Software machines
A virtual machine per software generation, with the operating system, the software, the license, and the communication driver, plus the physical interface it needs, kept with the engineering records.
- 7
Isolate
A firewall between any legacy controller and anything it does not need to talk to; no direct internet, no direct business network, remote access only through a jump host.
- 8
Document
While the people who know the system are still available: a narrative, an I/O list, and comments recovered from the printout into the program.
Security
A legacy controller trusts every message it receives. It has no accounts, no password on its network services worth the name, no signed firmware, and a network stack that can be crashed by malformed packets. The only protection is not to let anything reach it: a firewall that permits exactly the SCADA server and the engineering jump host, a network with nothing else on it, and physical control of the panel. A legacy controller found with a direct path to the business network or a cellular router with a public address is the first remediation item in any security assessment.
Planning the migration
- Start with the risk: the controllers whose failure stops treatment or causes an overflow, whose spares are gone, or whose software cannot be run, go first.
- Choose the target platform for the whole utility, not per site; the site library, the spares, and the training follow from it.
- Preserve the field wiring where a conversion system exists: swing-arm and cable conversion systems for several legacy I/O families land the old terminal blocks on the new I/O without rewiring the field.
- Convert the logic with the vendor tool where one exists, then review every routine; a conversion is a starting point, not a result.
- Build the SCADA changes with it: tag names, drivers, and graphics change with the controller.
- Phase by process area; run old and new in parallel with the field wiring switched over area by area, and keep the old controller in place until the new one has run through a full operating cycle.
- Write the narrative and the I/O list as part of the migration; the new system starts documented.
Frequently asked questions
- The processor lost its program. What now?
- Load the backup with the correct software, if one exists, and replace the battery. If no backup exists, the printout is typed back in, or the process is run manually while a new program is written from the narrative. This is why the backup comes first on every visit.
- Can I keep the old controller and just add a gateway to modern SCADA?
- Yes, for a time; a protocol gateway or a driver for the legacy network gives SCADA access without touching the controller. It does not fix the battery, the spares, or the software, and it should be a step in a migration plan, not a substitute for one.
- How do I justify replacing a controller that works?
- With the consequences and the cost of the day it stops: the overflow, the boil notice, the manual operation for weeks while a replacement is engineered under pressure. A planned migration costs less than an emergency one and can be scheduled around the process.
- Is a virtual machine with old software really necessary?
- Until the last controller of that generation is gone, yes. The alternative is discovering on the day of a failure that nothing on the shelf can talk to the processor. The virtual machine, the license, and the cable are the insurance.
Related topics
- PLC Program BackupsWhat a complete controller backup contains, how often to take one, where to keep it, why the upload from the running controller is not the master, and the verification that turns a folder of files into a recovery plan.
- Offline CopiesThe backup copy that survives ransomware: why anything reachable over the network will be encrypted too, what offline and immutable mean, options from rotated drives to immutable storage, what goes in the offline set, and the restore test that uses it.
- Segmenting a Remote SiteA lift station, a well, or a tank site as its own zone: the site firewall and what it permits, the modem as transport with no public address, cameras and extras off the control segment, engineering access through the plant, and local control without the link.
- Documenting Firmware VersionsWhy the firmware version of every controller, module, drive, switch, radio, and instrument belongs in the inventory with the date it was read: advisories are issued by version. Where to read each one, the several versions one controller has, and the cadence.
- Retentive MemoryWhat survives a power cycle in a controller and what does not, how retention is backed up by battery, capacitor, or nonvolatile storage, what should be retentive, and how retained data gets lost.
- Retentive Data LostThe plant came back from a power cycle with zero setpoints, zero totals, and the wrong pump as lead. Which backup failed, which restore overwrote what, and how to get the data back and keep it.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.