FoundryNet / Compare / DNP3 vs Modbus TCP
Protocol comparison

DNP3 vs Modbus TCP

The utility SCADA question, and the one place where Modbus's simplicity is genuinely a liability.

Get an API key All 14 adapters

Side by side

The comparison

DNP3Modbus TCP
SpecificationIEEE 1815Modicon Modbus, TCP encapsulation (Modbus-TCP)
First published19931979 (serial), 1999 (TCP)
TransportTCP 20000, or serialTCP, port 502
Data modelObject groups and variations — binary input, analog input, counter — with quality flags and event time tags built in.Flat 16-bit registers and single-bit coils. No types, no names, no metadata — a register is a number at an address.
DiscoveryLimited. Point lists are configured, not browsed.None. You need the vendor's register map, usually a PDF.
SecuritySecure Authentication v5 is specified and is genuinely used in utility deployments.None in the base specification. Whatever the network gives you.
Polling or subscriptionPolling plus unsolicited responses, with time-tagged event buffering so nothing is lost across an outage.Polling only. The client asks; the device answers.
Implementation complexityHigh. Class 0/1/2/3 scanning, event buffers and time synchronisation are all real concepts.Lowest of any protocol here. A working client is ~200 lines.
Typical industriesElectric utilities, water, and SCADA over WAN links.Everything. Drives, meters, inverters, sensors, PLCs, BESS.
Forge supportNo adapter today. DNP3 data reaches Forge only via a gateway that re-publishes to a supported transport.Adapter shipped. 14 OEM families mapped.

Where each one wins

DNP3

Strength. Built for lossy WAN links: event buffering and time tagging mean a comms outage does not lose data.

What it costs you. Utility-specific and heavyweight for anything that is not SCADA.

DNP3 adapter →

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 →

Modbus over a WAN link loses data during an outage and cannot tell you it did. DNP3 buffers time-tagged events specifically so it does not. If your link is reliable, Modbus's simplicity wins; if it is not, DNP3's complexity is the feature you are paying for.


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.

These two protocols do not carry a canonical field in common in the corpus — they serve different domains, and pretending otherwise would make a better diagram and a worse answer. What they do share is the output schema.

DNP3

No adapter today. Readings reach Forge only through a gateway that republishes onto a supported transport.

Modbus TCP — Sungrow

{"Battery charging power": 1450}
# normalized
{"charge_rate_kw": 1450}

Different fields, different domains, one schema and one query surface across both.

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

Keep reading

Protocol hubs

DNP3 Modbus TCP All adapters
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.