• Kafka/NATS (im Rechenzentrum):
  • Hoher Durchsatz, Replays, Consumer-Gruppen – entkoppelt zentrale Systeme.
  • Edge-seitig keine Kafka-Clients nötig; Gateways publishen via MQTT/HTTP in Edge-Gateways, die ins Rechenzentrum forwarden.

Topic- und Schema-Design entscheidet über Skalierbarkeit:

  • Themenstruktur strikt: site/{id}/device/{id}/telemetry, …/events, …/desired, …/reported.

  • Schemaevolution versionieren (v1/v2), Avro/JSON-Schema/Protobuf für zentrale Flüsse, damit Kontrakte maschinenlesbar bleiben.

Konfigurationsmodell: Desired vs Reported State

Deklarative Steuerung funktioniert skalierbar, wenn die Control Plane den gewünschten Zustand beschreibt und das Gerät sich konvergent annähert:

  • Desired State:
  • Welche App-Versionen sollen laufen?
  • Welche Modelle sind aktiv? Mit welcher Konfiguration (Schwellwerte, Sampling-Raten)?
  • Ressourcenquoten, Log-Level, Feature-Flags.
  • Reported State:
  • Tatsächliche App-/OS-Versionen, Checksummen, Modellversionen.
  • Health-Informationen: Temperatur, CPU-Load, Disk-Füllstand, Watchdog-Resets.
  • Letzte erfolgreiche Verbindung, Pufferstände in der Telemetrie-Queue.
  • Konfliktlösung:
  • Idempotente Kommandos, Versionstoken, „last writer wins“ nur mit Clock-Disziplin.
  • Server-seitige Policies verhindern verbotene Kombinationen (z. B. zu hoher GPU-Power-Draw während Spitzenlast im Werk).

Sichere Updates: OS, Container, Modelle

Nichts bricht Vertrauen schneller als ein Update, das Geräte bricked oder Prozesse stoppt. Ein belastbares Design:

  • Betriebssystem:
  • A/B-Partitionierung mit atomaren Swaps, Rollback bei Health-Check-Fail.
  • Delta-Updates zur Bandbreitenersparnis, kryptografisch verifiziert.
  • Container und ML-Modelle:
  • Immutable Tags plus Digest-Pinning. Keine „latest“-Magie.
  • Image- und Modell-Signaturen prüfen; SBOMs speichern und mitrollen.
  • Warm Standby/Shadow: Neues Modell parallel laden, Schatteninferenzen ausführen, Statistiken vergleichen, erst dann aktiv schalten.
  • Rollout-Steuerung:
  • Staged: 1% → 10% → 50% → 100%, standortweise mit Pausen und Metrik-Gates.
  • Fehlerbudgets: Stoppe/rolle zurück, wenn Metriken außer Band laufen (Crash-Loop, Latenz, Fehlerraten).
  • Wartungsfenster: Produktionskalender integrieren, um Schaltvorgänge in Leerlaufzeiten zu legen.
  • Netzwerkschonung:
  • Site-Local Proxies/Caches, Peer-Assist im selben LAN optional.
  • Konfigurierbare Bandbreitenlimits pro Site und Tageszeit.

Observability, ohne die Leitung zu verstopfen

Zentral alles sehen, vor Ort minimal invasiv:

  • Logs:
  • Edge-Sampling, Level-Gating, Drop von High-Volume-Noise.
  • Relevante Fehlermuster erkennen (z. B. OOM-Killer Events) und priorisiert senden.
  • Metriken:
  • Low-Cardinality-Labels, lokale Aggregation (1s → 10s → 60s).
  • Remote Write asynchron, Fallback auf Ring-Puffer.
  • Tracing:
  • Selektives Tracing für kritische Pfade (z. B. Inferenz-Latenzen), adaptive Sampling bei Vorfällen.
  • Korrelation mit Update-Events: „Seit Modell v3.2 stieg P99-Latenz um 20%“ – entscheidend für schnelle Rollbacks.
  • Edge-Gesundheit:
  • Heartbeats sind nicht genug. Healthz-Checks für App- und Systemebene, Watchdog-Reset-Zähler, Dateisystem-Fehler, Thermalthrottling als Warnsignale.

Resilienz bei Netzwerkausfällen

