Deutsche BlogsISO26262

Re-Use Szenarien in ISO 26262 (Teil 2)

Im Teil 1 habe ich die Vielfalt von verschiedenen Re-Use Szenarien dargestellt. Im Teil gehe ich nun auf konkreten Maßnahmen ein, die den Re-Use von Software erfolgreich machen.

Fall 1: Software erfüllt die ISO26262, 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. Es müssen im Wesentlichen die Artifakte aus der vorangegangenen Entwicklung 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.

Teil2_Bild1Die 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 ISO26262, 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.

Teil2_Bild2Fall 2: Software erfüllt die ISO26262, 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 ISO26262 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üssten. 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.

Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: martin.heininger[at]heicon-ulm.de
Einen unverbindlichen Überblick über die Leistungen finden sie auch auf der
HEICON Homepage.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

This site uses Akismet to reduce spam. Learn how your comment data is processed.