Technische Konsequenzen:

  • Inferenz auf dedizierter Edge-Hardware mit vorgewärmten Modellen, keine Kaltstarts

  • Quantisierte Modelle, TensorRT/ONNX-Optimierung, CPU-Pinning für deterministische Ausführung

  • Containerisierung ja, aber mit Bedacht: Realtime-Workloads separat, Scheduling/Isolierung hart konfigurieren. Nicht jede Orchestrierung ist RT-tauglich out-of-the-box

  • Preemption vermeiden, Ressourcenreservierung, hohe Prioritäten für kritische Threads

  • Netzwerk-Determinismus: TSN/PRP, priorisierte VLANs, PTP-Zeitbasis, keine “Best Effort”-Pfade im kritischen Loop

4) Protokolle im Verbund: OPC UA, MQTT, Kafka – wofür, wo und wie verbinden?

Jedes Protokoll hat seinen Platz, wenn es sauber entkoppelt wird:

  • OPC UA: Starke Semantik, Tauglichkeit für PLC/OT-Welt, Method Calls, rich Metadata. Ideal in der Zelle, um Prozesssignale strukturiert zugänglich zu machen. Für hohe Volumina (Bilder, hochfrequente Sensordaten) nicht optimal.
  • MQTT: Leichtgewichtiges Pub/Sub, exzellente Eignung für Geräte-Telemetrie und Command/Control mit klaren Topics und ACLs. QoS1 ist praxistauglicher Standard; QoS2 nur, wenn genau-einmal dringend ist und Overhead vertretbar bleibt. Retained Messages für Konfiguration, Last-Will für Flottenrobustheit.
  • Kafka: Stark für Hochvolumen-Streams, Replays, Backpressure-Resilienz und Konsumentenvielfalt in der On-Prem-Kernschicht. Erfordert bewusste Schema-Disziplin (Schema-Registry), Partitionsstrategie und Idempotenz.

Brückenmuster:

  • OPC UA -> Edge: Subscriptions auf interessierende Knoten, Übersetzung in “schlanke” Edge-Events (z. B. JSON/CBOR/Protobuf), Ergänzung eines stabilen Keys (Asset-ID) und einer präzisen Zeitbasis

  • Edge (MQTT) -> Core (Kafka): Bridge-Service, der Topics auf Partitionen mappt, QoS/Retain-Logik respektiert, Payloads validiert und gegen Schemas prüft. Backpressure-Handling: lokale Puffer, adaptive Publish-Rates, Priorisieren kritischer Topics

  • Schemaverwaltung: OPC UA-Nodesets sind keine 1:1-Schemas für Events. Der Brückencode ist der Ort, an dem OT-Semantik in stabil versionierte Domänenereignisse übersetzt wird

Genau-einmal-Semantik:

  • Über Zonen hinweg ist “exactly once” schwierig. Strategie aus der Praxis: at-least-once mit deduplizierbaren Ereignissen (stable Event-IDs), Idempotenz in Konsumenten, und Zustandsmaschinen, die Wiederholungen tolerieren.

5) Flottensteuerung: Tausende Edge-Geräte deterministisch betreiben

Dort entscheidet sich, ob ein IIoT-System über Jahre stabil bleibt:

  • Identität und Aufnahme:
  • Werksseitig provisionierte TPMs, Geräte melden sich mit Hardware-gebundenen Zertifikaten
  • Kurzlebige Client-Zertifikate (mTLS) aus einer On-Prem-PKI, kein statisches Shared Secret über Jahre
  • Aufnahme-Workflow (“enrollment”) mit Freigabe durch Betreiber und Policy-Prüfung (Standort, Seriennummer, Besitzer)
  • Konfigurationsmodell:
  • Desired/Reported State (Device Twin): Der zentrale Zustand ist deklarativ (“Dieses Gerät soll Modell X in Version 1.3 fahren, Kamera-ROI Y, Meldeschwellen Z”)
  • Konfliktauflösung deterministisch (Priorität: Sicherheits-Policy vor Operator-Override, vor Default)
  • Versionierte Konfigurationsschemas mit Migrationspfaden
  • Software-/Model-Updates:
  • Immutable Images, A/B-Partitionierung, signierte Artefakte, atomare Switchovers
  • Health Checks nach Update; Rollback bei Fehlersignalen
  • Stufenweise Rollouts: canary -> ring-based -> breit, mit automatischem Halt bei Telemetrie-Anomalien
  • Modelle als eigenständige, versionierte Artefakte; Promotion nur nach on-device Validierung
  • Telemetrie und Logs:
  • Budgetiert: Sampling-Raten, Downsampling am Edge, Schemadisziplin
  • Persistente Offloader am Edge mit Prioritätswarteschlangen (kritische Alarme > Diagnostik > Rohdaten)
  • Kompression (z. B. LZ4/Snappy) und Chunking, um intermittente Links zu nutzen
  • Sicherheit im Lebenszyklus:
  • Remote Attestation vor dem Ausrollen sensibler Workloads
  • SBOM-Tracking für jedes Edge-Image
  • Rotierbare Schlüssel, Zertifikate mit kurzen Laufzeiten, keine “ewigen” Tokens
  • Richtlinien, die Cloud-Abhängigkeiten für den Betrieb ausschließen (Offline-first-Design)

