MQTT Protokoll im Maschinenbau

In der Diskussion um die vernetzte Fertigung konzentrieren sich viele Entscheider reflexartig auf OPC UA als den einzigen universellen Standard für den Maschinendatenaustausch. Doch in der Praxis zeigt sich oft ein anderes Bild: Sobald es um hohe Gerätezahlen, instabile Netzwerkverbindungen oder die reine Übertragung von Telemetriedaten in übergeordnete Systeme geht, stößt die komplexe Client-Server-Architektur klassischer Protokolle an Grenzen. Hier hat sich MQTT (Message Queuing Telemetry Transport) als schlanke, leistungsfähige Alternative etabliert, die ursprünglich gar nicht für den Fabrikboden, sondern für die Pipeline-Überwachung entwickelt wurde. Wer heute eine Digitalisierungsstrategie plant, muss verstehen, wo dieses Protokoll seine Stärken ausspielt und wo es lediglich eine Ergänzung darstellt.

Warum MQTT in der Fertigungshalle Fuß fasst

Die klassische Automatisierungspyramide löst sich zunehmend auf. Daten müssen nicht mehr zwingend Schritt für Schritt von der Feldebene über die SPS bis ins MES oder ERP klettern. Oft ist der direkte Weg von einem Sensor oder einer Steuerung in eine Datenbank oder Cloud-Anwendung gewünscht, etwa für Condition Monitoring oder Predictive Maintenance. Hier ist MQTT oft das Mittel der Wahl, da es extrem leichtgewichtig ist. Im Gegensatz zu HTTP-Anfragen, die jedes Mal einen neuen Verbindungsausbau erfordern, hält MQTT eine stehende, ressourcenschonende Verbindung offen.

Das entscheidende Merkmal ist der Wechsel vom Anfrage-Antwort-Prinzip (Polling) hin zum Publish-Subscribe-Modell. Eine Maschine sendet Daten nicht an einen spezifischen Empfänger, sondern veröffentlicht sie unter einem bestimmten Thema (Topic) an einen zentralen Broker. Wer die Daten benötigt – sei es das Dashboard in der Instandhaltung oder der Data Lake der Qualitätssicherung – abonniert dieses Thema einfach. Das reduziert die Komplexität der Schnittstellen drastisch, da Sender und Empfänger nichts voneinander wissen müssen. Diese Entkopplung ist der Hauptgrund, warum Fertigungsplaner bei neuen IIoT-Architekturen auf dieses Protokoll setzen.

Wann sich das Protokoll technisch lohnt

Nicht für jede Anwendung ist MQTT die richtige Antwort. Die Entscheidung für oder gegen dieses Protokoll hängt stark von den physikalischen Gegebenheiten und den Zielen der Datenerfassung ab. Sie sollten MQTT vor allem dann in Betracht ziehen, wenn Sie viele kleine Datenpakete von vielen Quellen einsammeln müssen, ohne den operativen Steuerungsprozess zu belasten. Es ist ideal für Telemetriedaten – also Zustandsberichte wie Temperatur, Vibration oder Stückzahlzähler.

Es gibt jedoch klare Abgrenzungen. Wenn Sie harte Echtzeit für die direkte Maschinensteuerung (Motion Control) benötigen, ist MQTT ungeeignet; hier bleiben Feldbussysteme wie PROFINET oder EtherCAT führend. Auch wenn Sie komplexe Datenmodelle mit direkter semantischer Beschreibung benötigen (also: „Was ist diese Variable?“), hat OPC UA von Haus aus Vorteile. MQTT ist „payload agnostic“ – es transportiert den Inhalt, egal ob Text, JSON oder Binärdaten, kümmert sich aber nicht um dessen Interpretation. Die Entscheidung fällt also oft zugunsten von MQTT, wenn Skalierbarkeit und Bandbreiteneffizienz wichtiger sind als semantische Selbstbeschreibung.

Die Rolle des Brokers und der Architektur

Das Herzstück jeder MQTT-Implementierung ist der Broker. Er fungiert als Verkehrsleitstelle. In einer typischen Werkshalle kann dieser Broker entweder lokal auf einem Edge-Gateway laufen, im Rechenzentrum des Unternehmens (On-Premise) oder direkt in der Cloud. Für die Produktionsleitung bedeutet dies eine strategische Entscheidung: Wo sollen die Daten aggregiert werden? Ein lokaler Broker sorgt dafür, dass die Produktion auch bei Internetausfall weiter kommunizieren kann, während ein Cloud-Broker die weltweite Vernetzung mehrerer Standorte vereinfacht.

