Industrial IoT mit MQTT: Der komplette IIoT-Leitfaden

Mit Industrial IoT MQTT bringen moderne Werke Daten von SPS, Sensoren und Maschinen zu den Systemen, die darauf reagieren, ohne die fragilen Punkt-zu-Punkt-Integrationen der Vergangenheit. Dieser Leitfaden erklärt, warum MQTT zum Rückgrat des IIoT wurde, wie eine Edge-to-Cloud-Architektur aufgebaut ist, wo Sparkplug B, ISA-95-Topic-Namespaces und der Unified Namespace (UNS) ihren Platz haben und wie Sie mit lauffähigem Code einen ersten Datenfluss von der Maschine zum Broker aufbauen. Am Ende haben Sie eine Referenzarchitektur und eine Checkliste, die Sie in Ihr nächstes Industrie-4.0-Projektmeeting mitnehmen können, ob im Maschinenbau, in der Fertigung oder in der Prozessindustrie.

Warum MQTT zum Rückgrat des Industrial IoT wurde

Die klassische Automatisierung folgt dem geschichteten Purdue-Modell: Sensoren sprechen mit SPS, SPS mit SCADA, SCADA mit einem Historian, und darüber sitzen MES und ERP. Jede Schicht ist über Punkt-zu-Punkt-Verbindungen mit der nächsten integriert, oft mit proprietären Protokollen. Einen neuen Abnehmer von Maschinendaten hinzuzufügen, etwa ein Qualitäts-Dashboard oder ein Modell für vorausschauende Wartung, bedeutet, mehrere dieser Verbindungen anzufassen.

MQTT durchbricht dieses Muster mit Publish/Subscribe. Jede Datenquelle veröffentlicht einmal an einen zentralen Broker, und beliebig viele Abnehmer abonnieren genau das, was sie brauchen. Wenn Ihnen dieses Modell neu ist, erklärt was ein MQTT-Broker leistet die Grundlagen. Für den industriellen Einsatz sind einige MQTT-Eigenschaften besonders wichtig:

• Nur ausgehende Verbindungen. Edge-Geräte bauen Verbindungen zum Broker auf; nichts muss von außen ins Werksnetz greifen. Das passt weit besser zu OT-Sicherheitsrichtlinien als Polling-Protokolle, die eingehenden Zugriff erfordern.
• Report by Exception. Geräte veröffentlichen, wenn sich ein Wert ändert, statt in festen Zyklen abgefragt zu werden. Das reduziert die Bandbreite auf langsamen oder volumenbasiert abgerechneten Verbindungen drastisch. Siehe Report by Exception.
• Zustandsbewusstsein. Last-Will-and-Testament-Nachrichten, Retained-Werte und Keep-Alives teilen jedem Abnehmer mit, ob eine Maschine online ist und was ihr letzter bekannter Zustand war.
• Geringer Ressourcenbedarf. MQTT-Clients laufen auf SPS, Gateways und sogar Mikrocontrollern und funktionieren über Mobilfunkverbindungen.
• Offener Standard. MQTT ist ein OASIS-Standard mit Clients in jeder Sprache, Sie sind also nicht an den Stack eines einzelnen Herstellers gebunden.

Das macht OPC UA oder Feldbusprotokolle nicht überflüssig. OPC UA bleibt hervorragend für reichhaltige Informationsmodelle und den Zugriff auf Maschinenebene, weshalb die meisten IIoT-Architekturen beides kombinieren; wir vergleichen sie in OPC UA vs. MQTT.

Referenzarchitektur für Industrial IoT MQTT

Eine praxistaugliche IIoT-Architektur hat vier Schichten. Jede hat eine klare Aufgabe, und der Broker steht im Zentrum.

Der Artikel zur IIoT-Architektur geht tiefer auf jede Schicht ein. Hier sind die wichtigsten Entscheidungen.

Das Edge-Gateway

