Titel: Edge vs. Cloud im IIoT: Wo On-Premise alternativlos ist – und wie man hybride Architekturen richtig baut

Einleitung – das eigentliche Engineering-Problem
In industriellen Systemen geht es nicht um “KI einführen”, sondern um Taktzeit, Verfügbarkeit, Sicherheitsfreigaben und Datenhoheit. Die Frage ist nicht: “Wie bekommen wir die Daten in die Cloud?” Sondern: “Wie halten wir einen stabilen 100-ms-Regelkreis ein, erfüllen unsere Audit-Anforderungen und behalten die Schlüssel in der eigenen Hand?” Aus genau dieser Perspektive betrachten wir Edge, Cloud und hybride Modelle.

Wir haben sowohl eine Cloud-Plattform für Pilotenausbildung als auch ein Fleet-Intelligence-System für Eisenbahnnetze gebaut. Beide Lösungen profitieren von zentralen Ressourcen, aber beide mussten vor allem eines: lokal, deterministisch und souverän funktionieren – auch mit schlechter Verbindung, auch im Offline-Fall, auch unter Audit.

Dieser Artikel zeigt, wo On-Premise nicht verhandelbar ist, wie man industrielle Datenströme (MQTT/OPC UA/Kafka) richtig zusammensetzt, wie man tausende Edge-Geräte beherrschbar macht und warum 100 ms Latenz oft den Unterschied zwischen “funktioniert im Labor” und “läuft im Werk” ausmachen. Roter Faden: Souveränität. Nur wer Kontrolle über Datenflüsse, Schlüssel und Betriebsabläufe hat, kann robuste Intelligenz implementieren.

1) Wann On-Premise alternativlos ist
Es gibt Industriebereiche, in denen Cloud ein Bonus ist – und andere, in denen sie ein Risiko ist. Ein paar klare Indikatoren, dass Edge/On-Prem die Leitarchitektur sein muss:

  • Harte Latenzbudgets: Wenn ein Modell Teil eines Regelkreises ist (z. B. visuelle Inline-Prüfung mit Taktzeiten < 200 ms), darf das Ergebnis nicht von WAN-Jitter abhängen. Selbst 30–50 ms zusätzliche Latenz oder sporadische Paketverluste kippen Sicherheitsmargen.
  • Offline- und Degradationsfähigkeit: Bahnsysteme, Baugewerbe im Feld, Werksnetze mit Segmentierung oder Defense-Setups – es ist realistisch, dass Verbindungen tagelang eingeschränkt sind. Der Betrieb muss autonom weiterlaufen und deterministisch degradieren.
  • Unverhandelbare Datensouveränität: Wenn Daten nur in europäischen Rechenzentren oder ausschließlich im Kundennetz verbleiben dürfen – und Schlüsselverwaltung (KMS/HSM) unter Kundensouveränität steht –, ist eine rein cloudzentrierte Architektur Fehlplanung.
  • Zulassung und Audit: In sicherheitskritischen Bereichen ist die Nachvollziehbarkeit von Modellentscheidungen, Datenpfaden und Update-Prozessen essenziell. “Black-Box SaaS” hinter Public-APIs fällt hier oft durch, weil Audit-Artefakte, Logik-Isolation oder forensische Reproduzierbarkeit fehlen.
  • Kostenstruktur vs. Datenvolumen: Hochfrequente Sensordaten (z. B. Kamerastreams, Schwingungen) sind lokal günstig zu verarbeiten und teuer zu transportieren. Vor-Ort-Selektion, -Aggregation und -Inferenz spart Geld und erhöht Robustheit.

Konsequenz für das Architektur-Design:

  • Edge-first als Default: Inferenz, Vorverarbeitung, Regelkreise, lokale Entscheidungsfindung on-premises.

  • Cloud/zentraler Knoten optional: Für Flottenanalyse, globales Roll-out-Management, nicht-zeitkritische Auswertungen – und nur, wenn die Souveränitätsanforderungen eingehalten werden.

  • Reversible Architektur: Der Betrieb darf niemals an die Erreichbarkeit eines externen Endpunkts gekoppelt sein. Das System muss “mit” und “ohne” zentrale Verbindung äquivalent funktionieren.

