Wie entwickelt man industrielle Anwendungen, die gegen kurzfristige Netzwerkausfälle, Geräte-Neustarts und Verbindungsverluste robust sind?

Die Widerstandsfähigkeit einer Industrieanwendung gegenüber kurzzeitigem Netzausfall, Geräte-Neustarts und Verbindungsverlust ist heute kein Komfortmerkmal mehr, sondern eine Voraussetzung für einen ordnungsgemäßen Prozessablauf und dafür, dass die Verantwortung beim Hersteller, Integrator oder Endanwender klar zugeordnet bleibt. In industriellen Umgebungen ist ein Kommunikationsausfall kein Ausnahmefall: Er tritt bei Servicearbeiten, Infrastrukturumschaltungen, dem Wiederanlauf nach einem Stromausfall, bei Updates, Netzüberlastung oder schlicht durch den Ausfall eines Edge-Geräts auf. Verliert die Anwendung unter solchen Bedingungen die Konsistenz ihres Zustands, dupliziert Befehle oder führt nach Wiederherstellung der Verbindung ausstehende Operationen ohne Kontrolle des Kontexts aus, ist das Problem nicht mehr nur ein IT-Thema. Es wird zu einer Frage der Prozesskontinuität, der funktionalen Sicherheit, der Qualität von Produktionsdaten und der Nachvollziehbarkeit von Konstruktionsentscheidungen.

Deshalb muss dieses Thema zu Beginn des Projekts entschieden werden und nicht erst nach der ersten Inbetriebnahme. Eine gegen Kommunikationsunterbrechungen robuste IT-/OT-Architektur beeinflusst, wie Maschinenzustände modelliert werden, nach welchen Regeln Daten gepuffert werden, in welcher Reihenfolge Befehle bestätigt werden, unter welchen Bedingungen eine Sitzung erneut aufgebaut wird und nach welcher Logik die Anlage nach einem Neustart den Betrieb wieder aufnimmt. Wenn das Team diese Entscheidungen aufschiebt, endet es meist bei teuren Behelfslösungen: lokal nachträglich eingebauten Ausnahmen, manuellem Leeren von Warteschlangen, zusätzlichen Bediensperren oder dem Ausbau der Leitebene allein deshalb, um das fehlende vorhersehbare Verhalten der Geräte zu kompensieren. Das praktische Bewertungskriterium ist einfach: Für jede wesentliche Funktion muss sich eindeutig beantworten lassen, was bei einem Verbindungsverlust geschieht, was nach einem Neustart passiert und wer die Wiederaufnahme des Betriebs bestätigt. Lautet die Antwort „das hängt von der Implementierung ab“ oder „der Bediener wird sehen, dass etwas nicht stimmt“, dann ist das noch keine Konstruktionsentscheidung, sondern eine Verlagerung des Risikos in den Betrieb.

Besonders deutlich zeigt sich das an der Schnittstelle zwischen Anwendung und Maschinen- oder Prozessbewegung. Man stelle sich ein System vor, in dem das Bedienpanel den Start eines Zyklus auslöst, die Steuerung ihn jedoch wegen eines kurzzeitigen Verbindungsverlusts verzögert ausführt. Wenn die Anwendung nach Wiederherstellung der Kommunikation den Befehl erneut sendet, weil keine Bestätigung eingegangen ist, kann es zu einer doppelten Ausführung des Vorgangs oder zu einem Start unter anderen Bedingungen kommen als denen, die der Bediener beim Absetzen des Befehls gesehen hat. An diesem Punkt geht das Thema Kommunikationsrobustheit in den Bereich der Sicherung gegen unerwartetes Anlaufen über: Nicht jeder Neustart ist ein Sicherheitsproblem, aber jeder Neustart, der die Anlaufbedingungen ohne bewusste Bestätigung und ohne Prüfung des Gerätezustands verändern kann, erfordert bereits eine Analyse auf diesem Niveau. Ähnlich verhält es sich mit Verriegelungseinrichtungen und Zuhaltungen: Wenn die Anwendungslogik das Personal nach einem Netzausfall dazu verleitet, lästige Sperren zu umgehen, liegt das Problem nicht allein im Verhalten des Benutzers, sondern in der Konstruktionsentscheidung.

