"Es sollte nicht hinten gut getestet, sondern vorne besser entwickelt werden"

Ohne hoch entwickelte Simulationstests und -modelle ist eine wettbewerbsfähige Fahrzeugentwicklung heute kaum mehr denkbar. all4engineers sprach mit Dr. Herbert Hanselmann, geschäftsführender Gesellschafter der dSpace GmbH, unter anderem über Potenziale von Simulationsmodellen, Echtzeitfähigkeit und die Tests am schnellsten und teuersten Serien-Pkw überhaupt, dem Bugatti Veyron.

Herr Dr. Hanselmann, welche Auswirkungen hatten in der Vergangenheit eingedampfte Budgets und das generell zögerliche Investitionsverhalten der Kunden speziell auf die Entwicklung Ihrer Produkte?
Eingedampfte Budgets gab es Anfang 2003 in der Tat einige. Wir beobachten, dass manche Kunden temporär mehr mit Bordmitteln als mit neuen Tools arbeiten und ihrem Management den Nutzen noch überzeugender erklären müssen. Unser Umsatz ist in 2003 auch nicht so stark gestiegen wie zuvor. Doch unsere Entwicklungspläne ändern sich dadurch wenig. Wir haben die Entwicklung auch in 2003 weiter ausgebaut. Und wenn Technologien etwas langsamer kommen als ursprünglich geplant, dann haben wir immer noch jede Menge zu tun, an anderen Stellen etwas zu verbessern.

Welchen Stellenwert besitzt der Parameter Echtzeitfähigkeit von Simulationswerkzeugen in den Bereichen Entwicklung und Engineering?
Der Stellenwert von Echtzeitfähigkeit wird immer wichtiger. Wir müssen an einen Punkt kommen, an dem Simulationsmodelle und Tests, die man damit in frühen Entwicklungsphasen entwickelt, also offline, auch später wiederverwendet werden können, und zwar bis hin zum letzten Akt, dem Gesamtsimulationstest am HIL-Simulator. Und hier muss die Notwendigkeit vermieden werden, große, detailgetreue Modelle, die mit Mühe für den Offline-Bereich erstellt wurden, manuell mit großem Aufwand zu vereinfachen, damit sie dann in Echtzeit am HIL laufen können. Wir haben gerade aus diesem Grund ein neues Prozessorsystem herausgebracht, das hier einfach mehr Spielraum schafft. Und das ist nach unseren Benchmarks die derzeit weltweit schnellste Lösung für HIL-Simulatoren. Ein übliches Echtzeit-Motormodell wird dabei in nur 34 Mikrosekunden gerechnet, was uns die Möglichkeit gibt, noch einiges an Modellkomplexität im Hinblick auf das Gesamtfahrzeug oder genauere Modelle hinzuzufügen.

Warum muss die Hardware für Rapid Control Prototyping (RCP) und HIL-Simulationen überhaupt so schnell sein?
Sie muss nicht immer so schnell sein. Es gibt durchaus auch langsamere Anwendungen, etwa thermische, bei denen unsere Systeme deutlich schneller sind als erforderlich – jedoch ist es dann gut zu wissen, dass es da noch Reserven gibt. Es muss unterschieden werden zwischen der Schnelligkeit bei der Modellberechnung auf der einen, etwa eines Reglers oder einer Regelstrecke im HIL-Bereich, und der Ein-/Ausgabe auf der anderen Seite. Es würde wenig nützen, Modelle sehr schnell rechnen zu können, wenn man auf der Ein-/Ausgabe riesige Latenzzeiten hat. Wir achten deshalb immer auf beides.
Es gibt jedoch beim Rapid Prototyping viele Anwendungen, bei denen tatsächlich die maximale Geschwindigkeit gefordert ist – beispielsweise bei bestimmten neuen Motorsteuerungsansätzen, oder ganz extrem beim elektromagnetischen Ventiltrieb. Besonders zeitkritisch ist es oft dann, wenn im Bypass an einem vorhandenen Steuergerät eine neue Funktion auf dem Prototyping-System gerechnet wird. Man will dann den Zeitablauf in der vorhandenen Steuergeräte-Software nicht stören, so dass die neue Funktion, die oftmals viel komplizierter ist als die alte, einschließlich der Datenkommunikation hin und zurück in den vorhandenen Zeitslot passen muss. Beim Elektromagnetischen Ventiltrieb muss das beispielsweise alles in 50 Mikrosekunden erledigt sein.
Bei HIL-Simulatoren sind die Anforderungen an die Schnelligkeit durch die Rechenmodelle und durch die Komplexität der Ein-/Ausgabe bestimmt. Auch die geforderten Abtastraten werden immer höher. Vor wenigen Jahren hatte man einen einzigen Einspritzimpuls. Jetzt hat man vielleicht fünf oder mehrere, teilweise extrem kurze Impulse, deren Timing genau erfasst und im Modell berücksichtigt werden muss. Bei großen Simulatoren für den Integrationstest der Gesamtelektronik ist es zusätzlich die enorme Menge an Signalen, die höchste Leistung verlangt.

