English is currently available.
Industrial IoT DISCUSSION
We want production data from about 15 PLCs in a cloud database. One integrator proposes OPC UA from every PLC, another proposes an MQTT broker with Sparkplug B, and both say their approach is the standard for Industrial IoT.
Are these two actually competitors? I would like to understand what each one is good at, and whether plain MQTT with JSON payloads would do for a first version.
They solve different parts of the problem. OPC UA is client/server at its core: a client connects to a server (the PLC or a gateway), browses a structured address space with typed data and metadata, and reads, writes or subscribes. That makes it strong inside the plant, close to the machines.
MQTT is publish/subscribe through a broker: devices open an outbound connection and publish messages to topics, and any number of consumers subscribe without knowing about the devices. That makes it strong for moving data across network boundaries to many consumers. A very common architecture uses both: OPC UA or native drivers from the PLCs to an edge gateway, then MQTT from the gateway to the broker and the cloud.
MQTT itself defines only transport: a topic string and a payload of bytes. It says nothing about what is in the payload, how topics are named or how a consumer learns that a device has gone offline. Sparkplug B fills that gap.
It fixes the topic structure as spBv1.0/group_id/message_type/edge_node_id/device_id, encodes payloads with Protocol Buffers, and defines birth and death messages (NBIRTH, DBIRTH, NDEATH, DDEATH) so that consumers know every metric's name and data type at start-up and know when the data has become stale. Ordinary data messages then carry only the metrics that changed.
Plain MQTT with JSON is a reasonable first version if you write down your own conventions and keep to them: a topic scheme such as site/area/line/machine/measurement, a fixed JSON layout with value, timestamp and quality, a Last Will message per gateway for online/offline status, and retained messages for the latest state. The cost is that every consumer must be told your conventions, and JSON is larger than a binary encoding, which matters on cellular links but rarely on a wired plant network.
Send the timestamp from the source. The time the cloud received a message is not the time the measurement was taken, especially after a buffered reconnect.
The network side often decides it. For a cloud application to read OPC UA directly, the server port of each PLC has to be reachable from outside, which means inbound firewall rules or a VPN into the control network. With MQTT the edge gateway makes an outbound TLS connection to the broker (port 8883 by convention), and nothing in the plant has to accept incoming connections. Security teams are far more willing to approve that.
OPC UA also has a publish/subscribe extension that can use MQTT as its transport, so the two are converging rather than competing, but check what your PLCs and your cloud service actually support before planning around it.
Whichever you choose, keep control traffic out of the first version. Publish data upward only, and do not subscribe the PLCs to command topics until there is a clear need and an authorisation concept.
With 15 PLCs, also decide early where the tag list lives. If each PLC programmer invents names independently, the cloud database ends up with 15 dialects. A single naming model applied at the gateway, before anything is published, is the part that pays back most later.
Back to Industrial IoT community
