Functional Safety Software Engineering: Problemfälle Prozesse & Qualität

Auch fast zehn Jahre nach der Verabschiedung von ISO 26262 wird Entwickeln unter dem Aspekt Funktionaler Sicherheit als sehr aufwändig wahrgenommen. Doch für diesen wahrgenommenen Mehraufwand sind meist Defizite in Prozessen und der Softwarequalität verantwortlich.

Viele Softwareentwickler und Projektleiter empfinden das Thema Funktionale Sicherheit, insbesondere die Erfüllung von Auflagen nach ISO 26262,auch zehn Jahre nach deren Einführung noch als sehr aufwändig. Entwicklungsabteilungen beklagen sich darüber, dass Functional Safety spätestens bei in ASIL-B eingestuften Anwendungen nicht nur viel Zusatzdokumentation verlangt, sondern auch viele neue Anforderungen an den Entwicklungsprozess stellte.

Natürlich hat eine Anforderung mit einer ASIL-Bewertung (Automotive Safety Integrity Level) einen großen Einfluss auf den Systementwurf, speziell die Architektur. Bestimmte Architekturmodelle müssen dokumentiert werden, Redundanzen werden notwendig, und die Auswahl von ausfallsicheren Hardwarekomponenten und robuster Softwarearchitektur beeinflussen sich gegenseitig.

Bildergalerie

Bezogen auf die Vorgehensweise der Softwareentwicklung jedoch ist das Klagen in großen Teilen Quatsch. Bis auf einige Artefakte und Anforderungen steht in der ISO 26262 nichts Neues drin. Funktionale Sicherheit ist eben auf Systemebene „das Richtige tun“ und unter dem Qualitätsaspekt „es richtig tun“. Was die Softwareentwicklung im Kontext Funktionaler Sicherheit anders macht, ist, dass nun tatsächlich mal nachgewiesen werden muss, dass das, was sich die Entwicklungsorganisationen in ihrem Qualitätsmanagement mal lose ausgedacht haben, auch tatsächlich umgesetzt und gelebt werden muss.

Wir alle tun uns mit Funktionaler Sicherheit deutlich leichter, wenn wir endlich anfangen, Softwarequalität ernst zu nehmen und uns an Engineering-Prinzipien zu erinnern, die wir schon im Informatik- oder Ingenieurs-Studium gelernt haben.

In diesem Beitrag pflücken wir auseinander, was tatsächlich spezifische Software-/System-Prozesserfordernisse durch Funktionale Sicherheit sind, und was eigentlich durch normale Software-Qualitätsprozesse sowieso schon da sein sollte, wenn wir ernsthaft Automotive Embedded Software und Systeme entwickeln.

Für hervorragende Diskussionen, Anregungen und Verbesserungen zu diesem Beitrag danke ich Cenk Yazer, Christoph Patzelt und Steffen Kuhn.

Eine fehlerhafte Wahrnehmung

„Ach du liebe Güte, wir müssen jetzt auch ISO 26262 machen.“ „Wir sind bei unserem ISO 26262 Assessment durchgefallen, der Auditor hat uns in den meisten Punkten ordentlich rasiert.“ „Seit unsere Komponente ASIL-B eingestuft wurde, ist alles so kompliziert geworden in der Entwicklung.“ „Wir kommen schon gar nicht mehr zum Entwickeln, es ist alles nur noch Funktionale Sicherheit.“ „In zwei Monaten ist das FuSi-Assessment, wie sollen wir das nur bis dahin hinkriegen?“

So oder so ähnlich hören wir Stimmen aus automobilen Entwicklungsorganisationen. Das Muster ist immer das gleiche: „Weil wir ISO 26262 berücksichtigen müssen, haben wir Probleme“. Das Muster der Wahrnehmung ist ebenso dominant wie falsch.

Die Relevanz der ISO 26262 [1] ist nicht der Grund für ungeplante Aufwände in der Entwicklung und die Probleme der Organisation, die sich daraus ergeben. Dazu lohnt es, sich anzusehen, was Normen sind.

Im Wort „Norm“ steckt „Normal“. Eine Norm erfindet nichts, eine Norm an sich ist keine technische Innovation. Eine Norm schreibt auf, was in einem Bereich mindestens gegeben sein sollte, damit verschiedene Parteien gut zusammenwirken können, oder damit Nutzer eines Systems nicht einem unnötigen Risiko ausgesetzt sind. Eine Norm ist noch nicht einmal darauf ausgerichtet, den größtmöglichen Nutzen für die Kunden zu erzielen, sondern dient oft schlicht der Schadensabwehr.

Was eine Norm mit sich bringt, ist bisweilen die Forderung, zu dokumentieren, was man getan hat, um der Norm Genüge zu tun. Jede Norm hat darüber hinaus auch Anteile, die bestimmte Prozeduren vorsehen, die sich aus dem Anwendungsbereich der Norm ergeben. Was Entwicklungsorganisationen darauf hin zu tun haben, ist diese Dokumentation sicherzustellen, und davor die Prozeduren zu durchlaufen, die explizit gefordert werden.

Die Prozeduren sind jedoch nicht für die Norm da, sondern für den Zweck der Norm. Das ist der erste wichtige Aspekt, den es im Hinterkopf zu behalten gilt: Wir kümmern uns nicht um funktionale Sicherheit, um der ISO 26262 willens. Wir kümmern uns um funktionale Sicherheit, um die Nutzer unserer Produkte vor Schaden an Leib und Leben zu bewahren.

Die ISO 26262 ist ein Mittel, kein Zweck. Verständlicherweise ist im täglichen, praktischen Einsatz der Norm viel mehr ein anderer Gedanke präsent: Im hoffentlich nicht eintretenden Schadensfall kann durch eine akribisch befolgte Norm das Risiko von Regressforderungen begrenzt werden, da dann eben nach Stand der Technik und den Regeln der Kunst das System so entworfen wurde, so dass der Entwicklungsorganisation kein Verschulden oder keine billigende Inkaufnahme von Schäden unterstellt werden kann.

Um dies zu gewährleisten, fordert die ISO 26262 bestimmte Merkmale sowohl einer sicherheitsgerichteten Risikoanalyse mit allen daraus abgeleiteten Handlungsschritten, als auch einer qualitativ hochwertigen Software- und Elektronikentwicklung

(ID:45788049)