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

Das reale Problem, nicht die Technologie: Sie haben Maschinen, Fahrzeuge oder Sensoren, die kontinuierlich Daten erzeugen. Teile davon steuern sicherheitskritische Prozesse (Stop eines Förderbands, Notabsenkung einer Trennvorrichtung, Umschaltung eines Gleissignals). Einige Daten sind personenbezogen oder geschäftskritisch. Die Konnektivität ist unzuverlässig (Tunnel, Depots, Auslandseinsatz). Und Ihre IT-Sicherheitsrichtlinien verbieten, dass Rohdaten außerhalb des Standorts verarbeitet werden. In diesem Spannungsfeld wird schnell klar: Nicht jede Architektur mit einer “zentralen Cloud” ist tragfähig. In vielen Fällen ist On-Premise am Edge nicht nur eine Option, sondern die einzige.

Wir haben Cloud-Plattformen für die Pilotenausbildung und Fleet-Intelligence-Systeme für Eisenbahnnetze gebaut. Beides lehrt eine einfache Regel: Souveränität und Latenz sind Architekturanforderungen, keine “Nichtziele”. Wer sie nicht zuerst adressiert, baut später teuer um.

Wann On-Premise alternativlos ist

Nicht jede industrielle Anwendung braucht Edge-Compute. Aber es gibt Klassen von Anforderungen, die On-Premise erzwingen:

  • Latenzbudgets unter ~100 ms: Für Steuerkreise, Notabschaltungen und unmittelbare Mensch-Maschine-Interaktion sind Roundtrips in entfernte Rechenzentren unvorhersehbar. Jitter und Paketverluste reichen, um aus “manchmal gut” ein Sicherheitsrisiko zu machen. Wir unterscheiden grob: harte Echtzeit (<10 ms: gehört in SPS/MCU), weiche Echtzeit (10–100 ms: gehört auf lokales Edge-Gateway/IPC), alles darüber ist bestenfalls “Cloud-tauglich”.
  • Intermittierende oder teure Konnektivität: Züge im ländlichen Raum, Offshore-Anlagen, Konfliktgebiete, abgeschirmte Fabriknetze. Edge muss monatelang autonom laufen, mit Store-and-Forward und deterministischem Degradationsverhalten.
  • Datensouveränität: Rohbilder aus der Qualitätskontrolle, Wartungsdaten mit Personenbezug, Verteidigungs-Telemetrie. Wenn die Regel lautet “Rohdaten verlassen das Werk nie”, ist die Architektur darauf aufzubauen: Datenklassifikation am Ursprung, lokale Verarbeitung, strenge Egress-Policies.
  • Vorhersehbare Kosten: Dauer-Streaming von Video/Point-Clouds in zentrale Rechenzentren ist kostspielig und unnötig, wenn 99 % davon verworfen werden. Verdichtung und Event-Extraktion gehören an den Rand.
  • Lieferketten- und Abhängigkeitsrisiken: Systeme müssen ohne US-Cloud, ohne externe Token-Auflöser oder proprietäre Kontroll-Backends funktionieren. “Air Gap-fähig” ist eine Architektureigenschaft, kein nachträgliches Add-on.

Drei belastbare Referenzarchitekturen

1) Edge-native, voll On-Prem

Wenn Daten und Entscheidungen das Werksgelände nicht verlassen dürfen, legen Sie den Datenpfad vollständig lokal aus:

  • Feld- und Steuerungsebene: Sensoren/Aktoren über Feldbusse, OPC UA für Telemetrie und Informationsmodelle. Steuerlogik verbleibt auf SPS/IPC.
  • Edge-Gateway(s): Industrietaugliche Hardware (x86/ARM), Härtung via Secure Boot, signierte Images, TPM-basierte Schlüsselablage. Containerisiert, aber mit Bedacht: Realtime-Anteile in isolierten Services mit festen CPU-/IO-Quoten; Userland-Tuning (Thread-Pinning, isolcpus, HugePages).
  • Message-Bus: Leichtgewichtiger Broker für lokale Publikations-/Subskriptionsmuster (MQTT) mit persistenten Sessions und Store-and-Forward auf Disk. Themenhierarchien bilden Anlagenstruktur ab (werk/linie/zelle/maschine/…).
  • Stream-Verarbeitung: Low-latency Pipelines für Feature-Extraction, Anomalieerkennung, Regelvalidierung. “At-least-once” Semantik mit deduplizierbaren Event-IDs; Idempotenz statt globaler Transaktionen.
  • Speicher: Zeitreihendatenbank für Telemetrie, Objekt-Store auf dem Edge-Cluster für Artefakte (Modelle, Logs, Bildausschnitte). Retentions-Policy strikt: Rohdaten kurz, abgeleitete Daten länger.
  • Visualisierung & Bedienung: Lokale Dashboards, die ohne externen Login funktionieren. Benutzer- und Rollenverwaltung an das Werks-IdM gekoppelt.
  • Governance: Egress-Policy-Engine am Rand: Nur whitelists (z. B. Alarm-Metadaten), niemals Rohbilder. Jede Freigabe als Code und revisionssicher.

2) Hybrid: Edge-Inferenz, zentrales Training

Für viele KI-Anwendungen ist das ein robustes Muster:

  • Inferenz auf dem Edge: Modelle (z. B. Defekterkennung) laufen on-device mit quantisierten Artefakten und festen Latenzgarantien. Post-Processing generiert knappe Ereignisse (Defekt, Bounding Box, Score).
  • Datenkurierung lokal: Nur “lernrelevante” Ausschnitte (Unsicherheitsfenster, Drift-Indikatoren) werden zwischengespeichert. Sampling- und Rate-Limits verhindern Egress-Schleichwege.
  • Asynchrone Synchronisation: Zeitgesteuerte Upload-Fenster, mTLS, gegenseitige Zertifikatsprüfung, Replay-Schutz. Bei Netzausfall Backoff mit deterministischer Wiederaufnahme.
  • Zentrales/On-Prem-Training: Datenspeicher mit Versionierung, reproduzierbare Trainingspipelines, Model Registry. Modelle werden signiert, Canary-Rollouts orchestriert, Telemetrie zu Performance/Kalibrierung zurückgeführt – ohne Rohdaten.

3) Cloud-zentriert mit souveräner Grenze

Wenn es Gründe für zentrale Cloud-Services gibt (Rechenlast-Spitzen, Kollaboration), ziehen Sie eine harte Linie:

  • Edge führt Pseudonymisierung/Anonymisierung durch, bevor Daten ausleiten. Erlaubte Felder/Granularität sind in Policies kodiert.
  • Trennung der Identitäten: Geräte-Identitäten sind lokal ausstellbar; Cloud sieht nur pseudonyme Subjekte. Conditioning-Daten für Modelle bleiben vor Ort.
  • “Local override” by design: Bei Cloud-Ausfall bleibt der Betrieb vollständig funktionsfähig. Alle sicherheitsrelevanten Entscheidungen sind cloud-unabhängig.

Protokolle im industriellen Datenstrom: MQTT, OPC UA, Kafka – wofür ist was gut?

Die Protokollwahl entscheidet über Robustheit, keine Geschmacksfrage.

  • OPC UA: Stärken bei Informationsmodellierung, semantisch reichen Katalogen, Integrationen in SPS/SCADA. Für Steuerung und strukturierte Telemetrie aus Maschinen sinnvoll. Latenzarm im LAN, aber relativ “schwer” für WAN/verlustbehaftete Netze.
  • MQTT: Leichtgewichtig, verbindungsstabil über wackelige Links. QoS 0/1/2 erlaubt abstufbare Garantien. Sessions mit persistenten Subscriptions sind Gold wert bei intermittierender Konnektivität (Zug fährt in Tunnel, kommt wieder, setzt fort). Topic-Design ist das eigentliche Datenmodell: konsistent, versioniert, mit Retained Messages nur dort, wo sinnvoll.
  • Kafka (oder generell logbasierte Broker): Hochdurchsatz, Re-Reads, starke Backpressure-Modelle – super im Rechenzentrum/Backbone, selten sinnvoll direkt am Feldgerät. Pattern: OPC UA/MQTT am Edge, dann in stabilem Netzsegment Brücke in Kafka für Analytics-Cluster. Edge → Gateway (MQTT) → Core (Kafka).

Brückenmuster:

  • OPC UA → MQTT: Gateway extrahiert Telemetrie, mappt Node-IDs auf Topics, konvertiert Datenformate (z. B. Binary → JSON/CBOR). Events mit Sequence-IDs zur Deduplizierung.