Eine gute IIoT-Architektur teilt ein industrielles System in vier Schichten: Geräte, die messen und steuern, Edge-Gateways, die übersetzen und filtern, einen Broker, der Nachrichten verteilt, und Anwendungen, die aus Daten Entscheidungen machen. In dieser Referenz erfahren Sie, wofür jede Schicht zuständig ist, welche Designregeln die Schichten unabhängig halten und wie Sie ein kleines End-to-End-Beispiel ausführen, das alle vier berührt.
Warum Schichten im Industrial IoT wichtig sind
Viele frühe IIoT-Projekte wurden als gerade Leitungen gebaut: Ein Skript liest eine SPS und schreibt in eine Datenbank, die ein Dashboard abfragt. Für die Demo funktioniert das. Dann braucht ein zweiter Konsument die Daten, die SPS wird ersetzt oder die Datenbank zieht in die Cloud, und jede Änderung schlägt sich durch die gesamte Kette.
Eine geschichtete Architektur dämmt diese Wellen ein. Jede Schicht hat genau eine Aufgabe und einen klaren Vertrag mit ihren Nachbarn. Wird eine SPS ersetzt, ändert sich nur die Edge-Konfiguration. Kommt ein Analytics-Tool hinzu, erscheint nur ein neuer Subscriber. Beim Umzug von On-Premises in die Cloud verbindet sich die Edge einfach mit einer anderen Broker-Adresse. Das Publish/Subscribe-Modell macht diese Entkopplung möglich, und deshalb steht in den meisten modernen IIoT-Designs ein MQTT-Broker im Zentrum. Wer mit dem Referenzarchitekturmodell RAMI 4.0 der Plattform Industrie 4.0 arbeitet, findet die zugrunde liegenden ISA-95-Ebenen (IEC 62264) dort auf der Achse der Hierarchiestufen wieder.
Die vier Schichten der IIoT-Architektur
| Schicht | Verantwortung | Typische Komponenten | Spricht | Verantwortet von |
|---|---|---|---|---|
| Gerät | Messen, stellen, den Prozess steuern | Sensoren, SPSen, Antriebe, CNCs, Roboter | Feldbus, Modbus, OPC UA, analoge und digitale E/A | Automatisierungstechnik |
| Edge | Sammeln, normalisieren, puffern, filtern, Uplink absichern | Industrie-PCs, Gateways, Node-RED, Protokollkonverter | Geräteprotokolle nach unten, MQTT nach oben | OT, teils gemeinsam mit der IT |
| Broker | Nachrichten routen, aktuellen Zustand halten, Clients authentifizieren | MQTT-Broker, verwaltet oder selbst betrieben | MQTT 3.1.1 und 5.0 über TLS und WebSocket | Plattformteam oder Anbieter des verwalteten MQTT-Brokers |
| Anwendung | Visualisieren, speichern, analysieren, integrieren, entscheiden | Dashboards, Historians, MES, ERP-Konnektoren, Analytics | MQTT Subscribe und Publish | IT, Datenteams, Betrieb |
Geräteschicht
Das ist die physische Welt: Temperaturfühler, Durchflussmesser, SPSen, Antriebe, CNC-Steuerungen und Roboter. Geräte sind auf deterministische Steuerung optimiert, nicht auf das Teilen von Daten. Viele sprechen nur Feldbus- oder serielle Protokolle, manche haben überhaupt keine Kommunikationsschnittstelle. Die Architekturregel auf dieser Schicht ist einfach: Ändern Sie keine Steuerungslogik, um IT-Anforderungen zu bedienen. Lesen Sie Daten nicht-invasiv und lassen Sie Sicherheit und Steuerung dort, wo sie hingehören.
Edge-Schicht
Die Edge ist Übersetzer und Wächter zugleich. Ein Edge-Gateway liest SPS-Tags, Modbus-Register oder Sensoreingänge, wandelt sie in ein gemeinsames Format um und veröffentlicht sie per MQTT. Es übernimmt auch die Arbeit, die niemals über ein WAN laufen sollte: Rauschen filtern, Report by Exception, Zeitstempel und Einheiten ergänzen und Daten puffern, wenn der Uplink ausfällt. Unsere Leitfäden zur Auswahl eines IIoT-Edge-Gateways und zu Edge Computing vs. Cloud Computing im IIoT vertiefen, was hierher gehört.
Zentrale Aufgaben der Edge:
- Protokollkonvertierung von Geräteprotokollen zu MQTT.
- Normalisierung von Namen, Einheiten und Zeitstempeln.
- Report by Exception mit Totbändern, um Datenverkehr zu reduzieren.
- Store and Forward bei Netzwerkausfällen.
- Rein ausgehende Verbindungen zum Broker über TLS.
- Veröffentlichung des eigenen Zustands: Online-Status per Last Will, Firmware, Zeitpunkt der letzten Abfrage.
Broker-Schicht
Der Broker ist der Knotenpunkt. Jedes Edge-Gateway veröffentlicht in ihn hinein, und jede Anwendung abonniert aus ihm. Keine Seite kennt die andere, und genau darum geht es. Über das Routing hinaus hält der Broker Retained Messages, damit neue Anwendungen sofort den aktuellen Zustand sehen, bewahrt Sessions für Clients, die sich neu verbinden, setzt Authentifizierung und Quotas durch und veröffentlicht Last-Will-Nachrichten, wenn Gateways wegfallen. Für die Grundlagen lesen Sie, was ein MQTT-Broker macht.
Im Broker lebt auch der Namespace, und er ist das eigentliche Herzstück der Architektur. Ein Unified Namespace (UNS) macht die ISA-95-Gerätehierarchie (Enterprise → Site → Area → Line → Cell) zur Topic-Struktur auf dem MQTT-Broker, zum Beispiel connectmq/acme/plant1/packaging/line4/filler02/telemetry oder für ein deutsches Werk acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. So findet jede Anwendung Daten über den Ort im Werk statt über eine Tag-Liste, und der UNS wird zur einzigen Quelle des aktuellen Zustands für SPS-Gateways, SCADA, MES und ERP. Wie Sparkplug B diesen Namensraum ergänzt, erklärt der Beitrag zu Sparkplug B und dem Unified Namespace. Die Regeln für den Entwurf dieses Baums stehen in unserem Leitfaden zur UNS-Topic-Struktur.
Anwendungsschicht
In den Anwendungen werden Daten zu Wert: Live-Dashboards, OEE-Berechnungen, Alarmbenachrichtigungen, Historians, MES- und ERP-Integration, maschinelles Lernen. Jede Anwendung ist einfach ein weiterer MQTT-Client. Sie abonniert den Teil des Namespace, den sie braucht, und kann Ergebnisse zurück veröffentlichen, etwa eine berechnete OEE oder einen vorhergesagten Ausfall, die dann wiederum andere Anwendungen nutzen können. Die Langzeitspeicherung übernimmt meist ein eigener Subscriber, der in eine Zeitreihendatenbank schreibt; das behandelt unser Artikel zum MQTT-Historian.
Designregeln für eine saubere Architektur
- Jeder Pfeil zeigt auf den Broker. Geräte sprechen nie direkt mit Anwendungen, und Anwendungen pollen nie Geräte.
- Verbindungen gehen nach außen. Edge und Anwendungen öffnen Verbindungen zum Broker; nichts öffnet Verbindungen ins Werk.
- Ein Namespace, dokumentiert. Topic-Hierarchie und Payload-Format sind schriftlich festgehalten und versioniert.
- Zustand retainen, Ereignisse nicht. Aktuelle Werte sind retained; Alarme und Teilefertigmeldungen nicht.
- Jeder Client hat eine eigene Identität. Getrennte Zugangsdaten pro Gateway und pro Anwendung, sodass eine widerrufen werden kann, ohne andere zu beeinträchtigen.
- Intelligenz auf der richtigen Schicht. Zeitkritische Logik bleibt auf dem Gerät oder der Edge; standortübergreifende Analytics gehören in die Anwendungsschicht.
- Das System selbst beobachten. Gateway-Status, Verbindungszustand und Nachrichtenraten sind ebenfalls Daten.
End-to-End-Beispiel über alle vier Schichten
Das folgende Beispiel nutzt den öffentlichen MQTT-Broker, der für Tests und Prototypen gedacht ist. Der Bash-Befehl spielt die Edge-Schicht und veröffentlicht Gerätemesswerte. Das Python-Skript ist eine Anwendung: ein winziger Historian, der jeden Messwert in SQLite speichert und einen Alarm veröffentlicht, wenn ein Schwellwert überschritten wird.
Edge-Schicht (simuliert), veröffentlicht alle zwei Sekunden einen Messwert:
ID=arch-$RANDOM
echo "Use prefix connectmq/demo/$ID"
while true; do
T=$(awk -v r=$RANDOM 'BEGIN{printf "%.1f", 60 + (r % 300) / 10}')
mosquitto_pub -h broker.connectmq.com -p 1883 -i "$ID-edge" -q 1 \
-t "connectmq/demo/$ID/plant1/heat/furnace1/temperature" \
-m "{\"value\":$T,\"unit\":\"C\"}"
sleep 2
done
Anwendungsschicht, speichert Daten und veröffentlicht Alarme:
import json
import sqlite3
import sys
import time
import paho.mqtt.client as mqtt
PREFIX = sys.argv[1] # z. B. connectmq/demo/arch-12345
LIMIT_C = 85.0
db = sqlite3.connect("historian.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS readings (ts REAL, topic TEXT, value REAL)")
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(f"{PREFIX}/plant1/+/+/temperature", qos=1)
def on_message(client, userdata, msg):
data = json.loads(msg.payload)
value = float(data["value"])
db.execute("INSERT INTO readings VALUES (?, ?, ?)", (time.time(), msg.topic, value))
db.commit()
print(f"{msg.topic} = {value}")
if value > LIMIT_C:
alert_topic = msg.topic.rsplit("/", 1)[0] + "/alert"
client.publish(alert_topic, json.dumps({"reason": "over_limit", "value": value}), qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"{PREFIX.split('/')[-1]}-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Starten Sie es mit dem Präfix, das die Edge-Schleife ausgibt, zum Beispiel python historian.py connectmq/demo/arch-12345. Achten Sie darauf, was nie passiert: Der Historian kennt die IP-Adresse des Ofens nicht, und die Edge-Schleife weiß nicht, dass der Historian existiert. Sie könnten ein Dashboard, einen zweiten Historian oder ein ML-Modell als weitere Subscriber hinzufügen, ohne eines davon anzufassen. Für die Produktion stellen Sie beide Seiten auf Port 8883 mit TLS und ConnectMQ-Zugangsdaten aus dem Portal um und halten echte Werksdaten vom öffentlichen MQTT-Broker fern, den jeder lesen kann.
Wo der Broker laufen sollte
Die Broker-Schicht kann On-Premises, in einer DMZ, in der Cloud oder in einer Kombination davon laufen. Ein einzelnes Werk mit strikter Isolation behält vielleicht einen lokalen Broker. Organisationen mit mehreren Standorten wollen meist einen zentralen Broker, den alle Standorte ausgehend erreichen. Selbst betreiben bedeutet Patching, Zertifikatserneuerung, Monitoring und Kapazitätsplanung. Ein verwalteter MQTT-Broker nimmt Ihnen diese Arbeit ab, und unser Leitfaden zu Cloud-MQTT-Brokern vergleicht die Hosting-Modelle.
ConnectMQ ist dafür konzipiert, die Broker-Schicht in dieser Architektur zu sein. Es unterstützt MQTT 3.1.1 und 5.0 über TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084, sodass Edge-Gateways und Browser-Anwendungen sich mit demselben Namespace verbinden. Es erkennt ISA-95- und UNS-Topics, dekodiert Sparkplug B und veröffentlicht es erneut in ISA-95-Topics und bietet eine Geräteansicht nach ISA-95-Ebene, einen Live-Topic-Explorer und Regeln für Schwellwert-Alarme. Integrationen mit Historians, Datenbanken und Dashboards folgen dem obigen Muster: Werkzeuge wie Node-RED, Telegraf oder Ihre eigenen Subscriber verbinden sich als MQTT-Clients mit ConnectMQ. Die Bereitstellungsoptionen reichen von kostenlosem Serverless über Dedicated-Cluster bis zu BYOC in Ihrem eigenen Cloud-Konto. Für das vollständige industrielle Bild lesen Sie den Leitfaden zu Industrial IoT mit MQTT.
Starten Sie mit ConnectMQ
Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ganz ohne Kreditkarte. Richten Sie ein Edge-Gateway und eine Anwendung darauf aus, und alle vier Schichten Ihrer IIoT-Architektur laufen an einem Nachmittag.
Häufig gestellte Fragen
Aus welchen Schichten besteht eine IIoT-Architektur?
Eine praxistaugliche Referenz nutzt vier Schichten: Geräte, die messen und steuern, Edge-Gateways, die Daten sammeln und konvertieren, einen Broker, der Nachrichten routet und Zustand hält, und Anwendungen, die visualisieren, speichern und analysieren.
Warum wird MQTT als Messaging-Schicht im IIoT eingesetzt?
MQTT ist schlank, ereignisgesteuert und nutzt ausgehende Verbindungen, daher funktioniert es gut über segmentierte Werksnetze hinweg. Das Publish/Subscribe-Modell ermöglicht es vielen Anwendungen, dieselben Daten ohne Punkt-zu-Punkt-Integrationen zu nutzen.
Sollte die Verarbeitung an der Edge oder in der Cloud stattfinden?
Zeitkritisches Filtern, Protokollkonvertierung und Pufferung gehören an die Edge. Maschinen- und standortübergreifende Analytics, Langzeitspeicherung und Geschäftsintegration gehören meist in die Anwendungsschicht, oft in der Cloud.
Wie hängt das Purdue-Modell mit dieser IIoT-Architektur zusammen?
Das Purdue-Modell beschreibt Sicherheitsebenen des Netzwerks, diese Architektur dagegen den Datenfluss. Beide ergänzen sich: Geräte liegen auf den unteren Purdue-Ebenen, Edge-Gateways auf Standortebene und der Broker in der DMZ oder der Cloud.