Planen Sie Ausfälle als Normfall:

  • Store-and-Forward:
  • Telemetrie wird lokal mit deduplizierenden Indizes gepuffert, Zeitfenster definieren, was „auf jeden Fall“ zentral ankommen muss.
  • Eventual Consistency:
  • Desired State wird als Versionenfolge verarbeitet. Gerät kann mehrere Schritte später aufschließen, ohne Nebenwirkungen.
  • Zeit:
  • NTP mit redundanten, lokalen Stratum-Servern. Monotone Uhren nutzen, um Metriken robust zu aggregieren.
  • Safe Modes:
  • Wenn zentrale Kommandos fehlen, fällt Edge auf bewährte Konfigurationen zurück, begrenzt nicht-kritische Funktionen, warnt lokal (HMI) vor degradierter Betriebsart.

Sicherheit über Zero Trust, nicht über Tunnels

VPNs sind nicht per se böse, aber sie erzeugen große implizite Vertrauensdomänen. Besser:

  • mTLS für jede Edge↔Control-Verbindung, beidseitige Authentifizierung.
  • Autorisierung eng an Identität und Kontext (Gerät/Site/Role) gebunden.
  • Broker-Bridging/Reverse-Proxy, keine eingehenden Ports in Produktionsnetze.
  • Segmentierung: Pro Site eigene Mandantendomänen, Firewall-Policies, Air-Gap-fähige Betriebsmodi mit kuratiertem Datentransport.

Latenz und Rechenbudget: 100 ms sind eine harte Mauer

Für Qualitätsprüfung, Bahnübergangssensorik, Kollisionswarnungen oder Robotik gilt: Inferenz an den Rand. Die Cloud – oder selbst das zentrale Rechenzentrum – liefert Trainingszyklen, Modellselektion und Flottenanalyse. Die Architektur muss das reflektieren:

  • Edge-Inferenz:
  • Model-Optimierung (INT8-Quantisierung, TensorRT/ONNX-Optimierung), um SLAs zu halten.
  • Echtzeit-Threads/CPU-Isolierung, NUMA-Awareness auf stärkeren Knoten.
  • Lokale Puffer für Frames/Samples mit Prioritätswarteschlangen.
  • Zentrale Aufgaben:
  • Training, Evaluierung, A/B-Analysen, Flottenweite Drift-Erkennung auf Metadatenebene.
  • Entscheidungsgrundlagen liefern, nicht Regelkreise fernsteuern.

Governance und Nachvollziehbarkeit

Souveränität braucht Governance-Werkzeuge, die auditierbar sind:

  • Vollständige Update-Historie pro Gerät, mit Wer-hat-was-wann.
  • Policy-as-Code: Welche Artefakte dürfen wohin, unter welchen Bedingungen.
  • Reproduzierbare Builds, deterministische Container-Images soweit möglich.
  • Zugriffe rollenbasiert, Vier-Augen-Freigaben für kritische Flottenaktionen.

Build-vs-Buy unter Souveränitätsbedingungen

Hyperscaler-IoT-Plattformen erleichtern den Start, kosten aber Souveränität: Identitäten liegen extern, Telemetrie fließt über fremde Infrastrukturen, Exportkontroll- und Datenschutzfragen werden zu Vertragsfragen. Eine souveräne Alternative mit offenen Standards und on-prem-Komponenten bedeutet mehr Eigenbetrieb – aber volle Kontrolle.

Pragmatische Kombinationen:

  • Edge-Stack auf OSS-Basis (MQTT-Broker, Registry, Observability), gehärtet und integriert.

  • Zentrales Event-Backbone on-prem, optional über dedizierte Leitungen in ein europäisches, kontrolliertes Trainings-Cluster gespiegelt – ohne Produktionsdaten, nur abgeleitete Features/Statistiken.

  • Keine harten Abhängigkeiten von proprietären Geräte-SDKs; Standardprotokolle, austauschbare Komponenten.

Schritt-für-Schritt-Einführung

  • Inventarisierung: Welche Gerätetypen, welche Netze, welche Betriebsfenster?
  • Minimal Viable Fleet: 20–50 Geräte mit vollständigem Lifecycle (Enroll → Config → Update → Observability → Rollback).
  • Härtung: PKI-Lebenszyklus, Signaturpflicht, Firewall-Policies, Notfallprozeduren.
  • Skalierung: Site-Proxies, Bandbreitenprofile, Canary-Verfahren, Playbooks.
  • Kontinuierliche Verbesserung: Metriken definieren (MTTR, Rollback-Quote, Update-Durchlaufzeit, Telemetrie-Verlustquote) und Prozesse datengetrieben justieren.

Praxisnahe Stolpersteine und wie man sie umschifft