Einfach ausgedrückt fordert IEC 61508, Fehler zu vermeiden oder, falls sie nicht vermeidbar sind, schneller zu erkennen, bevor sie zum Schaden führen können. Hier kann man zwischen systematischen Fehlern und statistischen Fehlern unterscheiden. Systematische Fehler entstehen bei der Spezifikation und der Implementierung der eigenen Entwicklung, aber auch durch die ausgewählten Komponenten in Hardware und Software. Systematische Fehler können auch durch die Entwicklungswerkzeuge eingebracht werden.
Statistische Fehler entstehen durch Defekte der Hardware oder Störung der Hardware durch Umwelteinflüsse wie Höhenstrahlung, elektromagnetische Störungen, Störungen auf der Stromversorgung oder Signalleitungen.
Für die Vermeidung der systematischen Fehler ist mit einem geeigneten Entwicklungsprozess zu entwickeln (Bild 1). Dies kann durch Schulung und Umorganisation der Entwicklungsmannschaft geschehen oder durch Outsourcing der Entwicklung der sicherheitsrelevanten Teile. Die Erfahrung in diversen Consulting-Projekten zeigt, dass es sich hier lohnt, auf externe Berater zurückzugreifen, die praktische Erfahrung in Safety-Projekten bereits gesammelt haben. Das „Learning by Doing“ kann zu sehr vielen Iterationen führen, die den Aufwand vervielfachen.
Manche Kunden versuchen auch, ihre Applikation „unsafe“ zu lassen und durch einen sicheren Zusatz der Norm anzupassen. Das hat den Vorteil, dass nur der sichere Teil den erhöhten Aufwand benötigt und der unsichere Teil gewartet werden kann, ohne zu großen Einfluss auf eine Zertifizierung zu haben. Auch die Frage „make or buy“ hat hier sehr großen Einfluss. Eine Selbsttestbibliothek, die die korrekte Funktion eines Mikrocontrollers sowohl zur Startphase als auch während der Laufzeit zyklisch prüft, kann zwar mit Aufwand selbst entwickelt werden. Aber ohne die genauen internen Kenntnisse des Mikrocontrollers kann man nicht die hohe Testabdeckung erreichen, die eine Selbsttestbibliothek des Mikrocontrollerhersteller oder eines Kooperationspartners erreicht. Für ausgewählte Mikrocontroller werden solche Bibliotheken angeboten, die nach Prozess entwickelt und getestet und somit für eine Zertifizierung vorbereitet sind. Üblicherweise stehen dann auch die detaillierten Fehleranalysen (FMEDA) zur Verfügung, die dann zur genauen Fehleranalyse des Gesamtsystems beitragen.
Andere Software-Komponenten werden von einigen Herstellern teilweise auch schon nach Prozess entwickelt und zertifiziert angeboten. Dies ist nicht immer nötig, da bei Mikrocontrollern mit MPU sichere Programmteile von unsicheren getrennt werden können. Eine Ausnahme bildet ein Echtzeit-Betriebssystem. Soll dieses voll genutzt werden und auch die sicherheitskritischen Tasks verwalten, dann muss es selbst sicher sein. Hier gibt es verschiedene Anbieter, wobei sich die Preise sehr unterscheiden. Die statistischen Fehler können erkannt werden, indem Kontrollmechanismen eingebaut werden (z.B. ein Analogwert wird redundant eingelesen oder ein Output Pin wird zurückgelesen), durch Redundanz (z.B. ein zweikanaliges System) oder auch durch Software-Maßnahmen wie Selbsttests. Wie bereits erwähnt, gibt es bereits Selbsttestbibliotheken für verschiedene Mikrocontroller. Für eigene Applikationsteile müssen diese selbst entwickelt werden unter Beachtung der Vermeidung von systematischen Fehlern wie oben erwähnt.
Immer mehr Systeme betroffen
Funktionale Sicherheit ist eine Anforderung, die bei mehr Komfort oder Funktionen immer mehr Embedded-Systeme betrifft. Für Neueinsteiger ist dies sehr schwer und aufwändig; hier ist geraten, sich Unterstützung von erfahrenen Experten zu holen. Auch die Auswahl der Komponenten in Hardware und Software und der Entwicklungswerkzeuge hat wesentlichen Einfluss auf den Erfolg und den Aufwand.
Der Autor
Dipl.-Physiker Dr. Kurt Böhringer |
---|
ist seit über 20 Jahren in der Embedded-Welt bei Hitex tätig. Als Head of Technology & Innovation ist er unter anderem mit dem Schwerpunktthema Funktionale Sicherheit beschäftigt. |
kurt.boehringer@hitex.de