OEE Data Capture from Legacy PLCs
Overall equipment effectiveness is a genuinely useful metric, availability times performance times quality, but I've seen more OEE initiatives stall on the data capture problem than on anything to do with the metric itself. Modern machines with built in connectivity make this easy. A plant floor full of PLCs installed fifteen or twenty years ago, running proprietary protocols with no native connectivity to a modern data historian, is a much harder starting point, and that's the reality for most established manufacturing plants.
What you actually need to extract
Before worrying about connectivity methods, it's worth being precise about exactly what data OEE requires, because legacy PLC retrofits often try to capture far more than necessary and the project scope balloons as a result. At minimum, you need machine state, running, idle, down, and why, cycle counts or a reliable proxy for units produced, and some signal for quality, either a direct reject count from an inspection station or a manual entry point if automated quality data isn't available yet.
That's a much smaller data set than a full historian implementation would try to capture, and I'd resist the temptation to expand scope to every available PLC register just because the connectivity project is already underway. Get the core OEE data flowing reliably first.
Connectivity approaches for older PLCs
The right approach depends heavily on what's actually running on the floor, but a few patterns cover most situations.
- Direct protocol communication. Many legacy PLCs, even fairly old ones, support a proprietary or semi open protocol that a modern gateway device can speak directly, pulling register values without touching the PLC program itself. This is the cleanest option when available, since it requires no changes to validated control logic, which matters enormously in regulated industries where PLC program changes trigger revalidation requirements.
- Hardwired signal tapping. For PLCs with no accessible communication protocol at all, tapping discrete signals, a run light, a fault relay, a part present sensor, directly into a separate data capture device sidesteps the PLC's programming entirely. It's cruder, giving you state changes rather than rich data, but it's often the only non invasive option for genuinely old equipment, and it still supports the core availability and rough performance calculations OEE needs.
- Retrofit sensors independent of the PLC. Where neither of the above is practical, adding independent sensors, a photoeye counting parts off a conveyor, a vibration sensor detecting the machine is actively cycling, gives you a data source entirely outside the legacy control system. This adds hardware cost but completely avoids any risk to existing validated control logic.
I generally recommend starting with whichever machines have the most accessible connectivity option and proving the OEE calculation and reporting pipeline works end to end on those, rather than trying to solve the hardest, most isolated legacy machine first and letting that stall the whole project.
The downtime reason problem
Capturing that a machine is down is the easy part. Capturing why it's down, in a way that's consistent and useful for root cause analysis, is much harder, and it's the piece that determines whether your OEE program actually drives improvement or just produces a number.
For legacy equipment without rich diagnostic data available electronically, I'd pair automated state capture with a simple, fast manual reason code entry at a operator terminal near the machine, a short, well designed list of the most common downtime categories specific to that equipment, not a generic universal list. Operators will actually use a short, relevant list consistently. They'll ignore or misuse a long generic dropdown that doesn't match what they're actually experiencing on the floor.
Validation before you trust the numbers
Before rolling out OEE reporting broadly, I always want to see a validation period where the automated data capture is checked against manual observation on the floor. Run a shift or two with someone physically timing machine states and comparing against what the system is reporting. Discrepancies here almost always point to either a signal wiring issue or a state definition mismatch, a machine reporting as running when it's actually in a slow, degraded cycle, for example, and it's much better to catch and fix that during validation than to have a plant manager make decisions off numbers that are quietly wrong.
Rolling this out without disrupting production
Legacy PLC connectivity work should be done in a way that's genuinely non invasive to the running process, especially in regulated or high uptime environments. Passive monitoring approaches, whether protocol based or hardwired signal tapping, that don't write anything back to the PLC or alter its logic are much lower risk than approaches requiring PLC program modification, and I'd default to passive monitoring wherever it's technically feasible, reserving PLC program changes for situations where no other option exists.
What a realistic project looks like
For a plant with a genuinely mixed fleet of legacy and modern equipment, I'd expect a full OEE data capture rollout to take several months, phased by connectivity method, starting with the easiest wins to build organizational confidence in the numbers before tackling the hardest, most isolated legacy machines last. Trying to do it all simultaneously usually means the hardest machines become the bottleneck holding back reporting on the whole line, when they could have been queued up as a later phase without blocking value from the rest of the fleet.
