Edge vs. Cloud im IIoT: Souveränität als Architekturanforderung, nicht als Compliance-Checkliste

Wenn wir über industrielle IoT-Systeme sprechen, beginnt die Architektur nicht bei Protokollen oder Modellen, sondern bei der Frage: Wer kontrolliert in jedem Betriebszustand, was mit den Daten passiert? In Projekten für Pilotenausbildung (Cloud) und Fleet-Intelligence im Bahnsektor (Hybrid) hat sich gezeigt: Souveränität ist kein „nice to have“, sondern ein technischer Zwang, der Latenzbudgets, Deployment-Modelle, Update-Strategien, Protokollwahl und sogar die Form der ML-Pipelines prägt. Cloud ist dort stark, wo Elastizität, Kollaboration und globale Verfügbarkeit im Vordergrund stehen. Edge/On-Premise ist dort alternativlos, wo Bandbreite knapp, Latenz kritisch, Isolation erforderlich oder der Kontrollpfad nicht an Dritte delegiert werden darf. Zwischen beiden Welten liegt ein schmaler, aber definierbarer Hybrid-Korridor.

Was Souveränität in IIoT-Architekturen konkret bedeutet

Viele Diskussionen verwechseln Datenresidenz (wo liegen Bits) mit Souveränität (wer entscheidet technisch durchsetzbar, wer was wann tun kann). Für Systemarchitekturen ist Souveränität die Summe aus:

  • Kontrolle über den Control-Plane: Identitäten, Zertifikate, Schlüsselmaterial, Richtlinien, Softwarereleases. Wer hält Root of Trust? Wer darf Geräte „claimen“, Policies ändern, Software signieren?
  • Kontrolle über den Data-Plane: Welche Daten dürfen den Standort verlassen? In welcher Granularität, mit welcher Latenz, in welchem Format? Wer kann darauf zugreifen – auch in Störfällen und Notmodi?
  • Durchsetzungsfähigkeit: Policies sind keine Dokumente, sondern maschinell erzwingbare Regeln auf Gateways, Edge-Knoten und in der Datenverarbeitung. „Default Deny“ nach außen, explizite Freigaben nach innen.
  • Auditierbarkeit: Jede Konfigurationsänderung, jede Software-Freigabe und jeder Datenexport sind nachvollziehbar, signiert und rückverfolgbar – auch offline, mit späterer Synchronisation.

Erst wenn diese Fragen technisch beantwortet sind, lohnt die Diskussion über Cloud vs. Edge.

Nichtfunktionale Anforderungen, die On-Premise erzwingen

In der Praxis kristallisieren sich vier harte Treiber heraus, die Edge/On-Premise zur Pflicht machen:

1) Latenz und Determinismus

  • Geschlossene Regelkreise, sicherheitskritische Abschaltungen, hochfrequente Sensorik: Hier sprechen wir über Millisekunden bis wenige Dutzend Millisekunden als Budget. Jitter ist oft gefährlicher als Mittelwertlatenz.

  • Mensch-in-der-Schleife (HMI, Assistenzsysteme): Reaktionszeiten unter etwa 100–200 ms sind eine sinnvolle Zielgröße, damit Interaktionen „sofortig“ wirken.

  • Netzwerkpfade über das öffentliche Netz sind für solche Budgets inhärent unzuverlässig. Selbst „schnelle“ Verbindungen liefern keine garantierte Worst-Case-Latenz.

2) Bandbreite und Kosten

  • Hochauflösende Bild-/Videodaten, Vibrationsspektren, Ereignisströme aus dutzenden Maschinen: Das Rohdatenvolumen ist zu groß, um dauerhaft in die Cloud zu exfiltrieren. Edge-Vorverarbeitung und Verdichtung sind Pflicht.

3) Betriebsunabhängigkeit und Offline-Fähigkeit

  • Bahntunnel, Werksgelände mit Funklöchern, maritime oder militärische Einsatzszenarien: Netzpartitionen sind Norm, nicht Ausnahme. Systeme müssen autonom, sicher und nachvollziehbar weiterlaufen.

4) Kontrollierbarer Control-Plane

  • Wenn ein externer Identitäts- oder Update-Dienst ausfällt oder gesperrt wird, darf nicht die gesamte Flotte stehen. Root of Trust, CA, Paket- und Container-Registry müssen On-Premise beherrschbar sein.

