• MQTT
  • Stärken: Leichtgewichtig, gut für instabile Netze, feingranulare Topics, QoS, geringe Overheads, breite Geräteunterstützung.
  • Schwächen: Brokerzentriert, eingeschränkte Schema-Evolution, Backpressure-Strategien nötig, Clusterung komplexer als gedacht.
  • Einsatz: Sensor→Gateway, Gateway→Hub bei mäßigen Raten, Command/Control mit Retained/Last Will.
  • OPC UA / PubSub
  • Stärken: Industrieller Standard, Typisierung, Security-Model, Integration mit PLCs, deterministischere Profile, TSN-Unterstützung in passenden Umgebungen.
  • Schwächen: Komplexität, Heterogenität der Implementierungen, PubSub über UDP/TSN braucht passende Netzumgebung.
  • Einsatz: Maschinen- und PLC-Integration, semantisch reichere Daten, Werksinterne Busse.
  • Kafka (oder Pulsar)
  • Stärken: Hohe Durchsätze, Replaying, starke Persistenzgarantien, Producer/Consumer-Entkopplung, Schema-Registry.
  • Schwächen: Nicht für direktes Gerätesprechen geeignet, benötigt stabilere Netzverbindungen und Ressourcen.
  • Einsatz: Gateway→Zentrale, zentrale Verarbeitung, Langstrecken-Datenlogistik, Multi-Consumer-Szenarien.

Typisches Muster:

  • Gerät spricht OPC UA oder proprietär → Edge-Adapter normalisiert nach MQTT/OPC UA.

  • Gateway transformiert zu Avro/Protobuf, validiert gegen Schema, schreibt in lokales WAL.

  • Asynchroner Forwarder publiziert in Kafka-Topics, unter Beachtung von Bandbreitenfenstern und Prioritäten.

  • Rückkanal (Kommandos) per MQTT mit ACLs und Device-Scoping, kurzlebig und auditierbar.

Latenzanforderungen: Warum 100 ms den Unterschied machen

Latenz ist nicht nur Mittelwert. Auslegungspunkte:

  • Steuerung: Für geschlossene Regelkreise kalkulieren wir mit lokalen Pfaden. Selbst kleine Jitter-Spitzen können im Resonanzfall Probleme machen. Daher: Schleifenabschluss lokal, Telemetrie asynchron.

  • HMI/Assistenz: Reaktionsziele <100–200 ms vermeiden „Gummiband“-Effekte in der Bedienung und erhöhen Akzeptanz.

  • Erkennung/Alarme: Bereits eine weitere Sekunde Verzögerung kann in Fließfertigungen Ausschuss erhöhen. Ergo: Erkennung an der Kante, nur Befunde und Kontext zentral.

Fleet-Management: Tausende Edge-Geräte ohne Kontrollverlust

Skalierungsprobleme sind selten im Rechenaufwand, häufiger im „Day-2“-Betrieb. Ein belastbarer Plan umfasst:

  • Zero-Touch Provisioning
  • Geräte kommen mit einem Werkszertifikat/Seriennummer. Claiming-Prozess erzeugt Standortzertifikate, bindet Gerät an Mandant und Policy-Satz.
  • Identitäten und Autorisierung
  • Jedem Gerät einen kurzlebigen, rotierenden Satz an Credentials. Rechte sind minimal und kontextabhängig (Zeitfenster, Standort, Netzwerkprofil).
  • Rollouts und Sicherheit
  • Canary auf 1–5 % repräsentativer Knoten, automatische Metrik-Gates (CPU, Thermik, Fehlerquoten), Rollback bei Ausreißern.
  • Image- und Konfigsignaturen verpflichtend, Updates delta-basiert mit Bandbreitenbudget.
  • Inventar und Drifts
  • Tatsächlicher Zustand vs. Sollzustand kontinuierlich vergleichen, Drifts melden, aber nicht „heimlich“ korrigieren, wenn Unklarheit besteht (Audit-First).
  • Offline-Betrieb
  • Ausführbare Policies und Playbooks lokal. Bei Netzpartitionen gelten Standortregeln, Queues wachsen kontrolliert, Backpressure schützt Ressourcen.

