Souveräne IIoT-Architekturen: Wann On-Premise alternativlos ist – und wie Edge/Cloud-Hybride wirklich stabil laufen

Problem vor Technologie: In industriellen IIoT-Systemen kollidieren drei harte Zwänge genau dort, wo viele “Cloud-first”-Konzepte weich werden: strikte Latenzbudgets im Millisekundenbereich, unterbrochene oder teure Konnektivität am Rand des Netzes und nicht verhandelbare Datensouveränität über Betriebs- und Personendaten. In unseren Projekten – von cloudbasierten Trainingsplattformen in der Luftfahrt bis hin zu Fleet-Intelligence-Systemen im Bahnumfeld – zeigt sich immer wieder: Die Cloud ist ein hervorragendes Werkzeug, aber nur dann, wenn sie nicht zum Lock-in für Betriebsentscheidungen, Datenklassifikation und Sicherheitsarchitektur wird. Souveränität ermöglicht Intelligenz, nicht umgekehrt.

Dieser Beitrag adressiert, wann On-Premise die einzige sinnvolle Option ist, wie souveräne Hybridarchitekturen aufgebaut werden, welche Protokolle in welcher Schicht funktionieren und wie man tausende Edge-Geräte deterministisch koordiniert. Latenzbudgets und Governance ziehen sich als roter Faden durch.

1) Entscheidungsrahmen: Edge, On-Prem oder Cloud?

Anstelle religiöser Architekturdebatten lohnt ein Prüfraster, das sich in der Praxis bewährt hat:

  • Latenz und Determinismus: Braucht der Regelkreis vom Ereignis (z. B. Sensoranomalie) bis zur Aktion (z. B. Anlagenstopp) konsistent <100 ms, ist Cloud-Inferenz faktisch ausgeschlossen. Nicht wegen Rechenzeit, sondern wegen Netzwerkjitter, WAN-Hops und fehlender Deterministik. Hier gehört die Inferenz an die Maschine oder zumindest ins lokale Werksnetz.
  • Konnektivität und Ausfallmodi: Wenn Feldstandorte Intervall-Konnektivität haben (Tunnel, ländliche Gebiete, maritime/ferne Standorte), muss der Default-Betriebsmodus offline-stabil sein. Store-and-forward, lokale Buffer und idempotente Wiederholung sind Pflicht. Cloud wird zur Optimierungsschicht, nicht zur Betriebsvoraussetzung.
  • Datenklassifikation: Produktionsrezepte, Qualitätsbilder, Bewegungsdaten von Mitarbeitern – sobald diese Daten besonders schützenswert sind, gilt “Daten verlassen das Werk nur, wenn es einen guten Grund gibt”. Der Default ist On-Premise-Verarbeitung mit expliziten, protokollierten Exportpfaden.
  • Prozesskopplung: Wenn ML-Entscheidungen unmittelbar in Safety- oder Business-kritische Prozesse greifen (z. B. Bremssystemtest, Notabschaltungen, sicherheitsrelevante Montageprüfung), muss die Abhängigkeit von externen Diensten minimal sein. Auch organisatorisch: Wer trägt Verantwortung bei Störung?
  • Rechtsraum und Lieferkette: Unterschiedliche Rechtsräume und Drittlandzugriffe sind ein Risiko, das man nicht mit Technik “wegarchitekturiert”. On-Premise bzw. europäisch souveräne Infrastrukturen sind nicht Ideologie, sondern Risikosteuerung.
  • Betriebskosten real rechnen: Daten billig reinschieben, teuer wieder rausbekommen – diese Kostendynamik ist real. Wer Terabytes an Video-/Sensorikdaten in eine Cloud hebt, zahlt für Egress, Abfragen, Langzeitarchiv. On-Prem-Objektspeicher und lokale Lakehouse-Ansätze sind ökonomisch oft überlegen, wenn Datenvolumen und Verweilzeiten hoch sind.

Kurz: Cloud ist ein Werkzeug, kein Ort. Edge/On-Prem ist alternativlos, wenn Latenz, Souveränität und Offline-Fähigkeit harte Anforderungen sind. Hybrid wird interessant, wenn wir Trainings-Workloads entkoppeln können.