Die Architektur ermöglicht zudem interessante Puffer-Strategien. Da der Broker die Nachrichten verwaltet, können Clients (Maschinen) kurzzeitig die Verbindung verlieren, ohne dass der Gesamtprozess zusammenbricht. Sobald die Verbindung wieder steht, kann der Broker – je nach Konfiguration – die letzten wichtigen Informationen nachliefern. Dies macht das System deutlich robuster gegen die typischen EMV-Störungen oder WLAN-Schwankungen in einer metallverarbeitenden Umgebung. Doch diese Flexibilität erfordert eine saubere Definition der Dateninhalte.

Datenstruktur und Interoperabilität

Da MQTT den Inhalt der Nachricht (Payload) nicht vorschreibt, obliegt es Ihnen, hier Standards zu setzen. In der Praxis hat sich das JSON-Format durchgesetzt, da es menschenlesbar und von fast allen IT-Systemen verarbeitbar ist. Ein typischer Datensatz könnte Schlüssel-Wert-Paare wie {"temp": 65.4, "status": "active"} enthalten. Das Problem: Ohne klare Vorgaben sendet Maschine A „temp“, Maschine B „temperature“ und Maschine C „t_value“. Das führt zu hohem Integrationsaufwand im Backend.

Um dieses „Babylonische Sprachgewirr“ zu verhindern, greifen viele Betriebe auf Erweiterungen wie Sparkplug B zurück. Dies ist eine Spezifikation, die auf MQTT aufsetzt und genau definiert, wie Topics benannt sein müssen und wie die Nutzdaten strukturiert sind. Sparkplug sorgt dafür, dass sich Geräte beim Broker mit ihren Eigenschaften „vorstellen“. Wenn Sie eine herstellerübergreifende Flotte vernetzen wollen, ist die Einhaltung eines solchen Standards oder einer strikten internen „Topic-Policy“ unerlässlich, um die Daten später überhaupt nutzbar zu machen.

Typische Einsatzszenarien im Maschinenpark

In der betrieblichen Realität sehen wir MQTT häufig im Retrofit-Bereich. Alte Bestandsanlagen, die über keine modernen Ethernet-Schnittstellen verfügen, werden oft mit günstigen IoT-Gateways nachgerüstet. Diese Gateways greifen Signale direkt an der SPS oder über zusätzliche Aufstecksensoren ab und senden diese per MQTT an ein übergeordnetes System. Der Eingriff in die eigentliche Maschinensteuerung bleibt dabei minimal, was das Risiko von Stillständen während der Installation reduziert.

Ein weiteres Szenario ist die Anbindung von mobilen Einheiten, wie fahrerlosen Transportsystemen (FTS) oder intelligenten Werkzeugen. Da diese Geräte sich im WLAN bewegen und Roaming-Abrisse erleben können, profitieren sie massiv vom schlanken Overhead des Protokolls. Die „Retained Messages“-Funktion von MQTT stellt sicher, dass ein Dashboard sofort den letzten bekannten Status eines FTS anzeigt, sobald es sich anmeldet, ohne erst auf das nächste Update warten zu müssen. Solche Use-Cases verdeutlichen die Stärke in dynamischen Umgebungen.

Strategien für die Einführung

Die technische Hürde für MQTT ist niedrig, was verlockend, aber auch gefährlich sein kann. Eine erfolgreiche Einführung beginnt nicht mit der Installation, sondern mit dem Design des „Topic Tree“. Das ist die hierarchische Adressstruktur, unter der Daten abgelegt werden (z. B. Werk1/Halle3/Fräse5/Spindel/Temp). Ist diese Struktur einmal „wild gewachsen“, lässt sie sich später nur schwer korrigieren. Sie müssen vor dem ersten Paket definieren, wie granular Sie trennen wollen: Nach Standort, nach Gewerk oder nach Kostenstelle?

Folgender Ablauf hat sich bewährt:

• Pilotbereich definieren: Starten Sie mit einer unkritischen Anlage, um Erfahrungen mit Latenzen und Datenvolumen zu sammeln.
• Namenskonvention festlegen: Erarbeiten Sie eine verbindliche Struktur für die Topics (Themenbäume), die auch in fünf Jahren noch logisch ist.
• Payload standardisieren: Legen Sie fest, ob Sie JSON, Protobuf oder XML nutzen und welche Einheiten (Celsius vs. Fahrenheit) gelten.
• QoS-Level bestimmen: Entscheiden Sie pro Datenpunkt, wie wichtig er ist (siehe Fehlerquellen).

Fehlerquellen bei der Konfiguration

