Worauf Sie bei einem industriellen MQTT-Broker achten sollten

Ein industrieller MQTT-Broker steht im Zentrum Ihrer Werksdaten: Jedes Gateway veröffentlicht hinein, und jedes SCADA-System, MES, jeder Historian und jedes Dashboard liest daraus. In modernen Industrie-4.0-Architekturen bildet er den Unified Namespace (UNS), dessen Topic-Struktur der ISA-95-Hierarchie folgt: Unternehmen → Standort → Bereich → Linie → Zelle, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. In diesem Leitfaden erfahren Sie, welche Fähigkeiten einen Broker, der den Fabrikalltag übersteht, von einem unterscheiden, der lediglich Protokolltests besteht, und Sie führen ein kurzes Python-Skript aus, das die wichtigsten Verhaltensweisen an jedem Broker prüft, den Sie evaluieren.

Warum der industrielle Einsatz die Anforderungen verändert

Jeder standardkonforme Broker kann eine Nachricht von einem Publisher an einen Subscriber weiterleiten. In einer Consumer-IoT-App reicht das oft. Im Werk transportiert der Broker mehr als Nachrichten. Er transportiert Zustand: welche Maschinen online sind, den aktuellen Wert jedes Tags und ob ein Messwert frisch oder veraltet ist. Bediener treffen auf Basis dieses Zustands Entscheidungen, und in manchen Architekturen lösen SCADA-Systeme daraus Alarme aus.

Industrieller Datenverkehr sieht zudem anders aus. Tausende Tags ändern sich in ungleichmäßigen Raten, eine ganze Linie kann sich nach einer kurzen Netzwerkstörung gleichzeitig neu verbinden, und Payloads können Sparkplug-B-Protobuf statt lesbarem JSON sein. Clients laufen jahrelang auf Gateways, die niemand anfassen möchte. Ein Broker, der für ein Hobbyprojekt genügt, kann unter diesen Bedingungen ins Straucheln geraten. Wenn die Rolle des Brokers für Sie neu ist, beginnen Sie mit was ein MQTT-Broker ist.

Kernfähigkeiten eines industriellen MQTT-Brokers

Sparkplug-Unterstützung

Sparkplug B definiert Topic-Struktur, Birth- und Death-Zertifikate sowie eine Protobuf-Payload für industrielles MQTT. Streng genommen muss der Broker Sparkplug nicht verstehen: Es ist eine clientseitige Spezifikation, und jeder MQTT-3.1.1-Broker mit Unterstützung für Retained Messages, QoS und Wills kann es transportieren. In der Praxis spart ein Broker, der Sparkplug-Payloads dekodieren kann, jedoch Stunden. Bei der Inbetriebnahme möchten Sie Temperature = 72.4 sehen statt eines Binärblocks. Lesen Sie unseren Leitfaden zur Sparkplug-B-Payload, um zu verstehen, was darin steckt.

Noch nützlicher ist das Republishing. Sparkplug-Topics wie spBv1.0/factory1/DDATA/line1/cnc1 sind kompakt, aber für IT-Konsumenten wenig zugänglich. Ein Broker, der diese Metriken in ISA-95-Topics wie connectmq/factory1/production/line1/cnc1/telemetry erneut veröffentlichen kann, ermöglicht es Sparkplug-nativem SCADA und JSON-orientierten Geschäftsanwendungen, dieselben Daten zu nutzen. Für den UNS bedeutet das: Die Edge spricht Sparkplug, und der Broker stellt dieselben Daten zusätzlich entlang der ISA-95-Ebenen bereit. Das Zusammenspiel beider Modelle behandelt Sparkplug B und der Unified Namespace.

Retained State und Sessions

Ein UNS funktioniert nur, wenn ein Dashboard, das um 9:00 Uhr startet, den Zustand jeder Maschine um 9:00 Uhr sieht und nicht erst nach deren nächster Änderung. Genau das leisten Retained Messages. Persistente Sessions mit einer sinnvollen Session Expiry schützen vor dem anderen häufigen Fehler: Ein Gateway verbindet sich nach einem kurzen Netzwerkausfall neu und verpasst alles, was in der Zwischenzeit auf seinen Abonnements veröffentlicht wurde. In Sparkplug-Systemen stützt sich die Primary Host Application auf diese Mechanismen zusammen mit Death-Zertifikaten, um den Zustand der Edge Nodes zu verfolgen.

Sicherheit, die zur OT-Realität passt

