Sicherheit im Straßenverkehr fordert nicht allein der Gesetzgeber, Vorrichtungen zum Schutz vor Unfallfolgen zieren auch die Verkaufsprospekte. Doch auf dem heiß umkämpften Automobil-Markt gilt es auch, neue Modelle in kürzerer Zeit und zu geringeren Kosten herauszubringen.

Wie aber soll ein Entwicklungsingenieur wissen, ob sein ESP-System wirklich auf verschneiter Fahrbahn ein seitliches Ausbrechen verhindert? Ein Test ist erforderlich, denn schließlich ist das electronic stability program (ESP) ein recht komplexes Gebilde aus einer Vielzahl von Komponenten: Sensoren, die Beschleunigungen korrekt messen sollten; eine Software, die im Ernstfall rechtzeitig Konsequenzen zieht; Aktoren, die auf Motorregelung und Bremskraftmoment einwirken, um das Fahrzeug auf Kurs zu halten. Deshalb verfrachten Automobilhersteller ganze Fahrzeugflotten in Polarregionen, um sozusagen den Winter für solche Tests zu verlängern – ein recht aufwendiges Unterfangen. Derlei Beispiele lassen sich noch mehr finden.

Wie verhält sich die Software, die alle Systeme für stabiles Fahren kontrolliert, wenn der Fahrer plötzlich das Lenkrad ganz einschlägt und dabei voll auf die Bremse tritt? Ein Rotwild, das unvermutet aus dem Wald springt, mag eine derartige, kritische Situation auslösen. Sie im Versuch in einer realen Umgebung nachzubilden würde einen Testfahrer jedoch großen Gefahren aussetzen.

Die Alternative verdanken Automobilhersteller und -zulieferer moderner Rechnertechnik, Mathematik und Physik: die Simulation der Fahrdynamik eines kompletten Fahrzeugs. Ein modular aufgebautes Programm haben Wissenschaftler des Fachgebiets Mechatronik an der Gerhard-Mercator-Universität-Gesamthochschule Duisburg entwickelt. Fahrwerk, Chassis und Antriebsstrang werden darin durch ein Mehrkörpermodell nachgebildet. Hinzu kommen Module für die Bremshydraulik, die Federung und die elektrischen Regelungssysteme inklusive der Sensoren, Regler und Aktoren; auch die Umgebung mit allen ihren Einwirkungen auf das Fahrzeug wird simuliert.

In der Praxis stellt sich dem Entwicklungsingenieur zudem häufig das Problem, einzelne Soft- und Hardware-Komponenten eines Systems zur Regelung der Fahrdynamik zu testen. Funktioniert ein Element so wie erwartet? Ist es gut auf andere abgestimmt? Wie wirkt sich ein Fehler im Gesamtsystem auf die einzelnen Komponenten aus?

Ein Beispiel: Die Software eines Steuergeräts umfaßt Programme zur System-Diagnose, Steuer- und Regelungsalgorithmen, Kommunikationsprotokolle und die Sicherheitssoftware. Letztere prüft unablässig alle Funktionen des Steuergerätes sowie alle Sensor- und Aktorsignale auf Plausibilität und Konsistenz. Eine kritische Beschleunigung des Fahrzeugs um seine Hochachse kann ein Kriterium dafür sein, daß das Auto schleudert, doch wenn das Fahrzeugverhalten ansonsten dem Fahrerwunsch entspricht, liegt vermutlich eine Fehlfunktion des Sensors für diese Form der Beschleunigung vor.

Das läßt sich in einer reinen Softwaresimulation nicht testen, denn die Kommunikation zwischen realen und virtuellen Komponenten wäre dabei nicht korrekt abzubilden. Deshalb haben wir eine hybride Variante entwickelt, bei der reale Baugruppen mit ihrer Steuersoftware in ein virtuelles Fahrzeug eingebunden werden. Diese Technik bezeichnet man als Hardware-in-the-loop (HIL); wird auch die zeitlich korrekte Kommunikation der Komponenten beachtet, als HIL-Echtzeitsimulation (HILES).

Bleiben wir beim eingangs genannten Problem, dem Test einer ESP-Regelung unter winterlichen Bedingungen. Im Fahrzeug variiert dieser Sicherheitsmechanismus beispielsweise den Druck in den Radbremszylindern, indem es elektromagnetische Ein- und Auslaßventile über den Spulenstrom ansteuert. Die Spulenwicklungen und alle anderen relevanten elektrischen Komponenten der Bremszylinder haben wir im Labor aufgebaut, während ein großer Teil der Sensorsignale – Achtung, Beschleunigung um die Hochachse! – aus der Simulation kommt. Innerhalb einer Millisekunde löst der Rechner dazu alle dynamischen Gleichungen und generiert die Steuersignale für den realen Prüfstand.

Eine DEC-Alpha-Workstation simuliert das gesamte Fahrzeug; durch das für Echtzeitanwendungen optimierte Betriebssystem Open-VMS ist diese Software – anders als vergleichbare HILES-Systeme – auf jeden Standardrechner zu übertragen. Um möglichst viel Rechenzeit für die eigentliche Simulation freizuhalten, erledigt ein separater Computer alle mit dem Eingang und Ausgang von Daten erforderlichen Schritte wie Pegelwandlung, Zählung und Generation von Sensorsignalen.

Natürlich gehört die Validierung des Modells zum Aufbau einer HILES dazu. Dabei werden die Modellparameter solange mit Ergebnissen realer Fahrversuche verglichen und angepaßt, bis Simulation und Realität einander in engen Toleranzen entsprechen.

Dann aber kann die Fahrzeugflotte im heimischen Hafen bleiben, denn vereiste und verschneite Straßen oder starke Seitenwinde lassen sich in der simulierten Umgebung ebenso übers ganze Jahr hinweg testen wie regennasse Fahrbahnen, Unebenheiten und Neigungen. Und auch Fehler: Falsche Daten oder Ausfall von Sensoren dürfen das gesamte Fahrstabilitätssystem keinesfalls lahmlegen. Werden beispielsweise keine Raddrehzahlen oder Lenkwinkel mehr gemeldet, muß die Sicherheitssoftware das koordinierte Abschalten einzelner Regelungsfunktionen einleiten und dies dem Fahrer mitteilen. HILES macht es möglich, geeignete Strategien kostengünstig und ohne Gefährdung von Testfahrern zu entwickeln und deren zeitlich korrekten Ablauf zu überprüfen.


Aus: Spektrum der Wissenschaft 7 / 1999, Seite 92
© Spektrum der Wissenschaft Verlagsgesellschaft mbH