Lieferkette und Updates

  • Artefakte sind Content-Addressable, signiert (z. B. mittels gängiger Signatur-Workflows). SBOMs (CycloneDX) verpflichtend, CVE-Gates in der CI/CD.
  • Air-gapped Promotion: Pakete als verifizierte Bundles mit manifestierten Hashes, offline verifizierbar.
  • Staged Rollouts: Ring 0 (Labor) → Ring 1 (Pilot-Geräte) → Ring 2 (5%) → Ring 3 (100%). Automatisches Stop bei Health-Regression. Rollback first-class.

Auditierbarkeit

  • Append-only Audit-Logs für Konfigurationsänderungen und Datenbewegungen. Hashverkettung, Zeitstempel, Signaturen. Revisionssicher und querprüfbar zwischen Edge und Zentrale.

5) Latenzpfade richtig schneiden: warum 100 ms den Unterschied machen

Drei Klassen von Regelkreisen:

  • Unter 20 ms: klassische SPS/RT-Anteile, TSN/OPC UA PubSub lokal. KI hier nur, wenn fest deterministisch und echtzeitfähig – meist nicht praktikabel außerhalb Spezialhardware.
  • 20–100 ms: typische visuelle Erkennung mit Aktorik (z. B. Ausschleusen). Inferenz zwingend am Edge, Vorverarbeitung möglichst nah an der Kamera, Kommunikationspfad minimiert (kein unnötiger Kopier- oder Serialisierungsoverhead).
  • >1 Sekunde: Flottenentscheidungen, Optimierungen, abgeleitete KPIs. Hier kann zentral gesammelt, aggregiert, geplant werden.

Wichtig ist die Ende-zu-Ende-Latenz, nicht nur die Inferenzzeit: Kameraexposition + DMA + Preprocessing + Inferenz + Postprocessing + Feldbus/IO + Aktorik. Wer 60 ms Inferenz feiert, aber 120 ms auf dem Feldbus verliert, hat das System nicht verstanden.

6) Hybrid-ML: Edge-Inferenz, zentrales Training ohne Datensouveränität zu verschenken

Datenauswahl

  • Selektives Sampling: Reservoir Sampling/Sketching, Score-basierte Auswahl (Unsicherheit, Neuheit), begrenzte Batches.
  • On-Edge-Anonymisierung: PII-Redaktion, Bounding-Box-Crops statt Vollbilder, Downsampling. Auditierbar, reproduzierbar.
  • Labeling-Pipeline: Kleine, kuratierte Sätze mit klarer Herkunft. Keine „Saug alles in die Cloud“-Mentalität.

Training in souveräner Umgebung

  • Self-hosted MLOps: Reproduzierbare Pipelines, Feature Stores, Model Registry mit Lineage. Keine nicht-europäischen Abhängigkeiten, wenn Compliance dies fordert.
  • Deterministische Builds: Feste Seeds, containerisierte Toolchains, dokumentierte Abhängigkeiten.

Modell-Delivery

  • Portables Format (z. B. ONNX) mit Hardware-spezifischen Builds (TensorRT, OpenVINO) pro Edge-Profil.
  • A/B-Tests am Edge: Traffic-Splitting oder Shadow-Inferenz. Messgrößen: Accuracy-Drift, Latenz, Ressourcennutzung. Rollback jederzeit machbar.

7) Flottenmanagement für tausende Knoten: ohne „Remote-Root-Shell“ als Betriebsmodell

Skalierung und Topologie

  • Hierarchische Steuerung: Regionale Proxies/Broker, die Policies durchsetzen und Telemetrie voraggregieren.
  • Desired State deklarativ: GitOps-Prinzip, Snapshots signiert und für Edge gecacht. Edge zieht gewünschte Zustände, nicht „wir schieben SSH-Befehle“.
  • Enrollment/Attestation: Zero-Touch durch vorinstallierte Identitäten, Remote Attestation via TPM-Quotes. Kein Gerät wird zugelassen, das seine Integrität nicht nachweist.

Ressourcen- und Bandbreitensteuerung

  • QoS-bewusste Backpressure vom Datensee bis zum Sensor. Kein „Firehose-zu-CSV“-Antipattern.
  • OTA-Fenster und -Raten begrenzen: keine Flotten-Blackouts durch Parallel-Updates. Canaries wählen, die repräsentativ sind.