2) Referenzarchitektur für souveräne IIoT-Systeme

Aus Projekterfahrung ergibt sich ein Setup mit klaren Zonen und harten Übergängen:

  • Feld-/OT-Zone: SPS/PLC, Kameras, Steuergeräte, TSN-Netzwerke. Kommunikation über industrielle Protokolle (OPC UA für Semantik/PLC-Integration, ggf. TSN für harte Echtzeit). Sensorfusion und Vorverarbeitung so nah wie möglich an der Quelle. Zeitbasis über PTP, wo deterministisch notwendig.
  • Edge-Schicht (Zelle/Linie/Vehicle): Industrielle Gateways oder IPCs mit Hardware-Root-of-Trust (TPM), TPM-gebundene Geräteidentität, signierte Container/Images. Aufgaben:
  • Inferenz und lokale Regelung
  • Pufferung (Store-and-forward) für Telemetrie und Rohdaten
  • Datenminimierung/Anonymisierung vor jeglichem Verlassen der Zelle
  • Lokaler MQTT-Broker für lose gekoppelte Sensor-/Aktoren-Kommunikation
  • Vor-Ort-Visualisierung und Operator-HMI
  • On-Prem-Core (Werksrechenzentrum/Leitstelle):
  • Nachrichtenzwischenlage: MQTT für Edge-Pub/Sub, Kafka als Backbone für Hochvolumenstrom, Bridge mit sorgfältiger Schema-Übersetzung
  • Schema-Governance: klare, versionierte Schemas (z. B. Avro/Protobuf) für Datenstandards ab der Factory-Grenze. In der OT-Zone kann OPC UA-Semantik verbleiben; Übersetzung in generische Ereignisse erfolgt an der Edge-Brücke
  • Persistenz: Timeseries-Datenbank für Telemetrie, S3-kompatibler Objektspeicher für Rohbilder/Signale, relationales System für Stammdaten und Konfiguration
  • Stream Processing: On-Prem-Streaming-Jobs für Alarmierung, Aggregationen, Qualitätskennzahlen
  • MLOps on-prem: Model Registry, Feature-Kataloge (Edge-kompatibel), Trainingsdaten-Lake mit kuratierten Exportpfaden
  • PKI, Secrets, kurzlebige Zertifikate, mTLS überall, wo Geräte/Services sprechen
  • Optionale Cloud-Schicht:
  • Nur für Workloads ohne harte Latenz/Souveränitätsbindung: Simulationen, nicht-sensible Dashboards über aggregierte/anononymisierte Daten, optionales Scalout für Trainingsjobs
  • Sovereignty Gate: Ausgehende Datenflüsse sind explizit, genehmigt, protokolliert und technisch erzwungen (z. B. nur vordefinierte, transformierte Datensätze)

Sicherheitsgrundsätze:

  • Zero-Trust zwischen Zonen, minimal erforderliche Ports/Pfade

  • Einwegmuster, wo sinnvoll (z. B. Daten-Dioden-Design vom Feld in Richtung Core)

  • Geräteidentität über TPM-gestützte Zertifikate, Remote Attestation vor dem Zulassen von Workloads

  • Software Bill of Materials (SBOM) pro Edge-Build, signierte Updates, reproduzierbare Builds

3) Warum 100 ms den Unterschied machen

“Echtzeit” wird häufig missverstanden. Für ML-basierte Inline-Entscheidungen ist nicht nur die mittlere Latenz relevant, sondern die Varianz (Jitter) im End-to-End-Pfad:

  • Latenzbudget-Beispiel visuelle Qualitätskontrolle:
  • Kamera-Exposure + Sensor-Readout: 8–12 ms
  • Vorverarbeitung (Resize, Normalize): 2–5 ms
  • Inferenz (optimiertes, quantisiertes Modell): 5–20 ms je nach Hardware
  • Entscheidung/PLC-Handshake: 5–15 ms
  • Sicherheitsmarge (Jitter): 20–40 ms

Summe liegt schnell bei 60–90 ms. Jeder zusätzliche Hop (Edge -> Cloud -> Edge) frisst das Budget auf.