Entwicklungsstandards für zuverlässige Automotive-Software

In den wenigsten Fällen entwickeln und fertigen Automobilhersteller alle Fahrzeugkomponenten von Grund auf neu und auch oft nicht selbst, weshalb Integrationsprobleme vorprogrammiert sind. So können Übernahmekomponenten aus unterschiedlichen Fahrzeugmodellen, wie beispielsweise Getriebe X und Bremssystem Y in ihrer bisherigen Umgebung einwandfrei funktioniert haben, integriert in einem vollkommen neuen komplexen Systemumfeld können sich jedoch ungewollte und unerwartete Betriebssituationen einstellen.

Bild 1: Mit dem Zuwachs von Software im Fahrzeug steigen die Anforderungen an deren Sicherheit und Qualität. Parasoft

Verschleppte Softwarefehler bergen Folgekosten

Von unterschiedlichen Quellen auf verschiedenen Ebenen entwickelter Code macht einen großen Anteil an den mit Automotive-Software zusammenhängenden unternehmerischen Risiken aus. Die meisten elektronischen Komponenten mit ECUs stammen von Tier-2-Auftragsentwicklern, die ihrerseits Aufträge an Tier-3-Unternehmen auslagern und so fort. Jede nächstniedrigere Ebene stellt spezifische Anforderungen an die von ihnen entwickelten Komponenten, und die jeweiligen Organisationen wenden oft, aber nicht immer Verfahrensweisen zur Analyse von zugeliefertem Code an, um zu verifizieren, dass die Komponenten wie erwartet funktionieren.

Dies würde voraussetzen, dass jede Komponente entlang der Lieferkette eine Neuentwicklung ist. Tatsächlich aber zweigen die niedrigeren Ebenen einen Teil des für eine bestimmte Marke, ein bestimmtes Modell und ein bestimmtes Modelljahr entwickelten Codes ab.

Wenn Unternehmen versuchen, die Kosten der Softwareentwicklung zu berechnen, betrachten sie gerne allgemeine Messzahlen, wie etwa die Entwicklungszeit der Ingenieure, die Prüfzeit für die Qualitätssicherung sowie Arbeitsmaterial in Form von Tool-Lizenzen, Compilern und anderen Infrastruktur-Komponenten. So wichtig die finanzielle Bilanz auch ist, einen noch höheren Stellenwert hat die Tatsache, dass Menschen durch einen Softwarefehler tödliche Verletzungen erleiden können. Dabei spielt es keine Rolle, wie tief in der Lieferkette der Fehler seinen Ursprung hat, denn letztendlich ist der Automobilhersteller für alle Fehlfunktionen und deren Folgewirkungen verantwortlich. Entsprechend sind bei allen Kostenanalysen, die mit der Softwareentwicklung zu tun haben, die potenziellen Kosten für etwaige Defekte ins Kalkül zu ziehen.

Fehlende Disziplin in der Softwareentwicklung

Neben der Komplexität, die zu höheren Risiken für sicherheitskritische Systeme führt und die daraus resultierenden potenziellen Kosten für die Automobilhersteller gibt es noch eine weitere Dimension, die aus dem kulturellen Unterschied zwischen Technik und Softwareentwicklung resultiert.

Softwareentwicklung hat so gut wie niemals etwas mit Technik zu tun. Bestimmte Konzepte aus technischen Prinzipien, wie zum Beispiel Reproduzierbarkeit, sorgfältig ausgeführte erprobte Verfahrensweisen und die Anwendung von Entwurfsnormen, haben in der Softwareentwicklung noch nicht wirklich Fuß gefasst. Auch ist die Schulung von Programmierern häufig uneinheitlich, wenn es überhaupt eine gibt. Firmen müssten große Anstrengungen unternehmen, um zu verifizieren, dass ihre Entwickler über hinreichende Kenntnisse für die Entwicklung sicherheitskritischer Software verfügen.