Wie begegnet dSpace den großen Problemen, unter denen vor allem stark elektronik- beziehungsweise softwarelastige Fahrzeuge leiden?
Eine erste kurzfristige Maßnahme unsererseits besteht darin, dass wir dem Kunden die Testmittel an die Hand geben, mit denen sie die Probleme wenigstens rechtzeitig, vor Start of Production, finden und beheben können. Natürlich sollte primär nicht hinten gut getestet, sondern vorne besser entwickelt werden. Und deshalb sind wir auch in diesem Bereich aktiv, in erster Linie mit Rapid Prototyping und seit einigen Jahren mit der automatischen Code-Generierung.

Fehler von Steuergeräten, die isoliert betrachtet meist tadellos funktionieren, tauchen meist erst im Verbund auf, wie er im realen Fahrzeug vorkommt. Inwieweit sind Sie derzeit in der Lage, vernetzte Steuergeräte im Systemverbund zu testen?
Zur Klärung Ihrer Frage: Die Testaufgaben liegen bei unserem Kunden. Der Kunde will natürlich die Testhoheit haben. Wir stellen die Plattform, also den Simulator, und geben Hilfestellung.
Was die Testfähigkeit von Steuergeräten im Netzwerk angeht, so haben wir innerhalb von drei Jahren rund zwei Dutzend größere und große Verbundsimulatoren mit etwa 4 bis 40 Steuergeräten – durchschnittlich 18 – gebaut. Vier CAN- und 10 LIN-Busse gleichzeitig in einem Simulator, mit 7.000 darüber laufenden Signalen, 1.500 Steuergeräte-PINs. Das hatten wir alles schon, und nicht nur im Normalbetrieb, sondern auch im gestörten Betrieb. So können wir beispielsweise CAN-Messages bewusst ausfallen lassen oder verfälschen, um die Fehlerreaktion des Steuergeräteverbunds zu prüfen.
Ganz wichtig ist gerade bei den großen Simulatoren, zu wissen, wie man so einen HIL-Simulator aufbaut und in Betrieb nimmt. Ohne Erfahrung und strategisches Vorgehen kann man sich da total verlieren. Man sucht dann Fehler im Simulator und nicht im Steuergeräteverbund. Wir sind mittlerweile in der Lage, große Simulatoren, wenn die notwendigen Informationen über die Steuergerätefunktionen vorliegen, in wenigen Monaten auf einen Zieltermin hin fertigzustellen.

Bitte erklären Sie uns den Zusammenhang zwischen einer guten Winkelauflösung der Angular Process Unit (APU) eines I/O-Boards und den Testmöglichkeiten künftiger Steuergeräte-Generationen etwa für Motoren mit Benzin-Direkteinspritzung oder HCCI-Motoren.
Das ist ein Beispiel dafür, wie wir Aufgabenstellungen lösen, die entweder an uns herangetragen werden oder die wir für lösungsbedürftig halten. Wir waren schon Anfang der 90er-Jahre die ersten, die winkelbasierte Signale auch wirklich winkelbasiert erzeugt haben, statt sie mit, wie ich glaube, unsauberen Tricks auf Zeitbasis nachzubilden. Wir haben damals einen digitalen Signalprozessor (DSP) dafür eingesetzt. Als die Anforderungen höher wurden, sind wir auf FPGA ("Field Programmable Gate Array") umgestiegen. Damit konnten wir 29.000 1/min, also auch Rennmotoren, simulieren bei 0,08 Grad Auflösung für Winkelereignisse. Diese Lösung wurde zum Standard für Motorsimulationen, weil sie von vornherein auch für die genaue Erfassung von Mehrfach-Einspritzimpulsen nach Winkellage und zeitlicher Länge ausgelegt war.
Nun hat man von uns für neue Motorkonzepte wie HCCI – Homogeneous Charge Compression Ignition – wieder eine Steigerung gewünscht, was höhere Winkel- und Drehzahlauflösung angeht. Und wir haben darauf reagiert. Die höheren Anforderungen hängen mit der schwierigen Steuerung der Selbstzündung nach Zeitpunkt und Form sowie dem schnellen Verbrennungsvorgang zusammen. Dieser Vorgang muss in Gestalt von Zylinderdrucksignalen oder Ionenstromsignalen auch entsprechend fein auf der Simulatorseite abgebildet werden, um die Reaktion des Steuergeräts zu sehen. Deshalb haben wir die Auflösung jetzt hochgesetzt auf 0,01 Grad bei gleichzeitig hoher Drehzahlauflösung von 0,1 1/min. Auch wenn HCCI nicht schon morgen in Serie geht, wir sind vorbereitet.