Ein klassischer Stolperstein ist das Missverständnis der „Quality of Service“ (QoS) Level. MQTT bietet drei Stufen: QoS 0 („Fire and forget“), QoS 1 („At least once“) und QoS 2 („Exactly once“). Viele Ingenieure stellen reflexartig alles auf QoS 2, um „sicherzugehen“. Das erhöht jedoch den Netzwerk-Overhead massiv und verlangsamt den Durchsatz. Für einen Temperaturwert, der sekündlich kommt, reicht QoS 0 völlig aus – fehlt ein Wert, kommt gleich der nächste. Nur für Alarmmeldungen oder Konfigurationsbefehle sind höhere Level sinnvoll.

Ein weiterer Fehler liegt im Umgang mit „Retained Messages“. Wenn eine Nachricht als „retained“ (behalten) markiert ist, speichert der Broker den letzten Wert dauerhaft und sendet ihn jedem neuen Abonnenten sofort zu. Wird dies falsch eingesetzt, können längst behobene Fehlermeldungen als „Geister-Alarme“ wieder auftauchen, sobald ein Dashboard neu startet, obwohl die Maschine längst wieder läuft. Hier muss das Lösch-Verhalten der Nachrichten (Retain-Flag löschen durch leere Nachricht) sauber implementiert sein.

Abstimmungsbedarf zwischen IT und OT

MQTT ist ein TCP/IP-basiertes Protokoll, was es der IT-Abteilung sehr sympathisch macht, aber dennoch Abstimmungsbedarf erzeugt. Standardmäßig nutzt MQTT Port 1883 für unverschlüsselte und Port 8883 für verschlüsselte Kommunikation (TLS). In vielen strikt abgeschotteten Produktionsnetzen sind diese Ports standardmäßig blockiert. Sie müssen frühzeitig mit der IT-Sicherheit klären, dass diese Ports für die Gateways freigeschaltet werden – idealerweise nur ausgehend zum Broker.

Klären Sie zudem diese Punkte:

• Authentifizierung: Reicht Benutzername/Passwort oder sind Client-Zertifikate (mTLS) erforderlich? Letzteres ist sicherer, aber aufwändiger im Management.
• Broker-Hoheit: Wer betreibt den Broker? Die IT (im Serverraum) oder die OT (auf einem Industrie-PC)? Die Antwort entscheidet über Reaktionszeiten bei Ausfällen.
• Update-Management: Wie werden die MQTT-Clients auf den Maschinen gepatcht, wenn Sicherheitslücken bekannt werden?

Sicherheitskonzepte und Netzwerkintegration

Sicherheit wird bei MQTT oft als reines IT-Thema abgetan, ist aber für die Betriebssicherheit kritisch. Da MQTT-Clients die Verbindung von innen nach außen zum Broker aufbauen, müssen oft keine eingehenden Firewall-Ports an der Maschine geöffnet werden. Das ist ein immenser Sicherheitsvorteil gegenüber Server-basierten Protokollen, die auf Anfragen warten. Dennoch: Ein ungesicherter Broker im Netzwerk ist wie ein offenes Buch. Jeder, der Zugriff hat, kann nicht nur Daten mitlesen, sondern – je nach Berechtigung – auch falsche Steuerbefehle in das Netzwerk injizieren.

Daher ist Transport Layer Security (TLS) Pflicht, nicht Kür. Die Verschlüsselung verhindert Man-in-the-Middle-Angriffe. Darüber hinaus sollten Access Control Lists (ACLs) auf dem Broker konfiguriert werden. Damit legen Sie fest, dass die Säge nur in das Topic Säge/Status schreiben, aber nicht das Topic Ofen/Steuerung lesen darf. Diese feingranulare Rechtevergabe ist der Schlüssel, um auch in offenen MQTT-Architekturen die Integrität der Produktionsdaten zu gewährleisten.

Fazit und Perspektive

MQTT ist kein Allheilmittel, das etablierte Feldbusse oder OPC UA vollständig ersetzt. Es ist vielmehr der agile Logistiker für Daten, der die Lücke zwischen der starren Steuerungsebene und der flexiblen IT-Welt schließt. Wer die Einführung mit einer sauberen Topic-Struktur und einem klaren Sicherheitskonzept plant, gewinnt eine hochskalierbare Infrastruktur, die auch bei Tausenden von Datenpunkten stabil bleibt. Die Koexistenz von OPC UA (für komplexe M2M-Kommunikation) und MQTT (für Cloud/Data-Uplinks) wird in den kommenden Jahren der De-facto-Standard in modernen Fertigungsumgebungen sein.