In Hardware-in-the-Loop-Prüfständen lässt sich die Funktionalität vernetzter Komponenten – hier die Lkw-Lichtanlage – in einem vom Computer simulierten Fahrzeug testen.
 

Es ist nur ein kurzer Moment der Unachtsamkeit, aber er könnte fatale
Folgen haben: Das Warnlicht im Kombiinstrument hat der Fahrer des
32-Tonnen-Sattelzugs bereits übersehen. Er wechselte gerade im Radio
den Sender, und seine Augen waren auf das Display mit der Senderkennung gerichtet. Das kurze Anbremsen jedoch, mit dem der „Active Brake Assist (ABA)“ des Mercedes-Benz Actros spürbar auf die Gefahr vor dem Lkw aufmerksam macht, lenkt den Blick des Fahrers sofort zurück auf die Straße. Dort entwickelt sich gerade einer der berühmt-berüchtigten „Staus aus dem Nichts“.

Der Actros-Lenker erkennt die Gefahr blitzschnell, bremst mit maximaler Verzögerung und kommt rechtzeitig vor seinem Vordermann zum Stehen. Ohne diesen Assistenten hätte es 30 Minuten später im Verkehrsfunk vielleicht geheißen „Achtung, Vollsperrung auf der A 8 …“, und in
der der Tageszeitung hätte tags drauf eine Headline stehen können wie
„Ungebremst in Stauende gerast“.

Kernstück dieses Helfers ist neben einem Abstandsradar plus Steuergerät als Hardware vor allem die Software. Sie muss in Echtzeit und mit extrem hoher Trennschärfe eine „normale“ Verkehrssituation von einer gefährlichen unterscheiden. Wird es brenzlig, warnt der Assistent den Fahrer per Warn-
licht und Warnton. Reagiert der Fahrer dennoch nicht, löst er automatisch die Notbremsung aus, sobald ein Auffahrunfall nicht mehr zu vermeiden ist.

„Stellen Sie sich vor, ein solches System würde aufgrund eines Softwarefehlers in voller Fahrt auf der Autobahn unvermittelt eine Notbremsung auslösen.“ Mit dieser Situation, die sich jeder leicht selbstausmalen kann, skizziert Stefan Schmerler das schlimmste Schreckensszenario, das die Mercedes-Benz-Entwickler dieses Assistenzsystems ausschließen mussten. „Um einen solchen fatalen Fehler auszuschließen, lautet unser Anspruch: Null-Fehler-Software auf Knopfdruck.“ Schmerler leitet im Labor Software der Daimler-Forschung von Klaus Grimm die Abteilung „Methoden und Werkzeuge“. Eines der dortigen Projekte trägt den spröden Titel „Modellbasiertes Entwickeln von Assistenzsystemen (MBE)“.

Kern dieses Projekts ist ein Set von Methoden und Tools, mit denen die Entwicklung von Software für sicherheitskritische Systeme eine Qualität er-
reicht hat, die den von Stefan Schmerler postulierten Anspruch auch tat-
sächlich einlöst – vom Festlegen der Anforderungen über das eigentliche Erzeugen der Software bis hin zum Testen ihrer Funktionalität und Fehlerfreiheit.

Ingo Kreuz, der neue Leiter dieses Projekts, und Dirk Johanson, der das
MBE-Projekt davor geleitet und erfolgreich bis in die Serienentwicklung des Nutzfahrzeugbereichs begleitet hat, erläutern dem Besucher das Besondere an MBE (siehe Kasten S. 30). „Bisher gab es ein Lastenheft, in dem die Anforderungen einer Komponente fixiert waren. Mit dieser Dokumentation im Blick setzte sich anschließend ein Programmierer daran, die Software für das neue Steuergerät zu schreiben“, so beschreibt Dirk Johanson die bisherige Herangehensweise.

Wie beim Verfassen von Texten kann es dabei trotz Prüfung vorkommen, dass „Dreckfuhler“ unentdeckt bleiben. Spätere Funktionstests helfen zwar, der Softwarequalität auf den Zahn zu fühlen. Doch empirische Prüfungen, egal wie umfangreich betrieben, liefern nie letzte Gewissheit. Aber genau diese Aussagensicherheit mussten zum Beispiel die Entwickler des Notbremsassistenten im Actros erreichen. Sie müssen garantieren, dass es keine auch noch so seltene Betriebssituation gibt, in der das System ohne Notwendigkeit eine Notbremsung auslöst.

