Kostenlose DevOps-Analyse
Zurück zum Glossar
DevOps Glossar·OT / Industrial

Edge Gateway

// Direkte Antwort

Was macht ein Edge Gateway?

Ein Edge Gateway sitzt am Rand eines Netzwerks — typischerweise in der Fabrikhalle — und verbindet Maschinen und Sensoren mit der IT-Welt. Es übersetzt Feldprotokolle wie Modbus oder S7 in IT-Protokolle wie MQTT und OPC UA, filtert und verdichtet Daten direkt am Edge und leitet nur relevante Informationen an übergeordnete Systeme weiter, ohne dass die gesamte Datenmenge ins Rechenzentrum wandern muss.

// Kurz gefragt1 Klick, anonym

Ist Edge Gateway bei Ihnen gerade ein Thema?

Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.

// Im DetailEdge Gateway

Ein Edge Gateway ist ein Gerät an der Grenze zwischen OT und IT, das industrielle Maschinendaten erfasst, übersetzt, vorverarbeitet und sicher an übergeordnete IT- oder Cloud-Systeme weitergibt. Es erfüllt vier typische Aufgaben gleichzeitig: Protokollübersetzung, Datenvorverarbeitung, Pufferung und sichere Anbindung. Auf der OT-Seite spricht es Feldprotokolle wie Modbus, PROFINET, EtherNet/IP oder S7, auf der IT-Seite stellt es die Daten normalisiert über MQTT, OPC UA oder HTTPS bereit. Diese Übersetzerfunktion macht es zum praktischen Brückenkopf der IT/OT-Konvergenz, ohne dass die Steuerungsebene selbst angefasst werden muss.

Die Datenvorverarbeitung am Edge — Aggregation, Filterung, einfache Anomalieerkennung — reduziert Latenz und Bandbreite und ermöglicht Reaktionen, ohne den Umweg über das Rechenzentrum. Genau hier liegt der Unterschied zu einer reinen Protokoll-Bridge: Ein Edge Gateway kann Container oder Edge-Logik ausführen und wird damit selbst zu einem Deployment-Ziel. Moderne Gateways laufen häufig auf Linux mit Container-Runtime — oft mit schlanken Kubernetes-Distributionen wie k3s —, was sie für Industrial DevOps interessant macht. Architektonisch spielen sie zudem die Schlüsselrolle im Unified-Namespace-Ansatz: Das Gateway publiziert normalisierte Maschinendaten per MQTT (häufig mit Sparkplug B) in eine zentrale, semantisch strukturierte Datendrehscheibe, aus der sich MES, Cloud und Analytik gleichermaßen bedienen.

Damit wird das Edge Gateway aber auch ein sicherheitsrelevanter Knoten: Es steht mit einem Bein in der OT-Zone und mit dem anderen in der IT und muss sauber in die Netzwerksegmentierung nach IEC 62443 eingeordnet werden. Typische Stolpersteine sind ungemanagte Wildwuchs-Gateways ohne zentrale Update-Strategie, fehlende Geräte-Identitäten und das Versäumnis, Firmware und Edge-Workloads über dieselbe versionierte Pipeline auszurollen wie übrige Software. Das vergessene Gateway unter der Maschine, seit drei Jahren ungepatcht und mit einem Bein in der OT-Zone, ist dabei kein Ausnahmefall — beim Audit fällt genau dieses Gerät als erstes auf.

// Beispiele aus der Praxis2 Szenarien
/01

Brownfield-Anbindung ohne SPS-Eingriff

Ein Maschinenbauer liest ältere Anlagen über ein Edge Gateway per S7- und Modbus-Treiber aus und stellt die Daten normalisiert per MQTT bereit, ohne in die bestehende, validierte SPS-Programmierung einzugreifen.

/02

Containerisierte Edge-Workloads per GitOps

Ein Fertigungsbetrieb betreibt auf seinen Edge Gateways eine Container-Runtime und rollt Vorverarbeitungs- und Monitoring-Container über ein GitOps-Repository aus, sodass alle Gateways denselben versionierten, reproduzierbaren Stand fahren.

// Häufige FragenFAQ
Was ist ein Edge Gateway?
Ein Edge Gateway ist ein Gerät an der Schnittstelle zwischen OT und IT, das Maschinendaten erfasst, zwischen Feldprotokollen wie Modbus oder S7 und IT-Protokollen wie MQTT oder OPC UA übersetzt, am Edge vorverarbeitet und sicher weitergibt. Es ermöglicht die Anbindung von Bestandsanlagen an IT- und Cloud-Systeme, ohne in die validierte Steuerungslogik einzugreifen — und ist damit ein zentraler Baustein der IT/OT-Konvergenz.
Worin unterscheidet sich ein Edge Gateway von einer SPS?
Eine SPS steuert physische Prozesse in Echtzeit und ist auf deterministisches Verhalten ausgelegt. Ein Edge Gateway steuert in der Regel nichts sicherheitskritisch, sondern sammelt, übersetzt und verarbeitet Daten an der Grenze zwischen OT und IT. Beide ergänzen sich: Die SPS regelt, das Gateway vermittelt.
Wie hält man die Software auf vielen Edge Gateways aktuell?
Über eine zentrale, versionierte Update-Strategie — idealerweise dieselbe CI/CD- oder GitOps-Pipeline wie für übrige Workloads, ergänzt um signierte Artefakte, Staging-Rollout und Rollback. Manuelle Updates pro Gerät skalieren nicht und führen schnell zu inkonsistenten, schwer auditierbaren Ständen.
Gehört ein Edge Gateway in die IT- oder die OT-Zone?
In der Praxis liegt es meist in einer eigenen, kontrollierten Übergangszone, häufig in einer industriellen DMZ. Es darf weder die OT-Segmentierung aufweichen noch ungefiltert in die IT durchreichen. Geräte-Identität, Zertifikate und klar definierte Conduits nach IEC 62443 sind hier entscheidend.
Wann lohnt sich ein Edge Gateway — und wann reicht die direkte Anbindung?
Ein Edge Gateway lohnt sich, sobald Bestandsmaschinen ohne moderne Schnittstellen angebunden, mehrere Feldprotokolle vereinheitlicht oder Daten vor der Übertragung gefiltert und gepuffert werden müssen. Spricht eine neue Maschine dagegen bereits nativ OPC UA oder MQTT und ist die Netzwerksegmentierung geklärt, kann die direkte Anbindung genügen — das Gateway wäre dann nur eine zusätzliche Komponente, die gepflegt werden will.
Was ist der Unterschied zwischen einem Edge Gateway und einem IoT-Gateway?
Die Begriffe überlappen stark; der Unterschied liegt im Einsatzkontext. Ein IoT-Gateway bindet typischerweise Sensoren und Geräte an eine Cloud-Plattform an. Ein industrielles Edge Gateway spricht zusätzlich Feldprotokolle wie PROFINET oder S7, muss in die IEC-62443-Segmentierung passen und führt oft eigene Edge-Workloads aus — es ist die robustere, OT-taugliche Ausprägung derselben Idee.
// Ihre Einschätzung1 Klick, anonym

Wo steht Ihr Team bei Edge Gateway?

Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.

// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance