Start with the layers, not a protocol contest
A common selection mistake is to ask whether Modbus, OPC UA, or MQTT is the best protocol. Modbus primarily reads and writes registers on controllers, meters, drives, and sensors. OPC UA provides a typed, browsable industrial information model with quality and timestamps. MQTT moves messages through a broker and works well across unreliable or loosely coupled networks. Their capabilities overlap only partly, so practical systems often combine them.
A gateway also does more than translate packets. It sets polling rates, recovers from disconnections, converts data types, attaches quality and time information, controls write access, and exposes enough diagnostics to locate a failure. A transparent converter may pass source-specific addresses, scaling rules, and invalid values into every downstream ERP, analytics, or AI application. That moves complexity rather than removing it.
The first decision should therefore be where data originates, who consumes it, whether remote control is required, and what must happen during a network outage.
Understand the cost behind each protocol
Modbus remains a sensible choice for legacy PLCs and straightforward field devices. It is widely supported and relatively simple, but registers carry little meaning by themselves. Engineers must maintain slave IDs, function codes, addresses, lengths, byte and word order, scaling, and invalid-value conventions. Modbus RTU also requires careful serial timing and polling-load management. Modbus TCP simplifies transport but does not add a semantic model, encryption, or authentication, so it should not be exposed directly to an untrusted network.
OPC UA fits plant integrations that need discovery, subscriptions, events, typed values, source timestamps, quality, and granular access control. A client can understand an address space instead of guessing what register 40101 means. The trade-off is operational discipline: certificates, trust lists, namespaces, information models, and compatibility testing all need ownership. Mapping every Modbus register to a generic OPC UA node is technically valid, but it does not create useful semantics unless names, units, types, and equipment relationships are designed as well.
MQTT is effective for sending edge data to cloud platforms, data pipelines, and multiple asynchronous consumers. Publishers do not need to know where subscribers run, and implementations can support persistent sessions, offline buffering, retained messages, and several QoS levels. MQTT does not define the topic hierarchy, payload schema, or device identity for you. QoS is also not the same as exactly-once business execution: a retried command can still produce duplicate effects. Retained values need timestamps, versions, and expiry rules so that a newly connected consumer does not treat stale state as current.
Choose by system boundary and operating conditions
In many plants, Modbus belongs on the southbound device side, OPC UA serves the internal OT integration layer, and MQTT carries selected data northbound. An edge gateway might poll Modbus equipment, normalize values into engineering units, expose a governed model to SCADA through OPC UA, and publish selected telemetry through MQTT. This is a useful pattern, not a requirement. Every additional protocol adds deployment, monitoring, versioning, and troubleshooting work.
- Source capability: If a device exposes only registers, Modbus may be unavoidable. If it already provides a mature OPC UA server, preserve that native model when possible.
- Consumer behavior: SCADA, MES, and engineering tools often benefit from OPC UA browsing and quality data. Cloud services and event-driven applications usually fit MQTT better.
- Control risk: Separate telemetry from commands. Cross-site commands need authorization, timeouts, idempotency, acknowledgements, and a safe equipment-side fallback.
- Network conditions: MQTT with durable queues is useful when links are intermittent or buffered replay is required. OPC UA subscriptions are often appropriate for live monitoring on a stable plant network.
- Data governance: When several systems will reuse the data, define stable names, units, types, identifiers, and schema versions instead of making every consumer interpret registers.
- Security boundary: Keep Modbus inside controlled segments. OPC UA certificates and MQTT TLS identities and topic ACLs need workable renewal and revocation procedures.
For a small telemetry requirement, a single Modbus-to-MQTT gateway may be enough. A plant with an established OPC UA model may standardize there and bridge only selected data to MQTT. Avoid enabling every available interface for hypothetical future use; unused write endpoints and default credentials still increase the attack surface.
Validate failure behavior before standardizing
Run an end-to-end pilot against a real device before committing to a gateway product or architecture. Do more than confirm that a value reaches the destination. Disconnect the network, reboot the field device, change the PLC operating mode, force timeouts, and observe how the gateway reports quality, buffers data, and restores subscriptions. Distinguish device timestamps, gateway receipt times, and platform ingestion times; otherwise, an apparent process delay may actually come from a network or queue.
- Maintain an explicit mapping: Record Modbus addresses, types, word order, units, scaling, valid ranges, and their corresponding OPC UA nodes or MQTT fields.
- Normalize at the edge: Convert raw values into consistent units and stable equipment identifiers while retaining raw data for diagnostics.
- Separate state from events: State may be replaced, while events require identifiers, timestamps, and traceable replay behavior. Do not hide both behind an ambiguous topic.
- Isolate reads and writes: Use separate identities, permissions, and audit trails for telemetry and commands. Require acknowledgements and duplicate-execution protection.
- Monitor data freshness: Track the last successful poll, queue depth, protocol error codes, certificate expiry, and the age of each important signal, not only gateway CPU and connectivity.
The final answer is rarely that one protocol wins. The maintainable design is the one with explicit boundaries between device constraints, industrial semantics, and cross-network delivery, supported by failure tests that reflect how the system will actually operate.