Verfügbarkeit eines CPS überwachen und Ausfälle kontrolliert behandeln

Wenn “online” nicht mehr reicht

Die Elbwerk Behälterlogistik GmbH bewegt Transportboxen mit einem fahrerlosen Shuttle zwischen zwei Produktionsbereichen. Lichtgitter sichern die Übergabepunkte. Eine lokale Steuerung gibt jeden Fahrbefehl frei, das Shuttle meldet die Ausführung zurück und ein Edge-Gateway überträgt Betriebszustände an das Leitsystem.

Am Montag erscheinen für drei Minuten keine neuen Positionsmeldungen im Leitsystem. Der Netzwerkstatus des Gateways bleibt grün. Das Shuttle fährt in dieser Zeit langsamer weiter, weil seine lokale Sicherheitssteuerung auf den eingeschränkten Betrieb umschaltet. Erst als sich mehrere Aufträge stauen, bemerkt die Leitstelle die Störung.

Das Problem liegt nicht nur in einem fehlenden Alarm. Das Team hat noch nicht festgelegt, welche Funktion verfügbar sein soll, welche Beobachtung ihren Zustand belegt und wie schnell das System auf einen Verlust reagieren muss.

Die Grundidee dieser Lektion lautet: Verfügbarkeit wird erst steuerbar, wenn du eine betriebliche Funktion, ihren messbaren Zustand, eine Zeitgrenze und eine vereinbarte Reaktion miteinander verbindest. Ein erreichbares Gerät allein belegt nicht, dass der Transportprozess funktioniert.

Du solltest bereits wissen, wie Sensoren, Aktoren, Steuerung, Gateway und Anwendung in einem cyber-physischen System zusammenarbeiten. Die Plausibilität einzelner Messwerte behandelt eine eigene Lektion. Eine allgemeine Netzwerkdiagnose grenzt Übertragungsfehler ein. Die OT-Härtung schützt vor Angriffen und unerlaubten Änderungen. Hier entwirfst du die laufende Überwachung des vereinbarten Betriebszustands.

Formuliere zuerst die verfügbare Funktion

“Das Gateway ist verfügbar” bleibt mehrdeutig. Es könnte bedeuten, dass das Gerät Strom hat, eine IP-Adresse beantwortet oder gültige Prozessdaten weitergibt. Für Elbwerk lautet die betriebliche Funktion genauer:

Das System nimmt einen freigegebenen Transportauftrag an, bestätigt ihn innerhalb von 2 Sekunden und meldet spätestens 8 Sekunden nach einer Übergabe einen fachlich vollständigen Abschluss an das Leitsystem.

Diese Formulierung nennt drei prüfbare Punkte: Auftrag annehmen, Annahme bestätigen und Abschluss melden. Für jeden Punkt braucht die Überwachung einen Zeitstempel und eine eindeutige Auftragskennung.

Verfügbarkeit beschreibt hier den Anteil der vereinbarten Betriebszeit, in dem diese Funktion nutzbar ist. Für ein festgelegtes Beobachtungsfenster kann das Team rechnen:

Verfügbarkeit = verfügbare Betriebszeit / vereinbarte Betriebszeit × 100 %

In einer achtstündigen Schicht sind 480 Minuten vereinbart. Eine ungeplante Störung macht die Transportfunktion 12 Minuten lang unbrauchbar.

(480 min - 12 min) / 480 min × 100 % = 97,5 %

Das Ergebnis gilt nur für dieses Beobachtungsfenster und diese Funktionsdefinition. Es sagt nicht, wie schnell Aufträge im restlichen Zeitraum liefen. Ein System kann verfügbar, aber deutlich langsamer sein. Umgekehrt kann ein geplanter Wartungszeitraum je nach Vereinbarung aus dem Nenner ausgeschlossen sein. Diese Regel muss vor der Auswertung feststehen.

Kombiniere technische und fachliche Lebenszeichen

Ein Heartbeat ist ein regelmäßig gesendetes Lebenszeichen. Er zeigt, dass ein Sender und mindestens ein Teil des Übertragungswegs innerhalb einer Frist reagiert haben. Bei MQTT erfüllt die Keep-Alive-Funktion eine ähnliche Aufgabe für die Verbindung: Bleibt der erwartete Datenverkehr aus, sendet der Client eine Prüfnachricht. Der Server behandelt die Verbindung nach der im Standard beschriebenen Frist als ausgefallen.

Ein Heartbeat zeigt jedoch nicht automatisch, dass der Prozess funktioniert. Ein festgefahrener Anwendungsteil kann noch Lebenszeichen senden. Elbwerk überwacht deshalb drei Ebenen:

Ein Watchdog überwacht lokal, ob ein Programm oder Gerät innerhalb einer Frist ein erwartetes Zeichen liefert. Läuft die Frist ab, löst er eine vorab festgelegte Reaktion aus. Das kann ein Wechsel in einen sicheren Zustand, ein kontrollierter Neustart oder nur eine Störungsmeldung sein. Welche Reaktion passt, hängt vom Prozess ab. Ein automatischer Neustart ist kein allgemeines Sicherheitskonzept.

Für das Shuttle gelten folgende Regeln:

• Gateway-Heartbeat alle 5 Sekunden; nach 15 Sekunden ohne Heartbeat gilt die Verbindung als ausgefallen.
• Auftragsbestätigung spätestens 2 Sekunden nach Annahme.
• Abschlussmeldung spätestens 8 Sekunden nach der Übergabe.
• Lokaler Watchdog der Fahrsteuerung: Reaktion nach 500 Millisekunden ohne gültigen Programmtakt; Wechsel in den vom Hersteller vorgesehenen sicheren Zustand.

