Protokollwahl: MQTT, OPC UA, Kafka – wofür, wo und wie kombinieren?

  • OPC UA

  • Stärken: Industrielle Semantik, Adressraum-Modellierung, etablierte Security-Mechanismen

  • Einsatz: Verbindung zu Maschinen/PLCs, wenn Semantik und herstellerübergreifende Interoperabilität wichtig sind

  • Trade-offs: Höhere Komplexität; für hochvolumige Event-Ströme weniger effizient

  • MQTT

  • Stärken: Leichtgewichtig, gute Eignung für instabile Netze, QoS-Stufen

  • Einsatz: Geräteleben, Telemetrie, Command/Control; mit Sparkplug B lässt sich ein konsistentes Industriemodell abbilden

  • Trade-offs: Topic-Wildwest ohne strenge Konventionen; kein eingebautes Replay

  • Kafka (oder kompatible Logs)

  • Stärken: Hohe Durchsätze, Replays, Backpressure-Kontrolle, Partitionierung

  • Einsatz: Lokale Site-Backbones für hochvolumige Sensorik (Video, Vibration), zentrale Analytics-Pipelines

  • Trade-offs: Ressourcenhungriger; Overkill für Kleingeräte oder reine Command/Control-Pfade

  • Kombinationsmuster

  • Feld → OPC UA → Edge-Adapter → MQTT (Sparkplug B) für Anlagenstatus

  • Hochvolumiges (z. B. Frames, FFTs) → lokales Kafka + kompakte Feature-Extraktion → MQTT Events für Entscheidungen

  • Brücken mit klarer Semantik: Mapping-Tabellen, Schemas im Repository, Versionierung, Fallback-Strategien

Fleet Management für tausende Edge-Geräte

  • Identität und Vertrauensanker

  • Geräteidentität bei Produktion/Inbetriebnahme vergeben (z. B. X.509, Ed25519)

  • Kurzlebige Tokens, regelmäßige Rotation, Revocation-Listen

  • Zero-Trust: Jede Verbindung ist neu zu beweisen, keine impliziten Vertrauenszonen

  • Software-Lieferkette

  • Artefakte als OCI-Images; Signaturen verpflichtend

  • Transaktionale Updates (z. B. A/B-Partitionen, atomare Commits)

  • Delta-Updates, Bandbreitenlimits, Wartungsfenster

  • Laufzeit-Isolation

  • Container mit read-only RootFS, nur definierte Volumes beschreibbar

  • Ressourcenlimits hart (CPU, RAM, IO) pro Workload; Prioritätsklassen

  • Watchdogs, Supervisor-Prozesse, automatisches Rollback bei Healthcheck-Fails

  • Observability, aber souverän

  • Pull-basiertes Metrics-Scraping verringert Angriffsfläche

  • Ereignisprotokolle manipulationssicher gestalten (Signaturen/Hash-Chains)

  • Remote Shells vermeiden; stattdessen deklarative Aktionen mit Audit-Trail

  • Konfigurationsstrategie

  • Desired-State-Modelle (z. B. CRDs) statt Ad-hoc-Skripte

  • Variantenmanagement: Flotten in Kohorten, Policies pro Kohorte

  • Rollouts als Experimente: Canary, Progressive Delivery, Halt-Kriterien

Latenztechnik: Warum 100 ms den Unterschied machen

  • Budgetierung

  • Sensorlesen: 5–10 ms (abhängig von Bus und Abtastung)

  • Preprocessing: 10–20 ms (z. B. Denoising, ROI-Cut)

  • Inferenz: 10–50 ms (abhängig von Modell, Hardware)

  • Entscheidung/Aktorik/Alarm: 5–10 ms

  • Netzwerkslack: 10–20 ms (nur lokal, keine WAN-Abhängigkeit)

  • Jitter-Quellen und Gegenmaßnahmen

  • CPU-Scheduling: Isolierte Kerne, RT-Prioritäten für kritische Threads

  • Speicher: Pinned Memory, Preallocation, keine on-the-fly Alokationen im Hot Path

  • Garbage-Collection: Keine GC im Hot Path; native oder Low-GC-Laufzeiten

  • I/O: Async I/O, Batching, Zero-Copy-Pfade wo möglich

  • Modelldienste: Warm Starts, vorab geladene Gewichte, Tensor-RT/ONNX-Optimierungen

  • Netzwerk

  • Layer-2 bevorzugen, deterministische Switches, QoS für Prioritätsklassen

  • Kein DNS im Hot Path; statische Endpunkte, lokales Service-Discovery

