Wann 100 ms den Unterschied machen: Ein Latenz-Budget, das Projekte rettet

Nehmen wir visuelle Anomaliedetektion am Band mit automatischer Ausschleusung. Das Budget beträgt 100 ms vom Bild bis zur Aktorik:

  • Capture + Debayer/Resize: 10–20 ms, abhängig von Sensor/Interface.
  • Preprocessing (Normalization, ROI, Tensor-Package): 5–10 ms.
  • Inferenz: 20–50 ms, variiert je nach Modellgröße und Beschleuniger.
  • Postprocessing (NMS, Tracking, Heuristiken): 5–10 ms.
  • Entscheidung + Aktuator: 5–10 ms.
  • Netzwerk: 0 ms Budget – weil Netzwerk unzuverlässig ist. Entscheidungen müssen lokal fallen.

Alles, was zyklisch regelt oder Ausschleusungen triggert, darf kein WAN in der Schleife haben. Die Cloud kann das Ergebnis visualisieren, Trends analysieren und Modelle trainieren – aber nicht entscheiden.

Hybrid-Architekturen: Edge-Inferenz, Cloud-Training – ohne Souveränität zu verlieren

Das praktikable Muster:

  • Training/Finetuning: On-Prem-Cluster, wenn Trainingsdaten sensibel sind. Cloud kann ergänzen für nicht-sensible Datensätze, synthetische Daten oder Heavy Compute mit sauberer Anonymisierung.
  • Feature-Logging statt Rohdaten: Edge schreibt feingranulare, semantisch reduzierte Logs. Für Edge-Kameradaten: nur Crops mit starker Maskierung, kurze retention, hashes statt volle Frames.
  • Evaluation am Rand: Shadow-Modelle laufen parallel, sammeln nur Metriken. Switch-over erfolgt lokal nach klaren Health-Kriterien, nicht durch einen zentralen Schalter.
  • Reproduzierbarer Artefakt-Flow: Model Registry mit signierten Artefakten, SBOM, Provenance. Ausrollung über Fleet Management, ringbasiert und reversibel.

Protokollwahl im Detail: OPC UA, MQTT/Sparkplug B, Kafka – und wie sie zusammenspielen

  • OPC UA
  • Stärken: Semantische Informationsmodelle, Browsing, Alarme/Ereignisse, Security-Modelle, Integrationstiefe im Shopfloor.
  • Schwächen: Für WAN und sehr große Fan-outs weniger geeignet; Implementierungsqualität variiert; Overhead bei schwachen Geräten.
  • Einsatz: Direkt an der Maschine, für Engineering-Teams, die Semantik ernst nehmen und bidirektional arbeiten.
  • MQTT (+ Sparkplug B)
  • Stärken: Leichtgewichtig, gut über instabile Netze, klare Pub/Sub-Entkopplung. Mit Sparkplug B wird Statefulness (Birth/Death), Hierarchie und Metric-Struktur standardisiert.
  • Schwächen: Reines MQTT ohne Konventionen verwildert schnell (Topic-Sprawl). Persistenz und Replays sind zuzukaufen.
  • Einsatz: Edge-zu-Edge, Edge-zu-Backbone, wenn Robustheit und Einfachheit im Vordergrund stehen.
  • Kafka (oder kompatible Event-Streaming)
  • Stärken: Hoher Durchsatz, Replays, strikte Backpressure, genau einmal-Semantik je nach Design.
  • Schwächen: Nicht WAN-freundlich; Betriebskomplexität. Für einen Sensor auf LTE überdimensioniert.
  • Einsatz: Werk-/Datacenter-Backbone, Aggregation, Langzeitanalytik, ML-Feature-Stores.

Ein gesundes Pattern ist: OPC UA → Normalisierung → MQTT/Sparkplug über Werksgrenzen hinweg → Lokaler Kafka-Backbone im Werk/Rechenzentrum. Damit sind Edge-Knoten schlank, WAN ist robust, und im Core bekommen Sie Historie/Replays.

Fleet Management bei Tausenden Edge-Knoten

