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. Im Zuge einer Smart-Factory-Potenzialanalyse für ihren Kunden KSB identifizierte die Managementberatung NEONEX Opti mierungschancen bei der Beschaffung der Lieferantendokumentation sowie der Erstellung von Unterlagen zur Qualitätsprüfung entlang der Supply-Chain. ‣ weiterlesen
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
NEONEX, Fabasoft Approve & KSB: „Win-win-win-Situation“ durch starke Partnerschaft
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
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.
