ISO 13849 – Funktionale Sicherheit nach Kochrezept

ISO 13849 bedeutet Funktionale Sicherheit nach Kochrezept zugeschnitten für den Anwendungsbereich „Maschine“. Dabei handelt sich um eine harmonisierte Norm für Anwender und bildet den Standard für den Sicherheitsnachweis nach Maschinenrichtlinie (MRL) für Maschinen. Am 01.01.2012 wurde die Vorgängernorm EN 954-1, die seit 1996 im Bereich Maschinensicherheit die Auslegung von sicherheitsrelevanten Steuerkreisen beschrieb, durch die EN ISO 13849 ersetzt. Die ISO 13849 erlaubt Funktionale Sicherheit mit bzw. durch unterschiedliche Technologien wie z.B. pneumatische, hydraulische, elektromechanische Systeme und wie die anderen Normen auch, elektrisch, elektronisch, elektronisch programmierbare Systeme.

Im Vergleich zu anderen Sicherheitsnormen ist die ISO 13849 eher praktisch bzw. pragmatisch jedoch deshalb auch konservativ. Dies bedeutet, dass komplexe Technologien in programmierbar elektronischen Systemen nur bis PL d nach Kochrezept behandelt werden können. Intelligente und komplexe Machinensteuerungen mit softwarelastigen Funktionen sind mit der nicht harmonisierten Sicherheitsgrundnorm IEC 61508 besser bedient. Es besteht auch die Möglichkeit Subsysteme innnerhalb der ISO 13849 zu integrieren (Anwender der ISO 13849 ist dann der Integrator) und Subsysteme nach anderen harmonisierten Standards/Normen wie z.B. IEC 62061 für sicherheitsbezogene Steuerungen zu integrieren.

Die EN ISO 13849 ist in zwei Teile normativ aufgeteilt, unter dem Titel Sicherheit von Maschinen – Sicherheitsbezogene Teile von Steuerungen:

• Teil 1: Allgemeine Gestaltungsleitsätze
• Teil 2: Validierung

Allgemeine Begriffe zur Funktionalen Sicherheit:

• Ausfall (failure): Unfähigkeit eines Systems oder Komponente zu einem bestimmten Zeitpunkt (Ereignis) die Sicherheitsfunktion oder Teile davon auszuführen.
• Fehlerzustand (error): Abweichung von gewünschten Zustand.
• Störung (fault): Ereignis, welche ein System in einen unerwünschten Zustand versetzt.
• Ausfallart (failure mode): Art, in welcher ein Element ausfallen kann (z.B. Stuck-at = in einem statischen Zustand verharren).
• Ausfallrate (failure rate): Wahrscheinlichkeitsdichte eines Ausfalls geteilt durch die Wahrscheinlichkeit des Überlebens eines Hardware-Elements.
• Gefährdung (hazard): ein Zustand oder eine Menge von Bedingungen eines Systems, welches zu einem Schaden führen kann.
• Risiko (risk): Grad einer Gefährdung bzw. Kombination der Wahrscheinlichkeit des Eintritts eines Unfalls.
• Restrisiko: verbleibendes bzw. tolerierbares Risiko, nachdem Schutzmaßnahmen ergriffen wurden.
• Risikoanalyse: Festlegung der Grenzen der Maschine und Identifizierung potenzieller Gefährdungen.
• Risikobewertung: Bewertung von Gefährdungen aus der Risikoanalyse vor und nach der Anwendung/Konzeption von Sicherheitsfunktion im Hinblick auf das erreichte Restrisiko.
• Risikobeurteilung: Gesamtverfahren von Risikoanalyse und Risikobewertung.

Begriffe nach EN ISO13849-Teil 1- Abschnitt 3:

• SRP/CS (Safety Related Part of Control System): Teil einer Steuerung, das auf sicherheitsbezogene Eingangssignale reagiert und sicherheitsbezogene Ausgangssignale erzeugt.
• Sicherheitsfunktion: Eine Maschinenfunktion. Ein Ausfall dieser Funktion führt i.d.R. zur unmittelbaren Erhöhung von Risiken.
• Kategorie (Category): [B,1,2,3,4] Einordnung der sicherheitsbezogenen Teile einer Steuerung bezüglich ihrer Architektur bzw. Widerstandes gegen Fehler bzw. Fehlerverhaltens, das erreicht wird durch die Struktur der Anordnung der Teile, der Fehlererkennung und/oder ihrer Zuverlässigkeit(Güte).
• DC (Diagnostic Coverage): Maß für die Wirksamkeit der Diagnose, die bestimmt werden kann als Verhältnis der Ausfallrate der bemerkten gefährlichen Ausfälle und Ausfallrate der gesamten gefährlichen Ausfälle.
• MTTFd (Mean Time to Dangerous Failure): Mittlere Zeit bis zum gefährlichen Ausfall eines Kanals.
• PFH oder PFHd (Probability of dangerous failure per hour): Wahrscheinlichkeit eines gefahrbringenden Ausfalls pro Stunde
• Ausfall infolge gemeinsamer Ursache (Common Cause Failure-CCF): Ausfälle verschiedener Einheiten aufgrund eines einzelnen Ereignisses, wobei diese Ausfälle nicht auf gegenseitiger Ursache beruhen.
• Performance Level (PL): Diskretes und anteigendes Level [a,b,c,d,e] welches die sicherheitstechnische Leistungsfähigkeit von sicherheitsbezogenen Teilen einer Steuerung angibt im Hinblick auf eine Sicherheitsfunktion unter vorhersehbaren Bedingungen. Der PL ist in bekannte Sicherheitsintegritätslevel wie SIL (IEC 61508) bzw. SIL CL (IEC 62061) überführbar. Man spricht auch von Qualität der Risikoreduzierung.
• erforderlicher Performance Level (PLr): Top-Level-Spezifikation, welches die erforderlichen Aufwände in der Entwicklung sowie die Systemstruktur in der ISO 13849 vorgibt. Dieser wird nach der Risikobeurteilung als Attribut der erforderlichen Sicherheitsfunktion festgelegt. Es ist quasi ein Maß für die erforderliche Risikominderung je Sicherheitsfunktion bzw. erforderliche Integrität, welche erreicht werden muss im Hinblick auf die Ausfallwahrscheinlichkeit (Grad der Zuverlässigkeit) und Vermeidung systematischer Fehler in der Entwicklung.