Drei Dinge machen den Unterschied zwischen Pilot und Produktion:

  • Deklarativ und idempotent: Ein Gerät, das nach zwei Tagen Offline wieder online kommt, zieht exakt den gewünschten Zustand. Kein manuelles “Drücken”.
  • Rollouts mit eingebauten Bremsen: Health-Gates lesen Edge-Metriken (CPU, Dropped Frames, Fehlerraten). Wenn eine Metrik kippt, stoppt die Welle automatisch und rollt zurück.
  • Debug ohne Risiko: Remote Shells sind tabu. Stattdessen: Remote Profiles/Traces, limitierte Log-Pulls, Snapshots unter Ressourcen- und Datenschutzgrenzen. Für echte Notfälle ein “Break-Glass”-Prozess mit Audit-Trail.

Sicherheitsmodell, das Audit besteht

  • Root of Trust: TPM/SE, Secure Boot, Measured Boot.
  • Kurzlebige Identitäten: SPIFFE/SPIRE oder gleichwertiges System für Service- und Device-Identitäten.
  • Autorisierung bis zum Topic/Schema: Ein Edge-Service darf nur die Topics lesen/schreiben, die sein Auftrag verlangt. Durchsetzen per mTLS + Policy Engine.
  • Air-Gap/Diode: In Defense/KritIS ist oft Einweg-Datenfluss zwingend. Store-and-Forward mit physischen Diode-Pfaden oder strikt segmentierten Export-Proxys.

Anti-Patterns aus der Praxis

  • Zentraler Cloud-Broker als Single Point of Failure im Produktionsfluss.
  • “Wir loggen erstmal alles Rohvideo in die Cloud” – scheitert an Bandbreite, Kosten, Recht.
  • Unbounded Topic-Kardinalität (“device/{id}/…”) ohne Governance – Monitoring und ACLs werden unwartbar.
  • Latenz wird “am Ende optimiert” – Budgetierung muss vor Auswahl der Modelle/HW passieren.
  • PSKs auf Geräten – früher oder später leaken sie. Hardware-gebundene Keys sind Pflicht.

Mini-Fallskizzen: Wo Cloud Sinn hat – und wo Edge Pflicht ist

  • Pilotenausbildung (Cloud sinnvoll): Global verteilte Trainings, Nutzerzugriff weltweit, starke saisonale Lastspitzen. Personendaten streng segmentieren, Identitätsmanagement sauber regeln, Medieninhalte via CDN. Latenz für Interaktion ist wichtig, aber nicht deterministisch-hard.
  • Fleet-Intelligence im Bahnnetz (Edge/On-Prem Pflicht): Fahrzeuge als bewegliche Edge-Knoten, Depots mit Aggregationsknoten. Link ist intermittierend. Entscheidungen (z. B. sicherheitsrelevante Alarme, Fahrzeugzustände) fallen lokal; Uploads in Wartungsfenstern. Werk- und Landesgrenzen sind real.
  • Visuelle Qualitätskontrolle in der Fertigung (Edge Pflicht): Zyklische Entscheidungen in 50–100 ms, Privacy-Scope für Mitarbeiter. Cloud für Analytik/Training, nicht für Live-Entscheidungen.

Souveränität als methodischer Treiber

“Souveränität ermöglicht Intelligenz” ist für uns kein Slogan, sondern ein Entwurfsprinzip: Wenn die Datenhoheit und die Verfügbarkeit lokal gesichert sind, können Sie ohne Kompromisse automatisieren, datengetrieben steuern und verbessern. Souveränität heißt nicht “nie Cloud”, sondern: Die Architektur lässt rechtliche, physikalische und operative Zwänge nicht vom Hype überschreiben.

Praktische Checkliste zum Projektstart

  • Klassifizieren Sie Daten früh: Was darf nie raus? Was nur aggregiert? Was nach Maskierung?
  • Definieren Sie Latenzbudgets pro Use-Case und messen Sie die Pipeline-Stufen auf der Zielhardware.
  • Legen Sie die Protokoll-Grenzen fest: Wo ist OPC UA Ende? Wo beginnt MQTT/Sparkplug? Wo lebt Kafka?
  • Bauen Sie die Control Plane zuerst: Identitäten, attestation, OTA-Update, Device Twin.
  • Planen Sie Observability und Zeitsynchronisation als Muss-Anforderungen, nicht als “später”.
  • Entwerfen Sie einen ringbasierten Rollout-Prozess mit automatischen Health-Gates und Revert.
  • Entscheiden Sie Cloud-Nutzung gezielt: Training? Reporting? Globale User? Aber nicht in der Regelkette.

FAQ – Häufige technische Fragen