MQTT Topics & Wildcards: Anwendung in der Fertigungsindustrie

Inhalt

In einer zunehmend vernetzten Produktion spielt das MQTT-Protokoll eine zentrale Rolle für die Kommunikation zwischen Maschinen und Systemen. Um optimale Ergebnisse zu erzielen, sollten sich Anwender daher mit MQTT-Topics und der richtigen Verwendung von Wildcards vertraut machen. Dieser Artikel gibt einen Überblick über MQTT-Topics und Wildcards im Kontext der Fertigungsindustrie und zeigt, wie diese in ISA-95-konforme Architekturen integriert werden können.

 

Was sind MQTT Topics? 

MQTT-Topics dienen im MQTT-Protokoll als Kommunikationskanäle und ermöglichen Geräten, spezifische Datenströme (Payloads) zu veröffentlichen oder zu abonnieren. Ein Topic ist wie eine Adresse, die bestimmt, welche Nachrichten an welche Clients weitergeleitet werden. Sie bestehen aus einfachen Zeichenketten und folgen einer hierarchischen Struktur, vergleichbar mit einem Dateisystem eines Computer. Dabei dient der Schrägstrich (/) als Trennzeichen zwischen den Ebenen, ähnlich wie bei einem Dateipfad wie „C:/Benutzer/…“. Diese Struktur ermöglicht eine hierarchische Organisation von Informationen innerhalb des MQTT-Brokers. So könnte ein Temperatursensor zum Beispiel das folgende Topic verwenden, um die Prozesstemperatur eines bestimmten Work Centers zu übermitteln:

MQTT Topic Hierarchy

Diese Struktur erhöht die Flexibilität und Granularität des Datenaustauschs, da MQTT Clients nur relevante Informationen innerhalb der angegebenen Topic-Hierarchie abonnieren und empfangen können.

 

Wichtige Regeln für die Benennung von MQTT-Topics

Die Benennung von MQTT-Topics folgt einigen wichtigen Richtlinien:

  • Groß-/Kleinschreibung: Topics unterscheiden zwischen Groß- und Kleinschreibung. Beispielsweise sind werk01/linie01/Maschine01 und werk01/linie01/maschine01 zwei verschiedene Topics.
  • UTF-8 Zeichen: MQTT-Topics müssen aus gültigen UTF-8-Zeichen bestehen. Dabei dürfen bestimmte Zeichen, wie „+“ und „#“ (für Wildcards) und „$“ (für MQTT System-Topics), nicht wahllos verwendet werden, da sie spezielle Funktionen haben.
  • Konsistenz: Eine konsistente Benennung der Topics ist unerlässlich, um Verwirrung und Kommunikationsfehler zu vermeiden. Abhilfe kann hierbei die Anlehnung an Standards wie ISA-95 schaffen (Beispiel: enterprise/werk01/assemblyline01/linie01/Maschine01).
  • Eindeutigkeit: Die Vermeidung von Duplikaten in der Topic Benennung erleichtert den nahtlosen Datenaustausch, insbesondere aus der Unternehmensperspektive. Dies wird besonders deutlich, wenn der Datenaustausch zwischen Brokern über standardisierte MQTT-Bridges erfolgt. Eindeutige Topic-Namen verhindern dabei Topic Konflikte.
  • Versionierung: Um die Weiterentwicklung des MQTT Namespaces und der Topic Hierarchien zu optimieren, sollte Versionierung in die Hierarchie integriert werden. Dies ermöglicht eine einfache Verwaltung von Änderungen und erhält die Rückwärtskompatibilität (Beispiel: mySpec_v1/.../areaID/lineID/cellID).

 

MQTT Topic Benennung nach ISA-95

In einer Fertigungsumgebung sorgt ISA-95 für eine konsistente Benennung von MQTT-Topics. Hierdurch wird in der Regel eine klare und strukturierte Kommunikation zwischen allen Ebenen des Produktionsprozesses ermöglicht. Dabei teilt der ISA-95-Standard industrielle Systeme in fünf Ebenen auf, von der Unternehmens- bis in die Produktionsebenen. MQTT-Topics können diese Hierarchie direkt abbilden und eine klare Trennung zwischen Werksebenen, Produktionslinien, Maschinen und Prozessdaten schaffen. Dies erleichtert die gezielte Datenübertragung und das Abonnieren relevanter Informationen, auch über Fabrikgrenzen hinweg. Eine Schritt für Schritt Anleitung zur Entwicklung eines MQTT Topic Namespace finden Sie hier.

MQTT Topic Hierarchy according to ISA-95

 

MQTT-Wildcards und ihre Anwendung in ISA-95-Umgebungen

