• Defense-nahe Umgebung: Kein Internetzugang im Zielnetz. Edge-Inferenz ist Pflicht, Core ist air-gapped. Updates kommen per geprüften, signierten Transportmedien, OTA nur innerhalb abgeschotteter Zonen. Ergebnis: Stabiler Betrieb trotz Null-WAN, deterministische Latenzen, kontrollierte Datenabflüsse via Gate.
  • Railway-Fleet-Intelligence: Fahrzeuge mit intermittenter Konnektivität. Edge sammelt Telemetrie und führt Diagnostik lokal aus; bei Netz kommt synchronisierte Übertragung in priorisierten Batches. Flottenupdates sind ringbasiert und zwingen nie einen Fahrzeugstillstand. Ergebnis: Predictive-KPIs verfügbar, ohne Betriebsrisiko durch Netzabhängigkeit.
  • Fertigung, visuelle Qualitätskontrolle: 60–90 ms Latenzbudget, mehrere Kameras pro Linie. Inferenz auf dedizierten Edge-IPCs mit quantisierten Modellen, PTP-Synchronisierung und hart priorisiertem Netzwerk. Bei Modellwechsel Shadow-Phase, dann ringweises Ausrollen. Ergebnis: Fehlklassifikationen sinken, Linie bleibt deterministisch.

9) Erste Schritte für Entscheider

  • Anforderungen formalisieren: Latenzbudgets, Ausfallmodi, Datenklassifikation, Verantwortungsrollen. Ohne das wird jede Architektur unscharf.
  • Minimalviable Architektur statt MVP-Featureliste: Ein kleiner, aber sauber durcharchitektierter Pfad von Sensor bis Entscheidung, mit allen Souveränitätsgates und Rollback-Pfaden.
  • Protokoll- und Schemaentscheidungen früh treffen: Entscheidend für die Skalierbarkeit. Spätere Migrationen sind teuer.
  • Pilot mit echter Offline-Phase: Erzwingen Sie im Pilot einen mehrtägigen WAN-Ausfall. Nur so enttarnt man versteckte Cloud-Kopplungen.
  • Observability von Tag 1: Edge- und Core-Telemetrie, Konfigurationsdiffs, Zertifikatslaufzeiten, Rolloutmetriken. Ohne Sichtbarkeit keine Stabilität.

Fazit

Souveränität ist kein Widerspruch zur Leistungsfähigkeit – sie ist deren Voraussetzung. Wer Edge, On-Prem und Cloud nicht als “entweder-oder”, sondern als bewusst entkoppelte Schichten mit harten Verträgen denkt, erhält Systeme, die deterministisch handeln, auditierbar bleiben und über Jahre kosteneffizient skalieren. Der Weg dorthin führt nicht über Schlagwörter, sondern über Architekturdisziplin: klare Zonen, robuste Protokollbrücken, deklarative Flottensteuerung und MLOps, die Edge als Erstbürger behandelt.

FAQ – technisch konkret

1) OPC UA oder MQTT für die Linie?

  • In der Zelle/OT ist OPC UA für SPS-Interaktion und semantisch reichhaltige Prozessdaten meist die bessere Wahl. Für lose gekoppelte Edge-Telemetrie und Kommandos ist MQTT leichter, skalierbarer und besser über WAN/instabile Links zu betreiben. In der Praxis: OPC UA nahe an der Maschine, MQTT als Edge-Pub/Sub. Eine Brücke übersetzt relevante Knoten und Events in stabile, versionierte MQTT-Payloads.

2) Wie orchestriert man Realtime-Inferenz-Container am Edge?

  • Realtime-Workloads von nicht-RT-Services trennen. CPU- und IO-Isolation (cpuset, realtime priorities), vorgewärmte Modelldienste ohne Kaltstarts, Speichervorreservierung. Eine schlanke, deterministische Supervisor-Schicht ist oft stabiler als ein “voller” Orchestrator. Wenn Container-Orchestrierung genutzt wird, müssen Scheduling- und QoS-Klassen für RT sauber konfiguriert und getestet werden.

3) Exactly-once über MQTT und Kafka – geht das?

  • Über Zonen hinweg ist “exactly once” teuer und fragil. Besser: at-least-once mit Event-IDs, idempotenten Konsumenten und zustandsbehafteten Prozessen, die Duplikate tolerieren. Innerhalb von Kafka lässt sich eine exactly-once-ähnliche Semantik für Producer/Processor erreichen; zum Edge hin gewinnt Robustheit vor formaler Exaktheit.

4) OTA-Updates bei intermittenter Konnektivität?

  • Artefakte in Chunks mit Prüfsummen, A/B-Partitionierung, signierte Pakete. Update-Planung ringbasiert und lastgesteuert. Ein lokaler Edge-Cache reduziert erneut zu ladende Volumina. Nach Rollout: Health-Probe, Telemetrieprüfung, automatisches Rollback bei Abweichungen. Updates dürfen nie einen Produktionsstopp erzwingen.

5) Modell-Drift erkennen, ohne Rohdaten zu exportieren?

  • Auf dem Edge Geräte berechnen verteilte Statistiken (Feature-Histogramme, Konfidenzverteilungen, Fehlertypen), senden nur aggregierte, anonymisierte Kennzahlen. Im Core werden sie gegen Referenzverteilungen geprüft; bei Abweichung wird gezielt ein kleiner, genehmigter Rohdatenauszug für Re-Labeling angefordert. So bleibt der Default souverän, Trainingsqualität aber steuerbar.

Über uns

Wir bauen solche Systeme, weil in Defense, Fertigung, Bahn und weiteren Industrien Datensouveränität nicht verhandelbar ist. Unser Fokus liegt auf sauberer Requirements-Analyse, technischer Verantwortung über den gesamten Lebenszyklus und Software, die im Feld unter realen Bedingungen stabil bleibt – on-premise, DSGVO-konform und ohne externe Abhängigkeiten, die man im Ernstfall nicht kontrolliert. Souveränität ermöglicht Intelligenz. Genau in dieser Reihenfolge.