ESE Fachwissen
Safety-Architektur für Plattformen mit komplexer Hardware
Autor: Mehmet Özer, SYSGO AG
Beitrag - Embedded Software Engineering Kongress 2017
Die Sicherheitsnormen für die Eisenbahn (CENELEC - EN50128, EN50129, EN50126 etc.) haben einheitliche Anforderungen an die Entwicklung sicherheitsrelevanter elektronischer Systeme aus Software und Hardware eingeführt und sind an die Stelle lokaler Standards der einzelnen Länder getreten. Die Standardisierung führt zwar zu einem einheitlichen Verständnis von Sicherheit und Qualität, was definitiv positiv für die Safety ist, es zwingt aber auch die Unternehmen, einen kostspieligeren Entwicklungs- und Zertifizierungsprozess für Sicherheitssysteme umzusetzen.
Dieser Artikel orientiert sich an dem Use-Case einer Eisenbahn-Signalling-Anlage. Obwohl hierfür nur die relevanten CENELEC-Normen Anwendung finden, werden in diesem Artikel einige Aspekte aus dem Blickwinkel der IEC61508 beschrieben. Hintergrund hierfür ist nicht, dass die CENELEC-Normen nicht zur Genüge auf diese Aspekte eingehen würden. Vielmehr ist die Beschreibung in der IEC61508 verständlicher.
Die beiden Sicherheitsnormen EN50128 (Software für Eisenbahnsteuerungs- und Überwachungssysteme) und EN50129 (sicherheitsrelevante elektronische Systeme zur Signalisierung) sind eine Spezialisierung der IEC61508 zur funktionalen Sicherheit und definieren generische (Software-) Anwendungen und generische (Hardware-) Produkte, die eine unabhängige Zertifizierung für Bahnanwendungen erhalten können. Beim Aufbau eines komplexen Sicherheitssystems können solche COTS-Produkte (Commercial off-the-Shelf) wiederverwendet werden, einschließlich ihrer bestehenden Zertifizierungsartefakte. Mit diesem Ansatz kann eine sicherheitsrelevante Elektronik aus vorzertifizierten Software- und Hardwaremodulen zusammengesetzt werden.
Eine vorzertifizierte generische (Software-) Anwendung muss dabei den Regeln der EN50128 folgen. Aufgrund der Eigenschaften von Software werden in dieser Sicherheitsnorm nur systematische Fehler berücksichtigt. Um die systematische Fehlerquote auf ein akzeptables Niveau zu reduzieren, definiert der Standard "Techniken und Maßnahmen" für die Spezifikation, die Entwicklung, die Überprüfung und Validierung sowie für den Betrieb und die Wartung der sicherheitsrelevanten Software. Als Faustregel gilt, dass der Aufwand für die Zertifizierung von Software proportional mit der Anzahl der Codezeilen steigt.
Anders als bei Software können bei Hardware neben systematischen Fehlern auch zufällige Fehler auftreten. Systematische Hardwarefehler werden durch das Beachten von Regeln für den Entwicklungsprozess adressiert. Auch architektonische Maßnahmen (z.B. Diversität) können die Auswirkung von systematischen Ausfällen vermindern. Zufällige Hardwarefehler werden durch die Berechnung der Wahrscheinlichkeit des Ausfalls unter Verwendung statistischer Daten und historisch belegter Gebrauchsdaten adressiert. Das funktioniert ganz gut für diskrete Hardwarekomponenten, aber je komplexer eine Hardware ist, desto schwerer wird es, den Ausfall von Hardwarekomponenten zu errechnen. Eine praktikable Alternative besteht darin, den Ausfall extern (durch Diagnose) zu registrieren und die Hardware bzw. das System innerhalb einer definierten Zeitspanne in einen sicheren Zustand (Safe State) zu überführen. Diese Alternative ermöglicht Entwicklern, auch komplexe Hardwarekomponenten wie etwa Multi-Core-Prozessoren zu verwenden, falls entsprechende Diagnosemethoden angewendet werden.
Safety Integrity Levels (SIL)
Die primäre Aufgabe einer sicherheitsrelevanten elektronischen Anlage ist es, eine Sicherheitsfunktion auszuführen, die einen sicheren Zustand eines überwachten Gerätes erreichen oder aufrechterhalten muss, um die Folgen von gefährlichen Ereignissen zu verringern. Die Fähigkeit, die Sicherheitsfunktion auszuführen, wird durch die Sicherheitsintegrität (Safety Integrity) beschrieben, die ein Maß für die Wahrscheinlichkeit ist, dass ein sicherheitsrelevantes System die spezifizierten Sicherheitsfunktionen unter allen angegebenen Bedingungen innerhalb eines bestimmten Zeitraums durchführt. Dabei wird das höchste Sicherheitsintegritätsniveau (Safety Integrity Level - SIL) durch die Sicherheitsanforderungen an das System definiert.
Ziel eines sicherheitsrelevanten Systems ist es, das Risiko für eine bestimmte Situation in Bezug auf seine Wahrscheinlichkeit und ihre spezifischen Konsequenzen auf ein tolerierbares Niveau zu reduzieren. Um zu einem Urteil zu gelangen, was ein tolerierbares Risiko für eine spezifische Anwendung darstellt, müssen mehrere Faktoren wie gesetzliche Anforderungen, Richtlinien, Industriestandards (z.B. IEC61508, EN50128, EN50129 usw.) berücksichtigt werden. Die Konformität eines sicherheitsrelevanten Systems mit einer zugewiesenen SIL-Ebene muss für Hardware grundsätzlich mathematisch nachgewiesen werden.
Im Falle von SIL 3 gilt eine gefährliche Situation alle 1142 Jahre (10-7 pro Stunde) als akzeptabel (Tabelle 1, siehe PDF). Da elektronische Bauteile einen solchen Langzeitnachweis nicht erlauben, müssen architektonische Konzepte wie Hardware-Fehlertoleranz, Geräte-Diagnose, Inspektions- und Proof-Tests angewendet werden, um das Ausfallrisiko für die Elektronik zu reduzieren.
Systematische Fehler
Die Norm IEC61508 unterscheidet bei der Safety Integrity für elektronische Systeme zwischen Hardware-Sicherheitsintegrität und systematischer Sicherheitsintegrität. Hardware-Sicherheitsintegrität bezieht sich auf zufällige Hardware-Fehler, während die systematische Sicherheitsintegrität mit systematischen Fehlern zusammenhängt. Der Begriff Common Cause Failure (CCF) beschreibt dabei zufällige und systematische Ereignisse, die dazu führen, dass mehrere Geräte (in einem Mehrkanal-System) gleichzeitig ausfallen.
Fehler werden mit unterschiedlichen Strategien verwaltet, je nachdem, ob sie zufälliger oder systematischer Natur sind. Zufallsfehler können durch interne Geräte-Diagnose, externe Diagnose, Inspektion und Proof-Tests identifiziert werden. Während zufällige Hardwarefehler vor allem durch Alterung und externe Einflüsse verursacht werden, sind systematische Ausfälle eine direkte Konsequenz der Systemkomplexität. Sie werden oft während der Spezifikation und der Entwurfs- oder Implementierungsphase eingeführt, können aber auch durch Fehler während der Fertigung, der Integration sowie durch Bedienungs- oder Wartungsfehler verursacht werden. Systematische Ausfälle gelten als vorhersehbar und lassen sich durch die strikte Anwendung korrekter Prozesse während des Lebenszyklus der elektronischen Komponente und der implementierten Software in den Griff bekommen.
Die Wahrscheinlichkeit systematischer Ausfälle kann auch durch Mehrkanaligkeit (Fehlertoleranz durch Redundanz) auf einen hinreichend geringen Wert gebracht werden. Diese Fehlertoleranz kann etwa durch Diversität (Vielfalt) erreicht werden, indem unterschiedliche Technologien oder Produkte eingesetzt werden. Zudem kann man ggf. unterschiedliche Hardwarearchitekturen von verschiedenen Anbietern verwenden. Im Falle von Software kann der gleiche Algorithmus beispielsweise in unterschiedlichen Programmiersprachen implementiert werden und/oder in verschiedenen Laufzeitumgebungen laufen. Eine höhere Zuverlässigkeit durch Vielfalt basiert dabei auf der Annahme, dass verschiedene Geräte unterschiedliche Ausfallursachen und Ausfallmodi haben.
Zufällige Hardwarefehler
Zufällige Hardwarefehler treten zu einer zufälligen Zeit auf und resultieren aus einer physischen Verschlechterung der Hardware. Die Verschlechterung kann durch Fertigungstoleranzen, abnormale Prozessbedingungen (Überspannung und Temperatur), elektrostatische Entladung, Geräteverschleiß usw. verursacht werden, die dazu führen, dass Hardwarekomponenten während des Betriebs ausfallen. Die Ausfälle treten zwar mit vorhersagbarer Wahrscheinlichkeit auf, aber zu unvorhersehbaren (d.h. zufälligen) Zeiten. Abhängig von der Auswirkung eines Fehlers auf die Hardware wird dieser entweder als "weicher Fehler" oder "harter Fehler" bezeichnet. Ein weicher Fehler (Soft Error) ist vorübergehend und ohne dauerhafte Folgen, während ein harter Fehler (Hard Error) die Hardware bleibend beschädigt. Mit der zunehmenden Komplexität der Hardware steigt auch die Wahrscheinlichkeit von weichen und harten Fehlern aufgrund von Umwelt- und Betriebsbedingungen. Dies wird durch den Trend begünstigt, die Geometrie der Hardware zu schrumpfen und die Dichte von Transistoren auf dem Silizium zu erhöhen. Insbesondere Speicherkomponenten sind anfällig für Übersprecher und gegenüber elektromagnetischen Feldern, die zu weichen oder harten Fehlern führen.
Höhere SIL Level - aber wie?
Tabelle 2 (siehe PDF) ist laut IEC61508 Part-2 anzuwenden für komplexe Geräte.
Safe Failure Fraction (SFF)
Zur mathematischen Beschreibung dieser Größen benötigen wir noch die Kennzahl λ, die ein Maß für die Ausfall-Rate ist (Fehler pro Zeit). Die IEC61508 klassifiziert zufällige Hardware-Ausfälle auch nach ihren Auswirkungen auf das Sicherheitssystem, und zwar als sichere (safe) λs und gefährliche (dangerous) Ausfälle λD. Ein sicherer Fehler bewirkt, dass das Gerät die Sicherheit im Sinne des Sicherheitskonzeptes weiterhin gewährleistet. Ein gefährliches Versagen führt dagegen dazu, dass das Gerät seine Sicherheitsfunktion nicht ausführt.
Sichere und gefährliche Ausfälle werden weiter in die Kategorien "erkannt (detected)" und "unentdeckt (undetected)" aufgeteilt. Somit teilt sich die Ausfallrate in vier Gruppen auf:
- λSD = safe detected failure rate (entdeckte und ungefährliche Fehler)
- λSU = safe undetected failure rate (unentdeckte und ungefährliche Fehler)
- λDD = dangerous detected failure rate (entdeckte und gefährliche Fehler)
- λDU = dangerous undetected failure rate (unentdeckte und gefährliche Fehler)
Als Safe Failure Fraction oder SFF wird der Anteil der sicheren und als sicher zu behandelnden Fehler zu der Gesamtzahl der Fehler bezeichnet.
SFF = (λSU + λSD + λDD) / (λSU + λSD + λDD +λDU)
Erkannte (sichere und gefährliche) Ausfälle werden durch Diagnosetests aufgedeckt. Im Falle eines sicheren Fehlers (erkannt oder unentdeckt) kann die Sicherheitsfunktion aufrechterhalten werden. Ein via Diagnose erkannter gefährlicher Fehler kann als sicherer Fehler betrachtet werden, wenn wirksame Maßnahmen ergriffen werden, um das System in einen sicheren Zustand zu bringen. Gefährliche unentdeckte Ausfälle führen zu einem Verlust der Sicherheitsfunktion und müssen so gering wie möglich gehalten werden. Im Idealfall λDU à 0 kann eine SFF = 1 ≙ 100% erreicht werden. Eine solche Hardware würde gemäß Tabelle 2 (siehe PDF) theoretisch SIL 3 erreichen.
Hardware-Fehlertoleranz (HFT)
Hardware-Fehlertoleranz ist die Fähigkeit eines Systems, auch bei Hardwarefehlern die erforderliche Funktion zu gewährleisten. Eine Hardwarefehlertoleranz von 1 bedeutet, dass es beispielsweise zwei (redundante) Geräte gibt, die die Sicherheitsfunktion ausführen und der Ausfall eines der beiden Geräte die Sicherheitsfunktion nicht beeinträchtigt. Ein dreikanaliges System, bei dem ein einzelner Kanal die Sicherheitsfunktion im Falle eines Fehlers fortsetzen kann, hat eine Hardware-Fehlertoleranz von 2. Die HFT kann leicht berechnet werden, wenn die Architektur als M aus N (MooN) ausgedrückt wird (Tabelle 2). In diesem Fall wird die HFT als N-M berechnet. Mit anderen Worten, eine 2oo4 Architektur hat eine HFT von 2. Dies bedeutet, dass ein solches System 2 Ausfälle tolerieren kann und immer noch funktioniert.
Tabelle 2 (siehe PDF) zeigt den Worst-Case und einen Best-Case SIL, die je nach Hardware-Fehlertoleranz und der Safe Failure Fraction beansprucht werden können. Bei einer geringen SFF (<60%) wäre es nicht zulässig, ein Einkanal-System ohne jede Hardware-Fehlertoleranz zu verwenden, um eine Sicherheitsfunktion zu unterstützen. Unter der Voraussetzung, dass die festgelegten Kriterien für eine höhere SFF erfüllt werden können, wäre es jedoch möglich, bis zu SIL 3 für ein Einkanal-Subsystem zu deklarieren. Als Faustregel steigt die erreichbare SIL-Stufe für eine Komponente mit einem spezifischen SFF mit der HFT des Systemdesigns. Wenn zum Beispiel ein Gerät einen SFF zwischen 90% und 99% hat, kann es ohne Hardwaretoleranz SIL 2 und bei einem HFT von 1 SIL 3 erreichen.
Wenn der SFF unter 90% (aber > 60%) ist, erlaubt ein HFT von 2 auch ein SIL 3 Design mit diesen Komponenten.
Diagnosedeckungsgrad
Der Diagnosedeckungsgrad (Diagnostic Coverage = DC) beschreibt den Anteil gefährlicher Ausfälle, die durch Diagnosetests erkannt werden. Die mathematische Beschreibung dieser Größe zeigt ebenso die Notwendigkeit, gefährliche unentdeckte Ausfälle λDU so weit zu minimieren, dass eine Diagnoseabdeckung von 1 ≙ 100% erreicht werden kann.
DC = λDD/ (λDD +λDU)
Die herstellerspezifische Diagnose für bestimmte Komponenten ist in der Regel dazu gedacht, alle gefährlichen Fehler dieser Komponenten zu erkennen, so dass sie nicht das gesamte System abdeckt (z.B. Temperatursensor einer CPU). Aus Systemsicht muss eine zusätzliche Diagnose implementiert werden, um die Wahrscheinlichkeit von gefährlichen Systemausfällen zu verringern.
Die IEC61508 empfiehlt im Teil 2 (Annex-A) Techniken und Maßnahmen für diagnostische Tests und gibt die größtmögliche diagnostische Abdeckung an, die mit der jeweiligen Maßnahme erreicht werden kann (siehe Tabelle 3, PDF). Diese Tests können kontinuierlich oder periodisch durchgeführt werden.
Tabelle 3 zeigt exemplarisch einen Auszug aus den Tests, die für RAM (variable memory) vorgeschlagen werden. Tabelle 4 (siehe PDF) zählt alle Komponenten auf, für die unterschiedlichste Diagnosen im Annex-A vorgeschlagen werden. Die erforderliche Diagnose hängt von mehreren Faktoren ab, wie z.B. der zugewiesenen Sicherheitsintegritätsstufe, der Architektur und der zu erwartenden Anforderungsrate (wie oft wird die Sicherheitsfunktion pro Zeit angefordert). Es gibt durchaus Fälle, in denen spezifische Diagnosetest nicht durchgeführt werden sollten, wenn durch diese der Systemzustand ungünstig beeinträchtigt wird. Detaillierte RAM-Tests z.B. sind sehr zeitintensiv und können eventuell das Laufzeitverhalten der Applikation stören.
Sicherheitsgerichtete Software
Bei der Verwendung eines CPU-Boards in einem Sicherheitssystem wird Software ein wesentlicher Teil der Sicherheitsfunktion. In der frühen Geräteinitialisierung ist der Bootloader eine wichtige Software-Komponente. Nach dem Bootvorgang kann ein Betriebssystem (OS) eingesetzt werden, um die Nutzung der Hardware zu vereinfachen. Auf dem Betriebssystem kann eine Softwareanwendung die (Sicherheits-) Funktion einschließlich der Diagnosetests durchführen.
Software kennt nur systematische Fehler, die in der Regel durch Fehler in der Designphase verursacht werden. Die EN50128 und die IEC61508 Teil-3 beschreiben Methoden und Konzepte, um die Wahrscheinlichkeit der Softwarefehler auf einen bestimmten Wert zu reduzieren. Die Methoden beinhalten grob die folgenden Phasen:
- Anforderungsspezifikation
- Software-Design und Entwicklungsprozess
- Verifizierungs- und Validierungsverfahren
Detaillierte Unterlagen und Nachweise müssen vorbereitet werden, um nachzuweisen, dass ein angemessenes Niveau der vorgegebenen Regeln angewandt wurde. Dabei ist der Aufwand für die Validierungstests in hohem Maße abhängig vom Umfang des Quellcodes (Source Lines of Code - SLOC), der getestet werden muss. Ein schlanker Quellcode reduziert den Zertifizierungsaufwand erheblich. Dies gilt natürlich auch für alle Softwarekomponenten, wie Bootloader, Betriebssystem, Applikationscode und eingebaute Diagnosefunktionen. Die Verwendung des richtigen Technologie- und Validierungsansatzes hat daher einen erheblichen Einfluss auf die Gesamtkosten der Zertifizierung. Ausnahmslos alle industriellen Sicherheitsnormen schlagen hier eine Trennung von sicherheitsrelevanter und nicht sicherheitsrelevanter Software vor, so dass nur die sicherheitsrelevanten Teile zertifiziert werden müssen.
Trennung von Anwendungen durch einen Separation Kernel
Die Verwendung unabhängiger Hardwarekomponenten für sicherheitsrelevante und andere Anwendungen sorgt zwar für eine sichere Trennung, führt aber auch zu höheren Hardwarekosten. Ein auf einem Separation Kernel basierendes Betriebssystem ermöglicht dagegen die Trennung von sicherheitskritischem und unkritischem Applikationscode auf derselben Hardwareplattform durch die Aufteilung der physikalischen und zeitlichen Ressourcen der Hardware. Die Trennung von physikalischen Ressourcen wird als räumliche Trennung oder Ressourcenpartitionierung bezeichnet, während die Trennung der verfügbaren Ausführungszeit als zeitliche Trennung oder Zeitpartitionierung bekannt ist. Das Trennungsprinzip kann mit einem Hypervisor verglichen werden, doch der Hauptunterschied besteht darin, dass die Separierung durch den Separation Kernel rückwirkungsfrei ist. D.h. ein Fehler in einer Partition kann sich nicht auf andere Partitionen ausbreiten.
In der Nomenklatur eines Separation Kernels werden die isolierten Anwendungsbereiche als Partitionen bezeichnet. Die Trennung von Applikationen in Partitionen sorgt dafür, dass sich die Applikationen nicht gegenseitig beeinflussen können, so dass jede Applikation auf ihrem zugeordneten Safety Integrity Level (SIL) arbeiten kann. Somit kann eine Hardwareplattform Anwendungen gemischter Kritikalitätsstufen verarbeiten. Z.B. kann ein Kommunikations-Stack (TCP / IP, Web-Server, OPC-UA usw.) in einer SIL 0 Partition gehostet werden, während eine sicherheitsrelevante Anwendung in einer SIL 4 Partition läuft. Jeder Partitionsinhalt muss in einem solchen Fall nur für seine SIL-Ebene zertifiziert werden.
Fazit
Der Aufwand (Kosten und Zeit) für die Zertifizierung eines Safety Related Electronic Systems steigt mit der Komplexität der Hardware- und Softwarekomponenten. Die Aufgabe, die Ausfallraten für komplexe Hardware (wie z.B. CPU-Boards) durch die Betrachtung der Einzelkomponenten zu ermitteln, ist kaum leistbar. Zumal durch die kurzen Lebenszyklen der Hardware kaum belastbare Gebrauchsdaten vorliegen, die für eine "proven in use" Argumentation herangezogen werden können. Als Ausweg aus diesem Dilemma erlaubt die IEC61508 durch ein fehlertolerantes Design und diagnostische Tests das System so zu überwachen, dass es in einem Fehlerfall in einen sicheren Zustand überführt werden kann.
Der Aufwand für die Software-Zertifizierung ist abhängig von den Source Lines of Code (SLOC). Eine Reduzierung der SLOCs sind Grenzen gesetzt, wenn eine bestimmte Funktionalität implementiert werden muss. Wie wir gesehen haben, kann hier die Partitionierung der Software in unterschiedliche SIL-Klassen Abhilfe dahingehend schaffen, dass die jeweiligen Applikationsteile nur für ihren SIL-Level zertifiziert werden müssen.
Auf Komponentenebene erlauben die CENELEC-Normen für Railway und die IEC61508 die Vorzertifizierung von generischen Software- und Hardwarekomponenten. Somit können vorzertifizierte COTS-Software- und Hardwarekomponenten ohne erneute Zertifizierung in unterschiedlichen Projekten wiederverwendet werden.
Quellenverzeichnis
[1.2] IEC 61508-2, Edition 2.0 2010-04: Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 2: Requirements for electrical/electronic/programmable electronic safety- related systems
[1.3] IEC 61508-3, Edition 2.0 2010-04: Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements
[1.7] IEC 61508-7, Edition 2.0 2010-04: Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures
[2] BS EN 50128:2011: Railway applications — Communication, signalling and processing systems — Software for rail- way control and protection systems
[3] DIN EN 50129:2003: Bahnanwendungen. Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme. Sicherheitsrelevante elektronische Systeme für Signaltechnik
[4] SYSGO White Paper: Safety certication for unsafe COTS platforms
Unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Qualität, Safety & Security.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Qualität, Safety & Security - Fachwissen
Wertvolles Fachwissen zum Thema Qualität, Safety & Security steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.