SIL-Entwicklungen Praxis-Tipp Entwicklungsprojekt zur SIL-Zertifizierung für HMI-Geräte
Mit der IconTrust-Softwaretechnik ist es möglich, in einer sicherheitskritischen Gesamtfunktion nicht-sicherheitsrelevante HMI-Komponenten zu nutzen.
Anbieter zum Thema
Kontinuierlich werden in den letzten Jahren immer mehr funktionale Einzelgeräte miteinander vernetzt, Daten erfasst, ausgewertet und visualisiert. Dies betrifft inzwischen nicht mehr nur Server und PCs, sondern erfolgt bis zu kleinsten Steuerungen und Sensoren. Mit weitreichenden Folgen: Plötzlich sollen nicht-sicherheitsrelevante Komponenten für eine sicherheitsrelevante Gesamtfunktion verwendet werden.
Der Anwender verlangt inzwischen verstärkt vom Zulieferer der Systemkomponenten entsprechende Eignungsnachweise, aus denen er entnehmen kann, ob eine Systemkomponente in seinem sicherheitsrelevanten Anwendungsfall eingesetzt werden kann oder nicht. Ein Eignungsnachweis kann z.B. ein Gutachten nach DIN EN 50126 / 50126 / 50129, IEC 61508 o.ä. sein, das die Eignung der Systemkomponente für ein bestimmtes Einsatzszenario und einen geforderten SIL (Safety Integrety Level) mit einem einzuhaltenden Restrisiko bescheinigt. Was bedeutet dies für den Entwicklungsprozess einer Systemkomponente und dessen Produktdesign für den Zulieferer?
Die o.g. Normen definieren das von einem System ausgehende Restrisiko nach dem MEM-Prinzip (Minimum Endogenous Mortality). Das heißt, dass ein Ausfall der sicherheitsrelevanten Funktion der Systemkomponente die natürliche Sterblichkeitsrate des Menschen (2 x 10-4 Todesfälle pro Jahr und Person) nicht signifikant erhöhen soll. Das Restrisiko wird in der IEC 61508 als PFDavg-Wert (Average Probability of dangerous Failure on Demand) und/oder PFH-Wert angegeben (Average frequency of dangerous failure per hour). Aus diesen Werten kann ein SIL abgeleitet werden. Normalerweise macht diese Risikoanalyse der Kunde und gibt dem Zulieferer ein maximal zulässiges Restrisiko und den benötigten SIL für ein bestimmtes Einsatzszenario vor.
Der IEC 61508-Entwicklungsprozess in der Praxis
In der IEC 61508 ist ein generischer Entwicklungsprozess beschrieben, der Neueinsteiger schnell überfordert. Reduziert man den Prozess auf das für Komponentenhersteller notwendige, ergibt sich ein recht schlanker Entwicklungsprozess (Bild 1: Entwicklungsprozess für Komponentenhersteller). Ist ein passender Entwicklungsprozess in der Firma erst einmal eingeführt, lassen sich Projekte recht schematisch umsetzen, sodass systematische Fehler schon allein durch das „Leben“ des Prozesses verringert werden. Die Durchführung der Produktentwicklung für verschiedene SIL unterscheidet sich dann größtenteils nur noch durch die notwendige Teamstruktur, Systemarchitektur, Test- und Nachweistiefe.
Dafür muss der Hersteller noch nicht einmal unbedingt alle „alten“ Prozesse über Bord werfen. Meist reicht es die bestehenden Prozesse neu zu gruppieren und geringfügig anzupassen. Um die Kommunikation zwischen Hersteller, Gutachter und weiteren externen am Projekt beteiligten Akteuren zu verbessern, sollten die Bezeichnungen der IEC 61508 für Prozessschritte, Artefakte, Kennwerte u.s.w. übernommen werden.
Definition der Sicherheitsanforderung
Eine sicherheitsrelevante Entwicklung nach IEC 61508 ist anforderungsgetrieben. Daher ist es immens wichtig die Sicherheitsanforderungen bei Projektbeginn präzise zu erfassen und möglichst im Projektverlauf nicht mehr zu ändern. Unpräzise, sich widersprechende oder zu komplexe Anforderungen an die Sicherheitsfunktionen eines Systems verteuern und verlängern die Entwicklung signifikant. Jedweder unnötige Ballast sollte vermieden und in einer Abgrenzung des Systems erfasst werden. Hierbei spielen folgende Fragen eine zentrale Rolle: Wann werden Sicherheitsanforderungen erfüllt bzw. nicht erfüllt (EMV, Klima, mechanische Belastungen etc)? Was ist der sichere Zustand des Systems? Gibt es zeitliche Vorgaben (Reaktionszeiten, Prüfintervalle u.a.m.), die eingehalten werden müssen?
Artikelfiles und Artikellinks
(ID:28262550)