MQTT, OPC-UA, Modbus: A Practical Guide to Factory IoT Protocols

Why factories need IoT

Before we compare protocols, let us be clear about why factory IoT matters. This is not about technology for its own sake. It is about four operational outcomes that directly impact the bottom line:

• Real-time visibility: Knowing what every machine is doing right now — not what the last shift report said it was doing three hours ago.
• Predictive maintenance: Detecting bearing wear, motor degradation, or coolant pressure drops before they cause unplanned downtime. A single hour of unplanned downtime on a high-throughput line can cost $10,000-50,000.
• Quality control: Monitoring process parameters (temperature, pressure, humidity, vibration) in real time and catching deviations before they produce defective output.
• Energy monitoring: Tracking energy consumption per machine, per shift, per product — and identifying waste patterns that manual monitoring cannot detect.

To achieve these outcomes, you need data flowing from machines and sensors into your business systems. That data travels over protocols — and the choice of protocol determines what you can connect, how fast data arrives, and how secure the connection is.

The three dominant protocols

Factory IoT has largely settled on three protocols, each designed for different use cases. Here is how they compare:

MQTT: the lightweight workhorse

MQTT (Message Queuing Telemetry Transport) was designed in 1999 for oil pipeline telemetry over satellite links — environments where bandwidth is scarce and connections are unreliable. That origin makes it perfect for factory IoT.

MQTT uses a publish-subscribe model. A temperature sensor publishes readings to a topic (e.g., factory/line-3/furnace/temperature). Any system subscribed to that topic receives the reading instantly. The MQTT broker handles routing, buffering, and delivery guarantees.

Key strengths:

• Tiny footprint: The protocol overhead is minimal — a few bytes per message. This means it runs on microcontrollers, ESP32 boards, and low-power sensors that cannot support heavier protocols.
• Reliable over bad networks: MQTT supports three quality-of-service levels — fire-and-forget (QoS 0), at-least-once (QoS 1), and exactly-once (QoS 2). For factory environments with Wi-Fi dead zones and network congestion, QoS 1 ensures no data is lost.
• Scalable: A single MQTT broker can handle hundreds of thousands of concurrent connections. You can start with 10 sensors and scale to 10,000 without changing architecture.
• Easy to implement: Client libraries exist for every language. A Python script that publishes sensor data via MQTT is about 15 lines of code.

Best for: Environmental sensors (temperature, humidity, vibration), energy meters, barcode scanners, RFID readers, and any scenario where many devices send small packets of data frequently.

OPC-UA: the industrial standard

OPC-UA (Open Platform Communications Unified Architecture) is the protocol that industrial automation vendors have standardised on. If MQTT is the language of sensors, OPC-UA is the language of machines.

Unlike MQTT's simple topic-based model, OPC-UA provides a rich information model. A CNC machine exposed via OPC-UA does not just publish "spindle speed = 12,000 RPM." It publishes a structured object model that includes the machine's capabilities, its current state, its alarm conditions, its historical data, and the relationships between its components.

Key strengths:

• Rich data modelling: OPC-UA can represent complex equipment hierarchies — a production line containing machines containing axes containing sensors — with full semantic meaning.
• Built-in security: Unlike MQTT (which relies on TLS for transport security), OPC-UA has security built into the protocol itself — application-level authentication, message signing, and encryption. This matters in environments where regulatory compliance requires provable data integrity.
• Vendor support: Major PLC manufacturers (Siemens, Rockwell, ABB, Beckhoff) provide native OPC-UA servers in their controllers. You can read PLC data without custom code.
• Historical data access: OPC-UA supports historical data queries natively. You can ask the server for "all temperature readings from machine X between 2 PM and 3 PM" without building a separate time-series database.

Best for: PLC data, CNC machines, robotic cells, and any scenario where you need structured access to machine data from industrial automation equipment.

Modbus: the legacy connector

Modbus was created in 1979 by Modicon (now Schneider Electric) for PLC communication. It is the oldest protocol on this list — and the most widely deployed in existing factories. If your plant has equipment older than 10 years, there is a good chance it speaks Modbus.

Modbus is dead simple. It uses a master-slave architecture where a master device (your gateway or computer) polls slave devices (sensors, PLCs, meters) for their current register values. A Modbus register is just a 16-bit number. Reading "holding register 40001" from a power meter might return the current kilowatt reading.

Key strengths:

• Universal legacy support: Almost every industrial device manufactured in the last 40 years supports Modbus in some form — Modbus RTU (serial) or Modbus TCP (Ethernet).
• Zero complexity: No authentication, no encryption, no session management. You send a read request, you get a response. Implementation is trivial.
• Deterministic: Because it is a polling protocol (not event-driven), you control exactly when data is read and how often. This predictability matters in control systems.

Limitations: Modbus has no native security — no authentication, no encryption. Data travels in plaintext. For any deployment that touches a network beyond the local plant floor, you must wrap Modbus in a TLS tunnel or VPN. Modbus also has no built-in data model — register 40001 is just a number. The meaning of that number (temperature? pressure? RPM?) must be configured manually.

Best for: Connecting legacy equipment (old PLCs, energy meters, temperature controllers) that do not support newer protocols. Also useful for simple sensor arrays where the data model is straightforward.

