• Kafka (oder kompatible Log-Systeme)
  • Stärken: Hoher Durchsatz, Partitionierung, Replays, genau-einmal Semantik in der Verarbeitung, Integration mit Stream Processing.
  • Schwächen: WAN-unfreundlich, Betriebsaufwand; nicht für millisekundenkritische Roundtrips; benötigt sauberes Schema-Management (Avro/Protobuf).
  • Typische Rolle: Standortweiter Datenbus und Persistenzschicht; historische Replays; Training-Set-Extraktion; Audit.

Pattern aus der Praxis:

  • Feldgeräte/OPC UA -> Edge-Gateway abonniert Subscriptions, normalisiert, publiziert als MQTT-Telemetrie (kompakte Payloads, Protobuf/CBOR).

  • Standort-Broker (MQTT) -> Bridge/Connector -> Kafka-Cluster: Verdichtung, Retention, nachgelagerte Auswertung.

  • Rückkanal: Steuernde Kommandos nicht über Kafka, sondern über OPC UA Methoden oder gezielte MQTT-Topics mit strikter Access Control; niemals Safety-Pfade.

  • Schema-Verwaltung: Protobuf-Schemata versioniert, rückwärtskompatibel; bei Kafka Schema Registry, bei MQTT durch Topic-Kontrakte plus eingebettete Versionsfelder.

Handling tausender Edge-Geräte: Fleet-Management ohne Kontrollverlust
Souveränität heißt hier: Sie sind Eigentümer aller Schlüssel, Zertifikate, Images, Policies und Metriken. Ohne US-Cloud-Abhängigkeit. Das ist machbar, wenn man einige Prinzipien einhält.

  • Hardware-Basis
  • Industrietaugliche Geräte mit TPM 2.0, Watchdog, ECC-RAM, NVMe mit Power-Loss-Protection
  • Beschleuniger optional: iGPU (Intel), dGPU (NVIDIA), Edge-TPUs – aber nur, wenn das Modell es wirklich braucht
  • Betriebssystem und Container
  • Minimal-OS, read-only Root (A/B), signierte Updates, kein SSH als Dauerlösung, stattdessen kurzlebige Support-Tunnels
  • Container Runtime mit Signatur-Verifikation; Rootless, seccomp, AppArmor/SELinux
  • Orchestrierung: k3s für Lightweight-Kubernetes oder Systemd-nativ, je nach Komplexität; GitOps (FluxCD/ArgoCD) für deklarative Zustände
  • OTA-Updates und Progressive Delivery
  • A/B-Partitionen mit Health-Checks; atomare Rollbacks
  • Canary-Rollouts gestaffelt nach Standort, Linie, Zelle; automatischer Stop bei SLO-Verletzungen
  • Paketierung: OS-Update getrennt von Applikations-Update; Modelle als eigenständige, signierte Artefakte
  • Identitäten und Zertifikate
  • Manufacturing Provisioning: Geräte erhalten bei Produktion einen Geräteschlüssel im TPM und ein Enrollment-Zertifikat
  • Onboarding vor Ort über kurzlebige Bootstrap-Tokens; danach Rotationszyklus automatisiert, CRL/OCSP auch offline-fähig (stapled)
  • Keine gemeinsam genutzten Secrets; alles geräteindividuell
  • Observability
  • Edge exportiert Metriken (Prometheus) pull-basiert vor Ort; Remote nur über Gateways
  • Logs lokal gepuffert (Loki/Vector), rate-limited nach oben; personenbezogene Daten maskiert
  • Traces für Performancehotspots, Sampling aggressiv; nie vollständige Rohdaten unkontrolliert nach außen
  • Resilienz
  • Offline-first: Jede kritische Funktion muss ohne Cloud und ohne WAN funktionieren
  • Store-and-forward: Persistente Queues auf Edge, Backoff/Jitter; idempotente Serverpfade
  • Degradationsmodi definiert: Wenn Modell X nicht lädt, fällt auf Regelwerk Y zurück; Operator wird benachrichtigt, Anlage läuft sicher weiter