Observability

  • Edge-Health: CPU/GPU, Thermals, I/O-Fehler, Broker-Backlogs. Zentraler Überblick, aber lokale Alerting-Fähigkeit bei Netztrennung.
  • Traceability: E2E-Tracing auch am Edge (leichtgewichtig), Korrelation bis zur Entscheidung am Aktor.

8) Zwei Projektscheiben: warum die Entscheidung nicht ideologisch ist

Luftfahrt-Trainingsplattform (Cloud sinnvoll, aber begrenzt)

  • Multi-Tenant-Architektur, elastische Compute-Pools, EU-Datenhaltung, strikte Trennung von PII und Telemetrie durch unterschiedliche Pipelines und Schlüsselräume.
  • Trainingsjobs skalierten in Minuten, aber alle personenbezogenen Daten wurden vor Persistenz pseudonymisiert. Export-/Reportingpipelines liefen in isolierten Namespaces mit Network Policies.

Bahn-Fleet-Intelligence (Edge-first notwendig)

  • Tunnels, Funklöcher, sporadische Backhauls. Lösung: Store-and-Forward mit sequentiell nummerierten Events, Idempotenz am Ingress, Delta-Kompression bei Opportunistic Sync.
  • Lokale Inferenz für Zustandsklassifikation, zentrale Rekonfiguration und Modellverteilung nur im Wartungsfenster. Die Flotte blieb funktionsfähig, auch wenn die Zentrale tagelang offline war.

9) Referenzarchitektur, in Worten

  • Feld: Sensor/PLC/Kamera → lokales Preprocessing (C/C++/Rust) → Inferenzdienst am Edge (ONNX/TensorRT) → Entscheidung an Aktor via Feldbus/OPC UA Method Call.
  • Telemetriepfad: Inferenz-Metadaten/Framesamples → MQTT Broker (Edge) → Policy-Filter (DLP, Label-Check) → MQTT Bridge → zentrales Ingress → Kafka + Schema-Registry → Data Lake/Feature Store.
  • Steuerpfad: Zentrale Desired State (GitOps Repo) → Signiertes Snapshot-Manifest → Edge-Puller validiert Signatur/Policy → wendet Konfig an → bestätigt mit Audit-Event.
  • Identität: Gerät mTLS mit Gateway, Gateway mTLS mit Zentrale. Workloads erhalten kurzlebige Zertifikate, alle Verbindungen verschlüsselt und authentifiziert.
  • Updates: Artefakt-Registry (On-Prem) → signierte Bundles → orchestrierter Rollout mit Health-Gates → Telemetrie misst Impact → automatisches Stop/Rollback bei Regression.

10) Kosten- und Betriebs-Trade-offs, die wir immer wieder sehen

  • Egress-Kosten und Latenz töten naive „Alles in die Cloud“-Designs, besonders bei Bildern/Videos. Rechnen Sie an der Kante – nicht nur aus Compliance-, sondern aus Kostengründen.
  • Kubernetes überall klingt einheitlich, ist es aber nicht. Für sehr kleine Gateways ist ein stabiler Supervisor mit wenigen Services oft robuster als ein Cluster, den niemand patcht.
  • „Ein Protokoll für alles“ ist ein Irrweg. MQTT am Edge, OPC UA zur Maschine, Kafka im Rechenzentrum: drei Stärken, sauber verbunden.
  • Ohne SBOMs und signierte Artefakte ist Ihr Updatepfad eine Supply-Chain-Risikoquelle. Das fällt Ihnen nicht im Labor, sondern am Freitag um 22:00 auf.
  • Pull-basiertes Konfigmanagement skaliert sicherer als verteilte SSH-Skripte. Auditierbarkeit schlägt kurzfristige Bequemlichkeit.

11) Entscheidungshilfe: On-Premise, Hybrid oder Cloud?

Wählen Sie On-Premise/Edge-first, wenn:

  • Netztrennung/Offline-Betrieb zwingend ist.
  • Latenzpfade unter 100 ms mit Aktorik geschlossen werden müssen.
  • Datenhoheit rechtlich/faktisch nur vor Ort garantiert werden kann.
  • Ihre Sicherheitsvorgaben Remote-Abhängigkeiten ausschließen.

Wählen Sie Hybrid, wenn:

  • Inferenz/Preprocessing am Edge nötig ist, aber Training/Analyse in einer souveränen zentralen Umgebung Mehrwert bringt.
  • Konnektivität unzuverlässig ist, aber regelmäßige Synchronisation möglich bleibt.
  • Sie stufenweise aus einer Cloud-zentrierten Lösung herauswachsen.