MQTT und Modbus beantworten in Industrieanlagen meist unterschiedliche Fragen. Modbus liest Datenbereiche eines Geräts; MQTT verteilt Datensätze eines Datensammlers. Sie müssen keine Alternativen sein: Ein Gateway verbindet beide als getrennte Ebenen eines Datenflusses.
Jedem Protokoll die richtige Aufgabe geben
Ein Modbus-Client fordert bestimmte Daten an und erhält eine Geräteantwort. Ein MQTT-Herausgeber sendet eine Nachricht auf einem Topic, der Broker verteilt sie an Abonnenten. Die Verbindung muss häufig mehr leisten als Bytes transportieren: Sie definiert die Bedeutung des rohen Feldwerts.
Ob ein Registerwert 184 für 18,4 °C steht, hängt von der Gerätedokumentation ab. Der Datensammler ergänzt geprüfte Skalierung, Einheiten und Qualität. Ohne dokumentierte Umwandlung könnten nachgelagerte Dienste dasselbe Register unterschiedlich interpretieren.
Verantwortlichkeiten je Ebene
| Frage | Gerät / Modbus | Nachrichten / MQTT |
|---|---|---|
| Woher kommt der Wert? | Register- und Gerätezuordnung | Topic und Herausgeberidentität |
| Wie wird die Einheit verstanden? | Herstellerdefinition | Datenvereinbarung der Nutzdaten |
| Was passiert bei Trennung? | Lesezeitüberschreitung und Qualität | Sitzung, Puffer und Nachübertragung |
| Wie werden Wiederholungen erkannt? | Mess-/Ereignismodell | Ereigniskennung der Anwendung |
Die Trennung verbessert die Diagnose. Eine fehlende Brokernachricht beweist keinen Modbus-Sensorfehler. Prüfen Sie serielle Verbindung, Datensammler, Brokerverbindung und Speicherdienst getrennt. Jede Ebene benötigt einen aussagekräftigen Hinweis auf ihren letzten erfolgreichen Vorgang.
Beispielhafter kombinierter Datenfluss
Ein Kühlraum-Messmodul wird über Modbus RTU ausgelesen. Das Gateway rechnet in die vereinbarte Einheit um, ergänzt Quellkennung und Zeit und veröffentlicht den Datensatz über MQTT. Die Anwendung prüft ihn und speichert die Historie. Das Dashboard zeigt daraus einen Verlauf.
Die serielle Erfassung kann bei ausgefallenem übergeordnetem Netzwerk weiterlaufen. Das Gateway bewahrt Datensätze in einem begrenzten Puffer. Bei Wiederverbindung behalten sie ihre ursprünglichen Zeitstempel und Kennungen. Der Server ordnet sie historisch ein, statt sie als aktuelle Messungen anzuzeigen. Wiederholte Zustellung erzeugt keine zweite Beobachtung.
Weshalb ein Protokollkonverter nicht genügt
Eine fehlgeschlagene Modbus-Abfrage, ein vom Gerät gemeldeter Sensorfehler und ein unerreichbarer Broker sind verschiedene Bedingungen. Werden alle zu Null oder einem undifferenzierten Nullwert umgewandelt, wird die Fehlersuche schwierig. Bewahren Sie Qualitätskategorie, Zeitpunkt der letzten gültigen Messung und Quellzustand, soweit verfügbar.
Auch die QoS-Auswahl garantiert keinen einmaligen nachgelagerten Datenbankschreibvorgang. Nachrichtenannahme, Datensatzverarbeitung und Alarmauswertung bilden getrennte Grenzen. Die MQTT-Zustellregeln von OASIS sind nicht mit Transaktions- und Deduplizierungsanforderungen der Anwendung zu verwechseln.
Beide Verbindungen prüfen
Bei der Bestandsaufnahme werden Registerzuordnung, Ereignissignale gegenüber periodischen Beobachtungen, tolerierbarer Verlust, Uhrenverwaltung und Topic-Rechte geklärt. Ebenso wichtig sind endlicher Gatewayspeicher und Verhalten bei voller Kapazität. Mehr Puffer rekonstruiert keine nie erfassten Messungen.
Unterbrechen Sie bei der Abnahme sowohl Gerät–Gateway als auch Gateway–Server. Dokumentieren Sie erwartete Qualitätszustände, Nachübertragungsreihenfolge und Duplikatbehandlung. Prüfen Sie auch einen ungültigen Gerätewert und eine fehlerhafte Nachricht. Das Ergebnis ist ein erklärbarer Datenfluss mit sichtbaren Grenzen, nicht bloß ein verbunden wirkendes Protokollpaar.
Die Brückenvereinbarung vor den Topics schreiben
Ordnen Sie im Kühlraumbeispiel jedes normalisierte Feld seinem Ursprung zu. Temperatur stammt aus einer dokumentierten Gerätegröße, Einheit aus der geprüften Umrechnung und Anlagenkennung aus dem Konfigurationsverzeichnis. Die Zeit kann vom Gerät oder vom Lesezeitpunkt des Datensammlers stammen. Diese verschiedenen Belege dürfen nicht in einem mehrdeutigen, als live bezeichneten Zeitstempel verschmelzen.
Das Gateway benötigt außerdem eine Regel zur Vergabe von Beobachtungskennungen. Eine neue Abfrage kann eine neue Beobachtung erzeugen, obwohl sich der Zahlenwert nicht ändert. Erneutes Senden einer früheren Beobachtung nach einer Unterbrechung behält dagegen deren Kennung. Sonst unterscheidet die Anwendung unveränderte Temperatur nicht zuverlässig von doppelter Zustellung. Dokumentieren Sie, ob gleiche Folgewerte aufbewahrt, zusammengefasst oder unterdrückt werden. Die Entscheidung beeinflusst Historie und Aktualitätskontrolle.
Behandeln Sie Änderungen der Zuordnung als versioniertes Ereignis. Korrigiert ein Techniker den Skalierungsfaktor, müssen zukünftige Nutzdaten und historische Aufzeichnungen interpretierbar bleiben. Den neuen Faktor stillschweigend auf gemischte rohe und bereits normalisierte Werte anzuwenden kann einen Bericht verfälschen. Halten Sie die Umwandlungsgrenze ausdrücklich fest und entscheiden Sie, ob historische Korrekturen einen revidierten Datensatz oder eine gesondert dokumentierte Neuberechnung erzeugen.
Eine Unterbrechungsprüfung auf beiden Seiten
Trennen Sie zunächst die Modbus-Quelle bei verfügbarer Brokerverbindung. Erwartet wird eine Feldquellenstörung, keine vermeintlich gesunde aktuelle Messung allein wegen weiterhin eintreffender Nachrichten. Stellen Sie danach die Feldverbindung wieder her und trennen Sie nur den Brokerweg. Wenn die gewählte Hardware es unterstützt, kann lokal weiter erfasst werden. Historische Beobachtungen müssen später mit ursprünglicher Zeit und Qualität eintreffen.
Unterbrechen Sie zuletzt eine Bestätigung, nachdem die Anwendung bereits gespeichert hat. Die Nachübertragung darf weder eine zweite Probe noch eine unbegrenzte Folge wiederholter Alarme erzeugen. Nehmen Sie fehlerhafte Nutzdaten und Messqualitätsfehler in denselben Abnahmeplan auf; keiner darf zu einer unerklärten Null im Trend werden. Dokumentieren Sie das Ergebnis an Gateway, Empfänger und Bildschirm, damit spätere Wartende die gestörte Übergabe erkennen.
Die Übung zeigt, warum Protokollwahl nur ein Teil der Integration ist. Zum brauchbaren Ergebnis gehören Gerätezuordnung, Beispielnutzdaten, Identitäts- und Qualitätsregeln, Topic-Rechte und Wiederherstellungsverhalten. Teilen Sie diese Unterlagen bei der Besprechung einer Brücke zwischen vorhandenen Feldgeräten und Überwachungsanwendung. Ein Konverter allein liefert noch kein vollständiges Betriebsmodell.