Für Ingenieure eingebetteter Systeme wirkte das Internet der Dinge (IoT) anfänglich oft nur wie eine simple Erweiterung bestehender Mikrocontroller-Designs um eine Funkkomponente. Doch diese Sichtweise greift zu kurz. IoT fungiert als technologisches Bindeglied, das dezentrale Endknoten mit komplexen Computersystemen vereint.
In der Praxis ermöglicht dies Szenarien, die weit über das bloße Senden von Daten hinausgehen: Fabriken erkennen drohende Geräteausfälle präventiv, bevor Bänder stillstehen, und Logistikunternehmen überwachen den exakten Standort jeder einzelnen Sendung in Echtzeit. Das übergeordnete Ziel ist ein neuer Grad der Automatisierung, der nicht nur Prozesse effizienter gestaltet, sondern auch dem Fachkräftemangel entgegenwirkt, indem Maschinen intelligent miteinander agieren und Wartungsbedarfe selbstständig melden.
Technologische Abgrenzung: MQTT vs. HTTP
Um die Vorteile moderner IoT-Kommunikation zu verstehen, lohnt sich der Vergleich mit dem bekannten HTTP-Standard. Während HTTP für das Web entwickelt wurde – also für das Laden großer Dateien, Surfen und Videostreaming – verfolgt MQTT (Message Queuing Telemetry Transport) einen anderen Ansatz. Es ist spezifisch auf die Machine-to-Machine-Kommunikation (M2M) ausgelegt.
Bei HTTP werden bei jedem Abruf viele Metadaten übertragen, was bei instabilen Verbindungen oder kleinen Datenpaketen ineffizient ist. MQTT hingegen ist extrem schlank. Das Protokoll minimiert den Daten-Overhead, was besonders relevant ist, wenn Bandbreite teuer oder die Verbindung schlecht ist. Gerade wenn spezialisierte SIM Karten von M2M für IoT Netzwerke in mobilen Szenarien zum Einsatz kommen, sorgt diese Effizienz dafür, dass Datenvolumen gespart und Batterielaufzeiten verlängert werden. Zudem entfällt das bei großen Dateiübertragungen nötige „Resuming“ (Wiederaufnehmen), da MQTT-Nachrichten meist nur wenige Bytes umfassen und entweder ganz oder gar nicht ankommen.
Das Architekturmodell: Publish/Subscribe
Klassische Steuerungssysteme arbeiten oft mit direkten Abfragen: Eine zentrale Einheit fragt einen Sensor nach dem aktuellen Wert („Polling“). Dieses Vorgehen erzeugt unnötigen Netzwerktrausch, wenn sich Werte gar nicht geändert haben. MQTT löst dies durch eine Publish/Subscribe-Architektur, bei der Sender (Publisher) und Empfänger (Subscriber) voneinander entkoppelt sind.
Ein zentraler Verteiler, der sogenannte „Broker“, nimmt Nachrichten entgegen und leitet sie an alle interessierten Parteien weiter. Der entscheidende Vorteil ist das Prinzip „Report by Exception“: Ein Sensor sendet nur dann Daten, wenn sich ein Wert tatsächlich ändert (z. B. Temperatur sinkt um ein Grad). Solange keine neue Nachricht kommt, gilt der alte Zustand. Dies reduziert die Netzwerklast drastisch. Gleichzeitig ermöglicht das Modell eine hohe Skalierbarkeit, da eine einzige gesendete Nachricht vom Broker an beliebig viele Empfänger – etwa eine Datenbank, ein Analyse-Dashboard und eine Steuerungssoftware – gleichzeitig verteilt werden kann, ohne dass der Sensor mehrfach belastet wird.
Praxisbeispiel: Optimierung der User Experience im Carsharing
Wie kritisch die Wahl des Protokolls ist, zeigt ein Blick auf die Anfänge des Carsharings. Frühere Lösungen setzten auf eine Kombination aus SMS (zum „Aufwecken“ des Autos) und HTTP. Dies führte zu hohen Latenzen; Nutzer mussten oft bis zu 30 Sekunden warten, bis sich das Fahrzeug öffnete – eine Ewigkeit bei Regen oder Kälte. Zudem ist SMS kein garantierter Zustellkanal.
Durch den Wechsel auf MQTT konnte eine permanente, ressourcenschonende Verbindung gehalten werden. Die Reaktionszeit sank von 30 Sekunden auf unter eine Sekunde, was die Akzeptanz des Dienstes massiv erhöhte. Dennoch haben auch klassische Protokolle weiterhin ihren Platz: In hybriden Modellen wird MQTT genutzt, um den Befehl für ein Software-Update zu senden (die „Notification“), während der eigentliche Download der großen Update-Datei anschließend über HTTP erfolgt. Man nutzt also jede Technologie dort, wo sie ihre Stärken hat.
Sicherstellung der Datenqualität und Zuverlässigkeit
Im industriellen Kontext ist Datenverlust keine Option. MQTT bietet hierfür das Konzept des „Quality of Service“ (QoS) an, das in drei Stufen regelt, wie verbindlich eine Nachricht zugestellt wird:
- QoS 0 (At most once): Die Nachricht wird gesendet, ohne auf eine Bestätigung zu warten („Fire and forget“).
- QoS 1 (At least once): Der Empfang wird bestätigt. Im Zweifel wird die Nachricht erneut gesendet, was zu Duplikaten führen kann.
- QoS 2 (Exactly once): Durch einen mehrstufigen Handshake wird garantiert, dass die Nachricht exakt einmal ankommt – die sicherste, aber auch aufwendigste Methode.
Zusätzlich verhindern Mechanismen wie „Store and Forward“ Datenlücken: Ist ein Empfänger kurzzeitig offline, speichert der Broker wichtige Nachrichten zwischen. Ein weiteres Sicherheitsnetz ist das „Last Will and Testament“. Meldet sich ein Gerät nicht ordnungsgemäß ab (z. B. durch Batterieausfall), sendet der Broker automatisch eine vordefinierte Abschiedsnachricht an alle Teilnehmer. So erkennt das Gesamtsystem sofort, wenn ein Sensor ungeplant ausfällt, anstatt fälschlicherweise von gleichbleibenden Werten auszugehen.
Integration von IT und OT (Operational Technology)
Eine der größten Hürden in der Industrie 4.0 ist die Verschmelzung von Operational Technology (OT), also der Welt der Maschinen und Roboter, mit der klassischen IT-Infrastruktur. Historisch waren OT-Protokolle nicht für die Cloud-Kommunikation oder moderne Sicherheitsstandards ausgelegt.
MQTT fungiert hier als Brückentechnologie, oft organisiert durch das Konzept des Unified Namespace (UNS). Dabei werden MQTT-Topics (die „Betreffzeilen“ der Nachrichten) so strukturiert, dass sie die Hierarchie des Unternehmens abbilden (z. B. Standort/Linie/Maschine/Sensor). Dies macht Daten adressierbar und auffindbar, ohne dass der Konsument wissen muss, welches physische Kabel am Sensor hängt. Sicherheitstechnisch ermöglicht der Broker eine zentrale Verwaltung: Anstatt auf hunderten Feldgeräten einzeln Benutzer zu pflegen, steuern Sie zentral am Broker via Access Control Lists (ACLs) und Zertifikaten, wer welche Daten schreiben oder lesen darf.
Backend-Integration und Datenverwertung
Am Ende der Kette müssen die gesammelten Daten in Systemen landen, die sie auswerten können. Hierbei sollten Sie vermeiden, eigene komplexe Adapter („Glue Code“) zu schreiben. Professionelle MQTT-Broker bieten native Extensions für gängige Enterprise-Systeme wie Apache Kafka, SQL-Datenbanken (z. B. PostgreSQL) oder Cloud-Dienste von Amazon, Google und Microsoft.
Der Broker übernimmt dabei die Rolle des Entkopplers: Er wandelt die eingehenden MQTT-Nachrichten in das Format der Zieldatenbank oder des Streaming-Dienstes um. Dies verhindert einen Vendor-Lock-in, da sowohl die Sensoren als auch die Backend-Systeme austauschbar bleiben, solange sie den offenen MQTT-Standard sprechen. Sie binden sich nicht an einen proprietären Hardware-Hersteller, sondern behalten die Hoheit über Ihre Datenarchitektur.