Edge vs. Cloud im IIoT: Wann On-Premise die einzige Option ist – und wie man es richtig baut

Wir haben in den letzten Jahren zwei Extreme gebaut: eine Cloud-Plattform für Pilotenausbildung mit globaler Skalierung und ein Fleet-Intelligence-System für Eisenbahnnetze, das mit zeitkritischen, sensiblen Daten unter harschen Netzwerkbedingungen umgehen muss. Beide Systeme sind “AI-gestützt”, aber sie unterscheiden sich in einem Punkt fundamental: Souveränität. In der Ausbildung ist Cloud sinnvoll, solange personenbezogene Daten kontrolliert bleiben. Im Bahn- und Defense-Umfeld ist On-Premise die einzige Option – nicht aus Ideologie, sondern aus Technik und Recht.

Dieser Artikel ist eine nüchterne Entscheidungs- und Architekturhilfe für CTOs und VP Engineering in industriellen Umfeldern. Er beschreibt, wann Sie die Cloud nutzen sollten, wann Edge/On-Prem alternativlos ist, und welche konkreten Bausteine sich bewährt haben. Kein “KI ist wichtig”-Marketing, sondern Architekturen, Latenzbudgets, Protokollwahl, Sicherheitsmodelle und Rollout-Strategien, die in der Praxis funktionieren.

Problem zuerst: Warum “Cloud-first” in der Industrie oft scheitert

Die drei Hauptgründe, die Projekte zum Kippen bringen, tauchen immer wieder auf:

  • Latenz und Jitter: Produktionsschritte, Stellwerksentscheidungen oder Condition-Monitoring in geschlossenen Regelkreisen haben teils <100 ms End-to-End-Budgets. WAN-Jitter und unvorhersehbare Pfade ruinieren deterministische Reaktionszeiten.
  • Souveränität und Recht: Daten mit strategischer Relevanz (Defense), betriebsgeheimnis-trächtige Prozessdaten (Fertigung) oder personenbezogene Inhalte (Kameras, Audio) dürfen die Site oder das Land nicht verlassen – DSGVO, Betriebsrat, Exportkontrolle, Sicherheitsvorgaben. “Pseudonymisierung in der Cloud” reicht in der Praxis oft nicht.
  • Konnektivität: Züge, Baustellen oder Werksgelände sind oft nur intermittierend verbunden. Ein zentrales Cloud-Broker-Design ist schlicht nicht robust genug, wenn Linkausfälle normal, nicht Ausnahme, sind.

Wenn eine dieser drei Dimensionen hart ist, ist On-Premise keine philosophische Diskussion, sondern eine funktionale Anforderung.

Ein Entscheidungsrahmen in fünf Fragen

Wenn Sie diese Fragen mehrheitlich mit “ja” beantworten, ist Edge/On-Premise die Default-Entscheidung:

1) Muss das System deterministisch unter 100 ms reagieren, auch bei Netzwerkproblemen?
2) Dürfen Rohdaten das Werk/Standort/Land niemals verlassen, auch nicht temporär?
3) Gibt es Air-Gap-Anforderungen oder streng segmentierte Netze (Defense/KritIS)?
4) Erfordert der Betrieb kontinuierliche Verfügbarkeit trotz intermittierender WAN-Verbindungen?
5) Sind die Egress-Kosten oder Vendor-Lock-in-Risiken wirtschaftlich nicht vertretbar?

Cloud ist sinnvoll, wenn Sie überwiegend analytische Workloads, aggregierte Daten, lange Batch-Fenster, globale Nutzerzugriffe oder elastische Trainingsressourcen benötigen – und wenn Datenklassifizierung und Verträge das zulassen.

Architektur, die in der Praxis trägt: Bausteine für souveräne IIoT-Systeme

1) Datenerfassung und Protokolle an der Maschine

  • OPC UA, wenn Sie strukturierte Informationsmodelle, Browsing, Alarme/Zustände und sichere, stateful Verbindungen in Shopfloor-Netzen benötigen. OPC UA PubSub ermöglicht zudem Publisher-Szenarien ohne harte Client/Server-Kopplung.
  • MQTT, wenn Sie leichtgewichtige, robuste Pub/Sub-Verteilung über heterogene und flappige Links brauchen. Für den Shopfloor empfiehlt sich Sparkplug B, um Zustandsfulness (Birth/Death), Hierarchien und klar definierte Topic-Semantik zu erhalten.
  • Kafka (oder kompatible Event-Streams) als hochvolumiger Backbone in Rechenzentrumsnähe (Werk, Rechenzentrum, rolling stock gateway). Nicht ins WAN “strecken”, sondern per Edge-Gateway bundeln und resiliente Uploads fahren.

