MQTT in der Industrie: Publish-Subscribe-Architektur, Sicherheit und Einführung im Mittelstand

MQTT in der Industrie hat sich als schlankes Nachrichtenprotokoll etabliert, mit dem Maschinen, Sensoren, Gateways und Auswertungssysteme Daten austauschen, ohne dass jede Komponente jede andere direkt kennen muss. Statt starrer Punkt-zu-Punkt-Verbindungen veröffentlichen Datenquellen ihre Werte an einen zentralen Vermittler, den Broker, und interessierte Systeme abonnieren genau die Themen, die sie benötigen. Für mittelständische Fertigungsbetriebe mit gewachsenem Maschinenpark ist das attraktiv, weil sich neue Anwendungen wie Zustandsüberwachung, Energiemonitoring oder Kennzahlenboards anbinden lassen, ohne bestehende Steuerungen jedes Mal neu zu verdrahten. Zugleich verführt die Einfachheit des Protokolls dazu, ohne Konzept zu starten. Wildwuchs bei Topic-Namen, ungeklärte Zuständigkeiten für den Broker und fehlende Sicherheitsmaßnahmen führen dann zu Datenlandschaften, die sich kaum betreiben lassen. Dieser Beitrag erläutert die Funktionsweise von MQTT, die Dienstgüten, ein belastbares Topic-Design, den Einsatz von Sparkplug B, Sicherheitsanforderungen und ein Vorgehen für die Einführung. Er richtet sich an Geschäftsführung, Produktionsleitung und IT-Verantwortliche, die eine tragfähige Datenbasis für ihre Fertigung schaffen wollen.

Titelbild: Foto von Simon Kadula auf Unsplash.

Wie MQTT funktioniert und warum das Protokoll zur Fertigung passt

MQTT steht für Message Queuing Telemetry Transport und wurde für Verbindungen mit knapper Bandbreite und unzuverlässigen Netzen entworfen. Das Protokoll ist als ISO/IEC 20922 international genormt und wird von der OASIS-Spezifikation beschrieben. Es setzt auf TCP auf, verwendet sehr kleine Kopfdaten und hält Verbindungen dauerhaft offen. Dadurch eignet es sich für Steuerungen mit begrenzten Ressourcen ebenso wie für Gateways, die viele Signale bündeln.

Kern des Konzepts ist das Publish-Subscribe-Muster. Ein Client veröffentlicht eine Nachricht unter einem Thema (Topic), der Broker nimmt sie entgegen und leitet sie an alle Clients weiter, die dieses Thema abonniert haben. Sender und Empfänger sind damit zeitlich und räumlich entkoppelt: Der Sender muss nicht wissen, wer die Daten verarbeitet, und der Empfänger muss nicht wissen, woher sie stammen.

Für die Fertigung ergeben sich daraus mehrere Vorteile. Neue Verbraucher wie ein Dashboard oder ein Analysewerkzeug lassen sich ergänzen, ohne die Datenquelle zu verändern. Die Zahl der Verbindungen wächst linear mit der Zahl der Teilnehmer und nicht quadratisch wie bei Punkt-zu-Punkt-Anbindungen. Außerdem unterstützt das Protokoll Mechanismen, die in Produktionsnetzen häufig gebraucht werden, etwa das Zwischenspeichern des letzten Wertes oder die Meldung eines Verbindungsabbruchs.

Die wichtigsten Bausteine im Überblick

• Broker: Zentrale Vermittlungsstelle, die Verbindungen verwaltet, Nachrichten verteilt, Berechtigungen prüft und Sitzungen speichert.
• Client: Jede Komponente, die sich mit dem Broker verbindet, etwa Sensor, Steuerung, Edge-Gateway, Datenbank oder Visualisierung.
• Topic: Hierarchischer Name einer Nachrichtenquelle, getrennt durch Schrägstriche, zum Beispiel Werk, Halle, Linie, Maschine und Messgröße.
• Retained Message: Vom Broker gehaltene letzte Nachricht eines Topics, die neue Abonnenten sofort erhalten.
• Last Will: Vom Client hinterlegte Nachricht, die der Broker bei ungeplantem Verbindungsabbruch veröffentlicht.

