MQTT Connection Settings in the Unified Namespace (UNS)

In the context of Industry 4.0 and the Industrial IoT (IIoT), the Unified Namespace (UNS) is increasingly establishing itself as a central communication platform. The aim is to create a standardized real-time data space in which IT and OT systems are seamlessly integrated. The lean, event-based protocol MQTT, which efficiently networks sensors, controllers and IT systems, plays a key role in this. Factory systems – as MQTT clients – establish a connection to the MQTT broker for this purpose. The MQTT connection settings selected, such as Clean Session or Last Will, have a significant impact on the stability and reliability of communication. Careful configuration is crucial, especially in a production-critical environment. This article explains how central connection parameters influence the behavior of connected systems in the UNS.

What is a Unified Namespace (UNS)?

A Unified Namespace (UNS) is a central data space that organizes all of a factory’s data and makes it accessible in real time. This creates a single source of truth for a factory’s data streams. Details and further advantages can be found here. MQTT is often used as the technological basis, as it enables asynchronous, event-based and lean coupling of data sources and sinks via MQTT Topics. The architecture is highly scalable, as any number of factory systems (MQTT clients) can be connected.

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a client-server network protocol based on the publisher/subscriber model. A central element is the broker (server), via which connected MQTT clients exchange messages: A publisher client sends data with a specific topic (subject), subscriber clients can subscribe to these topics and receive the corresponding messages. The message exchange is very lean and efficient (more detailed information on MQTT can be found here).

MQTT Connection in the UNS: Structure and behavior

To establish a connection with the MQTT broker, MQTT clients use an MQTT library. These are available for almost all common programming languages. In a production environment, dozens, hundreds or even thousands of clients can be connected to the broker in parallel. Typical examples of MQTT clients are

1. CNC milling machine: As a publisher, the machine regularly sends the operating status (“active”, “malfunction”, “maintenance”) to the central Andon Board. At the same time, it receives new order data from the ERP as a subscriber.
2. Temperature sensor: As a publisher, a sensor continuously transmits process values such as “104.4 °C” to a higher-level condition monitoring system. The system uses the data for process monitoring.
3. ERP system (e.g. SAP): The ERP acts as an MQTT subscriber to receive production data (e.g. good parts) and automates subsequent processes such as replenishment or material postings.

Integration scenarios

There are two integration scenarios for factory systems:

1. Non-MQTT native systems that do not support MQTT directly and are connected via gateways (e.g. PLC controllers). These act as translators between the connected systems and MQTT.
2. MQTT native systems that use MQTT libraries directly (e.g. modern sensors or applications).

The role of the MQTT Broker

The MQTT Broker is the central control element in the MQTT network. It manages all connections, regulates the exchange of messages and checks authorizations. Only by correctly configuring and managing these processes can the smooth operation of a production-related MQTT network in the UNS be guaranteed. Its core tasks include

1. Receiving and forwarding messages between clients
2. Checking publish and subscribe authorizations
3. Management of messages with Quality of Service (QoS) Level 1 and 2
4. Assignment of messages to authorized subscribers

MQTT communication phases

An MQTT connection connects a client (e.g. machine, sensor) with an MQTT broker. The connection between client and broker takes place in the following phases:

1. Connect: The client sends a CONNECT packet to the broker, which contains connection parameters such as client ID, clean session, last will, etc.
2. The broker responds with a CONNACK packet that confirms or rejects the connection status.
3. In addition, the client regularly sends PINGREQ packets (ping request) to keep the connection active.
4. The broker responds with PINGRESP (Ping Response). PINGREQ and PINGRESP are an essential mechanism for connection monitoring (see Keep Alive below).
5. Disconnect: The client terminates the connection in a controlled manner via a DISCONNECT packet. If there is no clean disconnect (e.g. in the event of a power failure), the broker falls back to the configured Last Will.

MQTT Connection Settings

To connect the client and broker, the client first sends an MQTT CONNECT request to the broker. This request consists of the three mandatory parameters clientID, cleanSession and keepAlive as well as the optional parameters such as username, password, lastWillTopic, lastWillQos, lastWillMessage and lastWillRetain.

Client ID

The client ID is a mandatory parameter for every MQTT connection. It uniquely identifies the MQTT client to the broker. The choice of client ID has a direct influence on session management, especially in conjunction with the Clean Session parameter (see next section).

• Uniqueness is mandatory: Every client that connects to a broker must use a unique client ID. If a second client connects with the same ID, the existing connection is disconnected by the broker.
• Persistent sessions require consistency: With Clean Session = false, a consistent client ID is essential. This is the only way the broker can correctly assign the session, including subscriptions and outstanding QoS messages, and restore it when reconnecting.
• Best practices: Use systematically generated, speaking IDs (e.g. iflow-edge-id124, plc123-gw).