Die meisten installierten Maschinen sprechen kein MQTT. Ein IIoT-Edge-Gateway liest sie über ihr natives Protokoll aus und veröffentlicht an den Broker. Es sollte lokal schnell pollen, aber nur bei Änderungen veröffentlichen, Zeitstempel und Einheiten ergänzen und Nachrichten puffern, wenn die Uplink-Verbindung ausfällt. Diese letzte Aufgabe heißt Store and Forward, und sie verhindert, dass ein Netzausfall zu einer Datenlücke wird. Für einzelne Protokolle siehe Modbus TCP zu MQTT, den Leitfaden zum OPC-UA-zu-MQTT-Gateway und SPS in die Cloud.

Platzierung im Netzwerk

Werke trennen OT- und IT-Netze meist, mit einer DMZ dazwischen. Gängige Muster sind ein Broker in der DMZ, an den die OT-Gateways veröffentlichen, ein Broker in der Cloud, der über eine ausgehende Firewall-Regel erreicht wird, oder beide per Bridge verbunden. Jedes Muster hat Vor- und Nachteile bei Latenz, Autonomie und Sicherheit; MQTT in der industriellen DMZ geht sie durch.

Wo der Broker läuft

On-Premises-Broker laufen weiter, wenn das Internet ausfällt, was für alles innerhalb eines Regelkreises entscheidend ist. Cloud-Broker machen die standortübergreifende Aggregation, den Fernzugriff und Dashboards deutlich einfacher. Viele Werke machen beides: Lokale Logik bleibt lokal, und ein Cloud-MQTT-Broker aggregiert die Standorte für Analytics und Unternehmenssysteme. Wie auch immer Sie sich entscheiden: Die industriellen Anforderungen an Verfügbarkeit, Isolation und Sicherheit sind höher als im Consumer-IoT, was wir in einen industriellen MQTT-Broker auswählen behandeln.

Topic-Design: ISA-95 und der Unified Namespace

Reines MQTT sagt nichts über die Topic-Struktur aus, und diese Freiheit ist im Werksmaßstab gefährlich. Ohne Konvention landen machine7/temp, Line-2/Temp_C und plant/oven/temperature im selben Broker, und niemand kann „alles auf Linie 2“ abonnieren.

Die industrielle Antwort lautet, Topics an der ISA-95-Anlagenhierarchie auszurichten:

enterprise/site/area/line/cell/measurement
acme/werk-stuttgart/zerspanung/linie-1/cnc1/spindle_temp

Ein so organisierter Broker wird zum Unified Namespace: einem Ort, an dem der aktuelle Zustand des gesamten Unternehmens in einer Struktur veröffentlicht wird, die alle verstehen. Die ISA-95-Ebenen (Unternehmen → Standort → Bereich → Linie → Zelle) sind dabei direkt die Topic-Ebenen des UNS. Das MES abonniert acme/werk-stuttgart/#, ein Linien-Dashboard acme/werk-stuttgart/zerspanung/linie-1/# und ein Predictive-Maintenance-Modell acme/+/+/+/+/vibration. Einen Abnehmer hinzuzufügen erfordert nie einen Eingriff bei einem Erzeuger.

Regeln, die sich in echten Werken bewähren:

1. Einigen Sie sich auf Ebenennamen und erlaubte Zeichen, bevor sich das erste Gerät verbindet.
2. Verwenden Sie Kleinbuchstaben, keine Leerzeichen und stabile Bezeichner (Anlagen-IDs, keine Spitznamen der Bediener).
3. Trennen Sie Telemetrie, Zustand, Ereignisse und Befehle in eigene Blatt-Topics.
4. Legen Sie technische Einheiten und Zeitstempel in den Payload, nicht ins Topic.
5. Veröffentlichen Sie den aktuellen Zustand als Retained Messages, damit neue Abnehmer ihn sofort erhalten.

Die ausführliche Anleitung finden Sie in ISA-95 MQTT Topics, UNS-Topic-Struktur und der Schritt-für-Schritt-Anleitung einen Unified Namespace aufbauen.

Sparkplug B: Zustand und Struktur für MQTT

