Edge vs. Cloud im IIoT: Wenn On-Premise die einzige sinnvolle Architektur ist

Problemstellung
In industriellen Systemen scheitert ein KI/IIoT-Projekt selten an der Frage, ob ein Modell 2% mehr F1-Score erreicht. Es scheitert daran, dass Daten dort bleiben müssen, wo sie entstehen, auch wenn Entwickler, Auditoren und Lieferanten gerne alles in eine bequeme Public Cloud kippen würden. Latenzvorgaben, intermittente Konnektivität, Safety- und Security-Zonen, Exportkontrolle, Geheimschutz und schlicht IP-Schutz machen viele Architekturen, die im Webumfeld „normal“ sind, im industriellen Umfeld unbrauchbar.

Ich habe in den letzten Jahren zwei Systeme gebaut, die diesen Spannungsbogen gut zeigen:

  • Cloud-basierte Trainingsplattform für Pilotinnen und Piloten: globaler Zugriff, hoher Compute-Bedarf, geringe Datenschutzsensitivität bei Rohdaten (synthetisch, instrumentiert), klare Cloud-Fit.

  • Fleet-Intelligence für Eisenbahnnetze: tausende Edge-Knoten entlang von Strecken, harte Echtzeit- und Verfügbarkeitsvorgaben, Betriebsgeheimnisse, behördliche Vorgaben – faktisch Edge-first, On-Premise, Cloud nur für sekundäre Auswertungen.

Dieser Artikel fasst zusammen, wann On-Premise die einzige Option ist, wie man Edge-Flotten in der Größenordnung tausender Geräte beherrscht, welche Protokolle im industriellen Datenpfad wirklich funktionieren und warum 100 ms Latenz den Unterschied zwischen „funktioniert auf der Folie“ und „besteht den Werksabnahmetest“ ausmachen. Roter Faden: Datensouveränität ist keine Marketingfloskel, sondern ein Architekturprinzip mit operativen Implikationen.

Wann Cloud sinnvoll ist – und wann Edge alternativlos ist
Die folgende Einteilung hat sich in Projekten als verlässlich erwiesen. Nicht als Dogma verstehen, sondern als Guardrails für Architekturentscheidungen.

Cloud-fähig (oder Hybrid, Cloud-gestützt)

  • Modelltraining auf aggregierten, bereits pseudonymisierten oder synthetisierten Daten

  • Flottenweite Analysen ohne Personen- oder streng vertrauliche Produktionsdaten (z. B. Anomalieraten, Fleet Health)

  • Simulationspipelines, digitale Zwillinge ohne Rückschluss auf konkrete Betriebsgeheimnisse

  • Nichtkritische Backoffice-Integrationen (z. B. Ticketing, Wissensmanagement)

Edge/On-Premise alternativlos

  • Safety-kritische Steuerkreise und Schutzfunktionen (Not-Halt, Kollisionsvermeidung, SIL/PL-relevante Pfade)

  • Operative Entscheidungen mit <100 ms End-to-End-Latenz oder starker Jitter-Sensitivität

  • Verarbeitung von Daten mit Geheimschutz, Exportkontrolle oder vertraglich strengen IP-Vorgaben

  • Anlagen in Zonen mit eingeschränkter oder unzuverlässiger Konnektivität (Tunnel, Offshore, entlegene Werke)

  • Rechtliche Rahmenbedingungen, bei denen Datenübermittlung an außereuropäische Cloud-Anbieter praktisch nicht auditierbar oder durchsetzbar ist

  • Verteidigungsnahe Systeme mit Air-Gap-Anforderungen

Die Praxis-Faustregel: Wenn das Weglassen der Internetanbindung in einem FMEA-Workshop als akzeptabler Betriebsmodus gilt, gehört die Kernlogik auf Edge/On-Prem. Cloud ist dann nur eine Optimierungsschicht – niemals eine Betriebsbedingung.

Referenzarchitektur: Souveräne IIoT-Plattform On-Prem
Eine robuste, auditierbare Architektur für industrielle Standorte besteht typischerweise aus sieben Schichten:

1) Feld- und Steuerungsebene

  • Sensorik/Aktorik, SPS/PLC, CNC, Roboter, Kameras, IPCs

  • Echtzeitbetriebssysteme und Feldbusse (PROFINET, EtherCAT, CAN, etc.)

  • Safety-Funktionen strikt getrennt von IT/OT-IT (keine KI-Schleifen im Safety-Pfad)