Aus Sicht von Management und Compliance ist daher nicht entscheidend, ob Kommunikationsunterbrechungen „vorkommen“, sondern ob das Projekt in solchen Grenzzuständen ein sicheres und vorhersehbares Verhalten nachweisen kann. Genau an diesem Punkt geht das Thema auch in eine praktische Risikobeurteilung über: Es ist zu unterscheiden zwischen Funktionen, bei denen eine Verzögerung oder der Verlust eines Teils der historischen Daten zulässig ist, und Funktionen, bei denen der Verlust des Kontexts zu einer Fehlentscheidung des Bedieners, zu Produktschäden oder zu einer Gefährdung beim Wiederanlauf führen kann. Sinnvoll ist es, nicht eine abstrakte „Systemstabilität“ zu messen, sondern Kennzahlen, die die Auswirkungen der Konstruktionsentscheidung zeigen: die Anzahl uneindeutiger Wiederanläufe nach einem Neustart, die Anzahl von Befehlen, die eine manuelle Zustandsabstimmung erfordern, die Zeit bis zur sicheren Wiederaufnahme des Betriebs sowie Fälle, in denen das System nicht nachweisen kann, ob ein Befehl ausgeführt wurde. Erst vor diesem Hintergrund sind normative Anforderungen und Entscheidungen über technische Maßnahmen sinnvoll: die Analyse der Anlaufbedingungen nach einem Stromausfall, die Risikobeurteilung für Szenarien mit Verbindungsverlust sowie die Auswahl von Verriegelungs- und Überwachungslösungen dort, wo der reine IT-Mechanismus keine ausreichende Sicherheit bietet.

Wo Kosten oder Risiken am häufigsten steigen

Bei Projekten für Industrieanwendungen, die gegen kurzzeitigen Netzausfall, Geräte-Neustarts und Verbindungsverlust robust sein sollen, steigen die Kosten meist nicht durch die technischen Mechanismen selbst, sondern durch falsche Annahmen über den Prozesszustand nach einer Störung. Geht das Team davon aus, dass das System nach Wiederherstellung der Verbindung „zum Normalbetrieb zurückkehrt“, wird es früher oder später für manuelle Zustandsabgleiche, Korrekturen an der Steuerungslogik, zusätzliche Abnahmetests oder erst nach der Inbetriebnahme auferlegte Betriebsbeschränkungen bezahlen. Am teuersten sind Situationen, in denen die Anwendung nicht eindeutig beantworten kann, ob ein Befehl ausgeführt, unterbrochen, doppelt ausgeführt oder nur auf der Bedienoberfläche registriert wurde. Das ist keine Frage des Bedienkomforts, sondern der Verantwortung für die physische Wirkung: die Bewegung eines Antriebs, die Änderung eines Sollwerts, das Öffnen eines Ventils, die Quittierung eines Alarms oder die Wiederaufnahme eines Zyklus.

Eine weitere Ursache für Projektverzögerungen ist eine fehlerhafte Aufteilung der Verantwortlichkeiten zwischen Bedienebene, Middleware und Maschinensteuerung. Wenn die Entscheidung darüber, was nach einem Neustart geschehen soll, „der Implementierung“ überlassen wird, endet das Team meist mit widersprüchlichen Regeln: Das Panel zeigt den zuletzt bekannten Zustand an, die Steuerung startet eine Initialisierungsprozedur, und das übergeordnete System spielt ausstehende Befehle erneut ab, ohne sicher zu wissen, ob diese noch gültig sind. In der Praxis muss das früher und eindeutig festgelegt werden: Welche Vorgänge dürfen ohne Nebenwirkungen wiederholt werden, welche erfordern eine Bestätigung der aktuellen Anlagenbedingungen, und welche müssen nach einem Kommunikationsverlust verfallen und in einen sicheren Zustand übergehen. Ein gutes Entscheidungskriterium ist einfach: Wenn eine fehlerhafte Wiederaufnahme eines Vorgangs den Energiezustand, die Stellung eines Aktors, die Produktqualität oder die Sicherheitsbedingungen für Personen verändern kann, darf man sich nicht allein auf den gespeicherten letzten Zustand der Anwendung verlassen.

