Ein Angebot von

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

| Autor / Redakteur: Dr. Joachim Schlosser* / Sebastian Gerstl

Automotive SPICE und die ISO 26262

Mit Automotive SPICE, seit jüngstem vorliegend in der Fassung 3.1 [2] und gemessen anhand der ISO 33020 [3], liegt ein Prozessreifegradmodell (engl. Process Maturity Model) vor, das bei der Bewertung von Entwicklungsprozessen hilft. Wer produktiv im Automobilsektor verwendete Systeme entwirft, kommt um Lektüre und Umsetzung dieser Norm nicht herum – eigentlich.

Die ISO/IEC 33020 legt bestimmte capability levels, also Ebenen der einzelnen Fähigkeiten fest, die in Summe zu einem bestimmten Reifegrad führen sollen. Dabei kommen in verschiedensten Entwicklungsprozess-Schritten eine Vielzahl von Forderungen zum Tragen.

Schon allein die Prozesslandkarte in Abbildung 1 (siehe Bildergalerie) macht deutlich, dass der Wirkungsbereich von Automotive SPICE nach ISO 33020 sehr weit reicht. Tatsächlich alle acht Arbeitsfelder ACQ, SYS, SWE, SUP, SPL, MAN, REU, PIM sind direkt relevant für die Qualität des auszuliefernden Systems. Dazu kommen in Automtive SPICE 3.1 noch zwei weitere Felder für Hardware und Mechanik.

Wer in die Übersicht der ISO 26262 in der 2018 erscheinenden zweiten Ausgabe in Abbildung 2 blickt, stellt fest, dass auch hier einige ähnlich lautende Prozessfelder verortet sind. Die für die System- und Softwareentwicklung relevanten Teile lassen sich nun in Überdeckung bringen, im ersten Schritt auf der Prozess- bzw. Kapitelebene.

Die Ergebnisse der tiefergehenden Abbildung von Automotive SPICE auf ISO 26262 und in Gegenrichtung zeigen eine mittlere bis gute Abdeckung für alle For-derungen der ISO 26262, bei denen „Funktionale Sicherheit“ nicht vornehmlich auf Architektureigenschaften abzielt.

Dass die Abbildung von ISO 26262 und Automotive SPICE aufeinander sinnvoll ist, weil erhebliche Überschneidungen bestehen, zeigen auch die Arbeiten im Rahmen des SOQRATES-Projekts [5] oder vergleichenden Studien [6].

Pragmatische Wirksamkeit: Prozessfelder unterscheiden

Ein Großteil dessen, was in der ISO 26262 steht, sind also eher allgemeine Qualitätsanforderungen, die sich so auch in Automotive SPICE finden.

Um was es hier größtenteils geht, ist „QM-Software“, die einfach nur ordentlich entwickelt werden soll. Entwicklung besteht eben nicht nur darin, Code hinzuschreiben, der etwas tut, sondern die wohldefinierte Vorgehensweise von Erfassung und Analyse der Anforderungen bis zu Integration und Test, und das ganze so nachvollziehbar, dass auch Jahre später noch herausgefunden werden kann, wie die Software und das System zustande kamen, mit welcher Qualität und auf Basis welcher Anforderungen und Entscheidungen.

Deshalb empfiehlt dieser Beitrag, die Anforderungen der ISO 26262 in zwei Prozessfelder zu unterscheiden.

1. Anforderungen hinsichtlich Funktionalität und Architektur

Hier geht es um funktionale Anforderungen und die Architektur des Systems. Dies beinhaltet eben nur die Anteile, die sich aus den besonderen sicherheitsrelevanten Anwendungsfällen ergeben. Hier sind Methoden zu verorten wie ASIL-Einstufung und sich daraus ergebende Sicherheitsanforderungen, verbunden mit den sich daraus ergebenden Anforderungen an die System- und Softwarearchitektur.

Die ISO 26262 fordert also inhaltliche Arbeit. Analysen sind vorgeschrieben, ein intensives Sich-Gedanken-Machen, wie denn das System bei Ausfall wichtiger Komponenten reagieren soll. Als Nachweis dieser Analysen und Gedanken stehen die „Work Products“ im Fokus, und positiv betrachtet als Arbeitshilfen.

