2) Festlegung der geforderten Eigenschaften

Was ist konkret zu tun?

Wie eine Sicherheitsfunktion genau funktioniert, kann sehr unterschiedlich sein. Daher müssen in diesem zweiten Schritt für jede Sicherheitsfunktion die Eigenschaften genauer erklärt werden. Hierzu eine paar Fragen zur Anregung der Diskussion:

• Wie häufig wird eine Sicherheitsfunktion benötigt?
• Was soll abgeschaltet oder begrenzt werden?
• Welche Reaktionszeiten werden benötigt, um noch rechtzeitig einen sicheren Zustand zu erreichen?
• Ist eine Unterscheidung verschiedener Lebensphasen oder verschiedener Betriebsarten (z.B. Automatikbetrieb, Einrichtbetrieb) notwendig?
• Was passiert bei Ausfall der Energie?
• Welche Komponenten bieten sich für die Realisierung der Sicherheitsfunktion bereits an und wie wirken diese zusammen?
• Können fehlerhafte Komponenten erkannt werden und anschließend nach der Erkennung eines Fehlers noch ein sicherer Zustand erreicht werden?
• Müssen andere Sicherheitsfunktionen mit Priorität behandelt werden und entstehen hierbei möglicherweise neue Gefährdungen?

Die Dokumentation der geforderten Eigenschaften ergänzt die im Schritt 1 erstellte Liste der Sicherheitsfunktionen.

3) Bestimmen des erforderlichen Performance Level (PLr)

Wie zuverlässig müssen die Sicherheitsfunktionen sein?

Die erforderliche Qualität einer Sicherheitsfunktion wird durch ihre Ausfallwahrscheinlichkeit beschrieben. Hierbei gibt es verschiedene Qualitätslevel, die in der EN ISO 13849-1 auch als Performance Level (PL) bezeichnet werden.

Nicht jede Sicherheitsfunktion muss von gleich hoher Qualität sein. Kleine Risiken können bereits durch einfache Sicherheitsfunktionen gemindert werden. Hier ist auch eine höhere Ausfallwahrscheinlichkeit akzeptabel. Wenn es aber um Menschenleben geht, dürfen Sicherheitsfunktionen nur sehr selten ausfallen. Die entsprechende Festlegung wird häufig bereits in der vorgelagerten Risikobeurteilung getroffen. Die EN ISO 13849-1 schlägt hierzu im Anhang A einen Risikograph mit den folgenden Risikoparametern vor:

• S – Schwere der Verletzung
• F – Häufigkeit und/oder Dauer der Gefährdungsexposition
• P – Möglichkeiten zur Vermeidung der Gefährdung oder Begrenzung des Schadens
• W – Eintrittswahrscheinlichkeit eines Gefährdungsereignisses

Nach Durchlaufen des Risikographen steht der erforderliche PLr a, b, c, d oder e fest (das r in PLr steht für „required“).

Der o.g. W-Parameter ist bei erfahrenen Anwendern und auch in Normenkreisen sehr umstritten, da die Funktionale Sicherheit ja selbst der maßgebliche Faktor für die Eintrittswahrscheinlichkeit eines Gefährdungsereignisses ist. Bei leichtfertigem Umgang mit dem W-Parameter besteht daher die Gefahr, dass bereits bekannte Risiken bei einer erneuten Risikobeurteilung systematisch zu gering eingestuft werden.

4) Technische Realisierung

Entwurf der Sicherheitsfunktionen

Im Rahmen der technischen Realisierung ist für jede Sicherheitsfunktion festzulegen, welche Komponenten eingesetzt werden und wie diese zusammenwirken. Hierbei sind folgende Kriterien relevant:

• Kategorie der Sicherheitsfunktion (einkanalige oder zweikanalige Architektur)
• Zuverlässigkeit der beteiligten Komponenten
• Diagnose der beteiligten Komponenten, um rechtzeitig Fehler zu erkennen
• Maßnahmen gegen den gleichzeitigen Ausfall beider Kanäle einer zweikanaligen Architektur aufgrund einer gemeinsamen Ursache

Um das Ziel zu erreichen, erlauben die genannten Kriterien verschiedene Wege. Die Anforderungen können durch zuverlässige Komponenten oder alternativ durch eine bessere Architektur erreicht werden. Auch einfache Lösungen aus alten Projekten können hier schon eine gute Grundlage sein.

Einfache Sicherheitsfunktionen mit PLr a, b oder c können mit einer einkanaligen Architektur (Kategorie B oder 1) realisiert werden. Für PLr c gelten hier aber schon Einschränkungen, die genauer betrachtet werden müssen.

Höherwertige Sicherheitsfunktionen mit PLr d oder e benötigen in jedem Fall eine zweikanalige Architektur. Der zweite Kanal ist entweder ein vollwertiger zweiter Funktionskanal (Kategorie 3 oder 4) oder ein Testkanal (Kategorie 2), der bei Erkennung eines Fehlers noch eine rechtzeitige Abschaltung bewirken kann.