Das zeigt sich gut am Beispiel einer Sequenz, die vor dem Kommunikationsausfall den Befehl zum Schließen der Schutzeinrichtung und zum Start des Zyklus gesendet hat und nach dem Neustart der Bedienstation den Bildschirm „Betriebsbereitschaft“ wiederherstellt. Wenn die Anwendung nicht zwischen den Zuständen „Befehl angenommen“, „Ausführung bestätigt“, „Ausführung unterbrochen“ und „Zustand unbestimmt“ unterscheidet, erhält der Bediener ein scheinbar stimmiges, tatsächlich aber unvollständiges Bild. Die Folge können unnötige Stillstände sein, weil das Bedienpersonal den Prozess nicht wieder aufnehmen will, oder umgekehrt ein unzulässiger Anlauf, weil die Benutzeroberfläche nicht anzeigt, dass eine erneute Prüfung erforderlich ist. Für den Projektleiter bedeutet das später eine kostspielige Ursachenanalyse, die Änderung von Testszenarien und die Notwendigkeit, Umgehungsverfahren nachzutragen. Für den Produkteigentümer ist es ein Risiko für Reklamationen und Streitigkeiten über den Verantwortungsumfang, insbesondere wenn die Anforderungsdokumentation das Systemverhalten nach Ausfall der Spannungsversorgung oder der Kommunikation nicht eindeutig beschreibt. Deshalb sollte man nicht nur die Verfügbarkeit messen, sondern auch die Anzahl unbestimmter Zustände nach dem Neustart, die Anzahl von Vorgängen mit erforderlicher manueller Abstimmung sowie die Zeit bis zum Erreichen eines sicheren betriebsbereiten Zustands.

Eine eigene Kostenkategorie ist die Verwechslung von Kommunikationsrobustheit mit funktionaler Sicherheit. Allein die Tatsache, dass eine Anwendung Daten puffern, Übertragungen wiederholen oder eine Sitzung wiederherstellen kann, bedeutet noch nicht, dass sich die Maschine nach einem Verbindungsverlust sicher verhält. Wenn die Auswirkung einer Störung Funktionen betrifft, die mit Bewegung, gespeicherter Energie, Verriegelungen oder den Bedingungen für den Wiederanlauf zusammenhängen, geht das Thema zwangsläufig in eine praktische Risikobeurteilung über. Dann ist nicht nur die Wahrscheinlichkeit eines Netzausfalls zu untersuchen, sondern vor allem die möglichen Folgen einer fehlerhaften Zustandsinformation und einer fehlerhaften Wiederaufnahme. Wenn das System Hydraulik umfasst, kommen Anforderungen an das Verhalten der Aktoren bei Ausfall der Spannungsversorgung und Druckabfall hinzu; dabei dürfen Entscheidungen auf Anwendungsebene nicht im Widerspruch zu den Konstruktionsgrundsätzen für Hydrauliksysteme stehen. Dort wiederum, wo die Wiederherstellung der Betriebsbereitschaft vom Schließen einer Schutzeinrichtung oder dem Lösen einer Verriegelung abhängt, kann das Problem auch den Bereich von Verriegelungseinrichtungen und der Umgehungssicherheit betreffen, denn der Druck auf eine „schnelle Wiederaufnahme“ führt sehr häufig später zu gefährlichen Betriebspraktiken.

