10) Migrationspfad: Von 50 auf 5000 Geräte

  • Phase 1 (Pilot, 50 Geräte): Lokaler MQTT-Broker, ein Edge-Inferenzdienst, On-Prem-DB für Ergebnisse, manuelle Updates mit signierten Artefakten.

  • Phase 2 (200–500 Geräte): Einführung von k3s für Orchestrierung, zentrales on-prem Kafka für Streams, automatisierte OTA mit Canary, Observability-Stack, PKI ausgerollt.

  • Phase 3 (1000+ Geräte, mehrere Standorte): Standortweise Kafka-Cluster, Replikation aggregierter Statistiken an eine zentrale europäische Analyseinstanz (optional), aktives Retraining on-prem, strenge SLOs und Kapazitätsplanung, Remote Attestation obligatorisch.

Meinung und Standpunkt
“Cloud, wenn möglich” ist ein guter Default für Webanwendungen, aber ein gefährlicher Reflex im IIoT. In sicherheitskritischen, latenzsensitiven und regulierten Umfeldern gilt: Edge-first, Cloud als Add-on – nie als Abhängigkeit. Souveränität ist kein “Nice-to-have”, sondern die Voraussetzung, damit KI Ergebnisse produziert, die auditierbar, zuverlässig und bezahlbar sind. Oder kurz: Souveränität ermöglicht Intelligenz.

Praktische Checkliste für Ihr nächstes Projekt

  • Latenzbudget dokumentiert? Ja/Nein.

  • Welche Komponenten müssen bei WAN-Ausfall weiterlaufen? Liste mit Fallback-Strategien vorhanden?

  • Schlüsselverwaltung: Wo leben die Root-Keys? Wer rotiert sie? Wie attestieren Geräte ihren Zustand?

  • Protokollarchitektur: Welche Daten laufen über MQTT, welche über Kafka, wo ist OPC UA die Quelle der Wahrheit?

  • OTA: A/B, Rollback, Canary – implementiert und getestet?

  • Observability: SLOs definiert, Metriken/Logs lokal aggregiert, Alarmierung robust?

  • Datenmodell: Einheitliche Schemas, Zeitbasis, Idempotenz?

  • Governance: Auditierbarkeit von ML/LLM-Entscheidungen, Policies als Code?

FAQ – 5 technische Fragen aus der Praxis

1) Wie entscheide ich zwischen MQTT, OPC UA und Kafka?

  • Wenn Sie leichtgewichtige Telemetrie und Befehle brauchen, die von vielen Geräten publiziert/abonniert werden: MQTT.

  • Wenn Sie Maschinenvariablen mit Semantik, Typen und Methoden einbinden: OPC UA.

  • Wenn Sie persistente, skalierbare Streams für Analytik/ML mit Re-Processing benötigen: Kafka.

In der Regel kombinieren Sie alle drei: OPC UA für den Anschluss der Anlage, MQTT für Steuer-/Statuspfade, Kafka als Analytik-Backbone.

2) Wie organisiere ich OTA-Updates in einem air-gapped Netzwerk?

  • Verwenden Sie signierte, versionierte Artefakte (Container/Images), eine lokale Update-Authority (interne PKI) und A/B-Partitionen mit Health-Check.

  • Verteilen Sie Updates über einen physischen Transferkanal (Wechseldatenträger) in ein “Staging-Repo” vor Ort, von dem aus Geräte deterministisch ziehen.

  • Protokollieren Sie Installationsnachweise kryptografisch und erlauben Sie nur attestierte Gerätezustände für Update-Freigaben.

3) Wie baue ich ein Latenzbudget, das in der Realität hält?

  • Zerlegen Sie die Pipeline in Messpunkte: Sensor, Preprocessing, Inferenz, Postprocessing, Aktor, Transport.

  • Messen Sie p50/p95/p99 unter Produktionslast, nicht nur im Labor. Führen Sie synthetische Last und Störereignisse (Jitter, Paketverlust) ein.

  • Definieren Sie Fallbacks (Degradation), wenn Budgetgrenzen gerissen werden, und publizieren Sie Zustände als maschinenlesbare Signale (z. B. MQTT-Topics), damit übergeordnete Systeme reagieren können.

4) Wie setze ich Remote Attestation ohne Internetzugang um?

  • Nutzen Sie eine interne Attestations-Infrastruktur: Geräte signieren ihren Startzustand (gemessene Hashes von Bootloader, OS, Applikation) mit TPM/SE-gebundenen Schlüsseln.

  • Ein lokaler Verifizierer validiert die Messwerte gegen freigegebene Referenzen (Allowlist) und vergibt erst dann Zugangstoken/Keys.

  • Koppeln Sie kritische Operationen (Schlüsselvergabe, OTA) an einen “Attested-Only”-Pfad.

5) Was ist die Minimalarchitektur für 50 Geräte – und skaliert sie später?

  • Minimal: Edge-App je Gerät (Container), lokaler MQTT-Broker, kleine on-prem DB (z. B. Timeseries) für Ergebnisse, Skript-basierte signierte Updates.

  • Für Skalierung: Fügen Sie k3s für Orchestrierung, Kafka für Streams, PKI für mTLS, OTA mit Canary und Observability-Stack hinzu. Wenn Sie die Daten- und Protokollgrenzen früh sauber ziehen, können Sie horizontal wachsen, ohne umzuarchitektieren.

Schluss
Edge vs. Cloud ist im IIoT keine Geschmacksfrage, sondern eine Konsequenz aus Latenz, Souveränität und Betriebssicherheit. Eine robuste, souveräne Edge-Architektur mit klaren Daten- und Kontrollpfaden ist die Grundlage. Erst darauf lohnt sich der gezielte Einsatz zentraler Ressourcen – unter Ihrer Schlüssel- und Prozesshoheit. Wenn Sie so planen, laufen Ihre Systeme auch dann, wenn die Leitung wackelt – und Sie bestehen jeden Audit.