Aller Anfang ist der Sicherheitsplan

Die Norm ISO 13849 fordert Funktionale Sicherheit zu planen und zu dokumentieren. Eine systematische Vorgehensweise bei der Realisierung eines sicherheitsrelevanten Steuerungssystems (SRP/CS) kann nur durch einen Plan sichergestellt sein. Alle Aktivitäten werden im Sicherheitplan dokumentiert. Von der Gefährdungs- und Risikoanalyse (GuR), also der Risikobeurteilung bis hin zur Realisierung und Validierung (ISO 13849 Teil 2) ist alles zu planen. Nur so erhält man einen gerichtsfesten Sicherheitsnachweis. Der Plan berücksichtigt auch den Sicherheitslebenslauf. Auch wenn die ISO 13849 den Fokus auf die Entwicklung legt, sind durch die übergeordnete Maschinenrichtlinie (MRL) und die ISO 12100 auch die Phasen nach der Entwicklung wie z.B. die Transport, Inbetriebnahme, Instandhaltung und Außerbetriebnahme zu berücksichtigen. Daher planen Sie ganzheitlich, dies erspart einige teure Korrektumaßnahmen. Generell ist der Planung noch vor der Entwicklung die wichtigste Phase. Alles andere ist nur noch das Ausführen oder das iterative Korrigieren. Die Vorgehensweise, Strategie und Verantwortlichkeiten werden im Plan festgelegt.

Bedenken Sie auch die Anwendung der IEC 60204-1. Wenn Sie die ISO 13849 anwenden, so ist i.d.R. auch die IEC 60204-1 (elektrische Sicherheit) ergänzend unter der MRL anzuwenden.

Von der Idee zur Gefährdung und Risikobeurteilung

Sie haben eine Idee zu einer Maschine oder sogar schon ein Konzept oder die Maschine hat die Konkurrenz bereits im Markt ? Gut, denn dann können Sie mit diesen Informationen viel Zeit sparen! Aller Anfang in der Funktionalen Sicherheit ist die Item-Definition, also die vollständige Beschreibung der bestimmungsgemäßen Funktion(en) der Maschine in ihrer Betriebsumgebung mit räumlichen und zeitlichen Grenzen. Dies inkludiert auch die Betriebsarten. Im Einrichtbetrieb sind i.d.R. mehr Gefahrenpotenziale zu erwarten als im Normalbetrieb.

Funktionen beschreiben bedeutet KEINE technischen Details oder Lösungen aufzuzeigen. Abstraktion ist erforderlich und ein Team, welches diese Abstraktion in der Analyse auch einhalten kann. Einen Blick für Gefährdungen hat die Fachkraft für Arbeitssicherheit. Nehmen Sie diese mit ins Team bei der Identifizierung der Gefährdungen. Ein Blick in die ISO 14121 Teil 1 ist empfehlenswert. Wenn Sie die Funktion beschrieben und Anwendungsszenarien (Use-Cases) gefunden haben, fassen Sie die gemeinsamen Gefahrenmerkmale zusammen. Diese Gefahren können dann in der Risikoeinschätzung mittels Risikograph im Team eingeschätzt werden.

Wichtig ist, dass die Funktion und deren Gefährdungen ohne Sicherheitsfunktion(en) bzw. Sicherheitseinrichtungen betrachtet werden. Dann beginnen Sie mit einem Gesamtsicherheitskonzept. Diesem liegt ein iterativer Gestaltungs- und Bewertungsprozess zugrunde. Ziel ist es eine wirtschaftlich und ergonomisch angemessen Risikominderung zu erreichen, wie es nach PLr erforderlich ist. Ist das nicht pragmatisch ? Dazu nehmen Sie die ISO 12100 (Risikobeurteilung nach MRL) und gehen iterativ den typischen „Dreiklang“ der Risikominderung  durch.

Schritt 1: Bauen Sie die Maschine so sicher, wie es ein gewissenhafter Ingenieur es so macht. Dies wird durch inhärent sichere Konstruktionen erreicht. Gefährdungen wie z.B. Quetschen könnte man durch eine Abdeckung aus Metall und Anpassung des Arbeitsprozesses evtl. vermeiden.

Schritt 2: Fügen Sie technische Schutzmaßnahmen bzw. ergänzende Schutzmaßnahmen hinzu. Dies sind Sicherheitsfunktionen (SF), Schutztüren oder Lichtschranken. Diese technischen Schutzmaßnahmen sind der Kern, auf welchem die ISO 13849 – Funktionale Sicherheit angewendet wird. Ergänzende Schutzmaßnahmen sind rein funktional nach IEC 60204 Teil 1 zu behandeln und sind i.d.R. keine SF mit einem PL im Sinne der ISO 13849.

