Warum sich MQTT im industriellen IoT durchgesetzt hat
Das industrielle Internet der Dinge (IoT) generiert täglich Millionen von Messwerten: Sensoren, die minütlich Daten melden, Steuerungen, die sekündlich Statusmeldungen senden, und Zähler, die stündliche Zählerstände übermitteln. Diese Datenströme müssen zuverlässig, ressourcenschonend und sicher übertragen werden.
MQTT erfüllt genau diese Anforderungen:
- Ultraleicht — Header mit einer Größe von 2 bis 5 Byte. HTTP/REST erzeugt Hunderte von Byte an Headern für eine Nutzlast von nur wenigen Byte.
- Persistente Verbindung — das Gateway stellt einmalig eine Verbindung zum Broker her und hält diese aufrecht. Kein TCP-Handshake bei jeder Nachricht.
- Publish/Subscribe — mehrere Abonnenten (Cloud-Überwachung, ERP, BI) können dieselben Daten empfangen, ohne dass das Gateway davon Kenntnis hat.
- Konfigurierbare QoS – je nach Kritikalität der Daten.
- Ausfallsicherheit – Nachrichten werden gespeichert, wenn der Client vorübergehend nicht erreichbar ist (Retain, Persistent Session).
Industrielle MQTT-Architektur
MQTT-Themen: Struktur und bewährte Vorgehensweisen
Ein MQTT-Topic ist eine hierarchische Kette, die durch / getrennt ist:
eziwan/{site_id}/{Ausrüstung}/{Variable}
Exemples :
eziwan/Pumpstation-01/Steuerung/Förderdruck
eziwan/site-pompage-01/compteur/energie_kwh
eziwan/batiment-paris/cvc/temperature_zone_a
Bewährte Praktiken bei der Benennung:
- Fügen Sie immer die Standort-ID hinzu, um nach Standorten filtern zu können.
- Trennen Sie die Datentypen (Messwert, Status, Alarm, Befehl) in separate Topics auf.
- Verwenden Sie lesbare Namen, keine undurchsichtigen Codes.
- Vermeiden Sie zu weit gefasste Themen (
eziwan/#) für Abonnements in der Produktion.
QoS-Stufen: Welche Wahl trifft die Industrie?
| QoS | Garantie | Overhead | Empfohlene Nutzung |
|---|---|---|---|
| 0 | Höchstens einmal (Best-Effort) | Minimal | Häufige Messungen (1/s), Verlust zulässig |
| 1 | Mindestens einmal (mit Bestätigung) | Gering | Standardüberwachung, Warnmeldungen |
| 2 | Genau einmal (4 Austauschvorgänge) | Mittel | Befehle, kritische Daten |
Für die typische industrielle IoT-Überwachung (Messungen alle 5 bis 60 Sekunden) ist QoS 1 der richtige Kompromiss: ausreichende Zuverlässigkeit, akzeptabler Overhead.
MQTT vs. HTTP für das IoT: Ein Vergleich
| Kriterium | MQTT | HTTP/REST |
|---|---|---|
| Modell | Publish/Subscribe | Anfrage/Antwort |
| Overhead-Größe | 2–5 Byte | 200–400 Byte |
| Verbindung | Persistent | Pro Anfrage (oder Keep-Alive) |
| Daten-Push | Nativ (Subscribe) | Polling oder WebSocket |
| Latenz | < 50 ms | 100–500 ms |
| Mehrere Abonnenten | Nativ | Webhooks/externe Warteschlangen |
| Für IoT mit geringer Bandbreite geeignet | ★★★★★ | ★★ |
Der Eziwan-Ansatz
Das Eziwan Gateway implementiert einen MQTT-Client, der die erfassten Modbus-/OPC-UA-Daten an den MQTT-Broker der Eziwan Cloud übermittelt. Die Topics werden entsprechend der Konfiguration der jeweiligen Geräte automatisch generiert. Die Übertragung erfolgt sicher über TLS mit Authentifizierung per Client-Zertifikat – es werden niemals ungesicherte MQTT-Verbindungen hergestellt.
Weitere Informationen: Modbus-Cloud, industrielles IoT-Gateway und Überwachung von Remote-Standorten.