Ein IIoT-Edge-Gateway ist das Gerät, das eine Fabrik voller SPSen, Zähler und Antriebe in einen Strom strukturierter MQTT-Nachrichten verwandelt, die der Rest des Unternehmens nutzen kann. Dieser Artikel erklärt die vier Aufgaben, die jedes Gateway erfüllt (Protokollübersetzung, Pufferung, Sicherheit und Edge Computing), zeigt eine Referenzarchitektur und gibt Ihnen eine praxisnahe Checkliste für die Auswahl.
Warum Industriestandorte Edge-Gateways brauchen
Industrieanlagen wurden gebaut, um mit anderen Anlagen im selben Netzwerk zu kommunizieren, nicht mit der Cloud. In einer typischen Fertigung im Maschinenbau oder in der Prozessindustrie mischen sich Modbus RTU über RS485, Modbus TCP, OPC UA, EtherNet/IP, PROFINET und herstellerspezifische Protokolle, oft in Netzen, die bewusst vom Büro und vom Internet getrennt sind. Diese Protokolle arbeiten überwiegend nach dem Request-Response-Prinzip: Ein Client muss jedes Gerät nach jedem Wert abfragen.
Cloud-Systeme, Dashboards und Analysen erwarten etwas anderes: sichere, ausgehende, ereignisgesteuerte Daten mit einheitlichen Namen und Einheiten. Das Gateway ist Übersetzer und Wachposten zwischen beiden Welten. Ohne Gateway bräuchte jede Anwendung, die Maschinendaten möchte, eigene Treiber, einen eigenen Netzwerkpfad ins OT-Netz und würde empfindliche Steuerungen mit eigener Abfragelast belasten.
Die vier Kernaufgaben eines IIoT-Edge-Gateways
1. Protokollübersetzung und Datenmodellierung
Das Gateway fragt Geräte in ihren nativen Protokollen ab oder abonniert sie und veröffentlicht die Daten erneut über MQTT. Gute Gateways tun mehr, als Register zu kopieren: Sie wenden Skalierung, Einheiten und Namen an, sodass aus 40001 = 2351 ein {"temperature_c": 23.51} auf einem aussagekräftigen Topic wie acme/plant1/packaging/line2/filler/temperature wird.
In diesem Benennungsschritt baut das Gateway am Unified Namespace (UNS) mit. Wenn jedes Gateway in eine gemeinsame Hierarchie nach ISA-95 (Unternehmen → Standort → Bereich → Linie → Zelle) veröffentlicht, wird diese Anlagenhierarchie zur Topic-Struktur des UNS auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. MES, ERP, SCADA und Analytics finden die Daten dann, ohne zu wissen, welches Gateway oder Protokoll sie erzeugt hat. Wie das mit Sparkplug B zusammenspielt, zeigt der Beitrag Sparkplug B und der Unified Namespace. Konkrete Übersetzungswege werden in den Leitfäden zu Modbus TCP zu MQTT und zum OPC-UA-zu-MQTT-Gateway behandelt.
2. Pufferung und Store-and-Forward
Anlagennetze und WAN-Verbindungen fallen aus. Ein Gateway, das Daten einfach verwirft, solange der Broker nicht erreichbar ist, hinterlässt Lücken in der Historie, die sich oft nicht nachträglich füllen lassen. Industrielle Gateways puffern Nachrichten lokal, auf der Festplatte statt nur im Arbeitsspeicher, und spielen sie in der richtigen Reihenfolge ab, sobald die Verbindung zurück ist. Die Designdetails (Puffergröße, Zeitstempel, Wiedergaberate) finden Sie unter Store-and-Forward für MQTT.
3. Sicherheitsgrenze
Das Gateway ist meist das einzige Gerät, das sowohl das OT-Netz als auch ein externes Netz berührt. Damit ist es der richtige Ort, um mehrere Regeln durchzusetzen:
- Nur ausgehende Verbindungen. Das Gateway baut eine TLS-Verbindung zum Broker auf; nichts im Internet initiiert Verbindungen in das Werk hinein.
- Isolierte Zugangsdaten. Nur das Gateway besitzt Broker-Zugangsdaten. SPSen niemals.
- Standardmäßig nur lesend. Das Schreiben von Sollwerten aus der Cloud sollte, wenn überhaupt, pro Tag ausdrücklich freigeschaltet werden.
- Netzwerksegmentierung. Zwei Netzwerkschnittstellen, eine pro Zone, ohne Routing dazwischen, oder die Platzierung in einer industriellen DMZ. Dieses Zonen-und-Conduit-Denken entspricht IEC 62443 und hilft auch bei Anforderungen aus NIS2.
4. Edge Computing
Manche Logik gehört direkt an die Maschine: Rauschen filtern, Mittelwerte berechnen, Schwellwertüberschreitungen erkennen oder Alarme ausführen, die auch funktionieren müssen, wenn die Cloud nicht erreichbar ist. Die wertvollste Berechnung am Edge ist oft auch die einfachste: Report by Exception, das einen Wert nur veröffentlicht, wenn er sich nennenswert ändert, und den Datenverkehr im Vergleich zur Abfrage in festen Intervallen drastisch reduzieren kann.
Referenzarchitektur
Shop floor (OT network) Edge Cloud / IT
------------------------ ----------------- ------------------
PLC (EtherNet/IP) ---\ | IIoT edge | TLS | MQTT broker |
Energy meter (Modbus) ----+----> | gateway | -----> | (8883) | --> dashboards
CNC (OPC UA / MTConnect) --/ | - drivers | outbound| | --> historian
| - modeling | only | | --> analytics
| - buffer | | |
| - RBE / rules | ------------------
-----------------
Das Gateway veröffentlicht auf Topics, die der Anlagenhierarchie folgen. Ein typischer Payload sieht so aus:
{
"ts": "2026-10-16T08:14:03.512Z",
"values": {
"spindle_speed_rpm": 11980,
"spindle_load_pct": 41.5,
"program": "O1234",
"state": "RUNNING"
},
"quality": "GOOD",
"source": "gw-plant1-02"
}
Ein Quellzeitstempel, ein Qualitätsflag und die Gateway-ID in jeder Nachricht erleichtern das Wiedergeben gepufferter Daten und die Fehlersuche erheblich.
Ein IIoT-Edge-Gateway auswählen: Checkliste
| Kriterium | Zu stellende Fragen |
|---|---|
| Protokolltreiber | Unterstützt es heute jedes Protokoll in Ihrer Fertigung, einschließlich älterer serieller Schnittstellen? Werden Treiber pro Protokoll oder pro Tag lizenziert? |
| Qualität des MQTT-Clients | MQTT 3.1.1 und 5? TLS mit eigener CA? Konfigurierbare QoS, Retained Messages, Last Will, Keep Alive? |
| Payload-Optionen | Einfaches JSON, Sparkplug B oder beides? Lässt sich die Topic-Struktur vollständig steuern? |
| Store-and-Forward | Festplattenbasiert? Wie viel? Wiedergabe in Reihenfolge? Gedrosselte Wiedergabe? |
| Edge-Logik | Totbänder, Skalierung, Scripting oder Container für eigenen Code? |
| Hardware | Hutschiene, erweiterter Temperaturbereich, lüfterlos, industrieller Spannungseingang, serielle Ports? |
| Verwaltung | Fernkonfiguration und Firmware-Updates ohne eingehende Firewall-Ports zu öffnen? |
| Sicherheit | Secure Boot, signierte Updates, rollenbasierter lokaler Zugriff, getrennte Netzwerkschnittstellen? |
| Lebenszyklus | Wie lange unterstützt der Hersteller das Gerät, und können Sie die Konfiguration exportieren, wenn Sie es ersetzen? |
Gängige Gateway-Typen
- Dedizierte industrielle Gateways. Speziell gebaute Hutschienengeräte mit einem Konfigurationstool des Herstellers. Schnell einsatzbereit, aber auf die Protokolle und Logik beschränkt, die der Hersteller liefert.
- Industrie-PCs mit Gateway-Software. Flexibler: Sie betreiben eine kommerzielle Konnektivitätsplattform, Node-RED oder eigene Container. Erfordert mehr Wartung im IT-Stil.
- SPSen und Steuerungen mit integriertem MQTT. Viele moderne Steuerungen können MQTT direkt veröffentlichen. Das spart ein Gerät, verlagert aber Netzwerkverantwortung auf die Steuerung, womit nicht jedes Werk einverstanden ist.
- Mikrocontroller-Gateways. Für kleine Nachrüstungen kann ein Mikrocontroller einige Modbus-Geräte mit MQTT verbinden, wie im Tutorial zum ESP32 als Modbus-RS485-zu-MQTT-Gateway. Gut für Pilotprojekte und unkritisches Monitoring.
Sparkplug B oder einfaches JSON?
Gateways bieten zunehmend Sparkplug B an, das einen standardisierten Topic-Namespace, Birth- und Death-Zertifikate für das Zustandsbewusstsein und kompakte Protobuf-Payloads ergänzt. Einfaches JSON ist leichter zu lesen und mit jedem Tool zu verarbeiten. Viele Werke nutzen beides: Sparkplug B von den Gateways und eine lesbare ISA-95-JSON-Sicht im UNS für Konsumenten. ConnectMQ kann Sparkplug-B-Payloads dekodieren und in ISA-95-Topics erneut veröffentlichen, etwa aus spBv1.0/factory1/DDATA/line1/cnc1 ein connectmq/factory1/production/line1/cnc1/telemetry machen, sodass beide Stile auf einem Broker nebeneinander bestehen. Das Gesamtbild finden Sie im Leitfaden zu Industrial IoT mit MQTT.
Ein Gateway vor dem Rollout testen
Bevor Sie ein Gateway mit Produktionsdaten verbinden, richten Sie es auf einen öffentlichen MQTT-Broker aus und prüfen Sie Topics, Payloads und Reconnect-Verhalten:
mosquitto_sub -h broker.connectmq.com -p 1883 -i gw-test-viewer-81 -t "connectmq/demo/gw-test-81/#" -v
Konfigurieren Sie das Gateway so, dass es simulierte oder unkritische Werte unter connectmq/demo/gw-test-81/... auf dem öffentlichen MQTT-Broker veröffentlicht. Ziehen Sie dann für einige Minuten sein Netzwerkkabel und prüfen Sie, ob gepufferte Nachrichten nach dem Wiederverbinden in der richtigen Reihenfolge ankommen. Denken Sie daran, dass der öffentliche MQTT-Broker nur für Tests und Prototypen gedacht und für jeden lesbar ist; senden Sie also niemals echte Anlagendaten dorthin.
Wo der Broker ins Spiel kommt
Das Gateway ist nur die halbe Miete. Der Broker, an den es veröffentlicht, muss TLS, Authentifizierung, viele gleichzeitige Subscriber und den Retained-Zustand jedes Tags bewältigen. Diese Infrastruktur selbst zu betreiben, bedeutet Patches, Zertifikatserneuerung und Monitoring. Ein verwalteter MQTT-Broker nimmt Ihnen diese Last ab, und die Optionen reichen von gemeinsam genutzten Serverless-Brokern für Pilotprojekte bis zu dedizierten Clustern oder Brokern in Ihrem eigenen Cloud-Konto für strengere Anforderungen. Wenn Sie zuerst die Vor- und Nachteile des Hostings verstehen möchten, lesen Sie den Leitfaden zur Wahl eines Cloud-MQTT-Brokers. Um zu entscheiden, wie viel Logik am Edge und wie viel in der Cloud liegen sollte, lesen Sie Edge Computing vs. Cloud Computing im IIoT.
Bringen Sie Ihre Gateways mit ConnectMQ ins Gespräch
ConnectMQ gibt jedem Gateway einen TLS-Endpunkt auf Port 8883, ausgestellte Zugangsdaten, die an seine Client-ID gebunden sind, einen Live-Topic-Explorer und eine Geräteansicht, die nach ISA-95-Ebenen gegliedert ist. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und richten Sie Ihr erstes Gateway darauf aus.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem IIoT-Edge-Gateway und einem Router?
Ein Router leitet Netzwerkpakete weiter, ohne sie zu verstehen. Ein Edge-Gateway versteht industrielle Protokolle, liest Werte aus, wandelt sie in aussagekräftige Nachrichten um und veröffentlicht sie über MQTT.
Brauche ich ein Gateway, wenn meine SPS MQTT unterstützt?
Nicht immer. Ein Gateway hilft trotzdem, wenn Sie viele Altgeräte haben, festplattenbasierte Pufferung benötigen oder Broker-Zugangsdaten und Internetzugang von Ihren Steuerungen fernhalten möchten.
Sollte das Gateway Sparkplug B verwenden?
Verwenden Sie Sparkplug B, wenn Ihre konsumierenden Anwendungen es unterstützen und Sie ein standardisiertes Zustandsmanagement wünschen. Verwenden Sie einfaches JSON, wenn viele einfache Tools die Daten direkt lesen müssen; manche Werke veröffentlichen beides.
Wie viele Daten sollte ein Gateway puffern?
Dimensionieren Sie den Puffer für den längsten Ausfall, den Sie bei normaler Datenrate überstehen möchten, mit Reserve. Report by Exception reduziert sowohl den normalen Datenverkehr als auch den Pufferbedarf.