Dienstgüte und Sitzungsverhalten richtig wählen

MQTT kennt drei Stufen der Zustellgarantie, die jeweils pro Nachricht gewählt werden. Die Wahl beeinflusst Netzlast, Latenz und das Verhalten bei Verbindungsabbrüchen. In der Praxis wird häufig pauschal die höchste Stufe eingestellt, was Ressourcen verbraucht und selten nötig ist.

Stufe	Bezeichnung	Verhalten	Typischer Einsatz
QoS 0	Höchstens einmal	Keine Bestätigung, Verlust möglich	Hochfrequente Messwerte, bei denen der nächste Wert den vorigen ersetzt
QoS 1	Mindestens einmal	Bestätigung, Duplikate möglich	Zählerstände, Zustandswechsel, Alarme mit idempotenter Verarbeitung
QoS 2	Genau einmal	Vierstufiger Austausch, höchster Aufwand	Befehle und Ereignisse, die nie doppelt verarbeitet werden dürfen

Für zyklische Prozesswerte genügt meist QoS 0, weil ein verlorener Wert durch den nächsten ersetzt wird. Für Ereignisse wie Störungen oder Auftragsmeldungen ist QoS 1 üblich, sofern die Auswertung Duplikate verträgt, etwa durch Zeitstempel und eindeutige Kennungen. QoS 2 ist für Schaltbefehle sinnvoll, sollte aber die Ausnahme bleiben.

Ebenso wichtig ist das Sitzungsverhalten. Bei einer persistenten Sitzung hält der Broker Abonnements und unquittierte Nachrichten für einen vorübergehend getrennten Client vor. Das ist nützlich für Gateways in Netzen mit Funkstrecken. Dauerhaft getrennte Clients dürfen jedoch keine unbegrenzten Warteschlangen erzeugen, weshalb Ablaufzeiten für Sitzungen festgelegt werden sollten. Die Protokollversion 5 bietet dafür ausdrückliche Parameter sowie Ursachencodes bei Fehlern und gemeinsame Abonnements, mit denen sich Last auf mehrere Verbraucher verteilen lässt.

Topic-Design: Die unterschätzte Grundlage

Die Qualität einer MQTT-Landschaft entscheidet sich weniger an der Wahl des Brokers als am Namensschema der Topics. Ein unstrukturierter Wildwuchs ist später kaum zu korrigieren, weil jeder Verbraucher auf die bestehenden Namen aufgebaut hat. Bewährt hat sich ein hierarchisches Schema, das die Anlagenstruktur abbildet und von allgemein nach speziell gegliedert ist.

Ein Beispiel für ein solches Schema lautet Unternehmen, Werk, Bereich, Linie, Maschine, Datenart. Wildcards erlauben es Abonnenten, ganze Teilbäume zu beziehen. Das Pluszeichen ersetzt genau eine Ebene, die Raute steht für beliebig viele Ebenen. Gerade die Raute auf oberster Ebene ist mit Vorsicht zu verwenden, weil sie den gesamten Datenstrom eines Brokers auf einen Client leitet.

• Einheitliche Schreibweise festlegen, also Kleinbuchstaben, keine Leerzeichen, keine Sonderzeichen und keine Umlaute.
• Nur stabile Eigenschaften in den Topic-Namen aufnehmen, nicht veränderliche Werte wie Auftragsnummern oder Schichtbezeichnungen.
• Datenarten trennen, etwa Messwerte, Zustände, Ereignisse und Befehle, damit sich Berechtigungen und Qualitätsstufen gezielt vergeben lassen.
• Nutzdaten nicht in den Topic-Namen verlagern, sondern in der Nachricht transportieren.
• Das Schema schriftlich dokumentieren, versionieren und einer verantwortlichen Stelle zuordnen.

Das Konzept des Unified Namespace

