• MQTT → Kafka: Deduplication-Key = Geräteseriennummer + Message-Sequence. “Exactly-once” erreichen Sie praktisch mit idempotenten Konsumenten und Transaktions-Grenzen erst im Core; am Edge genügt at-least-once mit deterministischer Verarbeitung.
  • Backpressure: Am Edge steuern Sie per lokaler Queue und Priorisierung (Alarme > Betriebstaten > Rohdaten). Vermeiden Sie endloses Wachstum: Ringpuffer mit Drop-Policy für am wenigsten wichtige Klassen.

Flottenmanagement: Tausende Edge-Geräte koordinieren

Geräteidentität & -vertrauen:

  • Hardware-Root of Trust: TPM/TEE für Schlüsselspeicherung. Geräte bekommen bei Inbetriebnahme ein X.509-Zertifikat von Ihrer eigenen CA; kein ausgelagertes “Trust-as-a-Service”.
  • Provisionierung: Just-in-time Registration mit Kurzzeit-Bootstrap-Zertifikat, danach Rotation in produktive Identität. On-Site-Provisionierung möglich, falls keine Internetverbindung.
  • Mutual TLS überall: Broker, API, Update-Server. Zertifikatsrotation automatisiert, mit abgestuften Gültigkeiten.

Konfiguration als Code:

  • Desired/Reported State: Digitaler Zwilling pro Gerät. Änderungen werden deklarativ beschrieben, idempotent angewendet, mit Diff/Vorschau.
  • Policy-Vererbung: Werk > Linie > Zelle > Maschine. Abweichungen sind Ausnahmen mit Begründung und Ablaufdatum.

Sichere OTA-Updates:

  • Signierte Artefakte, A/B-Partitionen, Rollback bei Healthcheck-Fail. Delta-Updates, um Bandbreite zu sparen.
  • Gestaffelte Rollouts: Canary (1 %), dann 10 %, dann Wellen pro Standort/Schichtfenster. Harte Sperrzeiten für produktionskritische Phasen.
  • Kompatibilitäts-Matrix: Geräteklassen + Modell-/Runtime-Versionen. Keine “ad hoc”-Kombinationen im Feld.

Observability am Rand:

  • Metriken/Logs/Traces lokal puffern, verdichten, und nur Kennzahlen ausleiten. Für Tiefendiagnose: zeitlich begrenzte “Debug-Tunnel” mit expliziter Freigabe.
  • Zeit: NTP/PTP, monotone Uhren nutzen; Ereigniszeit ≠ Ingestionszeit. Korrelation über Event-IDs und Sequenzen, nicht über vage Zeitfenster.

Sicherheit als Laufzeit-Eigenschaft:

  • Least Privilege: Jeder Container, jeder Prozess, jedes Topic hat minimalste Rechte. mTLS + topic-level ACLs, signierte Policies.
  • Datenklassifikation am Device: Jedes Event trägt Label (öffentlich, intern, vertraulich, streng-vertraulich). Egress-Engine entscheidet anhand Label + Policy.
  • Auditierbarkeit: Alle Entscheidungen (z. B. “Event verworfen wegen Policy X”) sind maschinenlesbar protokolliert.

Latenzbudgets: Warum 100 ms den Unterschied machen

Es gibt eine harte Grenze zwischen “bedienbar” und “zu spät”. Beispiele aus der Praxis:

  • Visuelle Montagefehlererkennung: Kamera erfasst Bauteil, Inferenz klassifiziert, PLC stoppt Band – alles innerhalb 80 ms. Dafür brauchen Sie: Kameratreiber mit Zero-Copy in den Inferenzprozess, warmgehaltene Modelle (kein On-Demand-Laden), Batching deaktiviert, CPU/GPU Pinning, Pre-/Postprocessing in demselben Prozessraum oder Shared Memory. Netzwerk hops? Null.
  • Akustische Anomalieerkennung an Spindeln: Kurze FFT-Fenster, Schwellenwertlogik, lokales Regelwerk. Cloud-Analyse dient nur zur Modellverbesserung, nicht zur Echtzeit-Regelung.
  • Bahnflotte: Telemetrie puffern, an Depots hochladen. Während der Fahrt werden nur hochkritische Zustände übertragen. Lokales Auswerten erlaubt predictive Maintenancesignale an den Fahrer innerhalb Sekunden, nicht Minuten.

