Seit 2024 ist es schwieriger geworden, eine IIoT- und KI-Plattform als Erfolg zu betrachten, nur weil Daten ankommen und ein Modell Ergebnisse liefert. Für den Produktionsbetrieb zählt, ob eine Linie nach Netztrennung, Broker-Neustart und fehlerhaftem Modell-Update kontrolliert weiterläuft. Meine Position: DevOps sollte die Wiederanlauffähigkeit höher priorisieren als eine durchgehend einheitliche Cloud-Architektur.
„Alles sofort in die Cloud“ ist seit 2024 der falsche Betriebsstandard
Der Rat, Maschinendaten zunächst möglichst vollständig an eine zentrale Plattform zu senden und Ausfälle später zu behandeln, war schon riskant; seit 2024 ist er für neue KI-Anwendungen an der Linie noch schlechter, weil eine ausgefallene Verbindung inzwischen auch lokale Vorhersagen, Freigaben oder Bedienhinweise treffen kann. Zukunftssichere Fertigungssoftware mit IIoT, KI und Plattformen beschreibt eine sinnvolle Zielrichtung, unterschätzt aus Betriebssicht aber den Unterschied zwischen zentral auswertbaren Daten und einer lokal überlebensfähigen Anwendung.
Ich würde Produktionsentscheidungen nicht von einem synchronen Cloud-Aufruf abhängig machen, weil eine WAN-Störung sonst aus einem Analyseproblem einen Stillstand machen kann. Das bedeutet nicht, jedes Modell an den Rand des Netzes zu verlegen: Eine Monatsprognose darf warten, eine Warnung für den nächsten Arbeitsschritt möglicherweise nicht. Die Trennlinie gehört deshalb in eine dokumentierte Entscheidung pro Anwendungsfall, einschließlich der Frage, wer bei fehlenden Daten die Verantwortung trägt: Steuerung, Bedienperson oder Dienst.
Für die Datenstrecke ist MQTT 5.0 mit QoS 1 oft eine vernünftige Wahl zwischen Gateway und Broker, sofern Consumer Ereignisse anhand einer stabilen Ereignis-ID deduplizieren; QoS 1 erlaubt erneute Zustellung und ist deshalb keine Zusage für genau eine Verarbeitung. MQTT-Session-Expiry, Message-Expiry und Retained Messages lösen unterschiedliche Probleme. Eine persistente Session kann Nachrichten nach einer Trennung nachliefern, eine abgelaufene Nachricht sollte dagegen keine verspätete Handlung auslösen, und ein Retained-Wert ist ohne Zeitstempel kein Beleg für einen aktuellen Maschinenzustand. Am Übergang zu OPC UA müssen deshalb Quellzeit, Qualitätsstatus und Anlagenkennung erhalten bleiben, statt alles auf einen nackten Zahlenwert zu reduzieren.
Ein praktikabler Betriebsvertrag legt für jedes Ereignis fest, wie lange es gültig ist, ob Reihenfolge nötig ist und was bei Lücken geschieht. Für eine lokale Pufferung von zunächst 6 Stunden würde ich die benötigte Speichermenge anhand der gemessenen Ereignisrate und der tatsächlichen Nachrichtengröße einstellen; die sechs Stunden sind ein zu prüfender Auslegungswert, keine allgemeine Empfehlung. Der Abnahmetest trennt die WAN-Verbindung, schreibt währenddessen weiter und prüft nach Wiederverbindung sowohl Duplikate als auch Lücken. Ein grünes Dashboard während des Tests beweist wenig, wenn es lediglich den letzten Retained-Wert anzeigt.
Der Broker gewinnt nicht durch Funktionsumfang, sondern durch den beherrschbaren Wiederanlauf
Zwischen 2024 und 2026 ist die alte Empfehlung „nimm für jedes Ereignis sofort Kafka“ weniger überzeugend geworden, weil auch kleinere Teams langlebige Streams und Consumer-Zustände mit NATS JetStream betreiben können. Apache Kafka gewinnt, wenn viele unabhängige Consumer große Ereignisbestände erneut lesen müssen und das Team Partitionen, Replikation und Kapazität bereits beherrscht. Der Preis sind mehr Betriebsentscheidungen zu Partitionierung, Aufbewahrung und Cluster-Wiederherstellung. NATS JetStream gewinnt bei einer überschaubaren Zahl von Streams nahe der Anlage, wenn einfache Bereitstellung und gezielte Acknowledgements wichtiger sind als ein umfangreiches Analyse-Ökosystem. Sein Preis sind ebenfalls Replikations- und Speicherplanung sowie eine engere Prüfung, ob spätere Replay-Anforderungen zur gewählten Stream-Konfiguration passen.
Das ist keine Behauptung, JetStream sei grundsätzlich zuverlässiger. Beide Optionen verlieren Daten, wenn Aufbewahrung, Bestätigung und Wiederherstellung nicht zum Fehlerfall passen. Ich würde die Wahl daher an zwei Proben knüpfen: Erstens wird ein Consumer mitten in der Verarbeitung beendet, um erneut zugestellte Ereignisse und die Idempotenz des Schreibziels zu prüfen. Zweitens wird ein Knoten mit seiner lokalen Platte entfernt, um zu sehen, ob die dokumentierte Replikation tatsächlich den gewünschten Datenbestand erhält. Ein Happy-Path-Durchsatztest beantwortet keine dieser Fragen.
Der alte Rat, „genau einmal“ als Ende der Diskussion zu akzeptieren, verschleiert zudem die Grenze zum Zielsystem. Selbst wenn ein Stream-Consumer seine Position transaktional verwaltet, kann ein daneben ausgeführter HTTP-Aufruf an ein MES bereits erfolgt sein, bevor die Bestätigung verloren geht. Ein Consumer braucht deshalb entweder einen idempotenten Zielendpunkt oder eine transaktional gepflegte Ereignis-ID am Schreibziel. Für PostgreSQL kann ein eindeutiger Schlüssel auf dieser ID aus einer Wiederholung einen erkennbaren Konflikt machen; ein bloßer Zeitstempel kann das nicht, weil zwei gültige Ereignisse dieselbe Zeit tragen können.
Auch der Wiederanlauf braucht eine Reihenfolge. Gateways dürfen nach einer Trennung nicht unbegrenzt gleichzeitig nachliefern, weil ein solcher Schub Live-Daten verdrängen kann. Ich würde zunächst die maximale Nachlieferungsrate drosseln, dann den Rückstand pro Anlage beobachten und erst danach zusätzliche Consumer starten. Als Abnahmeziel für die konkrete Installation könnten 99,9 % der gültigen Ereignisse innerhalb des vereinbarten Zeitfensters verfügbar sein; dieser Prozentsatz ist ein vertraglich festzulegendes Ziel und ohne definiertes Zeitfenster bedeutungslos.
Eine grüne Pipeline kann seit zwei Jahren leichter eine tote Linie verbergen
Mit mehr Gateways, Streams und Modellendpunkten ist eine durchgehend grüne Infrastrukturansicht seit 2024 ein schwächeres Signal für funktionierende Fertigungssoftware geworden, weil jeder Dienst gesund sein kann, während gültige Ereignisse einer einzelnen Linie ausbleiben. Zukunftssichere Fertigungssoftware: IIoT, KI und Plattformen ist als Architekturziel brauchbar; für Bereitschaftsdienste fehlt darin jedoch die entscheidende Einheit der Beobachtung: die einzelne Datenkette von der Quelle bis zur wirksamen Entscheidung.
OpenTelemetry-Traces helfen bei einem einzelnen durchlaufenden Vorgang, sofern Gateway, Consumer und Inferenzdienst dieselbe Trace-ID weiterreichen. Für stillstehende Quellen sind sie allein ungeeignet, weil ohne neues Ereignis auch kein neuer Trace entsteht. Prometheus sollte deshalb zusätzlich den Zeitpunkt des letzten gültigen Ereignisses je Standort und Linie sehen. Die folgende Regel läuft als Prometheus-Rule-Datei, sobald der Exporter die Metrik mit den genannten Labels liefert:
groups:
- name: iiot-freshness
rules:
- alert: IIoTTelemetryStale
expr: time() - max by (site, line) (iiot_last_valid_event_timestamp_seconds) > 120
for: 5m
labels:
severity: page
annotations:
summary: "Keine gültigen Events für {{ $labels.site }}/{{ $labels.line }}"
Die 120 Sekunden sind hier ein an den Takt der Linie anzupassender Startwert; die 5 Minuten sind eine bewusst gewählte Entprellzeit gegen kurze Unterbrechungen. Die Regel erkennt allerdings keine Linie, deren Metrik vollständig verschwindet, weil Prometheus aus einer fehlenden Zeitreihe keinen Wahrheitswert für diesen Vergleich bildet. Eine zweite Prüfung muss deshalb erwartete Linien aus einem Inventar mit tatsächlich beobachteten Linien abgleichen. Außerdem muss der Exporter den Zeitstempel beim validierten Empfang setzen oder eine kontrollierte Uhrabweichung berücksichtigen, weil eine falsch gehende Gateway-Uhr sonst falsche Frische signalisiert.
Für den Bereitschaftsdienst würde ich vier Sichten nebeneinanderstellen: Zeit seit dem letzten gültigen Ereignis, Alter des ältesten noch nicht verarbeiteten Ereignisses, Anteil ungültiger Qualitätskennzeichen aus OPC UA und Anteil der Inferenzen, die rechtzeitig ein Ergebnis liefern. Das ist keine beliebige Metrikliste: Jede Sicht deckt einen anderen blinden Fleck ab, vom stillen Sensor bis zum langsamen Modell. Wenn ein Lasttest beispielsweise einen p99-Inferenzwert von 280 Millisekunden misst, ist das ein Messwert dieses Tests und noch keine Aussage über Schichtwechsel, Nachlieferung oder einen warm startenden Ersatzknoten. Ein Alarm darf erst nach solchen Fehlerproben als belastbar gelten.
Seit 2024 gehört das Modell-Update in denselben Wiederherstellungsplan wie die Software
Die Empfehlung „Modell austauschen, Qualität beobachten, bei Bedarf zurückrollen“ ist für Produktion zu vage geworden, weil sich mit einem Modell auch Vorverarbeitung, Laufzeitbibliotheken und die Bedeutung von Ausgabewerten ändern können. Ein Rollback auf frühere Gewichte hilft nicht, wenn ein neues Gateway die Eingabefelder bereits anders codiert. DevOps sollte Modell, Schema und ausführendes Image daher als gemeinsam getestete Freigabeeinheit behandeln. Eine Freigabe nennt mindestens Image-Digest, Modell-Hash, Eingabeschema, Schwellenwerte und den Datensatz, mit dem der lokale Funktionstest reproduziert werden kann.
Das ist auch eine Reaktion auf konkrete Änderungen der vergangenen zwei Jahre. Der EU Cyber Resilience Act trat 2024 in Kraft; seine Meldepflichten für aktiv ausgenutzte Schwachstellen gelten seit September 2026, soweit ein betroffenes Produkt in seinen Anwendungsbereich fällt. Deshalb reicht eine lose Paketliste für Hersteller solcher Produkte nicht als betriebliche Vorbereitung: Bei einer Schwachstelle muss auffindbar sein, welche ausgelieferten Gateway-Versionen und Images betroffen sind. CycloneDX 1.6 oder SPDX 3.0 liefern dafür standardisierte SBOM-Formate, ersetzen aber nicht die Zuordnung zu tatsächlich installierten Geräten. Der EU AI Act schafft daneben gestufte Pflichten, deren Anwendbarkeit von System und Rolle abhängt; ich würde daraus keine pauschale Einstufung jeder Wartungsprognose als Hochrisiko-KI ableiten, weil diese Einstufung den konkreten Einsatzzweck benötigt.
Im Release-Prozess sollten Sigstore Cosign für signierte Container-Artefakte, ein unveränderlicher Image-Digest und ein getesteter Rückweg zusammenkommen. Wer Kubernetes am Standort verwendet, kann ein neues Deployment schrittweise ausrollen; wer ohne Kubernetes auskommt, braucht denselben Nachweis mit seinem tatsächlichen Update-Mechanismus. Entscheidend ist nicht der Orchestrator, sondern dass ein Ersatzgerät nach einem Ausfall exakt die freigegebene Kombination erhält. Die von NVIDIA veröffentlichten 67 TOPS für das Jetson Orin Nano Super sind beispielsweise eine Herstellerangabe zur Rechenleistung, keine Garantie für die Latenz eines konkreten Modells mit Vorverarbeitung und paralleler Datenerfassung.
Ich würde einen Canary nicht allein nach allgemeiner Modellgenauigkeit freigeben, weil seltene, aber betriebsrelevante Zustände im Durchschnitt untergehen. Er sollte zunächst parallel ohne Wirkung auf die Linie laufen und Ergebnisse nach Anlagenzustand, Softwareversion und Datenqualität aufschlüsseln. Danach folgt ein kontrollierter Einsatz mit eindeutigem Abbruchkriterium und einem Rollback-Test unter Last. Wenn der Rückweg nur im Wartungsfenster funktioniert, ist er für einen Fehler mitten in der Schicht kein verlässlicher Rückweg.
Der nächste Schritt ist ein unterbrochener Datenweg, kein neues Architekturdiagramm
Trenne als Erstes in einer Testumgebung die Verbindung zwischen einem Gateway und seinem Broker. Halte fest, welche Entscheidung lokal weiterläuft, welches Ereignis nach der Rückkehr doppelt erscheint und wann die Frischewarnung auslöst. Wenn diese drei Antworten fehlen, beginne mit dem Betriebsvertrag für genau diese Linie – nicht mit der Auswahl der nächsten Plattformkomponente.