Viele Unternehmen bündeln ihre Topics in einem gemeinsamen Namensraum, der als zentrale, aktuelle Datenquelle für das gesamte Werk dient. Maschinen und Systeme veröffentlichen ihre Werte dort, andere Systeme abonnieren sie. Der Vorteil liegt in einer einzigen, nachvollziehbaren Struktur. Der Preis ist ein höherer Abstimmungsaufwand bei der Namensgebung und ein Betrieb des Brokers mit hoher Verfügbarkeit, da er zum Dreh- und Angelpunkt der Datenflüsse wird.

Nutzdaten und Sparkplug B

MQTT legt fest, wie Nachrichten transportiert werden, nicht aber, wie die Nutzdaten aufgebaut sind. Ohne Vereinbarung verwendet jede Abteilung ihr eigenes Format, und Verbraucher müssen jeden Sender einzeln anpassen. Viele Betriebe einigen sich auf JSON mit festen Feldern für Wert, Einheit, Zeitstempel und Qualitätskennzeichen. Das ist gut lesbar und einfach zu testen, erzeugt aber größere Nachrichten.

Als Ergänzung gibt es mit Sparkplug B eine offene Spezifikation, die unter dem Dach der Eclipse Foundation gepflegt wird. Sie definiert ein einheitliches Topic-Schema, ein kompaktes Nutzdatenformat auf Basis von Protocol Buffers und ein Zustandsmodell für Geräte. Beim Start meldet ein Gerät eine Geburtsnachricht mit allen verfügbaren Datenpunkten, bei Verbindungsverlust veröffentlicht der Broker eine Todesnachricht. Verbraucher erkennen so jederzeit, welche Quellen aktiv sind, und erhalten den vollständigen Datenbestand, ohne einzeln nachfragen zu müssen.

Wer Nutzdaten nicht festlegt, verlagert die Integrationsarbeit vom Sender auf jeden einzelnen Verbraucher. Ein verbindliches Datenmodell ist deshalb der eigentliche Hebel einer MQTT-Einführung.

Sparkplug B bringt Disziplin, setzt aber Werkzeuge voraus, die das Format unterstützen. Für ältere Anlagen ist ein einfaches JSON-Format mit klaren Regeln oft der praktikablere Einstieg. Entscheidend ist, dass die Wahl bewusst getroffen, dokumentiert und konsequent umgesetzt wird.

MQTT und OPC UA: Ergänzung statt Konkurrenz

In der Fertigung begegnen sich häufig MQTT und OPC UA. Beide Standards verfolgen unterschiedliche Schwerpunkte. OPC UA liefert ein umfangreiches Informationsmodell mit Datentypen, Methoden und Beziehungen und eignet sich zur semantisch reichen Anbindung von Maschinen. MQTT transportiert Daten leichtgewichtig und skaliert gut über Standorte hinweg.

Merkmal	MQTT	OPC UA
Kommunikationsmuster	Publish-Subscribe über einen Broker	Client-Server, ergänzend Publish-Subscribe
Informationsmodell	Nicht vorgegeben, Nutzdaten frei wählbar	Umfangreiches, standardisiertes Modell
Ressourcenbedarf	Gering, auch für kleine Geräte	Höher, abhängig vom Funktionsumfang
Stärke	Verteilung von Daten an viele Verbraucher	Semantische Anbindung von Maschinen und Steuerungen
Typische Rolle	Transportweg zwischen Edge, Werk und Cloud	Schnittstelle an der Maschine

In vielen Architekturen liest ein Edge-Gateway Daten über OPC UA aus der Steuerung und veröffentlicht sie per MQTT in den gemeinsamen Namensraum. So bleibt die Semantik an der Maschine erhalten, während die Verteilung schlank und skalierbar erfolgt. Eine Entscheidung für das eine Protokoll schließt das andere nicht aus.

Sicherheit: Was ein Broker mindestens leisten muss

Ein MQTT-Broker bündelt Daten aus der Produktion und ist damit ein sensibles Ziel. Das Protokoll selbst bringt keine Verschlüsselung mit, sondern verlässt sich auf die Transportschicht. Standardinstallationen, die unverschlüsselt auf dem üblichen Port ohne Anmeldung erreichbar sind, gehören in Produktionsnetzen zu den häufigsten Schwachstellen.