Hybrid-Architekturen: Edge-Inferenz + zentrales Training ohne Datenausverkauf

Das überzeugendste Muster, wenn Daten das Werk nicht verlassen sollen:

  • Datenselektion am Rand
  • Nur Ereignisse/Segmente mit hohem Informationsgehalt werden markiert (Trigger, Neuigkeits-Score, Unsicherheiten, Fehlerfälle).
  • Pseudonymisierung/Aggregation
  • Entfernen von Personen-/Betriebsgeheimnissen, ggf. Rendern von Features statt Rohdaten.
  • Kuratierter Sync
  • Asynchrone Übertragung in ein souveränes Objekt-Repository (On-Prem oder europäische Cloud), Versionierung und Herkunftsnachweise.
  • Training und Validierung
  • Wiederholbare Pipelines, Testen auf domänenspezifische Metriken, Robustheit gegenüber Drift.
  • Modellfreigabe
  • Signierte Artefakte, Kompatibilitätsprüfung mit Edge-Laufzeit, A/B-Strategien, Telemetrie zu Inferenzqualität, aber ohne exzessive Datensammelei.
  • Optional: Föderiertes Lernen
  • Wenn gar keine Daten das Gelände verlassen dürfen, Modelle lokal feintunen, nur Gradienten/Updates austauschen. In der Praxis braucht das strikte Governance für Konsistenz, Zeitsynchronisation und Ausreißerbehandlung.

Drei Architekturmotive aus der Praxis

  • Defense/Kritische Infrastruktur
  • Air-Gapped- oder geschlossene Netze, eigene PKI, kein externer IdP. Updates via offline-signierten Medien oder über streng kontrollierte Jump-Hosts. Telemetrie wird zunächst lokal ausgewertet, später gebündelt über gesicherte Kanäle exportiert. Cloud nur als Begriff für interne Cluster.
  • Bahn/Fleet-Intelligence
  • Fahrzeuge als Edge-Knoten mit intermittierender Verbindung. Daten werden in Bord-TSDB gepuffert, Inferenz passiert on-vehicle. Depots sind Synchronisationspunkte (WLAN/LTE-Bursts). Zentraler Hub aggregiert, trainiert, verteilt Policies/Modelle. Befehlswege sind asynchron, mit Zeit-/Positionsregeln.
  • Fertigung/Qualitätssicherung
  • Kameras und Sensorik am Band, OPC UA für Maschinenzustände, MQTT für Eventing. Visuelle Inferenz lokal, Ergebnisse und wenige Crops/Nachaudits in die Zentrale. Änderungen an Prüfplänen sind versioniert und werden wie Software behandelt.

Häufige Fallstricke

  • Cloud-Managed Control Planes als Single Point of Failure: Fällt der externe Dienst, steht die Flotte. Lokale Alternative und Fallback-Pfade sind Pflicht.
  • Pilot bleibt Pilot: Ein PoC ohne Update-, Identitäts- und Observability-Konzept skaliert nicht. Skalierungsfriktionen tauchen erst bei 100+ Knoten auf.
  • Protokollchaos: „Jedes Team nimmt sein Lieblingsprotokoll“ endet in Gateways, die nur noch übersetzen. Ein verbindliches Profil je Kommunikationsrichtung reduziert Komplexität.
  • Kein Backpressure: Wenn Kanäle dicht sind, müssen Systeme würdevoll degradieren (Sampling, Dropping nach Prioritäten, On-Disk-Puffer), statt unkontrolliert zu stauen.
  • Black-Box-Modelle ohne Governance: Ohne Nachvollziehbarkeit, wer welches Modell wann auf welches Asset ausgerollt hat, ist Root-Cause-Analyse Glückssache.

Entscheidungs-Checkliste: Edge, Cloud oder Hybrid?