Machine connectivity is getting live data out of every machine on your floor, modern or ancient, into software that can use it. Modern equipment connects through protocols like OPC UA and EtherNet/IP; older machines connect through Modbus, serial taps, or retrofit sensors. Nothing needs to be replaced to be connected.
Ask a plant manager which machines they can see in real time and the honest answer is usually "the two newest ones, sort of." The rest of the floor runs fine but runs dark: counts on clipboards, downtime reconstructed at shift end, faults that only the operator standing there ever saw. This guide covers the whole connectivity problem: why it is worth doing, what signals to collect, how the protocol landscape actually breaks down, what to do about machines older than the internet, and how to run the project without stalling after the pilot line.
Why connect machines at all?
Because everything downstream depends on it. Machine monitoring, honest OEE, real downtime analysis, predictive maintenance, AI scheduling: every one of these consumes machine data, and every one of them is only as good as the feed. Plants that run on hand-logged data do not just lose accuracy, they lose time; the information arrives hours after the moment it could have changed a decision.
The gap between logged and actual is not small. Manual downtime logs routinely miss the short stops entirely, because nobody writes down the ninety-second jam that happens eleven times a shift. Connected machines record all of it, timestamped, without asking anyone to remember. If you want to put a number on what that visibility is worth on your own lines, the ROI calculators are a reasonable place to start, and machine downtime covers why the invisible stops usually dwarf the visible ones.
What signals should you collect from each machine?
Start with the smallest set that answers real questions. For most machines that is four things: state (running, idle, faulted, off), counts (good and reject), fault codes (why it stopped), and a few process values that drive quality, like a temperature or a pressure. That set alone supports downtime tracking, OEE, and most root-cause work.
Resist the temptation to collect every tag the controller has. A thousand tags nobody looks at is not visibility, it is storage cost plus a naming problem. Signals earn their place by feeding a question someone actually asks. You can always add more later; the architecture below makes that cheap.
How do machines actually connect?
Every machine on a floor falls into one of four tiers, and the tier determines the method. The good news: all four tiers end up in the same place, publishing into the same data infrastructure.
Tier 1: modern machines. Equipment from roughly the last decade often ships with an OPC UA server on board: browsable, typed, secure data access over the standard IEC 62541 protocol. Practical usage details are in OPC UA for machine connectivity.
Tier 2: networked PLCs. Machines built around a PLC with an Ethernet port can be polled by driver: EtherNet/IP (standardized by ODVA) dominates North American floors, PROFINET dominates European and Siemens-heavy ones. An edge gateway with the right driver reads tags without touching the machine's program.
Tier 3: older controllers. Controllers from the 1990s and 2000s usually speak Modbus, first published in 1979 and still everywhere, or a vendor serial protocol over RS-232/485. Protocol gateways convert these to modern transports for a few hundred dollars.
Tier 4: no controller access. Mechanical presses, old grinders, machines whose builder is long gone: these get retrofit instrumentation. A current clamp on the motor tells you run state. A sensor on the stack light tells you faults. A vibration sensor tells you machine health. The full playbook, including what each option costs and what it can and cannot tell you, is in how to connect legacy machines.
A note on wiring versus wireless, because it comes up on every walkdown. Wired Ethernet is still the default for anything on a controller: it is deterministic, cheap, and immune to the RF chaos of a metal-heavy floor. Wireless earns its place at the retrofit tier, where battery-powered sensors report over low-power radio and pulling conduit to a fifty-year-old press would cost more than the sensors themselves. Most plants end up with both, and the gateway does not care: it is all data by the time it publishes. The broader sensor landscape, including what is available off the shelf, is covered in sensors in manufacturing and the wider IIoT primer.
What does the architecture above the machines look like?
The pattern that has won is edge-plus-broker. An edge gateway near the machines does the protocol translation, buffers data through network outages, and publishes changes over MQTT to a broker. Everything that needs machine data subscribes to the broker instead of poking at controllers directly. Many plants structure the broker's topic space as a unified namespace: one live hierarchy for the whole operation, so a new dashboard or AI tool plugs in by subscribing rather than by running a new integration project.
Storage splits by purpose: a historian keeps the dense time-series for trending, while the operational layer keeps events with context: which order, which operator, which lot. The full plumbing details, including security and store-and-forward, are in connecting PLC data to the cloud, and the choice of what to collect and how is in machine data collection methods.
Two failure modes are worth naming because they account for most abandoned stacks. The first is point-to-point sprawl: every application wired directly to every machine, so the tenth integration costs as much as the first and the map of who-talks-to-whom lives in one engineer's head. The broker pattern exists precisely to kill this. The second is the dark historian: years of tag data collected diligently and queried never, because nothing ties the tags to what the plant was doing at the time. Architecture prevents sprawl; only context prevents the dark historian.
How do you run a connectivity project without stalling?
Most connectivity projects die between the pilot and the rollout, usually because the pilot proved the plumbing but nobody used the data. The sequence that avoids that:
- Walk the floor and tier every machine. Controller model, ports, protocols, age. One spreadsheet row per machine. This takes days, not months, and kills the guesswork.
- Pick one line with a real problem. Not the newest line, the one where downtime or scrap actually hurts. Connectivity that answers a live question gets defended at budget time.
- Connect the minimum signal set. State, counts, faults, and the few process values that matter. Ship it in weeks.
- Put the data in front of the people who run the line. Supervisors and operators, not just engineering. If the data does not change a daily decision, find out why before scaling.
- Standardize the pattern, then repeat per line. Same gateway config, same naming convention, same dashboards. Line two should cost half of line one.
- Join machine data to orders and paperwork. This is the step that turns signals into answers, and it is where most stacks stop short.
That last step deserves emphasis. A machine count with no order context tells you the line made 4,812 of something. Joined to the order, the crew, and the quality checks, it tells you what you made, for whom, at what yield, and what went wrong. The data model behind that join is its own topic, covered in the AI-native MES data model.
Where does Harmony AI fit?
Connectivity is one of Harmony AI's core modules, but it is deliberately not sold as plumbing alone. Harmony AI connects your machines across all four tiers, mixed vintages and mixed brands, without replacing any of them, and lands the data in the same operational layer as your digitized paperwork and your existing software systems. That is the difference between a pile of connected tags and a floor you can ask questions of. Harmony AI deploys in person: engineers walk your floor, tier your machines, and wire the lines themselves rather than shipping you a box and a wiki. The CLS case study shows the end state on a real plant: live visibility on lines that used to report by paper, with nothing ripped out.
What do the standards say?
The connectivity stack rests on open standards with decades of stability behind them:
- OPC UA is standardized as IEC 62541 and maintained by the OPC Foundation; it is the vendor-neutral way modern machines expose structured data.
- Modbus dates to 1979 and has been an open protocol under the Modbus Organization since 2004, which is why it remains the lowest common denominator on older equipment.
- MQTT is an OASIS standard, published as ISO/IEC 20922 in 2016; Eclipse Sparkplug, published as ISO/IEC 20237 in 2023, defines how industrial data rides on it.
- EtherNet/IP has been standardized by ODVA since 2000, and PROFINET is maintained by PROFIBUS & PROFINET International; between them they cover most networked PLCs in service.
Build on these and no single vendor owns your data path. That, more than any feature, is what makes a connectivity investment durable.