Edge vs. Cloud im industriellen IoT: Wann On-Premise die einzige Option ist

Souveränität ermöglicht Intelligenz. Wer in Defense, kritischer Infrastruktur oder der vernetzten Produktion ernsthaft KI und IIoT skaliert, landet sehr schnell bei einer unbequemen Wahrheit: Die Cloud ist nicht das Default. Es gibt genügend Szenarien, in denen On-Premise die einzige Option ist – nicht aus Nostalgie, sondern aus harten technischen, regulatorischen und betrieblichen Gründen.

Dieser Beitrag betrachtet das Thema problemorientiert. Ich skizziere die Engineering-Entscheidungen, die wir in Projekten für Bahnen (Fleet Intelligence), die Luftfahrt (Pilotentrainingsplattform) und Defense-Umfelder wiederholt treffen mussten. Der rote Faden ist Datensouveränität: Architekturentscheidungen, die Unabhängigkeit und Kontrolle sichern, sind die Grundlage für zuverlässige, sichere und letztlich intelligente Systeme.

1. Vier harte Constraints, die die Cloud ausschließen

Es gibt vier technische Randbedingungen, die – jede für sich – Cloud-only-Architekturen disqualifizieren. In Kombination sind sie eindeutig.

  • Latenz und Determinismus:
  • Steuerkreise und Inspektionspipelines benötigen feste Latenzbudgets, oft im Bereich von 10–100 ms End-to-End. Es geht nicht nur um Mittelwerte, sondern um Jitter und deterministisches Verhalten.
  • WAN- und Internetpfade sind best-effort. Selbst bei nominal 20–40 ms RTT erzeugen Jitter, Congestion und Paketverluste unvorhersehbare Schwankungen, die geschlossene Regelkreise oder Sicherheitslogik destabilisieren.
  • Verfügbarkeit und Inselbetrieb:
  • Anlagen müssen auch bei WAN-Ausfall sicher und produktiv weiterlaufen. „Site Autonomy“ heißt: alle kritischen Pfade lokal, inklusive Persistenz, Identität, Caches, Modelle und Entscheidungslogik.
  • Cloud kann optional sein – niemals kritisch.
  • Datensouveränität und Regulatorik:
  • In Defense und kritischer Infrastruktur sind Datenräume, Schlüsselmaterial, Identitäten und Policies unter eigener Kontrolle zu halten. DSGVO ist Basis, aber die operative Souveränität geht darüber hinaus: Keine Exfiltration, nicht nur „wo liegt es“, sondern „wer kontrolliert den Stack“.
  • Datenminimierung ist nicht optional: Nur Features oder abgeleitete Artefakte verlassen die Anlage – wenn überhaupt.
  • Netzwerktopologie und Daten-Gravity:
  • Kamerastreams, Vibrationssensorik, Telemetrie aus tausenden Knoten: Die Rohdatenvolumina sind hoch, Bandbreiten kostbar. Sinnvolle Verdichtung, Feature-Extraktion und Filtering gehören an den Rand des Netzes.

Wenn Ihr System eines dieser Kriterien hart erfüllt, gibt es keine Diskussion: On-Premise/Edge zuerst. Cloud kann später Mehrwert liefern – Analytics, Flottenvergleich, Simulation, Retraining – aber nicht den Kernbetrieb dominieren.

2. Latenzbudget und deterministische Pfade: warum 100 ms den Unterschied machen

Es ist verführerisch, „schnelles Internet“ mit „schneller Steuerung“ gleichzusetzen. In der Praxis zählt jedoch deterministische End-to-End-Latenz inklusive Jitter-Budget. Beispiele:

  • Visuelle Fehlererkennung am Band:
  • Pipeline: Frame Capture → Preprocessing → Inferenz → Entscheidung → Aktorik/Abwurf.
  • Jedes Hop (Bilderfassung, Pre-/Postprocessing, Scheduler, IO) hat feste Budgets. Spikes von 30–50 ms ruinieren F1-Scores oder führen zu Fehlgriffen.
  • Remote-Assistance mit Sicherheitsfreigaben:
  • Mensch-in-der-Schleife mit HMI. 80–120 ms zusätzliche Latenz verändern Bedienbarkeit und Sicherheitsschwellen.