Schritt 3: Benutzerinformationen. Geben Sie mit Warnhinweisen und Schildern an der Maschine sowie in der Betriebsanleitung alle Hinweise und Informationen zum sicheren Umgang mit der Maschine. Die Betriebsanleitung ist das wichtigste mitgeltende Dokument und muss zum Lieferumfang gehören in passender Sprache.

Wenn Sie die erforderlichen Sicherheitsfunktionen festlegen und deren Eigenschaften spezifiziert sind, kann der erforderliche Performance Level (PLr) je Sicherheitsfunktion ermittelt werden. Beachten Sie, dass jede Sicherheitsfunktion nur einen (Teil)Beitrag zur Risikominderung der Maschine leistet. Inhärent sichere Konstruktionen, technische Schutzmaßnahmen wie Sicherheitsfunktionen und Benutzerinformationen sind ganzheitlich zu betrachten im Gesamtsicherheitskonzept.

Entwurf & Realisierung der Sicherheitsfunktion

Sie haben die Sicherheitsfunktion und grundlegende Eigenschaften festgelegt sowie den erforderlichen PLr ermittelt ? Dann folgt die Realisierung in strukturierter Arbeitsweise. Die SF muss den Lebensphasen der Maschine entsprechend ausgelegt werden. Die Entwicklung der Software erfolgt nach V-Modell und die Verifikations- und Validierungsaktivitäten sorgen für Konsistenz und Eignung während der Entwicklung bzw. bei der Integration. Nebenbei wird es etwas Abschätzungsrechnungen geben müssen zur Ausfallwahrscheinlichkeit. Doch zuerst ist die Sicherheitsanforderungspezifikation der SF weiter zu detaillieren und die grundlegende Architektur/Kategorie ist festzulegen.

Die Sicherheitsfunktion muss alle erforderlichen Eigenschaften aufweisen, um die Risikominderung angemessen umzusetzen. D.h. sie müssen z.B. das Zeitverhalten spezifizieren, Betriebsarten oder dynamisches/statisches Leistungsvermögen wie z.B. die Einschaltdauer, Reaktionszeiten, Diagnosen und deren Intervalle usw. Eine korrekte, vollständige und eindeutige Spezifikation ist ein grundlegender Aspekt, um systematische Fehler zu vermeiden. Hier können Sie einiges an Zeit benötigen! Oft wird die Top-Level-Spezifikation der Sicherheitsfunktion mit sogenannten Sicherheitszielen beschrieben. Beispiel ist „Im erkannten Fehlerfall muss die SF1 den sicheren Zustand xyz anfordern innerhalb von …ms.“ oder „Die SF1 muss Objekte mit der Geometrie nach Norm ABC mit der Reflektionseigenschaft > xyz [Einheit] erkennen.“ Es sind i.d.R. physikalische Größen wie Zeit, Intensität, Kräfte/Drehmonente oder Kapazitäten in den Top-Level-Sicherheitsanforderungen enthalten.

Es folgt ein Blockdiagramm für das sicherheitsbezogene System (SRP/CS), welches die Sicherheitsfunktion ausführt. Sensor (Erfassung), Logik (Auswertung) und Aktor (Reaktionseinheit/Ausgang) [S-L-A oder I-L-O] sind bildlich darzustellen. Das Blockschaltbild sollte eine der vorgesehenden Architekturen entsprechen. Haben Sie ein PLr = d ist z.B. eine zweikanalige Architektur bereits im Blockschaltbild erkennbar. Weiterhin sind je Block die Sicherheitskennzahlen, sofern bereits bekannt, aufzutragen. Das schwächste Glied in der Kette bestimmt das Fehlverhalten. Je nach Definition der Sicherheitsfunktion und Festlegung der Kategorie, kann sich die Blockstruktur verändern und damit auch die Berechnungen zur Ausfallwahrscheinlichkeit beeinflussen.

Vorgesehene Architekturen & Kategorien

Kein Kochrezept funktioniert ohne Prinzipien oder Randbedingungen. Daher haben sich die Autoren der ISO 13849 für die vorgesehene Architekturen und Kategorien entschieden. Hintergrund sind immer wieder vorkommende, gleichartige Strukturen, welche die beiden Kernziele der Funktionalen Sicherheit unterstützen. Diese Kernziele sind die Verminderung der Ausfallwahrscheinlichkeit durch zufällige Hardwarefehler, sowie die Vermeidung systematischer Fehler während der Entwicklung. Die gleichartigen Strukturen sind die vorgesehenen Architekturen, welche in Kategorien aufgeteilt sind. Die Kategorien sind bezeichnet als B, 1, 2, 3, 4. Sie bauen aufeinander auf und haben ein charakteritisches Systemverhalten und eine typische Struktur.

Kategorie B und 1 sind im Wesentlichen durch sorgsame Auswahl der Bauteile und Funktionsausfall bei Bauteilversagen charakterisiert (keine Diagnosen). Grundlegende bzw. bewährte Sicherheitsprinzipien nach ISO 13849 Teil 1 Anhang G (z.B. Energieabschaltung, Energieversorgungsschwankungen (s. auch IEC 60204-1), Umgebungseinflüsse, PAK usw…) sind anzuwenden.

Kategorie 2 fordert aufbauend auf den grundlegenden und bewährten Sicherheitsprinzipien von Kategorie B und 1 auch eine regelmäßige Testung der Sicherheitsfunktion durch eine Testeinrichtung (TE) bzw. ein niedrigen Diagnosedeckungsgrad (DC=LOW). Dies erfordert strukturell eine externe Testeinrichtung. Weiterhin sind Maßnahmen gegen Fehler gemeinsamer Ursache erforderlich. Die Bauteilgüte bestimmt die Ausfallwahrscheinlichkeit der Sicherheitsfunktion. Man kann mit Kategorie 2 ein PL d noch erreichen. Dieses Vorgehen ist nicht pauschal empfehlenswert und abhängig von dem Anwendungsfall. Die Testeinrichtung muss bei PL d und positiver Fehlerdiagnose der Sicherheitsfunktion den sicheren Zustand der Maschine anfordern.

