Automotive Software Entwicklungsstandards minimieren Risiko von Fehlfunktionen

Automobile Software auf dem Prüfstand.
Automobile Software auf dem Prüfstand.

Mit immer mehr Elektronik im Fahrzeug nehmen auch Masse und Komplexität der automobilen Software zu. Dieser Artikel beleuchtet diverse Aspekte, die zur Komplexität von Automotive-Software beitragen, und die mit deren Entwicklung verbundenen Risiken.

Elektronische Systeme in Automobilen kommen mittlerweile schon seit Jahrzehnten für sicherheitskritische Funktionen zum Einsatz. Der Trend zum Internet of Things hat dazu geführt, dass Automobilhersteller eine noch größere Zahl komplexer Computersysteme einbauen, die hinsichtlich ihrer Sicherheitsrelevanz das gesamte Spektrum abdecken. Verschärft wird die Komplexität durch die geschäftlichen Strukturen und Lieferketten, die mit der Systementwicklung zusammenhängen. Wenn überhaupt, kommt es nur selten vor, dass ein Hersteller alle Komponenten und Subsysteme in seinen Autos von Grund auf selbst entwickelt und produziert. Potenzielle Integrationsprobleme sind die Folge. Ein Getriebe wird von dem einen Modell übernommen, ein gutes Bremssystem von einem anderen. Solche Teilsysteme mögen in ihrem früheren Umfeld reibungslos funktioniert haben, aber in einem grundlegend neuen, komplexen System kann es zu unerwünschten und unerwarteten Ergebnissen kommen. Automotive-Software ist deshalb oft ein komplexes Gemenge von Systemen, die nicht unbedingt alle hinreichend geprüft wurden. Die Implementierung von Komponenten gleichsam aus dem Stegreif und ohne angemessene Tests kann speziell in sicherheitskritischen Anwendungen extrem hohe Kosten verursachen.

Positiv zu vermelden ist, dass es bekannte Methoden gibt, mit denen Automobilhersteller Ausfallrisiken abmildern können, indem sie den Aspekt der Software-Qualität von Anfang an in die Entwicklungsprozesse einbetten.

Bedeutet mehr Code zwangsläufig ein höheres Risiko?

Schätzungen zufolge kann ein heutiges normales Mittelklasseauto deutlich über hundert elektronische Steuergeräte (Electronic Control Unit, ECU) enthalten, die Millionen von Code-Zeilen verarbeiten – und diese Zahl wächst weiter. Ebenso ist es nicht ungewöhnlich, dass ein Hersteller mehrere Automodelle mit mehr als hundert Millionen Code-Zeilen produziert. Es kommt der Eindruck auf, dass der Umfang der eingebauten Software umso größer ist, je teurer das Auto ist, und, dass der Großteil der Software auf die anspruchsvollen Infotainment-Komponenten entfällt. Tatsächlich werden die Systeme immer komplexer, je weiter man sich in der Modellpalette nach oben bewegt. Aber auch in den Einstiegsmodellen kommt Software im Lenk- und Bremssystem, bei der Verteilung der Stromversorgung usw. zum Einsatz. Außerdem führen auch scheinbar geringfügige Veränderungen der Feature-Ausstattung, wie etwa Bluetooth, Klimaregelung oder Tempomat, zu einer exponenziellen Zunahme des Code-Umfangs.

Man kann davon ausgehen, dass mehr Code zu höherer Komplexität und damit auch zu einem höheren Risiko führt. Allerdings muss das nicht unbedingt entscheidenden Einfluss haben. Ein großer Anteil an den mit Automotive-Software zusammenhängenden geschäftlichen Risiken liegt in der Integration von Code, der durch verschiedene Quellen auf unterschiedlichen Ebenen entwickelt wurde. Die meisten Komponenten, darunter auch ECU-basierte Teile, werden an Tier-2-Zulieferer vergeben, die ihrerseits mit Teilelieferanten zusammenarbeiten (Bild 1). Jede nächsthöhere Ebene stellt bestimmte Anforderungen im Zusammenhang mit den von ihr entwickelten Komponenten. Oft, aber durchaus nicht immer, wenden die Organisationen Methoden zur Analyse des zugelieferten Codes an, um die erwartungsgemäße Funktion der Komponenten sicherzustellen. Das setzt allerdings voraus, dass es sich bei allen Komponenten entlang der Lieferkette um Neuentwicklungen handelt. In Wirklichkeit aber zweigen die untergeordneten Ebenen Code ab, der für eine bestimmte Marke, ein bestimmtes Modell oder ein bestimmtes Modelljahr entwickelt wurde.

Die Tatsache, dass es entlang der gesamten Lieferkette zur Abwandlung und Wiederverwendung von Code kommt, führt zu einem Prüfproblem. Wie kann ein Hersteller in einem derart chaotischen Software-Entwicklungs-Ökosystem einen lückenlosen End-zu-End-Test implementieren? Welche Folgen hat es, wenn die ECU in der Lenkung ursprünglich für ein bestimmtes Fahrzeug entwickelt wurde, die ECU in der Armaturentafel aber für ein anderes? Folglich wurde in diesem Beispiel keine der ECUs für das Auto entwickelt, in das sie jetzt eingebaut werden. Wie lässt sich sicherstellen, dass das Gesamtsystem wie erwartet funktioniert? Es ist durchaus möglich, dass beide Systeme die Tests als funktionierend bestehen und dennoch nicht in der Lage sind, in allen Situationen reibungslos zu kommunizieren. Welche Risiken ergeben sich aus dieser Lücke?