Edge-Pattern für deterministische Pfade:

  • Zeit-Synchronisation per PTP auf der Anlage; Zeitsensitive Netze (TSN) für deterministische Layer-2-Pfade.

  • Lokale Message-Broker und Shared-Memory-Plug-ins statt weite Netzwerk-Hops.

  • Inferenz auf GPU/TPU am Edge-Knoten, Postprocessing lokal; nur Entscheidungen oder komprimierte Features verlassen die Anlage.

  • Keine harten Abhängigkeiten zu Remote-Diensten im kritischen Pfad.

3. Site Autonomy: Inselbetrieb als Designziel

„Funktioniert auch offline“ ist kein nice-to-have. Es ist eine Architekturanforderung.

  • State-Management:
  • Ereignisorientierte Persistenz lokal (z. B. Event-Sourcing), Append-Only-Logs pro Anlage, idempotente Replay-Fähigkeit.
  • Lokale Stores wie RocksDB/SQLite pro Service, Snapshots als Recovery-Punkte.
  • Datenübertragung bei Wiederanbindung:
  • Store-and-forward mit Wasserzeichen; Konfliktlösung per Versionsvektoren, deterministische Merge-Strategien.
  • QoS-Levels für Telemetrie (kritisch, wichtig, best-effort) und gestaffelter Upload.
  • Identität und Secrets:
  • Lokaler Root-of-Trust: TPM-gestützte Schlüssel, Offline-CRL/OCSP-Spiegel.
  • Rollen- und Policy-Engine on-prem, mit eventual Consistency zur Zentrale.
  • Observability vor Ort:
  • Logs, Metriken, Traces lokal aggregiert; SLO-Monitoring auf Edge-Niveau.
  • Remote-Export, wenn Verbindung steht; keine Korrelation im WAN voraussetzen.

4. Datensouveränität praktisch: Minimieren, lokalisieren, kontrollieren

Souveränität ist kein PDF im Governance-Ordner, sondern Laufzeitverhalten.

  • Datenminimierung als Pipeline-Schritt:
  • Feature-Engineering am Edge. Aus Rohbildern werden Feature-Vektoren; aus Vibrationssignalen werden Spektralmerkmale. Rohdaten verbleiben lokal, Features sind einstellbar und auditierbar.
  • Herausgabe nur nach Policy: Freigabewege sind technische Gates, nicht Prozesse auf Zuruf.
  • „Feature export, not data export“:
  • Zentrale Analytik arbeitet auf abstrahierten, schematisierten Ereignissen.
  • Digital Twins im Backend referenzieren lokale IDs; Pseudonymisierung/Tokenisierung vor jedem Export.
  • Schlüssel- und Policy-Hoheit:
  • On-Prem KMS/HSM, alle Artefakte (Container, Modelle, Konfiguration) signiert; Verifikation am Edge.
  • Update-Policies und Rollbacks ohne externe Abhängigkeiten.

5. Protokolle richtig kombinieren: OPC UA, MQTT, Kafka – kein Entweder-oder

Wer in Brownfield-Umgebungen unterwegs ist, benötigt Brücken und klar getrennte Verantwortungsebenen.

  • Ebene Feld/PLC:
  • OPC UA für semantischen Zugriff auf Steuerungen, Browsing des Address Space, Typensysteme. Sinnvoll, wenn Engpass Steuerungsintegration ist.
  • OPC UA PubSub/TSN, wenn deterministische Kommunikation auf Layer 2 gebraucht wird.
  • Ebene Edge-Knoten:
  • MQTT für leichtgewichtige Pub/Sub zwischen Geräten und Edge-Services, QoS 1/2 bei sensibler Telemetrie, Retain für Zustände.
  • Topics klar namespacen: site/{id}/line/{id}/device/{id}/signal/{name}.
  • Ebene Linien-/Werksaggregation:
  • Kafka (oder kompatibel) als Hochdurchsatz-Backbone für normalisierte Ereignisse.
  • Schema-Registry (Avro/Protobuf) erzwingt Vertragstreue, Versionsierung und Abwärtskompatibilität.
  • Connectors/Bridges: OPC UA → MQTT Mapper; MQTT → Kafka Bridge mit Schematransformation.

Dieses Muster macht Systeme evolvierbar: Feldintegration bleibt stabil, Edge bleibt leichtgewichtig, und die Aggregation kann skalieren, ohne Geräte zu beeinflussen.

6. Flottensteuerung: Tausende Edge-Geräte, aber kein Kontrollverlust