Kategorie 3 fordert aufbauend auf Kategorie 2 zusätzlich Einfachfehlersicherheit der Sicherheitsfunktion. Eine mittlere Diagnoseabdeckung (DC=MEDIUM) und ein robustes Design in einer 2 kanaligen Struktur (Redundanz) sind typische Merkmale dieser Architektur.

Kategorie 4 fordert aufbauend auf Kategorie 3 zusätzlich Mehrfachfehlersicherheit bzw. eine Diagnose von latenten Fehlern im System, um ein Versagen der Sicherheitsfunktion rechtzeitig zu erkennen. Dies bedingt folglich Bauteile hoher Güte und ein hoher Diagnosedeckungsgrad (DC=HIGH).

Wenn man die Kategorien im Vergleich betrachtet, fällt auf, dass es sich ab Kategorie 3 um ein redundantes, mehrkanaliges System handelt. Dies ist eine typische Schwelle in der Funktionalen Sicherheit im Hinblick auf den Übergang von Sicherheitsintegritätslevel SIL 2 auf SIL 3 nach IEC 61508 bzw. im ISO-13849-Äquivalent das „Perfomance Level“ – kurz PL. Ein PL d entspricht ca. SIL 2, ein PL e entspricht ca. SIL 3.

PI mal Daumen bei der Ausfallwahrscheinlichkeit ?

Ist die Architektur festgelegt, folgt eine Schätzung der voraussichtlich erreichbaren Ausfallwahrscheinlichkeit bzw. die Ermittlung der möglichen Sicherheitskennzahlen [MTTFd,DCavg,Kategorie,PL] je Kanal. Haben Sie ins Regal der großen Hersteller für sicherheitsgerichtete Komponenten gegriffen oder planen dies ? Sehr gut, dann haben Sie alle Daten bereits vorliegen. Wenn nicht ist die Schätzung ohne Erfahrung und nach Kochrezept nur SEHR konservativ möglich. Spätestens wenn der erste Schaltplan vorliegt können Sie mit der Parts-Count-Methode (50%-Methode) oder einer FME(D)A eine Schätzung durchführen. Die Ausfallwahrscheinlichkeiten der Bauteile, sogenannte Roh-Ausfallraten sind aus Bauteilkatalogen zu entnehmen und auf die Anwendung jeweils anzupassen. Im Anhang D der ISO 13849 finden Sie auch einige typische Ausfallraten. Wenn Sie elektromechanische Schalter verwenden, werden Sie über die B10_d-Werte des Herstellers (s. Datenblatt) und die voraussichtlichen Schaltzyklen (n_op = Betätigungen pro Jahr)  die Ausfallrate ermitteln können.

Ziel ist die Restfehlerwahrscheinlichkeit eines Kanals (MTTFd) zu berechnen sowie dessen durchschnittlicher Diagnosedeckungsgrad (DCavg). Wenn sie eine Sicherheitsfunktion mit zweikanaliger Architektur mit Bauteilen mittlerer Güte und mittlerer Diagnoseabdeckung realisieren möchten, so können sie gut ein Performance Level d erreichen. Jedoch müssen Sie diese Architektur auch ausreichend robust gegen Fehler gemeinsamer Ursache (CCF) gestalten. Sie können aber auch der folgenden Grafik entnehmen, dass eine einkanalige Struktur mit Bauteilen höchster Güte ein Perfomance Level d erreichen kann.

Fehlerausschlusses, Annahmen & NEIN sagen ist (k)eine Kunst

Alles ist möglich. Also lassen Sie sich niemals in eine offene bzw. nicht wissenschaftliche Argumentation in der Funktionalen Sicherheit ein! Es ist das GESETZ NR. 1 in der FUSI.

Ein Negativbeispiel zum Thema Argumentation:

• Sie planen eine Kategorie 2 Architektur auf einer Platine mit einem integrierten Schaltkreis (IC) für die Testeinrichtung (TE) und den Funktionakanal (FUN). Dabei argumentieren Sie über die Softwarearchitektur. Sie können und dürfen nicht ausschließen, dass die Sicherheitsfunktion und dessen Testeinrichtung durch einen einzigen Fehler im IC ausfallen. Nun können Sie mit kostenintensiven Aufwand Analysen ausführen oder zertifizierte Hardware einkaufen oder einfach die räumliche Trennung von TE und FUN umsetzen.
• Sie haben ein Fehlerfall in einem beliebigen Hardwarebauteil auf Signalebene einer komplexen Sicherheitsfunktion. Sie argumentieren auf eine Fehlererkennungseigenschaft in den oberen Signalverarbeitungsebenen in der Software. Das Signal ist Teil eines komplexen Datenmodells mit später Fusion auf dem Level einer hohe Abstraktion. Sie können aufgrund iterativer Rechnungen in den Verarbeitungsebenen nicht reproduzierbar durch Testen oder analytisch Nachweisen, dass dieser Fehler sicher erkannt wird. Nur wenn Sie ein ausreichendes SNR zwischen Fehler und Signal in den Verarbeitungsebenen vorweisen könnten, ist überhaupt eine Argumentation möglich. Gehen Sie besser den Weg über eine Low-Level-Diagnose, d.h. eine Testeinrichtung deckt diesen Fehlerfall ab oder sie belasten einfach ihr Restfehlerbudget, wenn dies möglich ist.
• Sie planen eine Sicherheitsfunktion (SF1) mit einer anderen Funktion in einem System zu implementieren. Sie argumentieren über die deutliche Trennung der Funktionen in der Softwarearchitektur. Nun ist jedoch der Zugriff auf Peripherien des Zielsystems (z.B. I/O-Ports) zum Anfordern, Erreichen oder Erhalt des sicheren Zustandes nicht priorisierbar. Die Integrität der Sicherheitsfunktion kann nur durch aufwändige Analysen nachgewiesen werden. Implementieren Sie z.B. einen priorisierten Zugriff der SF1 auf einen unabhängigen Abschaltpfad.

