Edge vs. Cloud im IIoT: Wann On-Premise die einzige Option ist – mit einer Referenzarchitektur für souveräne Systeme

Problem zuerst, nicht Technologie: In industriellen Systemen zählt nicht, ob „Cloud-first“ modern klingt oder ob das Edge-Gerät eine neue GPU hat. Entscheidend ist, welche technischen und regulatorischen Randbedingungen den Lösungsspielraum bestimmen. Aus Projekten in Luftfahrt (cloudbasierte Trainingsplattform) und Bahn (Fleet-Intelligence bei intermittierender Konnektivität) haben wir dieselbe Lektion gelernt: Souveränität, Latenz und Betriebsrealität schneiden durch jede schöne Architekturfolie. Und für sicherheitskritische oder streng regulierte Umgebungen ist On-Premise nicht Nostalgie – es ist oft die einzige Option, um überhaupt liefern zu können.

Im Folgenden skizziere ich eine Architektur, die wir in Varianten in Defense, Bahn und Fertigung einsetzen. Souveränität ist der rote Faden: Identität, Datenklassifikation, Betriebsmodell und Lieferketten werden so gebaut, dass Sie die Kontrolle behalten – nicht der Hyperscaler.

1) Der echte Problemrahmen: Vier harte Constraints

  • Souveränität und Recht: DSGVO, Auftragsverarbeitung, Betriebs- und Geschäftsgeheimnisse, Export-/Sicherheitsauflagen. „EU-Region“ in einer US-Cloud löst nicht den CLOUD-Act-Konflikt. Für Defense/Kritische Infrastruktur ist rechtliche und faktische Datenhoheit nur On-Premise oder über streng europäische Provider/Private Cloud erreichbar.
  • Latenz und Verfügbarkeit: Regelkreise unter 100 ms sind keine Cloud-Kandidaten. Auch 300 ms können bei visueller Ausschleusung fehlerhafter Teile zu spät sein. Netzabbrüche sind Normalfall (Tunnel, Funklöcher, Werksabschirmungen). Das System muss offline-fähig sein.
  • Netzwerkrealität: Hohe Paketverlustraten, asymmetrische Links, NAT, eingeschränkte Ports, manchmal Luftspalt. Backhaul von Rohvideo ist illusorisch – es sei denn, Sie bezahlen dafür, dass Ihre Anwendung unbenutzbar wird.
  • Lebensdauer und Wartbarkeit: Industrielle Assets laufen 10–20 Jahre. Software muss patchbar bleiben, SBOMs und CVE-Management sind Pflicht. OTA-Rollouts brauchen Staging, Rollback und verifizierte Artefakte – auch im Luftspalt.

2) Cloud sinnvoll, Edge zwingend: eine nüchterne Matrix

  • Cloud sinnvoll:
  • Trainings- und Simulationsplattformen mit stark schwankender Last, wenn Personenbezug minimiert oder sauber getrennt ist.
  • Zentralisierte Flottenanalyse, wenn Rohdaten vorverdichtet sind und Synchronisierung opportunistisch erfolgen darf.
  • Modelltraining und Feature-Engineering in einer souveränen Private Cloud/On-Prem-Cluster mit elastischer Orchestrierung.
  • Edge zwingend:
  • Inline-Inspektion mit visueller Ausschleusung, Zykluszeiten im zweistelligen Millisekundenbereich.
  • Autarke Betriebsfähigkeit bei Netztrennung, z. B. sicherheitsrelevante Assistenzfunktionen.
  • Defense/KRITIS, wo Datenabfluss, Cloud-Zugriffe oder externe Abhängigkeiten unzulässig sind.
  • Hybrid:
  • Edge-Inferenz, zentralisiertes Training. Daten werden am Edge klassifiziert, anonymisiert/verdichtet und nach Policy selektiv hochgespielt.
  • Digitale Zwillinge mit lokaler Wahrheit (Edge) und globaler Sicht (Zentrale), die sich eventual-konsistent synchronisieren.

3) Architekturbausteine: vom Sensor bis zum Leitstand

Geräte- und Feld-Ebene

  • Sensoren/PLCs/Kameras als Datenquellen. Bestehende OPC UA-Server an Maschinen sind Gold wert, wenn man sie richtig integriert.

  • Edge-Gateways auf x86/ARM mit TPM. OS gehärtet, Secure Boot, Festplattenverschlüsselung, read-only Root, signierte Updates.