Gateways sollten sich mit eigenen Zugangsdaten authentifizieren, per TLS verbinden und gesperrt werden, wenn jemand die Anmeldung mit falschen Passwörtern bombardiert. An Zugangsdaten gebundene Client-IDs verhindern, dass sich ein Gerät als ein anderes ausgibt oder es durch Wiederverwendung seiner ID aus der Verbindung wirft. Der Broker sollte außerdem begrenzen, wie viel ein einzelner Client veröffentlichen darf, damit ein falsch konfiguriertes Gateway, das jede Millisekunde einen Tag sendet, den Dienst für den Rest des Werks nicht beeinträchtigt. Diese Anforderungen entsprechen dem, was IEC 62443 für Zonen und Conduits vorsieht, und helfen bei Nachweisen im Rahmen von NIS2.

Transparenz für die Menschen, die das System in Betrieb nehmen

Die am meisten unterschätzte Fähigkeit eines Brokers ist ein guter Einblick in ihn. Wenn ein Automatisierungstechniker ein neues Gateway anschließt, lautet die erste Frage immer: „Kommen die Daten an, und landen sie an der richtigen Stelle?" Ein Live-Topic-Explorer, eine Ansicht der verbundenen Clients und ein Topic für den Verbindungsstatus beantworten das in Sekunden. Schwellwert-Alarme machen den Broker von einer reinen Leitung zu einem einfachen Überwachungswerkzeug für Werte wie Temperaturgrenzen oder den Zustand von Gateways.

Verfügbarkeit und Betriebsmodell

Fragen Sie, wer den Broker patcht, wer Zertifikate erneuert, wer Festplatte und Speicher überwacht und wer um 3 Uhr nachts angerufen wird. Ein selbst betriebener Broker bietet volle Kontrolle, macht das Werksteam aber für einen aus dem Internet erreichbaren Server verantwortlich. Ein verwalteter MQTT-Broker verlagert diese Arbeit zum Anbieter. Wie auch immer Sie sich entscheiden: Planen Sie, wie sich Clients bei einem Broker-Neustart verhalten, also Neuverbindung mit Backoff, Wiederaufnahme der Sessions und erneutes Veröffentlichen von Births oder Retained State, wo nötig.

Testen Sie jeden industriellen MQTT-Broker selbst

Funktionslisten sind schnell geschrieben. Dieses MQTT-5-Skript prüft vier Verhaltensweisen, die im Werk zählen: Retained-Zustellung, Session-Wiederaufnahme, Last Will und Reason Codes. Führen Sie es zuerst gegen den öffentlichen MQTT-Broker aus, dann gegen jeden Broker, den Sie evaluieren.

import time
import uuid
import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes

HOST, PORT = "broker.connectmq.com", 1883
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1"

def make_client(cid):
    return mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                       client_id=cid, protocol=mqtt.MQTTv5)

def session_props(seconds):
    p = Properties(PacketTypes.CONNECT)
    p.SessionExpiryInterval = seconds
    return p

received = []

def on_message(client, userdata, msg):
    received.append((msg.topic, msg.payload.decode(), msg.retain))

# 1. Gateway veröffentlicht Retained State und registriert einen Last Will
gw = make_client("gw-" + uuid.uuid4().hex[:6])
gw.will_set(f"{BASE}/gw1/status", "OFFLINE", qos=1, retain=True)
gw.connect(HOST, PORT, keepalive=5)
gw.loop_start()
gw.publish(f"{BASE}/gw1/status", "ONLINE", qos=1, retain=True)
gw.publish(f"{BASE}/cnc1/state", "RUNNING", qos=1, retain=True).wait_for_publish()

# 2. Später Subscriber mit persistenter Session erhält sofort den Retained State
sub_id = "scada-" + uuid.uuid4().hex[:6]
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
sub.subscribe(f"{BASE}/#", qos=1)
time.sleep(2)
print("Retained on subscribe:", received)

# 3. Subscriber trennt sich, Gateway veröffentlicht, Subscriber nimmt Session wieder auf
sub.disconnect(); sub.loop_stop()
gw.publish(f"{BASE}/cnc1/state", "IDLE", qos=1).wait_for_publish()
received.clear()
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
time.sleep(2)
print("Delivered after resume:", received)

# 4. Gateway-Absturz simulieren: Netzwerkschleife ohne DISCONNECT stoppen
received.clear()
gw.loop_stop()
gw.socket().close()
time.sleep(10)  # länger als 1,5 x Keepalive warten
print("Last will:", received)
sub.disconnect()

