IoT-Dossier

Modbus RTU zu MQTT – Konvertierung und industrielle Bridge

Modbus RTU in MQTT-JSON konvertieren: QoS 0/1/2, TLS, AWS IoT Core, Azure IoT Hub, Mosquitto, Sparkplug B. Architektur, Konfiguration und Sicherheit.

Kurz gesagt
Ein Modbus-RTU-zu-MQTT-Brücke überprüft Ihre Geräte RS485/RS232 über Modbus-Polling, verpackt jeden Messwert in eine Nachricht JSON MQTT mit Zeitstempel, konfigurierbarer QoS und Verschlüsselung TLS 1.3, und veröffentlicht die Daten anschließend an den MQTT-Broker Ihrer Wahl (AWS IoT Core, Azure, HiveMQ, Mosquitto oder Eziwan). Die Konvertierung ist vollständig ohne Programmierung konfigurierbar.

Warum Modbus RTU in MQTT konvertieren?

Modbus RTU ist die Sprache der Maschine. MQTT ist die Sprache der Cloud. Die Modbus-RTU-→-MQTT-Brücke fungiert als Übersetzer zwischen diesen beiden Welten: Sie ermöglicht es Ihren älteren Industriegeräten, mit modernen IoT-Plattformen zu kommunizieren, ohne dass Änderungen an der bestehenden Anlage erforderlich sind.

Vorteile von MQTT für die industrielle Datenübertragung:

  • Geringer Datenverbrauch: Mindestens 2 Byte Header, ideal für 4G und kostenintensive Verbindungen
  • Publish/Subscribe: Entkopplung zwischen Produktion (Gateway) und Verbrauch (Dashboard, API)
  • Persistente Sitzung: Nachrichten werden bei Netzwerkunterbrechungen in eine Warteschlange gestellt
  • Konfigurierbare QoS: Auf jeden Datentyp zugeschnittene Zustellungsgarantie
  • Natives TLS: Verschlüsselung und Authentifizierung ohne zusätzliche Anwendungsschicht

Architektur der Modbus-RTU-→-MQTT-Brücke

Die Brücke arbeitet in zwei getrennten und voneinander unabhängigen Phasen:

Phase 1 – Modbus-RTU-Erfassung (Feldseite) Das Gateway fungiert als Modbus-Master. Es sendet Leseanfragen (FC01/02/03/04) gemäß einem konfigurierbaren Abfrageplan an die RS485-Slaves. Jede Antwort wird lokal decodiert, skaliert und mit einem Zeitstempel versehen.

Phase 2 – MQTT-Veröffentlichung (Cloud-seitig) Die dekodierten Werte werden in JSON-Nachrichten verpackt und an den MQTT-Broker gesendet. Ist die Verbindung nicht verfügbar, werden die Nachrichten lokal zwischengespeichert (72 Stunden) und bei Wiederherstellung der Verbindung mit ihrem ursprünglichen Zeitstempel erneut gesendet.

RS485-Bus-Gateway Eziwan MQTT-Broker
────────── ────────────────── ────────────
Esclave 1 ──┐ ┌── Modbus RTU master AWS IoT Core
Esclave 2 ──┤── RS485 ──►│ Polling FC03/FC04 MQTT Azure IoT Hub
Esclave 3 ──┤ │ Decode + Scale ──TLS► HiveMQ
Esclave n ──┘ └── JSON builder Mosquitto
Buffer 72h Eziwan Cloud

Struktur der MQTT-Topics für Modbus RTU

Die Organisation der MQTT-Topics ist entscheidend für die Wartbarkeit und die Integration:

Empfohlene Konvention:

{Website}/{Bereich}/{Ausstattung}/{Tag}

Beispiele:

usine/atelier_a/variateur_01/frequence_hz
usine/atelier_a/variateur_01/courant_a
usine/tgbt/compteur_principale/puissance_active_kw
usine/tgbt/compteur_principale/energie_kwh

Metadaten-Themen (Sparkplug B):

spBv1.0/fabrik/NBIRTH/Gateway_01 ← Anmeldeaufforderung
spBv1.0/Fabrik/NDATA/Gateway_01 ← Prozessdaten
spBv1.0/Fabrik/NDEATH/Gateway_01 ← Abmelden (LWT)

MQTT-kompatible Broker

Das Eziwan-Gateway ist mit den wichtigsten MQTT-Brokern auf dem Markt kompatibel:

BrokerHostingProtokollAnwendungsfälle
AWS IoT CoreAWS-CloudMQTT TLSAWS-Integration (Lambda, S3, Timestream)
Azure IoT HubAzure-CloudMQTT / AMQPAzure-Integration (Stream Analytics, Cosmos DB)
HiveMQ CloudManaged CloudMQTT 5.0 + TLSSparkplug B, UNS, Multi-Broker
MosquittoSelbst gehostetMQTT 3.1.1Lokales SCADA, minimale Latenz
Eziwan CloudManaged CloudMQTT TLSSchlüsselfertig, integriertes Dashboard

Verwaltung von Verbindungsabbrüchen und Pufferung

Industrielle Netzwerke (4G, WLAN in rauen Umgebungen) sind anfällig für Verbindungsunterbrechungen. Die Modbus-RTU-→-MQTT-Bridge bewältigt dies durch:

  • Last Will Testament (LWT): Automatische Nachricht, die vom Broker gesendet wird, wenn die Verbindung zum Gateway unterbrochen wird
  • Persistente Sitzung: Der Broker behält die Abonnements und die ausstehenden QoS-1/2-Nachrichten bei
  • Lokaler Puffer: Das Gateway speichert die Messwerte während der Unterbrechung im Flash-Speicher
  • Neusynchronisierung: Bei der Wiederherstellung der Verbindung werden die Nachrichten in chronologischer Reihenfolge erneut übertragen

Dieser Mechanismus gewährleistet keinen Datenverlust, selbst bei längeren Netzwerkausfällen – was für Anwendungen zur Energieerfassung oder Produktionsüberwachung von entscheidender Bedeutung ist.

Integration mit Cloud-TSDBs

MQTT-Daten werden in der Regel in einer Zeitreihendatenbank (Time Series Database) gespeichert:

  • InfluxDB: Open Source, hervorragend geeignet für industrielle Metriken
  • AWS Timestream: serverlos, in AWS IoT Core integriert
  • Azure Data Explorer: hohe Leistung bei großen Datenmengen
  • TimescaleDB: erweiterte PostgreSQL-Version, natives SQL
  • Eziwan Storage: Speicher inklusive, konfigurierbare Aufbewahrungsdauer

Von der TSDB aus werden die Daten in die Grafana-Dashboards, Leistungsberichte und Modelle zur vorausschauenden Wartung eingespeist.

Häufig gestellte Fragen

Das könnte Sie auch interessieren