Edge-Runtime

  • Containerisierte Workloads (OCI). Kubernetes-Varianten am Edge (k3s, microk8s) funktionieren, wenn das Ops-Team die Komplexität tragen kann. Sonst: systemd-Services mit einem leichten Supervisor und Pull-basierter Update-Logik.

  • Inferenz-Server (z. B. ONNX/TensorRT/OpenVINO) lokal, mit statisch gebauten Modellen und deterministischen Runtimes. Keine „Auto-Update“-Magie.

Messaging und Protokollwahl

  • MQTT: ideal für lossy Links und Pub/Sub. QoS 1/2, Retained Messages für Steuerkanäle, Session-Persistence für Offline-Resends. Topic-Design stringent versionieren und Namespacing für Flotten-Hierarchien einführen.

  • OPC UA: robust für Maschinenintegration, Zugriff auf semantisch reich strukturierte Daten. Für harte Echtzeit OPC UA PubSub über UDP/TSN – nicht über das Internet tunneln, sondern lokal nutzen und am Gateway auf MQTT/Kafka mappen.

  • Kafka: Backhaulkorridor im Rechenzentrum für hohen Durchsatz, Replaying, Event-Sourcing. Nicht auf jedem Edge-Gateway betreiben, sondern als zentrale Datenplattform. Bridge: MQTT→Kafka über Connect/Bridge, Schema-Validierung an der Kante.

Datenmodell und Schemata

  • Ereignis-Envelopes mit Metadaten: Gerät, Standort, Version, Klassifikation (PII, geschäftskritisch, Exportkontrolle), Hash/Signatur.

  • Binärformate (Avro/Protobuf) mit einem selbst betriebenen Schema-Registry. Hard Fail bei Schema-Verstoß an der Bridge, Soft Fail an der Kante mit Dead-Letter-Queues.

  • Zeitreihen lokal in einer leichten TSDB (z. B. eingebettete TSDB oder Timescale/Influx je nach Ressourcen) als Ringpuffer, der offline Tage übersteht.

Speicher und Synchronisation

  • Store-and-Forward: lokaler Outbox-Log mit Sequenznummern und Idempotenz-Keys. Backpressure muss bis zur Quelle propagieren (Drosselung der Kamera-FPS statt Dropping am Bus).

  • Delta-Sync mit Content-Addressing (z. B. Chunking und Hashes) für große Dateien (Modelle, Firmware, annotierte Samples).

Digitale Zwillinge

  • Lokaler Zwilling hält die letzte bekannte gewünschte Konfiguration und den aktuellen Ist-Zustand. Zentraler Zwilling aggregiert und berechnet Flottenzustand. Konflikte durch Last-Write-Wins vermeiden, besser: absichtsbasierte (intent-based) Zustände mit Änderungsgründen und Prioritäten.

4) Souveränität konkret umsetzen: nicht verhandeln, sondern bauen

Identität und Ende-zu-Ende-Sicherheit

  • Geräte-Identität ab Werk: Geräte-Zertifikate an TPM gebunden, Unique Device Secret. Enrollment über mTLS, kein gemeinsames Passwort, kein „goldenes“ Root-Zertifikat auf allen Knoten.

  • Workload-Identität: kurzlebige Zertifikate für Dienste (z. B. SPIFFE/SPIRE-Prinzip), Service-to-Service-mTLS auch am Edge. Keine impliziten Trusts über IP-Bereiche.

  • Schlüsselrotation automatisiert, Widerruf listenbasiert mit CRLs/OCSP, Edge-fähig gecacht.

Datenklassifikation am Ursprung

  • Sensor-Daten bereits am Edge taggen: PII, Betriebsgeheimnis, vertraulich/öffentlich. PII-Präfixe trennen Datenpfade in verschiedene Topics/Partitionen.

  • DLP-Filter am Gateway: z. B. Maskieren, Hashen, Downsampling, Region-of-Interest-Cropping für Bilddaten. Kein Rohvideo, wenn nicht für Training begründet und freigegeben.

  • Data Residency-Policies enforceable: Nachrichten mit bestimmten Labels verlassen das Werk nicht. Policy wird am Broker erzwungen, nicht nur „per Prozess“.