Erwartete Ausgabe: die Retained-Werte ONLINE und RUNNING beim Abonnieren, die Änderung auf IDLE, die nach der Session-Wiederaufnahme zugestellt wird, obwohl sie während der Abwesenheit des Subscribers veröffentlicht wurde, und OFFLINE, sobald der Broker bemerkt, dass das Gateway weg ist. Denken Sie daran, dass der öffentliche MQTT-Broker nur für Tests und Prototypen gedacht, für alle lesbar ist und bewusste Limits hat (Nachrichten bis 64 KB, 10 Nachrichten pro Sekunde und Client, Session Expiry bis 30 Minuten). Führen Sie Lasttests daher nur gegen Ihren eigenen Broker aus.

Checkliste für die Evaluierung

1. Führen Sie das obige Skript mit TLS auf Port 8883 gegen den Kandidaten-Broker aus.
2. Veröffentlichen Sie echten Sparkplug-B-Verkehr aus einem Simulator und prüfen Sie, ob Sie ihn in den Broker-Tools lesen können.
3. Verbinden Sie 50 Clients gleichzeitig neu und achten Sie auf abgelehnte Verbindungen oder langsame CONNACKs.
4. Veröffentlichen Sie absichtlich zu schnell und prüfen Sie, welchen Reason Code Sie zurückbekommen, zum Beispiel 0x97 (Quota überschritten) in MQTT 5.
5. Geben Sie fünfmal hintereinander ein falsches Passwort ein und bestätigen Sie, dass der Broker reagiert.
6. Fragen Sie, wer den Broker betreibt und wie die Zertifikatserneuerung funktioniert.

Für einen breiteren, nicht industriellen Vergleich lesen Sie, wie Sie einen IoT-MQTT-Broker auswählen.

Wie ConnectMQ den industriellen Einsatz angeht

ConnectMQ ist ein verwalteter MQTT-Broker, der mit genau diesen Anforderungen im Blick entwickelt wurde. Er unterstützt MQTT 3.1.1 und 5.0 über TCP, TLS, WebSocket und Secure WebSocket, Retained Messages, Session Expiry und die vollständigen MQTT-5-Reason-Codes. Er erkennt ISA-95- und UNS-Topics, dekodiert Sparkplug B (Protobuf und JSON) und veröffentlicht Sparkplug-Metriken erneut in ISA-95-Topics. Jeder Broker stellt den Verbindungsstatus unter $SYS/broker/connection/{clientId}/state bereit, und das Portal ergänzt einen Live-Topic-Explorer, eine Geräteansicht nach ISA-95-Ebene und Regeln für Schwellwert-Alarme. Mandantenisolation, planabhängige Quotas, Flood Protection und IP-Sperren nach wiederholten Fehlanmeldungen schützen jeden Mandanten. Die Pläne reichen von kostenlosem Serverless über Dedicated-Cluster und BYOC in Ihrem eigenen Cloud-Konto bis zu Self Managed Enterprise. Zu den allgemeinen Abwägungen beim Hosting lesen Sie unseren Leitfaden zu Cloud-MQTT-Brokern; für das größere industrielle Bild siehe Industrial IoT mit MQTT.

Starten Sie mit ConnectMQ

Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ganz ohne Kreditkarte. Richten Sie das Testskript und einen Sparkplug-Simulator darauf aus und sehen Sie Ihre Werksdaten innerhalb weniger Minuten dekodiert und nach ISA-95-Ebene geordnet im ConnectMQ-Portal.

Häufig gestellte Fragen

Muss ein industrieller MQTT-Broker Sparkplug B unterstützen?

Sparkplug B funktioniert auf jedem standardkonformen Broker mit Retained Messages, QoS und Last Will. Ein Broker, der Sparkplug-Payloads zusätzlich dekodiert, erleichtert Inbetriebnahme und Fehlersuche erheblich.

Ist MQTT 5 für den industriellen Einsatz erforderlich?

Nein, Sparkplug B und viele Gateways verwenden MQTT 3.1.1. MQTT 5 bringt nützliche Funktionen wie Session Expiry, Reason Codes und Shared Subscriptions, daher sollte ein Broker beide Versionen unterstützen.

Sollte ich einen industriellen MQTT-Broker selbst betreiben oder einen verwalteten MQTT-Broker nutzen?

Ein selbst betriebener Broker bietet volle Kontrolle, macht Ihr Team aber für Patching, Zertifikate und Monitoring verantwortlich. Ein verwalteter MQTT-Broker nimmt Ihnen diese Arbeit ab, und Optionen wie BYOC halten den Broker in Ihrem eigenen Cloud-Konto.

Wie erkenne ich, dass ein Gateway offline gegangen ist?

Konfigurieren Sie eine Retained-Last-Will-Nachricht wie OFFLINE auf einem Status-Topic. Der Broker veröffentlicht sie automatisch, wenn das Gateway die Verbindung ohne sauberes DISCONNECT verliert.