Wildcards sind Platzhalter, die es ermöglichen, eine Vielzahl von Topics zu abonnieren, ohne jedes einzelne manuell zu definieren. Ein Beispiel im Fertigungsumfeld: Clients können Events aller Maschinen einer bestimmten Linie über eine Wildcard abonnieren, ohne diese einzeln zu adressieren. Dabei gilt: Wildcards nur beim Abonnieren und nicht bei der Veröffentlichung von Nachrichten nutzen! In MQTT gibt es zwei wichtige Wildcard Typen:

  1. Plus-Zeichen (+): Das „+“ fungiert als Platzhalter für genau eine Ebene in der Topic-Hierarchie. Es ersetzt einen beliebigen Namen auf dieser Ebene. Ein Beispiel: fertigung/werk01/+/maschine01/status. Dieses Topic würde den Status von Maschine01 aus jeder Fertigungslinie innerhalb von Werk01 erfassen, unabhängig der Fertigungslinie.
  2. Hash-Zeichen (#): Das „#“ ist eine Multi-Level-Wildcard, die alles abdeckt, was nach der angegebenen Position folgt. Daher muss es immer am Ende eines Topics stehen. Beispiel: fertigung/werk01/#. Hiermit abonniert der Client alle Nachrichten für Werk01, egal ob sie von einer spezifischen Linie oder Maschine stammen.

 

Quality of Service (QoS) und Wildcards

Wildcard-Subscriptions können mit jeder QoS-Stufe (0, 1 oder 2) kombiniert werden. Dabei bestimmt der abonnierende Client, mit welcher Zustellgarantie er Nachrichten empfangen möchte – unabhängig davon, mit welcher QoS-Stufe sie veröffentlicht wurden. Bei QoS 1 und 2 muss der Broker jedoch Zustellversuche und ggf. unzustellte Nachrichten zwischenspeichern. Wenn viele Clients breit gefächerte Wildcards (z. B. #/status) mit hohen QoS-Stufen verwenden, kann dies zu einer spürbaren Speicher- und Rechenlast auf dem Broker führen. Für performante Systeme empfiehlt es sich daher, Wildcards gezielt und sparsam einzusetzen – idealerweise in Kombination mit QoS 0, wenn keine garantierte Zustellung erforderlich ist.

 

Retained Messages und Wildcards

Retained Messages speichern den letzten bekannten Wert eines Topics direkt im Broker. Sobald ein Client ein Topic abonniert – auch mit Wildcards –, sendet der Broker diese Nachricht sofort. Ein Client, der werk01/# abonniert, erhält also direkt alle aktuellen Zustände der Maschinen in werk01, sofern diese Topics Retained Messages enthalten. Das hilft besonders beim Systemstart oder nach einem Verbindungsabbruch: Der Client muss nicht warten, bis neue Werte eintreffen, sondern kennt den letzten Stand sofort. Dabei gilt: Der Broker speichert nur den jeweils letzten Wert pro Topic, nicht den Verlauf.

 

Security-Aspekte bei der Nutzung von Wildcards

Access Control Lists (ACLs) steuern, welche Clients auf welche Topics zugreifen dürfen. Wer MQTT produktiv einsetzt, sollte Wildcard-Zugriffe gezielt einschränken. Ein Beispiel: Ein Client erhält explizit Zugriff auf werk01/linie02/#, aber nicht auf andere Linien oder Werke. Damit solche Regeln greifen, muss die ACL auch Wildcards korrekt berücksichtigen. Andernfalls könnten Clients unbeabsichtigt auf Daten außerhalb ihres Zuständigkeitsbereichs zugreifen. Deshalb empfiehlt es sich, Wildcards nur dort zu erlauben, wo sie tatsächlich nötig sind – und immer in Verbindung mit klar definierten ACL-Regeln.

 

Wildcards und ACLs in the Unified Namespace

 

Fazit

In der modernen, vernetzten Fertigungsindustrie spielt das MQTT-Protokoll eine zentrale Rolle. Die korrekte Nutzung von MQTT-Topics und Wildcards ermöglicht eine effiziente und strukturierte Kommunikation zwischen Maschinen und Systemen. Durch die hierarchische Organisation der Topics nach ISA-95 und den Einsatz von Wildcards lassen sich große Datenmengen gezielt und flexibel verwalten, was zu einer verbesserten Performance und Übersichtlichkeit führt.

Über i-flow: i-flow ist ein Unternehmen für industrielle Software mit Sitz in Süddeutschland. Wir bieten produzierenden Unternehmen die weltweit intuitivste Software zur Vernetzung von Fabriken. Täglich über 400 Millionen Datenoperationen in produktionskritischer Umgebung demonstrieren nicht nur die Skalierbarkeit der Software, sondern auch das tiefe Vertrauen, das unsere Kunden in i-flow setzen. Unser Erfolg basiert auf enger Zusammenarbeit mit Kunden und Partnern weltweit, darunter namhafte Fortune-500-Unternehmen und Branchenführer wie Bosch.

Jetzt selbst ausprobieren - Kostenlose Testversion

Überzeugen Sie sich in einem Test selbst von den unbegrenzten Möglichkeiten, die Sie mit i-flow erhalten. Jetzt 30 Tage kostenfrei testen, auf Ihren Systemen.

Verwandte Artikel

Ihre Frage wurde nicht be­antwortet? Kontaktieren Sie uns.

Ihr Kontakt:

Marieke Severiens (i-flow GmbH)
content@i-flow.io