1. Verschlüsselte Verbindungen über TLS ausschließlich zulassen und unverschlüsselte Zugänge deaktivieren.
2. Jeden Client eindeutig authentifizieren, bevorzugt mit Zertifikaten, ersatzweise mit individuellen Zugangsdaten statt gemeinsamer Konten.
3. Berechtigungen pro Client und Topic-Bereich vergeben, sodass ein Sensor nur in seinem Zweig veröffentlicht und kein Verbraucher beliebige Befehle senden darf.
4. Broker in einer geschützten Zone betreiben, mit klar definierten Übergängen zwischen Produktionsnetz und Büronetz, orientiert an der Normenreihe IEC 62443.
5. Verbindungsversuche, Berechtigungsverstöße und Auslastung protokollieren und überwachen.
6. Patches für Broker und Bibliotheken in einen festen Wartungsprozess aufnehmen.

Für das übergeordnete Managementsystem kann eine Orientierung an der Normenreihe ISO/IEC 27001 hilfreich sein, in der Betriebe Zuständigkeiten, Risikoanalyse und Änderungsverfahren festschreiben. Zusätzlich sollte geprüft werden, ob die Anbindung neuer vernetzter Komponenten Pflichten aus der NIS-2-Umsetzung berührt.

Typische Stolperfallen in der Praxis

• Zu viele Daten ohne Zweck: Jeder Messwert wird mit höchster Frequenz veröffentlicht, obwohl der Verbraucher nur Minutenwerte benötigt. Das belastet Netz und Broker.
• Veraltete Retained Messages: Ein dauerhaft gehaltener Wert wirkt aktuell, obwohl die Quelle seit Stunden ausgefallen ist. Zeitstempel und Gültigkeitsprüfung sind erforderlich.
• Fehlende Zeitsynchronisation: Ohne gemeinsame Zeitbasis lassen sich Ereignisse aus verschiedenen Quellen nicht ordnen.
• Einzelner Broker ohne Ausfallkonzept: Fällt er aus, steht der gesamte Datenfluss. Clusterbetrieb oder eine Ersatzinstanz mit definiertem Umschaltverhalten sind einzuplanen.
• Befehle über denselben Weg wie Messwerte: Schreibende Zugriffe auf Maschinen brauchen strengere Freigaben und eine getrennte Berechtigungsstruktur.
• Fehlende Verantwortung: Ohne benannte Zuständigkeit für Schema, Broker und Clients veralten Dokumentation und Regeln rasch.

Schritt für Schritt zur Einführung

Ein pragmatisches Vorgehen beginnt klein, schafft früh Erfahrung und legt dabei die Regeln fest, die später für alle gelten. Die folgenden Schritte haben sich in Fertigungsbetrieben bewährt.

1. Ziel und Anwendungsfall festlegen, etwa Maschinenzustände für ein Kennzahlenboard oder Energiedaten für ein Monitoring, und den Nutzen messbar beschreiben.
2. Vorhandene Datenquellen erfassen: Welche Steuerungen, Sensoren und Systeme liefern welche Signale in welcher Qualität?
3. Topic-Schema, Datenformat und Zeitstempelregeln verbindlich festlegen und dokumentieren.
4. Broker auswählen und betreiben, entweder selbst im eigenen Rechenzentrum oder als verwalteten Dienst, und die Verfügbarkeitsanforderung klären.
5. Sicherheitskonzept umsetzen: TLS, Authentifizierung, Berechtigungen, Netzsegmentierung.
6. Edge-Gateways für Bestandsmaschinen einrichten, die Signale über herstellerspezifische Schnittstellen oder OPC UA auslesen und veröffentlichen.
7. Pilotlinie anbinden, Last und Datenqualität messen und die Regeln anhand der Erfahrungen anpassen.
8. Schrittweise auf weitere Linien und Werke ausrollen und den Betrieb in feste Zuständigkeiten überführen.