Sparkplug B ist eine Spezifikation der Eclipse Foundation, die festlegt, wie industrielle Geräte MQTT nutzen sollen. Sie regelt drei Dinge, die reines MQTT offenlässt:

• Einen Topic-Namespace: spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}.
• Ein Payload-Format: Protobuf-kodierte Metriken mit Namen, Datentypen, Zeitstempeln und Aliassen.
• Zustandsverwaltung: Birth- (NBIRTH, DBIRTH) und Death-Zertifikate (NDEATH, DDEATH), damit jeder Abnehmer weiß, welche Edge-Nodes und Geräte online sind und welche Metriken sie veröffentlichen.

Die Vorteile sind Interoperabilität zwischen Sparkplug-fähigen Produkten und ein verlässlicher Zustand. Der Preis: Protobuf-Payloads sind nicht menschenlesbar, und das feste Topic-Layout bildet Ihre Werkshierarchie nicht ab. Beginnen Sie mit den Erklärungen zum Sparkplug-B-Payload und zu Sparkplug Birth- und Death-Zertifikaten, und nutzen Sie Sparkplug B in Python dekodieren, wenn Sie rohen Datenverkehr untersuchen müssen.

Sparkplug B und ISA-95 gemeinsam

Viele Werke setzen beides ein: Sparkplug B an der Edge für zustandsbewusste, effiziente Kommunikation und einen ISA-95-JSON-Namespace als UNS für alle anderen. Die Herausforderung ist die Übersetzungsschicht dazwischen. Unser Artikel zu Sparkplug B und dem Unified Namespace vergleicht beide Ansätze im Detail, und der nächste Abschnitt zeigt, wie ein Broker die Übersetzung für Sie übernehmen kann.

Praxis: Ihr erster Industrial-IoT-MQTT-Datenfluss

Sie können industrielle Topic-Muster sofort auf dem kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com ausprobieren. Verwenden Sie ein eindeutiges Präfix, bleiben Sie innerhalb von 8 Topic-Ebenen und denken Sie daran, dass der öffentliche MQTT-Broker für Tests und Prototypen gedacht und für jeden lesbar ist; verwenden Sie also nur simulierte Daten, keine Produktionsdaten.

Abonnieren Sie das gesamte simulierte Werk:

mosquitto_sub -h broker.connectmq.com -p 1883 -i iiot-sub-m5q2 \
  -t "connectmq/demo/m5q2/#" -v

Veröffentlichen Sie einen Messwert im ISA-95-Stil und einen Retained-Maschinenzustand:

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/telemetry" \
  -m '{"spindle_temp":61.4,"spindle_rpm":8200,"unit_temp":"C","ts":1760600000}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 -r \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/state" -m "RUNNING"

Eine minimale Edge-Bridge von Modbus TCP zu MQTT

Das folgende Skript übernimmt die Rolle eines Edge-Gateways. Es liest jede Sekunde zwei Holding-Register von einem Modbus-TCP-Gerät, veröffentlicht nur, wenn sich ein Wert um mehr als ein Totband ändert, und registriert einen Last Will, damit Abnehmer wissen, wann das Gateway verschwindet. Es nutzt pymodbus 3.x und paho-mqtt 2.x:

pip install "pymodbus>=3.6" "paho-mqtt>=2.0"

import json
import time

import paho.mqtt.client as mqtt
from pymodbus.client import ModbusTcpClient

PLC_HOST = "192.168.1.50"      # Ihr Modbus-TCP-Gerät oder Simulator
BASE = "connectmq/demo/m5q2/machining/line1/press1"
DEADBAND = 0.5                 # nur veröffentlichen, wenn sich ein Wert um so viel ändert

def on_connect(client, userdata, flags, reason_code, properties):
    print("Broker connection:", reason_code)
    client.publish(f"{BASE}/state", "ONLINE", qos=1, retain=True)

