Autor: Mehmet \u00d6zer, SYSGO AG Die Sicherheitsnormen f\u00fcr die Eisenbahn (CENELEC – EN50128, EN50129, EN50126 etc.) haben einheitliche Anforderungen an die Entwicklung sicherheitsrelevanter elektronischer Systeme aus Software und Hardware eingef\u00fchrt und sind an die Stelle lokaler Standards der einzelnen L\u00e4nder getreten. Die Standardisierung f\u00fchrt zwar zu einem einheitlichen Verst\u00e4ndnis von Sicherheit und Qualit\u00e4t, was definitiv positiv f\u00fcr die Safety ist, es zwingt aber auch die Unternehmen, einen kostspieligeren Entwicklungs- und Zertifizierungsprozess f\u00fcr Sicherheitssysteme umzusetzen.<\/strong><\/p>\n Dieser Artikel orientiert sich an dem Use-Case einer Eisenbahn-Signalling-Anlage. Obwohl hierf\u00fcr nur die relevanten CENELEC-Normen Anwendung finden, werden in diesem Artikel einige Aspekte aus dem Blickwinkel der IEC61508 beschrieben. Hintergrund\u00a0 hierf\u00fcr ist nicht, dass die CENELEC-Normen nicht zur Gen\u00fcge auf diese Aspekte eingehen w\u00fcrden. Vielmehr ist die Beschreibung in der IEC61508 verst\u00e4ndlicher.<\/p>\n Die beiden Sicherheitsnormen EN50128 (Software f\u00fcr Eisenbahnsteuerungs- und \u00dcberwachungssysteme) 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\u00e4ngige Zertifizierung f\u00fcr Bahnanwendungen erhalten k\u00f6nnen. Beim Aufbau eines komplexen Sicherheitssystems k\u00f6nnen solche COTS-Produkte (Commercial off-the-Shelf) wiederverwendet werden, einschlie\u00dflich ihrer bestehenden Zertifizierungsartefakte. Mit diesem Ansatz kann eine sicherheitsrelevante Elektronik aus vorzertifizierten Software- und Hardwaremodulen zusammengesetzt werden.<\/p>\n 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\u00fccksichtigt. Um die systematische Fehlerquote auf ein akzeptables Niveau zu reduzieren, definiert der Standard „Techniken und Ma\u00dfnahmen“ f\u00fcr die Spezifikation, die Entwicklung, die \u00dcberpr\u00fcfung und Validierung sowie f\u00fcr den Betrieb und die Wartung der sicherheitsrelevanten Software. Als Faustregel gilt, dass der Aufwand f\u00fcr die Zertifizierung von Software proportional mit der Anzahl der Codezeilen steigt.<\/p>\n Anders als bei Software k\u00f6nnen bei Hardware neben systematischen Fehlern auch zuf\u00e4llige Fehler auftreten. Systematische Hardwarefehler werden durch das Beachten von Regeln f\u00fcr den Entwicklungsprozess adressiert. Auch architektonische Ma\u00dfnahmen (z.B. Diversit\u00e4t) k\u00f6nnen die Auswirkung von systematischen Ausf\u00e4llen vermindern. Zuf\u00e4llige Hardwarefehler werden durch die Berechnung der Wahrscheinlichkeit des Ausfalls unter Verwendung statistischer Daten und historisch belegter Gebrauchsdaten adressiert. Das funktioniert ganz gut f\u00fcr 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 \u00fcberf\u00fchren. Diese Alternative erm\u00f6glicht Entwicklern, auch komplexe Hardwarekomponenten wie etwa Multi-Core-Prozessoren zu verwenden, falls entsprechende Diagnosemethoden angewendet werden.<\/p>\n Die prim\u00e4re Aufgabe einer sicherheitsrelevanten elektronischen Anlage ist es, eine Sicherheitsfunktion auszuf\u00fchren, die einen sicheren Zustand eines \u00fcberwachten Ger\u00e4tes erreichen oder aufrechterhalten muss, um die Folgen von gef\u00e4hrlichen Ereignissen zu verringern. Die F\u00e4higkeit, die Sicherheitsfunktion auszuf\u00fchren, wird durch die Sicherheitsintegrit\u00e4t (Safety Integrity) beschrieben, die ein Ma\u00df f\u00fcr die Wahrscheinlichkeit ist, dass ein sicherheitsrelevantes System die spezifizierten Sicherheitsfunktionen unter allen angegebenen Bedingungen innerhalb eines bestimmten Zeitraums durchf\u00fchrt. Dabei wird das h\u00f6chste Sicherheitsintegrit\u00e4tsniveau (Safety Integrity Level – SIL) durch die Sicherheitsanforderungen an das System definiert.<\/p>\n Ziel eines sicherheitsrelevanten Systems ist es, das Risiko f\u00fcr 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\u00fcr eine spezifische Anwendung darstellt, m\u00fcssen mehrere Faktoren wie gesetzliche Anforderungen, Richtlinien, Industriestandards (z.B. IEC61508, EN50128, EN50129 usw.) ber\u00fccksichtigt werden. Die Konformit\u00e4t eines sicherheitsrelevanten Systems mit einer zugewiesenen SIL-Ebene muss f\u00fcr Hardware grunds\u00e4tzlich mathematisch nachgewiesen werden.<\/p>\n Im Falle von SIL 3 gilt eine gef\u00e4hrliche Situation alle 1142 Jahre (10-7<\/sup>\u00a0pro Stunde) als akzeptabel (Tabelle 1, siehe\u00a0PDF<\/a>). Da elektronische Bauteile einen solchen Langzeitnachweis nicht erlauben, m\u00fcssen architektonische Konzepte wie Hardware-Fehlertoleranz, Ger\u00e4te-Diagnose, Inspektions- und Proof-Tests angewendet werden, um das Ausfallrisiko f\u00fcr die Elektronik zu reduzieren.<\/p>\n Die Norm IEC61508 unterscheidet bei der Safety Integrity f\u00fcr elektronische Systeme zwischen Hardware-Sicherheitsintegrit\u00e4t und\u00a0 systematischer Sicherheitsintegrit\u00e4t. Hardware-Sicherheitsintegrit\u00e4t bezieht sich auf zuf\u00e4llige Hardware-Fehler, w\u00e4hrend die systematische Sicherheitsintegrit\u00e4t mit systematischen Fehlern zusammenh\u00e4ngt. Der Begriff Common Cause Failure (CCF) beschreibt dabei zuf\u00e4llige und systematische Ereignisse, die dazu f\u00fchren, dass mehrere Ger\u00e4te (in einem Mehrkanal-System) gleichzeitig ausfallen.<\/p>\n Fehler werden mit unterschiedlichen Strategien verwaltet, je nachdem, ob sie zuf\u00e4lliger oder systematischer Natur sind. Zufallsfehler k\u00f6nnen durch interne Ger\u00e4te-Diagnose, externe Diagnose, Inspektion und Proof-Tests identifiziert werden. W\u00e4hrend zuf\u00e4llige Hardwarefehler vor allem durch Alterung und externe Einfl\u00fcsse verursacht werden, sind systematische Ausf\u00e4lle eine direkte Konsequenz der Systemkomplexit\u00e4t. Sie werden oft w\u00e4hrend der Spezifikation und der Entwurfs- oder Implementierungsphase eingef\u00fchrt, k\u00f6nnen aber auch durch Fehler w\u00e4hrend der Fertigung, der Integration sowie durch Bedienungs- oder Wartungsfehler verursacht werden. Systematische Ausf\u00e4lle gelten als vorhersehbar und lassen sich durch die strikte Anwendung korrekter Prozesse w\u00e4hrend des Lebenszyklus der elektronischen Komponente und der implementierten Software in den Griff bekommen.<\/p>\n Die Wahrscheinlichkeit systematischer Ausf\u00e4lle kann auch durch Mehrkanaligkeit (Fehlertoleranz durch Redundanz) auf einen hinreichend geringen Wert gebracht werden.\u00a0 Diese Fehlertoleranz kann etwa durch Diversit\u00e4t (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\u00f6here Zuverl\u00e4ssigkeit durch Vielfalt basiert dabei auf der Annahme, dass verschiedene Ger\u00e4te unterschiedliche Ausfallursachen und Ausfallmodi haben.<\/p>\n Zuf\u00e4llige Hardwarefehler treten zu einer zuf\u00e4lligen Zeit auf und resultieren aus einer physischen Verschlechterung der Hardware. Die Verschlechterung kann durch Fertigungstoleranzen, abnormale Prozessbedingungen (\u00dcberspannung und Temperatur), elektrostatische Entladung, Ger\u00e4teverschlei\u00df usw. verursacht werden, die dazu f\u00fchren, dass Hardwarekomponenten w\u00e4hrend des Betriebs ausfallen. Die Ausf\u00e4lle treten zwar mit vorhersagbarer Wahrscheinlichkeit auf, aber zu unvorhersehbaren (d.h. zuf\u00e4lligen) Zeiten. Abh\u00e4ngig 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\u00fcbergehend und ohne dauerhafte Folgen, w\u00e4hrend ein harter Fehler (Hard Error) die Hardware bleibend besch\u00e4digt. Mit der zunehmenden Komplexit\u00e4t der Hardware steigt auch die Wahrscheinlichkeit von weichen und harten Fehlern aufgrund von Umwelt- und Betriebsbedingungen. Dies wird durch den Trend beg\u00fcnstigt, die Geometrie der Hardware zu schrumpfen und die Dichte von Transistoren auf dem Silizium zu erh\u00f6hen. Insbesondere Speicherkomponenten sind anf\u00e4llig f\u00fcr \u00dcbersprecher und gegen\u00fcber elektromagnetischen Feldern, die zu weichen oder harten Fehlern f\u00fchren.<\/p>\n Tabelle 2 (siehe\u00a0PDF<\/a>) ist laut IEC61508 Part-2 anzuwenden f\u00fcr komplexe Ger\u00e4te.<\/p>\n Zur mathematischen Beschreibung dieser Gr\u00f6\u00dfen ben\u00f6tigen wir noch die Kennzahl \u03bb, die ein Ma\u00df f\u00fcr die Ausfall-Rate ist (Fehler pro Zeit). Die IEC61508 klassifiziert zuf\u00e4llige Hardware-Ausf\u00e4lle auch nach ihren Auswirkungen auf das Sicherheitssystem, und zwar als sichere (safe) \u03bbs<\/sub>\u00a0und gef\u00e4hrliche (dangerous) Ausf\u00e4lle \u03bbD<\/sub>. Ein sicherer Fehler bewirkt, dass das Ger\u00e4t die Sicherheit im Sinne des Sicherheitskonzeptes weiterhin gew\u00e4hrleistet. Ein gef\u00e4hrliches Versagen f\u00fchrt dagegen dazu, dass das Ger\u00e4t seine Sicherheitsfunktion nicht ausf\u00fchrt.<\/p>\n Sichere und gef\u00e4hrliche Ausf\u00e4lle werden weiter in die Kategorien „erkannt (detected)“ und „unentdeckt (undetected)“ aufgeteilt. Somit teilt sich die Ausfallrate in vier Gruppen auf:<\/p>\n Als Safe Failure Fraction oder SFF wird der Anteil der sicheren und als sicher zu behandelnden Fehler zu der Gesamtzahl der Fehler bezeichnet.<\/p>\n SFF = (\u03bbSU\u00a0<\/sub>+ \u03bbSD\u00a0<\/sub>+ \u03bbDD<\/sub>) \/ (\u03bbSU\u00a0<\/sub>+ \u03bbSD\u00a0<\/sub>+ \u03bbDD\u00a0<\/sub>+\u03bbDU<\/sub>)<\/p>\n Erkannte (sichere und gef\u00e4hrliche) Ausf\u00e4lle werden durch Diagnosetests aufgedeckt. Im Falle eines sicheren Fehlers (erkannt oder unentdeckt) kann die Sicherheitsfunktion aufrechterhalten werden. Ein via Diagnose erkannter gef\u00e4hrlicher Fehler kann als sicherer Fehler betrachtet werden, wenn wirksame Ma\u00dfnahmen ergriffen werden, um das System in einen sicheren Zustand zu bringen. Gef\u00e4hrliche unentdeckte Ausf\u00e4lle f\u00fchren zu einem Verlust der Sicherheitsfunktion und m\u00fcssen so gering wie m\u00f6glich gehalten werden. Im Idealfall \u03bbDU\u00a0<\/sub>\u00e0 0 kann eine SFF = 1 \u2259 100% erreicht werden. Eine solche Hardware w\u00fcrde gem\u00e4\u00df Tabelle 2 (siehe\u00a0PDF<\/a>) theoretisch SIL 3 erreichen.<\/p>\n Hardware-Fehlertoleranz ist die F\u00e4higkeit eines Systems, auch bei Hardwarefehlern die erforderliche Funktion zu gew\u00e4hrleisten. Eine Hardwarefehlertoleranz von 1 bedeutet, dass es beispielsweise zwei (redundante) Ger\u00e4te gibt, die die Sicherheitsfunktion ausf\u00fchren und der Ausfall eines der beiden Ger\u00e4te die Sicherheitsfunktion nicht beeintr\u00e4chtigt. 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\u00fcckt 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\u00e4lle tolerieren kann und immer noch funktioniert.<\/p>\n Tabelle 2 (siehe\u00a0PDF<\/a>) zeigt den Worst-Case und einen Best-Case SIL, die je nach Hardware-Fehlertoleranz und der Safe Failure Fraction beansprucht werden k\u00f6nnen. Bei einer geringen SFF (<60%) w\u00e4re es nicht zul\u00e4ssig, ein Einkanal-System ohne jede Hardware-Fehlertoleranz zu verwenden, um eine Sicherheitsfunktion zu unterst\u00fctzen. Unter der Voraussetzung, dass die festgelegten Kriterien f\u00fcr eine h\u00f6here SFF erf\u00fcllt werden k\u00f6nnen, w\u00e4re es jedoch m\u00f6glich, bis zu SIL 3 f\u00fcr ein Einkanal-Subsystem zu deklarieren. Als Faustregel steigt die erreichbare SIL-Stufe f\u00fcr eine Komponente mit einem spezifischen SFF mit der HFT des Systemdesigns. Wenn zum Beispiel ein Ger\u00e4t einen SFF zwischen 90% und 99% hat, kann es ohne Hardwaretoleranz SIL 2 und bei einem HFT von 1 SIL 3 erreichen.<\/p>\n Wenn der SFF unter 90% (aber > 60%) ist, erlaubt ein HFT von 2 auch ein SIL 3 Design mit diesen Komponenten.<\/p>\n Der Diagnosedeckungsgrad (Diagnostic Coverage = DC)\u00a0 beschreibt den Anteil gef\u00e4hrlicher Ausf\u00e4lle, die durch Diagnosetests erkannt werden. Die mathematische Beschreibung dieser Gr\u00f6\u00dfe zeigt ebenso die Notwendigkeit, gef\u00e4hrliche unentdeckte Ausf\u00e4lle \u03bbDU\u00a0<\/sub>so weit zu minimieren, dass eine Diagnoseabdeckung von 1 \u2259 100% erreicht werden kann.<\/p>\n DC = \u03bbDD<\/sub>\/ (\u03bbDD\u00a0<\/sub>+\u03bbDU<\/sub>)<\/p>\n Die herstellerspezifische Diagnose f\u00fcr bestimmte Komponenten ist in der Regel dazu gedacht, alle gef\u00e4hrlichen Fehler dieser Komponenten zu erkennen, so dass sie nicht das gesamte System abdeckt (z.B. Temperatursensor einer CPU). Aus Systemsicht muss eine zus\u00e4tzliche Diagnose implementiert werden, um die Wahrscheinlichkeit von gef\u00e4hrlichen Systemausf\u00e4llen zu verringern.<\/p>\n Die IEC61508 empfiehlt im Teil 2 (Annex-A) Techniken und Ma\u00dfnahmen f\u00fcr diagnostische Tests und gibt die gr\u00f6\u00dftm\u00f6gliche diagnostische Abdeckung an, die mit der jeweiligen Ma\u00dfnahme erreicht werden kann (siehe Tabelle 3,\u00a0PDF<\/a>). Diese Tests k\u00f6nnen kontinuierlich oder periodisch durchgef\u00fchrt werden.<\/p>\n Tabelle 3 zeigt exemplarisch einen Auszug aus den Tests, die f\u00fcr RAM (variable memory) vorgeschlagen werden.\u00a0 Tabelle 4 (siehe\u00a0PDF<\/a>) z\u00e4hlt alle Komponenten auf, f\u00fcr die unterschiedlichste Diagnosen im Annex-A vorgeschlagen werden. Die erforderliche Diagnose h\u00e4ngt von mehreren Faktoren ab, wie z.B. der zugewiesenen Sicherheitsintegrit\u00e4tsstufe, der Architektur und der zu erwartenden Anforderungsrate (wie oft wird die Sicherheitsfunktion pro Zeit angefordert). Es gibt durchaus F\u00e4lle, in denen spezifische Diagnosetest nicht durchgef\u00fchrt werden sollten, wenn durch diese der Systemzustand ung\u00fcnstig beeintr\u00e4chtigt wird. Detaillierte RAM-Tests z.B. sind sehr zeitintensiv und k\u00f6nnen eventuell das Laufzeitverhalten der Applikation st\u00f6ren.<\/p>\n Bei der Verwendung eines CPU-Boards in einem Sicherheitssystem wird Software ein wesentlicher Teil der Sicherheitsfunktion. In der fr\u00fchen Ger\u00e4teinitialisierung 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\u00dflich der Diagnosetests durchf\u00fchren.<\/p>\n Software kennt nur systematische Fehler, die in der Regel durch Fehler in der Designphase\u00a0 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:<\/p>\n Detaillierte Unterlagen und Nachweise m\u00fcssen vorbereitet werden, um nachzuweisen, dass ein angemessenes Niveau der vorgegebenen Regeln angewandt wurde. Dabei ist der Aufwand f\u00fcr die Validierungstests in hohem Ma\u00dfe abh\u00e4ngig vom Umfang des Quellcodes (Source Lines of Code – SLOC), der getestet werden muss. Ein schlanker Quellcode reduziert den Zertifizierungsaufwand erheblich. Dies gilt nat\u00fcrlich auch f\u00fcr 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\u00fcssen.<\/p>\n Die Verwendung unabh\u00e4ngiger Hardwarekomponenten f\u00fcr sicherheitsrelevante und andere Anwendungen sorgt zwar f\u00fcr eine sichere Trennung, f\u00fchrt aber auch zu h\u00f6heren Hardwarekosten. Ein auf einem Separation Kernel basierendes Betriebssystem erm\u00f6glicht 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\u00e4umliche Trennung oder Ressourcenpartitionierung bezeichnet, w\u00e4hrend die Trennung der verf\u00fcgbaren Ausf\u00fchrungszeit 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\u00fcckwirkungsfrei ist. D.h. ein Fehler in einer Partition kann sich nicht auf andere Partitionen ausbreiten.<\/p>\n In der Nomenklatur eines Separation Kernels werden die isolierten Anwendungsbereiche als Partitionen bezeichnet. Die Trennung von Applikationen in Partitionen sorgt daf\u00fcr, dass sich die Applikationen nicht gegenseitig beeinflussen k\u00f6nnen, so dass jede Applikation auf ihrem zugeordneten Safety Integrity Level (SIL) arbeiten kann. Somit kann eine Hardwareplattform Anwendungen gemischter Kritikalit\u00e4tsstufen verarbeiten. Z.B. kann ein Kommunikations-Stack (TCP \/ IP, Web-Server, OPC-UA usw.) in einer SIL 0 Partition gehostet werden, w\u00e4hrend eine sicherheitsrelevante Anwendung in einer SIL 4 Partition l\u00e4uft. Jeder Partitionsinhalt muss in einem solchen Fall nur f\u00fcr seine SIL-Ebene zertifiziert werden.<\/p>\n Der Aufwand (Kosten und Zeit) f\u00fcr die Zertifizierung eines Safety Related Electronic Systems steigt mit der Komplexit\u00e4t der Hardware- und Softwarekomponenten. Die Aufgabe, die Ausfallraten f\u00fcr 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\u00fcr eine „proven in use“ Argumentation herangezogen werden k\u00f6nnen. Als Ausweg aus diesem Dilemma erlaubt die IEC61508 durch ein fehlertolerantes Design und diagnostische Tests das System so zu \u00fcberwachen, dass es in einem Fehlerfall in einen sicheren Zustand \u00fcberf\u00fchrt werden kann.<\/p>\n Der Aufwand f\u00fcr die Software-Zertifizierung ist abh\u00e4ngig von den Source Lines of Code (SLOC). Eine Reduzierung der SLOCs sind Grenzen gesetzt, wenn eine bestimmte Funktionalit\u00e4t 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\u00fcr ihren SIL-Level zertifiziert werden m\u00fcssen.<\/p>\n Auf Komponentenebene erlauben die CENELEC-Normen f\u00fcr Railway und die IEC61508 die Vorzertifizierung von generischen Software- und Hardwarekomponenten. Somit k\u00f6nnen vorzertifizierte COTS-Software- und Hardwarekomponenten ohne erneute Zertifizierung in unterschiedlichen Projekten wiederverwendet werden.<\/p>\n [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<\/p>\n [1.3] IEC 61508-3, Edition 2.0 2010-04: Functional safety of electrical\/electronic\/programmable electronic safety-related systems – Part 3: Software requirements<\/p>\n [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<\/p>\n [2] BS EN 50128:2011: Railway applications \u2014 Communication, signalling and processing systems \u2014 Software for rail- way control and protection systems<\/p>\n [3] DIN EN 50129:2003: Bahnanwendungen. Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme. Sicherheitsrelevante elektronische Systeme fu\u0308r Signaltechnik<\/p>\n [4] SYSGO White Paper:\u00a0Safety certication for unsafe COTS platforms<\/a><\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2017<\/h3>\n
Safety Integrity Levels (SIL)<\/h2>\n
Systematische Fehler<\/h2>\n
Zuf\u00e4llige Hardwarefehler<\/h2>\n
H\u00f6here SIL Level – aber wie?<\/h2>\n
Safe Failure Fraction (SFF)<\/h2>\n
\n
Hardware-Fehlertoleranz (HFT)<\/h2>\n
Diagnosedeckungsgrad<\/h2>\n
Sicherheitsgerichtete Software<\/h2>\n
\n
Trennung von Anwendungen durch einen Separation Kernel<\/h2>\n
Fazit<\/h2>\n
Quellenverzeichnis<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n