Wie würden Sie typische Prozessabläufe im Entwicklungsprozess beim Kunden beschreiben?
Da gibt es große Unterschiede, die auch von der Arbeitsweise der Kunden abhängen. Lässt sich ein OEM von Zulieferern "bedienen", wird er nur HIL-Tests einsetzen, eventuell zukünftig auch unser Applikationssystem zum Tuning der Steuergeräteparameter. Mittlerweile ist es aber üblich, dass OEMs mindestens Teilfunktionen selbst entwickeln. Dann werden sie auch RCP betreiben. Vor allem im Antriebstrang geht das oft am besten und schnellsten über Bypass am Steuergerät des Zulieferers.
Alternativ kann auch mit TargetLink gearbeitet werden, also mit der Code-Generierung. Man hat aber dann nicht die Freiheiten, Bequemlichkeiten und Reserven eines leistungsstarken RCP-Systems, dafür ist man gleich seriennah. Für die Entwicklung größerer neuer Funktionen wird man aber zu RCP greifen, weil man hier nicht zu früh eingeengt sein darf. Ein weiterer Grund können zusätzlich nötige Ein-/Ausgabe-Kanäle sein, die das vorhandene Steuergerät nicht bietet.
Hat ein OEM ein RCP-System benutzt, kann er das Modell der neu entwickelten und bereits getesteten Funktion an den Zulieferer geben. Dieser wird sie dann programmieren und in sein Steuergerät integrieren. Hat der OEM TargetLink genutzt, dann konnte er bereits prüfen, ob die neue Funktion in das Rechenzeit- und Speicherbudget des Zielsteuergeräts passt. Es liegt natürlich dann nahe, dass der Zulieferer ebenfalls TargetLink einsetzt, und die Anpassung an seine individuellen Prozesse und Umgebungen über TargetLink vornimmt. Wir aber wissen auch von Fällen, in denen der OEM dem Zulieferer gleich den fertigen Objekt-Code in die Hand gibt.

Sie waren an den Steuergerätetests des mit 1.160.000 Euro und 400 km/h teuersten und zugleich schnellsten Serien-Pkw beteiligt, des Bugatti Veyron. Worin lag für Sie die größte Herausforderung bei diesem Projekt?
Das ist eine interessante Frage. Die größten Herausforderungen liegen oft gar nicht da, wo man sie vermutet. Sonst müsste die Formel 1 die größte Herausforderung darstellen. Ein großer Integrationstest-Simulator für einen Mittelklassewagen kann mehr Aufwand verursachen als ein Teilbereichs-HIL-Testsystem für ein hochgerüstetes Fahrzeug. Hier beim Bugatti war ein Simulator für Antrieb und Fahrdynamik gefragt, nicht für die Komfortelektronik. Wir hatten es mit sechs Steuergeräten zu tun. Die ESP- und Allradantriebssteuerungen stellten aufgrund der Erfahrung unserer Applikationsingenieure mit den verwendeten Steuergeräten keine großen Herausforderungen dar, trotz einiger Abweichungen vom Normalen wegen der hohen Fahrgeschwindigkeit.
Neu waren für uns das 7-Gang-Doppelkupplungsgetriebe und der 16-Zylinder-Motor mit je einer ME9-Motorsteuerung von Bosch pro Zylinderbank, die synchron laufen müssen. Das Getriebe hatte alleine 24 Aktuatoren. Das mathematische Modell für Motor und Getriebe wurde von Volkswagen gestellt und wir haben es zusammen mit dem Fahrdynamik-Modell von Tesis integriert.
Die größte Herausforderung war, wie oft bei Simulatorprojekten, dass viele Änderungen nach Projektstart kamen. Und wenn man einen HIL-Simulator voll ausnutzen will, muss er deutlich vor Beginn der Fahrzeugerprobung schon Ergebnisse gebracht haben. Da kann man nicht erst beginnen, wenn alle Steuergeräte fertig und stabil auf dem Tisch liegen.
Natürlich ist so ein Projekt auch emotional spannend und interessant. Zu wissen, dass der HIL-Simulator einen essentiellen Entwicklungsbeitrag leistet, motiviert. Man darf einfach die wenigen Prototypen nicht kaputtfahren. Und die Auswirkung eines E-Gas-Fehlers oder einer falschen Getriebeschaltung bei 400 km/h möchte auch niemand real testen.