mqttc = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="edge-press1-m5q2",
    protocol=mqtt.MQTTv5,
)
mqttc.will_set(f"{BASE}/state", "OFFLINE", qos=1, retain=True)
mqttc.on_connect = on_connect
mqttc.reconnect_delay_set(min_delay=1, max_delay=30)
mqttc.connect("broker.connectmq.com", 1883, keepalive=30)
mqttc.loop_start()

plc = ModbusTcpClient(PLC_HOST, port=502)
last = {}

while True:
    if not plc.connected:
        plc.connect()
    rr = plc.read_holding_registers(address=0, count=2)
    if rr.isError():
        print("Modbus read failed:", rr)
        time.sleep(2)
        continue

    values = {
        "pressure_bar": rr.registers[0] / 10.0,  # in der SPS mit Faktor 10 skaliert
        "temperature_c": rr.registers[1] / 10.0,
    }
    changed = {k: v for k, v in values.items()
               if k not in last or abs(v - last[k]) >= DEADBAND}
    if changed:
        changed["ts"] = int(time.time() * 1000)
        mqttc.publish(f"{BASE}/telemetry", json.dumps(changed), qos=1)
        last.update({k: v for k, v in changed.items() if k != "ts"})
    time.sleep(1)

Beobachten Sie Ihr Subscriber-Terminal: Werte erscheinen nur, wenn sie sich ändern, und OFFLINE kommt an, wenn Sie das Skript beenden. Registerskalierung, Wortreihenfolge und Adressierung unterscheiden sich zwischen SPS-Herstellern, prüfen Sie daher die Registertabelle des Geräts; unser Leitfaden zur Modbus-MQTT-Bridge behandelt diese Details. Ein produktives Gateway würde außerdem bei Ausfällen auf die Festplatte puffern und TLS mit Zugangsdaten verwenden.

Wie ConnectMQ Industrial IoT MQTT unterstützt

ConnectMQ ist ein verwalteter MQTT-Broker mit Funktionen, die speziell auf industriellen Datenverkehr zugeschnitten sind:

• ISA-95- und UNS-Erkennung. Der Broker erkennt ISA-95- und UNS-Topic-Strukturen in Ihrem Datenverkehr.
• Sparkplug-B-Dekodierung. Sparkplug-B-Payloads werden dekodiert (Protobuf oder JSON), sodass Sie sie im Portal lesen können, statt auf Bytes zu starren.
• Republishing von Sparkplug nach ISA-95. Sparkplug-B-Daten können mit lesbaren Payloads in ISA-95-Topics neu veröffentlicht werden, zum Beispiel wird aus spBv1.0/factory1/DDATA/line1/cnc1 das Topic connectmq/factory1/production/line1/cnc1/telemetry. Edge-Nodes sprechen weiterhin Sparkplug, während MES und Dashboards einen sauberen Namespace konsumieren.
• ISA-95-Geräteansicht und Alarme. Das Portal zeigt Geräte nach ISA-95-Ebenen gegliedert, und Schwellenwert-Alarmregeln mit Alarmprotokoll melden Werte wie eine Spindeltemperatur, die einen Grenzwert überschreitet.
• Wahl der Bereitstellung. Starten Sie mit dem kostenlosen Serverless-Plan und wechseln Sie dann zu einem isolierten Dedicated-Cluster, zu BYOC in Ihrem eigenen Cloud-Konto oder zu Self Managed Enterprise für Standorte, die On-Premises bleiben müssen.

Wie das durchgängig aussieht, zeigt die Web-Demo des ConnectMQ 3D Digital Twin: eine Fabrik mit CNC-Maschine, Roboterarm, Ofen, Tank, Förderband und Pumpe, die sich live über Secure WebSocket aktualisiert. Speicherung und Analytics werden auf offene Weise gelöst: Historians, Telegraf, Node-RED oder Ihre eigenen Services abonnieren den Broker als Standard-MQTT-Clients. Siehe einen MQTT-Historian aufbauen für dieses Muster.

Projekt-Checkliste für Industrial IoT MQTT

