MQTT (Message Queue Telemetry Transport) is recognized as the Standard for IoT Messaging and is one of the main drivers of digitization in the economy and society. This protocol offers an extremely lightweight and efficient method for devices to communicate, which is crucial for the “Internet of Things” (IoT).
As an OASIS standard messaging protocol, MQTT is distinguished by several key criteria:
• It operates as a simple built-in binary publish and subscribe protocol at the TCP/IP level.
• It is suitable for low-functionality devices and optimized for transmission over unreliable, low-bandwidth, or high-latency networks.
• It minimizes network bandwidth needs through its push mechanism.
The Publish/Subscribe Architecture
MQTT decouples the devices involved in communication using a publish/subscribe mechanism. This architecture involves three core components:
1. MQTT Client: This is the program or device (such as an industrial controller) that uses MQTT. The Client actively establishes the Network Connection to the Server. A Client can function as a Publisher (sending messages) or a Subscriber (receiving messages).
2. MQTT Broker (Server): This is the central component that acts as the intermediary. The Broker accepts network connections, receives messages from Publishers, processes subscription requests, and forwards messages to all subscribing Clients that match the specified topic.
3. Topics: Messages are organised hierarchically using Topics that describe the subject area, similar to a directory path. The content and topic name are defined by the sender.
Ensuring Reliability with Quality of Service (QoS)
Reliability is managed through three defined Quality of Service (QoS) levels, ensuring messages are handled appropriately for the application:
• QoS 0 (At most once delivery): This is the lowest level, often referred to as “fire’n’forget”. There is no guarantee of message arrival, and no response or retry is performed by the sender.
• QoS 1 (At least once delivery): This ensures the message arrives at the receiver at least once. Duplicates can occur. The Broker acknowledges receipt with a PUBACK packet.
• QoS 2 (Exactly once delivery): This is the highest level, guaranteeing that the message is delivered exactly once, preventing both loss and duplication. This reliability is achieved through a robust four-packet handshake involving PUBLISH, PUBREC, PUBREL, and PUBCOMP packets.
Essential Features: Security and Connection Integrity
For industrial and large-scale applications, security and network stability are paramount:
• Security (TLS): MQTT supports the optional encryption of messages using TLS. Secured communication typically uses the port 8883, while unsecured communication uses port 1883. Securing the connection requires importing the MQTT Broker’s certificate (which can be self-signed or CA-derived) into the Client for authentication.
• Keep-Alive: This feature ensures the connection remains open by defining a maximum tolerated time period without communication. If the Client does not send another control packet before the interval expires, it MUST send a PINGREQ packet to signal its availability to the Broker.
• Version 5.0 Enhancements: Newer specifications (MQTT v5.0, OASIS Standard 2019) introduce features designed for enterprise and large-scale systems, including Shared Subscriptions for load balancing, improved error reporting via Reason Codes on all acknowledgement packets, Flow Control to limit the number of outstanding reliable messages, and enhanced authentication methods.
Industrial Implementation: SIMATIC S7 as an MQTT Client
For integrating SIMATIC controllers into an MQTT architecture, Siemens provides the “LMQTT” library, which includes the function block “LMQTT_Client” for use with the S7-1500 and S7-1200 CPUs.
To configure the S7 CPU as an MQTT Client:
1. The necessary function blocks and PLC data types are copied from the “LMQTT” Global Library into the TIA Portal user program.
2. A Global Data Block (DB) is created to store essential TCP connection parameters (e.g., hardware ID, Broker IP address or domain name, and port 1883/8883) and MQTT connection parameters (e.g., Client identifier, username, password, desired QoS level).
3. The main logic involves calling the FB “LMQTT_Client” and linking the defined parameters to its inputs and outputs.
4. To establish communication, the input tag enable is set to “True” to initiate the TCP and MQTT connection sequence. A successful connection is signalled when the output tag status reaches the value 16#7004.
Once connected, the Client can send messages by triggering the input tag publish, or request messages by activating the subscribe tag. For secure MQTT over TLS, the S7-1500 CPU must have firmware V2.0 or higher, and the MQTT Broker’s certificate must be imported into the TIA Portal’s Certificate Manager and assigned to the CPU.
I. Internal Operation: LMQTT_Client State Machines
The LMQTT_Client function block employs three state machines working hierarchically to fulfill communication requirements. An MQTT connection and subsequent messaging are only possible if the lower-level TCP connection is established and maintained.
The three state machines are:
1. STATE_MACHINE_FUNCTION_BLOCK_TCP (TCP Management):
◦ Function: Manages the underlying TCP connection and controls the structure and breaking of both TCP and MQTT connections. It also monitors the existing TCP connection for errors (e.g., cable breakage).
◦ Key States:
▪ FB_STATE_NO_PROCESSING: Waits for a positive edge on the enable input.
▪ FB_STATE_TCP_CONNECTING: Attempts to establish the TCP connection using TSEND_C. If successful, the status output is set to 16#7003 (STATUS_MQTT_CONNECTING), and the FB moves to the operating state.
▪ FB_STATE_OPERATING_MONITOR_TCP: The active state where it monitors the TCP connection and manages the next state machine, MQTT_STATE_MACHINE.
2. MQTT_STATE_MACHINE (MQTT Connection Management):
◦ Function: Starts automatically upon successful TCP establishment (status = 16#7003). It handles the “Handshake procedure” to establish the MQTT connection, monitors the Keep-Alive interval, and evaluates inputs like publish, subscribe, and unsubscribe to trigger command execution.
◦ Key States:
▪ MQTT_CONNECT_STATE_BUILD_PAKET: Assembles the CONNECT packet and sends it via the TSEND_C block.
▪ MQTT_CONNECT_STATE_SEND_PAKET_WAIT_FOR_CONNACK: Waits for the Broker’s CONNACK packet. Upon receipt, the overall status becomes 16#7004 (STATUS_MQTT_CONNECTED).
▪ MQTT_CONNECT_STATE_CONNECTED: The core runtime state. It checks for new send jobs and manages the MQTT_COMMANDS state machine. If the Keep-Alive interval is close to expiring, it initiates the PINGREQ packet send routine.
3. MQTT_COMMANDS (MQTT Control Packet Management):
◦ Function: Only processed if the MQTT_STATE_MACHINE is in the MQTT_CONNECT_STATE_CONNECTED state. This machine handles specific message jobs triggered by user inputs (publish, subscribe, unsubscribe) or the Keep-Alive monitor (PINGREQ).
◦ Operation Example (Publish/QoS 2): If publish is triggered, it enters MQTT_COMMAND_STATE_BUILD_PUBLISH to assemble the PUBLISH packet. In MQTT_COMMAND_STATE_SEND_PUBLISH, the client expects a sequence of acknowledgement packets (PUBREC, then sends PUBREL, then expects PUBCOMP) to complete the QoS 2 job. The status is momentarily set to 16#7006 to signal the push mechanism is running.
II. MQTT Control Packet Headers and Payloads
All MQTT Control Packets adhere to a fixed structure consisting of three parts, always in this order: the Fixed Header, the Variable Header (present in some packets), and the Payload (present in some packets).
A. Fixed Header Structure (Mandatory for all packets)
The Fixed Header always consists of:
1. Control Packet Type (Bits 7-4 of Byte 1): An identifier number (4-bit unsigned value) that specifies the type of MQTT control packet (e.g., CONNECT=1, CONNACK=2, PUBLISH=3, PINGREQ=12).
2. Flags (Bits 3-0 of Byte 1): Flags specific to the packet type (e.g., PUBLISH uses DUP, QoS, and RETAIN flags). Reserved flag bits MUST be set to the value listed.
3. Remaining Length (Byte 2 onwards): Encoded as a Variable Byte Integer, this field represents the number of bytes remaining in the packet (Variable Header + Payload).
B. Packet-Specific Details (CONNECT, PUBLISH, SUBSCRIBE, PING)
| Packet Type | Fixed Header Type | Variable Header Content | Payload Content |
| CONNECT | Type 1 | Protocol Name (“MQTT”), Protocol Level (5 for V5.0), Connect Flags (Will Flag, Will QoS, Clean Start, User Name/Password Flags), Keep Alive time, and optional Properties. | Client Identifier (ClientID – mandatory), Will Properties, Will Topic, Will Payload, User Name, and Password (order and presence depend on Connect Flags). |
| CONNACK | Type 2 | Connect Acknowledge Flags (including Session Present flag), Connect Reason Code (e.g., 0x00 Success), and Properties . | None. |
| PUBLISH | Type 3 | Topic Name, Packet Identifier (if QoS > 0), and Properties (e.g., Payload Format Indicator, Message Expiry Interval, Topic Alias). | The Application Message (user data), which can be zero length. |
| SUBSCRIBE | Type 8 | Packet Identifier, and Properties (e.g., Subscription Identifier, User Property). | List of Topic Filters (UTF-8 Encoded String), each followed by a byte of Subscription Options (including Maximum QoS, No Local, Retain As Published, Retain Handling). |
| PINGREQ | Type 12 | None. | None. |
| PINGRESP | Type 13 | None. | None. |
C. Data Types within Packets
Data within the control packets utilizes several specific MQTT data types:
• Two Byte Integer: 16-bit unsigned integers in big-endian order (MSB followed by LSB). Used for Packet Identifiers and Keep Alive time.
• Four Byte Integer: 32-bit unsigned integers in big-endian order. Used for Session Expiry Interval and Maximum Packet Size.
• Variable Byte Integer: Used for variable-length fields like the Remaining Length and Property Length. It uses up to four bytes, with the most significant bit indicating continuation.
• UTF-8 Encoded String: Used for fields like Topic Names, Client Identifiers, and Reason Strings . They are length-prefixed with a Two Byte Integer.