If you're building a machine data pipeline for a discrete manufacturing plant that's been running for more than five years, you will encounter Modbus. If you're connecting to new equipment installed in the last few years, you will encounter OPC-UA. If you're deploying condition monitoring across a mixed floor — legacy presses from the 1990s alongside a new CNC machining center commissioned in 2022 — you will need to handle both, cleanly, in the same ingestion architecture.
This article lays out what each protocol is actually doing, where each one works well, where each one creates problems, and how to structure your data pipeline so you're not rebuilding the ingestion layer every time you add a new machine class.
Modbus: What It Is and Why It's Everywhere
Modbus was introduced by Modicon in 1979 as a serial communication protocol for PLCs. It became a de facto standard for industrial device communication and has never really been displaced on legacy equipment — it's simply too embedded. Modbus RTU runs over RS-232 or RS-485 serial lines. Modbus TCP/IP carries the same PDU structure over a standard TCP connection, which is the variant most relevant to plant-floor data ingestion today.
The data model is a flat register map: Coils (1-bit read/write), Discrete Inputs (1-bit read-only), Input Registers (16-bit read-only), and Holding Registers (16-bit read/write). Function codes define the operation: FC01 reads coils, FC03 reads holding registers, FC16 writes multiple holding registers, and so on. That's the extent of the native data model. There is no native data type definition — a 32-bit float requires two consecutive 16-bit registers, and whether the high word comes first or second (big-endian vs little-endian register ordering) is not standardized across vendors. You will encounter both, sometimes on the same product line across different firmware versions.
Polling is master-slave and strictly synchronous. The Modbus master sends a request; the slave responds. There are no subscriptions, no change notifications, no push events. If you want 100 ms data from a Modbus device, your master must poll at 100 ms intervals. This creates polling load on the master and on the device, and it means your sampling rate is bounded by the round-trip latency of the polling cycle — which matters for vibration data where you may want higher-frequency sampling.
For reading process data — temperatures, pressures, counts, status flags — Modbus TCP is workable and familiar to most PLC programmers on the floor. For reading high-frequency vibration data directly, it's a poor fit: the polling architecture was not designed for streaming continuous waveform data at 1 kHz+ sample rates.
OPC-UA: The Architecture Built for Modern IIoT
OPC-UA (Unified Architecture, standardized as IEC 62541) is a different class of protocol. It's not just a communication layer — it's a data modeling framework, a security architecture, and a service set. The relevant services for condition monitoring data ingestion are the Data Access (DA) profile for current-value polling and the Historical Access (HA) profile for reading buffered data from a historian.
OPC-UA's information model is object-oriented. Nodes have typed attributes, references to other nodes, and optional metadata including engineering units, data type definitions, and description strings. When you connect to an OPC-UA server on a modern CNC controller, you can browse the address space and discover what data is available — machine state, spindle speed, axis positions, temperature readings — with their units and types defined in the server's namespace. Compare this to Modbus, where the register map is an external document you need to obtain from the machine OEM, or in some cases, reverse-engineer from the controller's configuration interface.
OPC-UA also supports Subscriptions with MonitoredItems and ChangeNotifications. Instead of polling every register on a fixed interval, your client subscribes to a set of nodes and receives a notification when the value changes or when a configurable sampling interval elapses. This is much more efficient than polling for slowly-changing process data, and it reduces the latency between a change on the device and its arrival in your ingestion layer.
Security is built in: OPC-UA defines authentication (username/password, X.509 certificates), message signing, and message encryption at the transport layer. Modbus has no native security mechanism whatsoever — it was designed for isolated fieldbus networks and assumes everything on the network segment is trustworthy.
The Practical Reality on a Mixed Plant Floor
A job shop in Michigan running 14 CNC lathes — eight machines from 2015–2018 with Fanuc controls that expose OPC-UA servers, plus six older turret lathes from 2008–2012 with older Mitsubishi controls that only support Modbus TCP via a third-party gateway — faces a representative ingestion problem.
The OPC-UA machines are relatively straightforward: deploy an OPC-UA client that connects to each controller, browses the server namespace, subscribes to spindle current, spindle speed, and program state nodes, and streams the values to the ingestion platform via MQTT or a REST endpoint. Authentication via certificate. Sampling at 200 ms intervals for process data.
The Modbus machines require a different approach. The ingestion layer must function as a Modbus TCP master, poll each machine's register map on a schedule, handle register endianness correctly for each specific controller model, and scale the raw register values to engineering units using the OEM-provided scaling factors. You also need to handle polling failures gracefully — Modbus devices will go silent on network glitches without any error signaling, and an ingestion pipeline that doesn't distinguish between "value unchanged" and "no response received" will silently introduce data quality issues.
Running both in the same ingestion architecture means your pipeline needs a protocol abstraction layer that normalizes the output regardless of source: a timestamp, a machine identifier, a tag name, a value, a quality indicator, and an engineering unit. Whether that value came in via OPC-UA subscription or Modbus TCP poll should be invisible to the analytics layer above it.
EtherNet/IP and What Sits Outside This Comparison
A note on EtherNet/IP, which is the industrial Ethernet protocol used natively on Rockwell/Allen-Bradley control systems and is common in US automotive supplier plants: EtherNet/IP uses the Common Industrial Protocol (CIP) over Ethernet. It offers tag-based access similar to OPC-UA in concept (Explicit Messaging for read/write, Implicit Messaging for I/O streaming), but it's proprietary in its tag address structure and doesn't share OPC-UA's open information model or security framework.
For condition monitoring data ingestion from Rockwell-controlled equipment, you typically read EtherNet/IP via a data server layer (Kepware KEPServerEX or similar OPC-UA gateway products that support EtherNet/IP as a source) rather than direct EtherNet/IP client implementation in your ingestion pipeline. This means the practical advice for EtherNet/IP floors is: get the data into OPC-UA via a gateway, then treat it as an OPC-UA source from the ingestion side.
This article isn't covering every protocol in industrial automation — PROFINET, CC-Link, and several others exist and may be relevant to specific equipment in your facility. The Modbus vs. OPC-UA framing covers the protocols that appear most frequently in discrete manufacturing data ingestion projects in North America, not the complete universe of fieldbus options.
When to Prioritize Each Protocol in Your Design
For new installations where you have a choice of protocol for data access, OPC-UA is the right selection. It provides richer data modeling, built-in security, subscription-based delivery, and standard compliance that will make future integrations — to CMMS, MES, or historian — much easier to maintain.
For existing Modbus devices that aren't being replaced in the near term, build clean Modbus TCP polling with thorough error handling and value-change detection. Don't attempt to shoehorn high-frequency waveform data through a Modbus polling loop — if you need raw accelerometer data from a sensor attached to that machine, run a separate direct data acquisition path (USB DAQ, vibration transmitter with analog output, or an edge computing node with local sensor acquisition) alongside the Modbus process data feed.
The blend of both protocols on most real plant floors is not a problem to be solved — it's a reality to be architected around. The plants that get this right normalize early, document their register maps and node addresses carefully, and invest in a protocol abstraction layer that lets the analytics and alerting systems work with clean, unit-correct time-series data regardless of where it originated.