An automotive assembly plant has 27 HMIs on the floor, each collecting cycle-time data from a local PLC. The corporate IIoT team wants this data in AWS for a machine-learning OEE model. The controls engineer wants the HMIs to keep updating every 100 ms regardless of what happens to the cloud connection. These two requirements — real-time local control and asynchronous cloud data delivery — need two different protocols working together. OPC UA handles the structured, secure connection to the automation layer; MQTT handles the lightweight, bandwidth-efficient push to the cloud. Understanding how to partition data between them is the difference between a data pipeline that coexists with machine control and one that interferes with it.
Why Two Protocols Instead of One
OPC UA was designed for industrial interoperability — it models data as objects with properties, methods, and events, supports certificate-based authentication and encryption at the transport level, and can traverse firewalls through a single configurable port (typically 4840). These characteristics make it the right protocol for northbound communication from PLCs, drives, and instruments to HMIs and SCADA systems.
MQTT was designed for constrained networks — it has a 2-byte minimum header, publishes data by topic rather than polling, and uses a central broker that decouples producers from consumers. These characteristics make it the right protocol for sending selected data to cloud platforms across WAN links. MQTT does not model data — it transports binary or JSON payloads — and leaves security to TLS. Using MQTT alone between the HMI and the PLC would sacrifice the data modeling OPC UA provides; using OPC UA alone to push data to the cloud would require exposing the OPC UA server to the WAN, which most OT security policies prohibit.
The Partitioned Architecture: OPC UA on the OT Side, MQTT on the IT Side
In a well-designed architecture, the HMI or an edge gateway functions as the protocol boundary. On the OT side, it is an OPC UA client, subscribing to tags from PLCs and drives with guaranteed session integrity and automatic reconnection. On the IT side, it is an MQTT client, publishing selected data to a cloud broker as structured JSON payloads. The Honeywell ControlEdge PLC integrates OPC UA server functionality for OT integration alongside MQTT for cloud data egress from a single device, collapsing what would otherwise require a separate edge gateway. For applications needing only OPC UA connectivity, the Piovan Easytherm EP mold temperature controller shows how even single-purpose equipment increasingly exposes OPC UA as a standard interface.
What Data Goes Where: A Practical Filtering Framework
The most common mistake in OT-to-cloud architectures is publishing everything. An injection molding cell with 400 tags generates roughly 80 kB per second at a 100 ms scan rate — enough to saturate a cellular router uplink. Three categories of data should go to the cloud; everything else stays on OPC UA:
- Aggregated KPIs — cycle time, parts count, OEE components. Compute locally and publish once per cycle, not once per scan.
- Alarm and event data — timestamped alarm transitions with acknowledgement status. Publish on change, not on poll.
- Condition monitoring variables — vibration RMS, motor current trend, temperature maxima. Publish at intervals measured in seconds, not milliseconds.
Everything else — raw I/O states, intermediate logic values, per-scan quality checks — stays on OPC UA for local HMI and SCADA consumption only. This filtering discipline keeps the MQTT data flow within bandwidth budget while preserving real-time control data where it is needed. Explore industrial communication and protocol converters for hardware options.
Security at the Protocol Boundary
The boundary between OPC UA and MQTT is also the boundary between OT and IT networks. Best practice places the HMI or edge device at this boundary with two logically separated network interfaces — one on the machine network running OPC UA with certificate-based authentication and no default gateway, the other on the plant network running MQTT with TLS 1.3, connecting outbound to a known broker. No inbound connections from IT to OT are permitted. This satisfies ISA/IEC 62443 zone-and-conduit requirements while enabling the cloud data pipeline the IIoT team requested. Browse our HMI and industrial PC catalog for devices with dual-network capability.
OPC UA connects the machine. MQTT connects the machine to the cloud. The architecture works when each protocol is assigned to the network domain it was designed for — and fails when one is forced to do the other's job.
