FoundryNet / Compare / Modbus TCP vs OPC UA
Protocol comparison

Modbus TCP vs OPC UA

The default retrofit question. You have a plant of Modbus devices, a new machine arrives speaking OPC UA, and someone has to decide what the site standard is.

Get an API key All 14 adapters

Side by side

The comparison

Modbus TCPOPC UA
SpecificationModicon Modbus, TCP encapsulation (Modbus-TCP)IEC 62541
First published1979 (serial), 1999 (TCP)2008
TransportTCP, port 502TCP binary on 4840, or HTTPS
Data modelFlat 16-bit registers and single-bit coils. No types, no names, no metadata — a register is a number at an address.A full information model: typed nodes, references, objects, methods and historical access. The richest model in industrial automation.
DiscoveryNone. You need the vendor's register map, usually a PDF.Built in. Browse the address space, read the type definitions.
SecurityNone in the base specification. Whatever the network gives you.Built in and mandatory to configure: X.509 certificates, signing, encryption, user authentication.
Polling or subscriptionPolling only. The client asks; the device answers.Both. Polled reads and subscriptions with monitored items and dead-banding.
Implementation complexityLowest of any protocol here. A working client is ~200 lines.High. The stack is large, certificate handling is a real operational task, and server implementations vary.
Typical industriesEverything. Drives, meters, inverters, sensors, PLCs, BESS.Modern machine tools, robotics, packaging, anything specified after ~2015.
Forge supportAdapter shipped. 14 OEM families mapped.Adapter shipped. 23 OEM families mapped.

Where each one wins

Modbus TCP

Strength. Universal, trivial to implement, works on hardware from 1985.

What it costs you. Carries no semantics whatsoever. Scaling, byte order and register meaning all live outside the protocol.

Modbus TCP adapter →

OPC UA

Strength. Self-describing. You can walk a server you have never seen and learn what it holds.

What it costs you. Self-describing is not the same as standardised — two vendors model the same machine differently, so the names still need mapping.

OPC UA adapter →

They are not competitors so much as different eras. Modbus gives you a number and no context; OPC UA gives you context and charges you a stack for it. Most real plants end up running both, which is precisely the situation that makes a normalization layer worth having rather than a nice-to-have.


The Forge angle

Whichever one you pick, the output is the same

Forge is not an argument for a protocol. It is the layer that makes the choice stop mattering downstream: 16,908 curated mappings across 14 protocol adapters, resolving to 366 canonical fields with enforced units and physics bounds.

Two devices, two protocols, two vendors, two entirely different tag names — and one canonical field out. Both of these are real mappings from the corpus, not illustrations.

Modbus TCP — Fanuc

# raw tag on the wire
{"actual_feed": 1450}
# normalized
{"feed_rate": 1450}

OPC UA — DMG Mori

# raw tag on the wire
{"FeedActual": 1450}
# normalized
{"feed_rate": 1450}

Same field: feed_rate. Same unit contract, same physics bounds, same shape. Your query does not need to know which protocol the reading arrived on.

# Try it against both, with no key and no account
docker run -p 8000:8000 ghcr.io/foundrynet/forge-sandbox

Keep reading

The protocol you pick matters less than the schema underneath. The Machine Agent, weekly. Read it →
Get the thesis behind this infrastructure — The Machine Agent, weekly.