2) Protokollwahl im IIoT: MQTT, OPC UA, Kafka – kein Entweder-oder
Jedes Protokoll löst ein anderes Problem. Die saubersten Architekturen trennen Kontrollpfade, Telemetrie und hochvolumige Datenströme. In der Praxis kombinieren wir meist alle drei.

  • MQTT – leichtgewichtiges Pub/Sub für Telemetrie und Befehle
  • Stärken: Geringer Overhead, einfache Topic-Hierarchien, QoS 0/1/2, Retained Messages (z. B. für Sollwerte), gut für Edge-Gateways, die Zustände/Events verteilen oder entgegennehmen.
  • Einsatz: Gerätestatus, Alarme, Konfigurations-Updates, Ergebnis-Metadaten (nicht Rohbilder). Broker oft on-prem (Cluster mit HA), optional Bridges zu zentralen Brokern. Wichtig: mTLS mit Client-Zertifikaten, restriktive ACLs pro Topic-Baum.
  • OPC UA – Semantik und Methodenaufrufe für Maschinenintegration
  • Stärken: Standardisierte Address Spaces, Typ-Systeme, Method-Calls für Aktoren, Subscription-Modelle (PubSub), geeignet für die Verbindung in die Welt der SPS/Leitsysteme.
  • Einsatz: Zugriff auf Maschinenvariablen, Kontroll- und Abfragepfade, Interoperabilität mit Bestandsanlagen. Edge-Adapter übersetzen proprietäre Feldbusse in OPC UA und publizieren Status/Events weiter via MQTT/Kafka.
  • Kafka – persistenter, skalierbarer Stream-Backbone
  • Stärken: Hoher Durchsatz, Replikation, genau definierte Konsumptionssemantik (idempotente Producer, Transaktionen), Retention und Re-Processing für Analytik/ML-Feature-Pipelines.
  • Einsatz: On-prem als zentrales Nervensystem pro Werk/Standort für Streaming-Analytik, Batch-Aggregationen, Trainings-Datenpipelines. Schema Registry (Avro/Protobuf) ist Pflicht, um Evolvierbarkeit zu garantieren. Für zentrale Konsolidierung können kompakte, anonymisierte Aggregationen periodisch exportiert werden – unter voller Schlüsselkontrolle.

Praktisches Pattern:

  • Feldseite: OPC UA-Adapter lesen Maschinendaten; Ereignisse/Status werden in MQTT-Themen strukturiert (z. B. site/line/station/device/metric).

  • Edge-Core: MQTT-Broker verteilt; Edge-Inferenz schreibt Ergebnisse und Qualitätsmetadaten in MQTT, eine Brücke konsumiert nach Kafka fürs persistente Stream-Processing.

  • Analytics/ML on-prem: Kafka + Stream-Prozessor (Flink/Spark Structured Streaming/ksqlDB) erzeugt Feature-Tabellen und Alarme; ein lokaler Data Lake hält Roh- und Zwischenstände. Nur explizit freigegebene Artefakte verlassen den Standort.

3) Latenzanforderungen: Warum 100 ms den Unterschied machen
Ein Beispiel aus der Fertigung: Kamera erfasst Bauteil, Preprocessing (Entzerrung, Crop, Normalisierung), Inferenz, Postprocessing (Geometrieprüfung, Toleranz), Aktorentscheidung (OK/NOK, ggf. Stopp). Das Budget muss die gesamte Kette abdecken:

  • Sensoraufnahme: 5–15 ms (Rolling Shutter, Belichtung)
  • Vorverarbeitung: 5–20 ms (GPU/CPU abhängig)
  • Inferenz: 10–40 ms (Modellgröße, Quantisierung, Batch=1)
  • Postprocessing: 5–15 ms
  • Kommunikations- und Steuerpfad: 5–20 ms (lokal, deterministisch)

Sobald WAN-Kommunikation ins Spiel kommt, addieren sich Jitter und Retries, und die 100 ms sind schnell überschritten. Deshalb:

  • Modell- und Pipeline-Lokalisierung: Inferenz lokal, Synchronisation asynchron.

  • QoS und Backpressure: MQTT auf QoS 1 für kritische Kommandos, lokal priorisierte Verarbeitung. Für Streams: Ringpuffer mit Drop-Policies (z. B. “latest wins”).

  • Graceful Degradation: Wenn Modell oder GPU ausgelastet ist, schalte auf heuristische Regeln, sichere Stopp-Strategien oder geringere Bildauflösung um; Zustand maschinenlesbar im lokalen Topic-Baum veröffentlichen.