Herr Thiesmann, aufgrund der Lieferengpässe kommt es zu Reengineering und auch alternativen Lösungen. Welche Auswirkungen hat das auf die Sicherheitszertifizierung nach den Safety-Standards? Wie lässt sich eine erneute Zertifizierung verhindern?

Tobias Thiesmann: Gezielt kann man in diesem Fall wenig verhindern. Wenn die alternativen Bauteile innerhalb der vorgegebenen Spezifikation sind und über die gleiche Bauform verfügen, bewerten wir es intern und melden die Änderung beim zuständigen Notified Body. Muss eine wesentliche Änderung durch das alternative Bauteil durchgeführt werden, wie zum Beispiel eine Layout-, Schaltungs- oder Software-Änderung, müssen diese Änderungen beim Notified Body neu geprüft werden – bis hin zur Neuzertifizierung.

Immer mehr Safety-Funktionen werden in Software abgebildet. Worauf sollte der Anwender bei der Realisierung achten?

Sicherheitsfunktionen in Software abzubilden ist grundsätzlich kein Problem. Allerdings sollte diese Software auf einer Hardware laufen, die für den Einsatz im Bereich funktionaler Sicherheit geeignet ist. Das erkennt man in der Regel schon daran, dass der Hersteller die entsprechenden Kennwerte angibt – also Safety Integrity Level, Performance Level oder Sicherheitskategorie. Aber auch die Software selbst muss bestimmte Anforderungen erfüllen. Einen Einstieg bieten hier die Normen ISO 13849-1 und 13849-2. Meistens wird programmierbare Hardware, die es erlaubt, Sicherheitsfunktionen in Software abzubilden, seitens des Herstellers mit einer geeigneten Programmierumgebung ausgeliefert. Nach Erstellung der Software muss außerdem eine Validierung vorgenommen werden, die gewährleistet, dass die Implementierung der Software den Anforderungen zum Beispiel aus der Risikobeurteilung genügt.

Auf Safety-Steuerungen kommt auch Software von Anwendern zum Einsatz. Was heißt dies bezüglich der Einhaltung der Safety-Zertifizierung?

Die programmierbaren Sicherheitssteuerungen Protect PSC1 sind Basis vieler Sicherheitslösungen – auf Wunsch mit kundenspezifischer Software.

© Schmersal

Die vom Hersteller angegebenen Sicherheitsparameter gelten in der Regel nur für die Hard- und Firmware der Sicherheitsteuerung. Die Anwendersoftware liegt – wie der Name schon nahelegt – in der Verantwortung des Erstellers, also des Anwenders. Softwarefehler im engeren Sinne werden hierbei zwar oft über die Programmierumgebung abgefangen, die eigentliche Programmlogik bleibt bei dieser Prüfung aber außen vor. Das heißt: Nicht alles, was kompiliert ist, ist auch funktional sicher.

Zusätzlich zur Verwendung sicherer Hardware und einer geeigneten Programmierumgebung muss der Anwender durch Validierung die Eignung der Software dokumentieren. Neben der Eignung der Steuerung spielen nämlich auch Fragestellungen in Bezug auf die konkrete Applikation zur Erreichung bestimmter Sicherheitskennwerte eine Rolle – zum Beispiel Schutz gegen unerwarteten Wiederanlauf oder das Einbinden der Rückführkreise.

Schmersal steht Anwendern beratend zur Seite. Welche Fragen tauchen dabei immer wieder auf? Wo sehen Sie den größten Handlungsbedarf?

Die erste Fragestellung ist oft die Auswahl der richtigen Hardware für eine konkrete Aufgabenstellung. Daran schließt sich dann häufig die Beratung der Kunden bei der Integration der Sicherheitslösung in die Applikation an. Was oftmals auf der Strecke bleibt, ist allerdings die Nutzung von Synergie- effekten. Eine moderne, programmierbare Sicherheitslogik bietet häufig die Möglichkeit, Sicherheitslösungen zu vereinheitlichen und auch weitere Funktionen wie etwa Schnittstellen zur Dokumentation sowie zur Diagnose und Kommunikation. Dieses Potenzial wird gern verschenkt, weil es dem Anwender nicht unmittelbar neuen Umsatz bringt und man deshalb ‚alles so lassen will, wie es ist‘. Die langfristige Steigerung der Produktivität bleibt damit leider oft auf der Strecke.