Ein Steuerungssystem sollte nach dem Einschalten sofort einsatzbereit sein, ohne manuelles Eingreifen. Doch nach mehreren Neustarts blieb genau das aus – und das obwohl ein cleverer Sicherheitsworkaround eigentlich für reibungslose Abläufe sorgen sollte.
Wenn zwei Sicherheitslogiken um ein und dieselbe Identität konkurrieren
Die Herausforderung bestand darin, ein Testwerkzeug zu entwickeln, das zwei gegensätzliche Sicherheitsmodi in einem einzigen System vereinen sollte. Beide Modi nutzten dieselbe Verbindung über FSoE (Fail Safe over EtherCAT), ein von Beckhoff entwickeltes Protokoll zur Übertragung von Sicherheits-signalen wie Not-Aus-Befehlen über ein Standard-Ethernet-Netzwerk. FSoE gilt als besonders zuverlässig, weil jede Verbindung eine eindeutige ID besitzt, die zyklisch überprüft wird. Ein Master entscheidet, was sicher ist, während ein Slave die Anweisungen ausführt. Doch wie sollte ein System funktionieren, das zwei gegensätzliche Sicherheitslogiken unter einer einzigen ID betreiben muss?
Der Workaround, der zunächst überzeugte
Die naheliegende Lösung wäre gewesen, zwei separate, validierte Konfigurationen zu erstellen und jeweils nur eine davon aktiv zu schalten. Doch die Rahmenbedingungen ließen dies nicht zu. Stattdessen wurde der TwinCAT 3 Safety Editor TE9000 von Beckhoff genutzt, um das Verhalten zur Laufzeit zwischen Master- und Slave-Modus umzuschalten – bei gleichbleibender Verbindungskennung. Das Ergebnis war ein tragbares Gerät, bestehend aus einem Beckhoff Compact-PC und einer Sicherheits-SPS, das automatisch nach dem Hochfahren starten sollte. Und es funktionierte – zumindest anfangs.
Warum der automatische Start plötzlich versagte
Nach einigen Neustarts und dem Wechsel zwischen den Sicherheitskonfigurationen blieb der automatische Start des Systems gelegentlich aus. Manchmal startete es erst beim zweiten oder dritten Versuch, manchmal musste es manuell über die Entwicklungsumgebung gestartet werden. Die Ursache blieb unklar. Eine Vermutung: Die wiederholte Modifikation der Sicherheitskonfiguration im Runtime-Betrieb hinterließ das System in einem Zustand, in dem die Boot-Sequenz und die Sicherheitslogik nicht mehr synchron liefen. Das Problem? Ein System, das „meistens“ startet, ist für den Betrieb einer Sicherheitskomponente absolut ungeeignet.
Die harte Lektion: Safety verlangt Vorhersehbarkeit
Sicherheitssysteme müssen von Anfang an zuverlässig sein – insbesondere beim Systemstart. Jedes Einschalten sollte in einen vorhersehbaren, validierten Zustand führen. Sobald die Sicherheitskonfiguration zur Laufzeit verändert wird, riskiert man unvorhersehbare Zustände, von denen sich das System nicht immer sauber erholt. Intermittierende Fehler sind besonders tückisch, weil sie sich oft erst im Ernstfall zeigen. Die Lösung war daher nicht ein noch clevererer Umschaltmechanismus, sondern das genaue Gegenteil: zwei separate, statisch validierte Konfigurationen, von denen jeweils nur eine aktiv ist. Flexibilität und Sicherheit stehen hier im Widerspruch – und bei Sicherheits-systemen gewinnt immer die Vorhersehbarkeit.
Wer mit TwinSAFE, FSoE oder einer Sicherheits-SPS arbeitet, sollte bei Runtime-Konfigurationen besonders vorsichtig sein. Alles, was das Sicherheitsverhalten während des Betriebs verändert, birgt Risiken. Funktionieren und Zuverlässigkeit sind zwei verschiedene Dinge.
KI-Zusammenfassung
Güvenlik davranışını çalışırken değiştirmek, beklenmedik arızalara yol açabilir. Beckhoff FSoE sistemlerinde yaşanan gizli hata ve güvenilir sistemler için alınması gereken önlemler.