Diese knifflige Aufgabe hat auch eine ganz handfeste Seite, auf die Ingo Kreuz hinweist: „Fahrzeuge sind heute rollende Computer mit 50 oder gar mehr Steuergeräten an Bord. Die Anforderungsprofile oder Lastenhefte hierfür können für ein Fahrzeugmodell durchaus einen Umfang von 500 Leitz-Ordnern umfassen. Damit haben sie einen Grad an Komplexität erreicht, der es fast unmöglich macht, alles vollständig im Blick zu haben“, erklärt der Diplom-Informatiker.

Genau hier setzt das MBE-Projekt an. Die Grundidee ist, eine zusätzliche Ebene einzuziehen. Auf diese überführen die Entwickler die Anforderungen an das Steuerprogramm zunächst in ein Funktionsmodell. Es enthält sämtliche Eingangsgrößen, die für die Funktion notwendig sind, und stellt grafisch dar, was mit diesen Eingangsgrößen rechnerisch passieren soll; also wie sie verarbeitet werden sollen, wo sich Schnittstellen für die Datenübergabe von Teilverarbeitungsschritten befinden und welche Aktuatoren das Steuergerät am Ende wie ansteuern soll. Was sich zunächst eher nach Verkomplizierung als nach Vereinfachung anhört, bietet einige Vorteile. Etwa die höhere Anschaulichkeit: Gesamt- und Teilfunktionen sind grafisch dargestellt, lassen sich somit schneller erfassen und leichter auf Widerspruchsfreiheit prüfen
als Hunderte von Textseiten.

Der entscheidende Punkt – und hier kommt Stefan Schmerlers Anspruch einer Null-Fehler-Software ins Spiel – ist jedoch, dass sich ein solches Funktionsmodell viel rigider testen lässt, als dies mit empirischen Funktionstests möglich wäre. Hierfür nutzt das Team um Schmerler automatisierte Verifikations- und Testverfahren. In Simulationsläufen wird zum Beispiel die Frage gestellt, ob in diesem Modell ein bestimmter Zustand – etwa eine Fehlfunktion – unter irgendeiner, wenn auch noch so unwahrscheinlichen Betriebssituation, also prinzipiell auftreten kann.

Dirk Johanson verweist auf einen dritten Vorteil: „Hat man ein abgesichertes Funktionsmodell erstellt, geschieht das Programmieren praktisch vollautomatisch.“ Sogenannte Code-Generatoren können nämlich ein solches Modell direkt in die Programmsprache C übersetzen, also ohne Zutun eines Programmierers die erforderliche Software schreiben. Da diese Code-Generatoren ihrerseits auf Herz und Nieren geprüft sind, können sich bei diesem vollautomatischen Prozess keine „Dreckfuhler“ in den Code einschleichen. Damit ist also auch der „Knopfdruck-Anspruch“ von Stefan Schmerler eingelöst.

Und er nennt einen vierten wichtigen Pluspunkt: „Dank modellbasierter Entwicklung ist es erheblich einfacher, eine Funktionalität etwa von einem Lkw auf einen Reisebus zu übertragen. Viele Teilfunktionen des Systems lassen sich für beide Fahrzeugtypen nutzen. Wir haben also eine Art Baukasten mit bereits abgesicherten Modulen. Das macht die Entwicklung nicht nur schneller, sondern bedeutet auch, das wir von Anfang an einen viel höheren Reifegrad erreichen.“

Der Notbremsassistent war für die Softwarespezialisten um Stefan Schmerler gleichsam ein „Türöffner“ in der Nutzfahrzeugentwicklung. Doch die neue Vorgehensweise stieß rasch auch bei anderen Entwicklern im Konzern auf Interesse. Ingo Kreuz weiß, warum: „Unsere Kollegen betonen immer wieder, wie froh sie sind, dass wir mit dem modellbasierten Entwickeln eine geschlossene Tool-Kette anbieten können.“