München. Software ist in modernen Fahrzeugen heute nicht mehr wegzudenken. Und so kommen die Softwarespezialisten der Daimler-Forschung mit ihren Teams immer dann zum Einsatz, wenn es bei der Entwicklung eines neuen Fahrzeugmodells unerwartete Probleme mit der Software von elektronischen Steuergeräten gibt. Die elektronischen Brandherde, zu denen die Spezialisten aus der Vorentwicklung gerufen werden, können harmlose Störungen im Steuergerät eines Telematiksystems sein, dessen Bildschirm sich im Navigationsmodus nur im Zeitlupentempo Zeile für Zeile aufbaut oder beim Aktivieren des Telefons plötzlich ganz ausfällt. Es können aber auch gravierende Fehler auftreten, die unter Umständen die Motorsteuerung oder das Getriebemanagement beeinflussen.
Würde man die Anforderungsprofile aller Steuergeräte eines Autos ausdrucken, erhielte man ein Lastenheft, das bis zu 500 gut gefüllte Ordner umfassen würde. Berücksichtigt man zudem, dass fast alle Steuergeräte oder Controller in irgendeiner Form miteinander kommunizieren, wird deutlich, dass in der Entwicklungsphase eines Fahrzeugs immer wieder Unstimmigkeiten auftreten können. „Die meisten Steuergeräte werden zusammen mit der Software von spezialisierten Zulieferern nach Vorgaben der Fahrzeughersteller entwickelt und produziert“, heißt es bei Daimler. Bei besonders wettbewerbskritischer Software, wie etwa beim Antriebsstrang für einen Lkw, entwickelt Daimler die entsprechenden Quellcodes allerdings selbst. Ein Ansatz, mögliche Schwachstellen in Steuergeräten aufzuspüren, ist die Code- oder Software- Analyse. Dabei wird der Quellcode mit speziellen Analyseprogrammen untersucht, um dort Fehler und Unstimmigkeiten aufzudecken.
Der Quellcode für ein Steuergerät würde ausgeduckt Tausende eng bedruckter Seiten füllen – eine für einen einzelnen Menschen unüberschaubare Datenflut. Daher lassen die Softwareprüfer den Quellcode über unterschiedliche Codeanalyse- Programme laufen. Diese Programme erkennen Fehler wie zum Beispiel eine Division durch null, aber auch Programmteile, die nie ausgeführt werden, oder einen falschen Speicherzugriff. Beim Abschluss einer Codeanalyse steht eine Liste aller entdeckten Fehler und Unstimmigkeiten zur Verfügung, mit deren Hilfe die Spezialisten anschließend mit der Fehlerbehebung beginnen. Das macht der Fahrzeughersteller in der Regel nicht selbst, sondern gibt den Softwareentwicklern bei den Zulieferern entsprechende Hinweise zur Fehlerbehebung. In der Praxis sieht das häufig so aus, dass die Codeanalysten bei Daimler einige Tage bei den entsprechenden Zulieferern vor Ort sind, dort mit sogenannten Feuerwehrprogrammen die Quellcodes untersuchen und ihre Empfehlungen aussprechen.
Die Codes selbst bleiben dabei immer bei den Zulieferern, da die jeweilige Steuergerätesoftware deren geistiges Eigentum ist. Bei einer Codeanalyse wird das Programm, also der Quellcode, lediglich betrachtet und nicht in einem Prüfverfahren ausgeführt. Da durch Funktionalitätstests nicht alle möglichen Fehlerkombinationen aufgedeckt werden können, wird die Codeanalyse durchgeführt, um grundsätzliche Fehler lokalisieren zu können. Die Software selbst muss in jedem Fall fehlerfrei sein. Spielraum gibt es für die Experten bei einer Codeanalyse deshalb nur bei der Frage, wie exakt die formalen Regeln eingehalten werden müssen. Diese Frage stellte sich auch bei einem Common Powertrain Controller (CPC), einem Steuergerät, das bei leichten und schweren Lkw und Bussen zum Einsatz kommt. Da kaum ein Nutzfahrzeug einem anderen gleicht und deshalb auch die Elektronik sehr unterschiedlich ausfällt, muss ein CPC viele Varianten abbilden können. Trotzdem muss er zuverlässig mit den rund 30 weiteren Nutzfahrzeug-Steuergeräten kommunizieren. „Es kamen aber immer wieder Laufzeitfehler vor, wobei unbekannt war, wann und wo diese Fehler verursacht wurden“, erinnern sich die Softwarespezialisten bei Daimler. Weil sich die Fehler nicht reproduzieren ließen, war eine Codeanalyse der sehr umfangreichen Software notwendig, in deren Verlauf die Ursachen gefunden und behoben wurden.
Wenn Software im Lauf der Jahre immer weiterentwickelt wird, hat dieses organische Wachstum oft zur Folge, dass das Programmpaket allmählich unübersichtlich wird, erläutern die Spezialisten des Pkwund Lkw-Bauers. Die Software funktioniert dann zwar noch in weiten Umfängen, aber es werden unter Umständen nicht mehr benötigte Algorithmen mitgeschleppt. Unerklärliche Fehler treten auf, und für neue Mitarbeiter ist der ursprüngliche Quellcode kaum noch nachvollziehbar. Die Folge: Irgendwann können keine neuen Funktionen mehr integriert werden, ohne dass es zu weiteren Fehlern kommt. In Fällen dieser Art hilft eine Codeanalyse allein nicht mehr weiter. Die Daimler-Forscher machen sich dann an das sogenannte Software- Reengineering, also die Neuorganisation ganzer Programme. Ein Beispiel dafür ist die elektronische Differenzschlupfregelung (DSR), wie sie bei Bussen und den Mercedes- Benz-Trucks Atego, Axor und Actros zu finden ist. Mithilfe der DSR wird anhand der Raddrehzahlen die Achslastverteilung errechnet und die Bremskraft optimal verteilt.
Für die Experten gab es genügend Gründe, das Softwarepaket aufzuschnüren und neu zu strukturieren. Zum einen war die 1987 im Actros eingeführte DSR-Software im Lauf der Jahre gewachsen und sollte nun neu geordnet werden, um sie künftig besser warten und erweitern zu können. Ziele waren eine höhere und kostengünstige interne Wiederverwendung, die Reduktion von Fehlerrisiken und schließlich die Möglichkeit zur schnelleren Erweiterung um neue Zusatzfunktionen. Zum anderen wünschten sich die Nutzfahrzeug-Entwickler einen zweiten Zulieferer, dem man das Know-how klar strukturiert zur Verfügung stellen wollte. Bei diesem Projekt wurden einige Softwareelemente aus dem Paket entfernt. Der Großteil der Funktionalität aber wurde beibehalten und neu strukturiert. „Bei einem solchen Software-Umbau wollen wir ja nicht das Rad neu erfinden, sondern bewährte Algorithmen in eine tragfähige Form überführen und so dokumentieren, dass sie auch für neue Mitarbeiter nachvollziehbar ist“, erläutert ein Softwarespezialist. Dass die Arbeit der Forscher bei ihren Kollegen in der Nutzfahrzeug- Entwicklung auf fruchtbaren Boden fällt, zeigt das Beispiel Differenzschlupfregelung.
Mithilfe der Softwareexperten aus der Forschung ist es den nachgeordneten Entwicklern möglich, die aktuelle Seriensoftware in kleine, klar überschaubare Teile zu trennen. Dadurch können sich die Spezialisten aus der Forschung verstärkt auf den Kern der Anwendung, konkret die Hardware- unabhängige Funktionsentwicklung, konzentrieren. Ziel der Forscher ist es, durch Reengineering saubere Software- Architekturen zu schaffen. Bisher erfolgt ein solcher Programmumbau meist in einem späten Stadium, in dem die Strukturen oft schon sehr unübersichtlich sind und einen hohen Einsatz an Zeit und Personal verlangen. Die Teams, die sich bei Daimler mit Software- Strukturen beschäftigen, arbeiten deshalb auch an Methoden, mit denen sich das Reengineering zumindest ein Stück weit automatisieren lässt. Das Wunschbild der Spezialisten: ein Softwareumbau auf Knopfdruck.
