Plant protocols explained: Modbus, OPC UA, MQTT and Sparkplug B, and where each belongs
The four protocols that carry most plant data were built for different problems at different levels of the plant. What each was built for, how it works, what it carries, what security it has and what to watch for, set on a map of the plant with a rule for choosing by what the link has to do.
Key takeaways
- Four protocols carry most plant data: Modbus between devices and controllers, OPC UA between systems, MQTT from the edge outward, and Sparkplug B to make MQTT self-describing.
- They are not rivals. Each solves a different problem at a different level of the plant, and a well-built site uses all four, each where it belongs.
- Modbus carries numbers with no names. OPC UA carries a typed, browsable model with security built in. MQTT carries anything through a broker. Sparkplug B says what the anything means.
- The choice follows the link: what has to be read, how far it has to travel, whether the network is reliable, and whether anyone on the far end will know what a value means without a document.
- Whatever the protocol, the data leaves the plant one way, through the DMZ, and nothing on the business side writes back.
Ask three engineers which protocol a plant should use and the argument that follows will miss the point. The four protocols that carry most plant data were each built for a different problem at a different level of the plant, and a site that runs well uses all of them, each where it belongs. Modbus talks to devices. OPC UA talks between systems. MQTT moves data from the edge outward. Sparkplug B makes MQTT say what its data means.
This guide explains each of the four plainly: what it was built for, how it works, what it carries, what security it has, and what to watch for. It then sets them on a map of the plant, gives a rule for choosing by what the link has to do, and ends with the one rule that holds for all of them, which is that data leaves the plant one way.
It sits beside the data historian guide, which covers what happens to the data once it has been collected, and the technology stack guide, which places all of this in the ISA-95 layers. Enco's own historian, Histenco, collects through all four.
Modbus: the register map
Modbus was published by Modicon in 1979 for its programmable controllers and is still the most common way a device exposes its data. A client, once called the master, polls a server, once the slave, for numbered registers: coils and discrete inputs for single bits, input and holding registers for 16-bit values. Modbus RTU runs over serial lines, with many devices on one bus addressed by number. Modbus TCP wraps the same requests in Ethernet frames on port 502.
Its strength is that everything speaks it. Its weakness is that it carries numbers and nothing else. Register 40012 is a 16-bit value, and whether that is a temperature in tenths of a degree, a status word or the high half of a 32-bit float is written in the device manual and nowhere in the protocol. There is no security either. A secure variant over TLS has existed since 2018 and is rarely seen in the field, so a Modbus network is protected by what is around it, not by anything in it.
Managing Modbus is managing its register maps. The map for each device model and firmware version is kept in version control beside the configuration that polls it, with byte order, scaling and units recorded, because the configuration is the only record of what each register means. On a shared serial bus, the poll loop is designed, not left to default, or the slowest device decides the rate for all of them.
OPC UA: the information model
OPC UA, standardised as IEC 62541, is what systems use to talk to each other when they need more than numbers. A server exposes an information model: a tree of nodes, each with a name, a data type, engineering units, a description and relationships to other nodes, that a client can browse without a document. Clients read, write and subscribe, and a subscription delivers changes rather than answers to polls. Controllers, SCADA, historians and MES all offer OPC UA servers or clients, and companion specifications define standard models for industries and equipment classes.
Security is built in rather than bolted on. Each end holds a certificate, the channel is signed and encrypted under a security policy chosen per endpoint, and users authenticate separately from applications. That is also where it goes wrong in practice: servers shipped with security set to none and never changed, certificates that expire with nobody owning the renewal, and a trust list that accepts anything. OPC UA done properly needs someone to own the certificates, the way someone owns the firewall rules.
The other things to watch are commercial. Vendor servers are often licensed by tag count or client count, and an integration that worked at a hundred tags stops at the licence limit. And a publish and subscribe profile exists within OPC UA, which overlaps with MQTT below; most sites use the client and server form on site and MQTT beyond it.
MQTT: the broker in the middle
MQTT is a publish and subscribe protocol, standardised as ISO/IEC 20922, built for telemetry over networks that are slow or drop out. Clients connect to a broker. Publishers send messages to a topic, subscribers ask for topics, and neither knows about the other. Three quality of service levels decide whether a message is sent at most once, at least once or exactly once; a retained message gives a new subscriber the last value; a last will tells everyone when a client drops off. It runs on port 1883, or 8883 over TLS, and a client that loses its connection reconnects and carries on.
That design is why it suits the edge. A remote asset or a site gateway publishes when it can, the broker holds the fan-out, and a hundred subscribers cost the publisher nothing. It is also why the broker belongs in the industrial DMZ: the plant side publishes outward, the business side subscribes, and the broker's topic permissions make the direction a rule rather than a hope.
What MQTT does not do is say what a message means. The topic is a string and the payload is bytes, so every project invents its own conventions, and a subscriber joining later cannot tell a temperature from a status without a document. There is also no state: a subscriber that connects has no way to know which publishers are alive or what they publish. Those two gaps are what Sparkplug B fills.
Sparkplug B: MQTT that describes itself
Sparkplug B is an open specification from the Eclipse Foundation, also published as ISO/IEC 20237, that fixes the three things MQTT leaves open for plant data. The topic namespace is defined, so every subscriber knows where to find a group, an edge node and a device. The payload is defined, in a compact binary format, so every metric carries a name, a data type, a timestamp, quality and optional properties such as units. And state is defined: an edge node announces itself with a birth message that lists every metric and its current value, publishes changes by alias from then on, and is declared dead by the broker through its last will if it drops off.
The effect is report by exception with a known starting point. A subscriber that connects reads the retained births and knows every metric, its type and its last value, then receives only changes. A primary host application can be named, and edge nodes buffer while it is away, so a central historian that goes offline for an hour does not lose the hour. For a fleet of sites feeding one place, this is the difference between a data platform and a pile of JSON.
The things to watch are discipline rather than design. Plain MQTT and Sparkplug on the same broker confuse every subscriber. A primary host that is never configured loses the buffering. And vendors implement the namespace with varying care, so a gateway is tested against a reference host before it is trusted.
MQTT moves the bytes. Sparkplug B is the agreement about what the bytes mean, made once instead of per project.
The four side by side
| Protocol | Lives | Model | Carries | Security | Watch for |
|---|---|---|---|---|---|
| Modbus (RTU and TCP) | Field devices and controllers: drives, meters, small PLCs, gateways | Client polls a server for numbered registers and coils. RTU over serial, TCP on port 502 | 16-bit registers with no names, no units and no types. The meaning lives in the device manual and the poller's configuration | None in the protocol. A newer secure variant over TLS exists and is rarely deployed. Protected by the network around it | Register maps that differ by firmware, byte order, a slow poll loop on a shared serial bus, and a configuration that is the only record of what each register means |
| OPC UA | Controllers, SCADA and the historian: anything that needs a typed, browsable interface | Client and server with browsing, reads, writes and subscriptions, and a publish and subscribe profile. Port 4840 by default | A typed information model: nodes with names, data types, units and structure, discoverable by browsing. Companion specifications for industries | Built in: certificates for both ends, signed and encrypted channels, user authentication, and security policies chosen per endpoint | Servers shipped with security off, certificate handling nobody owns, and licensing or tag limits on vendor servers |
| MQTT | Edge to enterprise and site to site: telemetry, remote assets, the industrial DMZ | Publish and subscribe through a broker. Clients never talk to each other. Port 1883, or 8883 over TLS | Anything. The payload is bytes, and the topic is a string, so the structure is whatever the publisher chose | TLS and user credentials or certificates at the broker. Topic-level permissions decide who may publish and subscribe where | Topic and payload conventions that drift per project, no state on connect, no way for a subscriber to know what a value means without a document |
| Sparkplug B | On top of MQTT, wherever MQTT carries plant data | A specification for the topic namespace, the payload and the state of every node, so MQTT becomes self-describing | Metrics with names, types, units, timestamps and quality, announced in a birth message, then sent on change by alias | The broker's, through MQTT. Sparkplug adds no security of its own | Mixing Sparkplug and plain MQTT on one broker, a primary host that is not set up, and vendors that implement the namespace loosely |
Where each belongs
Set on a map of the plant, the four stop competing. In the field and control band, devices speak Modbus because that is what they have, alongside the controller vendor's own protocols, EtherNet/IP, PROFINET or DNP3, which do the same job for the same reason. In the supervisory band, systems that need names, types, writes and security talk OPC UA to each other. In the edge and enterprise band, data leaves through MQTT with Sparkplug B, so every subscriber beyond the plant reads the same self-describing metrics.
The direction on the map is the rule that holds for all four. Data flows up and out through the DMZ. Nothing on the business side publishes to the plant, writes to an OPC UA server in the control zone or polls a Modbus device, and the firewall rule per conduit names the devices and ports that may talk. The OT security guide covers the zones and conduits that enforce it.
Band 1Field and control
- Instruments and drives
- PLCs and RTUs
- Serial gateways
Speaks
Modbus RTU and TCP, with EtherNet/IP, PROFINET and DNP3 where the controller vendor chose them
Band 2Supervisory
- SCADA and HMI
- Historian collector
- OPC UA servers
Speaks
OPC UA between systems that need names, types and security
Band 3Edge and enterprise
- Edge gateway
- MQTT broker in the DMZ
- Central historian, analytics
Speaks
MQTT with Sparkplug B, so every subscriber reads the same self-describing metrics
→ Registers become named, typed tags
→ Tags become self-describing metrics, one way out
Choosing by what the link has to do
The question is never which protocol is best. It is what this link has to carry, how far, over what network, and to whom. The table gives the usual answer for the common links, and the note beside each is the part that gets missed.
| The link | Usual choice | And |
|---|---|---|
| Read a drive, a meter or a small PLC | Modbus, because the device speaks nothing else | Keep the register map in version control beside the configuration |
| Integrate two systems that both need to browse and write | OPC UA | Turn security on, own the certificates, and limit writes by user |
| Collect from many sites into one place over an unreliable network | MQTT with Sparkplug B | Report by exception, let the birth message carry the names and types |
| Feed a historian from a controller | OPC UA on site, Sparkplug B across sites | The historian collector stamps quality either way |
| Move data from the plant to the business | MQTT through a broker in the DMZ | One direction, and nothing on the business side may publish to the plant |
Where it goes wrong
- A Modbus register map that lives only in one engineer's poller configuration, so a firmware update silently changes what a tag means.
- OPC UA security set to none because it was easier during commissioning and nobody went back.
- An MQTT broker on port 1883 with anonymous access, reachable from the business network.
- A business-side application given write access to a plant OPC UA server for convenience.
- Topic and payload conventions invented per project, so the third project cannot read the first two.
- Sparkplug without a primary host, so the buffering it was chosen for never happens.
- A collector that stores values without quality, so a dropped link reads as a flat line.
Common questions
What is the difference between Modbus and OPC UA?
Modbus is a simple polling protocol from 1979 in which a client reads numbered registers from a device. The registers have no names, types or units, and there is no security in the protocol. OPC UA is a modern standard, IEC 62541, in which a server exposes a typed, browsable information model, with names, data types, units and structure, over channels that are signed and encrypted with certificates at both ends. Modbus is what field devices speak; OPC UA is what systems speak to each other.
What is Sparkplug B?
An open specification from the Eclipse Foundation, also published as ISO/IEC 20237, that defines how to use MQTT for plant data. It fixes the topic namespace, the payload format and the state management, so that every metric has a name, a type, a timestamp and quality, announced in a birth message when a node connects and then sent by alias only when it changes. Plain MQTT carries bytes; Sparkplug B makes those bytes mean the same thing to every subscriber.
Is MQTT secure for industrial use?
MQTT itself is a transport, and its security is the broker's: TLS on the connection, credentials or certificates for every client, and permissions per topic for who may publish and who may subscribe. Run that way, with the broker in the industrial DMZ and the plant side only publishing, it is a sound way to move data out of a plant. Run with anonymous access on port 1883, it is not.
When should Modbus be used?
When the device speaks nothing else, which is the case for most drives, meters, protection relays and small controllers. Modbus is not chosen so much as inherited. The work is in managing it: the register map kept in version control beside the poller's configuration, byte order and scaling recorded, and the serial bus not overloaded by a poll loop that asks for everything every second.
What is the difference between OPC UA and MQTT?
OPC UA is client and server, with a rich information model that a client can browse and subscribe to, best between systems on the same site that need names, types, writes and security. MQTT is publish and subscribe through a broker, with no model of its own, best for moving data from many sources to many consumers over networks that drop out. OPC UA also has a publish and subscribe profile, and Sparkplug B gives MQTT a model, so the two overlap more than they used to.
Which protocol should a data historian use?
Whatever the sources speak. A historian collector on site usually reads controllers through OPC UA, drives and meters through Modbus, and remote sites or edge gateways through MQTT with Sparkplug B. The collector stamps each value with quality, which matters more than the protocol, and the historian serves everything above it through its own interface and a replica in the DMZ.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- Modbus application protocol specification (Modbus Organization)
- OPC UA online reference (IEC 62541) (OPC Foundation)
- MQTT specification (ISO/IEC 20922) (OASIS)
- Sparkplug specification (Eclipse Foundation)
- SP 800-82 Rev. 3, Guide to operational technology security (NIST)
- ISA/IEC 62443 series of standards (ISA)
Related case studies and tools
- Time-Series Data Volume Calculator (tool)
- Telemetry and monitoring for remote assets (case study)
- Bridging OT and IT with custom software (case study)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.