Ein normativer Bezug ist erst in diesem Stadium sinnvoll, wenn bereits feststeht, welches Szenario technische und organisatorische Auswirkungen hat. Wenn Verbindungsverlust oder Neustart die Bedingungen für einen sicheren Anlauf verändern können, muss dies in der Risikobeurteilung beschrieben werden und darf nicht als Standardverhalten des Softwareherstellers oder des Steuerungslieferanten offenbleiben. Wenn ein Antriebssystem nach Ausfall der Spannungsversorgung einen prozesstechnisch ungünstigen oder gefährlichen Zustand annehmen kann, ist zu prüfen, ob die Anforderungen für die jeweilige Antriebsart und das jeweilige Medium zusätzliche konstruktive Maßnahmen erzwingen, unabhängig von der Anwendungslogik. Ein praktisches Abgrenzungskriterium lautet: Wenn sich ein Fehler nach der Wiederherstellung des Zustands ausschließlich durch ein Bedienverfahren beseitigen lässt, ist das Thema nicht mehr nur informationstechnisch, sondern auch eine Frage der Konstruktion und Konformität. Genau an diesem Punkt ist die Entscheidung über die Anwendungsarchitektur keine Frage des Implementierungskomforts mehr, sondern Teil der Verantwortung für ein sicheres und vorhersehbares Verhalten des Gesamtsystems.

Wie man das Thema praktisch angeht

In der Praxis beginnt die Robustheit einer Industrieanwendung gegenüber kurzzeitigem Netzausfall, Geräte-Neustarts und Verbindungsverlust nicht mit der Wahl der Technologie, sondern mit der Entscheidung, welche Ausfallfolgen akzeptabel sind und welche nicht. Das Team sollte zu Beginn drei Dinge voneinander trennen: den Prozesszustand, den Steuerungszustand und den dem Bediener angezeigten Zustand. Diese Unterscheidung entscheidet darüber, ob die Anwendung nach einem Kommunikationsabbruch lediglich die Ansicht wiederherstellen soll oder ob sie die Steuerung, die Befehlswarteschlange oder die technologische Sequenz wieder aufnehmen darf. Wenn diese Ebenen zu einer einzigen verschmolzen werden, endet das Projekt meist mit kostspielig nachprogrammierten Ausnahmen, manuellen Umgehungsverfahren oder einem Streit über die Verantwortlichkeit nach der Inbetriebnahme. Für das Management ist hier eines entscheidend: Das Fehlen einer ausdrücklichen Architekturentscheidung senkt das Risiko nicht, sondern verlagert es in die Phase der Abnahmen, des Service und der Konformität.

Operativ bedeutet das, für jeden kritischen Fall festzulegen, was das System nach einer Störung beibehalten soll und was keinesfalls beibehalten werden darf. Es geht nicht um die allgemeine Aussage „soll nach Reconnect weiterlaufen“, sondern um präzise Regeln: Welche Daten werden aus einem persistenten Speicher wiederhergestellt, welche müssen vom Gerät bestätigt werden, welche Befehle verlieren nach Ablauf einer Frist ihre Gültigkeit und welche erfordern eine erneute Autorisierung oder eine Bestätigung durch den Bediener. Ein gutes Entscheidungskriterium ist einfach: Wenn sich nach einem Neustart nicht eindeutig feststellen lässt, ob ein vorheriger Befehl ausgeführt wurde, darf das System ihn nicht automatisch erneut ausführen. Dasselbe gilt für Alarme, Chargenzähler, Betriebsarten und technologische Verriegelungen. Eine solche Festlegung wirkt wie ein kleines Projektdetail, ohne sie steigen jedoch die Kosten für Integrationstests, weil jede Unklarheit als schwer reproduzierbarer Fehler zurückkehrt. Auch die Verantwortung auf Seiten des Lösungsverantwortlichen nimmt zu, weil später nachgewiesen werden muss, dass das Verhalten bei Verbindungsverlust vorhersehbar und beabsichtigt war.

Ein typisches Beispiel ist eine Anwendung, die einen Startbefehl für einen Zyklus an die Steuerung sendet und dann die Verbindung verliert, bevor eine Bestätigung eingeht. Sendet die Anwendung nach Wiederherstellung der Verbindung den Befehl „zur Sicherheit“ erneut, kann sie den Zyklus ein zweites Mal starten. Geht sie umgekehrt davon aus, dass der Befehl sicher ausgeführt wurde, kann sie den Prozesszustand falsch rekonstruieren und weitere Vorgänge in einer falschen Reihenfolge zulassen. Der richtige Ansatz besteht darin, Befehle und Antworten so zu entwerfen, dass sie zeitlich unterscheidbar und identifizierbar sind und sich nach einem Neustart der tatsächliche Gerätezustand prüfen lässt, bevor die Geschäftslogik wieder aufgenommen wird. An dieser Stelle sollte nicht nur die Systemverfügbarkeit gemessen werden, sondern auch die Anzahl uneindeutiger Zustandswiederherstellungen, die Zahl manueller Eingriffe nach einem Neustart sowie die Zeit, die für eine sichere Wiederaufnahme des Betriebs benötigt wird. Das sind Kennzahlen, die die tatsächlichen Kosten der Architektur zeigen und nicht nur den Komfort für die Programmierung.

