Edge vs. Cloud in industriellen IoT-Systemen: Wann On-Premise die einzige Option ist

Problem zuerst
In industriellen Umgebungen ist die Entscheidung für Cloud, Edge oder On-Premise keine Technologiedebatte, sondern eine Engineering-Entscheidung mit klaren Nicht-Funktionalen Anforderungen: Latenz- und Verfügbarkeitsziele, Datenklassifizierung, Auditierbarkeit, Sicherheitsdomänen, Netzwerkprofile, Lebenszyklus und Betriebsmodell. Wer diese Parameter nicht explizit macht, landet schnell in Architekturen, die sich im Betrieb nicht beherrschen lassen.

Aus meinem Blickwinkel – eine Cloud-Plattform für Pilotenausbildung und ein Fleet-Intelligence-System für Eisenbahnnetze im Feld – ist der rote Faden eindeutig: Souveränität ermöglicht Intelligenz. KI-Funktionalität skaliert erst dann, wenn Datenpfade, Verantwortlichkeiten und Betriebsinstrumente in der Hoheit der Organisation bleiben. Cloud kann sinnvoll sein (Training, Simulation, nicht-sicherheitskritische Aggregation). Aber in Defense, kritischer Infrastruktur und vielen IIoT-Szenarien ist On-Premise/Edge die einzige tragfähige Option für den produktiven Pfad.

Ein Entscheidungsrahmen statt Glaubensfrage
Die folgenden Kriterien nutze ich, um eine Architektur festzulegen. Ein „Ja“ bei mehreren Punkten kippt die Entscheidung in Richtung On-Premise/Edge:

  • Latenz und Jitter:
  • Strikte SLOs, z. B. p99 Antwortzeiten ≤ 100 ms im geschlossenen Regelkreis (z. B. visuelle Kontrolle, Not-Halt-Interlocks).
  • Jitter-Sensitivität: Planbare Reaktionszeit wichtiger als Durchsatz.
  • Datenklassifizierung:
  • Betriebsgeheimnisse, IP, Rüstzustände, Fertigungsrezepte, sicherheitskritische Telemetrie.
  • Personenbezug (Video, Audio, Wearables) mit restriktiven Datenflüssen.
  • Netzwerkprofil:
  • Begrenzte oder intermittierende Konnektivität (Tunnel, Satellit, rollendes Material).
  • Hohe lokale Datenraten (Kamera-Streams, Vibrationssensoren), aber geringe brauchbare WAN-Kapazität.
  • Regulatorik und Audit:
  • Eindeutige Datenlokation, kontrollierbare Verarbeitungsgrenzen, nachvollziehbare Pipelines.
  • Air-Gap-Anforderungen oder strikter Egress-Allowlist.
  • Betriebsmodell:
  • Tausende Edge-Knoten, die deterministisch verwaltet, gepatcht, beobachtet und rückgerollt werden müssen.
  • Hohe Anforderungen an Offline-Fähigkeit und lokale Entscheidbarkeit.

Drei Zielarchitekturen in der Praxis
1) Rein On-Prem/Edge

  • Einsatz: Defense, kritische Infrastruktur, Fertigungsschritte mit Safety-Interlocks.

  • Muster:

  • Lokale Inferenz und Vorverarbeitung, lokales Messaging-Backbone, lokales Storage.

  • Keine permanenten ausgehenden Verbindungen; Updates via signierter Pull-only-Mechanik.

  • Identitäten und Zertifikate über eine eigene, offline verwaltete PKI.

  • Trade-offs: Mehr Betriebslast vor Ort, härteres Lifecycle-Management. Dafür maximale Kontrolle und deterministische Latenz.

2) Hybrid: Edge-Inferenz, zentrale Aggregation/Training

  • Einsatz: Flottenbetrieb (z. B. Bahn), visuelle Qualitätskontrolle, Predictive Maintenance.

  • Muster:

  • Edge: Feature-Extraktion, Dekomprimierung, Inferenz, Event-Enrichment.

  • Zentrale: Kuratierte Daten-Samples, Offline- oder Datacenter-Training, Versionsfreigabe und Distributionskanäle für Modelle.

  • Nur abgestufte, kuratierte Datenauszüge verlassen den Edge-Standort.

  • Trade-offs: Höherer Architekturaufwand, aber gutes Verhältnis aus Datenminimierung und Modellgüte.

