Praktische Stolpersteine und ihre Gegenmittel

  • OPC UA Subscription Storms: Wenn tausende Knotenpunkte mit niedrigen Sampling-Intervallen überwacht werden, kollabiert der Server. Gegenmittel: Sampling-Hierarchien, Deadbanding, Event-basierte Reports, mehrere Server-Instanzen.

  • MQTT Wildcard-Hölle: Unkontrollierte Topic-Nutzung führt zu ACL-Albträumen. Gegenmittel: Strenge Namenskonventionen, Tenant-Isolation, ACLs pro Gerät, dedizierte Command-Topics.

  • Kafka im WAN: Direkt über Standorte verteilt führt zu Latenz und Split-Brain-Risiken. Gegenmittel: Pro Standort Cluster, zwischen Standorten asynchrone Replikation über dedizierte Transferdienste.

  • Hardware-Heterogenität: Unterschiedliche Beschleuniger brechen Portabilität. Gegenmittel: ONNX als Zielformat, Build-Matrix, Capabilities Discovery am Edge, fallback-Pfade.

  • Air-Gap-Updates: „USB-Stick-DevOps“ skaliert nicht. Gegenmittel: Physisch isolierte, aber logisch verbundene Update-Hubs mit strikt kontrollierten Ingress-Pipelines und Offline-Signaturprüfungen.

Ein Wort zur europäischen Cloud und DSGVO
Auch wenn rechtliche Rahmenlagen sich weiterentwickeln: Für kritische Produktions- und Infrastrukturdaten ist die beste Risikoreduzierung oft, die Daten die Anlage nie verlassen zu lassen. Europäische Cloud-Angebote oder strikt europäisch betriebene Tenants können für sekundäre Workloads sinnvoll sein, ändern aber selten die Edge/On-Prem-Pflicht für Kernfunktionen. Die Architektur sollte daher so angelegt sein, dass sie mit und ohne Cloud identisch funktioniert – Cloud ist ein optionaler Beschleuniger, kein Single Point of Failure.

Beispielhafte Minimal-Stacks pro Schicht

  • Edge-Gateway: Ubuntu Core/Yocto, containerd, k3s, ONNX Runtime/TensorRT, Eclipse Paho Client, TPM2-Tools

  • Standortbus: EMQX/HiveMQ oder Mosquitto (klein), Redpanda/Kafka, Schema Registry

  • Verarbeitung: Flink/ksqlDB, TimescaleDB, MinIO

  • MLOps: MLflow Registry, Seldon Core/Bento, Feast

  • Sicherheit: HashiCorp Vault (On-Prem), step-ca/Smallstep PKI, WireGuard für Punkt-zu-Punkt

  • Observability: Prometheus, Loki/Vector, Grafana, OpenTelemetry Collector

Woran man eine gute Architektur erkennt

  • Offline-fähig: Kritische SLOs werden ohne Internet und ohne Cloud erfüllt.

  • Deterministisch: Gleicher Input -> gleicher Output, reproduzierbar im Teststand.

  • Auditierbar: Jede Aktion ist einer Version, einem Commit, einer Signatur zuordenbar.

  • Austauschbar: Komponenten sind ersetzbar; keine proprietären Sackgassen im Kernpfad.

  • Kostentransparent: Betriebskosten dominieren nicht die Einsparungen durch Automatisierung.

Fazit
Edge vs. Cloud ist in der Industrie keine Glaubensfrage, sondern eine Sicherheits- und Souveränitätsfrage. Wenn das Risiko eines Datenabflusses, die Latenzanforderungen oder rechtliche Vorgaben hoch sind, ist On-Premise nicht „Oldschool“, sondern State of the Art. Cloud kann helfen – beim Training, bei Simulation, bei übergreifender Analyse –, darf aber nie zum Nadelöhr der Produktion werden. Wer Souveränität architektonisch ernst nimmt, entscheidet Protokolle, Identitäten, Updatepfade und Observability so, dass sie unabhängig von externer Infrastruktur funktionieren. Alles andere ist ein späteres Retrofit mit hohen Kosten.

FAQ

1) Ist Kubernetes am Edge nicht Overkill?
Kommt auf die Komplexität an. Für ein einzelnes Inferenzmodul reichen systemd-Services. Sobald Sie mehrere Dienste, Sidecars (z. B. für Telemetrie), Canary-Rollouts, Secrets-Management und GitOps brauchen, ist k3s erstaunlich leichtgewichtig und reduziert langfristig die Betriebskomplexität – vorausgesetzt, Sie signieren Images und begrenzen den API-Scope streng.

2) OPC UA oder MQTT – was nehme ich für neue Anlagen?
Für semantisch reiche, steuernde Pfade (Zustände, Parameter, Methoden) ist OPC UA die erste Wahl. Für reine Telemetrie, Events und leichtgewichtige pub/sub-Muster ist MQTT unschlagbar. Meist landen Sie bei einer Kombi: OPC UA nahe an der Maschine, MQTT für Standort-weite Distribution, Kafka für Persistenz/Auswertung.

3) Wie rotiere ich Zertifikate in einer air-gapped Umgebung?
Mit einer internen PKI und kurzlebigen Zertifikaten, die über einen lokalen Enrollment-Workflow verteilt werden. Edge-Geräte haben einen Geräteschlüssel im TPM. CRLs/OCSP-Stapling werden periodisch über einen signierten, offline eingebrachten Paketkanal aktualisiert. Keine statischen, jahrelang gültigen Zertifikate.

4) Wie teste ich Latenzbudgets realistisch?
Definieren Sie End-to-End-SLOs (z. B. „Bildaufnahme bis Aktortrigger P99 < 80 ms“) und instrumentieren Sie jede Stufe mit Zeitstempeln. Messen Sie unter Produktionslast, mit aktivem Logging, Störungen im Netzwerk und künstlichem Jitter. Cloud-Komponenten werden dabei explizit aus- und wieder eingeschaltet, um Degradationsmodi zu verifizieren.

5) Wie verhindere ich, dass Lieferanten die Souveränität aushebeln?
Vertraglich und technisch. Vertragsseitig: Datenhoheit, On-Prem-Pflicht für sensible Pfade, Audit-Rechte, SBOM-Pflicht. Technisch: Eigene PKI, Zutritts- und Zugriffskontrolle, segmentierte Netze, keine Vendor-Cloud-Agents in Kernzonen, klare Exportpfade nur über Ihren Bus, alles signiert und protokolliert.

Wenn Sie Edge-Architektur, Protokolle und Governance so planen, bleibt die Kontrolle dort, wo sie hingehört: in Ihre Werkshallen, Fahrzeuge und Leitstände – nicht in eine externe API. Souveränität ermöglicht Intelligenz, nicht umgekehrt.