Einige Positivbeispiele wären:

• Sie können eine Leiterunterbrechung bzw. Leiterbahnunterbrechung im Abschaltkanal nicht ausschließen. Sie haben jedoch eine Kategorie 3 Architektur, welche für diesen Fehlerfall in einem Kanal die Fehlertoleranzeigenschaft bereit hält.
• Sie können eine Leiterunterbrechung bzw. Leiterbahnunterbrechung nicht ausschließen. Sie haben jedoch eine Erwartungshaltung für dieses Signal (z.B. Ruhestrom oder Timeout), welches die Fehlererkennungseigenschaft bereit hält.
• Sie können eine Unterbrechung oder eine zufällige Veränderung [50% – 200%] des Nennwertes eines SMD-Metallschichtwiderstandes nicht ausschließen, jedoch ist ein Kurzschluss bei MELF (Zylinderform)-Bauart möglich. Um flexibel zu sein, entscheiden Sie sich alle 3 Fehlerarten in der FME(D)A als möglich und relevant zu erachten. Ein Kurzschluss und eine Unterbrechung wird durch eine Abweichung des Ruhe- bzw. Aktivstroms durch eine Diagnosefunktion erkannt. Die Widerstandsänderung ist rechnerisch nachgewiesen kompensierbar, da es sich bei dem sicherheitsrelevanten Signal um eine ausreichend leistungsfähige Stromquelle handelt.

Vermeidung und Beherrschung systematischer Fehler

Die Ausfallwahrscheinlichkeit durch zufällige Hardwarefehler wird durch quantitative Analysen (z.B. FME(D)A) nachgewiesen. Dabei spielt nur die Bauteilgüte (Ausfallraten der Bauteile) und Systemstrukturmerkmale wie Redunanz (Mehrkanaligkeit) und Toleranz gegen Fehler gemeinsamer Ursache (CFF, z.B. räumliche Trennung) eine Rolle. Das Feld der Maßnahmen gegen systematische Fehler ist dagegen aufwendiger in der Anwendung und im Nachweis.

Der Faktor Mensch ist der Ursprung dieser Fehler. Wir Ingenieure sind auch nur Menschen und machen Fehler. Diese Fehler sind z.B. Dimensionierungsfehler. Sie wollen durch einen niedrigen Ruhestrom in der nächsten Hardware-Revision Energie sparen, haben aber nicht an die erhöhten EMV-Störfestigkeitsanforderungen gedacht ? Oder Sie haben einen logischen Denkfehler und A mit Implikation zu B nicht berücksichtigt im Test ? Oder Sie haben in der Software eine Verklemmung (deadlock), welche den Abschaltkanal unbedienbar machen würde und der sicher Zustand nicht oder nur zu spät eingenommen werden würde ?

Je komplexer die Technologie oder das System, desto höher das Risiko für systematische Fehler. Diese Fehler werden oft in das Produkt hineinentwickelt. Dies gilt es zu verhindern. Dazu müssen die Fehlerquellen bekannt sein und eine Reihe von wirksamen Maßnahmen zur Vermeidung systematischer Fehler angewendet werden. Eine sorgfältige Dokumentation, das 4 Augenprinzip, unterschiedliche Analysemethoden oder das Testen sind solche Maßnahmen, welche im Rahmen der Validierungs- und Verifikationsaktivitäten (V&V-Aktivitäten) ausgeführt werden und im Unfang mit steigendem PL skalieren. Bei höherem PL ist Diversität das (teure) Mittel der Wahl. Unterschiedliche Technologien kombiniert wie z.B. programmierbare Elektronik und Pneumatik erfordern andere Entwicklungsprozesse und Betrachungswinkel bezogen auf eine Sicherheitsfunktion. Dies deckt systematische Fehlerpotenziale auf. Im Automotive-Bereich nach ISO 26262 werden bei ASIL D ( > PL e) ganze Softwareentwicklungsteams räumlich und organisatorisch getrennt mit diversitären Entwicklungs- und Zielumgebungen eingesetzt.

Die ISO 13849 schränkt z.B. die Verwendung von Datentypen und die Anzahl von Eingangs- sowie Ausgangssignalen von Softwareelementen ein. Ab PL e verweist diese direkt auf die IEC 61508 Teil 3! Damit ist dann auch Schluss mit Kochrezept für sicherheitsrelevante Softwareelemente. Es müssen dann umfangreiche Maßnahmen umgesetzt werden. Da im Maschinenbau oft eine speicherprogrammierbare Steuerung (SPS) im Einsatz ist, bietet es sich natürlich an, diese als Safety-Version auch für die Sicherheitsfunktion zu verwenden. Die Software ist dann eher ein Konfigurationsdatensatz wie ST (Strukturierter Text), AWL, KOP oder FUP und keine komplexe selbstprogrammierte Firmware.

Validierung und Verifikation (V&V) – die Beurteilung

