Parametrieren statt Programmieren

Für sichere Maschinen und Anlagen braucht es eine zuverlässige Sicherheitssoftware. Ob diese fehlerfrei und normgerecht umgesetzt ist, lässt sich über eine Validierung feststellen – ein Prozess, der auf den ersten Blick aufwändig und kompliziert erscheint. Doch es geht auch einfach und übersichtlich, zum Beispiel mit einer strukturierten Vorgehensweise auf Basis der Normen EN ISO 13849 und EN 62061.

Ob eine Maschine sicher und fehlerfrei umgesetzt ist, entscheidet sich auch durch die Validierung der Sicherheits-Software. Die damit verbundenen Anforderungen sind jedoch sehr hoch, was den Validierungsprozess schnell kompliziert macht. Um hier den Überblick behalten zu können, ist eine strukturierte Vorgehensweise hilfreich, die sich bestenfalls an aktuell gültigen Normen orientiert. Besonders relevant sind in diesem Zusammenhang die EN ISO 13489 und EN 62061, die sich beide mit der Zuverlässigkeit sicherheitsrelevanter Steuerungssysteme befassen. Sie kommen dann zum Tragen, wenn der Konstruktionsprozess der Maschine soweit fortgeschritten ist, dass über die notwendigen Sicherheitsfunktionen nachgedacht werden muss.

Sowohl die EN ISO 13489 als auch EN 62061 berücksichtigen die Anwendung programmier- und parametrierbarer Systeme und die Erstellung sicherheitsrelevanter Software. Der Aufwand für den zwingend erforderlichen Verifikations- und Validierungsprozess wiederum hängt dabei nicht nur vom geforderten Performance Level, sondern auch von der Entwicklungsplattform und der Art der Software ab. Hier wird grundsätzlich zwischen Anwendersoftware (Sraws), Embedded Software (Srews) und Parametrierung unterschieden, für deren Entwicklung unterschiedliche Anforderungen gelten, je nachdem, welche Programmiersprache verwendet wird. Anwenderbezogene Sicherheitsfunktionen für eine Maschine werden für gewöhnlich mittels Low Variability Language (VL), das heißt in einer applikationsorientierten Sprache, umgesetzt. Hier greifen die Vorgaben der EN 13489. Die Programmierung von Embedded Software erfolgt üblicherweise mittels Full Variability Language (FVL), und unterliegt damit den sehr komplexen Anforderungen der Sicherheitsgrundnorm IEC 61508.

Fehler vermeiden
Im Umgang mit sicherheitsrelevanter Software liegt der Fokus grundsätzlich auf der Vermeidung von Fehlern. Wichtig zu wissen ist in diesem Zusammenhang, dass es sich bei Softwarefehlern nicht um zufällige Fehler handelt. Vielmehr sind diese von Anfang an vorhanden und können in allen Projektierungsphasen – von der Spezifizierungsphase über die Entwurfs- und Codierungsphase bis hin zur Implementierungs- und Änderungsphase – entstehen. Darüber hinaus ist der Zeitpunkt der Fehlfunktion ungewiss. Insbesondere bei komplexen Programmen kann nicht prognostiziert werden, zu welchem Zeitpunkt Fehler auftreten. Besonders heikel ist die Angelegenheit bei denjenigen Funktionen, die nur für den Störfall oder für Sonderfälle programmiert wurden. Zusätzliches Fehlerpotential entsteht außerdem durch personenbezogene Faktoren wie mangelnde Kenntnisse, falsche Erfahrungs- und Verantwortungswahrnehmung, Defizite in der Organisation, Bedienfehler oder Stress bei der Erstellung.