Die Grenze zur praktischen Risikobeurteilung ist dort erreicht, wo eine fehlerhafte Zustandswiederherstellung das Verhalten einer Maschine, einer Sequenz oder eines Aktors verändern kann. In diesem Fall ist das Thema nicht mehr ausschließlich informationstechnisch, sondern fällt in den Bereich der praktischen Risikobeurteilung, auch im Sinne der bei ISO/TR 14121-2 angewendeten Methodik. Besteht nach einem Spannungsausfall oder einem Neustart des Geräts die Möglichkeit, dass Bewegungen selbsttätig wieder anlaufen, ein Medium zugeführt wird, ein Aktor freigegeben wird oder in eine Betriebsart gewechselt wird, ohne dass der Bediener bewusst zugestimmt hat, betrifft das auch den Schutz gegen unerwartetes Anlaufen, was einen breiteren Blick als nur auf die Anwendungslogik erfordert. Wo hydraulische oder pneumatische Antriebe vorhanden sind, kommen zusätzlich konstruktive Anforderungen und das Verhalten des Systems bei Energieverlust hinzu; deshalb darf die Entscheidung über eine „weiche“ Wiederaufnahme des Betriebs nicht losgelöst von den technischen Bedingungen der gesamten Anlage getroffen werden. Aus Sicht der Konformität ist es am sichersten, die Prozessabsicht nach einer Störung nicht zu erraten, sondern die Bedingungen für die Rückkehr in den Betrieb im Voraus festzulegen und konkreten Verantwortlichkeiten zuzuordnen: der Anwendung, der Steuerung, dem Aktorsystem und dem Bediener.

Worauf bei der Umsetzung zu achten ist

Die meisten Fehler bei der Umsetzung industrieller Anwendungen, die gegen kurzzeitige Netzwerkausfälle, Geräte-Neustarts und Verbindungsverlust robust sein sollen, entstehen nicht durch die Technologie selbst, sondern durch eine falsche Zuordnung von Verantwortlichkeiten. Das Team geht davon aus, dass die „Robustheit“ durch die Kommunikationsebene, den Cloud-Anbieter oder die Steuerung gelöst wird, obwohl das eigentliche Problem in der Beziehung zwischen Prozesszustand, Gerätezustand und Datenzustand liegt. Werden diese drei Ebenen nicht bereits bei der Abnahme voneinander getrennt, erzeugt das Projekt eine scheinbare Zuverlässigkeit: Die Anwendung funktioniert nach dem Neustart, aber niemand kann nachweisen, ob sie den Zustand nach dem Neustart korrekt, sicher und im Einklang mit der physischen Realität wiederhergestellt hat. Das wirkt sich unmittelbar auf die Kosten aus, weil spätere Korrekturen in der Regel gleichzeitig Änderungen an der Steuerungslogik, der Bedienoberfläche, der Ereignisprotokollierung und den Anfahrprozeduren erfordern. Es wirkt sich auch auf die Verantwortung aus, weil sich eine Lösung im Fall eines Vorfalls nur schwer verteidigen lässt, wenn nicht eindeutig festgelegt wurde, wer und auf welcher Grundlage die Bereitschaft zur Wiederaufnahme des Betriebs bestätigt.