Datensouveränität als Architekturprinzip

  • Daten-Mindestprinzip

  • Nicht alles sammeln, was man sammeln könnte; definieren, welche Features wirklich nötig sind

  • Vor-Ort-Anonymisierung/Pseudonymisierung, wenn Daten das Gelände verlassen

  • Trennung von Daten- und Steuerungsebene

  • Sensible Rohdaten bleiben lokal; nur Modelle, Policies und de-identifizierte Statistiken gehen zentral

  • Audits verlangen Nachvollziehbarkeit: Wer hat wann welche Daten gesehen/übertragen?

  • Modellgovernance on-prem

  • Signierte Modelle, Freigabeprozesse, reproduzierbare Builds

  • Blackbox-Modelle ohne Reproduzierbarkeit sind in sicherheitsrelevanten Umgebungen schwer zu vertreten

  • LLM-gestützte Systeme in der Industrie

  • Retrieval und Wissensbasis lokal; keinerlei Prompt-/Kontextdaten an externe APIs

  • Agenten mit restriktiven Tools; jede Aktion ist nachvollziehbar, reversibel, begrenzt

  • Observability der Agenten on-prem: Token- und Tool-Logs bleiben im eigenen Scope

  • Governance: Prompt-Policies, PII-/IP-Filter, Rollback von Wissensartefakten

Wann Cloud sinnvoll ist – und wie ohne Souveränitätsverlust

  • Zentrale Modelltrainings, wenn Daten verdichtet und de-identifiziert sind

  • Flottenweite Analysen und Simulationen, die auf aggregierten Statistiken basieren

  • Nicht-kritische Dienste (z. B. Reporting, Langzeithistorisierung) – mit klarer Trennung: Kein Backchannel ins Operative

  • Private oder europäische Cloud-Umgebungen können die Elastizität liefern, ohne operative Pfade zu gefährden – vorausgesetzt, Datenklassifizierung und -trennung sind konsequent implementiert

Praxisnotizen aus realen Projekten

  • Eisenbahn-Fleet-Intelligence

  • Erfordernis: Edge-Entscheidungen trotz Tunnel, Bahnhofswechsel, sporadischem Netz

  • Lösung: Offline-First-Design, lokale Ereignislogbücher mit späterer Synchronisation, Inferenz on-train; zentrale Plattform nur für aggregierte Auswertungen und Modellverteilung

  • Cloud-Plattform für Pilotenausbildung

  • Erfordernis: Skalierbare Infrastruktur für Trainingsdaten, Evaluationspipelines und Simulationen

  • Lösung: Cloud für Elastizität und Batch-Verarbeitung; strikte Datenklassifizierung, sensible Cockpit- und Leistungsdaten entkoppelt; keine operative Abhängigkeit vom Netz in Simulatoren

  • Industrielle Bildprüfung

  • Erfordernis: 50–80 ms End-to-End, deterministisches Verhalten, Nachvollziehbarkeit

  • Lösung: Lokale GPU-Knoten, deterministische Pipelines, Vorberechnung von Features, Canary-Rollouts in Schichten, TSDB für Traceability

Checkliste: Cloud, Edge oder Hybrid?

  • Ist die 99,9%-Latenzanforderung < 100 ms inkl. Jitter?

  • Muss das System bei WAN-Ausfall voll funktionsfähig bleiben?

  • Dürfen Rohdaten das Gelände/das Land verlassen?

  • Welche Daten sind tatsächlich nötig für zentrale Zwecke? Lassen sie sich vor Ort verdichten/anonymisieren?

  • Gibt es Safety- oder Security-Zulassungen, die deterministische, reproduzierbare Pfade verlangen?

  • Wie groß ist die Flotte, und wie wird Identität/Update/Observability souverän gemanagt?

  • Können Sie klar trennen: Datenebene lokal, Steuerungsebene zentral?