Hybrid-Architektur: Edge-Inferenz + Cloud-Training (ohne Souveränität zu verlieren)
Cloud kann sinnvoll sein, wenn sie als Beschleuniger für nichtkritische, gut entkoppelte Teile dient.

  • Datenexport mit Kontrolle
  • Sampling und Entschärfung an der Quelle: bounding boxes statt Vollbilder, Hashing/Maskierung, Quantisierung
  • Aggregation vor Export: Features statt Rohdaten; nur, was für Lernfortschritt nötig ist
  • Pseudonymisierung und klare Metadaten-Labels: Herkunft, erlaubte Nutzung, Löschfristen
  • Trainingspipeline
  • Reproduzierbar On-Prem ausführbar, Cloud nur als Skalierungsziel
  • Versionierte Datasets, Feature-Spezifikationen, Trainingskonfigurationen
  • Evaluationsmetriken gegen Edge-Constraints (Latenz, RAM, Energie) – kein reiner Offline-Score
  • Modell-Rollout
  • Modelle als OCI-Artefakte mit Signatur
  • Shadow- und A/B-Tests am Edge, harte SLOs: Latenz-P99, Fehlalarmrate, Throughput
  • Governance: Jede Entscheidung am Edge referenziert Modell-ID und Hash; für Audits nachvollziehbar

Latenzanforderungen: Warum 100 ms den Unterschied machen
Ein paar konkrete Budgets, die in der Praxis entscheiden, ob Cloud tabu ist:

  • Vision-basierte Qualitätskontrolle am Band
  • Kameraaufnahme bis Inferenz: 10–30 ms (je nach Auflösung/Beschleuniger)
  • Entscheidungslogik + Aktortrigger (z. B. Ausschleusen): 5–10 ms
  • Mechanik-Laufzeit und Puffer: 20–50 ms
  • Budget gesamt: typischerweise <100 ms. Jede WAN-Roundtrip-Latenz zerstört diese Bilanz, insbesondere unter Jitter.
  • Mensch-Maschine-Interaktion (HMI) mit Assistenzfunktionen
  • Perzeptions-Feedback-Schleife: >200 ms fühlt sich träge an; >100 ms erhöht Fehlerquoten bei manuellen Tätigkeiten
  • Edge-Inferenz hält Interaktionen konsistent, Cloud speist nur periodisch Wissensupdates ein
  • Flottenweite Koordination (Bahn/Logistik)
  • Lokale Entscheidungen (z. B. Bremsvorgänge, Kollisionslogik) sind edge-only
  • Cloud kann Taktung, Routenplanung, Energieoptimierung vorrechnen, aber niemals im kritischen Pfad liegen

Wesentliche Erkenntnis: Nicht nur der Median zählt, sondern P99 und P99.9 – die seltenen Ausreißer sind die, die reale Anlagen aus dem Takt bringen. Deshalb sind deterministische Pfade ohne externe Abhängigkeiten so wertvoll.

Souveränität operativ verankern: Daten, Modelle, Lieferkette
Souveränität ist kein Compliance-Dokument, sondern eine Kette technischer Entscheidungen, die im Alltag halten müssen:

  • Datendomänen trennen: Rohdaten mit Geheimschutz bleiben in einer „rote Zone“. Nur abgeleitete, freigegebene Daten dürfen in „gelbe“ oder „grüne“ Zonen.
  • Rechte und Verantwortlichkeiten: Wer darf Daten exportieren? Wer signiert Modelle frei? Welche Telemetrie ist zulässig? Alles als Code und Policies, nicht als PDF.
  • Reproduzierbarkeit und Audit: Jeder Edge-Entscheidungspfad muss in einer On-Prem-Umgebung reproduzierbar sein – ohne Internet. Dazu gehören Container-Images, Modelle, Konfigurationen, Schemata.
  • Lieferkette härten: SBOMs für jede Komponente, Signaturprüfungen in der Runtime, periodische Updates unter eigener Kontrolle. Keine Black-Box-Cloud-Komponenten im Kernpfad.