3) Cloud-zentriert mit Edge-Cache

  • Einsatz: Nicht-kritische, latenzunsensitive Analytik, Simulation, Pilotentrainingsinhalte.

  • Muster:

  • Edge als dünner Client für Caching, Rate-Limiting und Sensordatenpuffer.

  • Cloud: Rechenintensive Workloads, Datamarts, Reporting.

  • Trade-offs: Einfachere Zentralisierung, aber Abhängigkeit von WAN und geringere Souveränität.

Der Datenpfad ist die Architektur
Eine saubere Architektur erzwingt Klarheit über den Datenpfad. Der häufigste Fehler: Protokolle und Semantik zu mischen, bis das System in untestbaren Punkt-zu-Punkt-Verbindungen erstickt. In der Praxis haben sich drei Schichten bewährt:

  • Feld-Schicht (Geräte, Sensoren, Steuerungen)
  • Deterministische und domänenspezifische Protokolle.
  • OPC UA dort, wo ein Informationsmodell und Typensystem gewünscht ist (z. B. Maschinenzustände, Alarme, Metadaten). Vorteil: Semantik standardisierbar, Browsing möglich.
  • MQTT dort, wo leichtgewichtige Telemetrie, Broadcast-Muster, Offline-Puffer und flexible Topic-Hierarchien wichtig sind. Mit Sparkplug B kann man Zustände und Birth/Death-Messages robust verwalten.
  • Sicherheit: mTLS, Client-Zertifikate pro Gerät, kein Passwort-Zoo; Hardware-Truststore (TPM) für Schlüsselschutz.
  • Edge-Backbone
  • Kafka on-premises als zentrales Event-Backbone für entkoppelte, skalierbare Verarbeitung.
  • Brücken: MQTT→Kafka (z. B. dedizierte Bridge-Komponenten) und OPC UA→Kafka (Adapter, die das Informationsmodell in wohldefinierte Topics und Schemas übersetzen).
  • Schema-Disziplin: Pro Stream ein Schema (Avro/JSON-Schema), Versionskontrolle, Abwärtskompatibilität. Sonst drohen stille Datenkorruption und kaputte Replays.
  • Storage: Objekt-Storage vor Ort (z. B. mit S3-kompatibler API) für Rohdaten, Traces, Modelle, mit Versionierung und WORM-Policies, wenn Audit wichtig ist.
  • Applikations-/KI-Schicht
  • Microservices für Inferenz, Anomaly Detection, Qualitätsregeln.
  • Zustandsbehaftete Edge-Apps mit lokalen Caches und Snapshots; keine hart codierten Cloud-Abhängigkeiten im Hot-Path.
  • Observability by design: OpenTelemetry-Tracing und -Metrics, lokales Scraping (Prometheus), Log-Aggregation mit robustem Backpressure.

Protokollwahl: MQTT, OPC UA, Kafka ohne Religionskrieg

  • MQTT

  • Sinnvoll für: Leichtgewichtige Telemetrie, mobile Assets, variable Netzqualität, Event-Signale, schnelle Pub/Sub-Verteilung.

  • Stärken: QoS 1/2, Retained Messages, Last Will, einfache Topic-Hierarchien, sehr gute Client-Verfügbarkeit auf Embedded.

  • Stolpersteine: Fehlende starke Schemas. Abhilfe: Strikte Topic-Konventionen, Schema-Registrierung an der Brücke, Validierung beim Edge-Backbone.

  • OPC UA
  • Sinnvoll für: Maschinenintegration mit Informationsmodell, Browsing, einheitliche Semantik, Alarme/Zustände.
  • Stärken: Modellierung, Method Calls, Security-Modelle.
  • Stolpersteine: Gewichtiger als MQTT, Tuning für hohe Update-Raten nötig. Empfehlung: Sampling und Publishing sauber trennen, Deadband- und Queue-Parameter bewusst setzen.
  • Kafka
  • Sinnvoll für: Entkopplung von Produzenten/Konsumenten, Replays, Event-Sourcing, horizontale Skalierung.
  • Stärken: Hoher Durchsatz, klare Retention-Regeln, Backpressure-resistent.
  • Stolpersteine: Kein Ersatz für Feldprotokolle; Kafka-Clients nicht auf Edge-Geräte zwingen, wo Ressourcen knapp sind. Brücken entlasten die Peripherie und centralisieren Schema-Validierung.