Machine connectivity protocols are the languages equipment uses to share data. On the floor you will meet Modbus, EtherNet/IP, and Profinet; between machines and software, OPC UA and MQTT dominate. Almost no plant runs just one, so the real job is translating a mix of protocols into a single usable stream. The good news: every protocol that matters is open, documented, and supported by mature tooling. You do not need to standardize your machines. You need a layer that speaks all of them.
This guide maps the protocol landscape in plain English: what each protocol is for, how data actually moves, how to choose a path for your own plant, and what to do about machines that speak nothing at all. It pairs with our guides to machine data collection methods and OPC UA for machine connectivity.
What is a machine connectivity protocol?
A protocol is an agreement about how two devices exchange data: how a value is addressed, encoded, transported, and secured. When software asks a PLC for the machine state, the protocol defines how that question is framed and how the answer comes back. Protocols matter to non-engineers for one reason: they decide how hard, and therefore how expensive, it is to get data out of a given machine. A machine with an OPC UA server is an afternoon of configuration. A machine with a proprietary serial port from 1993 is a puzzle. A machine with no port at all is a retrofit sensor. All three are solvable; the protocol just sets the path.
Which protocols will you actually meet on the floor?
Four families cover most plants:
| Protocol | Steward | Where you meet it | Character |
|---|---|---|---|
| Modbus (RTU/TCP) | Modbus Organization | Drives, meters, older PLCs, utilities | Born 1979. Simple registers, no data typing, no built-in security. Everywhere. |
| EtherNet/IP | ODVA | Rockwell/Allen-Bradley environments | Industrial Ethernet carrying CIP. Common across North American plants. |
| Profinet | PROFIBUS & PROFINET International | Siemens environments | Industrial Ethernet, strong in European-built machinery. |
| OPC UA | OPC Foundation (IEC 62541) | Modern PLCs, machine tools, packaged lines | Rich typed data model, discovery, built-in security. The lingua franca upward. |
Beneath these sit serial links, proprietary interfaces, and plain discrete I/O. Above them sits MQTT, which is less a machine protocol than a delivery service: a lightweight publish-subscribe transport that moves whatever payload you give it. The Sparkplug specification adds a standard topic structure and payload format so MQTT data is self-describing rather than ad hoc.
What do OPC UA and MQTT do differently?
OPC UA and MQTT are complements, not rivals, and most modern architectures use both. OPC UA is a full information model: a client can browse a server, discover that a tag is a temperature in Celsius on machine 4, and read it with security built in. It answers the question "what data exists and what does it mean?" MQTT answers a different question: "how do I move data efficiently to many consumers?" It is a publish-subscribe transport where devices push updates to a broker only when values change, which is light on bandwidth and ideal for sending plant data to servers and cloud systems; see connecting PLC data to the cloud. Sparkplug closes MQTT's gap by standardizing topics, payloads, and birth/death certificates so subscribers know what they are receiving and whether a device is online.
How does data actually move: poll or publish?
Two patterns move nearly all machine data. Polling asks on a schedule: a gateway reads a Modbus register or PLC tag every second and passes the value along; it is simple and predictable but generates traffic whether anything changed or not. Publish-subscribe reports by exception: the device announces changes as they happen, so a machine state that flips twice an hour sends two messages, not 3,600. Report by exception scales far better across a plant, which is why the MQTT/Sparkplug pattern has become the default for moving data beyond the machine network, while polling remains the workhorse for extracting data from the machines themselves. In practice the edge does both: poll the floor, publish upward.
How do you choose a protocol path for your plant?
You mostly do not choose protocols; your machines already did. What you choose is the extraction path per machine and the standard you normalize to. A practical sequence:
- Inventory what each machine already speaks. Model and year of the PLC or controller answers most of it. Note ports, protocols, and whether tags are documented.
- Take the easiest honest path per machine. OPC UA server if present; native driver (EtherNet/IP, Profinet, Modbus TCP) if not; serial gateway for legacy links; retrofit sensor when there is nothing to talk to. Do not force elegance; see how to connect legacy machines.
- Normalize at the edge. Translate everything into one namespace with consistent names, units, and timestamps. This is where tag mapping discipline pays off for years.
- Publish upward over an open standard. OPC UA or MQTT/Sparkplug out of the edge, so no software above the plant ever needs a proprietary driver again.
- Design security in from day one. Segment machine networks, keep data flow outbound, and treat the edge as read-only; our guide to machine connectivity and security covers the pattern.
What about machines with no network at all?
A machine with no controller and no port still shows its state physically: a motor draws current, parts break a photo eye, a stack light glows. Retrofit sensors turn those physical facts into signals: a current sensor on the motor gives run/stop, a proximity sensor gives cycle counts, a tap on the stack light gives machine state. These signals are modest, but as our post on connecting machines for OEE shows, run state plus counts is most of what daily improvement needs. Retrofit machine monitoring covers the options in depth.
What do the standards bodies say?
Every protocol above is an open, published standard with a steward you can read directly:
- Modbus, introduced in 1979 and now stewarded by the Modbus Organization, remains freely published, which is why implementations are everywhere from VFDs to power meters.
- EtherNet/IP is managed by ODVA and carries the Common Industrial Protocol (CIP) over standard Ethernet.
- OPC UA is published by the OPC Foundation and standardized internationally as IEC 62541, with security and information modeling in the specification itself.
- MQTT is an OASIS and ISO standard, ISO/IEC 20922; the Sparkplug specification from the Eclipse Foundation became ISO/IEC 20237 in 2023.
The takeaway for a plant manager: none of this is vendor lock-in territory anymore. The protocols are public, the tooling is commodity, and connectivity cost has fallen accordingly; our post on the ROI of connecting machines works through what that means for payback.
Where does Harmony AI fit?
Harmony AI treats protocol translation as table stakes, not the product. The platform connects to what your floor already speaks, modern PLCs over their native protocols, older devices over Modbus or serial gateways, unnetworked machines through retrofit sensors, and normalizes everything into one operational layer where machine data meets schedules, paperwork, and people. No rip-and-replace, and no requirement that your machines share a brand or a decade. Deployment happens in person: the field team typically visits once or twice, walks the floor with your electricians, and maps the extraction path machine by machine. The CLS case study shows the end state on a real line: mixed equipment, one live picture. For the wider context on plant networks, see what is SCADA and IIoT.