Edge vs. Cloud im Industrial AI: Wann On-Premise die einzige Option bleibt

Problem zuerst: In industriellen Systemen sind drei Dinge nicht verhandelbar – Verfügbarkeit, Determinismus, Souveränität. In der Praxis kollidieren genau diese Anforderungen mit den Komfortversprechen der Public Cloud. Ich habe Cloud-Plattformen für die Pilotenausbildung gebaut, wo Elastizität und globale Auslieferung zählen. Und ich habe Fleet-Intelligence-Systeme für Eisenbahnnetze gebaut, wo 2G-Funk, Tunnel und militärähnliche Betriebsanforderungen Realität sind. Diese Erfahrung hat meinen Blick geschärft: Es gibt valide Cloud-Use-Cases. Aber es gibt ebenso Szenarien, in denen On-Premise die einzige verantwortbare Architektur ist – insbesondere, wenn Datensouveränität nicht verhandelbar ist.

Dieser Beitrag gibt eine technische Entscheidungsgrundlage: wann Edge und On-Premise zwingend sind, wann Cloud sinnvoll ist, und wie hybride Architekturen robust gebaut werden. Ohne Marketingfloskeln, mit konkreten Architekturmuster, Latenzbudgets, Protokollentscheidungen und Betriebsmodellen.

Was Datensouveränität technisch bedeutet – jenseits von Schlagworten

Datensouveränität ist kein Paragraf, sondern ein technischer Zustand. Vier Fragen entscheiden, ob Sie ihn erreichen:

  • Datenlokalität: Können Sie erzwingen, wo Rohdaten, Zwischenartefakte und Modelle physisch gespeichert und verarbeitet werden? Nicht „region preferred“, sondern durch harte Netzwerkgrenzen, VLAN/VRF-Isolation, Air-Gap oder Data-Diode.
  • Schlüsselhoheit: Liegen Identitäten, Schlüsselmaterial und Signaturen unter Ihrer Kontrolle? Dazu gehören HSMs/TPMs on-prem, eigene PKI, Offline-Signing von Artefakten und kein externer KMS als Single Point of Failure.
  • Auditierbarkeit: Können Sie jede Datenbewegung, jeden Modellwechsel, jede abgesetzte Agentenaktion nachvollziehen – inkl. Reproduktion der Ausführung ohne Internetzugang?
  • Lieferkette und Rechtsraum: Welche Komponenten (Runtime, Images, ML-Frameworks) sind in welcher Jurisdiktion entstanden, und welche rechtlichen Durchgriffe sind theoretisch möglich? Technisch übersetzt: Minimierung externer Abhängigkeiten, reproduzierbare Builds, interne Artefakt-Repositories.

Wenn eine dieser Fragen mit „Nein“ beantwortet wird, sind Sie nicht souverän. Das ist in Defense und kritischer Infrastruktur nicht akzeptabel.

Latenz und Determinismus: Warum 100 ms den Unterschied machen

In Produktionsumgebungen zählt nicht die durchschnittliche Latenz, sondern das 99,9-Perzentil – und die garantierte Obergrenze. Eine scheinbar kleine Abweichung von 100 ms kann zwischen „Produkt gut verpackt“ und „Anlage stoppt“ entscheiden. Beispiele:

  • Visuelle Fehlererkennung in der Linie: 60 fps Kamera bedeutet 16,7 ms pro Frame. Inferenz, Entscheidung und Aktuatorbefehl müssen in 100 ms führt zu verpassten Ausschleusungen.
  • Zustandsüberwachung mit Alarmen: Viele Systeme tolerieren Sekundenlatenz. Aber wenn Alarme in komplexe Workflows verzahnt sind (z. B. Bahnleitstellen), sind Worst-Case-Latenzen und deterministische Reihenfolgen (Total Ordering) entscheidend.

Diese Anforderungen schließen Remote-Inferenz über WAN aus. Selbst „niedrige“ Cloud-Latenzen kollabieren unter Jitter, Congestion und Retransmits. Konsequenz: Platzieren Sie Inferenz und Regelung möglichst nah an der Datenquelle (Edge-Node oder On-Prem-Cluster). Zentralisieren Sie nur, was von Natur aus tolerant ist: Training, Flottenauswertung, Reporting.

Protokollwahl: MQTT, OPC UA, Kafka – wofür, wo und wie gekoppelt

Es gibt kein „one size fits all“. Die robuste Pipeline nutzt mehrere Protokolle, klar abgegrenzt:

  • OPC UA an der OT-Grenze: Stärken sind Datenmodellierung, Typensysteme, Zugriffskontrolle und sichere Sessions zu SPS/Leitsystemen. In modernen Setups mit Publisher/Subscriber und TSN erreichen Sie deterministische Zustellung auf der Zellebene. Schwäche: Overhead und Komplexität außerhalb des OT-Kontexts.
  • MQTT für Edge-Telemetrie: Leichtgewichtig, Topic-basiert, gut für intermittierende Verbindungen (QoS 1/2, Retained Messages, Last Will). Ideal für Edge-zu-Aggregator-Kommunikation im Werk. Schwäche: Kein eingebautes Schema-/Typen-Management; erfordert Disziplin (Topic-Taxonomie, Payload-Schema).
  • Kafka als On-Prem-Datendrehscheibe: Stark in Durchsatz, Partitionierung, Replikation und strenger Ordering-Garantie pro Partition. Ideal für Event-Sourcing, Stream Processing und als zentrale Backbone zwischen Diensten im Rechenzentrumssegment des Werks.

Bewährte Koppelungsmuster:

  • OPC UA → Edge-Adapter → MQTT: Ein Adapter an der Zellen-Grenze mappt UA-Knoten auf MQTT-Topics, normalisiert Timestamps und fügt Qualitätsbits hinzu. Wichtig: Eine feste Topic-Konvention mit Versionierung (z. B. plant/line/station/signal:v2).
  • MQTT → On-Prem-Backbone (Kafka): Ein Bridge-Service konsumiert MQTT, validiert gegen ein Schema-Registry (z. B. Avro/Protobuf), bereichert Metadaten (Trace-ID, Device-ID, Clock-Offset) und produziert in Kafka-Topics. Backpressure wird in der Bridge erzwungen, niemals am Gerät.
  • Rückkanäle: Steuerkommandos laufen nicht über denselben Pfad. Entweder dediziertes Command-Topic mit strengen ACLs und Command-IDs (idempotent, mit TTL) oder direkte Steuerung in OPC UA Sessions. Niemals ungesicherte Wildcard-Subscriptions auf Edge-Seite.

Souveränität bedeutet hier: Broker und Backbone laufen On-Prem in Ihrer Domäne. Kein extern gehosteter MQTT-Broker, keine geteilten Kafka-Cluster. Identitäten und ACLs liegen in Ihrer PKI; Zertifikate für Geräte werden bei der Inbetriebnahme erstellt und regelmäßig rotiert.

Architekturpatterns, die in der Praxis tragen