VIRTUALISIERUNG VALIDIERUNG VON ÜBER 200 GETRIEBE VARIANTEN AUF PC-BASIS

Transkript

1 VIRTUALISIERUNG VALIDIERUNG VON ÜBER 200 GETRIEBE VARIANTEN AUF PC-BASIS Getriebesteuerungen werden häufig für Dutzende oder Hunderte von Fahrzeugvarianten entwickelt und appliziert. Nicht jede Variante wird während der Entwicklung physikalisch realisiert. Selbst die Simulation der Varianten auf HiL-Prüfständen stößt mit wachsender Variantenzahl an praktische Grenzen, denn für jede Variante muss zumindest das Getriebesteuergerät physikalisch realisiert und in ein reales HiL-Testsystem integriert werden. In solchen variantenreichen Fällen wird die vollständige Simulation des Systems einschließlich der Steuerung besonders attraktiv. Daimler, QTronic und Vector beschreiben, wie Mercedes-Benz heute über 200 Getriebevarianten für Sprinter-Transporter durch vollständige Virtualisierung des Getriebesystems auf PC automatisiert validiert. 290

2 AUTOREN STEFAN GLOSS ist Entwicklungsingenieur bei der Daimler AG in Stuttgart. MILAN SLEZÁK ist Mitarbeiter der QTronic GmbH in Stuttgart. ANDREAS PATZER ist Mitarbeiter der Vector Informatik GmbH in Stuttgart. VALIDIERUNG VON 200 VARIANTEN Mercedes-Benz-Transporter der Sprinter-Serie sind in den Varianten Kastenwagen, Kombi und Pritsche lieferbar, für Vier- und Sechs-Zylinder-Dieselmotoren auch mit Siebengang-Automatikgetriebe 7G-Tronic Plus. Die maximale Zuladung und die Hinterachsübersetzung sind dabei vom Kunden konfigurierbar. Für die Getriebesteuerung VGS3 ergeben sich dadurch über 200 applikationsrelevante Varianten. Für die Applikation und den Test dieser Varianten baut Mercedes-Benz seit 2010 eine simulationsgestützte Werkzeugkette auf, ➊. Hauptidee ist, die Entwicklungs- und Testaufgaben soweit wie möglich von Fahrversuch und HiL-Prüfstand weg und hin auf den PC zu verlagern, um so die problematische Abhängigkeit von teuren oder beschränkt verfügbaren Ressourcen wie Versuchsfahrzeugen und HiL-Prüfständen zu reduzieren. Technisch muss dazu vor allem das Getriebesystem virtualisiert, das heißt, per Simulation auf den PC dargestellt werden. Mercedes-Benz setzt für die Entwicklung der Funktionssoftware für Getriebesteuerungen seit Jahren virtuelle Steuergeräte auf Basis von Silver ein [1, 2, 4, 5]. Deshalb stehen seitens der 7G-Tronic-Funktionsentwicklung gut kalibrierte Simulationsmodelle zur Nachnutzung für Applikations- und Testaufgaben zur Verfügung. Für die Validierung der VGS3 per Simulation wurden im realen Straßenverkehr (Stadt, Landstraße, Autobahn) Fahrszenarien mit wenigen physikalisch realisierten Sprinter-Varianten aufgezeichnet. Dabei wurden die Fahrgeschwindigkeit und (per GPS-Messtechnik) das Straßenprofil erfasst und als MDF-Datei gespeichert. Der Validierungsprozess für einen gegebenen Softwarestand der Getriebesteuerung läuft damit wie folgt ab, ➋: :Konfigurieren von 200 Software-in-the-Loop-Simulationen in Silver auf mehreren PCs. Jede Simulation bildet eine Variante mit Original-Funktionssoftware und den variantenspezifischen Applikationsdaten ab, einschließlich der gelernten Adaptionswerte :Treiben der 200 Simulationsmodelle mit den aufgezeichneten Fahrszenarien und Speichern der Schaltvorgänge als MDF Datei. Dabei wird die Mehrkern-Architektur der eingesetzten PC-Hardware (Intel Core i7) zur Parallelisierung genutzt :Skriptbasierte Auswertung der simulierten Schaltvorgänge mit der Data-Mining-Funktion von CANape. Die Skripte wurden ursprünglich für die Auswertung von realen Fahrversuchen entwickelt. So stehen die gleichen Auswertungen über den gesamten Entwicklungszyklus hinweg zur Verfügung :Automatisches Erzeugen, Ausführen und Bewerten von Fahrszenarien mit dem Testfallgenerator TestWeaver zur Komplettierung der Testabdeckung :Analysieren der von CANape und TestWeaver gefundenen auffälligen Schaltungen. Dabei wird mit CANape via XCP auf PC in das virtualisierte Getriebesteuergerät VGS3 hineingemessen. Auch eine Applikation (Verstellen von Parametern) ist so möglich. 04I Jahrgang SIMULATION DES GETRIEBESYSTEMS Für die Fahrzeugsimulation wurden Streckenmodelle aus der modellbasierten Funktionsentwicklung auf Basis Modelica/ Dymola wiederverwendet [4] und durch Ändern von Modellparametern an die Fahreigenschaften der Sprinter-Varianten 291

