In an increasingly connected production environment, the MQTT protocol is crucial for communication between machines and systems. To ensure optimal results, users should understand MQTT topics and the proper use of wildcards. This article offers an overview of MQTT topics and wildcards within the manufacturing industry and explains how to integrate them into ISA-95-compliant architectures.
What are MQTT Topics?
MQTT topics serve as communication channels in the MQTT protocol and enable devices to publish or subscribe to specific data streams (payloads). A topic is like an address that determines which messages are forwarded to which clients. They consist of simple character strings and follow a hierarchical structure, comparable to a computer’s file system. The slash (/) serves as a separator between the levels, similar to a file path such as “C:/User/…”. This structure enables a hierarchical organization of information within the MQTT broker. For example, a temperature sensor could use the following topic to transmit the process temperature of a specific work center:
This structure increases the flexibility and granularity of data exchange, as MQTT clients can only subscribe to and receive relevant information within the specified topic hierarchy.
Important Rules for Naming MQTT Topics
The naming of MQTT topics follows some important guidelines:
- Case-sensitive: Topics are case-sensitive. For example, werk01/linie01/Maschine01 and werk01/linie01/maschine01 are two different topics.
- UTF-8 characters: MQTT topics must consist of valid UTF-8 characters. Certain characters, such as “+” and “#” (for wildcards) and “$” (for MQTT system topics), must not be used indiscriminately as they have special functions.
- Consistency: Consistent naming of topics is essential to avoid confusion and communication errors. This can be remedied by following standards such as ISA-95 (example:
enterprise/werk01/assemblyline01/linie01/Maschine01). - Uniqueness: Avoiding duplicates in the topic naming facilitates seamless data exchange, especially from a business perspective. This becomes particularly clear when data is exchanged between brokers via standardized MQTT bridges. Unique topic names prevent topic conflicts.
- Versioning: To optimize the further development of the MQTT namespace and the topic hierarchies, versioning should be integrated into the hierarchy. This enables simple management of changes and maintains backwards compatibility (example:
mySpec_v1/.../areaID/lineID/cellID).
MQTT Topic Naming According to ISA-95
In a production environment, ISA-95 ensures consistent naming of MQTT topics. This generally enables clear and structured communication between all levels of the production process. The ISA-95 standard divides industrial systems into five levels, from the company level to the production level. MQTT topics can map this hierarchy directly and create a clear separation between plant levels, production lines, machines and process data. This facilitates targeted data transmission and the subscription of relevant information, even across factory boundaries. A step-by-step guide to developing an MQTT topic namespace can be found here.
MQTT Wildcards and the Application in ISA-95 Environments
Wildcards are placeholders that make it possible to subscribe to a large number of topics without having to define each one manually. An example in the production environment: clients can subscribe to events from all machines on a specific line via a wildcard without having to address them individually. The following applies: only use wildcards when subscribing and not when publishing messages! There are two important wildcard types in MQTT:
- Plus sign (+): The “+” acts as a placeholder for exactly one level in the topic hierarchy. It replaces any name at this level. An example:
fertigung/werk01/+/maschine01/status. This topic would record the status of machine01 from each production line within plant01, regardless of the production line. - Hash character (#): The “#” is a multi-level wildcard that covers everything that follows the specified position. It must therefore always appear at the end of a topic. Example:
fertigung/werk01/#. The client uses this to subscribe to all messages for Werk01, regardless of whether they originate from a specific line or machine.
Quality of Service (QoS) and Wildcards
Wildcard subscriptions can be combined with any QoS level (0, 1 or 2). The subscribing client determines the delivery guarantee with which it wishes to receive messages – regardless of the QoS level with which they were published. With QoS 1 and 2, however, the broker must buffer delivery attempts and any undelivered messages. If many clients use a wide range of wildcards (e.g. #/status) with high QoS levels, this can lead to a noticeable memory and computing load on the broker. For high-performance systems, it is therefore advisable to use wildcards selectively and sparingly – ideally in combination with QoS 0 if no guaranteed delivery is required.
Retained Messages and Wildcards
Retained messages store the last known value of a topic directly in the broker. As soon as a client subscribes to a topic – even with wildcards – the broker sends this message immediately. A client that subscribes to werk01/# therefore receives all the current states of the machines in werk01 directly, provided these topics contain retained messages. This is particularly helpful at system startup or after a connection failure: the client does not have to wait for new values to arrive, but knows the latest status immediately. The following applies: The broker only saves the last value per topic, not the history.
Security Aspects when Using Wildcards
Access control lists (ACLs) control which clients are allowed to access which topics. Anyone using MQTT productively should specifically restrict wildcard access. An example: A client is explicitly granted access to werk01/linie02/#, but not to other lines or plants. For such rules to apply, the ACL must also take wildcards into account correctly. Otherwise, clients could unintentionally access data outside their area of responsibility. It is therefore advisable to only allow wildcards where they are actually necessary – and always in conjunction with clearly defined ACL rules.
Conclusion
The MQTT protocol is crucial in modern, connected manufacturing. Proper use of MQTT topics and wildcards allows for efficient, structured communication between machines and systems. By organizing topics hierarchically according to ISA-95 and utilizing wildcards, large data volumes can be managed in a targeted, flexible way, improving both performance and clarity.