Die Verifikation hat zum Ziel, die Ausgaben einer Phase mit den Eingaben auf Konsistenz zu prüfen. Deckt die Sicherheitsanforderungspezifikation den Anwendungsfall vollständig und korrekt ab ? Hat das Schaltungslayout den Schaltplan richtig implementiert ? Die Validierung hat zum Ziel, die vorliegende Eignung im Hinblick auf die Anforderungen in Ihrer Gesamtheit zu beurteilen. Sind die funktionalen und nicht funktionalen Sicherheitsanforderungen erfüllt und entspricht deren Erfüllung den normativen Anforderungen der ISO 13849 ? Verifikation ist die Prüfung oder Analyse von Teilaspekten auf Konsistenz bzw. Zielwerte und Validierung ist die Prüfung des Ganzen auf Übereinstimmung und Eignung.

Die V&V-Aktivitäten sind frühzeitig zu planen (i.d.R. in der Spezifikationsphase) und durch unabhängiges und erfahrenes Personal (Mehraugen Prinzip) auszuführen. Der Unabhängigkeitsgrad ist dem PLr angemessen zu wählen. Schauen Sie dazu auch in den Safety-Basics unter dem Begriff erforderliche Unabhängigkeit mal nach. Die Anforderungen an die Validierung sind in ISO 13849 Teil 2 enthalten. Dabei handelt es sich im Kern um eine Prüfung der sicherheitsgerichteten Eigenschaften. In ISO 13849 Teil 1 ist die Planung zur Validierung enthalten.

Der V&V-Plan sollte folgende Aspekte enthalten:

• Eindeutige Identifikationsmerkmale des SRP/CS und seiner Komponenten/Varianten
• Zusammenhang der Sicherheitsfunktion mit den SRC/CS
• Alle mitgeltenden Dokumente wie Normen, Regeln, Lastenhefte, Spezifikationen des Anwendungsbereiches, interne Regeln/QM-Handbuch/Leitlinien/Richtlinen/Verfahrensanweisungen
• Grundlegende Prüfnormen (auch nicht funktionale wie EN 60068 (Umgebungseinflüsse im Lebenszyklus)
• Analyse- & Prüfverfahren (inkl. Abfolge) (Umgebunsgeinflüsse z.B. über modellbasierte Nachweise usw…)
• Liste vorqualifizierter Komponenten sowie deren Kennzeichnung und Verweis auf Nachweisdokumente (z.B. Zertifikate, Sicherheitshandbücher, Validierungsberichte)
• Fehlerlisten* (s. ISO 13849 Anhang A bis D oder in spezifischen FuSi-Normen (Feldbuss nach IEC 61784-3) oder für Recheneinheiten (DSP,µC,CPUs usw..) in IEC 61508 Teil 2 Anhang A.2 / Tabelle A.1)
• Ergänzende Fehlerlisten* neuer Technologien, welche nicht in ISO 13849 Teil 2 enthalten sind
• Implementierungsstrategie zu den Maßnahmen gegen Fehler gemeinsamer Ursache (CCF)
• Verwendete statische Softwareanalyse-Werkzeuge und dessen Anwendungsfeld (SRESW, SRASW ?) bzw. Testabdeckungsbereich
• Verantwortliches Personal und deren Verantwortungsbereiche
• Prüf- und Betriebsumgebung(en), deren Bedingungen, die Betriebsmittel, Prüfmittel, Hilfsmittel und Ausrüstung, wenn nicht in den V&V-Berichten enthalten
• Die Dokumentation der Ausgaben aus den V&V-Aktivitäten-/Phasen („Ergebnisdokumentation“) wie Prüf- und Testfallspezifikation oder Checklisten
• Bewertungskriterien (Pass/Fail) und die Maßnahmen bei Auffälligkeiten (z.B. Iteration des V-Modells auf Software-Ebene mit neuem Release nach Fail-Kriterium mit Impactanalyse (Einflussanalyse) auf die V&V-Aktivitäten)
• Formale Aspekte eines typischen Dokumentenlenkungsprozesses wie Identifikation, Version, Änderungshistorie, Autor, Verantwortliche Freigabevermerke und Unterschriften

*Fehlerlisten: Listen mit Fehlermodi der grundlegen Fehlermodelle eines kleinsten Bauteils (z.B. Widerstand: hochohmig, niederohmig oder Drift des Nominalwertes um …%).

Erforderliche Eingangs-Dokumente für V&V-Aktivitäten:

• Spezifikationsdokumente an die Sicherheitsfunktion mit Entwurfsanforderungen mit folgenden Merkmalen:
  • Betriebsarten
  • Leistungsmerkmale
  • Eigenschaften
  • Zustands- und Ablauferwartungen
• Bemessungsdaten/Auslegungsdaten im Hinblick auf Bauteile (z.B. aus Normen) bzw. Betriebs- und Umgebungsbedingungen
• Beschreibung der Sicherheitsfunktion in Text und Bild (z.B. Verhaltensdiagramm, Zustands-Übergangs- & Ablaufdiagramm, Sequenzdiagramm usw)
• Übersichts- und Detaildarstellungen aller Technologien zur vollständigen Erläuterung (z.B. Datenblätter, Pläne, Zeichnungen, Tabellen usw…)
• Softwaredokumentation
• Ausfall- und Systemfehlerreaktion des SRP/CS und dessen Komponenten
• Bedienkonzept und HMI-Interaktion (Anwendungsfälle)
• FME(D)A für Einfach- (bis Kat. 3) und FTA für Mehrfachfehler (Kat. 4)
• Beschreibung zu den Fehlertoleranz- und Beherrschungsmaßnahmen (Diagnosen)
• Angewandte grundlegende und bewährte Sicherheitsprinzipien sowie die Liste der CCF-Maßnahmen
• Dokumente zur Herleitung der Sicherheitskennzahlen (Quantifizierung zum erreichten PL durch PFHd,MTTFd,DCavg,CCF) jedes SRP/CS
• Angewandte Gestaltungsregel (PCB-Design, Programmierrichtlinien usw…)
• Nachweise für vorqualifizierte Bauteile/Baugruppen/SRP/CS/bewährte Bauteile usw…) (auch aus andere Normen wie IEC 61508)

