MQTT

Core concept

MQTT (Message Queuing Telemetry Transport) is a lightweight, TCP/IP-based messaging protocol that uses a publish–subscribe model. It is commonly used to connect devices, sensors, controllers, and applications, especially where bandwidth, power, or processing capacity is limited.

In industrial and manufacturing environments, MQTT is often used as a transport layer for OT data (e.g., machine states, sensor values, alarms) to be consumed by IT systems such as MES, historians, analytics platforms, or cloud services.

How MQTT works

MQTT is based on three key elements:

– **Broker**: A server that receives messages from publishers and routes them to subscribers based on topics.
– **Publisher**: A client that sends messages to the broker, tagging them with a topic (for example, `plant1/line3/machine7/state`).
– **Subscriber**: A client that registers interest in specific topics and receives messages that match those topics.

Characteristics commonly seen in industrial use:

– **Publish–subscribe pattern**: Decouples data producers and consumers in time, location, and implementation.
– **Topic hierarchy**: Messages are organized under topic strings, often reflecting plant/line/machine/parameter structure.
– **Quality of Service (QoS) levels**: Controls delivery guarantees (at most once, at least once, exactly once) for messages, important for alarms and state changes.
– **Lightweight wire format**: Messages have a small overhead, suitable for constrained devices and high-volume telemetry.

Use in manufacturing and regulated operations

In industrial and regulated environments, MQTT commonly refers to its role in:

– **Machine and device connectivity**: PLCs, sensors, gateways, and edge devices publish machine states, process values, and alarms to an MQTT broker.
– **MES, SCADA, and historian integration**: MES or SCADA applications subscribe to MQTT topics to receive real-time production, quality, or alarm data, or publish commands and setpoints.
– **Event and alert transport**: Alerting systems (for example, Andon boards, email/SMS gateways, operator dashboards) may subscribe to MQTT topics carrying alarm or status events from MES or shop-floor systems.
– **Edge-to-cloud data flows**: Edge gateways consolidate OT data and forward it using MQTT to cloud analytics or centralized monitoring systems.

When used in regulated environments, MQTT-based data flows are typically subject to the same change control, validation, access control, and audit requirements as other integration mechanisms.

Boundaries and exclusions

– **MQTT is a transport protocol, not a full application standard**: It defines how messages are moved, not the semantics of payloads. Payloads may be JSON, binary, or other formats; structure and meaning are defined separately (for example via OPC UA data models, custom schemas, or vendor-specific formats).
– **Not the same as message queues or enterprise buses**: Despite the name, MQTT is not a traditional enterprise message queue or ESB. It can be used within such architectures, but it does not itself provide workflow orchestration, transactional queuing, or complex routing rules beyond topics and wildcards.
– **Not specific to any one vendor or platform**: MQTT is an open protocol and is implemented by many brokers and clients. Using MQTT does not imply a particular MES, SCADA, or cloud platform.

Common confusion and related terms

– **MQTT vs. OPC UA**:
– MQTT is a messaging transport; it says how to move messages.
– OPC UA is a broader standard covering data models, services, security, and sometimes transport. OPC UA can be used over MQTT, and some industrial stacks combine both.
– **MQTT vs. AMQP, Kafka, or other messaging protocols**:
– MQTT is optimized for lightweight telemetry and constrained devices.
– AMQP, Kafka, and similar protocols are often used for heavier enterprise messaging or streaming use cases with more complex broker features.
– **MQTT vs. REST/HTTP APIs**:
– MQTT is stateful and push-oriented with publish–subscribe.
– REST/HTTP is typically request–response. Both can coexist; for example, MES may expose REST APIs while using MQTT for live telemetry and alerts.

Site context: MES alerts and plant systems

In the context of MES alerts and plant integrations:

– MES or event-processing services can **publish alerts** (e.g., `plant1/alerts/andon/line3`) to an MQTT broker.
– Andon displays, email/SMS gateways, or other notification systems can **subscribe** to these topics to render visual signals, send emails, or log events.
– Reliability considerations (QoS, retained messages, persistent sessions) and IT/OT governance (network zoning, authentication, authorization, audit logging) are typically addressed when using MQTT as part of validated MES and plant alert workflows.

This usage does not change the general meaning of MQTT; it is one common application pattern within OT–IT integration.