Nutzen Sie diese Liste, wenn Sie eine erste Bereitstellung planen. Die vollständige Version finden Sie in unserer IIoT-Konnektivitäts-Checkliste.

1. Inventarisieren Sie Maschinen, Protokolle und die Datenpunkte, die tatsächlich eine geschäftliche Frage beantworten.
2. Einigen Sie sich mit OT und IT auf eine ISA-95-Topic-Hierarchie für den UNS und auf Namensregeln.
3. Legen Sie das Payload-Format fest: Sparkplug B an der Edge, JSON für Abnehmer oder beides.
4. Wählen Sie Gateway-Hardware und stellen Sie sicher, dass sie Pufferung und TLS unterstützt.
5. Entscheiden Sie, wo der Broker läuft und wie der Datenverkehr die OT/IT-Grenze überquert.
6. Vergeben Sie eindeutige Zugangsdaten pro Gateway und erzwingen Sie TLS auf 8883; IEC 62443 liefert dafür den Rahmen.
7. Definieren Sie das Zustandshandling: Last Will, Retained-Zustands-Topics, Birth- und Death-Nachrichten.
8. Planen Sie Speicherung und Visualisierung mit Subscriber-Tools, nicht mit Magie auf Broker-Seite.
9. Starten Sie ein Pilotprojekt auf einer Linie, messen Sie und skalieren Sie dann.

Die organisatorische Abstimmung ist hier ebenso wichtig wie die Technik; IT/OT-Konvergenz behandelt, wie Teams die Verantwortlichkeiten aufteilen. Für das Gesamtbild, wo diese Konnektivitätsschicht in einem Programm zur digitalen Transformation steht, lesen Sie unseren Industrie-4.0-Leitfaden.

Bauen Sie Ihr Industrial-IoT-Pilotprojekt auf ConnectMQ

Probieren Sie die obigen Beispiele auf broker.connectmq.com aus und erstellen Sie dann einen privaten Broker unter app.connectmq.com. Der kostenlose Serverless-Plan benötigt keine Kreditkarte und reicht für ein Pilotprojekt auf einer Linie mit einigen Gateways, Dashboards sowie der oben beschriebenen Sparkplug-B-Dekodierung und den ISA-95-Ansichten.

Häufig gestellte Fragen

Eignet sich MQTT für die industrielle Automatisierung?

Ja, für den Datentransport zwischen Maschinen, Edge-Gateways und Anwendungen. Harte Echtzeit-Regelkreise gehören weiterhin auf Feldbusse und SPS; MQTT transportiert die Daten rund um sie herum zu SCADA, MES, Historians und Analytics.

Brauche ich Sparkplug B für Industrial IoT MQTT?

Nein, aber es hilft, wenn Produkte vieler Hersteller zusammenarbeiten müssen und Sie einen verlässlichen Online/Offline-Zustand benötigen. Viele Werke nutzen Sparkplug B an der Edge und einen ISA-95-JSON-Namespace als UNS für die Abnehmer.

Sollte der industrielle MQTT-Broker vor Ort oder in der Cloud laufen?

Alles innerhalb eines Regelkreises sollte nicht von einer Internetverbindung abhängen, daher sind lokale Broker in Werken verbreitet. Ein Cloud-Broker ist besser für die standortübergreifende Aggregation, Remote-Dashboards und die Unternehmensintegration, und viele Architekturen nutzen beides.

Wie binde ich eine SPS an, die kein MQTT unterstützt?

Verwenden Sie ein Edge-Gateway, das die SPS über ihr natives Protokoll wie Modbus, OPC UA, S7 oder EtherNet/IP ausliest und an den Broker veröffentlicht. Viele neuere SPS haben außerdem integrierte MQTT-Clients.

Kann ConnectMQ Sparkplug-B-Nachrichten lesen?

Ja. ConnectMQ dekodiert Sparkplug-B-Payloads und kann sie mit lesbaren Payloads in ISA-95-Topics neu veröffentlichen, sodass Abnehmer ohne Sparkplug-Unterstützung die Daten direkt nutzen können.