Beispielrechnung zur Datenmenge

Eine Beispielrechnung verdeutlicht, warum die Veröffentlichungsfrequenz geprüft werden sollte. Angenommen, eine Linie veröffentlicht 40 Messwerte je Sekunde, jede Nachricht umfasst inklusive Kopfdaten etwa 200 Byte. Das ergibt rund 8 Kilobyte je Sekunde und knapp 690 Megabyte je Tag für eine einzige Linie. Werden nur Änderungen oberhalb einer Schwelle veröffentlicht und für Auswertungen Minutenmittelwerte gebildet, sinkt die Menge um ein Vielfaches. Diese Zahlen sind ein Rechenbeispiel und keine Messung, zeigen aber die Größenordnung der möglichen Einsparung.

Checkliste vor dem Produktivbetrieb

• Topic-Schema und Nutzdatenformat sind dokumentiert und freigegeben
• Verschlüsselung und individuelle Authentifizierung sind aktiv
• Berechtigungen sind pro Client und Topic-Bereich vergeben
• Dienstgüte ist je Datenart bewusst gewählt
• Ausfallkonzept für den Broker ist getestet
• Zeitsynchronisation aller Quellen ist sichergestellt
• Überwachung von Auslastung, Verbindungen und Fehlern läuft
• Zuständigkeiten für Schema, Betrieb und Weiterentwicklung sind benannt

Fazit

MQTT bietet der Fertigung einen schlanken, skalierbaren Weg, Daten aus Maschinen und Sensoren für viele Anwendungen verfügbar zu machen. Der Erfolg hängt weniger vom Protokoll als von der Disziplin bei Namensschema, Datenmodell, Sicherheit und Betrieb ab. Wer klein beginnt, Regeln früh festlegt und den Broker als kritische Infrastruktur behandelt, schafft eine Grundlage, die sich über Linien und Werke hinweg erweitern lässt. Die Spezifikation des Protokolls ist bei OASIS frei einsehbar und eignet sich als Referenz für die technische Umsetzung.

FAQ

Wofür wird MQTT in der Industrie hauptsächlich eingesetzt?
MQTT dient als Transportweg für Sensor-, Zustands- und Ereignisdaten von Maschinen und Gateways zu Auswertungs- und Visualisierungssystemen. Durch das Publish-Subscribe-Muster lassen sich neue Verbraucher ergänzen, ohne die Datenquellen zu verändern.

Welche Dienstgüte sollte für Messwerte gewählt werden?
Für zyklische Messwerte genügt meist QoS 0, da ein verlorener Wert durch den nächsten ersetzt wird. Für Zustandswechsel und Alarme wird häufig QoS 1 verwendet, für kritische Befehle QoS 2.

Ersetzt MQTT die Schnittstelle OPC UA?
In der Regel nicht. OPC UA bietet ein semantisches Informationsmodell an der Maschine, MQTT verteilt Daten schlank über Werke und Systeme. Häufig liest ein Gateway per OPC UA aus und veröffentlicht per MQTT.

Wie wird ein MQTT-Broker abgesichert?
Mindestens durch verschlüsselte Verbindungen mit TLS, individuelle Authentifizierung jedes Clients, Berechtigungen pro Topic-Bereich, Netzsegmentierung und laufende Überwachung. Unverschlüsselte und anonyme Zugänge sollten deaktiviert werden.

Was ist Sparkplug B und wann lohnt sich der Einsatz?
Sparkplug B ist eine offene Spezifikation für Topic-Schema, Nutzdatenformat und Gerätezustände auf Basis von MQTT. Der Einsatz lohnt sich, wenn viele Systeme unterschiedlicher Hersteller einheitlich Daten austauschen sollen und die eingesetzten Werkzeuge das Format unterstützen.

Wie groß sollte ein Pilotprojekt sein?
Eine Linie oder ein klar abgegrenzter Anwendungsfall genügt. Entscheidend ist, dass Topic-Schema, Datenformat und Sicherheitsregeln bereits im Pilot verbindlich festgelegt und später übernommen werden.