Bei den o.g. Punkten handelt es sich um quantifizierbare Aspekte. Hinzu kommen aber noch weitere Anforderungen qualitativer Art, die häufig übersehen werden, z.B.:

• Berücksichtigung von Umgebungsbedingungen
• Anwendung von Sicherheitsprinzipien
• Maßnahmen gegen systematische Ausfälle
• Maßnahmen gegen Fehler in der Software

5) Ermittlung des erreichten Performance Level (PL)

Anwendung von SISTEMA

Um nachzuweisen, dass der geforderte Performance Level (PLr) auch erreicht wird, muss etwas gerechnet werden. Das am häufigsten genutzte Software-Tool ist SISTEMA und wird vom Institut für Arbeitsschutz (IFA) kostenlos zur Verfügung gestellt.

Die zur technischen Realisierung gewählte Architektur (Kategorie) wird hierbei mit den Sicherheitskennwerten der verwendeten Komponenten aufgefüllt. Je nach Bauart und Klassifizierung der Komponenten kommen hier unterschiedliche Sicherheitskennwerte infrage, z.B. PFHd, MTTFd oder B10d.

Außerdem müssen noch die Daten berücksichtigt werden, die von der konkreten Anwendung im eigenen Projekt abhängen, z.B. die Schalthäufigkeit bestimmter Komponenten (nop), die getroffenen Maßnahmen zur Diagnose (DC) und die Maßnahmen gegen den gleichzeitigen Ausfall von zwei Kanälen (CCF).

In der Praxis sind die Schritte 4 und 5 nicht streng getrennt. Jeder Lösungsvorschlag zur technischen Realisierung kann mit SISTEMA kurz überprüft werden.

SISTEMA erreicht den Status Grün nur, wenn auch ein paar „Nebenbedingungen“ angekreuzt werden. Von „Nebenbedingungen“ kann aber eigentlich keine Rede sein, da es sich hier unter anderem um die Einhaltung der wichtigen qualitativen Aspekte handelt (Sicherheitsprinzipien, Maßnahmen gegen systematische Ausfälle, Software-Fehler, etc.). Diese Aspekte sollten separat, z.B. anhand von Checklisten, dokumentiert werden.

6) Verifikation des Performance Level (PL)

Notwendige Überprüfung

Das ist der Schritt, bei dem die Dokumentation und die dort beschriebenen Daten und Maßnahmen überprüft werden müssen. Hierzu gehören z.B. auch dokumentierte Funktionstest an der Maschine, mit Test von Grenzwerten, Überprüfung von Reaktionszeiten, Erzeugung von Fehlerzuständen und Überprüfung von Diagnosemaßnahmen.

In der Praxis werden gerade in dieser Phase noch einige Punkte erkannt, die nachgebessert werden müssen. Es sei daran erinnert, dass es sich um einen iterativen Prozess handelt. Die Nachbesserung ist also kein Makel, sondern ein notwendiger Teil des Gesamtprozesses.

Die Verifikation der Berechnung zeigt, ob der tatsächlich erreichte Performance Level (PL) mindestens den aus der Risikobeurteilung erforderlichen Performance Level (PLr) erreicht.

Auch die bei Schritt 5 bereits genannten „Nebenbedingungen“ und die Software dürfen bei der Verifikation keinesfalls vergessen werden.

7) Validierung

Abschließende Kontrolle

Die Validierung ist noch einmal ein spezieller abschließender Prozessschritt, der mit der Verifikation verwandt ist. Während sich die Verifikationstätigkeiten eher um Überprüfung von Einzelaspekten kümmern, dient die Validierung dem Nachweis, dass die ursprünglichen Anforderungen tatsächlich erfüllt sind. Die Validierung sollte von fachkundigen Personen durchgeführt werden, die unabhängig von der vorangegangenen Gestaltung der Sicherheitsfunktionen sind.

Ausgangspunkt ist hier in der Regel ein Validierungsplan, der schon in der frühen Entwicklungsphase erstellt werden sollte.

Abschluss ist ein Validierungsbericht, der die Ergebnisse der Validierung enthält und die Erfüllung aller relevanten Aspekte bestätigt.

Auch die Validierung ist noch Teil des iterativen Prozesses, d.h. auch von hier kann noch einmal ein Rücksprung in den Gestaltungsprozess vorgenommen werden.

8) Alle Sicherheitsfunktionen bearbeitet?

Zurück zur Risikobeurteilung

Dieser letzte Schritt aus der EN ISO 13849-1 ist schnell erklärt: Wenn alle Sicherheitsfunktionen bearbeitet worden sind, geht es zurück zur Risikobeurteilung nach EN ISO 12100.

Vor der Fortsetzung der Risikobeurteilung wird noch einmal überprüft, ob möglicherweise sogar neue Gefährdungen entstanden sind und ob die Funktionale Sicherheit den ihr zugedachten Beitrag zur Risikominderung geleistet hat.