Teil 1 der Artikelserie beleuchtete die Normenwelt, beschrieb die einzelnen Normen, deren Zusammenhänge und die von der Norm geforderten formalen Notwendigkeiten. Die Normen der funktionalen Sicherheit – die sich über die Zeit in verschiedene Sektor-/produktspezifische Varianten ausdifferenziert haben – dienen primär dazu, Schäden an Menschen und Sachwerten zu vermeiden. Der Effekt wird statistisch sichtbar, im Optimum durch drastisch reduzierte Werte. Allerdings ergeben sich dabei Ungereimtheiten: So gibt es für den Maschinenbau mit der IEC62061 und ISO13849 zwei gleichberechtigte Normen. Der Systemintegrator kann sich für eine der beiden Normen entscheiden. Für den Komponentenhersteller werden jedoch beide Normen aus Vermarktungsgründen quasi zur Pflicht. Aus der ISO13849 ergeben sich einige zusätzliche Anforderungen an die Produktentwicklung. Am augenfälligsten ist, dass die ISO13849 anstatt des SIL einen sogenannten Performance Level (PL a bis e) definiert. Die grundlegendste Antriebssicherheitsfunktion Safe Torque Off (STO) kann prinzipiell rein hardwarebasiert umgesetzt werden. Die EN61800-5-2 gibt dazu gute Hilfestellung. Interessant hingegen wird es, wenn komplexere Antriebssicherheitsfunktionen gefordert sind. In der Praxis werden derartige Funktionen in Software realisiert. Für Software verweist die Antriebsnorm auf die IEC61508-3. Mit steigendem Sicherheitsintegritätslevel (SIL) werden sehr hohe Anforderungen an die Softwareentwicklung gestellt – wie etwa die verwendeten Methoden und die durchzuführenden Verifikationen, einschließlich der verwendeten Werkzeuge. Das bedingt eine Dokumentation, wie sie Abbildung 1 darstellt.
Der sichere Weg
Teil 2 gab Hilfestellung für frühe SRS-Projektphasen und befasste sich mit der Entstehung und den richtigen Inhalten einer SRS (Safety Requirement Specification). Eine wesentliche Phase jeder Entwicklung im Bereich funktionaler Sicherheit ist das Requirement Engineering, also die Phase der Erstellung der Anforderungen. Die Planung erfolgt in der Regel im überlagerten Functional Safety Management Plan und im Verifikation- und Validierungsplan (V&V-Plan). Im Projekt entstehen dann schrittweise, entlang des linken Astes, die typischen Dokumente SRS, SDRS, Design Spezifikationen für die Hardware und Software und erst am Ende die klassischen technischen Unterlagen, wie Stromlaufpläne und Quellcode.
Toolchain – vom Requirement zum Test Case
Teil 3 der Serie diskutierte den (Software-)Entwicklungsprozess und die Product Lifecycle Managementumgebung, die Dokumentations- und Entwicklungsumgebung, in der, nachvollziehbar und auditierbar, aus Requirements ein nach Regeln der IEC61508 zertifizierbares Produkt entstehen soll. Die Nachvollziehbarkeit von der Anforderung bis zum durchgeführten Test und die überprüfbaren statistischen Aussagen ergeben sich durch die Integration der Tools, also der Werkzeuge. Die Toolchain ist eine Kombination der Prozesse mit diesen Werkzeugen. Allein die Prozesse können den Nachweis und Rückverfolgbarkeit nur schwerlich und mit erheblichem Aufwand generieren. Auch die Toolchain – ohne Integration und definierte Prozesse – kann das nicht leisten. Eine intelligente Integration der einzelnen Werkzeuge kombiniert mit intelligenten Prozessen, die jeweils auf den benötigten Safety Integrity Level adaptiert werden (von Standard Entwicklung ohne SIL Anforderung bis zur SIL3 Anforderung), ist das Mittel der Wahl. Abbildung 2 veranschaulicht das.
FMEA – Fehlermöglichkeit und Einflussanalyse
Mit Qualitätsplanung und System-FMEA im Safety-Projekt haben wir uns in gleich zwei Artikeln beschäftigt (Teil 4 und 5). Deren Anwendung in der Praxis ist oft ein zeitaufwendiges Unterfangen mit einigen Stolpersteinen. Das Ziel der Untersuchung von Fehlermöglichkeit und Einflussanalyse (FMEA) ist zum einen das präventive Erkennen der Zusammenhänge von potentiellen Fehlern, Ursachen und Folgen sowie die Priorisierung der Ursachen-Wirkungs-Ketten bezüglich ihres Risikos. Zum anderen ist es die präventive Einleitung von Abstellmaßnahmen für Ursachen-Wirkungs-Ketten mit hohem Risiko. Abbildung 3 zeigt unterschiedliche FMEA im Produkt Entstehungs-Prozess.
Die System-FMEA im Safety-Projekt
Teil 5 erörterte die Verwendung des Werkzeuges FMEA in der Entwicklung funktional-sicherer Komponenten. Er beschrieb den Schritt von den normativen Anforderungen zur praktischen Anwendung und zog die typischen Anforderungen der Fabrikautomation heran: SIL3, Anforderungsrate High Demand. Abhängig vom zu erreichenden Sicherheitsintegritätslevel macht die Norm konkrete Vorgaben bezüglich der zu erreichenden Hardwarefehlertoleranz (HFT) sowie dem Anteil sicherer Fehler (SFF). Neben fehlersicheren Design-Prinzipien sind Diagnosemaßnahmen der Schlüssel zu einer hohen SFF. Die Tabelle in Abbildung 4 veranschaulicht diesen Zusammenhang. Die Vielfalt und die gegenseitige Abhängigkeit der Einflussfaktoren erschweren gerade Neueinsteigern die Anwendung und führen bei falscher Anwendung oft zu sub-optimalen Ergebnissen. Typische negative Folgen in der Praxis sind die Notwendigkeit von Anpass-Entwicklungen, die erst spät im Entwicklungszyklus erkannt werden. Es ist aber auch Over-Engineering von Sicherheitsmaßnahmen, die zu Lasten der Verfügbarkeit des Produkts gehen und das Produkt unnötig verteuern. Design Packages für sichere Antriebstechnik auf Basis der EN61800-2 minimieren solche Risiken. Neben sehr produktspezifischen Blöcken, wie dem Leistungsteil und der Steuereinheit, eignen sich Funktionsblöcke wie Diagnostic Functions sowie Communication & IO-Block zur Standardisierung als generischer Funktionsblock, der letztlich Zeit, Aufwand und Personal schont und wiederverwendet werden kann. In Form von:
