MQTT in Manufacturing: Why the IoT Protocol Took Over the Shop Floor

Key takeaways

• MQTT is a lightweight pub/sub messaging protocol. Originally built for low-bandwidth telemetry, now everywhere in manufacturing.
• It decouples publishers (PLCs, sensors, machines) from subscribers (OEE platforms, cloud, analytics) via a broker.
• The standard pattern in modern shops is Sparkplug B — an MQTT specification that adds data modeling, birth/death messages, and state tracking.
• MQTT scales to thousands of devices with minimal bandwidth, which is why edge IIoT solutions converged on it.
• It complements OPC UA, it does not replace it. Many stacks use both.

Short answer: MQTT is a pub/sub messaging protocol designed for low-bandwidth IoT but adopted at scale in manufacturing because it decouples data producers (machines) from data consumers (OEE platforms, cloud, analytics). Modern industrial deployments use the Sparkplug B specification on top of MQTT to add the data modeling and state tracking that raw MQTT lacks. MQTT and OPC UA solve overlapping problems; many stacks use both. See also OEE for Batch Manufacturing.

What MQTT is

MQTT (Message Queuing Telemetry Transport) is a publish/subscribe messaging protocol invented in 1999 at IBM for low-bandwidth oil-and-gas telemetry. The architecture is simple:

• Publishers push messages to topics (named channels) on a broker.
• Subscribers ask the broker for messages on topics they care about.
• Broker routes messages from publishers to subscribers without either knowing the other.

The decoupling is the value. A PLC publishes its run state to a topic; whoever subscribes gets the data. The PLC does not know or care who the consumer is.

Why MQTT took over manufacturing telemetry

Three reasons:

• Bandwidth efficiency. Small message overhead, persistent connections, minimal handshake. Works on cellular and constrained networks.
• Scalability. A single broker can handle thousands of devices publishing concurrently.
• Decoupling. Add or remove subscribers without touching the data sources. Try doing that with point-to-point integrations.

For an OEE platform consuming data from 50+ machines across a plant, MQTT is a natural fit. One broker, many publishers, many subscribers.

Why raw MQTT is not enough

Raw MQTT has no opinion about message content. A PLC publishing "423" on topic "line5/cycle" is fine until two different PLCs use different topic conventions, units, or message formats. Integration becomes a mess.

The fix is Sparkplug B, an open specification on top of MQTT that adds:

• A standard topic namespace (group/edge node/device/metric).
• Birth and death messages so subscribers know when a device joins or leaves.
• State tracking and value persistence (the broker maintains last-known value).
• Strong typing of metrics (int, float, boolean, datetime).

Most modern industrial MQTT deployments use Sparkplug B. Raw MQTT works for greenfield with strict topic discipline but rarely scales.

MQTT vs OPC UA

They overlap but solve different problems:

• MQTT is pub/sub, broker-based, lightweight, ideal for many-to-many telemetry at scale.
• OPC UA is client-server (with optional pub/sub), point-to-point, structured, ideal for reliable data exchange with strong typing and security.

Many modern stacks use both: OPC UA for structured data exchange at the line (PLC to gateway), MQTT/Sparkplug B for high-scale telemetry from gateway to cloud or central OEE platform.

What "unified namespace" means and why MQTT enables it

Unified namespace (UNS) is an architectural pattern where every system publishes to a single shared MQTT broker. The broker becomes the single source of truth for all real-time plant data. ERP, MES, OEE platform, historian, analytics — they all subscribe to the topics they need without point-to-point integration.

UNS replaces the rigid PLC → SCADA → MES → ERP hierarchy with a flat pub/sub bus. It is a strong fit for greenfield digital transformation and lift-and-shift modernization of plants with legacy SCADA.

What this means for OEE platform selection

• Does the OEE platform support MQTT natively?
• Does it support Sparkplug B (not just raw MQTT)?
• Can it run on-premises against an existing broker?
• Can it function as a publisher (writing computed OEE values back) in addition to subscriber?

For SMB manufacturers without an existing broker, OPC UA-only is often simpler. For larger or multi-site operations, MQTT + Sparkplug B usually wins on long-term scalability.

Fabrico's OEE module supports both OPC UA and MQTT/Sparkplug B as data sources, and can publish computed OEE metrics back to MQTT for downstream consumers.

See how Fabrico captures this automatically — explore OEE for manufacturing or book a demo.

Related reading

• OEE for Batch Manufacturing
• Pareto Chart in Manufacturing
• KPI vs OKR in Manufacturing
• Manufacturing Data Lake vs Data Warehouse

Frequently asked questions

Should I use MQTT or OPC UA for OEE?

For most SMB plants, OPC UA is enough and simpler. For multi-site or unified-namespace strategies, MQTT/Sparkplug B is the better long-term choice.

What is Sparkplug B?

An open specification on top of MQTT that adds standard topic naming, birth/death messages, state tracking, and typed metrics. The de facto standard for industrial MQTT.

Do I need a separate broker?

Yes. MQTT is built around a broker. Common choices: HiveMQ, EMQX, Mosquitto (open source), or cloud brokers (AWS IoT, Azure IoT Hub).

Is MQTT secure?

Yes, with TLS encryption and authentication. Anonymous, unencrypted MQTT in production is not safe.

How does MQTT compare to REST/HTTP for telemetry?

MQTT is much more efficient for continuous telemetry. HTTP is fine for occasional API calls. For machine data flowing every few seconds across thousands of devices, MQTT wins decisively.