When to use which: a decision guide

Choosing the right protocol depends on three factors: what you are connecting, how fast you need data, and what security requirements you have.

• New sensors, environmental monitoring, barcode/RFID: Use MQTT. Low overhead, easy to implement, scales well.
• Modern PLCs and CNC machines with OPC-UA servers: Use OPC-UA. You get structured data, security, and vendor support out of the box.
• Legacy equipment (10+ years old) with Modbus ports: Use Modbus TCP/RTU through a gateway that converts to MQTT for upstream communication.
• Mixed environment (most real factories): Use all three. A factory IoT gateway that speaks Modbus to legacy equipment, OPC-UA to modern machines, and MQTT as the unified transport layer to your business platform.

The real world is messy. Most factories will use all three protocols simultaneously. The question is not which one to choose — it is how to unify them into a single data stream that your business systems can consume.

The middleware problem

In most enterprise architectures, IoT data flows through a separate platform — AWS IoT Core, Azure IoT Hub, ThingWorx, Ignition, or a custom Node-RED deployment. This IoT platform collects, normalises, and stores sensor data. Your ERP/MES then integrates with the IoT platform through APIs.

This architecture works, but it creates the same problems as the MES-ERP disconnect: two databases, integration middleware, sync latency, and an additional platform to license, maintain, and secure.

The alternative is native protocol support — a business platform that can subscribe to MQTT topics, connect to OPC-UA servers, and poll Modbus registers directly, without a separate IoT platform in between. When the temperature sensor publishes a reading, the business platform receives it, evaluates it against process limits, and triggers a quality hold or maintenance alert within the same system where the work order, inventory, and cost records live.

This is not a hypothetical. Platforms that were built with hardware integration in their DNA — not bolted on after the fact — can consume IoT data natively and turn it into business actions without middleware.

Practical setup patterns

Here are three common scenarios and how to implement them:

Barcode scanner on a shop floor

A handheld barcode scanner connected via USB to a Raspberry Pi. The Pi runs a lightweight MQTT client that publishes each scan to a topic like factory/line-2/scanner/scan. The business platform subscribes to this topic and uses the scanned barcode to log production quantities, confirm material issues, or update work order status.

Hardware cost: $50 (Pi) + $100 (industrial barcode scanner). Setup time: 2-3 hours. Protocol: MQTT over Wi-Fi.

PLC temperature sensor on a furnace

A Siemens S7-1500 PLC monitoring furnace temperature via a thermocouple input. The PLC has a built-in OPC-UA server. The business platform connects as an OPC-UA client and subscribes to the temperature node. When the temperature exceeds the process limit, the platform creates a quality hold on the current batch and notifies the quality team.

Hardware cost: Existing PLC (no additional hardware). Setup time: 4-6 hours (OPC-UA server configuration + platform connection). Protocol: OPC-UA over Ethernet.

RFID reader at a warehouse dock

A fixed RFID reader at the goods receipt dock. When a pallet with RFID-tagged items passes through, the reader publishes the tag IDs via MQTT. The business platform matches tag IDs to expected delivery items, auto-confirms the goods receipt note, and updates inventory in real time.

Hardware cost: $300-800 (fixed RFID reader) + $0.10 per tag. Setup time: 4-6 hours. Protocol: MQTT over Ethernet.

Security considerations

Factory IoT security is a broad topic, but three principles cover most of the risk surface:

• Network segmentation: IoT devices should sit on a separate VLAN from your corporate network and your business applications. A compromised temperature sensor should not be a pathway to your ERP database.
• Authentication: Every device that connects to your MQTT broker or OPC-UA server should authenticate with a unique credential — ideally a client certificate, not a shared password. If a device is decommissioned or compromised, you revoke its certificate without affecting other devices.
• Encrypted transport: All data in transit should be encrypted. MQTT over TLS (port 8883) and OPC-UA with security mode "SignAndEncrypt" are non-negotiable for any deployment that leaves the local network. For Modbus, wrap the connection in a TLS tunnel or use a gateway that translates Modbus to MQTT-over-TLS.

Getting started: a three-step plan

If your factory has zero IoT connectivity today, here is a practical plan to get started without a massive capital project:

1. Step 1 — Pick one pain point (Week 1-2): Do not try to connect everything at once. Choose one specific problem: unplanned downtime on a critical machine, manual production counting on a bottleneck line, or energy monitoring on the highest-consumption equipment. One machine, one sensor type, one clear ROI case.
2. Step 2 — Deploy a pilot (Week 3-6): Install a sensor or connect to an existing PLC. Set up an MQTT broker (Mosquitto is free and runs on a Raspberry Pi). Connect it to your business platform. Build one dashboard or one alert rule. Prove the value with real data.
3. Step 3 — Scale what works (Month 2-6): Once the pilot proves ROI, replicate the pattern across similar machines. This is where protocol choice matters — if you are connecting 50 temperature sensors, MQTT is the right choice. If you are connecting 10 CNC machines, OPC-UA is more appropriate. The gateway and broker architecture from the pilot scales linearly.

The barrier to factory IoT is not technology — the protocols are mature, the hardware is cheap, and the software tools are well-documented. The barrier is starting. Pick one machine, connect one sensor, prove one value case. Everything else follows from there.