August 11, 2026 · Comparison

OPC UA vs Modbus TCP: Which Industrial Protocol to Choose

Modbus TCP and OPC UA are the two protocols you will meet on almost every industrial Ethernet network. Both are open. Both run over TCP. Both let a client read and write values on a remote device. That is roughly where the resemblance ends. Modbus TCP is a 1979 serial protocol lifted onto TCP port 502 — minimalist, stateless, ubiquitous on cheap field hardware. OPC UA is a modern, service-oriented stack with a self-describing information model, built-in security, and standardized domain models that scale from the device layer to the enterprise.

This guide compares the two on the axes that actually decide which one to use: data model, security, discovery, transport, scalability, and best-fit use cases. For how UA compares to a lighter alternative still, see OPC UA vs MQTT; for UA's address space in detail, see the information model explainer.

Modbus TCP: The 1979 Protocol on Ethernet

Modbus was originally a serial protocol (RTU over RS-485) published by Modicon in 1979 for its PLCs. Modbus TCP wraps the same application-layer PDU in a TCP segment, defaulting to port 502. The model is stubbornly simple:

• Master/slave (called client/server in the TCP spec, but functionally master/slave). The master sends a request; one slave replies. Slaves never speak first.
• Four data tables per slave: coils (1-bit read/write), discrete inputs (1-bit read-only), input registers (16-bit read-only), holding registers (16-bit read/write). That is the entire data model.
• Function codes are the read/write API. 0x01 Read Coils, 0x03 Read Holding Registers, 0x06 Write Single Register, 0x10 Write Multiple Registers, 0x17 Read/Write Multiple Registers, and so on.
• Stateless request/response. Each transaction is independent. No sessions, no subscriptions, no push.
• Per-frame addressing: a request targets slave id 1–247, a starting register number, and a quantity. Typical practical limit is around 250 devices per network segment.

The protocol specifies nothing about what each register means. Register 40001 on slave 5 might be the temperature of a motor winding, a setpoint for a VFD, or the firmware revision of an energy meter — you can only know via a separate, out-of-band register spreadsheet provided by the device vendor. That spreadsheet is where most of the operational pain of Modbus lives.

OPC UA: A Modern Industrial Stack

OPC UA (Unified Architecture) was designed from scratch as a platform-independent replacement for classic COM/DCOM-based OPC. Its surface area is much larger than Modbus:

• Self-describing information model. A browseable address space of typed nodes (objects, variables, methods, types) with engineering units, ranges, and semantic meaning. See information model and companion specs.
• Discovery. FindServers, GetEndpoints, and RegisterServer let a client locate servers on a network and learn their capabilities before connecting.
• Built-in security. X.509 certificates, mutual authentication, message signing, and encryption — selectable per endpoint via security policies (None / Sign / SignAndEncrypt). See security and certificates.
• Subscriptions and monitored items. The client subscribes to variables and is notified on change (push) rather than polling (pull). See subscriptions.
• Methods. Servers can expose callable functions, not just data — clients invoke methods with typed arguments and get typed return values.
• Multiple transports. UA Binary over TCP (default port 4840), or HTTPS/JSON for web-facing integrations.
• Companion specifications. Standardized domain models (Machinery, Machine Tools, Robotics, PLCopen) so multi-vendor equipment exposes the same data the same way.

Feature Comparison

Performance and Overhead

Modbus TCP's per-frame overhead is genuinely tiny — a typical Read Holding Registers request is 12 bytes on the wire and the response is 6 bytes plus 2 bytes per register. For high-frequency polling of a small register set on a constrained device, Modbus TCP is hard to beat. But that low per-frame cost is offset by two ongoing costs: the master must poll continuously to detect changes, and the client must already know the register map via out-of-band documentation. Polled traffic scales as O(devices × registers × poll rate).

OPC UA's handshake is heavier: certificate exchange, session establishment, and subscription creation all cost more bytes and round-trips than a Modbus read. But once a subscription is established, the server pushes only the changes that matter, with their timestamps and qualities, on a single TCP connection. For a plant monitoring hundreds or thousands of tags where most values are stable, OPC UA's ongoing cost is lower than equivalent Modbus polling, even though the handshake was more expensive.