2) Edge-Gateways

  • Industrielle Gateways mit TPM/TEE, ausreichend RAM/CPU, optional GPU/TPU/NPU

  • Protokolladapter: OPC UA Client/Server, Modbus, proprietäre SPS-Protokolle

  • Pub/Sub-Bus für Telemetrie (MQTT) mit mTLS, CRL/OCSP, hardwaregestützte Schlüssel in TPM

  • Lokale Inferenzdienste als Container (z. B. ONNX Runtime, TensorRT), Soft-RT-fähiges Linux

3) Standortweiter Event- und Datenbus

  • MQTT-Broker für IoT-Telemetrie (QoS, Retain, Wildcards)

  • Kafka oder Kafka-kompatibel (z. B. Redpanda) für hochvolumige Streams, Replays, genau-einmal Semantik auf Standortebene

  • OPC UA für semantisch reiche, bidirektionale Zustände und Methodenaufrufe (z. B. Job-Trigger, Rezeptwechsel)

4) Stream- und Batch-Verarbeitung

  • Edge-seitige Streamprozessoren (Flink, ksqlDB) für Low-Latency-Aggregation, Windowing, CEP

  • Time-Series-Datenbanken (InfluxDB, TimescaleDB) für Metriken, Zustände

  • Objekt-Storage On-Prem (MinIO, Ceph) für Bild-/Videodumps, Rohdaten, Trainingssets

5) MLOps und Modell-Governance On-Prem

  • Modell-Registry (z. B. MLflow, Seldon), Signierung, Herkunftsketten (in-toto/SLSA)

  • Feature Store lokal (Feast/Custom) mit klaren PII/Trade-Secret-Barrieren

  • Drift-Detection, Shadow-Deployments, Canary-Rollouts am Edge

6) Identität, Sicherheit, Netzwerk

  • Interne PKI, kurzlebige Zertifikate, rollenbasierte Zugriffe, Gerätezertifikate in TPM

  • Netzwerksegmentierung (OT/IT/DMZ), Zero Trust zwischen Zonen, applikationsseitige AuthZ

  • Software-Lieferkettenhärtung: SBOMs, signierte Container, verifizierende Runtime

7) Observability und Betrieb

  • Metriken/Logs/Traces On-Prem (Prometheus, Loki, OpenTelemetry Collector, Jaeger)

  • OTA-Update-Infrastruktur mit A/B-Partitionen (Mender, balena, OSTree)

  • Flottenweite Richtlinien, Health-Checks, Progressive Delivery, Rollback

Cloud-Anbindung, wenn überhaupt, erfolgt kontrolliert:

  • Datendiät: Nur abgeleitete, aggregierte, entpersonalisierte Daten raus

  • Asynchron: Store-and-forward, Retry-Backoff, Bandbreitenbudgets

  • Reproduzierbarkeit: Alles, was in der Cloud gerechnet wird, muss On-Prem deterministisch nachziehbar sein

Protokollwahl im industriellen Datenpfad: MQTT, OPC UA, Kafka – kein Entweder-oder
Die Diskussion „MQTT vs. OPC UA vs. Kafka“ ist meist falsch gestellt. Die drei bedienen unterschiedliche Schnittstellenprobleme.

  • MQTT (Message Queuing Telemetry Transport)
  • Stärken: Leichtgewichtig, Pub/Sub, gute Edge-Tauglichkeit, hierarchische Topics, Offline-Pufferung über Clients, QoS 0/1/2, Retained Messages.
  • Schwächen: Schwacher Typ/Rahmen, keine semantische Selbstdokumentation, nicht für exakt-einmal bei hohen Lasten designt.
  • Typische Rolle: Telemetrie von Edge-Knoten ins Standort-Backbone; Remote-Command über dedizierte Topics; Brücken zwischen Zellen.
  • OPC UA (Unified Architecture)
  • Stärken: Richer Data Model, Discovery, Methodenaufrufe, Subscriptions, Security-Modelle speziell für OT; Companion Specs für Domänen.
  • Schwächen: Höherer Overhead, komplexeres Profiling/Tuning, Subscription-Skalierung erfordert Know-how.
  • Typische Rolle: Maschinennahe Integration, Zustände, Parameter, Rezepturen, Befehle; digitale Zwillinge auf Objektknotenebene.