3 ➊ Simulationsgestützte Validierung der Varianten angepasst. Das Modell der Getriebesteuerung wurde durch Kompilieren des TargetLink-generierten C-Codes für Windows PC / Silver erzeugt und konnte hier ebenso wiederverwendet werden. Die Systemsimulation in Silver verwendet die variantenspezifischen Applikations- und Modellparameter. Die Getriebesteuerung VGS3 enthält verschiedene Adaptionsfunktionen, um Parameter der Getriebemechanik (beispielsweise Füllzeiten der Kupplungen) während des Betriebs zu lernen und dem Alterungsprozess zu folgen. Der Lernvorgang wird in Silver per Skript nachgestellt. Die so gelernten Adaptionswerte werden zu Beginn einer Simulation zusammen mit den Applikationsdaten in das simulierte Steuergerät geflasht. Der Modellfehler des Streckenmodells ist dadurch zu großen Teilen wegadaptiert, und die Simulation auf PC liegt insgesamt sehr nahe am realen Fahrverhalten. Das eingesetzte Streckenmodell ist deutlich detaillierter als vergleichbare Modelle, die für den Einsatz unter Echtzeitbedingungen am HiL entwickelt wurden. 292 Der Einsatz derart detaillierter Modelle ist hier nur möglich, weil Dank der vollständigen Virtualisierung keine reale Hardware mehr beteiligt ist, und die Simulation daher nicht echtzeitfähig zu sein braucht. Dies ermöglicht den Einsatz von numerischen Solvern mit variabler Schrittweite: Die Simulation läuft dann während Schaltungen langsamer und in stationären Phasen mehrfach schneller als Echtzeit. CANape passt sich bei der Erfassung der Messdaten vollständig an das zeitliche Verhalten der simulierten Steuergeräte an. Die dabei entstehenden Messdateien zeigen einen kontinuierlichen Zeitverlauf an, der einer Echtzeitmessung entspricht. Insgesamt ermöglicht das Fallenlassen der Echtzeitanforderung eine physikalisch fundiertere Modellierung. Erst diese macht es möglich, Applikationsdaten per Simulation hinsichtlich Schaltqualität und Reibleistung auf PC zu validieren. Mit den am HiL typischerweise eingesetzten echtzeit fähigen Modellen ist dies wegen fehlender Modellierungstiefe so nicht möglich. TESTFALLGENERATOR FÜR DIE AUTOMATISIERTE FEHLERSUCHE Der Test des Getriebesystems mit aufgezeichneten Fahrszenarien deckt typische Fahrsituationen des Alltags gut und realitätsnah ab. Die aufgezeichneten Szenarien sind allerdings auch sehr redundant: Viele Schaltvorgänge wiederholen sich mit nur geringer Varianz immer wieder, während exotische Fahrsituationen, beispielsweise bestimmte Mehrfachschaltungen, selten oder gar nicht getestet werden. Um die Testabdeckung insgesamt zu maximieren und auch unvorhergesehenes Fahrerverhalten einzubeziehen, wurde zusätzlich der Testfallgenerator von TestWeaver [4, 5] in den Validierungsprozess integriert. Hierbei werden die aufgezeichneten Fahrszenarien durch das Werkzeug TestWeaver ersetzt, das die Rolle des Fahrers übernimmt. TestWeaver fährt das simulierte Fahrzeug dabei nicht planlos, sondern verfolgt aktiv zwei Ziele: Zum einen versucht TestWeaver das System in Zustände zu fahren, die vorgegebene Systemanforderungen verletzen (zum

4 Beispiel Schaltruck, zu lange Schaltzeit, zu hohe Reibleistung an einer Kupplung während einer Schaltung). Zum anderen versucht TestWeaver, das zu testende System in möglichst viele unterschiedliche Zustände zu treiben. Im Idealfall sind dies genau die erreichbaren Zustände des Systems. Was dabei der Zustandsraum ist, kann in TestWeaver kompakt durch Angabe der Variablen (Achsen) definiert werden. Wählt man beispielsweise den Zielgang und den Istgang der Getriebesteuerung, so ist der Zustandsraum genau die Menge der Kombinationen aus Ist- und Zielgang, also alle denkbaren Gangwechsel. TestWeaver sucht dann selbstständig durch Variieren von Fahrpedal, Bremspedal und Straßenprofil nach Fahrmanövern, die möglichst unterschiedliche Gangwechsel erreichen. Wählt man als dritte Achse das Motormoment, versucht TestWeaver, diese Gangwechsel zusätzlich für unterschiedliche Motormomente zu erreichen. Man kann so mit relativ geringem Spezifikationsaufwand und ganz ohne Testskripte eine hohe Testabdeckung erreichen und so Abdeckungslücken beim Nachfahren vordefinierter Fahrszenarien schließen. AUSWERTUNG DER TESTFÄLLE Über das Data Mining in CANape und mit Test- Weaver werden tabellarische Berichte und Diagramme erzeugt. Sie bieten Möglichkeiten zur interaktiven Analyse von erkannten Problemen. Eine herausragende Eigenschaft von Silver ist die 100-Prozent-Reproduzierbarkeit von Szenarien: Eine Simulation kann so oft wie nötig exakt wiederholt und sogar per Breakpoint beim Eintreffen bestimmter Ereignisse angehalten werden. Auch Debuggen auf C-Code-Ebene ist möglich, falls der Quellcode des Steuergeräts auf dem Simulationsrechner zur Verfügung steht. Über CANape können dabei einzelne Parameter verändert oder komplette Parametersätze in die Steuergeräte geladen werden, um beispielsweise bei gleichem Szenario unterschiedliche Bedatungen zu testen und zu bewerten. KOSTEN UND NUTZEN Wird mit dem zuvor beschriebenen Validierungsprozess ein Softwarestand auf zum Beispiel vier PCs für sieben Tage (reine Laufzeit) getestet, so wird dabei eine Laufleistung von insgesamt km erreicht. Falls jeder PC einen Vier- Kern-Prozessor enthält, laufen je PC gleichzeitig vier unabhängige Fahrzeugsimulationen. Bezüglich Testdurchsatz entspricht ein PC dabei vier HiLs mit jeweils einem Steuergerät. Anders gesagt: Um einen Softwarestand im selben Zeitraum und Umfang auf einem HiL zu testen, bräuchte man 16 HiL-Systeme. Zusätzlich müsste man dafür die auf PC eingesetzten Strecken- 04I Jahrgang 293