When Modbus TCP Wins

• Simple devices. Energy meters, VFDs, remote I/O modules, basic sensors — most of these speak Modbus TCP out of the box and nothing else.
• Cost-sensitive deployments. Modbus TCP is royalty-free, has near-zero CPU and RAM requirements, and ships on devices that cost tens of dollars. UA stacks cost real engineering budget to implement well.
• Legacy equipment. Decades of installed PLCs only expose Modbus TCP. You cannot retrofit UA onto them.
• Small fixed installations. A single machine with one PLC and one HMI, where the register map is documented once and never changes.
• When you already have the map. If the register spreadsheet is in hand and the client is built against it, Modbus TCP just works.

When OPC UA Wins

• Multi-vendor plants. Three vendors' equipment, one client technology, one information model. Companion specs make this real; see companion specifications.
• Security requirements. Anything internet-adjacent, audit-controlled, or in a regulated industry. Modbus TCP's lack of authentication or encryption is a liability that can only be papered over with VLAN isolation.
• Semantic data. When the client needs to know "this is a temperature in degrees Celsius with range 0–150", not "this is a 16-bit integer at address 40017".
• SCADA and enterprise integration. Alarms, events, historian, method invocation — UA has these in the protocol; Modbus TCP does not.
• Anything needing browseable tags. When connecting to a server you have never seen before and discovering what is there is part of the workflow.

The Common Pattern: Gateway Aggregation

Most real plants do not pick one. The dominant architecture in industry today is Modbus TCP at the device layer, OPC UA at the controller or gateway layer, upstream to SCADA and beyond. A gateway (a PLC, an edge box, or a dedicated protocol converter) polls Modbus TCP field devices, exposes their data as a typed OPC UA address space upstream, and lets the SCADA system speak one protocol instead of fifty. This is also exactly the pattern MacTools OPC UA Explorer and Voltrus Gateway are built to support — bridge Modbus field devices into a self-describing UA facade, then browse and subscribe from macOS as if every device on the floor were UA-native.

Accessing Both From macOS

MacTools OPC UA Explorer is a native UA client: connect to any UA server, browse the address space, read and write variables, subscribe to monitored items, and call methods. For Modbus TCP field devices, the practical path is to put a UA gateway in front of them and browse the gateway — your macOS client then sees a single, typed address space that hides the Modbus polling underneath. This is the cleanest way to consume both protocols without running two separate client tools.

Frequently Asked Questions

Can OPC UA replace Modbus TCP?

In most modern plants, yes — OPC UA covers everything Modbus TCP does (read and write values over Ethernet) and adds self-describing data, built-in security, subscriptions, and standardized domain models. The exception is at the low end: cheap field devices, energy meters, and legacy equipment where Modbus TCP's near-zero footprint and universal support still win. Gateways aggregating Modbus into UA upstream are the common compromise.

Is Modbus TCP still used in new installations?

Heavily. Modbus TCP remains the default on low-cost PLCs, VFDs, energy meters, and remote I/O because it is royalty-free, simple to implement, and supported by virtually every industrial device. New plants routinely deploy Modbus TCP at the device layer and bridge it into OPC UA at the controller or gateway layer for SCADA consumption.

Does Modbus TCP have security?

No. Modbus TCP is a plaintext protocol with no authentication, no encryption, and no message integrity. Security depends entirely on network isolation — dedicated VLANs, firewalls, and physical separation. If a client can reach TCP port 502 on a slave, it can read and write any register. OPC UA, by contrast, has X.509 certificates, signing, and encryption built into the protocol.

Why use OPC UA over Modbus TCP?

Use OPC UA when you need multi-vendor interoperability, browseable self-describing tags, built-in security, push-based subscriptions instead of polling, or integration with SCADA and enterprise systems. Use it wherever the alternative would otherwise require a manually maintained register spreadsheet. Modbus TCP remains preferable for simple, cost-sensitive field devices where the register map is already known.

Further Reading

• OPC UA Information Model Explained
• OPC UA Subscriptions and Monitored Items
• OPC UA Security: Certificates and Encryption
• Industrial Protocol Comparison