Bewährtes Muster: OPC UA am Gerät, Übersetzer/Gateway schickt semantisch reduzierte und normalisierte Events via MQTT/Sparkplug in den lokalen Backbone; in der Fabrik: MQTT-to-Kafka-Bridge mit klarer Topic-Namenskonvention und Schema-Registry.

2) Edge-Inferenz und lokale Datenhaltung

  • Inferenz-Engines: ONNX Runtime, TensorRT, OpenVINO, je nach Zielhardware. Wichtiger als der Name: feste Budgetierung. Beispiel für 100 ms Budget: 10–20 ms Capture/Preproc, 30–50 ms Inferenz, 10–20 ms Postproc, <10 ms Aktorik.
  • Daten-Minimierung: Bewahren Sie Rohdaten nur lokal und kurzzeitig in verschlüsselten Ring-Puffern auf (z. B. 24–72 Stunden), exportieren Sie nur Ereignisse, Features oder anonymisierte Snippets für spätere Modellverbesserung – wenn rechtlich zulässig.
  • Zeitreihen: Lokale Timeseries-DB (z. B. Influx/Timescale) oder ein append-only Log. Wichtig sind deterministische Schreiblatenzen und robustes Write-Ahead-Logging bei Stromausfall.

3) Control Plane für Tausende Edge-Geräte

  • Device Identity: Hardware-gebundene Identitäten per TPM 2.0/ATECC, mTLS mit kurzlebigen Zertifikaten (SPIFFE/SPIRE), kein statischer Schlüssel-Müll.
  • Desired vs. Reported State (Device Twin): Konfiguration und Softwarestände deklarativ verwalten. Die Geräte “ziehen” den gewünschten Zustand, auch wenn die Verbindung sporadisch ist.
  • Updates: A/B-Partitionen oder Container-Rollouts mit signierten Artefakten (TUF/Notary v2). Prozentuale, ringbasierte Ausrollungen (Dev ring → Pilotlinie → 10 % → 50 % → 100 %), integriert mit automatischen Health-Gates.
  • Remote Attestation: Vor der Annahme von Konfigs/Modellen attestieren Geräte ihre Integrität (Measured Boot, TPM-Quotes). In Defense/KritIS Standardvorgehen, nicht “nice to have”.

4) Datenpfad und Resilienz

  • Lokale Message-Broker sind First-Class Citizens. Ein zentraler Cloud-Broker ist optional, nicht kritisch fürs Tagesgeschäft.
  • Store-and-Forward: Edge-Gateways puffern, komprimieren, deduplizieren und schicken bei verfügbarer Bandbreite. Niemals unbounded Buffers – definierte Backpressure-Strategien.
  • Schema-Disziplin: Avro/Protobuf mit Schema-Registry. Entwickeln Sie echte Evolutionsregeln (back-/forward-kompatibel), sonst brechen Multi-Team-Integrationen.

5) Sicherheit und Segmentierung

  • Zero Trust im Werk: Jede Verbindung ist mTLS, Autorisierung ist service- und topic-genau. Kein “Flat Network”.
  • Secret-Lifecycle: Kurzlebige Tokens, dynamische Zertifikate, kein Langzeit-PSK. Schlüsselmaterial verlässt nie die Hardware-Trust-Anker.
  • Datenklassifizierung: Hart trennen zwischen personenbezogen, geschäftskritisch, irreversibel anonymisiert. Die Klassifizierung treibt Speicherdauer, Export-Pfade, Maskierung.

6) Observability und Zeit

  • Zeit ist die unsichtbare Abhängigkeit. PTP oder präzises NTP, sonst korrelieren Sie nie wieder Ereignisse über Maschinen hinweg.
  • Telemetrie: OpenTelemetry Collector am Edge, lokaler Prometheus/Log-Puffer. Asynchroner Export bei Bandbreite, niemals Live-Abhängigkeit von zentralen Dashboards.
  • Reproduzierbarkeit: Jede Modell-/Konfig-Version und jeder Inferenz-Trace sind rückverfolgbar. Ohne vollständige Auditkette scheitern Ursachenanalysen.