Entwicklungsprozess für funktional sichere Steuergeräte Rundherum sicher

Steigende Anzahl der funktional sicheren Steuergeräte sorgen für konsequenten Entwicklungsprozess
Steigende Anzahl der funktional sicheren Steuergeräte sorgen für konsequenten Entwicklungsprozess

Mit der Anzahl der Steuergeräte im Fahrzeug steigt die Anzahl der Akteure, die an ihrer Entwicklung beteiligt sind. Oft arbeiten international verteilte Entwicklerteams aus mehreren Unternehmen parallel am gleichen Projekt. Funktionale Sicherheit ist in so einem kollaborativen Entwicklungsprozess eine Frage der Organisation.

Mehr und mehr Funktionen im Fahrzeug werden durch Software in elektronischen Steuergeräten realisiert. Auch die steuergeräteübergreifende Verknüpfung von Software-Funktionen nimmt stetig zu. In Modellen der Oberklasse sind es teils mehr als hundert Steuergeräte, die über Datenbusse vernetzt untereinander und mit den im Fahrzeug verteilten Sensoren kommunizieren. Zudem nimmt die Vernetzung nach außen rasch zu. Automobile werden zu Netzwerkknoten einer komplexen vernetzten Verkehrswelt.

Durch die Vernetzung mit der Außenwelt, die sensorische Überwachung des Fahrzeugumfeldes und die umfassende IT-gestützte Steuerung an Bord wird das Fahren sicherer und effizienter. Zugleich bergen die neuen Systeme aber auch Risiken. Denn mit der Anzahl und Vernetzung der Steuergeräte wächst die fachliche und organisatorische Komplexität bei deren Entwicklung. Schon am Entwicklungsprozess eines einzelnen Steuergeräts sind diverse, oft weltweit verstreute Akteure beteiligt: Neben Entwicklern und Applikateuren des Steuergeräteherstellers arbeiten auch dessen Zulieferer sowie Entwickler des Automobilherstellers an und mit dem Steuergerät. Sie alle sind auch an der Entwicklung der Steuergeräte-Software und der Bedatung beteiligt. So befassen sich etwa bei Motorsteuergeräten unterschiedliche Teams damit, Einspritzung, Luftzufuhr, Zündzeitpunkte und viele weitere Parameter für einen effizienten Motorbetrieb zu regeln. Oft greifen verschiedene Funktionen gleichzeitig auf Speicher und Prozessorleistung des Steuergeräts zu. Erschwert wird das Ganze zusätzlich, weil OEMs im Sinne der Liefersicherheit identische Steuergeräte für ein Fahrzeugmodell bei verschiedenen Zulieferern bestellen. Käufer sollen aber keinerlei Unterschiede im Fahrzeugverhalten spüren.

Sicherheit im kollaborativen Entwicklungsprozess

Trotz der komplexen Kollaboration im Entwicklungsprozess, trotz anteiliger Bedatung und über Steuergeräte verteilter Funktionen gilt es, die funktionale Sicherheit der Steuergeräte-Software zu gewährleisten. Über den gesamten Lebenszyklus des Fahrzeugs hinweg sind sicherheitskritische Fehler tabu. Das Zusammenspiel der Steuergeräte und Software-Anteile von unterschiedlichen Anbietern muss stets reibungslos funktionieren.

Um das zu erreichen, helfen Methoden wie die Virtualisierung. Sie ermöglicht es, Software in realistischen Strecken-, Umgebungs- und Fahrermodellen zu validieren. So können Entwickler Steuergeräte-Software in der Frühphase des Entwicklungsprozesses in virtueller Umgebung auf Herz und Nieren testen, indem sie zum Beispiel das Werkzeug Isolar-Eve von ETAS in Verbindung mit Simulationsmodellen am PC nutzen. Und das schon weit bevor Fahrzeuge produziert oder Steuergeräte als Prototyp vorliegen. Sie können sogar umfassender testen. Denn anders als im realen Fahrzeug bleiben Fehler im virtuellen Raum folgenlos. Das erlaubt es, bei der Auslegung sicherheitskritischer Assistenzsysteme Grenzbereiche zu erkunden. Fehler oder Fehlannahmen fallen im virtuellen Test früh auf und können behoben werden, ehe größerer Schaden entsteht.

Doch die Virtualisierung ist nur ein Baustein in einer umfassenderen Gesamtarchitektur. Tests allein können das Arbeiten in verteilten Teams nicht hinreichend absichern. Dafür gilt es, weiter auszuholen und den gesamten Entwicklungsprozess zu strukturieren (Bild 1). Sowohl in den Software-Architekturen als auch zwischen den mitwirkenden Teams sind von vornherein klare Hierarchien festzulegen. Nicht minder wichtig: ständiges Prozess-Monitoring. Denn auch wenn eine Sicherheitsphilosophie vereinbart ist, heißt das noch nicht, dass die Teams sie im hektischen Entwicklungsalltag befolgen oder sich ein einheitliches Verständnis der Vereinbarungen einstellt. Regelmäßige Audits und Assessments müssen das tatsächliche Vorgehen überprüfen und wo nötig nachjustieren. 

Feste Regeln für Software- und Entwicklungsprozesse

Nicht nur die Software und die Zugriffe auf Speicher und Prozessorleistung müssen also festen Regeln folgen, sondern auch der Entwicklungsprozess mit allen daran beteiligten Individuen und Organisationen. Die Grundlagen eines solchen Regelwerks finden sich in Normen wie der ISO 26262.

Der eigentliche Entwicklungsprozess beginnt mit der Definition von Items im Top-Down-Ansatz: Ausgehend von Gesamtsystem und Kontext nimmt er die vorhandenen Schnittstellen und die Interaktion mit anderen Systemen in den Fokus – und grenzt den Funktionsumfang ein. Ist das geschehen, folgt eine strukturierte Gefährdungs- und Risikoanalyse: Die Wahrscheinlichkeit und die Kontrollierbarkeit etwaiger Fehler sind dabei ebenso zu gewichten wie das drohende Schadensausmaß. Ziel der Analysen ist die Definition verbindlicher Sicherheitsziele.

Das Erreichen dieser Sicherheitsziele ist fortan für alle beteiligten Teams die Richtschnur der Entwicklung. An ihr richtet sich die Konzeption der praktischen Umsetzung aus. Das Erreichen dieser Sicherheitsziele ist fortan für alle beteiligten Teams die Richtschnur der Entwicklung. An ihr richtet sich die Konzeption der praktischen Umsetzung aus. Die Ziele werden dabei auf konkrete Arbeitspakete für die Arbeitsgruppen heruntergebrochen, ehe das Programmieren beginnt. 

Auch hier liegen Regeln und bewährte handwerkliche Methoden zugrunde. Orientierung an Best Practice, das Einhalten von Style Guides, strukturierte Dokumentation sowie regelmäßige dezidierte Reviews und Code-Analysen sind zu gewährleisten. Zudem gilt es, vorab sorgfältig zu planen, wann und wie die Software in welchen Kontexten getestet werden soll. Dazu gehören zwingend Fault Injection Tests, in denen die Reaktion der Software auf gezielt eingebrachte Fehler abgeprüft wird. Per Bypass Tool, etwa Ehooks von ETAS, speisen die Entwickler fehlerhafte Daten ein – wobei das im Gegensatz zu den frühen Tests mit der Isolar-Eve schon auf realer Hardware geschieht (Bild 2).

Das Wissen, in welchem Speicherbereich ein Steuergerät welche Funktion umsetzt, erlaubt es den Prüfingenieuren, über die Kalibrier- und Diagnose-Schnittstellen Fehler einzuschleusen und so interne Signale im Steuergerät zu ersetzen. Erzeugen lässt sich diese Fehl-Bedatung direkt an der Mess-, Applikations- und Diagnose-Software ETAS Inca.

Erst die Ausnahmesituation zeigt, ob Sicherheitsziele und Konzeption tragen – robuste Steuergeräte-Software muss Fehler erkennen und die sichere Funktion jederzeit aufrechterhalten.