Die kürzlich vorgestellte Basis-I/O-Hardware von dSpace Simulator unterstützt Signale bis 42 Volt. Wie schätzen Sie die Zukunft des 42-V-Bordnetzes in Pkw im Hinblick auf den Bedarf und vor allem technische Hürden ein?
Meine Meinung ist, dass das 42-V-Bordnetzes schon kommen wird, aber aus Kostengründen lange nur für einen Teilbereich der Fahrzeugarchitektur parallel zu einem 12-Volt-System. Ein Lämpchen im Innenraum muss nun wirklich keine 42 Volt haben. Wir sind jedenfalls immer wieder nach Unterstützung für 42 Volt gefragt worden und sind bereit. Die Failure Insertion Units, also die Fehler-Simulationseinheiten in unseren Simulatoren, mit denen man Kabelbrüche, Kurzschlüsse und Ableitwiderstände nachbildet, sind auch für 42 Volt ausgelegt.
42 Volt im Auto gibt es übrigens schon, bei Toyota für eine Start-Stop-Funktion und im Audi A8 gab es schon vor Jahren einen 14/42-Volt-DC-DC-Wandler zum Betrieb einer 1.000-Watt-Windschutzscheibenheizung. In diesem Jahr wird GM einen Pickup Truck mit dem Continental ISAD Starter-Generator auf der Kurbelwelle herausbringen. Die elektrohydraulische Servolenkung läuft ebenso mit 42 Volt wie die Wandler für etwas, was in USA vielleicht so wichtig wird wie der berühmte Dosenhalter, nämlich vier Steckdosen für 120 Volt Wechselspannung für diverse elektrische Geräte bis 2,4 kW.

Welche Veränderungen wird die X-by-Wire-Technologie künftiger Fahrzeugmodelle für die Testlandschaft bringen?
Ich erwarte für unsere Produkte keine großen Veränderungen. FlexRay haben wir im Repertoire, 42 Volt auch und Fahrdynamik sowieso. Der Bedarf zu testen, wird sich da allerdings aufgrund der riskanten Technik noch verstärken. In der letzten Zeit bestanden HIL-Simulatoren oft nur noch aus Simulator und Steuergerät. Man hat versucht, die Echtteile zu minimieren. Bei X-by-Wire für die Fahrdynamik werden künftig wieder mehr Testprüfstände zu sehen sein, bei denen mechanisch/elektrische Echt-Aggregate als Teil der Simulation verbaut sind – echte Bremsen, echte Lenkungen in einem Setup, das der Realität sehr nahe steht. Damit kann man Dinge sehen, die das Simulationsmodell noch nicht hergibt. So hat HIL übrigens früher einmal begonnen, und daher kommt auch der Name: Hardware in the Loop.

Vielen Dank, Herr Dr. Hanselmann, für das Gespräch.

Zur Person:
Dr.-Ing. Herbert Hanselmann (55) ist geschäftsführender Gesellschafter (President & CEO) der dSpace GmbH, Paderborn. 1968 bis 1973 studierte er Elektrotechnik an der Universität Karlsruhe und promovierte dort im Jahr 1978 zum Thema Regelungssysteme. Danach forschte und lehrte er am heutigen Mechatronik-Labor der Universität Paderborn. 1988 gründete er mit drei weiteren Ingenieuren die dSpace GmbH.

Autor(en): Thomas Jungmann

Suche: