Praxisansatz aus dem Bereich Bahn & Bus: Sicherheitsnachweisführung für Mensch-Maschine-Schnittstellen

Sensibilisiert durch die neue Maschinenrichtlinie RL 2006/42/EG verlangen Anwender inzwischen verstärkt vom Komponentenzulieferer Eignungsnachweise, aus denen sie entnehmen können, ob eine Systemkomponente in seinem sicherheitsrelevanten Anwendungsfall eingesetzt werden kann oder nicht. Ein Eignungsnachweis kann z.B. ein Gutachten nach DIN EN50126/50126/ 50129, IEC61508 o.ä. sein, das die Eignung der Komponente für ein bestimmtes Einsatzszenario und einen geforderten SIL (Safety Integrity Level) mit einem einzuhaltenden Restrisiko bescheinigt. Bedeutung für den Entwicklungsprozess einer Systemkomponente Die genannten Normen definieren das von einem System ausgehende Restrisiko nach dem Minimum Endogenous Mortality-Prinzip (MEM). Das heißt, dass ein Ausfall der sicherheitsrelevanten Funktion der Komponente die natürliche Sterblichkeitsrate des Menschen (2×10-4 Todesfälle pro Jahr und Person) nicht signifikant erhöhen soll. Das Restrisiko wird in der IEC61508 als PFDavg-Wert (average Probability of dangerous Failure on Demand) bzw. PFH-Wert (Probabilty of Failure per Hour) angegeben. Aus diesen Werten kann ein SIL abgeleitet werden. Normalerweise macht diese Risikoanalyse der Betreiber und gibt dem Zulieferer ein maximal zulässiges Restrisiko und den benötigten SIL für ein bestimmtes Einsatzszenario vor. Der IEC61508-Entwicklungsprozess in der Praxis In der IEC61508 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 2). 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 vermieden werden. Die Durchführung der Produktentwicklung für verschiedene SIL-Stufen unterscheidet sich dann größtenteils nur noch durch die notwendige Teamstruktur, Systemarchitektur, Test- und Nachweistiefe. \’Alte\‘ Prozesse müssen nicht zwangsweise über Bord geworfen werden, oft reicht eine Neugruppierung und geringfügige Anpassung. Um die Kommunikation zwischen Hersteller, Gutachter und weiteren externen, am Projekt beteiligten Akteuren zu verbessern, sollten die Bezeichnungen der IEC61508 für Prozessschritte, Artefakte, Kennwerte usw. übernommen werden. Eine sicherheitsrelevante Entwicklung nach IEC61508 ist anforderungsgetrieben. Das Wichtigste ist, 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. Sicherheitsplan erstellen und implementieren Sind die Sicherheitsanforderungen erst einmal alle bekannt, muss ein Sicherheitsplan erstellt werden, in dem eine, dem SIL-Level angemessene, Auswahl und Umsetzung der in der IEC61508 geforderten Maßnamen festgelegt wird. Anschließend muss ein Projektteam zusammengestellt werden, das den Sicherheitsplan implementiert. Frühzeitig sollte der Anforderungstestplan und die Anforderungstestspezifikation erstellt werden. Diese Dokumente sind die Basis für die abschließende Validation der Anforderungen. Es zeigt sich bei der Erstellung schnell, ob noch weitere Anforderungen an das System, bedingt durch das Testen, existieren und ob alle Anforderungen konsistent und testbar sind. In der Systemarchitekturspezifikation ist konzeptionell festzulegen, dass sicherheitsrelevante Anforderungen möglichst intelligent von nicht sicherheitsrelevanten Anforderungen getrennt und auf unterschiedliche Subkomponenten aufgeteilt werden. Das ermöglicht, z.B. durch Mehrkanaligkeit, eine Reduktion des benötigten SIL für die einzelnen Subkomponenten. Wichtig ist, dass Fehler gemeinsamer Ursache (CCF) vermieden werden. Es muss für eine Rückwirkungsfreiheit zwischen den Komponenten gesorgt werden, da sonst die Reduktion des SIL für eine Subkomponente nicht oder nur bedingt nachgewiesen werden kann. Ein intelligentes Konzept trägt zur Reduktion der Kosten und der Entwicklungszeit bei. Mit der Fixierung des Konzeptes kann das Restrisiko abgeschätzt werden. Jetzt sollte Kontakt mit dem Gutachter aufgenommen werden. Die frühe Prüfung des Konzeptes ermöglicht es, frühzeitig und daher kostensparend fehlende Sicherheitsmechanismen zu ergänzen. Der größte Unterschied zwischen den SIL-Stufen zeigt sich in dem Testaufwand, da von der IEC61508 das automatische Testen teilweise explizit gefordert wird. Ein intelligentes Architekturkonzept zahlt sich in dieser Phase durch massive Einsparungen beim benötigten Testaufwand aus. Neben den Tests ist gegebenenfalls noch eine Sicherheitserprobung im Zielsystem notwendig. Verifikations- und Validationstests durchführen Zu guter Letzt werden alle Ergebnisse der Verifikations- und Validationstests sowie aller anderen qualitätssichernden Maßnahmen in einem technischen Sicherheitsbericht zusammengefasst. Dieser enthält zusätzlich die inzwischen berechneten sicherheitsrelevanten Kennwerte des Systems. Der Gutachter prüft dann, ob das Entwicklungsteam alle nach dem SIL-Level geforderten Maßnahmen umgesetzt hat und der angestrebte SIL-Level erreicht wurde. Das Ergebnis dieser Prüfung wird in einem offiziellen Gutachten festgehalten. Die IconTrust Technik ist ein Beispiel für die flexible Sicherheitsnachweisführung bei HMI-Systemen, die neben vielen nichtsicherheitsrelevanten Daten auch einige wenige sicherheitsrelevante Daten anzeigen. Den Anstoß für die Entwicklung der innovativen Technik gaben gesetzliche Anforderungen an die Sicherheitsnachweispflicht für Anzeige- und Bediensysteme in Fahrständen von Hochgeschwindigkeitszügen. In einem konventionellen Sicherheitskonzept müsste die gesamte Kette aus Applikation, Betriebssystem, CPU, Grafikkarte und Display als sicherheitsrelevant angesehen werden und dementsprechend entwickelt worden sein, mit hohen Entwicklungskosten bei geringerer Flexibilität sowie starken Leistungseinbußen, und für jede Änderung ist eine neue Begutachtung notwendig. Kontroll-Konzept erleichtert die Entwicklung Das IconTrust-Konzept erleichtert die Entwicklung. Die Schaltung prüft, ob auf den als sicherheitsrelevant definierten Anzeigebereichen, die korrekte Information angezeigt wird. Es können mehr als 100, auch überlappende, anwendungsspezifisch konfigurierte Bereiche gleichzeitig und unabhängig kontrolliert werden. Dafür müssen in einer einmaligen Initialisierungskonfiguration die Überwachungsbereiche mit der Menge ihrer erlaubten Anzeigedaten, gegebenenfalls mit erlaubten Abweichungstoleranzen, in einer Referenztabelle in einem FPGA festgelegt werden (Bild 3). Um die PC-Leistung nicht einzuschränken, wird das Datenvolumen durch Verwendungen eines Codierverfahrens gering gehalten, es wird faktisch jedem Soll- und Ist-Anzeigewert ein eindeutiger \’Fingerabdruck\‘ zugeordnet, die in einem zweikanaligen Controller bei jedem Bildwiederholzyklus \’on-the-fly\‘ verglichen werden (Bild 4). Passen sie nicht zusammen wird ein erkennbar sicherer Zustand eingenommen, d.h. eine projekt-individuell einstellbare sicherheitsgerichtete Reaktion ausgelöst. Prinzipiell können alle Arten von separat dargestellten Informationen als Grafik, Symbol, Zeigerinstrument, Text oder Farbcodierung unabhängig und exklusiv überwacht werden. Wenn gefordert, können verschiedene Bildschirmdarstellungen für ein und denselben Wert der Eingangsgröße zugelassen werden. Mit der Konzentration aller sicherheitsrelevanter Funktionen in IconTrust kann die gesamte PC-Kette aus Applikation, Betriebssystem, CPU und Grafikkarte als nicht sicherheitsrelevant betrachtet werden. Das bringt die folgenden Vorteile für den Anwender: – Flexibilität – Aufgrund der Unabhängigkeit von Sicherheitsanforderungen kann jeder PC oder eine ähnliche Plattform zur Grafikerzeugung und -anzeige eingesetzt werden. – Bereits vorhandene Anwendungen können leicht nachgerüstet werden. – Standard-Betriebssysteme können verwendet werden. – Die Nutzung von Standard-Grafikwerkzeugen und -bibliotheken ermöglicht die drastische Reduzierung des Entwicklungsaufwands. – Bei Änderungen der grafischen Benutzerschnittstelle ist außerhalb der überwachten Bereiche keine weitere Begutachtung notwendig. – Selbst wenn das Layout der grafischen Benutzerschnittstelle innerhalb des vordefinierten Bereichs verändert wird, genügt es, die Konfiguration anzupassen. – Die Obsoleszenz von PC-Komponenten hat keinen Einfluss auf den Sicherheitsnachweis. Das gilt auch für alle zukünftigen Revisionsstände der PC-Plattform. – Nutzung der vollen PC-Leistung und seiner ergonomischen Vorteile. So zeigt sich, dass ein intelligentes Sicherheitskonzept den Entwicklungsaufwand für ein HMI-System verringern kann und eine Sicherheitszulassung nach SIL vereinfacht.