Statt “Big Bang” empfehle ich einen inkrementellen Aufbau:
1) Edge-Laufzeit

  • Container Runtime + leichter Kubernetes-Stack (k3s)

  • Lokaler MQTT-Broker

  • OpenTelemetry Collector

2) Datenbrücke

  • OPC UA Adapter → MQTT Topics (normalisiert)

  • Persistenter Ringpuffer auf Gerät

3) Inferenzdienst

  • ONNX/TensorRT-Server oder leichter Runtime-Container

  • Zero-Copy-Pfad zwischen Preprocess und Inferenz

4) Governance

  • On-prem Registry/Model Store

  • Signaturprüfung am Edge, GitOps-Rollouts

  • Lokales Audit-Log für Inferenz-Events

5) Standort-Backbone

  • Kafka-Cluster (redundant) für Replays/Analytik

  • Objekt-Storage für Artefakte und abgeleitete Daten

6) Hybride Tür

  • Strikte Export-Pipeline, die nur freigegebene, anonymisierte Artefakte herauslässt

Eindeutige Standpunkte aus der Praxis

  • Public Cloud ist ein Werkzeug, keine Policy. In kritischer Industrie beginnt man mit Edge/on-prem als Default und rechtfertigt jeden externen Hop.
  • “Wir anonymisieren später” ist keine Architektur. Data Contracts und technische Enforcer gehören in die Pipeline, sonst wird nie anonymisiert – nur verschoben.
  • Ohne Observability kein Rollout. Wer nicht misst (Latenz-P95, Jitter, Fehlerraten, Drift), fliegt blind – und überschätzt seine Stabilität.
  • OPC UA, MQTT, Kafka sind komplementär. Ein Protokoll “für alles” ist ein Gerücht, das Sie teuer zu stehen kommt.

FAQ

Frage 1: Wie aktualisieren wir Modelle in einer air-gapped Umgebung sicher?
Antwort: Bauen Sie eine dedizierte Artefakt-Pipeline: Trainingscluster signiert Modelle (cosign o. ä.), erzeugt SBOM und Metadaten (Commit-Hashes, Evaluationsmetriken). Ein gehärtetes Transfer-Gateway prüft Signaturen, scannt Artefakte, spiegelt sie in eine interne Registry/Model-DB. Edge-Nodes akzeptieren nur signierte und freigegebene Artefakte (Policy Enforcement). Rollouts erfolgen GitOps-gesteuert in Wellen mit automatischen Rollbacks bei SLO-Verletzungen. Für komplett offline Standorte nutzen Sie signierte Offline-Bundles und ein Vier-Augen-Freigabeverfahren.

Frage 2: Wie koordinieren wir tausende Edge-Geräte ohne die Leitung zu überlasten?
Antwort: Trennen Sie Steuerdaten von Telemetrie. Konfigurationen werden als deklarative Desired State in kleinen Artefakten verteilt. Telemetrie wird lokal gesampelt/aggregiert; nur Key-Metriken gehen zentral. Nutzen Sie Delta-Updates für Container/Modelle. Vermeiden Sie “Chatty” Muster; stattdessen Event-getriebene Architekturen mit Backpressure. Für großflächige Rollouts: Wellenweise Deployment, geographisch und topologisch gruppiert, jeweils mit Health-Gates.

Frage 3: Können wir zentral trainieren, ohne Rohdaten aus dem Werk zu nehmen?
Antwort: Ja, mit zwei Mustern: a) Federated Learning – Modelle lernen lokal, nur Gradienten/Aktualisierungen werden zentral aggregiert. b) Feature-Level-Export – Sie extrahieren vor Ort Merkmale, entfernen Identifikatoren, prüfen Re-Identifizierbarkeit, und exportieren nur freigegebene Features oder synthetische Äquivalente. In beiden Fällen brauchen Sie strikte Data Contracts, Audit-Logs und technische Enforcer in der Pipeline.

Frage 4: Wie stellen wir 100 ms End-to-End sicher, inklusive Jitter?
Antwort: Planen Sie explizite Latenzbudgets pro Stage und messen Sie sie. Minimieren Sie Kontextwechsel (CPU-Pinning), nutzen Sie Realtime-fähige Scheduling-Klassen wo sinnvoll, vermeiden Sie unnötige Serialisierung (Zero-Copy). Halten Sie kritische Komponenten kollokiert, eliminieren Sie WAN-Hops aus dem Hot Path. Legen Sie harte Abbruchbedingungen fest (Circuit Breaker), wenn die Pipeline ins Schlingern gerät. Telemetrie muss P50/P95/P99 ausweisen – Mittelwerte sind wertlos.

Frage 5: Warum nicht einfach OPC UA direkt bis zur Zentrale, statt MQTT/Kafka-Mix?
Antwort: Weil Aufgaben unterschiedlich sind. OPC UA ist stark in der Nähe der Maschine (Semantik, State, Security). Für Flotten-Telemetrie über wechselhafte Netze ist MQTT robuster und leichtergewichtig. Für standortweite Persistenz, Replays und Analytik ist Kafka das richtige Werkzeug. Der Mix erlaubt Ihnen, das Richtige am richtigen Ort zu tun – ohne Kompromisse bei Stabilität oder Souveränität.

Schlussgedanke

Souveränität ist kein Appendix in der Architektur – sie ist die Achse, um die Edge, Cloud und alles dazwischen kreisen. Wenn Sie in einer kritischen Industrie arbeiten, lautet die Grundregel: Bringen Sie den Compute zur Datenquelle und exportieren Sie nur das, was Sie auch auf die Titelseite der Zeitung setzen würden. Der Rest folgt aus solide gebauten Pipelines: Protokolle nach Aufgabe, deterministische Budgets, auditierbare Artefakte und Flottenbetrieb mit System. So wird aus “Wir brauchen KI” eine belastbare IIoT-Architektur, die Jahre trägt – nicht Wochen.