Die Validierung, also die Beurteilung des SRP/CS oder Teile davon, erfolgt im Kern durch manuelle oder automatisierte Analyseverfahren. I.d.R. werden die Dokumente manuell durch Review, Walkthrough, Inspection behandelt, während in Bereichen des PCB-Designs, der Softwareanalyse oder der FME(D)A/FTA/Markov oft durch Software-Werkzeuge die Analyse durchgeführt wird. Umgebungseinflüsse sind oft nur in einer modellbasierten Entwicklungsumgebung nachweisbar. Daher ist oft das hybride Nachweisverfahren (Analyse und Prüfung durch systematisches teil- oder vollautomatisches Testen) die wichtigste Validierungsstrategie. Die Messunsicherheiten der Prüfverfahren/Prüfmittel sind zu ermitteln und müssen angemessen sein (S. ISO 13849 Teil 2).

Am Ende der Entwicklung nach ISO 13849 liegt der Validierungsbericht zur Funktionalen Sicherheit vor. In anderen Normen wird dieser auch Safety-Case genannt. In diesem Dokument sind alle gültigen Dokumente referenziert, welche als Bewertungsgrundlage oder zur Bewertung beigetragen haben. Der Bericht gibt über folgende Aspekete der Beurteilungsgrundlagen und Beurteilungsaussagen Auskunft:

• Nachweise über Analyse- und Prüftätigkeiten sowie deren Ergebnisse
• Konsistenz zwischen Spezifikationsdokument und Analyse/Testbericht
• Eindeutige Identifikation des Analyseobjekts (Dokument, Testobjekt usw…)
• Konfigurationsdaten
• Bedingungen, deren Bestätigung sowie Ablauf bei Analyse und Prüfungstätigkeiten
• Aufgezeichnete V&V-Aktivitäten
• Formale Informationen (z.B. Dok-ID, Datum, Unterschrift, verantwortliche Person)

Folgende Verifikationsaktivitäten sind auszuführen:

• Prüfung durch Inspektion und Review durch internen und extern Prüfer, ob die Spezifikation der Sicherheitsfunktion vollständig und korrekt ist, sowie Bewertungskriterien daraus ableitbar sind.
• Prüfung, ob die Kategorie-Anforderungen erfüllt sind durch Struktur- und Signalpfadanalyse und Bewertung der Diagnosen, sowie eine umfangreiche Inspektion der verwendeten Sicherheitsprinzipien, verwendeter betriebsbewährter Bauteile und Fehlerlisten (insb. Ergänzungen und Fehlerausschlüsse). Gegebenenfalls auch Testung bei nicht ausreichender Analysequalität (z.B. Fehlerinjektionstests für erwartete und seltene Fälle, Fehlersimulation)
• Plausibilitätscheck der MTTFd-Werte in der Quantifizierung durch nachvollziehbare Berechnung (Bsp. B10d für elektromechanische Elemente oder die im Katalogen enthaltenen Randinformationen bzw. Korrekturfaktoren)
• Analyse und Testung der Diagnosen, um den Diagnosedeckungsgrad (DCavg) zu Plausibilisieren. Berechnung prüfen, Diagnosefunktion identifizieren, Wirksamkeit bewerten und prüfen durch Fehlerinjektion
• Prüfung der errreichten Punktzahl gem. CFF-Bewertungsverfahren nach ISO 13849-1 Anhang F (Maßnahmen gegen Fehler gemeinsamer Ursache (CFF) mit Punktegewichtung [mind. 65 von 100 Punkten]) sowie der Umsetzung dieser Maßnahmen durch Inspektion (statische HW-Analyse) oder Prüfung (Test bei Umgebungs- bzw. Grenzbedingungen)
• Prüfung, dass der erforderliche Performance Level erreicht wurde. Die Verfifikation, ob PL größer bzw. gleich PLr erreicht wurde, erfolgt anhand der Analyse der Struktur des SRP/CS zusammen mit den ermitteltem Ausfallwerten eines Kanals (MTTFd) bezogen auf eine Sicherheitsfunktion. Dazu wird im vereinfachten Verfahren der erreichte PL durch Vergleich der erreichten MTTFd/DCavg-Werte/Kategorie im Säulendiagramm ermittelt (Diagramm ist Grundlage des vereinfachten Kochrezeptverfahrens mit komplexer Grundlage (Markov-Modell & Kategorien)).
• Analyse, ob die technischen Maßnahmen zur Vermeidung und Beherrschung systematischer Fehler gem. ISO 13849 Teil 1, Anhang G umgesetzt wurden und nachgewiesen sind (Funktionstest im Grenzbereich, Fehlerinjektion an Versorgungselementen (Energie, Takt usw…), Störfestigkeitsprüfung, Funktionsprüfung der Programmablaufkontrolle (PAK)). Inspektion von Datenübertragungssystem-Eigenschaften sowie die Merkmale grundlegender und bewährter Sicherheitsprinzipien in den Entwicklungsdokumenten sowie weiterer Maßnahmen (z.B. Diversität)
• Analyse der Softwarespezifikation durch Inspektion, Entwurf und Codierung u.a. durch statische Codenalyse/Simulation/Modultest sowie integration durch Integrationstest. Wurden die PL-spezifischen Gestaltungsmaßnahmen angewandt ?
• Wenn Parametrierbarkeit oder Programmierbarkeit im SRP/CS gegeben ist, so sind die V&V-Aktivitäten auch auf die SRP/CS-Konfigurationswerkzeuge auszuweiten.
• Prüfung durch Inspektion, Review oder Walkthrough gemäß ISO 13849 Teil 2, Abschnitt 12, ob die technische Dokumentation, welche aus dem Entwicklungs- und Konstruktionsprozess entsteht, den Anforderungen nach ISO 13849 Teil 1 Abschnitt 10.
• Prüfung durch Inspektion/Review, ob die Benutzerinformationen (Verkaufsprospekt, Bedienungsanleitung, Betriebs- und Montageanleitung, das Typenschild und die Instandhaltungsanleitung) die erforderlichen Inhalte nach ISO 13849 Teil 1 Abschnitt 9 und 11 enthalten (Sprache und Form gem. MRL beachten).