Statt sich also zu beschweren, man müsse jetzt nur wegen der ISO mehr machen, lohnt es sich, oben nochmal nachzusehen, wozu wir Funktionale Sicherheit machen.

Das, was hier gemacht wird, ist tatsächlich eine direkte Folge der Einführung der Norm zur Funktionalen Sicherheit für bestimmte Funktionalitäten im Automobil, und bedeutet im Vergleich zu Entwicklung nicht sicherheitsgerichteter Systeme einen Mehraufwand.

Der Mehraufwand fällt zum großen Teil in der frühen Phase eines Systems an, in der Architektur und Design entworfen werden. Außer, und das ist ein großes „außer“, wenn die leider immer wieder anzutreffende „nachgelagerte Dokumentation“ oder noch härter „nachgelagerte FuSi“ praktiziert werden. Dann ist die ISO 26262 für alle Entwickler ein Riesenstress.

2. Anforderungen hinsichtlich Prozess und Qualität

Ein großer Teil der ISO 26262 verlangt jedoch Prozesse und deren Dokumentation, die sich nicht direkt mit der Funktionalität eines Systems auseinandersetzen. Stattdes-sen steht die Qualität im Fokus, und der Weg dahin. Den Forderungen liegen folgende Paradigmen zugrunde:

  • Absichtlichkeit (Intentionality),
  • Wiederholbarkeit (Reproducibility),
  • Nachverfolgbarkeit (Traceability).

Wie strikt die Paradigmen einzuhalten sind, hängt auch vom ASIL, dem Safety Integrity Level ab, also wie sicherheitskritisch ein System eingestuft ist.

Was sich in Entwicklungsorganisationen nach wie vor häufig findet, sind Vorgehensweisen, die eben mehrere oder gar viele der Paradigmen verletzen:

Da werden Softwarereleases mit viel manueller Arbeit aus schlecht gepflegten Versionierungssystemen erstellt, und wenn der Kunde einige Wochen später einen Fehler in einem bereits ausgelieferten Release meldet, schafft man es schwer bis gar nicht, das damalige Release nochmal exakt nachzubauen. Da werden Tests durchgeführt oder auch nicht, ohne Aufzeichnung welche gelaufen sind und mit welchem Ergebnis. Da ist ohne erheblichen Invest von Lebenszeit nicht mehr herauszufinden, wie sich die Ergebnisse und die Abdeckung durch Tests im Verlauf der Entwicklung verändern. Da werden Programmierregeln missachtet, aber entweder kein Werkzeug zur Codeanalyse eingesetzt oder die Regelverletzungen nicht systematisch ausgewertet. Da wer-den neue Features eingebaut auf Zweigen in der Versionierung, die auf einem zweifelhaften Stand der Softwareentwicklung aufbauen. Da werden Algorithmen und Strukturen im Code verwendet, ohne dass ersichtlich wäre, auf Basis welcher Anforderungen dies geschieht und ohne Chance herauszufinden, welche Tests diese abprüfen.

Das alles hat jedoch nur bedingt mit der funktionalen Sicherheit zu tun, hier geht es um Software Craftsmanship. Im Software Craftsmanship Manifesto [7], das auf die Aspekte des Handwerks von Software hinweist, heißt es beispielsweise: „Nicht nur funktionierende Software, sondern auch gut gefertigte Software.“

Nicht zufällig finden sich sowohl in Automotive SPICE als auch ISO 26262 Anforderungen an den Entwicklungsprozess, die auf gut gefertigte Software abzielen.

Software, bei der jeder Entwickler, jeder Tester, jeder daran beteiligte Ingenieur stolz sagen kann: „Ja, das habe ich gemacht. Heben Sie ruhig den Teppich hoch, auch darunter ist ordentlich gearbeitet. Ich bin stolz darauf und mir sicher, dass Sie, lieber Kunde, lange Freude daran haben werden.“

Was die Qualitätsanforderungen bringen sollen, ist nicht weniger als genau das: Qualität. Qualität, die Folgekosten in der Wartung reduziert. Qualität, die die Beteiligten strahlen lässt. Qualität, die sich im Kontext funktional sicherheitsgerichteter Systeme als risikomindernd für Anwender und Unternehmen auswirkt.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45783874 / Safety & Security)