OPC-UA vs Modbus: Which Industrial Protocol Should You Use?

If you’re connecting industrial equipment, the first decision is the wire protocol — and the two you’ll meet everywhere are Modbus and OPC-UA. They’re often framed as competitors, but they solve different problems at different layers. This is a plain-English comparison to help you choose, and a note on why your middleware shouldn’t force the choice.

Modbus: simple, old, everywhere

Modbus (specifically Modbus TCP on modern floors) is the lingua franca of PLCs. It’s a 1979 protocol and it shows — in a good way for reliability.

How it works: a master reads and writes numbered registers (holding, input, coils) on a slave device over TCP. You poll on an interval. That’s it.

Strengths:

• Ubiquitous. Almost every PLC, drive, and instrument speaks it.
• Dead simple. Register 40001 holds an int. You poll it. No discovery, no schemas.
• Predictable. Deterministic polling; easy to reason about timing.
• Low overhead. Great for low-power edge devices.

Weaknesses:

• No built-in security. No authentication or encryption in classic Modbus TCP.
• No data typing. A register is 16 bits; you decide if it’s an int, two bits of a float, or a status flag. Decoding lives in your code.
• Polling only. No events or subscriptions — you ask, the device answers.
• Flat address space. No hierarchy or semantic context.

OPC-UA: modern, typed, secure

OPC-UA is the successor designed to fix all of Modbus’s gaps. It’s a full application-layer protocol with a data model.

How it works: a client subscribes to nodes in a server’s address space. Nodes have types, units, and descriptions. The server can push value changes (subscriptions) instead of waiting to be polled.

Strengths:

• Typed, semantic data. Nodes carry type, unit, and meaning — less manual decoding.
• Built-in security. Authentication, authorization, encryption, and signing.
• Subscriptions / events. Push-based; you get notified on change instead of polling blindly.
• Structured address space. Hierarchical, browsable, self-describing.

Weaknesses:

• Heavy. Bigger stack, more CPU and memory — harder on tiny edge devices.
• Complex to configure. Security certs, endpoint negotiation, node mappings.
• Not universal. Older or cheaper devices don’t expose it; you may still need Modbus for them.

Side by side

How to choose

• Pick Modbus when the device only speaks Modbus (common), you’re on a constrained edge device, or you want dead-simple deterministic polling.
• Pick OPC-UA when the device supports it, you need security, you want push-based change notifications, or you’re tired of hand-decoding registers.

In practice, most real floors have both: Modbus on the legacy PLCs and sensors, OPC-UA on newer machines and SCADA gateways. That’s normal.

The real problem is neither — it’s the layer above

Here’s the thing: choosing the protocol is the easy part. The hard part is what comes after. Both protocols hand you data that still needs to be:

• Normalized to one shape (Modbus registers and OPC-UA nodes look nothing alike).
• Transformed — filtered, unit-converted, enriched — before it’s useful.
• Routed to a warehouse, broker, or app.

If your middleware speaks only one protocol, you end up with Modbus data over here and OPC-UA data over there, decoded twice and never quite matching.

Why OpexFlow speaks both

OpexFlow normalizes every source — Modbus, OPC-UA, MQTT, FOCAS, MTConnect — to a single CanonicalMachineData struct at the source boundary. From the transform layer down, it doesn’t matter which protocol produced the event. A Modbus register and an OPC-UA node that represent the same spindle speed end up in the same spindle.speed field.

That means:

• You choose the protocol per device on its merits, not on what your transform code can cope with.
• Transforms and sinks are written once, against one shape. (See the transform DSL.)
• Mixing a legacy Modbus PLC with a new OPC-UA machine is a config change, not a rewrite.

The bottom line

Modbus and OPC-UA aren’t rivals — they’re tools for different devices and constraints. Pick per device, then put a middleware above them that normalizes both to one shape so your transforms and storage don’t care. That’s the whole idea behind OpexFlow.

Want both on one floor? See how it works, read the adapter reference, or request a license.

Related: Modbus to ClickHouse the right way and OpexFlow as a Kepware alternative.