Im Beitrag Re-Use Szenarien in ISO 26262 (Teil 1) habe ich die Vielfalt von verschiedenen Re-Use Szenarien dargestellt. Im folgenden Beitrag gehe ich auf konkreten Maßnahmen ein, die den Re-Use von Software erfolgreich machen.

Fall 1: Software erfüllt die ISO 26262, neues System hat gleichen ASIL Level

Hier gehen wir davon aus, dass eine bestehende Software schon die ISO 26262 erfüllt. Es ist nun angedacht diese Softwar unverändert in ein neues System zu übernehmen. Der ASIL bleibt gleich. Für diesen Fall definiert die ISO 26262, Teil 8 „Qualifikation von Software Komponenten“ die zu erledigenden Aufgaben. Die Artifakte aus der vorangegangenen Entwicklung müssen geprüft werden, in wie weit sie auch für den neuen Einsatz der Software gültig und vollständig sind. Im Idealfall ist das Ergebnis dieser Prüfung, dass alle Artifakte ohne Änderung übernommen werden können. Gemäß ISO 26262, Teil 6 „Integration und Testen“ sind dann aber noch Integrationstests notwendig um nachzuweisen, dass die Software auch in der neuen Umgebung fehlerfrei funktioniert.

Die Selbstzerstörung der Ariane 5 kurz nach dem Start am 04.06.1996, ist ein Beispiel das zwar aus einer anderen Branche stammt, aber es zeigt welche Fehler unentdeckt bleiben können, wenn Software in ein neues System übernommen wird, die Integrationstests aber unvollständig bleiben. Die Ursache des Absturzes damals war ein Speicherüberlauf bei Umrechnung der horizontalen Geschwindigkeit von 64-Bit-Gleitkommazahl in 16-Bit-Wert. Bei dieser Umrechnung kam es zu einem Überlauf des 16-Bit-Wertes, weil die neue Rakete deutlich höhere horizontale Geschwindigkeitswerte hatte, als das Vorgängermodell. Die Software war dafür nicht ausgelegt.

Fall 1a: Software erfüllt die ISO 26262, wird aber verändert, neues System hat gleichen ASIL Level

Für den Fall das zwar die bestehende Software nach ISO26262 entwickelt wurde, der ASIL gleich bleibt, aber die Software verändert wird, kann man Teil 8 „Qualifikation von Software Komponenten“ nur noch teilweise anwenden. In diesem Fall wird man Artifakte für den Teil der Software der unverändert bleibt wiederverwenden. Zusätzlich wird dann aber eine Einflussanalyse erstellt, die die Auswirkungen der Änderungen analysiert. Bei komplexen Änderungen wird das Ergebniss der Analyse allerdings ergeben, dass große Teile der bestehenden Artifakte zur Erfüllung der ISO26262 angepasst werden müssen. Wenn die Änderungen der Software auch neue Teile enthält müssen diese entsprechenden den Forderungen der Norm neu erstellt werden. Wie auch im obigen Fall, werden auch hier Integrationstests ganz sicher notwendig sein.

Fall 2: Software erfüllt die ISO 26262, neues System hat höheren ASIL Level

Der Unterschied zum ersten Fall liegt hier darin, dass das neue System einen höheren ASIL erfüllen muss. Die vorhandene Software wurde für einen niedrigeren ASIL Level entwickelt. In diesem Fall muss eine Analyse der ISO26262 durchgeführt werden um zu identifizieren, welche Artifakte zusätzlich erstellt werden müssen. Es kann auch sein, dass bestehende Artifakte zur Erfüllung des höheren ASIL angepasst werden müssen.

Beispielsweise kann die Analyse ergeben, dass Reviews die als Walkthrough durchgeführten wurden (Ausreichend für ASIL A), nun in Form einer Inspektion neu zu erstellt werden müssen (notwendig bei ASIL B, C und D).
Ein weiteres Beispiel ist die notwendige strukturelle Coverage des Source Codes. Für ASIL B und C genügt die Branch Coverage. Für ASIL D wird die MC/DC gefordert.

Fall 3: Software wurde vor Inkrafttreten der ISO 26262 entwickelt

Dieser Fall ist sehr einfach. Für so eine Software gilt die ISO26262 nicht und muss daher auch nicht angewendet werden.
Allerdings ist klar, dass der Fall immer seltener wird, da die Norm inzwischen schon einige Jahre (seit 2011) in Kraft ist. Als man die ISO 26262 eingführt hat wollte man vermeinden, dass die zu diesem Zeitpunkt breits bestehende Systeme nachträglich an die Norm angepasst werden müssen. Das war die Intension dieser Regelung.

Fall 4: COTS Software

Für Commercial off-the-shelf (COTS) Software, die im Autombil eingesetzt wird ist denkbar, dass man das sogenannte „Proven in Use Argument“ (ISO26262, Teil 8) anwenden kann. Für solche Software ist es oft nahezu unmöglich, die notwendigen Artifakte der ISO26262 zu erstellen. Der Grund ist, dass man meist keinen Zugang zum Source Code hat.
Da kann das das Proven in Use Argument eine sehr hilfreiche Möglichkeit sein, um die Forderungen der Norm erfüllen zu können.
Allerdings sind die Forderungen für diesen Fall in der Norm recht anspruchsvoll:

• Es muss gezeigt werden, dass Felddaten während eines definierten Beobachtungszeitraums zur Verfügung stehen, die tatsächlich relevant sind (Detaillierte Analyse muss durchgeführt werden).
• Sofern Änderungen vorgenommen worden sind im Beobachtungszeitraum, dann muss nachgewiesen werden, dass diese Änderungen keinen Einfluss haben auf die Relevanz der Daten
• Es müssen Methoden zur systematischen Integration angewendet werden
• Es muss eine Begründung für die Berechnung des Beobachtungszeitraumes (Service Period) gegeben werden

Fazit

>Der zweite Teil des Blogs hat gezeigt, dass für die verschiedenen Re-Use Szenarien eindeutige Maßnahmen definiert sind, die zu erfüllen sind.
Abschließend kann festgestellt werden, dass man von einem Re-Use aus wirtschaftlicher Sicht nur profitieren kann, wenn sowohl ein professionelles Konfigurationsmanagement vorhanden ist, als auch ein sehr hoher Grad von Testautomatisierung.

Weitere HEICON Blog Beiträge zum Thema

• Re-Use Szenarien in der ISO26262 (Teil 1)
• Guter Safety Software Entwicklungsprozess – Was ist das?
• Funktionale Sicherheit – Was ist das?

Ihre individuellen Fragen zur praktischen Umsetzung der ISO 26262 beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).