Seit 2024 hat sich für viele Fertigungsanlagen weniger am Sensor als am Weg seiner Daten geändert: Edge-Gateways puffern, Plattformen verarbeiten und KI-Dienste bewerten Ereignisse. Damit ist ein grüner Dienst kein Beleg mehr für einen sicheren Wiederanlauf. Meine Position: DevOps sollte zuerst die Semantik nach einer Unterbrechung absichern und erst danach weitere Verfügbarkeit durch Automatisierung versprechen.
Seit 2024 ist Wiederanlauf ein Datenproblem, kein Neustartproblem
Ein älterer Betriebsratgeber lautete: Verbindung prüfen, Dienst neu starten, Eingangsdaten kontrollieren. Das war brauchbar, solange eine Anwendung nach einer Störung überwiegend neue Werte las. In einer Architektur mit Edge-Puffer und Plattform kann sie nach dem Neustart zugleich alte und aktuelle Ereignisse empfangen. Ein erfolgreiches Kubernetes-Rollout sagt darüber nichts aus, weil Readiness-Probes nur die konfigurierte Erreichbarkeit prüfen und nicht die fachliche Reihenfolge der Daten.
Der Beitrag Warum deine OT-Runbooks seit 2024 Ausfaelle riskieren trifft den wunden Punkt der Betriebsdokumentation. Ich würde daraus allerdings nicht zuerst längere Anweisungen ableiten: Ein Runbook kann einen falsch implementierten Wiederanlauf nicht zuverlässig reparieren, weil ein Operator bei einer kurzen Netzunterbrechung nicht jedes gepufferte Ereignis einzeln beurteilen kann.
Die Veränderung der letzten zwei Jahre ist nicht, dass MQTT oder OPC UA neu wären. Verändert hat sich in betroffenen Installationen die Zahl der Zustandsgrenzen: Steuerung, Gateway, Broker, Stream-Verarbeitung und Anwendung können unabhängig ausfallen und wiederkehren. Wer 2024 noch einen Gateway-Neustart als lokalen Vorgang behandelte, muss 2026 prüfen, welche Abnehmer danach historische Nachrichten erneut sehen. Das gilt besonders, wenn ein zuvor isolierter Datenstrom inzwischen auch Qualitätsentscheidungen oder einen KI-Dienst versorgt.
Schreibe deshalb für jeden produktiven Datenpfad drei Aussagen auf: Wer vergibt eine dauerhafte Ereigniskennung? Wer entscheidet, ob ein Wert zu spät ist? Wer darf nach einem Verbindungsabbruch wieder Aktionen auslösen? Fehlt eine Antwort, ist „Dienst läuft“ kein geeignetes Abschlusskriterium für einen Incident. Die Zuordnung gehört in den Code und in einen ausführbaren Test; im Runbook steht anschließend, woran der Bereitschaftsdienst das Ergebnis erkennt.
Auch die rechtliche Uhr ist weitergelaufen: Der EU Cyber Resilience Act trat im Dezember 2024 in Kraft; seine Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten ab September 2026. Das macht aus einem OT-Alarm nicht automatisch einen meldepflichtigen Vorfall. Es macht aber eine unbelegte Aussage wie „Gateway war kurz weg, keine Auswirkung“ riskant, weil ohne Ereignisprotokoll weder Auswirkungen noch zeitlicher Ablauf verlässlich feststellbar sind.
Ein lokaler Puffer gewinnt gegen blindes Vertrauen in die Cloud
Ich würde Messereignisse nicht ausschließlich direkt an einen entfernten Dienst senden, wenn die Verbindung zwischen Werk und Plattform ausfallen kann. Der Grund ist schlicht: Ein Retry im Client schützt nicht vor Prozessabbruch oder Stromverlust, während eine dauerhaft gespeicherte Warteschlange den noch nicht bestätigten Bestand erhält. Sie kostet Speicher, Schreibvorgänge und Pflege; diese Kosten sind sichtbar und lassen sich begrenzen. Der Verlust unbemerkter Ereignisse ist schwerer zu begrenzen.
Für einen Beispielbetrieb sei eine Rate von 200 Ereignissen pro Sekunde angenommen. Bei einer ebenfalls angenommenen Unterbrechung von 15 Minuten entstehen rechnerisch 180.000 Ereignisse. Diese Zahlen sind ein Kapazitätsszenario, keine Messung einer Anlage. Vor der Auswahl eines Puffers müssen zusätzlich Nachrichtengröße, Indizes, Schreibverstärkung und gewünschte Aufbewahrungsdauer bekannt sein. Ein Gateway, dessen Datenträger bei voller Queue nur noch Lesefehler liefert, hat das Verfügbarkeitsproblem lediglich verschoben.
SQLite mit PRAGMA journal_mode=WAL kann für einen einzelnen Gateway-Prozess eine überschaubare lokale Queue tragen, weil Transaktionen und ein eindeutiger Schlüssel ohne zusätzlichen Server verfügbar sind. Für mehrere konkurrierende Produzenten oder lange Offline-Zeiten kann ein betriebener Broker wie Eclipse Mosquitto geeigneter sein; dort müssen unter anderem persistence true, Speichergrenzen und das Verhalten bei vollem Datenträger geprüft werden. Weder SQLite noch ein Broker erzeugen von selbst fachliche Eindeutigkeit.
Das folgende Python-3-Beispiel läuft ohne Zusatzpakete. Es zeigt nur die notwendige Dublettenentscheidung anhand von Anlage, Startkennung und Sequenznummer; für Produktion muss die Datenbankdatei dauerhaft gespeichert und die Startkennung tatsächlich eindeutig erzeugt werden.
import sqlite3
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE events(asset TEXT, boot TEXT, seq INTEGER, "
"PRIMARY KEY(asset, boot, seq))")
batch = [("presse-07", "start-42", 1),
("presse-07", "start-42", 1),
("presse-07", "start-42", 2)]
for event in batch:
before = db.total_changes
db.execute("INSERT OR IGNORE INTO events VALUES (?, ?, ?)", event)
if db.total_changes > before:
print("neu:", event)
Die zweite Nachricht wird verworfen, weil ihr Schlüssel schon vorhanden ist. Daraus folgt ausdrücklich kein „Exactly once“ über Gateway, Broker und Datenbank hinweg: Zwischen Speichern und Bestätigen kann ein Prozess abstürzen. Das belastbare Ziel ist eine erneute Zustellung mit idempotenter Verarbeitung. Ich würde dafür keine Gerätezeit als alleinigen Schlüssel verwenden, weil eine korrigierte Uhr mehrere verschiedene Messungen gleich aussehen lassen kann.
MQTT und OPC UA gewinnen an unterschiedlichen Grenzen
Eine ausdrückliche Wahl ist hilfreicher als „wir standardisieren alles auf ein Protokoll“. OPC UA gewinnt an der Grenze zur Anlage, wenn ein Client typisierte Knoten, Metadaten und einen definierten Zugriff auf den aktuellen Zustand braucht. Sein Preis sind die Pflege von Zertifikaten, Namensräumen und Sitzungen sowie die Prüfung, was nach einer erneuten Subscription tatsächlich nachgeliefert wird. MQTT 5.0 gewinnt zwischen Gateway und Plattform, wenn viele Abnehmer entkoppelt Nachrichten beziehen sollen. Sein Preis ist ein zusätzliches, sorgfältig festzulegendes Nachrichtenmodell.
MQTTs QoS 1 bestätigt eine Zustellung im Protokoll, nicht die einmalige Ausführung einer fachlichen Aktion. Die in MQTT 5.0 spezifizierten Eigenschaften Session Expiry Interval und Message Expiry Interval verdienen deshalb getrennte Entscheidungen: Eine Sitzung darf erhalten bleiben, während ein veralteter Sollwert gerade nicht mehr zugestellt werden soll. Die Werte sind zu konfigurieren; ein pauschaler Standardwert für beide wäre falsch, weil Messhistorie und Steuerbefehl unterschiedlich altern.
Eclipse Sparkplug B 3.0 kann über MQTT eine gemeinsame Struktur für Gerätezustand und Geburtsnachrichten liefern. Es nimmt dem Team aber nicht die Entscheidung ab, ob ein nach einem Reconnect empfangener Messwert historische Analyse ergänzt oder eine aktuelle Entscheidung auslösen darf. Eine Plattform, die beides im selben Consumer erledigt, macht aus einer harmlosen Nachlieferung möglicherweise eine verspätete Aktion. Trenne die beiden Pfade, auch wenn sie denselben Broker nutzen.
Der Text Zukunftssichere Fertigungssoftware mit IIoT, KI und Plattformen setzt zu Recht auf anschlussfähige Systeme. „Zukunftssicher“ wäre für mich trotzdem kein Argument für ein einheitliches Plattformformat bis zur Steuerung: Die Übersetzung gehört an eine benannte Grenze, weil sich dort Herkunft, Sequenz und Gültigkeitsdauer prüfen lassen, ohne die Semantik des Anlagenprotokolls in jedem Cloud-Consumer nachzubauen.
Für die Fehlersuche reichen Broker-Metriken allein nicht. Erfasse getrennt die Zahl gespeicherter, bestätigter, verworfener und wegen Ablauf nicht mehr ausgeführter Ereignisse. Prometheus kann die Zähler sammeln und Grafana sichtbar machen; eine Ereigniskennung im Log erlaubt die Prüfung eines konkreten Falls. Ein frei einstellbarer erster Alarmwert könnte 90 Sekunden für das Alter des ältesten noch nicht bestätigten Ereignisses sein. Dieser Wert ist keine Norm: Er muss gegen die zulässige Verzögerung des jeweiligen Prozesses getestet werden.
Ein erfolgreiches Deployment beweist noch keine sichere Datenrückkehr
Der veraltete Rat „nach dem Rollout auf Pod-Status und Fehlerrate schauen“ übersieht den gefährlichsten Zeitpunkt: die Rückkehr einer zuvor getrennten Verbindung. Kubernetes kann einen Pod per readinessProbe erst dann ansprechen lassen, wenn sein HTTP-Endpunkt antwortet. Ob der Consumer einen Rückstau korrekt abarbeitet, zeigt dieser Endpunkt nur, wenn die Anwendung diese Bedingung ausdrücklich abbildet. Auch ein Kubernetes PodDisruptionBudget schützt Verfügbarkeit während geplanter Unterbrechungen, nicht die Reihenfolge wieder eintreffender OT-Ereignisse.
Ich würde vor einem Produktions-Rollout mit tc netem eine Netztrennung zwischen Gateway und Broker simulieren und den Gateway-Prozess während des Rückstaus zusätzlich beenden. Der Test muss prüfen, dass nach Wiederverbindung kein Ereignis unbemerkt verloren geht, keine Dublette eine zweite fachliche Aktion bewirkt und abgelaufene Befehle nicht nachträglich ausgeführt werden. Ein reiner Lasttest ohne Unterbrechung beantwortet diese Fragen nicht, weil gerade die Übergänge zwischen den Zuständen das Risiko erzeugen.
Für eine überprüfbare Freigabe würde ich in OpenTelemetry-Spans die Ereigniskennung und den Verarbeitungsschritt korrelieren, jedoch keine sensiblen Rohwerte als unbegrenzte Attribute übernehmen. Als Messgröße eignet sich das 99,9. Perzentil der Zeit vom Empfang am Gateway bis zur abgeschlossenen Verarbeitung; es ist eine zu erhebende Betriebsmetrik, kein hier behaupteter Messwert. Ergänze sie um Queue-Alter und Ablehnungszähler, weil eine gute Latenz der bereits verarbeiteten Ereignisse einen liegen gebliebenen Restbestand verdecken kann.
Für KI-Ausgaben gilt eine strengere Grenze. Ein Modell kann nach einem Replay formal gültige, aber zeitlich falsche Eingaben sehen; deshalb sollte ein neuer Modellstand zunächst im Shadow Mode auf denselben Daten mitlaufen, ohne Aktoren anzusteuern. Vergleiche seine Ausgaben mit freigegebenen Entscheidungen und zeichne Modellversion, Eingangszeit und Verwerfungsgrund auf. Ich würde eine automatische Rückschaltung auf das alte Modell nicht als alleinige Sicherheitsmaßnahme akzeptieren, weil auch das alte Modell mit verspäteten Daten falsch handeln kann.
Beginne beim nächsten Dienst mit einem einzigen Reconnect-Test: Trenne die Verbindung, erzeuge währenddessen Ereignisse, starte den Gateway neu und prüfe danach jede Ereigniskennung bis zum Consumer. Halte fest, welche Nachricht nachgeliefert, verworfen oder für eine Aktion gesperrt wurde. Erst wenn dieses Ergebnis reproduzierbar ist, lohnt es sich, Readiness-Probes, Alarme und Runbook auf genau diese Zustände auszurichten.