6) Hybrid-Architekturen: Edge-Inferenz, zentrales Training – souverän gedacht

Machine-Learning-Lebenszyklen lassen sich sauber zwischen Edge und Core/Cloud trennen:

  • Datengewinnung:
  • Nur die nötigsten Rohdaten verlassen die Edge – typischerweise Stichproben, Fehlklassifikationen, Annotationskandidaten
  • Anonymisierung und Pseudonymisierung am Edge, strikte Trennung von PII und Betriebsdaten
  • Positivlisten: Welche Datentypen dürfen die Zelle verlassen? Alles andere ist per Default verboten
  • Trainingsumgebung:
  • On-Prem-Cluster, wenn Datenklassifikation es fordert. Cloud-Compute nur für anonymisierte/abgeleitete Datensätze und wenn vertraglich/technisch abgesichert
  • Reproduzierbare Trainingspipelines, deterministische Seeds, klare Artefaktketten
  • Model Registry und Promotion:
  • Jede Modellversion trägt Herkunft, Trainingsdaten-Scope, Metriken und Gültigkeitsraum (z. B. Linie A, Kamera-Batch C)
  • Vor produktivem Ausrollen: On-Edge-Shadowing (nur inferieren, nicht handeln), Telemetrievergleich, Stabilitätskennzahlen
  • Canary-Rollout mit automatischer Rücknahme bei Drift oder KPI-Verlust
  • Drift-Überwachung ohne Datenabfluss:
  • Auf Edge: Berechnung verteilter Statistiken (Feature-Distributionen, Konfidenzen, Fehlerklassen), Übertragung nur aggregierter Werte
  • Im Core: Vergleich mit Referenzverteilungen, Alarmierung, falls Signifikanzschwellen überschritten
  • Feature-Engineering:
  • Feature-Definitionen versioniert und Edge-tauglich (keine Features, die Cloud-Abfragen brauchen)
  • Wo möglich: On-Device-Featurekalkulation, damit Trainings- und Inferenzpfad konsistent bleiben

7) Governance und Souveränität sind Architektur, nicht Papier

“DSGVO-konform” als Fußnote reicht nicht. Souveränität wird durch technische Leitplanken erzwungen:

  • Datenfluss-Diagramme sind Code: Die erlaubten Flüsse sind als Infrastructure-/Policy-as-Code abgebildet. Alles, was nicht erlaubt ist, ist technisch unmöglich.
  • Ausgehende Pfade sind whitelisted, transformierend und auditierbar. Kein “direkter S3-Upload ins Internet” vom Edge.
  • Rollen und Verantwortungen: Wer darf ein Modell in Produktion heben? Wer darf einen neuen Datentyp exportieren? Diese Rechte sind an CI/CD-Pipelines gebunden, nicht an einzelne Personen.
  • Messbarkeit: Metriken für Souveränität (z. B. Anteil Edge-verarbeiteter Entscheidungen, Zeit bis Datenlöschung, Zahl blockierter, nicht genehmigter Exporte).
  • Resilienzübungen: Regelmäßige “Cloud weg”-Drills. Bleibt die Linie stabil? Erreicht Telemetrie verzögert, aber vollständig den Core? Greifen Offline-Runbooks?

8) Beispiele aus der Praxis (abstrahiert)