Im Bereich der Automatisierung kamen die ersten sicherheitsrelevanten Steuerungen vor mehr als einem Vierteljahrhundert auf den Markt. Was damals noch als Exot galt, ist heute in zahlreichen Maschinen und Anlagen zu finden. Safety-SPS unterscheiden sich auf den ersten Blick meist schon durch die gelbe Farbgebung von den Standardsteuerungen. Doch es gibt ein viel bedeutenderes Differenzierungsmerkmal: Im Inneren der Safety-SPS schlagen oftmals zwei ‚Herzen‘. Das bedeutet, dass zwei Prozessoren den Programmablauf kontrollieren und lediglich im Einklang miteinander die Ausgänge freigeben, die dann zum Beispiel Bewegungsabläufe sicher starten und stoppen können.
Der Vorteil der sicherheitsrelevanten Steuerung liegt in der Flexibilität, sicherheitsrelevante Verknüpfungen zu realisieren. Damit ist die Safety-SPS auch Teil der Sicherheitskette, wenn es darum geht, die Sicherheits- und Gesundheitsschutzanforderungen umzusetzen. Vor diesem Hintergrund wurde die Sicherheitssteuerung entsprechend vom Steuerungshersteller konstruiert und beispielsweise für das Sicherheitslevel SIL 3 gemäß der internationalen Norm IEC61508 zertifiziert. Bei der Anwendungssoftware kommt diese Aufgabe hingegen dem Hersteller der Applikation zu. Die Anforderungen an die Softwareentwicklung kann der Applikateur den Normen zur funktionalen Sicherheit entnehmen. Im Anwendungsbereich der Maschinenrichtlinie sind das die EN ISO62061 und die DIN EN ISO13849-1. Letztere wird im Maschinenbau häufig bevorzugt angewandt. Dabei unterscheidet die Norm verschiedene Performance Level (PLr), die als Vorgabe für die Sicherheitsfunktion in der Risikobeurteilung ermittelt wurden. Die Einstufung erstreckt sich von PLr a bis zu PLr e für Gefährdungen mit einem großen Risiko.
Trennung von sicherheitsbezogener und nicht-sicherheitsbezogener Software
Der notwendige Performance Level (PLr) ist ebenfalls ausschlaggebend für die Erstellung der Applikationssoftware der Sicherheitssteuerung. In Kapitel 4.6 der DIN EN ISO13849-1 gibt es generelle Basisanforderungen, die für jeden Performance Level zutreffen. Sie werden durch sogenannte zusätzliche Anforderungen ergänzt, welche ab einem Performance Level PLr c einzuhalten sind. In diesem Zusammenhang wird davon ausgegangen, dass die Applikationssoftware in einer Programmiersprache mit eingeschränktem Sprachumfang (LVL – Limited Variability Language) – und hier vorzugsweise einer grafischen Programmierung – zum Einsatz kommt. Handelt es sich andererseits um einen uneingeschränkten Sprachumfang (FVL – Full Variability Language), wird auf die wesentlich umfangreicheren Entwicklungs- und Validierungsprozesse gemäß der Sicherheitsgrundnorm IEC61508 verwiesen.
Die meisten Sicherheitssteuerungen stellen dem Anwender daher nur einen eingeschränkten Sprachumfang zur Verfügung. Das heißt, dass sie zum Beispiel keine Programmschleifen und -sprünge unterstützen, damit das Softwareprogramm übersichtlich und wartbar bleibt. Die Trennung der sicherheitsbezogenen und nicht-sicherheitsbezogenen Applikationssoftware ist ebenso wichtig, denn die reine Prozesssteuerung wird im Regelfall öfter modifiziert. Manchmal nimmt der Programmierer sogar noch kurz vor der Inbetriebnahme Änderungen vor. Bei der Nutzung zertifizierter Sicherheitssteuerungen – wie den Safety-SPS von Phoenix Contact – ist diese Trennung gegeben und mit einer eindeutigen Prüfsumme geschützt.
Basisanforderungen gemäß DIN EN ISO13849-1
Beginnend mit der Spezifikation lässt sich für die Generierung der sicherheitsrelevanten Applikationssoftware das vereinfachte V-Modell anwenden. Eine modulare und strukturierte Programmierung gehört auch zu den grundlegenden Prinzipien zur Fehlervermeidung und -beherrschung ebenso wie die Validierungsplanung der programmierten Sicherheitsfunktionen unter den möglichen Betriebszuständen. Anpassungen an der sicheren Applikationssoftware stellen im Projektverlauf keine Seltenheit dar. Deshalb ist die normative Anforderung zur Definition von geeigneten Entwicklungsaktivitäten hinsichtlich der Softwareänderung sehr gut nachvollziehbar. Neben den zuvor genannten Basisanforderungen gibt es weitere zusätzliche Anforderungen, die ab dem Performance Level PLr c verlangt werden.
Softema-Tool zur Umsetzung normativer Rahmenbedingungen
Die Abfrage, ob die Anforderungen gemäß DIN EN ISO13849-1 umgesetzt worden sind, ist ebenfalls in den Softwareassistenten Sistema des Instituts für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung (IFA) integriert. Dort lautet die Abfrage wörtlich: „…sicherheitsbezogene Software nach Abschnitt 4.6 entwickelt bzw. keine Software vorhanden“. Von den Anwendern wird die Realisierungsabfrage häufig schnell mit einem Häkchen bestätigt. Im Rahmen seiner Service-Dienstleistungen hat das Team des Competence Center Services von Phoenix Contact allerdings festgestellt, dass diese Anforderungen nur teilweise oder gar nicht umgesetzt worden sind. Dies hat das IFA erkannt und abgesehen vom Softwareassistenten Sistema für die sicherheitsrelevante Hardware seit März 2022 eine kostenfreie Software für die normativen Softwareanforderungen bereitgestellt: Softema. Der Softwareassistent Softema basiert auf einer Matrixmethode, mit der die Verschaltung der Sicherheitslogik und alle erforderlichen Validierungsaktivitäten spezifiziert werden. Eine eingebaute Benutzerverwaltung ermöglicht eine rollenbasierte Bearbeitung des Softema-Projekts und bietet so auch Schutz vor unberechtigten Änderungen.
Mit Softema erhalten die Anwender eine Methodik zur Realisierung der Anforderungen gemäß DIN EN ISO13849-1. Ergänzend zu den projektspezifischen Softema-Daten, wie der Cause&Effect-Matrix, stehen projektübergreifende Stammdaten zur Verfügung, die für weitere Softema-Projekte übernommen werden können. Dabei handelt es sich beispielsweise um die Programmierregeln, Personendaten und die Beschreibung der Funktionsbausteine. Interessierte Anwender können die Handhabung des Softwareassistenten in den Softema-Kochbüchern nachlesen. Darüber hinaus bieten Phoenix Contact und andere Unternehmen bereits Softema-Seminare an, in denen das Handling an praktischen Beispielen erlernt wird.
Erkennung systematischer Fehler
Ab einer gewissen Anzahl und Komplexität der Sicherheitsfunktionen erweist sich der Einsatz einer programmierbaren Sicherheitssteuerung gegenüber dem klassischen Sicherheitsrelais als vorteilhaft. Die Programmierung der Sicherheitssteuerung unter Berücksichtigung der normativen Anforderungen gibt dem Anwender eine Hilfestellung, systematische Fehler bei der Erstellung der sicherheitsrelevanten Applikationssoftware frühzeitig zu detektieren. Auf diese Weise lassen sich gefahrbringende Situationen im Arbeitsalltag vermeiden. Es ist also notwendig, die normativen Anforderungen in den Entwicklungsprozess zu integrieren.
Die Maschinenrichtlinie fordert die Einhaltung der Sicherheits- und Gesundheitsschutzanforderungen. Dazu gehört auch die ordnungsgemäße Integration von Sicherheitsfunktionen als risikomindernde Maßnahme. Kommt dabei sicherheitsrelevante Applikationssoftware zum Einsatz, ist dies ein entscheidender Faktor für die Zuverlässigkeit der Sicherheitsfunktion. Anwender sind aber oftmals unsicher, wie die normative Entwicklung und Prüfung der sicherheitsrelevanten Applikationssoftware gestaltet werden muss. Phoenix Contact bietet deshalb entsprechende Dienstleistungen an, die auf verschiedene Weise unterstützen. Abgedeckt wird ein breites Spektrum von der Schulung bis zur Erstellung der kompletten Nachweisdokumentation inklusive der Validierung und Wirksamkeitsprüfung der Sicherheitsfunktion. Die Grundlage hierfür bilden die normativen Anforderungen der DIN EN ISO13849-1.