5 ➋ Analyse auffälliger Schaltungen mit TestWeaver, Silver und CANape modelle echtzeitfähig machen, ohne dabei die benötigte Modellierungstiefe zu opfern. Der Aufwand zum Aufsetzen der Simulation für 200 Varianten beträgt mit der vorgestellten Werkzeugkette ein bis zwei Personentage. Die 200 Simulationskonfigurationen für Silver werden dabei per Skript generiert. Als Messkonfigurationen für CANape können bereits vorhandene Konfigurationen von realen Messfahrten direkt übernommen werden. Die Applikationsparameter für alle 200 zu testenden Varianten befinden sich in einer einzigen PAR- oder HEX-Datei und werden über Variantenkodierung automatisch auf die einzelnen Konfigurationen verteilt. Ein ähnlich hoch automatisiertes Vorgehen ist für eine HiLbasierte Testumgebung schwer vorstellbar. Der vorgestellte Prozess hat damit im Vergleich zum Test am HiL ein besonders günstiges Kosten-Nutzen-Verhältnis. 294 ZUSAMMENFASSUNG Der vorgestellte Prozess ermöglicht die Absicherung von Funktionssoftware und Applikationsdaten mit außerordentlich hohem Automatisierungsgrad bei vergleichsweise bescheidenem Aufwand. Daimler plant daher, dieses Vorgehen auch für Transporter der Vito- und Viano-Serie anzuwenden. Möglich scheint künftig auch das teilweise Verlagern von Applikationsaufgaben auf PC. LITERATURHINWEISE [1] Junghanns, A.; Serway, R.; Liebezeit, T.; Bonin, M.: Schneller zum virtuellen Steuergerät. In: ATZelektronik 7 (2012), Nr.3, S [2] Brückmann, H.; Strenkert, J.; Keller, U.; Wiesner, B; Junghanns, A.: Model-based Development of a Dual-Clutch Transmission using Rapid Prototyping and SiL. International VDI Congress Transmissions in Vehicles 2009, Friedrichshafen, Germany, DCT_2009.pdf [3] Mauss, J.; Simons, M.: Steuergeräte-Simulation auf PC mittels TriCore-Emulation. In: ATZelektronik 7 (2012), Nr.6, S [4] Rink, A.; Chrisofakis, E.; Tatar, M.: Automating Test of Control Software - Method for Automatic Test Generation. In: ATZelektronik 5 (2009), Nr.6, S [5] Tatar, M.; Schaich, R.; Breitinger, T.: Automated test of the AMG Speedshift DCT control software. 9 th International CTI Symposium Innovative Automotive Transmissions, Berlin, de/doc/testweaver_cti_2010_paper.pdf DOWNLOAD DES BEITRAGS READ THE ENGLISH E-MAGAZINE order your test issue now: springervieweg-service@springer.com