Understanding and choosing between OPC-UA, MQTT and Modbus for your industrial IoT projects: use cases, performance, compatibility and decision criteria.
Why Protocol Choice Determines IIoT Project Success
Protocols define how data flows between sensors, gateways, and central systems. This choice appears technical, but has major implications: compatibility with existing equipment, data security, integration ease, scalability, long-term costs.
A bad choice creates technical debt from day one. You end up with sensors that don't talk to your CMMS, failing security, or an architecture frozen in place that will never scale. The cost of migrating to another protocol after 2 years of deployment is often catastrophic.
Conversely, choosing the right protocol from your pilot makes future extensions seamless and economical. It's an hour's investment now that saves thousands of euros in 3 years.
Overview: The Three Dominant Industrial Protocols
Three protocols dominate the industrial IIoT landscape and cover 90% of real-world cases.
Modbus is the old workhorse, born in the 1970s. All legacy industrial machines speak Modbus. It's simply a master (controller) polling a slave (sensor) at regular intervals. No built-in security, very rigid model, but ultra-reliable and omnipresent.
OPC-UA is the modern and ambitious standard, created around 2006 as an evolution of classic OPC. Industry 4.0 standard, backed by the largest industrial foundation (Plcopen). Rich architecture: client/server + pub/sub, built-in security, complex semantic information model.
MQTT is the lightweight and scalable protocol for IoT, created in 1999. Originally for constrained networks. Pure pub/sub model: publishers send data to a central broker, subscribers consume it. Very simple, very efficient, scales well.
Modbus: The Legacy Protocol Still Everywhere
Modbus RTU (serial) and Modbus TCP (Ethernet) are the two variants.
Advantages
- Extreme simplicity: master requests a value, slave responds. Easy to test with a multimeter.
- Universal support on old and modern equipment.
- No network dependency, RTU works on simple cable.
- Very low overhead, ideal for narrow bandwidth.
Operational Limits
- No native security. Data circulates in plaintext. For sensitive data, you must wrap Modbus in TLS (complex).
- Rigid master/slave model: master pulls all data. No real-time notifications if something changes.
- No semantics. A Modbus register 40001 = what? Temperature, pressure, position? The integrator must maintain documentation manually.
- Limited scalability. One RTU can support max 32 slaves. TCP supports more, but remains constrained.
When to Use It
Legacy equipment mandatory, small networks (< 50 points), ultra-tight budget, no external security constraints.
OPC-UA: The Industry 4.0 Standard
OPC-UA is the ambitious, rich protocol. Many see it as "too complex", but often from poor tools or bad introduction.
Architecture and Strengths
- Classic client/server but also async pub/sub. Real-time notifications without polling.
- Built-in security: certificate-based authentication, encryption, audit trail. Data is truly secured.
- Semantic information model: each variable has a type, context, documentation. OPC-UA doesn't expose just numbers, but business objects.
- Interoperability: two OPC-UA systems can "talk" without prior adaptation, because the model is standardized.
- Legacy support: OPC-UA can wrap Modbus or proprietary with a standardized interface.
When to Use It
Modern SCADA/MES/ERP systems, large deployments, high security requirements, cross-vendor integration, long-term evolution planned.
Real Limits
Learning curve, expensive licensed tools, larger network overhead than MQTT. A beginner easily gets lost in complexity.
MQTT: Lightweight and Scalable for Constrained Networks
MQTT is the simple, ultra-efficient pub/sub protocol.
Model and Strengths
- Pure pub/sub: publishers send messages to a broker, subscribers subscribe to topics. Complete decoupling between source and consumer.
- Hierarchical topics.
equipment/line1/motor1/vibrationis a valid MQTT message. - Configurable QoS: delivery guarantee 0 (best effort), 1 (at least once), or 2 (exactly once).
- Low bandwidth: minimal header, ideal for remote 4G/WiFi.
- Centralized broker easy to deploy and operate.
Security
No native security in the protocol, but combined with TLS (encryption) and certificate-based authentication, MQTT reaches the same security level as OPC-UA. Caution: some industrial MQTT deployments skip TLS for "performance". That's a mistake.
When to Use It
Geographically distributed deployments, unstable WiFi/4G networks, need for massive scalability (thousands of sensors), rapid deployment with minimal overhead.
Detailed Comparison Table
| Criterion | Modbus TCP | OPC-UA | MQTT |
|---|---|---|---|
| Native security | ✗ | ✓✓ | ✗ (TLS external) |
| Rich semantics | ✗ | ✓✓ | ✗ |
| Scalability | Low | Medium | High |
| Legacy support | ✓✓ | ✓ | ✓ |
| Implementation complexity | Very low | High | Low |
| Network overhead | Low | Medium | Very low |
| Real-time / notifications | ✗ (polling) | ✓ | ✓ |
| Cross-vendor interoperability | Low | Very high | Medium |
| Industrial maturity | Very high | High | Growing |
Interoperability and Convergence: OPC-UA over MQTT
The modern trend in Industry 4.0 is the combination: OPC-UA PubSub over MQTT. The concept: publish OPC-UA data (rich, semantic, secure) via MQTT (lightweight, scalable, distributed).
Concretely:
- Sensors and equipment produce OPC-UA data locally
- A gateway "translates" them to MQTT messages toward a cloud broker
- Business systems (ERP, CMMS, analytics) subscribe to MQTT topics and receive enriched OPC-UA data
Advantages: OPC-UA semantics + MQTT scalability + TLS security. It's the reference for new industrial deployments not constrained by legacy.
Selection Criteria Based on Your Context
No universal protocol. Here's a simplified decision tree.
Do you have legacy Modbus equipment that must stay operational? → Yes: a Modbus-to-OPC-UA or Modbus-to-MQTT gateway is necessary. Direct Modbus RTU in production remains viable.
Do you have externalized security constraints (clients, standards, audit)? → Yes: OPC-UA is the default choice. MQTT + TLS works if well configured.
Do you have unstable or geographically distributed network infrastructure? → Yes: MQTT is superior. OPC-UA + VPN/WAN can work but is more complex.
Do you have a network/IT team capable of operating a centralized MQTT broker? → No: OPC-UA or Modbus TCP (direct peer-to-peer) are operationally simpler.
Do you plan long-term evolution with cross-vendor integration? → Yes: OPC-UA or MQTT. Modbus is a technological dead-end.
Gateways and Protocol Conversion
Rarely does an SME completely eliminate legacy Modbus. Rather, it isolates Modbus in gateways that expose the same data via OPC-UA or MQTT.
Common pattern:
Old Modbus RTU equipment
↓
IoT Gateway (edge)
↓
Exposes via OPC-UA & MQTT
↓
Cloud platform / CMMSGateways do three things:
- Collect from Modbus (regular polling)
- Transform to semantic data (add type, unit, context)
- Publish via OPC-UA or MQTT
This saves hardware legacy investments while respecting modern architecture.
See IIoT for SMEs and Azymuth IoT platform for typical deployment architectures.
Conclusion: No Universal Protocol, But Clear Criteria
Simplified recap:
- Modbus : legacy mandatory, extreme simplicity, ultra-tight budget.
- OPC-UA : modern Industry 4.0, security required, long-term interoperability.
- MQTT : geographic distribution, unstable network, massive scalability.
Combine them if needed via gateways. The important thing is to decide before instrumenting, not after.
For precise diagnosis based on your infrastructure, contact Azymuth integration and deployment services.
FAQ
Does OPC-UA replace Modbus on existing equipment?
Not directly. You keep the Modbus equipment physically, but a gateway exposes it via OPC-UA to the rest of the system. Zero impact on the machine.
Is MQTT secure enough for industrial use?
With TLS (encryption) and certificate-based authentication, yes. Without these layers, no. Verify the MQTT broker configuration in your deployment.
Do you need an industrial network expert to choose a protocol?
For complex deployments (> 100 equipment, heavy legacy, critical security), an expert is recommended. For a simple pilot or clear extension, community resources and an IoT integrator suffice.
Related articles
IIoT for Industrial SMEs: A Practical Guide
How industrial SMEs deploy IIoT without massive budgets or data teams: priority use cases, architecture, and concrete steps.
Industry 4.0: Where to Start Concretely
Demystifying Industry 4.0 and defining a concrete roadmap: priority use cases, digital maturity, architecture, and steps for a pragmatic transformation.
CMMS and IoT: Integrating Sensor Data into Your CMMS
How to enrich your CMMS with real-time IoT data to trigger automatic work orders, reduce manual interventions, and improve reliability.
Real-Time Industrial Supervision: Why and How
Implementing real-time industrial supervision: field data collection, operator dashboards, alerts, and integration into production management processes.