SoDoQ | Funktionale Sicherheit

Funktionale Sicherheit

Eigentlich kein neues Thema

Funktionale Sicherheit begleitet den Maschinenbau von Beginn an. Ein frühes Beispiel hierfür ist der Fliehkraftregler von Dampfmaschinen. Jeder Konstrukteur hat bewusst oder unbewusst mit dem Thema zu tun und man muss niemanden erklären, dass sich die Sicherheit durch eine doppelte Überwachung erhöht.

Um dem gesetzlich geforderten Stand der Technik zu genügen, müssen die Ausfallwahrscheinlichkeiten von Sicherheitsfunktionen berechnet werden. Die gesetzlichen Anforderungen leiten sich direkt aus der aktuellen Maschinenverordnung (EU) 2023/1230 ab. Dort heißt es:

Steuerungen sind so zu konzipieren und zu bauen, dass es nicht zu Gefährdungssituationen kommt.

Weiter wird ausgeführt, dass Steuerungen insbesondere so ausgelegt und beschaffen sein müssen, dass

sie, wenn den Umständen und Risiken angemessen, den zu erwartenden Betriebsbeanspruchungen sowie beabsichtigten und unbeabsichtigten Fremdeinflüssen, einschließlich vernünftigerweise vorhersehbare böswillige Versuche Dritter, die zu einer Gefährdungssituation führen, standhalten können
ein Defekt der Hardware oder der Software der Steuerung nicht zu Gefährdungssituationen führt
Fehler in der Logik des Steuerkreises nicht zu Gefährdungssituationen führen
die Grenzen der Sicherheitsfunktionen im Rahmen der vom Hersteller durchgeführten Risikobeurteilung festgelegt werden, und keine Änderungen der durch die Maschine oder das dazugehörige Produkt oder den Bediener generierten Einstellungen oder Regeln, auch während der Lernphase der Maschine oder des dazugehörigen Produkts, vorgenommen werden dürfen, wenn solche Änderungen zu Gefährdungssituationen führen könnten
vernünftigerweise vorhersehbare Bedienungsfehler nicht zu Gefährdungssituationen führen
das Rückverfolgungsprotokoll der Daten, das im Zusammenhang mit einem Eingreifen generiert wurden, und der Versionen der Sicherheitssoftware, die nach dem Inverkehrbringen oder der Inbetriebnahme der Maschine oder des dazugehörigen Produkts hochgeladen wurden, bis zu fünf Jahre nach dem Hochladen ausschließlich für den Nachweis der Konformität der Maschine oder des dazugehörigen Produkts mit diesem Anhang auf begründete Anforderung einer zuständigen nationalen Behörde zugänglich ist

Im direkten Vergleich zu der alten Maschinenrichtlinie 2006/42/EG klingen in dieser Liste bereits neue Anforderungen an, die die Cyberresilienz unterstützen und den Einsatz von Künstlicher Intelligenz ermöglichen.

Die Interpretation dieser Anforderungen wird erleichtert durch die Anwendung der harmonisierten Normen EN ISO 60204-1, EN ISO 13849-1 und EN ISO 13849-2. Abgedeckt werden hierbei nicht nur elektrische und programmierbare elektronische Steuerungen, sondern auch die mechanischen, hydraulischen und pneumatischen Komponenten.

Nachweis zur Sicherheit der Steuerung – so wirds gemacht

1) Identifikation der Sicherheitsfunktionen

Welchen Beitrag muss die Steuerungstechnik für die Sicherheit übernehmen?

Im Maschinenbau wird für viele Funktionen Steuerungstechnik verwendet. Die Funktionen, die für die Sicherheit zuständig sind oder die an der Sicherheit beteiligt sind, müssen klar identifiziert und definiert werden. Dies geschieht in der Regel bereits mit der vorgelagerten Risikobeurteilung nach EN ISO 12100. Risiken, die sich nicht durch inhärent sichere Konstruktion lösen lassen, müssen (so weit möglich) durch technische Schutzmaßnamen gemindert werden. Sobald die Steuerungstechnik ins Spiel kommt, wird daraus eine Sicherheitsfunktion.

Sehr hilfreich sind hier Produktnormen (Typ-C-Normen), die häufig bereits die wesentlichen Sicherheitsfunktionen für bestimmte Produkte benennen. Die eigene Risikobeurteilung wird dadurch wesentlich erleichtert. Es muss aber in jedem Fall überprüft werden, ob die Normvorgaben auf die eigene Maschine zutreffen und nicht weitere, individuelle Gefährdungen zusätzlich berücksichtigt werden müssen.

Dieser erste Schritt endet mit der dokumentierten Auflistung der benötigten Sicherheitsfunktionen.

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.

Zur Bearbeitung verwendet SoDoQ Checklisten, die sich in vielen Projekten bewährt haben und Punkt für Punkt den aktuellen Stand Ihres Projektes abfragen und dokumentieren.

Auch in komplizierten Situationen konnten wir durch geeignete Vereinfachungen und konkrete Lösungsvorschläge weiterhelfen. Die SISTEMA-Berechnungen übernehmen wir gerne. Die erste telefonische Beratung ist für Sie kostenlos.

Kontakt