Für die Validierung ist:

• die Sicherheitsfunktion und deren korrekte Definition und Umsetzung sowie vollständige Übereinstimmung mit der Spezifikation nachzuweisen durch Funktionstest bzw. Fehlerinjektionstest (Fehlererkennung und Behandlung) / Verhaltenstest / SW-Black-Box-Test / Software-I/O-Test (z.B. verwendet die SW die richtigen HW-Ein- und Ausgänge ?)
• die korrekte Integration der Sicherheitsfunktion an der vollständigen Maschine nachzuweisen (dynamisches Verhalten im Zusmamenspiel mit der Maschine (z.B. Einhaltung von Sicherheitsabständen), Vermeidungsmaßnahmen zu systematischen Fehlern während der Integration (z.B. zuverlässige Erkennung falscher Kombination(en) von Elementen))

Ist die ISO 13849 ein anwendbares Kochrezept ?

Ja, in der Tat. Soweit einige Randbedingungen erfüllt sind, wie es im Maschinenbau üblich ist, wird die Anwendung schnell gelingen. Es sind nur folgenden Kernaktivitäten durchzuführen:

• Festlegen der Risikominderung durch Schutzmaßnahmen (Gefahren erkennen, Risiken bewerten und „Dreiklang“ zur Risikominderung anwenden) (s. ISO 12100 Teil 1)
• Bestimmen des erforderlichen Perfomance Levels (PLr) je Sicherheitsfunktion
• Planung der Vorgehensweise und Aktivitäten für die technische Schutzmaßnahme / Sicherheitsfunktion:
  • Spezifikation, Enwurf, Integration
  • Validierung & Verifikation (V&V)
  • Dokumentation (Projekt und technisch) sowie Benutzerdokumentation
  • Strategie & Konzept zur Funktionalen Sicherheit (Anwendung, sicherer Zustand, Technologieauswahl, Architektur, Maßnahmen zur Vermeidung systematischer Fehler usw..)
  • Festlegen der Verantwortlichkeiten für Entwicklung und Validierung
• Güte der Sicherheitsfunktion durch Berechnung(Schätzung) der Ausfallwahrscheinlichkeit sowie die erreichbare Sicherheitsintegrität festlegen nach folgenden Schritten:
  • Sicherheitsfunktion als Blockdiagramm (SRP/CS) mit vorläufiger Kategorie gem. PLr abbilden mit seinen Teilsystemen (Typisch: Sensor, Logik, Aktor)
  • Festlegen der Teilsystemeigenschaften bezüglich der Sicherheitskennzahlen [MTTFd, DCavg, Kategorie, PL]
  • Festlegen von Make or Buy der Teilsysteme
  • Berechnung (Ausfallratenkataloge oder Hersteller B10d-Werte) oder Ermittlung (s. Hersteller-Datenblatt) der Ausfallwahrscheinlichkeit (PFH) je Teilsystem
  • Addieren der Teilsystem-Ausfallwahrscheinlichkeiten je Kanal zur Gesamtausfallwahrscheinlichkeit des Kanals (PFH = 1/MTTFd_S + 1/MTTFd_L + 1/MTTFd_A)
  • ggf. Kommunikationsausfallraten dazu addieren
  • CCF-Faktor bestimmen (Punktesystem), z.B. 2% Aufschlag auf Gesamtausfallrate
  • Identifizieren des niedrigsten PL bzw. SILs eines Kanals
  • Vergleichen des erreichten PFH mit den PL-spezifischen einzuhaltenden Grenzwert unter Berücksichtigung der Kategorie
  • Ergebnis: Wenn der ermittelte PL UND die ermittelte Ausfallwahrscheinlichkeit (PFH) den erforderlichen PLr erreicht haben, kann entwickelt werden.
• Entwicklung nach Plan mit Verifikation der Sicherheitsanforderungspezifikation VOR Entwicklungsbeginn
• Software nach einfachem V-Modell (s. ISO 13849 Teil 1, Bild 6) oder bei komplexer Software nach IEC 61508 Teil 3 entwickeln
• Validierung durch Test und Analyse durch fachkundige und unabhängige Person durchführen lassen
• Dokumentation nach MRL komplettieren und CE-Konformitätserklärung aufstellen
• Maschine mit der SF und Benutzer-/Anwender-/Integrator-Dokumentation ausliefern
• Hoffentlich mehr als kostendeckenden Umsatz machen und den Sicherheitslebenslauf nach der Entwicklung berücksichtigen!