Mann mit Karte in der Hand kratzt sich am Kopf

Was funktionale Sicherheit nicht ist: häufige Missverständnisse

Lesezeit 2 min

Funktionale Sicherheit ist von einigen Mythen umgeben, häufig ist nicht klar was man überhaupt machen muss oder es gibt andere falsche Vorstellungen. Die folgenden Missverständnisse versuchen wir hier auszuräumen:

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.

Nehmen Sie mit mir Kontakt auf, wenn Sie keinen Missverständnissen unterliegen möchten.

Andreas Stucki

Was ist Ihre Meinung? Bitte kommentieren Sie hier!

Stichworte/ Tags

Kommentare

Keine Kommentare

Was ist Ihre Meinung?

* Diese Felder sind erforderlich

Teilen auf

Lassen Sie uns Ihre Idee/ Ihr Projekt diskutieren