How to Preserve OPC UA Quality and Timestamps When Publishing to MQTT
The Robustel EG3120e Edge Computing Gateway can host supported applications close to industrial data sources, making it a practical place to map OPC UA data into MQTT. The mapping must carry value, quality, source time and sequence together; publishing only the latest number can turn stale or uncertain data into an apparently healthy cloud value.
Define One Canonical MQTT Record Before Writing the Connector
For every OPC UA item, map node identity, engineering unit, value, StatusCode, SourceTimestamp, ServerTimestamp where useful and the gateway ingestion time. Keep event time separate from transport time. A cloud consumer should be able to tell whether a value was measured late, published late or replayed after an outage.
Translate quality explicitly. Good, uncertain and bad states should not disappear into a numeric payload or be inferred from a missing topic. If the downstream schema uses its own quality vocabulary, document the conversion and keep the original OPC UA code available for diagnosis.
Test the cases that tidy demonstrations avoid: a disconnected sensor, a frozen source timestamp, a server restart, an unknown unit, out-of-order samples and a WAN outage followed by replay. Verify that the consumer sees the same operational meaning, not merely the same number.
Draw the Publisher, Broker and Subscriber Roles
In PubSub over MQTT, an OPC UA publisher creates dataset messages, an MQTT broker transports them and subscribers interpret them through the agreed information model and security configuration. The broker does not convert arbitrary MQTT JSON into OPC UA semantics.
| Role | Key design input | Ownership question |
|---|---|---|
| Data source | PLC/OPC UA variables and update rate | who owns namespace and quality? |
| Publisher | dataset and message mapping | where is PubSub encoded? |
| Broker | MQTT service, TLS and ACL | who operates availability and certificates? |
| Subscriber | metadata and consumption | how are schema changes handled? |
Decide Whether PubSub Is Actually Required
Use PubSub when multiple consumers need the OPC UA information model through a decoupled transport and the chosen platforms support the same profile. Use OPC UA client/server when direct browse/read/write relationships are clearer. Use standard MQTT or Sparkplug B when the target system expects those models.
Mixing the names creates difficult acceptance tests. “The value arrived over MQTT” does not prove that a compliant subscriber can interpret the expected OPC UA PubSub dataset.
Robustel’s machine-builder connectivity and remote-service Application Example illustrates why controller data, remote access and fleet operations need explicit ownership once industrial equipment leaves the builder. It does not verify OPC UA PubSub, but it gives the semantic and support boundaries in this architecture a real operational context.
How the Robustel EG3120e Edge Computing Gateway Fits a Verified PubSub Implementation
The Robustel EG3120e Edge Computing Gateway runs RobustOS Pro on a quad-core platform with 2 GB RAM and supports Docker plus Debian applications. It provides Ethernet, cellular/eSIM, Wi-Fi, configurable serial ports and digital I/O. Those resources make it a viable host for an independently validated OPC UA PubSub application.
On compatible Robustel EG3120e hardware, Robustel E2C Factory documents OPC UA Server data forwarding, MQTT cloud publishing and Sparkplug B as separate functions. It can reduce engineering work when one of those supported patterns meets the requirement. Current documentation reviewed for this article does not establish a native OPC UA PubSub-over-MQTT function, so do not rename an OPC UA Server plus MQTT publisher as PubSub.
If genuine PubSub is mandatory, select and test an application or container that explicitly supports the needed OPC UA profile, encoding, metadata and security. Benchmark it with E2C Factory and other services active if they will share the gateway.
| Requirement | Use documented E2C function when… | Use separately validated PubSub app when… |
|---|---|---|
| SCADA browses edge tags | OPC UA Server fits | — |
| Cloud consumes custom topics | MQTT publishing fits | — |
| Sparkplug platform needs lifecycle state | Sparkplug B fits | — |
| OPC UA subscribers require PubSub dataset messages over MQTT | not established by those functions | explicit PubSub interoperability is mandatory |
The Robustel secure remote access to industrial robots Application Example illustrates why application lifecycle and controlled support matter at industrial edge sites. It does not verify OPC UA PubSub.
Commission Interoperability With Captured Messages
Use the target publisher, broker and subscriber. Verify connection, dataset metadata, value and quality, sequence handling, restart, certificate rotation and schema change. Capture broker and application logs so a transport success cannot hide a decoding failure.
Remove the broker, restore it and check session/republication behaviour. Run the production update rate long enough to expose memory or queue growth. If two software stacks share the gateway, test their combined CPU, storage and network load.
The Robustel EG5000 Series Quick Pitch video provides family context even though EG3120e is the featured model. The selected PubSub SDK/application documentation is the protocol authority.
FAQs
Q1. What is OPC UA PubSub?
It is an OPC UA communication model in which publishers send dataset messages through an underlying transport to one or more subscribers without direct client/server sessions.
Q2. Can OPC UA PubSub use MQTT?
Yes, supported OPC UA PubSub implementations can use MQTT as transport. Publisher, broker and subscriber must agree on the required profile, encoding, security and metadata.
Q3. Is OPC UA over MQTT the same as Sparkplug B?
No. Both can use MQTT, but they define different data and lifecycle models. Select the one required by the consuming platform.
Q4. What is the difference between OPC UA Server and PubSub?
An OPC UA Server supports direct client/server services such as browsing and reads. PubSub distributes dataset messages through a transport to subscribers.
Q5. Can the Robustel EG3120e Edge Computing Gateway host an OPC UA PubSub gateway?
Its Debian/container platform can host supported applications, but the exact PubSub software must be independently verified. E2C Factory documents OPC UA Server, MQTT and Sparkplug B functions separately, not as proof of native PubSub over MQTT.
Conclusion
The Robustel EG3120e Edge Computing Gateway offers a suitable compact compute and connectivity platform where the project needs an industrial host for a specifically validated OPC UA-to-MQTT application. Its value comes from the open application environment and industrial interfaces, not from an unsupported assumption about protocol names.
If OPC UA Server, standard MQTT or Sparkplug B meets the actual consumer requirement, E2C Factory on EG3120e provides documented paths that may be simpler to commission and maintain. Genuine OPC UA PubSub over MQTT should be chosen only when subscriber interoperability requires it.
Procurement should finish with a captured-message interoperability test using the production publisher, broker and subscriber. That evidence prevents a transport-level demonstration from being accepted as semantic compatibility.
Explore More Articles About Robustel Edge Computing Gateways
About the Author
Robustel Editorial Team
The Robustel Editorial Team publishes practical articles on industrial connectivity, edge computing, LoRaWAN and device management, focusing on deployment considerations, technical limitations and long-term operation.