Was funktionale Sicherheit nicht ist

Wir haben eine FMEDA gemacht, nun ist das Produkt sicher!

In der Entwicklung für funktionale Sicherheit geht es darum, Fehler im Produkt zu vermeiden und zu entdecken. Es gibt zwei Arten von Fehlern: systematische und zufällige Fehler.

Die zufälligen Fehler werden in quantitativen (d.h. auf Ausfallraten basierten) FMEA Varianten (FMEDA, FMECA...) für die Hardwarekomponenten berechnet und minimiert. Das ist jedoch nur ein verschwindend kleiner Anteil der Aufgaben für funktionale Sicherheit.

Der grössere Teil befasst sich mit systematischen Fehlern der Software und auch der Hardware, d.h. damit, Entwicklungsfehler zu minimieren. Dies geschieht durch Requirements-/ Anforderungsmanagement, Reviews, Tests u.v.a.m. Wenn jemand sein Produkt als sicher anpreist, weil eine FMEA gemacht wurde, dann ist es noch ein langer Weg bis das Produkt wirklich funktional sicher ist.

Am Schluss gehen wir mit dem Produkt zum TÜV, der macht dann die Plakette drauf!

In Diskussionen um funktionale Sicherheit taucht manchmal die Meinung auf, dass man das Produkt "wie normal" entwickeln kann oder sogar ein bestehendes Produkt nehmen kann. Dann macht man etwas Dokumentation, geht zur benannten Stelle ("Notified Body") der Wahl und die geben dann eine "SIL Plakette".

In Realität müssen so viele Aktivitäten zusätzlich durchgeführt werden, dass das Produkt eigentlich neu entwickelt wird. Und vor allem sollte man die funktionale Sicherheit von Anfang an einplanen, da sich deren Anforderungen auf das ganze Systemdesign, Softwaredesign und auch das Hardwaredesign auswirken.

Das Produkt ist fertig, lasst es uns sicher machen!

Ein ähnlicher Fall ist es, wenn der Anspruch an funktionale Sicherheit erst auftaucht, wenn das Produkt schon fertig entwickelt ist. Oder ein bestehendes Produkt sollte nun mit einem SIL, einem PL verkauft werden.

In fast allen Fälle bedeutet eine solche Situation, das Produkt komplett neu zu entwickeln, da viele Aspekte der funktionale Sicherheit sich auf die Hard- und Softwarearchitektur auswirken. Z.B. auf Isolation von Kanälen voneinander, auf Software-Architekturen ohne "Hidden Data Flow", sogar auf die Wahl der Programmiersprache und der Komponenten (ohne Safety Manual des Hersteller geht da leider nichts, man kann also nur eine eingeschränkte Auswahl verwenden). Daher macht es mehr Sinn, von Anfang an die funktionale Sicherheit im Projekt einzubeziehen, dann gibt es am Ende keine massiven Korrekturen mehr.

Was sich hingegen lohnen kann sind Rapid Prototypen oder Funktionsmuster, um Risiken zu minimieren. Diese erlauben es, auch Sicherheitsaspekte (z.B.: reicht die Rechenleistung für die Sicherheitsmechanismen?) vorab abzuklären.

Wir haben MISRA und Code Coverage, also ist unsere Software sicher!

Wenn man Marketing-Material von Software (Betriebssysteme, Bibliotheken...) oder embedded Produkten anschaut, Statements von Startups und auch von Open-Source Projekten, dann findet man die Aussage, dass die Software funktional sicher sei. Denn man habe sich an die MISRA Codierregeln gehalten, man habe vollständige Code Coverage mit Unit Tests erreicht oder die Software erfülle andere Metriken (wie maximale Cyclomatic Complexity).

Diese Aktivitäten sind notwendig, aber bei weitem nicht hinreichend , um eine Software sicher zu machen. Zur Vermeidung von systematischen Fehlern gehören viele zusätzliche Aktivitäten und v.a. Reviews...

Andreas Stucki

Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!