IoT-Gateway vs. Edge-Gerät: Die beiden Muster zum Abrufen von Anlagendaten von der Produktionsfläche

Wichtigste Erkenntnisse

• IoT-Gateway = Gerät, das Daten von vielen Sensoren/SPS aggregiert und an übergeordnete Systeme weiterleitet.
• Edge-Gerät = Gerät, das lokal auf den Daten rechnet, bevor (oder statt) sie weitergeleitet werden.
• Gateways minimieren Rechenleistung in der Anlage; Edge-Geräte verlagern Verarbeitung näher zum Sensor.
• Die meisten Anlagen benötigen beides: Gateway für Aggregation, Edge für latenzkritische Analysen oder bei beschränkter Bandbreite.
• Die richtige Wahl hängt von Datenmenge, Latenzanforderungen und Zuverlässigkeit der Verbindung ab.

Kurzantwort: Ein IoT-Gateway aggregiert Daten von vielen Sensoren und SPS und leitet sie an übergeordnete Systeme (OEE-Plattform, Cloud, Historian) weiter. Ein Edge-Gerät führt lokale Berechnungen an den Daten durch, bevor es weiterleitet (oder anstatt weiterzuleiten). Gateways zentralisieren Verarbeitung auf der höheren Ebene; Edge-Geräte verteilen sie. Die meisten Anlagen brauchen beides, Gateways zur Aggregation und Edge-Geräte für latenzkritische Analysen oder bei bandbreitenbegrenzten Standorten.

Was ein Gateway macht

Ein IoT-Gateway:

• Spricht mehrere Protokolle (Modbus, OPC UA, MQTT) zu Sensoren und SPS.
• Aggregiert die Daten.
• Übersetzt Formate.
• Puffert bei Verbindungsproblemen.
• Leitet nach oben an die OEE-Plattform, den Historian oder die Cloud weiter.

Gateways minimieren die Rechenanforderungen in der Anlage. Entscheidungen erfolgen in übergeordneten Systemen.

Was ein Edge-Gerät macht

Ein Edge-Gerät:

• Empfängt Daten von einer kleinen Gruppe von Sensoren (oft räumlich zusammenliegend).
• Führt lokale Verarbeitung aus, Anomalieerkennung, OEE-Berechnung, Regelkreise.
• Handelt lokal ohne Roundtrip in die Cloud.
• Leitet Ergebnisse (nicht Rohdaten) nach oben weiter.

Edge-Geräte verlagern Verarbeitung zum Sensor. Geringe Latenz, bandbreiten­sparend.

Wann ein Gateway verwenden

• Viele SPS und Sensoren sollen aggregiert werden.
• Verarbeitung erfolgt zentral (OEE-Plattform, Cloud).
• Die Bandbreite nach oben ist ausreichend.
• Latenzanforderungen sind moderat (Sekundenbereich).

Wann Edge verwenden

• Latenzanforderungen sind streng (unter einer Sekunde).
• Die Bandbreite nach oben ist begrenzt oder teuer.
• Die Konnektivität ist unzuverlässig; lokale Verarbeitung muss weiterlaufen.
• Das Rohdaten­volumen ist hoch (Bildverarbeitung, Schwingungen), aber Entscheidungen sind einfacher.

Hybride Muster

Die meisten realen Deployments kombinieren beides:

• Edge-Geräte an kritischen Assets für latenzkritische Analysen.
• Gateway, das Edge-Ergebnisse und weitere Sensordaten aggregiert.
• Cloud oder OEE-Plattform empfängt den aggregierten Stream.

Dieses Muster bewahrt die Vorteile von Edge dort, wo sie wichtig sind, und behält gleichzeitig die Aggregation auf Gateway-Ebene bei.

Was wo läuft

Edge:

• Anomalieerkennung bei Schwingungen.
• Visuelle Fehlererkennung (Vision).
• Echtzeit-OEE für eine einzelne Linie.
• Lokale Regelkreise.

Gateway:

• Protokollübersetzung.
• Datenpufferung.
• Aggregation über viele Assets.
• Formatnormalisierung.

Cloud / OEE-Plattform:

• Linienübergreifende Analysen.
• Trendanalysen.
• Multi‑Site-Konsolidierung.
• Prädiktive Modelle.

Häufige Fehler

1. Edge für alles. Verteilte Verarbeitung ist schwerer zu managen. Edge dort einsetzen, wo es sich auszahlt.

2. Gateway für alles. Verpasst die Latenz- und Bandbreiten­vorteile von Edge.

3. Unzureichende Edge‑Hardware. Edge-Geräte brauchen echte Rechenleistung für reale Workloads. Unterdimensionierte Geräte versagen unter Last.

4. Puffern überspringen. Verbindungsabbrüche passieren. Sowohl Gateway als auch Edge brauchen lokalen Speicher zur Wiederherstellung.

Sicherheitsaspekte

Beide Schichten brauchen Sicherheit:

• Authentifizierung gegenüber SPS und Sensoren.
• Verschlüsselter Transport nach oben.
• Geräteauthentifizierung gegenüber der Cloud.
• Update-Mechanismus für Sicherheitspatches.

Insbesondere Edge-Geräte benötigen einen verwalteten Aktualisierungsweg, sie sitzen am Netzwerkrand und sind häufige Angriffsziele.

Herstellerkategorien

Gateways: Hilscher netRAPID, Moxa, Advantech, Siemens IoT2050, Open‑Source‑Lösungen auf Industrie‑PCs.

Edge‑Geräte: NVIDIA Jetson (Vision/ML), Litmus Edge, Crosser, kundenspezifisches Linux auf Industriehardware.

Viele Anbieter verwischen die Grenze, Geräte, die beides tun. Nach Fähigkeiten bewerten, nicht nur nach Kategorie.

Wie OEE‑Plattformen beides konsumieren

Eine moderne OEE‑Plattform verbindet sich mit Gateways über OPC UA, MQTT oder REST. Sie verarbeitet die Outputs von Edge‑Geräten als abgeleitete Kennzahlen statt als Rohdaten. Die Plattform vereinheitlicht die Eingänge zu einer einzigen OEE‑Sicht.

Das OEE‑Modul von Fabrico integriert sich mit industriellen Gateways und Edge‑Geräten über OPC UA und MQTT und verarbeitet sowohl rohe als auch abgeleitete Eingänge zu einer einheitlichen OEE‑Sicht.

Sehen Sie, wie Fabrico das automatisch erfasst, OEE für die Fertigung erkunden oder Demo buchen.

Häufig gestellte Fragen

Ist Edge Computing dasselbe wie Fog Computing?

Fog Computing bezieht sich üblicherweise auf Verarbeitung am Netzwerkrand, ähnlich wie Edge. Anbieter verwenden die Begriffe leicht unterschiedlich.

Brauche ich sowohl Gateway als auch Edge?

Für die meisten Produktionsanlagen: ja. Gateways aggregieren breit; Edge übernimmt latenzkritische Aufgaben.

Wie hängt ein Unified Namespace damit zusammen?

Unified Namespace (UNS) ist eine Pub/Sub‑Architektur, oft über MQTT implementiert. Gateways und Edge‑Geräte publizieren beide in einen UNS.

Kann ich ML auf einem Gateway betreiben?

Manchmal. Leichtgewichtiges ML läuft auf Gateways. Leistungsintensives ML (Bildverarbeitung, Deep Learning) erfordert meist Edge‑Geräte mit GPU.

Welche Protokolle sollten Gateways unterstützen?

Mindestens OPC UA und MQTT. Modbus, Ethernet/IP und serielle Legacy‑Protokolle für ältere Geräte.