Das moderne Automobil ist ein Konglomerat aus miteinander interagierenden elektromechanischen Systemen. Viele diese Systeme, wie zum Beispiel Bremsen, Lenkung, Antriebsstrang und Fahrassistenzsysteme, sind entscheidend für die Sicherheit und für Menschenleben, während dies für andere Anwendungen wie etwa die Unterhaltungselektronik nicht in so hohem Maße gilt. Alle Systeme aber stützen sich auf Software, deren Umfang exponentiell zunimmt, und in vielen Designs nutzen die Teilsysteme auch dieselbe interne Kommunikations-Infrastruktur. Dies führt dazu, dass bei der Entwicklung und Prüfung des Codes die funktionale Sicherheit berücksichtigt werden muss, und zwar sowohl für das System insgesamt als auch für die unabhängigen Teilmodule.

Zweck und Geltungsbereich der ISO 26262

Die ISO 26262 ist eine Norm für die funktionale Sicherheit von Straßenfahrzeugen. Sie definiert die Anforderungen und Prozesse zur Sicherstellung der funktionalen Sicherheit über ein Spektrum von Klassifizierungsstufen, die als „Automotive Safety Integrity Levels“ (ASIL) bezeichnet werden. Die ASILs legen die Maßnahmen zur Wahrung der funktionalen Sicherheit von Level A (geringste Gefährlichkeit) bis Level D (höchste Gefährlichkeit) fest. Der von der ISO 26262 spezifizierte Prozess beginnt bei den allgemeinen Anforderungen und umfasst die Spezifikation der eigentlichen Sicherheitsanforderungen, das Design der Softwarearchitektur sowie die eigentliche Codierung und Implementierung der Funktionsmodule. Hinzu kommen Schritte zum Testen und Verifizieren dieser Module.

Die notwendige detaillierte Spezifikation der Anforderungen an das Systemdesign und der Sicherheitsanforderungen kann auf einer recht abstrakten Ebene erfolgen, nämlich mit Spreadsheet- und Textverarbeitungs-Programmen, aber auch mit formelleren Anforderungsverwaltungs-Tools. Allerdings müssen diese Anforderungen Eingang in die einzelnen Softwarekomponenten finden, mit denen sie umgesetzt werden, sowie in die Verifikations-Aktivitäten, mit denen sie geprüft werden. Gemäß der ISO 26262 ist die bidirektionale Rückverfolgbarkeit entscheidend zur Gewährleistung eines transparenten und offenen Entwicklungs-Lebenszyklus. Wenn Code umgeschrieben werden muss, ist es außerdem wichtig zu verstehen, aus welcher übergeordneten Anforderung er abgeleitet wurde.

Design und Prüfbarkeit von Softwarearchitekturen

Auch wenn die Bezeichnung „Design for Testability“ ein oftmals überfrachteter Begriff ist, wird das zugrundeliegende Konzept in der ISO 26262 klar formuliert. Das in Abschnitt 7 der Norm behandelte Design der Softwarearchitektur zielt auf eine Softwarearchitektur, die den Anforderungen an die Softwaresicherheit genügt. In dieser frühen Phase werden häufig Modellierwerkzeuge genutzt, um den Lösungsraum für die Softwarearchitektur abzustecken. Einige Unternehmen setzen beim übergeordneten Design noch auf manuelle Methoden, das heißt auf Dokumente und abstrakte Codierung unter Weglassung des detaillierten Verhaltens.

Unabhängig von der verwendeten Methode ist es während des Designs und der Implementierung erforderlich, das Architekturdesign zu verifizieren. Bei niedrigeren ASILs wie A oder B können Techniken wie zum Beispiel informelle Begutachtungen und Inspektionen ausreichen. Geht es aber um die höheren ASILs C oder D, ermöglichen Automatisierungs-Techniken den Entwicklern kosteneffektive Architekturanalysen und -prüfungen, zu denen auch gründliche Kontroll- und Datenfluss-Analysen gehören. Letztendlich sollte das Architekturdesign gemäß der Norm ISO 26262 zu einer gut ausgearbeiteten Softwarearchitektur hinführen, die prüfbar ist und sich zu ihren Funktionssicherheits-Anforderungen zurückverfolgen lässt.

Die ISO 26262 verlangt ferner nach einer hierarchischen Strukturierung der Softwarekomponenten, und zwar für alle ASILs. Hinsichtlich der Qualität enthält die Norm exemplarische Richtlinien wie die folgenden:

  • Softwarekomponenten sollten in ihrer Größe beschränkt und lose mit anderen Komponenten gekoppelt sein.
  • Sämtliche Variablen müssen initialisiert werden.
  • Es sollten keine globalen Variablen verwendet werden, solange ihre Nutzung nicht gerechtfertigt ist.
  • Es sollte keine impliziten Typumwandlungen, unbedingten Sprünge oder verdeckte Daten- oder Kontrollflüsse geben.
  • Dynamische Objekte oder Variablen sind zu prüfen, sofern sie überhaupt verwendet werden.

Ohne Automation wäre es sehr mühsam, teuer und fehleranfällig, das jeweils implementierte Modul nach diesen Regeln und Empfehlungen zu prüfen.

Codierstandards und -richtlinien

Im Rahmen der Anforderungen der Norm ISO 26262 trägt die Implementierung der Softwaremodule zum Entstehen einer qualitativ hochwertigen Applikation bei, die sich besser prüfen lässt. Die ISO 26262 verlangt die Verwendung eines Codierstandard, ohne aber einen bestimmten Standard vorzuschreiben. In Frage kommende Standards und Richtlinien wie MISRA C:2012, MISRA C++:2008, SEI CERT C oder CWE haben alle das Ziel, potenzielle Safety- und Security-Risiken zu beseitigen. Sie werden dabei durch automatisierte Toolpakete unterstützt. Regelmäßig überprüfen und durchsetzen lassen sich die Codierrichtlinien mithilfe eines integrierten statischen Analysetools, das den Quellcode untersucht und alle Abweichungen vom gewählten Standard markiert.

ISO 26262

Bild 1: Zuordnung der Fähigkeiten einer automatisierten Toolchain zu den Prozessrichtlinien der ISO 26262. LDRA

Über die Einhaltung der Codierstandards hinaus, können vollintegrierte Softwaretools auch Richtlinien für das Qualitätsdesign von Softwaremodulen prüfen und durchsetzen und deren Integration und Prüfung gemäß der definierten Softwarearchitektur und den Systemanforderungen erleichtern. Die Anwendung und Durchsetzung solcher Prinzipien beim Codieren der einzelnen Module erhöht die Sicherheit, dass die Module innerhalb der definierten Softwarearchitektur zusammenpassen und miteinander funktionieren. Im Idealfall sollte ein integriertes Toolpaket diese automatisierten Funktionen so miteinander abgleichen, dass sie sich auf alle Entwicklungsstufen nach dem standardmäßigen V-Modell (Bild 1) anwenden lassen und in der Lage sind, die Rückverfolgbarkeit der Anforderungen, die Analyse und das Testen über alle Phasen der Produktentwicklung hinweg zu koordinieren.

Seite 1 von 3123