One Bad Card. One Old Laptop. One Near-Shutdown.

An industry colleague called us the other day. He was elbow-deep troubleshooting an I/O card problem at an 800-megawatt power plant. Staring down a problem that started small and got very large, very fast.
A single I/O card had failed in an older Allen-Bradley CompactLogix system. Not a dramatic failure, just one bad module. But that module sat in a POINT I/O remote rack tied to the plant's critical water process, and when it faulted, it didn't fail quietly. It took the entire rack offline with it. One card, one connection lost, and a whole slice of the process went dark.
Here's the part that should make every plant manager sit up: that fault had been live for the better part of a day. By the time we spoke, the process this PLC controlled had been down for somewhere between 12 and 18 hours. Left much longer, it would have forced a plant-wide shutdown... on a facility that powers a region.
The real obstacle wasn't the broken card

Replacing a failed module is routine. What turned a routine fix into an all-day ordeal was getting into the equipment to diagnose and reconfigure it.
The rack's Ethernet adapter, a 1734-AENT/A, does its configuration through an embedded web page. And that web page, like a lot of equipment specified in the mid-2000s, drives its diagnostics through a Java applet.
In 2006, that was clever engineering. In 2026, it's a trap. Modern browsers dropped Java applet support years ago. The plug-in is a known security liability. Try to open that config page on any current laptop and you get nothing; no diagnostics, no configuration, no way in. My colleague got back in only because he had the right old laptop kept around, with the right old browser and the right old Java runtime still on it.

Think about how fragile that is. The continued operation of a critical process at an 800 MW plant depended on a single aging laptop nobody had thrown out yet. That's not a maintenance plan. That's luck.
Legacy technology is an operational risk, not an IT footnote
It's tempting to file all of this under "IT housekeeping" and push it down the list. But the Java applet wasn't an inconvenience, it was the difference between a 30-minute fix and a near-shutdown. The technology you configure and recover your plant with is every bit as critical as the technology that runs it.
When the tools required to maintain your equipment become extinct, your equipment becomes un-maintainable, even when it's still running fine. You don't notice until the day you urgently need in, and the door has quietly rusted shut.
Three lessons stand out from that phone call:
1. Lifecycle is a process risk, not a budget line. A 20-year-old adapter that "still works" is fine right up until the moment you need to touch it under pressure. Currency isn't about chasing the newest hardware, it's about making sure you can still operate, diagnose, and recover the assets you depend on.
2. Eliminate single points of pain - including single points of knowledge. One bad card shouldn't take the whole PLC offline. One retired laptop shouldn't be the only way back into a critical process. Every "only Dave knows how" and "only that one machine can do it" is a future outage with a date not yet assigned.
3. Proactive beats heroic, every time. My colleague's save was genuinely impressive. But the best version of this story is the one where the adapter was modernized two years ago during a planned window, and yesterday's call never happened. Heroics are expensive, stressful, and they don't scale.
What "keeping it current" actually looks like

You don't rip-and-replace a working plant. Proactive lifecycle management is quieter than that:
Know what you're running. A current inventory of controllers, adapters, firmware, and critically the tools and credentials needed to service each one.
Flag the extinct dependencies. Anything that needs Java applets, Windows XP, unsupported runtimes, or a single irreplaceable laptop is a risk worth planning around, scheduling out, and replacing. Not discovering mid-incident.
Modernize in planned windows. Migrate aging adapters and access methods on your schedule, in daylight, with the process down on purpose, not at hour 14 of an unplanned event.
Keep the bridge equipment, deliberately. Until you've migrated, that old laptop is critical infrastructure. Image it, document it, lock it down, and don't let it be the thing nobody's responsible for.
That failed I/O card will get replaced and the plant will run for another decade. The real question every operator should be asking is simpler: when the next call comes, will we still be able to get in?
At JPI, this is the work we love — getting into legacy control systems, finding the quiet dependencies before they bite, and planning the modernization that keeps critical facilities running for the long haul. If you're not sure what's hiding in your own racks, that's exactly the conversation worth having before struggling for 14-hours trying to fix something.
Solving operational challenges in ways others have only imagined.




Comments