Dies steht in krassem Gegensatz zur Technikwelt. Hier erzwingen Einstellung, Mentalität und Werdegang der Disziplin eine Vorgehensweise, die verglichen mit der Softwareentwicklung weniger defektanfällig ist. Das bedeutet quasi, die Automobiltechnik ist zweimal so ausgereift wie die Softwareentwicklung. Zudem fördert das nicht greifbare, temporäre Wesen der Software die etwas anmaßende Haltung, dass ein Produkt dann fertig ist, wenn es funktioniert.

Bild 2: Das Flußdiagramm zeigt den Software-Entwicklungs-Lebens-Zyklus (SDLC), wie ihn die Norm ISO26262 definiert. Parasoft

Programmierstandards als Leitlinie

Bei der Programmierung geht es um schnellere Ablieferung und funktionale Anforderungen. Hier steht die Frage im Raum: „Wie schnell können wir diese Funktionalität umsetzen?“. Das Management bietet leider kaum Anreize, um bei der Softwareentwicklung solide technische Praktiken anzuwenden. Wenn aber funktionale Sicherheit im Code verankert werden soll, gilt es bestimmte technische Prinzipien in die Arbeitsweise einzubinden:

• Funktionale Sicherheit muss proaktiv sein
• Prozesse müssen kontrollierbar, messbar und reproduzierbar sein
• Defekte sind durch die Implementierung von Normen zu vermeiden
• Tests müssen effektiv und deterministisch sein
• Tests sollten bei komplexen Speicherproblemen zur Anwendung kommen

Positiv ist, dass sich die Einstellungen im Umfeld der Programmierung weiterentwickelt haben. ISO 26262, MISRA und andere Standards streben eine Vereinheitlichung der Softwareentwicklung für Automotive-Anwendungen an, indem sie eine Grundlage für die Umsetzung von Konzepten aus der Technik in Softwareentwicklungs-Prozessen schaffen. Manche Unternehmen betrachten die Konformität zur Norm ISO 26262 (Straßenfahrzeuge – Funktionale Sicherheit) als eine den Aufwand in die Höhe treibende Bürde, die keinen unmittelbaren Nutzen hat. Fakt ist aber, dass die Kosten für Ausfälle, die auf Softwarefehler zurückzuführen sind, deutlich höher sind, als die Aufwendungen für die Qualitätssicherung. Ebenso wie elektrotechnische Normen einen bestimmten Leiterquerschnitt für eine bestimmte Stromstärke vorschreiben, könnten auch Programmierstandards als Leitlinien zur Abwendung von Katastrophen dienen.

Umsetzung von ISO 26262 und MISRA

Die Konformität zu ISO 26262 und MISRA zu erzielen, beginnt mit der Einhaltung der entsprechenden „Best Practice“ in Form einer Methode. Diese ist nicht mit einer Richtlinie gleichzusetzen, die ein bestimmtes Verhalten vorschlägt oder empfiehlt. Stattdessen zielt dieses Vorgehen auf eine automatisch umsetzbare Aussage, die in normaler Sprache ausdrückt, wie Software zu entwickeln ist. Diese Methode muss explizit festlegen, dass Software gemäß dem SDLC (Software Development Life Cycle) nach der Definition der Norm ISO 26262 zu entwickeln ist, und dass eine Verwendung von Programmcode vorgeschalteter Auftragnehmer ohne hinreichende Rückverfolgbarkeit zum Nachweis der Normkonformität untersagt ist (Bild 2).

Die Entwicklungs-Methoden sollten in ähnlicher Sprache abgefasst sein, um die Konformität zu den MISRA-Codierrichtlinien zu spezifizieren. Dies nämlich bietet dem jeweiligen Hersteller eine andere Art der Abnahmeprüfung, wodurch sich Software von vorgeschalteten Anbietern zertifizieren lässt (Bild 3).