In der Praxis ist die gefährlichste Falle, den Verbindungsverlust wie einen gewöhnlichen technischen Fehler zu behandeln und nicht wie einen eigenen Betriebszustand des Systems. Wenn die Anwendung nach einem Netzausfall Vorgänge puffert und sie nach Wiederherstellung der Verbindung ohne Prüfung des aktuellen Kontexts erneut abarbeitet, kann sie verspätete, nicht mehr zulässige oder dem tatsächlichen Zustand der Linie widersprechende Aktionen ausführen. Ein analoges Problem tritt nach einem Geräte-Neustart auf: Ein zuvor gespeicherter logischer Zustand kann formal vollständig sein, physisch aber veraltet, weil sich in der Zwischenzeit die Position eines Aktors, der Druck des Mediums, die Konfiguration der Betriebsart oder ein Eingriff des Bedienpersonals geändert hat. Ein gutes Entscheidungskriterium ist auch hier einfach: Wenn das System nach der Zustandswiederherstellung irgendeine auf den Prozess einwirkende Handlung ausführen soll, muss deren Zulässigkeit zuerst anhand der aktuellen Signale verifiziert werden können und nicht ausschließlich anhand der vor der Störung gespeicherten Historie. Lässt sich eine solche Verifikation nicht nachweisen, ist es sicherer, in einen Zustand zu wechseln, der eine ausdrückliche Bestätigung oder eine erneute Synchronisierung erfordert.

Ein gutes Beispiel ist eine Station, die nach einem kurzzeitigen Kommunikationsausfall die Verbindung zum übergeordneten System verliert, lokal aber weiterhin einen Teil der Eingangssignale sieht. Aus Sicht des Programms ist es verlockend, die Sequenz nach Wiederherstellung der Verbindung „zu Ende zu fahren“, um keine Zykluszeit zu verlieren. Das Problem beginnt dann, wenn der Bediener in der Zwischenzeit das Werkstück entfernt hat, ein Entlastungsventil angesprochen hat, das Panel neu gestartet wurde oder der Antrieb in einen anderen Modus gewechselt ist. In der Applikationslogik kann alles konsistent aussehen, und dennoch wird das Wiederaufnehmen des Schritts zu einem verfahrenstechnischen Fehler oder zu einer Gefährdung. Deshalb sollte man bei der Implementierung nicht nur die Anzahl verlorener Telegramme oder die Dauer der Sitzungswiederherstellung bewerten, sondern auch Kennzahlen, die die Qualität des Verhaltens nach einer Störung zeigen: wie oft das System eine manuelle Resynchronisation erforderte, wie viele Vorgänge als nicht mehr aktuell verworfen wurden, wie viele Neustarts mit dem Übergang in einen sicheren Zustand statt mit einer automatischen Wiederaufnahme endeten. Das sind bessere Reifegradindikatoren für eine Lösung als die reine Dienstverfügbarkeit, weil sie offenlegen, ob die Robustheit nicht auf Kosten der Kontrolle über den Prozess erkauft wurde.

Die Grenze, an der dieses Thema nicht mehr nur eine Frage der Anwendungsarchitektur ist, wird schneller erreicht, als Projektteams meist annehmen. Wenn der Verbindungsverlust, ein Neustart der Steuerung oder die Wiederherstellung der Aufgabenwarteschlange die Maschinenbewegung, die Energiezufuhr oder eine Zustandsänderung der Aktorik beeinflussen kann, geht das Thema in eine praktische Risikobeurteilung über. An dieser Stelle reicht das Argument nicht mehr aus, dass die Lösung „normalerweise korrekt funktioniert“; erforderlich ist eine Analyse von Abweichungsszenarien, auch in einer Logik, die dem bei ISO/TR 14121-2 verwendeten Ansatz nahekommt. Wenn darüber hinaus nach Wiederherstellung der Versorgung oder der Verbindung die Möglichkeit einer selbsttätigen Wiederaufnahme der Funktion besteht, betrifft das Thema auch den Schutz vor unerwartetem Anlauf und muss umfassender betrachtet werden, im Zusammenhang mit den Anlaufbedingungen und dem Zustand der Energieabschaltung. Wo das System Hydraulik oder Pneumatik umfasst, lässt sich die softwareseitige Entscheidung nicht vom Verhalten der Anlage nach Energieausfall trennen; in solchen Fällen sind auch die konstruktiven Anforderungen zu prüfen, die für das Gesamtsystem gelten, und nicht nur die Korrektheit des Anwendungscodes.