Edge Computing vs. Cloud Computing im IIoT ist keine Entweder-oder-Entscheidung: Die eigentliche Frage ist, welche Logik direkt an der Maschine läuft und welche zentral. Dieser Artikel vergleicht beide Ansätze bei Latenz, Bandbreite, Ausfallsicherheit, Sicherheit und Kosten und zeigt dann ein hybrides Design, bei dem ein Edge-Knoten schnelle Entscheidungen lokal trifft und zusammengefasste Ergebnisse an einen Cloud-MQTT-Broker veröffentlicht.
Begriffe im industriellen Kontext
Edge Computing bedeutet, Daten in oder nahe der Fertigung zu verarbeiten: in einer SPS, einem Industrie-PC, einem Gateway oder einem kleinen Server im Werk. Auf die Daten wird reagiert, bevor sie den Standort verlassen.
Cloud Computing bedeutet, Daten zentral in einer öffentlichen oder privaten Cloud zu verarbeiten: Speicherung, Analysen, Dashboards, Training von Machine-Learning-Modellen und standortübergreifendes Reporting.
Zwischen beiden liegt die Messaging-Schicht. In den meisten modernen IIoT-Systemen ist das MQTT: Edge-Geräte veröffentlichen, Cloud-Dienste abonnieren, und der Broker entkoppelt sie, sodass sich jede Seite ändern kann, ohne die andere zu beeinträchtigen.
In Industrie-4.0-Projekten wird diese Schicht meist als Unified Namespace (UNS) organisiert: Die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Edge-Knoten veröffentlichen in ihren Zweig des UNS, und Cloud-Dienste, MES und ERP abonnieren genau die Ebenen, die sie brauchen. Wie Sparkplug B dazu passt, erklärt Sparkplug B und Unified Namespace.
Edge Computing vs. Cloud Computing im IIoT: Gegenüberstellung
| Faktor | Edge Computing | Cloud Computing |
|---|---|---|
| Latenz | Millisekunden, kein WAN-Umlauf | Abhängig vom Internetpfad; zehn bis hunderte Millisekunden, manchmal mehr |
| Bandbreite | Rohdaten bleiben lokal; nur Ergebnisse werden gesendet | Jeder Wert muss das WAN durchqueren |
| Ausfallsicherheit | Arbeitet bei Internetausfällen weiter | Nicht verfügbar, wenn die Verbindung unterbrochen ist, außer die Edge puffert |
| Rechenkapazität | Durch lokale Hardware begrenzt | Elastisch, praktisch unbegrenzt |
| Standortübergreifende Sicht | Jeweils ein Standort | Alle Standorte, gesamte Historie, an einem Ort |
| Wartung | Hardware über Standorte verteilt, einzeln gepatcht | Zentrale Updates und zentraler Betrieb |
| Sicherheitsexposition | Daten bleiben im Werk | Daten verlassen das Werk, daher zählen Transport- und Zugriffskontrolle |
| Kostenprofil | Hardware im Voraus und Support vor Ort | Laufende, nutzungsbasierte Kosten, die mit dem Datenvolumen wachsen |
Keine Spalte gewinnt eindeutig. Jede Zeile verweist auf eine Klasse von Aufgaben, die auf eine der beiden Seiten gehört.
Was an den Edge gehört
- Sicherheits- und Regelkreise. Alles, was in Millisekunden reagieren muss oder nie vom Internet abhängen darf, bleibt in SPSen und Sicherheitssystemen. Die Cloud sollte niemals Teil eines Regelkreises sein.
- Hochfrequente Signalverarbeitung. Schwingungen mit Abtastraten im Kilohertzbereich, Netzqualitäts-Wellenformen und schnelle Zähler erzeugen weit mehr Daten, als Sie übertragen möchten. Berechnen Sie Merkmale (RMS, Spitzenwert, Frequenzbänder) lokal und veröffentlichen Sie diese.
- Lokale Alarme. Ein Überlaufalarm für einen Tank muss auch dann auslösen, wenn das WAN ausgefallen ist.
- Datenreduktion. Totbänder und Report by Exception reduzieren den Datenverkehr an der Quelle.
- Pufferung. Edge-Knoten puffern Daten während Ausfällen und spielen sie später ab, wie unter Store-and-Forward für MQTT beschrieben.
- Protokollübersetzung. Die Umwandlung von Modbus, OPC UA oder EtherNet/IP in MQTT ist von Natur aus lokal; siehe IIoT-Edge-Gateway.
Was in die Cloud gehört
- Standortvergleiche und OEE-Reporting. Um Linien in verschiedenen Werken zu vergleichen, müssen die Daten an einem Ort liegen.
- Langzeithistorie. Zeitreihendaten über Jahre lassen sich zentral günstiger und einfacher verwalten.
- Modelltraining. Machine-Learning-Modelle werden mit großen historischen Datensätzen auf elastischer Rechenleistung trainiert; das trainierte Modell kann anschließend wieder an den Edge ausgerollt werden.
- Geschäftsintegration. ERP-, Instandhaltungs- und Qualitätssysteme liegen in der IT, nicht in der Fertigung.
- Remote-Dashboards und mobiler Zugriff. Ingenieure und Führungskräfte außerhalb des Werks benötigen einen zentralen Endpunkt.
Das hybride Muster
Die praktische Antwort für die meisten Werke ist hybrid: am Edge rechnen, in der Cloud koordinieren und analysieren und beides mit MQTT verbinden.
Machine --> Edge node --> Cloud MQTT broker --> Cloud services
(100 Hz) - samples raw signal (TLS 8883) - dashboards
- local alarm (no WAN needed) - historian
- 1-minute aggregates - analytics
- publishes events + summaries
Der Edge veröffentlicht zwei Arten von Nachrichten: Ereignisse (Alarm ausgelöst, Alarm aufgehoben) in dem Moment, in dem sie eintreten, und Zusammenfassungen (Minimum, Maximum, Mittelwert pro Minute) nach festem Zeitplan. Die Cloud sieht den rohen 100-Hz-Datenstrom nie, es sei denn, ein Ingenieur fordert ihn ausdrücklich an.
Ein funktionierender hybrider Edge-Knoten in Python
Dieses Skript simuliert einen Sensor, der mit 20 Hz abgetastet wird. Es wertet bei jedem Messwert lokal einen Alarm aus, veröffentlicht Alarmwechsel sofort und veröffentlicht ein Aggregat pro Minute. Es verwendet paho-mqtt 2.x und den öffentlichen MQTT-Broker broker.connectmq.com, der für Tests und Prototypen gedacht ist; ändern Sie für den Produktivbetrieb Host, Port und Zugangsdaten.
import json
import math
import random
import statistics
import time
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PORT = 1883
CLIENT_ID = "edge-node-3c9d"
BASE = "connectmq/demo/edge-3c9d/plant1/line1/pump1"
SAMPLE_HZ = 20
WINDOW_S = 60
ALARM_ON = 78.0 # Grad C
ALARM_OFF = 74.0 # Hysterese
def read_sensor(t):
"""Simulierte Lagertemperatur mit langsamer Drift und Rauschen."""
return 70 + 6 * math.sin(t / 90) + random.gauss(0, 0.4)
def now_iso():
return datetime.now(timezone.utc).isoformat(timespec="milliseconds")
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.publish(f"{BASE}/status", "online", qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
protocol=mqtt.MQTTv5)
client.on_connect = on_connect
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
# Produktion: client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"); client.tls_set(); PORT = 8883
client.connect(BROKER, PORT, keepalive=60)
client.loop_start()
window = []
alarm = False
window_start = time.monotonic()
t0 = time.monotonic()
while True:
value = read_sensor(time.monotonic() - t0)
window.append(value)
# Edge-Logik: bei jedem Messwert ausgewertet, kein Netzwerk nötig
if not alarm and value > ALARM_ON:
alarm = True
# hier würden Sie zusätzlich einen lokalen Ausgang ansteuern, z. B. eine Signalsäule
client.publish(f"{BASE}/event", json.dumps(
{"ts": now_iso(), "type": "HIGH_TEMP", "state": "RAISED", "value": round(value, 2)}),
qos=1)
elif alarm and value < ALARM_OFF:
alarm = False
client.publish(f"{BASE}/event", json.dumps(
{"ts": now_iso(), "type": "HIGH_TEMP", "state": "CLEARED", "value": round(value, 2)}),
qos=1)
# Cloud-Zusammenfassung: eine Nachricht pro Fenster statt SAMPLE_HZ * WINDOW_S
if time.monotonic() - window_start >= WINDOW_S:
summary = {
"ts": now_iso(),
"window_s": WINDOW_S,
"samples": len(window),
"min": round(min(window), 2),
"max": round(max(window), 2),
"mean": round(statistics.fmean(window), 2),
"alarm": alarm,
}
client.publish(f"{BASE}/summary", json.dumps(summary), qos=1, retain=True)
print("summary", summary)
window.clear()
window_start = time.monotonic()
time.sleep(1 / SAMPLE_HZ)
Abonnieren Sie in einem zweiten Terminal, um den Unterschied zwischen dem Datenvolumen am Edge und dem, was die Cloud empfängt, zu sehen:
mosquitto_sub -h broker.connectmq.com -p 1883 -i edge-3c9d-viewer -t "connectmq/demo/edge-3c9d/#" -v
Der Knoten verarbeitet 1.200 Messwerte pro Minute, sendet aber nur eine Zusammenfassung plus gelegentliche Ereignisse. Die Alarmentscheidung fällt lokal und sofort; ist der Broker nicht erreichbar, funktioniert der lokale Alarm trotzdem. Ergänzen Sie für einen echten Einsatz eine festplattenbasierte Queue, damit während eines Ausfalls ausgelöste Ereignisse nicht verloren gehen.
Kostenbetrachtung ohne Hype
Edge-Hardware kostet Geld im Voraus und braucht jemanden, der sie vor Ort wartet. Cloud-Dienste kosten laufend Geld, und die Rechnung wächst meist mit dem Datenvolumen. Damit ist die Datenreduktion am Edge der größte einzelne Hebel für die Cloud-Kosten: Wenn Sie nur senden, was nötig ist, kommen Sie mit kleineren Tarifen, kleineren Datenbanken und weniger Bandbreite aus, besonders bei volumenabhängig abgerechneten Verbindungen wie MQTT über Mobilfunk. Der Haken: Daten, die Sie nie senden, lassen sich später nicht analysieren. Halten Sie Rohdaten daher eine Weile lokal vor, falls Ingenieure sie benötigen.
Sicherheit in einem hybriden Design
Die Verbindung vom Edge zur Cloud sollte immer ausgehend, verschlüsselt und authentifiziert sein. Der Edge-Knoten baut eine TLS-Sitzung zum Broker auf Port 8883 auf und nutzt dabei Zugangsdaten, die eigens für diesen Knoten ausgestellt wurden. Eingehende Ports ins Werksnetz sind nicht nötig, sodass das OT-Netz geschlossen bleibt, ganz im Sinne des Zonen-und-Conduit-Modells aus IEC 62443. Cloud-Konsumenten abonnieren mit eigenen Zugangsdaten. Der Leitfaden zu Industrial IoT mit MQTT ordnet dieses Muster in die größere Werksarchitektur ein.
Die Cloud-Seite wählen
Im hybriden Modell ist der Cloud-Broker die Drehscheibe, von der jeder Standort und jeder Konsument abhängt. Ihn selbst zu betreiben, heißt, TLS, Authentifizierung und Kapazitätsplanung für ein kritisches System zu verantworten. Ein verwalteter MQTT-Broker nimmt Ihnen diese Arbeit ab, und ConnectMQ bietet eine Bandbreite von gemeinsam genutzten Serverless-Brokern für Pilotprojekte bis zu Dedicated- und Bring-your-own-Cloud-Bereitstellungen für größere Rollouts. Integrationen wie Historians oder Datenbanken werden als gewöhnliche MQTT-Subscriber angebunden (Telegraf, Node-RED oder eigene Dienste), was die Architektur einfach und portabel hält. Wenn Broker für Sie generell neu sind, beginnen Sie mit was ein MQTT-Broker macht.
Verbinden Sie Ihren Edge mit ConnectMQ
Geben Sie Ihren Edge-Knoten in wenigen Minuten eine sichere Cloud-Drehscheibe. ConnectMQ bietet MQTT 3.1.1 und 5.0 über TLS, ausgestellte Zugangsdaten, einen Live-Topic-Explorer und Schwellwert-Alarmregeln zur Überwachung der Zusammenfassungen. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker ohne Kreditkarte und richten Sie das obige Skript darauf aus.
Häufig gestellte Fragen
Ersetzt Edge Computing das Cloud Computing im IIoT?
Nein. Beide lösen unterschiedliche Probleme. Der Edge übernimmt schnelle, lokale und bandbreitenintensive Aufgaben; die Cloud übernimmt standortübergreifende Analysen, Historie und Integration. Die meisten Systeme nutzen beides.
Mit welcher Latenz kann ich bei der Verarbeitung in der Cloud rechnen?
Das hängt vom Netzwerkpfad und der Region des Anbieters ab, typischerweise zehn bis hunderte Millisekunden mit gelegentlichen Spitzen. Für Dashboards und Analysen ist das in Ordnung, für Regelkreise nicht.
Verbessert Edge Computing die Sicherheit?
Das kann es, weil Rohdaten im Werk bleiben und nur Zusammenfassungen es verlassen. Die Edge-Knoten selbst brauchen aber weiterhin Patches, Härtung und sichere Zugangsdaten.
Wie hilft MQTT einer hybriden Architektur?
MQTT entkoppelt Produzenten und Konsumenten. Edge-Knoten veröffentlichen auf Topics, ohne zu wissen, wer sie konsumiert, sodass Cloud-Dienste ergänzt oder geändert werden können, ohne das Werk anzufassen.
