OPC UA, MQTT and Industrial IoT
The information model, client/server and publish/subscribe, Sparkplug, gateways and edge architectures.
Why a new layer above the controller
Controllers and drives speak protocols made for control: tags and registers, fast and compact. Supervisory systems, historians, analytics tools and cloud services speak the language of IT: names, types, security and standard transports. OPC UA and MQTT are the two protocols that bridge the gap. They are not replacements for the control-level networks; they carry data up from them, and sometimes commands back down, without each system needing a custom driver for every PLC brand.
| Problem | Old answer | Current answer |
|---|---|---|
| Reading PLC tags into SCADA | A proprietary driver for each brand, or OPC Classic over DCOM | OPC UA server in the PLC or a gateway |
| Merging data from different brands | Custom code | OPC UA with a common information model |
| Sending data to the cloud | VPN and a database connection | MQTT outbound through a firewall |
| Describing what a value means | A spreadsheet of register numbers | Self-describing nodes: name, type, unit, range |
| Security | Perimeter firewall only | Authentication, signing and encryption in the protocol |
OPC UA
OPC UA (Unified Architecture, IEC 62541) is a platform-independent standard from the OPC Foundation. An OPC UA server (in a PLC, a drive, a gateway or software) exposes data as a structured address space of named nodes; an OPC UA client (SCADA, historian, MES, a script) connects, browses the tree, and reads, writes, calls methods and subscribes to changes. It replaces the older OPC Classic, which depended on Microsoft DCOM and was hard to secure.
| Service | What it does | Notes |
|---|---|---|
| Browse | Explore the address space | The client can discover what is there without a tag list |
| Read / Write | Get or set the value of a node | Returns value, quality (status code) and timestamp |
| Subscribe / Monitored items | The server sends a change to the client | Set a sampling interval, a publishing interval and a deadband; far more efficient than polling |
| Call | Run a method on the server | For example Start() on a pump object |
| History | Read stored values | If the server keeps history |
| Events and alarms | Notification of conditions | Alarms and Conditions model |
| PubSub | Publish to many subscribers without a session | Over UDP, Ethernet (TSN) or MQTT, for field-level and cloud use |
| Item | Detail |
|---|---|
| Transport | opc.tcp binary on TCP port 4840 (the common choice); HTTPS and WebSockets are also defined |
| Endpoint | An address such as opc.tcp://192.168.10.10:4840; a server offers endpoints with different security settings |
| Discovery | A client can ask a server for its endpoints; a discovery server lists many servers |
| Sessions | A client creates a secure channel, then a session (authenticated), then works within it |
| Data types | Boolean, integers, floats, strings, arrays and structures with names; no register or word-order problem |
| Companion specifications | Standard information models for particular industries: PackML, Euromap 77 (injection molding), MTConnect and Machine Tools, robotics, PROFINET, IO-Link, Machine Vision |
The information model and nodes
| Node class | Meaning | Example |
|---|---|---|
| Object | A thing: a machine, a tank, a pump | Tank1 |
| Variable | A value with a data type, a quality and a timestamp | Level = 25.5 |
| Property | A fixed description of a node | EngineeringUnits = cm |
| Method | A function the client can call | Pump1.Start() |
| Object type, variable type | A template that objects follow, so that every tank has the same structure | TankType |
| View, reference | A subset of the tree; a typed link between nodes (HasComponent, Organizes) |
Each node has a NodeId: a namespace index and an identifier, for example ns=2;s=Plant.Line1.Tank1.Level (a string) or ns=3;i=1042 (a number). Names are unique within a server, so a client written once for the TankType works on every tank in every plant that follows it.
OPC UA security
| Security mode | Protects | Use |
|---|---|---|
| None | Nothing | Only for testing on an isolated bench |
| Sign | Integrity: messages cannot be altered undetected | Where encryption is not allowed |
| Sign and Encrypt | Integrity and confidentiality | The normal choice in production |
- Certificates. Each client and server has an X.509 certificate; each must trust the other’s. A failed connection with “BadSecurityChecksFailed” is usually an untrusted certificate: trust it in the server’s certificate store, deliberately.
- User authentication. Anonymous, user name and password, or a certificate. Never leave Anonymous access enabled on a server that can write.
- Security policies name the algorithms (for example Basic256Sha256); use the newest the devices support and disable the deprecated ones.
- Certificate lifetime. Certificates expire, often silently after a year or two: record the dates, or a historian stops one day.
- Firewall. Open TCP 4840 only between the client and server addresses concerned.
MQTT
MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol (OASIS standard, ISO/IEC 20922) designed for small devices and unreliable links. Instead of devices talking to each other, they talk to a broker: a publisher sends a message to a topic, and the broker forwards it to every subscriber of that topic. The publisher and subscriber never need to know about each other, are never connected directly, and can come and go.
| Concept | Meaning | Practical note |
|---|---|---|
| Broker | The server that receives and routes messages | Mosquitto, EMQX, HiveMQ, cloud services; one broker can serve thousands of clients |
| Topic | A slash-separated name such as plant1/line2/tank1/level | Design the hierarchy before you start; renaming later is painful |
| Wildcards | + matches one level; # matches all levels below | plant1/+/tank1/# matches every line’s tank 1 |
| QoS 0, 1, 2 | At most once; at least once; exactly once | QoS 1 is the usual compromise; QoS 2 adds handshakes |
| Retained message | The broker keeps the last value of a topic and gives it to new subscribers at once | Useful for status and for slowly changing values |
| Last will and testament | A message the broker publishes if a client disappears | Tells subscribers that a gateway is offline |
| Keep-alive | How often a client must show it is alive | 30 to 60 s is typical |
| Persistent session | The broker queues messages for a client that is offline | Allows reliable delivery over intermittent links |
| TLS and authentication | Encryption (port 8883), user name and password or client certificates | Always on in production; the broker also controls who may publish or subscribe to each topic (ACLs) |
Worked example: how big is an MQTT message?
- Publishing the value 25.5 to the topic
plant1/line2/tank1/level(24 characters) with QoS 0: the MQTT packet is a fixed header (1 byte), a remaining-length field (1), the topic length (2), the topic (24) and the payload (4) = 32 bytes. - On the wire add IP and TCP headers (40) and Ethernet (18): about 90 bytes, plus the TCP acknowledgments.
- The same value as JSON,
{"tank1":{"level":25.5,"unit":"cm","ts":"2026-10-30T12:00:00Z"}}is 64 bytes of payload, a good deal bigger, but self-describing. Binary payloads (Sparkplug B uses Protocol Buffers) are smaller. - Rule: batch many values into one message when you can, and keep topic names short and meaningful.
Sparkplug B
Plain MQTT says nothing about topic names or payloads, so every project invents its own. Sparkplug B (an Eclipse Foundation specification) defines a standard topic namespace, a compact binary payload and a state model for industrial data, so that a gateway from one maker and an application from another understand each other.
| Message | Topic pattern | Purpose |
|---|---|---|
| NBIRTH | spBv1.0/group/NBIRTH/edge_node | An edge node announces itself and all of its metrics |
| DBIRTH | spBv1.0/group/DBIRTH/edge_node/device | A device behind the edge node announces its metrics |
| NDATA, DDATA | spBv1.0/group/NDATA/edge_node | Metrics that changed (report by exception) |
| NCMD, DCMD | spBv1.0/group/NCMD/edge_node | Commands from the application to the node or device |
| NDEATH, DDEATH | spBv1.0/group/NDEATH/edge_node | Last will: the node or device is gone |
| STATE | spBv1.0/STATE/host_id | The state of the primary application |
OPC UA and MQTT compared
| OPC UA | MQTT | |
|---|---|---|
| Standard | IEC 62541, from the OPC Foundation | OASIS and ISO/IEC 20922 |
| Model | Client and server, plus PubSub; a structured information model | Publish and subscribe through a broker; topics and payloads of your choice |
| Data description | Built in: names, types, units, ranges | None unless you add it (Sparkplug B does) |
| Default ports | TCP 4840 | TCP 1883, 8883 with TLS |
| Security | Built in: certificates, signing, encryption | TLS and broker authentication; configure it deliberately |
| Strength | Rich, vendor-neutral, browsable data between PLCs, SCADA and MES | Lightweight and efficient; ideal for many small values to the cloud over slow or unreliable links |
| Weakness | Heavier to implement; sessions and certificates to manage | Needs a broker; no model; payloads must be agreed |
| Typical use | Reading tags from PLCs into SCADA, historians and analytics | Edge gateways sending data to cloud platforms and dashboards |
The two are complementary: a common design reads PLC data with OPC UA at the edge, then publishes selected values by MQTT to a broker.
Edge architectures and gateways
| Pattern | How it works | Good for |
|---|---|---|
| SCADA reads the PLC directly | OPC UA client in the SCADA connects to the PLC server | A single plant with a local SCADA |
| Edge gateway | A small PC or industrial gateway collects from PLCs (OPC UA, Modbus, EtherNet/IP, S7), filters and normalizes, and publishes upward | Mixed brands; cloud analytics; remote sites |
| Historian in the DMZ | The plant historian is mirrored to a server in the DMZ, so that IT users never touch the control network | Reporting without exposing controllers |
| PLC with built-in MQTT or OPC UA | The controller publishes directly (many newer PLCs do) | Simple projects; take care over CPU load and security |
| Cloud-to-edge commands | Commands come back over MQTT to the gateway, which writes to the PLC under rules | Remote set-point changes; allow only a short list of tags |
- Outbound only. The gateway opens the connection to the cloud, so the machine network needs no inbound port.
- Store and forward. When the link is down, the gateway buffers data and sends it later with the original timestamps.
- Time. Use synchronized time (NTP) on PLCs and gateways, and publish UTC timestamps.
- Naming. Agree one naming scheme (site, area, line, machine, tag) before connecting anything.
- Do not publish everything. Select the tags that the application needs.
- Read-only first. Start by reading; add writes only with a clear need and strong limits.
Data volumes and report by exception
Worked example: polling against report by exception
- Polling every second. 200 tags, each sent as about 60 bytes of JSON once a second: 12 000 bytes per second, or 96 kbit/s, which is 1036.8 MB per day.
- Report by exception. If only about 5 percent of the tags change by more than the deadband in any second, that is 10 values a second: 600 bytes per second, 4.8 kbit/s, or 51.8 MB per day, 20 times less.
- On a cellular link billed by the megabyte, this is the difference between a negligible and a serious cost.
- The price: a subscriber that was offline must get the current state when it reconnects (a retained message, an OPC UA initial read, a Sparkplug BIRTH), or it will not know values that have not changed.
Worked example: an OPC UA subscription
- A client subscribes to 5 nodes with a sampling interval of 250 ms and a publishing interval of 1 s. The server checks each node 4 times a second (20 samples per second in all) but sends only changes: one notification message per second at most, carrying the queued changes.
- A deadband of 0.5 percent on an analog node means a noisy value that wiggles by 0.1 percent is never sent; the traffic falls to almost zero until the process moves.
- The sampling interval sets how quickly the server notices; the publishing interval sets how often the client hears. Choose them from the process, not from habit.
Other IoT and integration protocols
| Protocol | What it is | Where you meet it |
|---|---|---|
| REST / HTTPS with JSON | Request and reply over the web | PLC and gateway web APIs, cloud services, MES |
| AMQP | A message-queue protocol with guaranteed delivery | Enterprise integration, cloud platforms |
| MTConnect | A read-only standard for machine tools over HTTP/XML | CNC machines and shop-floor monitoring |
| Umati | OPC UA for machine tools (a companion specification) | Machine tool builders |
| Database connections (SQL, ODBC) | PLC, SCADA or gateway writes to a database directly | Production logs and recipes |
| Kafka | A high-volume streaming platform | Large analytics projects |
| BACnet/IP | Building automation over IP | HVAC integration |
| CoAP, LwM2M, LoRaWAN, NB-IoT | Constrained-device and low-power wide-area protocols | Remote sensors, utilities |
Planning an integration
- 1. State the question. What decision will the data support, and how fresh must it be? “Everything every second” is a cost, not a requirement.
- 2. List the sources and their native protocols. PLC, drives, meters, sensors: what does each offer (OPC UA, Modbus, EtherNet/IP)?
- 3. Choose the path. OPC UA for browsing and control-level integration; MQTT for upward data; a gateway where native support is missing.
- 4. Design the namespace. Site, area, machine, signal, with units and types.
- 5. Design the security before you connect: segmentation, certificates, accounts, firewall rules, outbound only.
- 6. Prove it with a small slice, one machine and a handful of tags, before you scale.
- 7. Monitor and maintain. Watch the gateway’s health, certificate dates and data gaps.
Typical faults
| Symptom | Likely cause | Check |
|---|---|---|
| OPC UA client cannot connect | Wrong endpoint URL or port, firewall, untrusted certificate, security mode mismatch | Ping, port 4840, the server’s trusted-certificates folder, the endpoint list |
| Connection works, values show Bad quality | The node is not readable by this user, the PLC is in stop, or the source is offline | The status code; the PLC mode; the user’s permissions |
| Subscription stops after some time | Session timeout, a lost connection not noticed, a certificate that expired | Reconnect logic; certificate dates |
| Values correct but timestamps wrong | Time not synchronized, time zone confusion | NTP on every device; use UTC |
| MQTT client connects and disconnects repeatedly | Two clients with the same client ID, wrong credentials, a keep-alive shorter than the network delay | Unique client IDs; broker logs |
| Subscriber receives nothing | Topic spelled differently (case matters), wrong wildcard, ACL denies it | Subscribe to # on a test broker and compare topics |
| Cloud data has gaps | Link down with no buffering at the gateway, QoS 0 | Enable store and forward; QoS 1 |
| PLC slow after enabling a server | Too many subscriptions or a small sampling interval loading the CPU | Increase the intervals; reduce the nodes |
Related
- Industrial Communication: the overview of this guide.
- Industrial Ethernet: EtherNet/IP, PROFINET and EtherCAT and IP Addressing, Subnets and VLANs: the network under these protocols.
- Industrial Network Security: certificates, firewalls and outbound-only designs.
- Connecting PLCs, Drives and HMIs: enabling OPC UA on Siemens and other controllers.
- System Integration: putting controllers, networks and software together.
- Data Logging: what to do with the data once you have it.
FAQ
Should I use OPC UA or MQTT?
Use OPC UA to read structured data from controllers and to connect SCADA and MES; use MQTT to send selected values upward to a broker and the cloud. Many systems use both: OPC UA at the edge and MQTT beyond it.
Does OPC UA replace Modbus and EtherNet/IP?
Not at the field and control level. Those networks carry real-time I/O. OPC UA sits above them to deliver data to higher systems (and, with PubSub and TSN, may reach the field in time).
Is MQTT secure?
Only if you make it so. MQTT itself has no encryption; use TLS (port 8883), authentication and topic-level access control. An open broker on the internet will be found.
Why does my OPC UA connection fail with a security error?
Usually the server does not trust the client’s certificate yet. Find the certificate in the server’s rejected folder and move it to trusted, after checking it is yours.
Do I need a cloud to use these?
No. OPC UA and MQTT work on a local network too; a local broker or OPC UA server is a common way to feed a plant SCADA and a historian.
What is the difference between polling and subscription?
Polling asks repeatedly whether a value changed. A subscription tells the server what to watch and sends only changes, which saves bandwidth and gives faster updates.
References
- IEC 62541, OPC Unified Architecture, and the OPC Foundation specifications and companion specifications (opcfoundation.org).
- OASIS, MQTT Version 5.0 (also ISO/IEC 20922 for version 3.1.1) (mqtt.org).
- Eclipse Foundation, Sparkplug Specification (sparkplug.eclipse.org).
- IEC 62443 series, Industrial communication networks: network and system security.
- Mahnke, W., Leitner, S.-H., Damm, M., OPC Unified Architecture, Springer.
Last reviewed: October 2026. Speeds, lengths, node counts and menu names are typical: confirm against the specification and the manufacturer’s documentation for the devices you use.