Eine Edge-Referenzarchitektur, die in der Praxis trägt

„Edge“ ist kein einzelnes Gerät, sondern ein verteiltes Subsystem mit klaren Schichten. Bewährt hat sich folgender Aufbau:

  • Hardware
  • Industrielle Gateways/Server mit x86/ARM, optional GPU/TPU. Redundante NICs, HW-Root-of-Trust (TPM/SE), out-of-band Management.
  • Betriebssystem und Laufzeit
  • Härtbare Distros (z. B. Yocto-basiert, Ubuntu Core), unveränderliche Basissysteme mit atomaren Upgrades (z. B. OSTree).
  • Containerisierung mit Podman oder Kubernetes-Varianten (k3s/microk8s) für deklaratives Deployment und Isolierung.
  • Messaging und Datenerfassung
  • Feldprotokolle/PLCs: OPC UA (Client/Server oder PubSub), Feldbus-Adapter.
  • Gerät-zu-Gateway: MQTT mit TLS, mutual auth, QoS 1/2 bei Bedarf. Lokale Retained Messages und Backpressure-Handling.
  • Gateway-zu-Zentrale: Streaming-Brücke Richtung Kafka (Protobuf/Avro, Schema-Registry), optional Pufferung (lokale Zeitreihen-DB oder Append-Only-Log in Parquet/Segmentdateien).
  • Verarbeitung am Rand
  • Regel- und Alarm-Engines, Feature-Extraktion, Kompression/Filtering, Inferenz mit ONNX Runtime/TensorRT/OpenVINO.
  • A/B-/Shadow-Inferenz: Neue Modelle laufen schattiert mit, vergleichen Ausgaben, bevor sie live schalten.
  • Policy- und Governance-Schicht
  • Outbound-Filter: Nur geprüfte, aggregierte Daten verlassen den Standort. PII-/Betriebsgeheimnisse werden an der Quelle entfernt/aggregiert.
  • OPA (Open Policy Agent)-artige Richtlinien am Gateway, signiert, versioniert, offline auswertbar.
  • Sicherheit und Identitäten
  • Gerätezertifikate aus eigener PKI, Enrollment via EST/ACME/SCEP-ähnlichen Flows, erneuerbar ohne Internet.
  • Signierte Container-Images (Cosign), Verified Boot, Secure Update mit Rollback.
  • Updates und Flottensteuerung
  • Delta-Updates, gestaffelte Rollouts (Canary), Fensterplanung, erzwungene Pausen bei Anomalien.
  • Desired-State-Ansatz: Zentrale deklariert Ziel, Edge reconciliert autonom, meldet Status/Ereignisse asynchron.

Worauf die Cloud (oder das On-Prem-Cluster) wirklich gut ist

Selbst wenn Inferenz und Steuerung am Rand passieren, braucht es einen starken „Hub“:

  • Speicher/Compute
  • Objektspeicher (S3-kompatibel) für Roh- und abgeleitete Daten, Ceph/MinIO-Cluster On-Prem oder europäische Cloud.
  • Streaming-Layer (Kafka/Pulsar) mit Schema-Registry. Trennung von Topics für Betriebsdaten, Telemetrie, Events, Modelle.
  • ML-Ops
  • Trainingsumgebung auf Kubernetes/Slurm mit GPU-Nodes, reproduzierbare Pipelines (Feature Store, Datenversionierung), Model Registry, signierter Release-Prozess.
  • Observability
  • Metriken, Logs, Traces für Edge- und Hub-Komponenten, End-to-End-Korrelation von Ereignissen bis Modellversionen.
  • Governance
  • Freigabe-Workflows: Jedes Modell/ jede Policy ist nachvollziehbar, signiert, mit Audit-Trail bis zum Commit/Datensatz.
  • Datenveredelung
  • Aggregierte Analysen, Dashboards, Flottenzustand, Predictive-Model-Training mit Daten, die bewusst freigegeben wurden.

Protokollwahl in der Praxis: MQTT, OPC UA PubSub oder Kafka?

Die richtige Wahl ergibt sich aus Kommunikationsrichtung, Gerätetyp und Zuverlässigkeitsanforderungen. Aus der Praxis: