Souveränität vor Skalierung: Edge, Hybrid und die 100-ms-Frage in der Industrie

Wenn wir in industriellen Projekten die Architekturfrage diskutieren, kommt fast immer dieselbe Spannung auf: Cloud skaliert schnell und bequem, aber die Randbedingungen der Industrie – Latenz, Offline-Fähigkeit, Datenklassifikation, Jurisdiktion – zwingen uns oft an den Rand der Cloud, sprich: auf Edge und On-Premise. In der Pilotenausbildung (Cloud-Plattform mit Simulatoranbindung) ist die Cloud sinnvoll, sobald es um Auswertung, Kursmanagement und Langzeitspeicherung geht. In Bahn-Fleet-Intelligence-Systemen waren Edge- und On-Premise-Anteile unverhandelbar, weil Züge Funklöcher haben und Betriebsdaten nicht einfach das Werk verlassen dürfen.

Dieser Beitrag dreht sich um genau diese Abwägung. Nicht “Cloud vs. Edge” als Glaubensfrage, sondern als Ingenieursentscheidung mit klaren Kriterien und Mustern. Souveränität dient dabei als Leitplanke: Wer darf wann worauf zugreifen, wer kann notfalls ohne Dritte weiterarbeiten, und wer besitzt die operative Kontrolle über Laufzeit, Modelle und Datenlebenszyklus?

Ein Entscheidungsrahmen in vier harten Constraints

Bevor wir über Technologie sprechen, prüfen wir vier harte Constraints. Sobald eines davon “rot” ist, ist Edge/On-Premise kein “Nice-to-have”, sondern Pflicht:

1) Latenzbudgets

  • Wird innerhalb von 100 ms eine Aktion erwartet (z. B. visuelle Inspektion mit Stop/Go-Entscheidung, sicherheitsrelevante Anomalie-Erkennung, Taktzeiten an der Linie)? Dann sind Roundtrips in entfernte Rechenzentren praktisch raus. Nicht die theoretische RTT zählt, sondern das Ende-zu-Ende-Budget: Sensor → Vorverarbeitung → Inferenz → Entscheidung → Aktor.

2) Offline- und Degradationsbetrieb

  • Kann die Anlage ohne WAN/Konnektivität für Stunden oder Tage weiterlaufen? Wenn nicht, ist lokale Autonomie erforderlich – inklusive Konfigurationscache, Zwischenspeicherung und nachvollziehbaren Entscheidungsprotokollen.

3) Datenklassifikation und Zugriffskontrolle

  • Verlassen Daten der Klassen “personenbezogen”, “betriebsgeheim”, “kritische Infrastruktur” überhaupt das Werk/den Zug/die Leitwarte? Wenn die Antwort “nein” ist, bestimmt die Klassifikation die Architektur – nicht die Bequemlichkeit einer API.

4) Lieferkette und Jurisdiktion

  • Können Sie im Audit belegen, wer technischen Zugriff auf Laufzeit, Speicher und Modellartefakte hat? Können Sie auch ohne Anbieter X weiterarbeiten (Vendor-Exit)? Wenn hier Unklarheit herrscht, kippt die Architektur Richtung On-Prem-Infrastruktur, die Sie selbst kontrollieren.

Warum 100 ms den Unterschied machen

Ein Beispiel aus der Fertigung: Kamera (30 FPS) überwacht eine Station, ein Modell erkennt Montagefehler. Die harmlose Aussage “100 ms sind doch nichts” relativiert sich, sobald man das Budget explizit aufteilt:

  • Sensoraufnahme + DMA auf Edge-GPU: 5–12 ms
  • Vorverarbeitung (Entzerrung, Zuschneiden, Normalisierung): 5–20 ms
  • Inferenz: 10–30 ms (abhängig vom Modell, Batch=1, INT8/FP16)
  • Postprocessing (NMS, Heuristiken), Entscheidung: 5–15 ms
  • Ansteuerung Aktor/PLC: 5–10 ms

Selbst in einem optimierten Edge-Pfad liegen wir häufig bei 40–80 ms. Jede zusätzliche Netzwerk-Latenz und Jitter verschiebt das System in den unsicheren Bereich. Selbst wenn die pure RTT unter 20 ms liegt, addieren sich Pufferung, TLS-Handshakes, (De-)Serialisierung, Gateways, Shared Network Contention. Und Jitter ist tückischer als Mittelwerte. Die einfachste, robusteste Antwort ist Co-Location: Sensorik, Inferenz und Aktorik so dicht wie möglich beieinander, Shmem oder Zero-Copy zwischen Prozessschritten, und nur asynchrone Telemetrie nach “oben”.

Offline zuerst: Betrieb ohne Netz ist eine Funktion, kein Fehlerzustand

In Bahnsystemen gilt: Funklöcher sind nicht “Edge Case”, sondern Normalfall. Daraus folgen Architekturprinzipien:

  • Lokale Wahrheit: Entscheidungen, Logs und Metriken werden vor Ort als Append-only-Log geschrieben (z. B. lokaler Commit-Log). Cloud synchronisiert später über idempotente Replays mit deduplizierten Offsets.
  • Asynchrone Priorisierung: Kritische Ereignisse bekommen vorrangige, komprimierte, signierte Exporte; Bulk-Rohdaten folgen nachrangig, wenn Bandbreite vorhanden ist.
  • Deterministische Reproduzierbarkeit: Die Edge-Software muss im Nachgang erklären können, warum eine Entscheidung getroffen wurde – inklusive Modellversion, Feature-Konfiguration, Checksummen der Artefakte.
  • Schutz gegen Split-Brain: Konfigurationen sind versioniert, signiert und besitzen klare Gültigkeitsintervalle; Edge akzeptiert nur vorab autorisierte Updates.

Datensouveränität technisch umgesetzt

Souveränität ist kein Policy-Dokument, sondern ein technischer Zustand. Drei konkrete Punkte:

  • Daten am Rand verarbeiten: Feature-Extraktion, Pseudonymisierung/Maskierung und Entscheidung am Edge; nur notwendige, verdichtete Merkmale verlassen den Ort.
  • Kontrolle über Laufzeit und Artefakte: Container-Registry, Modell-Repository, Zugriffsschlüssel, Zertifikate – alles unter Ihrer Domäne. Kein Ausfallschlüssel eines Dritten, kein “Support-Backdoor”.
  • Nachvollziehbarkeit als Standard: Jede Entscheidung führt ihren Provenienz-Stammbaum mit (Modell-ID, Datenquellen, Konfigurationen). Das gilt für klassische ML ebenso wie für LLM-Agenten, die Workflows automatisieren.

Protokollwahl für industrielle Datenströme: MQTT, OPC UA, Kafka

Kein Protokoll “gewinnt” universell. Die Auswahl folgt dem Pfad der Daten:

  • Gerät/Steuerung → Edge Broker/Gateway
  • MQTT: Leichtgewichtig, pub/sub, gut für Sensor-Telemetrie, variable QoS, geringe Overheads, hervorragend bei intermittenter Konnektivität. Themenhierarchien erleichtern Multi-Tenant-Layouts vor Ort.
  • OPC UA: Reichhaltiges Informationsmodell, Adressraum, Typisierung – ideal, wenn Steuerungen/Anlagen semantisch sauber angebunden werden müssen und Interoperabilität mit SPS/SCADA zählt.
  • Edge/Site → Zentrale Verarbeitung
  • Kafka: Widerstandsfähiger, verteilter Commit-Log für hohe Durchsätze und Retention; gut als Backbone für Events, ML-Pipelines, Replays in der Zentrale. Eignet sich als “Wahrheitsschicht” für verteilte Verbraucher.

Bridging-Muster, die sich bewährt haben:

  • Lokaler MQTT/OPC-UA-Broker spricht mit Geräten; ein Edge-Connector mappt Topics/Nodes verlustfrei in Kafka-Topics im Rechenzentrum (on-premises).

  • Schema-Management am Backbone, nicht am Rand: Avro/Protobuf-Schemata in der Zentrale versionieren, Edge-Connector validiert vor dem Egress.

  • Sicherheit Ende-zu-Ende: mTLS zwischen Gerät und Edge-Broker; mTLS oder SASL/TLS Richtung Kafka. Zertifikatsrotation offlinefähig, CRLs oder Kurzläufer-Zertifikate per Out-of-Band-Update.

Fleet Management: Tausende Edge-Knoten sicher steuern

Wer hunderte bis tausende Edge-Knoten betreibt, braucht einen Flotten-Ansatz – keine SSH-Session-Kultur.