Die vier Fristen überwachen unterschiedliche Dinge. Der lokale Watchdog schützt eine zeitkritische Steuerungsfunktion. Der Gateway-Heartbeat erkennt einen längeren Kommunikationsausfall. Die beiden fachlichen Fristen zeigen, ob der Auftrag tatsächlich durch die erwarteten Prozessschritte läuft.

Leite Timeout und Alarmgrenze aus dem Prozess ab

Ein Timeout ist die Frist, nach der das System eine erwartete Antwort als ausgeblieben behandelt. Eine Alarmgrenze legt fest, ab welchem Messwert oder Zustand eine Meldung entsteht. Beide Werte brauchen einen fachlichen Grund.

Für die Abschlussmeldung beobachtet Elbwerk im freigegebenen Normalbetrieb Werte zwischen 3 und 6 Sekunden. Die betriebliche Vorgabe erlaubt höchstens 8 Sekunden. Daraus folgt kein allgemeiner Branchenwert, sondern eine Regel für dieses Shuttle:

• Bis einschließlich 6 Sekunden: Normalbetrieb.
• Über 6 Sekunden: Vorwarnbereich für die Trendanzeige.
• Über 8 Sekunden bei drei aufeinanderfolgenden Aufträgen: Zustand DEGRADIERT und Alarm.
• Keine Abschlussmeldung nach 15 Sekunden: Zustand AUSFALL für den Auftrag und kontrollierter Stopp weiterer Übergaben.

Die Bedingung über drei Aufträge verhindert, dass ein einzelner kurzer Ausschlag sofort einen Betriebsalarm erzeugt. Für die Rückkehr gilt eine andere Grenze: Der Alarm wird erst gelöscht, wenn fünf aufeinanderfolgende Aufträge höchstens 6 Sekunden benötigen. Diese getrennten Ein- und Ausschaltbedingungen bilden eine Hysterese. Sie verhindert ein ständiges Wechseln zwischen Alarm und Normalzustand nahe der Grenze.

Gib jedem Betriebszustand eine Reaktion

Das Team verwendet vier sichtbare Zustände. Ein Status ohne Reaktion wäre nur eine farbige Anzeige.

WARTUNG ist nicht dasselbe wie NORMAL. Eine unterdrückte Meldung macht die Funktion nicht verfügbar. Das Monitoring muss Wartungsfenster, Verantwortlichkeit und Ablaufzeit protokollieren. Sonst kann eine vergessene Unterdrückung einen echten Ausfall verdecken.

Baue eine durchgängige Monitoringkette

Eine Messgröße hilft nur, wenn sie verlässlich bis zu einer zuständigen Person gelangt. Die Monitoringkette von Elbwerk verbindet Erfassung, Bewertung, Alarmierung und Rückmeldung.

Die Überwachung selbst kann ebenfalls ausfallen. Elbwerk prüft deshalb, ob der Sammler regelmäßig Daten erhält, ob die Zeitquelle stimmt und ob ein Testalarm den vereinbarten Empfänger erreicht. Dieser Eigenzustand des Monitorings gehört auf eine getrennte Anzeige. Sonst sieht eine leere Alarmseite genauso aus wie ein störungsfreier Betrieb.

Ein handlungsfähiger Alarm enthält mindestens:

Alarm-ID: SHUTTLE_COMPLETION_TIMEOUT
Beginn: 2026-07-10T14:31:22+02:00
Funktion: Auftrag T-882 an Übergabepunkt U-3 abschließen
Soll: Abschlussmeldung innerhalb 8 s
Ist: seit 15 s keine Abschlussmeldung
Zustand: AUSFALL
Reaktion: neue Übergaben gesperrt; Auftrag T-882 lokal gesichert
Nächster Schritt: Ereigniskette für T-882 ab Gateway prüfen

“Shuttle gestört” reicht nicht. Die Meldung braucht einen Zeitbezug, die verletzte Regel, die betroffene Funktion und die bereits ausgeführte Reaktion. So beginnt die Diagnose mit einem Befund statt mit einer Vermutung.

Entwirf die Überwachung für eine neue Anlage

Was du aus der Überwachung mitnimmst

Verfügbarkeit ist keine einzelne grüne Lampe. Sie verbindet eine fachliche Funktion mit Messwert, Zeitgrenze, Zustand und Reaktion.

• Definiere zuerst, was im Betrieb verfügbar sein soll.
• Kombiniere Heartbeat oder Keep Alive mit einem fachlichen Funktionsnachweis.
• Nutze einen lokalen Watchdog nur mit einer vorab festgelegten sicheren Reaktion.
• Begründe Timeouts aus Prozess und Risiko, nicht aus einem beliebigen Standardwert.
• Trenne Normalbetrieb, Degradation, Ausfall und Wartung sichtbar.
• Vermeide flatternde Alarme durch passende Hysterese, ohne klare Ausfälle zu verzögern.
• Überwache auch die Monitoringkette und bestätige den Wiederanlauf Ende zu Ende.

Die Abgrenzung bleibt wichtig: Diese Lektion bewertet nicht, ob ein einzelner Sensorwert physikalisch plausibel ist. Sie lokalisiert auch keine konkrete Netzwerkstörung und entwirft keine Schutzarchitektur gegen Angriffe. Sie legt fest, wie ein CPS seinen Betriebszustand laufend sichtbar macht und auf verlorene Verfügbarkeit kontrolliert reagiert.

Belegmatrix