Clean Session

Clean Session is a central parameter of an MQTT connection and influences the session management between client and broker. This setting determines whether the broker and client establish a persistent session or whether the broker starts a new, temporary session each time it connects to the client.

Overview

MQTT Connection Settings: Keep Alive

The Keep Alive parameter defines the maximum time interval (in seconds) that may elapse between two messages from a client to the broker. Even if the client does not transmit any user data via Publish/Subscribe, the client must send a ping request (PINGREQ) within this interval to keep the connection active. The broker expects these signs of life regularly and responds with a ping response (PINGRESP). If these messages are not received, the connection is considered inactive and closed.

• Connection monitoring: The keep alive value is used by the broker to detect interrupted connections, for example due to network problems or unexpected client crashes.
• Heartbeat function: Even without publish/subscribe data, the client regularly sends a PINGREQ and receives a PINGRESP from the broker to maintain the connection.
• Best Practice:
  • Select the keep-alive value to suit the application: Low (1-10 s) for time-critical systems (e.g. controllers), higher (60-120 s) for battery-powered or bandwidth-sensitive clients (e.g. mobile devices or sensors).
  • Keep the keep-alive value synchronized with network infrastructure, firewalls or proxies that could disconnect inactive TCP connections early.

MQTT username and password

The MQTT connection parameters “username” and “password” are used to authenticate the client to the broker. Although this is optional, it is essential in security-critical environments such as industrial networks.

• Access control: The broker can decide on the basis of user name and password whether a client is allowed to connect. In addition (optional), the broker can determine which user has publish or subscribe rights to which topics.
• Security: The client transmits the authentication data in plain text if no transport encryption (e.g. TLS) is used. The use of TLS is therefore strongly recommended.

MQTT Connection Settings: Last Will

The Last Will (in full: Last Will and Testament) is optional, but extremely important in the context of MQTT Connection Settings. It defines which message the broker should publish on behalf of the client in the event of an unexpected connection failure. This allows the broker to inform other systems about the failure. Further details on Last Will can be found here.

• Fault tolerance: The Last Will serves as an “emergency message” and makes it possible to recognize the loss of a client and react automatically (e.g. alarm, fallback strategy, display in the HMI).
• Trigger: The broker publishes the last will if a client does not disconnect properly (e.g. power failure, network error, crash). In the event of a regular disconnect, the broker does not send the last will.
• Configuration: The Last Will is included in the CONNECT packet when the connection is established. It includes the topic, message, QoS and the retain flag.

Last Will Topic

The last will topic determines on which topic the broker publishes the last will message. It should be named clearly and logically. This allows other systems to react specifically to failure information by subscribing specifically to these topics. For example:

• status/iflow-edge-id123
• system/iflow-edge-id123/will

Last Will QoS

The QoS level (Quality of Service) determines the delivery guarantee of the last-will message. At least QoS 1 should be used in production-critical applications so that the broker can deliver messages reliably and react to client failures.

• QoS 0: “At most once” – no delivery guarantee
• QoS 1: “At least once” – can arrive twice
• QoS 2: “Exactly once” – highest delivery quality

Last Will Message

The Last Will Message is the message text that the broker automatically publishes in the event of an unexpected client failure (e.g. “offline”). The client can freely choose the content and format, for example as plain text or in JSON format.

Last Will Retain

The retain flag controls whether the broker saves the last-will message permanently:

• Retain = true: The broker saves the message on the topic and actively sends it to each new subscriber as soon as they subscribe.
• Retain = false: The message is only sent when the event occurs, but is not saved permanently.

Practical example and best practices

An MQTT client of a controller connects to the broker and configures a Last Will with topic status/plc001, message “offline”, QoS 1 and Retain = true. If the controller fails unexpectedly, the broker automatically publishes this message. An HMI system that has subscribed to the status topic recognizes the failure immediately and displays a corresponding warning. The following best practices apply:

• Use clear, machine-readable message formats (e.g. JSON) for easy evaluation.
• Set QoS 1 or 2 for critical systems.
• Activate the retain flag if new subscribers should recognize the failure status directly.
• Select a dedicated status topic, e.g. …/status/plc001.

Conclusion

Choosing and configuring the right MQTT connection settings is crucial for the reliability, stability and transparency of real-time communication in the Unified Namespace (UNS). Parameters such as Client ID, Clean Session, Keep Alive, Username/Password and Last Will significantly influence the behavior of connected systems – especially in the event of network failures, reconnects or security requirements.

A conscious and standardized configuration of these connection parameters is particularly worthwhile in production-critical environments. This is the only way to ensure that data flows reliably, system statuses are detected correctly and MQTT-based integrations in the UNS can be operated in a robust and scalable manner.