Planungstipp: Definieren Sie Budget pro Schritt (Sensor → Puffer → Feature → Inferenz → Aktor) mit Maximalzeiten, nicht Durchschnitt. Jedes Plus an hops und Serialisierung frisst Budget.

Hybrid-ML: Edge-Inferenz, zentrales Training – aber souverän

Edge ist der Ort für Inferenz. Training braucht oft mehr Ressourcen. Der Souveränitätsfaktor entscheidet, wo der Trainings-Stack läuft: On-Prem-Cluster oder europäischer souveräner Cloud-Anbieter. Architekturelemente:

  • Datenwahl statt Datensammelwut: Unsichere Inferenz, Out-of-Distribution-Detektoren, aktives Lernen wählen wenige repräsentative Beispiele aus. Annotieren nahe der Quelle, wenn möglich (Operator UI).
  • Versionierung & Reproduzierbarkeit: Datasets, Features, Modelle sind versioniert; Trainingsläufe sind deterministisch reproduzierbar (Seeds, Container, Hardwareprofile).
  • Validierung & Freigabeprozess: Modelle durchlaufen formale Checks (Genauigkeit, Latenz, Ressourcenverbrauch, Drift-Resilienz). Freigaben sind nachvollziehbar, keine “stille” Aktualisierung.
  • Rollout-Strategien: Shadow-Mode (nur beobachten), A/B-Messung, abgestufte Aktivierung. Telemetrie zur Laufzeit erfasst echte Performanz unter Produktionslast, ohne Datenexfiltration.

Governance für KI-Agenten und LLMs am Edge

Auch im IIoT tauchen LLM-basierte Assistenten/Agenten auf: für Wartungsleitfäden, Ticket-Triage, Anomalie-Beschreibung. In souveränen Umgebungen braucht es Observability und Policy-Enforcement on-prem:

  • Datenflüsse einschränken: Kein Rohtext mit PII in externe APIs. Redaktions- und Maskierungsstufen direkt am Edge/On-Prem.
  • Entscheidungsrahmen für Agenten: Welche Aktionen sind erlaubt? Welche Quellen sind vertrauenswürdig? Jede Aktion wird mit Kontext und Begründung protokolliert.
  • Audit & Reproduzierbarkeit: Prompt, Kontext, Modellversion, Tool-Aufrufe – alles muss nachvollziehbar sein. Nur so sind Entscheidungen später überprüfbar.

Wir bauen solche Governance-Schichten als Teil der Edge-/On-Prem-Architektur, sodass selbst “intelligente” Komponenten unter denselben Souveränitätsregeln laufen wie jede andere Pipeline.

Entscheidungsrahmen: Cloud oder Edge?

Stellen Sie die Architektur über folgende harte Kriterien:

  • Latenz: Muss eine Aktion in <100 ms passieren? Wenn ja, Edge. <10 ms? SPS/RTOS.
  • Konnektivität: Kann das System 48 h ohne Backhaul autonom arbeiten? Wenn nein: Machen Sie es möglich, oder verzichten Sie auf Cloud-abhängige Pfade.
  • Datenklassifikation: Dürfen Rohdaten das Gelände verlassen? Wenn nein, modellieren Sie Egress-Policies als Code, nicht als “Betriebsvereinbarung”.
  • Volumen: Liegt das Rohdatenvolumen (z. B. Video) >100 Mbit/s pro Linie? Verdichten am Rand, extrahieren Ereignisse. Cloud bekommt nur Signale.
  • Ressourcen vor Ort: Gibt es Platz/Power/Thermik für Edge-Compute? Falls knapp: konsolidieren Sie Workloads, vermeiden Sie “one box per vendor”.
  • Lieferkettenrisiko: Können Sie den Betrieb ohne Dritt-Cloud 12 Monate sicherstellen (Updates, Lizenzen, Zertifikate)? Wenn nein, Architektur ändern.

Pragmatische Umsetzungsschritte

  • Minimal viable Edge: Starten Sie mit einem Edge-Gateway, das nur einen Datenpfad souverän macht (z. B. eine Kameralinie). End-to-End-Härtung, OTA, Observability aufbauen. Dann skalieren.
  • Topics und Schemata als API: Dokumentieren Sie MQTT-Topics/OPC-Strukturen wie öffentliche APIs. Versionieren, Deprecation-Plan, Contract-Tests.
  • Egress-Policy testen: Unit- und Integrationstests, die belegen: Kein Rohbild verlässt das Gerät. Build bricht, wenn ein neuer Pfad dies umgeht.