To connect mixed-vintage equipment, tier the fleet: machines without PLCs get external sensing like current clamps and light taps, PLC-era machines get gateway reads, and modern machines stream native protocols. Then normalize everything into one shared data model so every vintage reports the same states and counts on one screen.
Brochure factories are born in one year. Real ones accrete: a press bought when the founder's father ran the shop, CNCs from three different decades, a packaging line added for a big contract, one shiny robot cell. The average age of U.S. manufacturing capital has been rising for decades per Bureau of Economic Analysis fixed-asset data, and rising average age means widening spread: new machines arrive while old ones refuse to die. Connecting that spread is a different problem from connecting a greenfield plant, and this post is about solving it without waiting for the fleet to turn over. It extends connecting machines without replacing them to the fleet level.
Why is mixed-vintage the hard case?
Because every era of equipment externalizes data differently, and most floors contain all the eras at once. Pre-1990 machines are electromechanical or relay-controlled: no data port, no protocol, nothing to query. The PLC era brought controllers you can read, but through a Babel of serial links, fieldbuses, and vendor protocols that changed by decade and by brand. The modern era finally speaks standard tongues like OPC UA and MTConnect natively. A connectivity plan that assumes any single era fails on the other two: the all-modern plan strands the old iron, and the lowest-common-denominator plan wastes the rich data the new machines give away free.
The result, in plants that improvise, is three half-systems: a sensor app for the old machines, a historian for the PLCs, and a vendor cloud for the robot, none agreeing on what "running" means. That is how data silos get rebuilt one generation newer.
There is a human version of the same spread. The old machines are usually the best understood by people and the least understood by systems: the operator who has run the press since 1996 can hear a bad cycle from across the aisle, while the robot cell arrived with terabytes of telemetry and nobody who feels it in their teeth. Connecting the fleet evens this out in both directions. The press finally produces a record that outlives its operator's retirement, and the robot's torrent gets reduced to the handful of facts a supervisor actually acts on. Vintage diversity is not just a wiring problem; it is a knowledge-capture opportunity wearing a wiring problem's clothes.
How do you connect a mixed-vintage floor?
Five steps, run as one pass across the whole fleet rather than machine by machine:
- Census the fleet. Walk the floor and record every asset's age, controls, ports, stack lights, and criticality. A spreadsheet and a day of walking beats a quarter of meetings.
- Assign tiers, not wishes. Tier 1: no controller, sense from outside with retrofit monitoring. Tier 2: has a PLC, read it through a gateway; the wrinkles live in connecting legacy machines. Tier 3: speaks a modern protocol, subscribe directly.
- Define the shared data model first. Before any hardware ships, write down the states, counts, and names every machine must report: what counts as running, down, changeover, starved. This document is worth more than any sensor.
- Connect in criticality order. Constraint line first, chronic offenders second, balance of plant last. Value funds the rollout.
- Commission each machine against the model. Stand at the machine and verify its reported state matches reality, so the 1989 press and the 2023 robot mean the same thing by "down".
Why does one data model matter more than the hardware?
Because comparability is the whole prize. The plant does not need the press to report like a robot; it needs both to answer the same questions: running or not, how many, how fast, why stopped. When every vintage maps into one model, downtime Paretos span the whole floor, OEE is computable line by line with the OEE calculator, and the scheduler can trust rates from any asset. Without the shared model you get precise incomparability: perfect vibration spectra from one machine, tag soup from another, and no answer to "which line lost the most hours last week".
The standards help at the protocol level: OPC UA, standardized as IEC 62541 by the OPC Foundation, and MTConnect (ANSI/MTC1.4) for machine tools both exist precisely to give equipment a common vocabulary. But standards only reach the machines that speak them; the operational data model is what extends the same discipline to the clamp on the 1989 press. That model, plus the protocols, is what turns a mixed fleet into a smart factory rather than a museum with sensors.
What are the classic mixed-fleet mistakes?
Letting the oldest machine set the ceiling: "we can't do connectivity, half our floor is from the eighties" ignores that tier 1 sensing handles exactly those machines. Letting the newest machine set the standard: designing the data model around the robot's 400 tags guarantees the press can never comply; design around the questions instead. Serial perfectionism: spending a year on the hardest legacy integration while easy value waits; connect the cheap 80 percent first. Deferring to the next capital cycle: the fleet will still be mixed after the next purchase, because fleets are always mixed. The plan has to work for the floor you have. And one quiet failure worth naming: connecting everything and comparing nothing. If the signals land in per-vendor apps instead of one layer, the plant ends up better instrumented and no better informed, which discredits the whole effort with the people whose trust the next phase needs.
How does Harmony AI connect a mixed fleet?
This is Harmony AI's home turf, and the model is exactly what this post describes because this post describes our model. We deploy in person, white-glove: engineers walk your census with you, tier every asset, connect each one the cheapest reliable way, and normalize everything into one operational layer that also holds your ERP, quality, and paperwork data, so machine events land next to the records they explain; see the platform. No rip-and-replace, and no machine dismissed for its age. The CLS case study covers a multi-shop operation whose equipment spans decades, unified on one live layer. The fleet you have is connectable as it stands. The only real decision is the order.