Im Gegensatz zu zufälligen Hardwarefehlern, die in der Regel beherrscht werden müssen, geht es bei Software-Fehlern darum, diese gar nicht erst ins Programm hinein zu bringen. Ein Weg führt zum Beispiel über eine gut strukturierte und dadurch verständliche, einfach lesbare, test- und pflegbare Software (Sraws). Dies ist ein Vorteil für alle Projektbeteiligten und es ist zu erwarten, dass dadurch weniger Fehler eingebracht werden. Alternativ gibt es die Möglichkeit, bestimmte Funktionen nicht selbst zu schreiben, sondern bereits zertifizierte Funktionsbausteine einzusetzen. Hier gilt es abzuwägen, ob dieser Baustein genau das erfüllt, was benötigt wird und wie sich das Ganze preislich darstellt. Da ein zugekaufter Funktionsbaustein bereits zertifiziert ist, lässt sich die Validierung einsparen. Personenbezogenen Fehlern wiederum kann durch Fachschulungen der Mitarbeiter sowie durch richtiges Personal-, Projekt- und Zeitmanagement entgegengewirkt werden.

Strukturiertes Vorgehen mit dem V-Modell
Die DIN EN ISO 13849 stellt qualitative Anforderungen an sicherheitsbezogene Software, und zwar nicht nur während der Erstellung, sondern während des gesamten Lebenszyklus der Software. Dies betrifft sowohl die vom Maschinenbauer zugekaufte Software, als auch die vom Maschinenbauer erstellte Applikationssoftware. Die Vorgehensweise bei der Programmerstellung wiederum orientiert sich am sogenannten V-Modell, einem Vorgehensmodell, das die Entwicklung aus technischer und funktionaler Sicht betrachtet und Qualitätssicherungsmaßnahmen definiert. Es visualisiert die Gegenüberstellung von Validierung und Verifikation und stellt damit zwei wichtige Fragen: Leistet das System das, was die Anwendung verlangt, und erfüllt das System die Spezifikation? Während die Validierung also die Anwendung beleuchtet, betrifft die Verifikation das Engineering bzw. die Entwicklung. Dieser kleine aber feine Unterschied wird selbst in der Normung nicht unbedingt sauber auseinandergehalten und sollte mit mehr Sorgfalt behandelt werden.

Egal, wie klein oder groß das Programm auch ist – ein strukturiertes Vorgehen auf Basis des V-Modells macht die Software-Erstellung überschaubar. Dies beginnt bei der Spezifikation der Funktionen, was in der Praxis aus Zeitmangel oftmals nicht so gründlich betrieben wird, wie es sein sollte.  Aus der Spezifikation wird ein Entwurf abgeleitet, daraufhin einzelne Module entworfen und erst dann programmiert bzw. codiert. Im Anschluss werden die einzelnen Module getestet, zusammengesetzt und schließlich das gesamte Programm validiert. Für den Fall, dass zertifizierte Funktionsbausteine eingesetzt werden, verkürzt sich das Verfahren, da die Module bereits validiert sind. So gilt es im Systementwurf zu beschreiben, welche Funktionsbausteine eingesetzt werden sollen und deren Integration mit den anderen Bausteinen und der Hardware zu überprüfen.

Programmiersoftware gegen Fehler
Inwiefern sich mit vorgefertigten Funktionsblöcken Zeit sparen lässt und Fehler vermieden werden können, zeigt beispielsweise Wieland Electric im Rahmen seiner Programmiersoftware Samos Plan, die für die modulare, kompakte Sicherheitssteuerung Samos Pro zur Verfügung steht. Das lizenzfreie, intuitive Tool verfügt über eine umfangreiche Bibliothek mit applikationsspezifischen, TÜV-zertifizierten Funktionsblöcken, die typische, applikationsspezifische Sicherheitsfunktionen beinhaltet. Durch das einfache Handling per Drag & Drop – ganz nach dem Motto „Parametrieren statt Programmieren“ – werden der Engineering-Aufwand, die Projektierungszeit und auch die Fehlermöglichkeiten deutlich reduziert.

Eines der Kernmerkmale von Samos Plan ist die Offline-Simulation. Diese erlaubt es, die programmierte Logik bereits am PC zu simulieren, so dass die implementierte Logik überprüft werden kann. Darüber hinaus kann mit einer Oszilloskop-Funktion eine Langzeit-Aufzeichnung erstellt werden, um Fehler im Betrieb schnell zu identifizieren. Auch die Dokumentation wurde berücksichtigt: Samos Plan erstellt auf Knopfdruck einen mehrsprachigen Report über die implementierte Hardware und die erstellte Logik-Funktion sowie einen Verdrahtungsplan.