In Bezug auf die Funktion bedeutet dies die Anwendung von Entwicklungstest-Aktivitäten, um sicherzustellen, dass der Code gemäß diesen Methoden entsteht. Auf dem Markt sind mehrere Hilfsprogramme erhältlich, welche die MISRA-Richtlinien in Form von Regeln für die statische Analyse umsetzen. Jedes Tool beinhaltet seine eigene Methodik zur Umsetzung von Codierstandards, sodass man selbst herausfinden muss, welches Tool für die eigene Entwicklungsumgebung und das verfügbare Budget am besten passt.

Bild 3: Das MISRA Dashboard der Entwicklungs-Test-Tools von Parasoft verschafft Entwicklern und dem Management einen schnellen Überblick zur MISRA-Konformität ihrer Lösung. Parasoft

Statische Analyse und Code Reviews

Bei knappen Entwicklungs-Ressourcen ist die statische Analyse ein kosteneffektiver Weg, einfache Softwarefehler im Code aufzudecken. Modulweise Tests sind trotz der vielen automatischen Testgenerierungs-Lösungen ressourcenintensiver und wesentlich teurer. Dahinter steckt die Pflege, die Parametrisierungen, die Grenzfälle und weitere Aspekte dieser Tätigkeit, die nach menschlicher Intelligenz verlangen. Trotzdem sind die Kosten potenzieller Ausfälle immer noch weit höher als die für das Testen entstehenden Aufwendungen.

Das Peer Code Review verlangt vom Softwareentwickler im Rahmen des Entwicklungsprozesses eine abschnittsweise Code-Prüfung (beispielsweise nach jeweils 200 bis 400 Code-Zeilen). Diese sehr effektive Möglichkeit zur Sicherstellung der Softwarequalität bedarf zwar auch Ressourcen, die Kosten sind jedoch vernachlässigbar, wenn sich dadurch ein Defekt vermeiden lässt, der einen Rückruf verursacht hätte.

Laufzeit-Fehlererkennung mit Abdeckungsanalyse

Eine Überwachung während der Codeausführung, spürt Konstrukte auf, die sich nur zur Laufzeit äußern – so etwas sollte im Validierungs- und Verifikationsprozess implementiert sein. Runtime Error Detection (RED) hilft beim Auffinden von Codesequenzen, die zu schwierig aufzufindenden Fehlern (Race Conditions, Exceptions, Ressoeurcen- und Speicherlecks, Sicherheitslücken) führen können.

Ohne eine Aussage darüber, wieviel Code die Tests letztendlich abdecken, lässt sich nicht beurteilen, ob der Testumfang hinreichend war. Die Coverage-Analyse selbst leistet nicht sehr viel, aber in Verbindung mit Tests kann sie unschätzbar wertvolle Informationen über die Software beisteuern.

Risikominimierung durch standardisiert entwickelte Software

Software nimmt einen wachsenden Stellenwert ein, je intelligenter moderne Produkte werden. Insbesondere in der Automobilentwicklung ergeben sich diesbezüglich Herausforderung in punkto Gewährleistung der Sicherheit (funktional wie auch auf Datenebene) und Zuverlässigkeit von embedded Anwendungen. Im Automotive-Bereich vermengt sich sicherheitskritischer Programmcode mit anderer Software, die Alleinstellungsmerkmale begründet. Zudem erfolgt die Entwicklung auf sehr dezentrale Weise über mehrere Unterlieferanten.

Lückenlose End-zu-End-Tests von Automotive-Anwendungen sind häufig zu teuer und zu komplex – trotzdem sollten die mit Softwareausfällen verbundenen Kosten ein triftiger Grund dafür sein, Möglichkeiten zur Risikominimierung zu finden. Hier bieten Entwicklungsstandards wie ISO 26262 oder MISRA wertvolle Unterstützung. Durch ihre Anwendung können Automobilhersteller optimale Voraussetzungen schaffen, um Risiken aufgrund von fehlerhafter Software zu vermeiden.

(jwa)