SIMULATION & BErEcHNUNg
Antriebsstrang
Simulationsgestützte Methoden IDE und XiL zur Entwicklung von Antriebsstrangkomponenten 48
Automotive Engineering Partners
Die heutigen Märkte stellen gerade im Automobilbereich hohe Anforde rungen an die Entwicklungsprozesse. Innovationen wie Hybridantriebe müssen möglichst schnell in neue Fahrzeugmodelle Eingang finden, daher muss die Entwicklung möglichst effizient sein. Das Institut für Produkt entwicklung (IPEK) der Universität Karlsruhe forscht an Simulations- und Versuchsmethoden, die es erlauben, mit der ständig steigenden Produkt komplexität umzugehen, um damit einen Beitrag zu effizienten Entwicklungs prozessen zu leisten. Die Automobilentwicklung kann sich dabei positiven Erfahrungen der Softwareentwicklung bedienen.
1 Einleitung Vielleicht noch merklicher als im Automobilbereich fand in der Software-Branche ein rasanter Innovationssprung statt. Einen wesentlichen Beitrag zur effizienten Bewältigung der Softwareentwicklung liefern die zur Verfügung stehenden Entwicklungswerkzeuge, die ihrerseits wieder nur Software sind und so gleichermaßen f lexibel an die Anforderungen der Produktentwicklung angepasst werden können. In der Automobilentwicklung ist der Trend zur Virtualisierung der Entwicklungsaufgaben ebenfalls deutlich erkennbar. Virtualisierung bedeutet derzeit nichts anderes als die Übertragung von Systemen in den Rechner mit dem Ziel, Probleme früher zu identifizieren, Probleme zu lösen und komplexe Systeme überschaubar zu halten. Es gilt daher, die Erkenntnisse und Vorgehensweisen aus der Softwareentwicklung in die Automobilentwicklung zu übertragen, um die Vorteile der Virtualisierung voll ausnutzen zu können. Allerdings ist es, nicht nur zur Validierung von Simulationsmodellen, unumgänglich, reale Versuche an Komponenten, Teil- und Gesamtsystemen durchzuführen. Es ist naheliegend, den Schritt hin zu einer integrierten Entwicklungsumgebung auch in der Versuchsmethodik zu vollziehen, und die Simulation – zum Beispiel des Fahrerverhaltens oder von Umgebungseigenschaften und Umwelteinflüssen – in den Versuch zu integrieren.
2 Stand der Technik Die Entwicklungswerkzeuge beziehungsweise -umgebungen in der Softwaretech-
nik werden als integrierte Entwicklungsumgebung oder Integrated Development Environment (IDE) bezeichnet. So mussten früher Tätigkeiten wie Quellcodeerstellung oder Fehlersuche (Debugging) getrennt durchgeführt werden, während sie heute in eine Applikation integriert sind. Gleichzeitig sind oftmals Hilfsmittel zur Verwaltung von Programmmodulen, Quelltext und Dokumentation eingebunden, und schließlich bieten die IDEs zahlreiche Assistenten an, begonnen bei der Codevervollständigung bis hin zur grafischen Programmierung. In vielen Anwendungen, die auch in der Automobilentwicklung zum Einsatz kommen, wurde diese Funktionsintegration bereits aufgenommen – beispielsweise durch Verbindung von Prüfstandssteuerung, Auswertung und Simulationsumgebung. Zur Verknüpfung von Versuchsergebnissen und Simulationsmethoden haben sich am IPEK verschiedene Methoden etabliert. Ein Beispiel hierfür ist ein Kupplungsfunktionsmodell, mit dem durch Kopplung von Finite-Elemente-Methode, Mehrkörpersimulation und experimentell ermittelten Kennfeldern [1] das dynamische Verhalten des Antriebssystems ermittelt werden kann, zum Beispiel in Bezug auf komfortkritische Gesichtspunkte wie das Kupplungsrupfen.
3 Simulation im Versuch Ein weiterer Schritt ist die Echtzeit-Kopplung von Simulation und realem Versuch, das heißt die Integration eines echtzeitfähigen Simulationsmodells in eine Prüfstandsregelung. Hier sind die Punkte Fahrzeugsimulation per Elektromotoren und X-in-the-Loop-Ansatz zu erwähnen.
Die Autoren Dipl.-Ing. Martin Geier ist Leiter der Forschungsgruppe Antriebstechnik am Ins titut für Produktentwick lung (IPEK) der Univer sität Karlsruhe (TH).
Dipl.-Ing. Christian Stier ist Mitarbeiter der For schungsgruppe An triebstechnik am Insti tut für Produktentwick lung (IPEK) der Univer sität Karlsruhe (TH).
Dipl.-Ing. Tobias Düser ist Leiter der For schungsgruppe NVH Driveability am Institut für Produktentwicklung (IPEK) der Universität Karlsruhe (TH).
Dipl.-Ing. Matthias Behrendt ist stellvertretender Leiter der Forschungs abteilung 1 am Institut für Produktentwicklung (IPEK) der Universität Karlsruhe (TH).
Dipl.-Ing. Sascha Ott ist Leiter der Forschungs abteilung 1 am Institut für Produktentwicklung (IPEK) der Universität Karlsruhe (TH).
Prof. Dr.-Ing. Dr. h.c. Albert Albers ist Ordinarius des Insti tuts für Produktentwick lung (IPEK) der Univer sität Karlsruhe (TH).
ATZextra I Juni 2009
49
Simulation & Berechnung
Antriebsstrang
Bild 1: Fahrzeug- und Streckensimulation durch Elektromotoren am Antriebsstrangprüfstand
3.1 Fahrzeugsimulation per Elektromotoren Die Verknüpfung von Fahrzeugmodell und Prüfstandsregelung ist im Bereich der Antriebsstrangentwicklung am IPEK bereits etabliert [2]. Dabei werden in Antriebsstrangversuchen Verbrennungsmotor und Restfahrzeug durch Elektromotoren abgebildet, Bild 1. Die Vorgaben für die Elektromotoren werden in Echtzeit zum Beispiel aus hinterlegten Fahrzeugdaten und Kennfeldern berechnet. Auf der Antriebsseite wird das Verhalten des Verbrennungsmotors mit seinen dynamischen Momentenschwankungen, zum Beispiel unter Vorgabe der Fahrpedalstellung, aus Motorkennfeldern berücksichtigt. Die Fahrzeuggeschwindigkeit beziehungsweise die Drehzahländerung an den Belastungsmaschinen wird online aus dem gemessenen Beschleunigungsmoment und den Fahrwiderständen berechnet. Hierzu ist ein Simulationsmodell in die Prüfstandsregelung integriert worden, das auch auf reale Streckendaten zur Berücksichtigung von Steigungswiderständen und Kurvenfahrten zurückgreifen kann. Die Übertragung dieser Vorgehensweise auf verschiedene Versuchsebenen führt zu dem nachfolgend beschriebenen X-in-the-Loop-Ansatz, kurz XiL-Ansatz genannt. 50
Automotive Engineering Partners
3.2 Der X-in-the-Loop-Ansatz Der am IPEK definierte XiL-Ansatz für Antriebssysteme beschreibt eine durchgängige Vorgehensweise bei Untersuchungen auf verschiedenen Systemebenen am Beispiel der Antriebsstrangentwicklung [3]. Das „X“ steht dabei für das jeweils betrachtete Teilsystem, die Einheit „Unit under Test“ (UUT). Die UUT kann beispielsweise eine einzelne Antriebsstrangkomponente wie die Kupplung oder auch das gesamte Fahrzeug sein, Bild 2. Auf jeder Ebene wird das jeweils restliche System – in diesem Fall das
verbleibende Fahrzeug – virtuell mit dem Ziel abgebildet, dass die untersuchte Komponente die möglichst gleichen Belastungen und Wechselwirkungen erfährt wie im realen System. Auf diese Weise ist eine Vergleichbarkeit von Untersuchungen auf verschiedenen Systemebenen gewährleistet. Ebenso sind Versuche mit realen Komponenten beziehungsweise ihre Ergebnisse auf anschauliche Weise in die in Abschnitt 4 beschriebene virtuelle Entwicklungsumgebung übertragbar. Die möglichen Detaillierungsgrade für das Fahrerverhalten sowie für die Umgebung sind in Bild 3 dargestellt. Die Ausbaustufen reichen von generischen Vorgaben in Stufe 1, zum Beispiel in Form von Drehmoment- oder Drehzahlprofilen, bis hin zum realen Fahrer in der realen Umgebung. In Zwischenschritten ist es möglich, beispielsweise auf digitale Streckendaten, künstlich generierte Verkehrssituationen sowie verschieden detaillierte Fahrermodelle zurückzugreifen. Die Software zur Umgebungssimulation greift auf den digitalen Streckenatlas des IPEK zurück, in dem verschiedene Strecken wie der Nürburgring, die Großglockner-Hochalpenstraße oder das Karlsruher Stadtgebiet erfasst sind [4, 5]. Dadurch ist eine gute Übertragbarkeit von Daten der virtuellen in die reale Umgebung gewährleistet. Desweiteren ist bei dem XiL-Ansatz zwischen Open-Loop- und Closed-LoopManövern zu unterscheiden. Bei OpenLoop-Manövern reagiert der virtuelle oder reale Fahrer nicht auf Umgebungs-
Bild 2: X-in-the-Loop-Ansatz – Verbindung von virtueller und realer Welt
Bild 3: Mögliche Detaillierungsgrade für das Verhalten des Fahrers sowie für die Umgebung
einflüsse wie Steigungen und Verkehrszeichen; der Fahrer beziehungsweise der Prüfstand fährt ein definiertes Prüfprogramm ab, zum Beispiel unter Vorgabe von Übersetzung, Fahrpedalstellung und Bremsmoment. In Closed-Loop-Manövern ist der Regelkreis zwischen Fahrer und Umgebung geschlossen. Beispielsweise erhält der Fahrer (virtuell oder real) eine Fahrgeschwindigkeitsvorgabe oder erkennt die mögliche Geschwindigkeit anhand von Verkehrszeichen und der Verkehrssituation (virtuelle oder reale Umgebung).
4 Integrierte Simulationsumgebung Der in Abschnitt 3 vorgestellte XiL-Ansatz lässt sich in eine vollständig virtuelle Entwicklungsumgebung überführen, indem man die reale UUT durch ein Simulationsmodell ersetzt. Mit dieser Model-in-the-Loop(MIL)-Methode, siehe Bild 2, kann die Validität eines gegebenen Systems zumindest teilweise schon auf Basis eines Konzepts bewertet werden. Das erlaubt Teilvalidierungen zu einem sehr frühen Zeitpunkt im Produktentstehungsprozess. Voraussetzung dafür ist die sichere Modellbildung und Implementierung von Gesamt- und Teilsystemen sowie die Verknüpfung mit Umweltbedingungen und Referenzmanövern. Am IPEK wurde eine IDE auf Basis einer etablierten Simulationssoftware geschaffen, welche die einzelnen Aspekte berücksichtigt. Modelle eines Antriebssystems werden modularisiert, implementiert, in ein Umweltmodell eingebunden, mit einem Fahrermodell verknüpft und nach der numerischen Lösung automatisch bewertet.
4.1 Modellbildung Zur sicheren Modellbildung und Implementierung bedarf es einer Klassierung der einzelnen mit dem Antriebssystem interagierenden Teilsysteme, wie es in Bild 4 dargestellt wird: Der Zustand des Antriebssystems äußert sich in Phänomenen wie zum Beispiel dem Getrieberasseln. Die Phänomene sind wahrnehmbar durch den Fahrer. Schließlich wirken sich die Wahrnehmungen sowohl auf die subjektive Bewertung des Antriebssystems durch den Fahrer und Kunden als auch direkt auf das Verhalten des Fahrers aus. Neben den System-Phänomenen beeinflussen auch noch Umwelt-Phänomene die Bewertung durch den Menschen. Die
Umweltbedingungen wie zum Beispiel eine Straßensteigung stellen Randbedingungen für das System dar. Das Antriebssystem wird charakterisiert durch seine Topologie (zum Beispiel Heckantrieb), seine Parameter, seine Anfangsbedingungen sowie durch die Steueranforderungen seitens des Fahrers. Auf Topologie, Parameter, Anfangsbedingungen und Steueranforderungen hat der Entwickler Einfluss. Daher können sie als Ursache für das Systemverhalten gewertet werden. Manche Parameter, Topologien, Initialbedingungen und Steueranforderungen können auch variant sein und so zusammen mit dem Fahrer und der Umwelt das Fahrmanöver bilden, zum Beispiel den Start des Motors. Neben der Wahrnehmung durch den Fahrer lassen sich Phänomene aus Umwelt und System auch über Messtechnik erfassen oder im Falle einer Simulation direkt in Auswertealgorithmen eingeben. Sehr deutlich geht aus Bild 4 hervor, wie eng Manöver und Phänomene miteinander verknüpft sind. Da bestimmte Phänomene nur im Verlauf gewisser Manöver auftreten, muss ein Modell sowohl für die Untersuchung eines Phänomens als auch für das durchzuführende Manöver geeignet sein. Attribute, welche die
Bild 4: Teilsystemklassierung und -wechselwirkung – Manöver und Phänomene sind eng miteinander verknüpft ATZextra I Juni 2009
51
Simulation & Berechnung
Antriebsstrang
Bild 5: Modultemplate für Antriebs systemkomponenten
Eignung von Modellen für Phänomene und Manöver beschreiben, sind also ein fester Bestandteil des MIL-Ansatzes.
DOI: 10.1365/s35778-009-0305-4
4.2 Modularisierung Die Modularisierung im MIL-Ansatz erfolgt anhand eines Modulvorlage, eines Templates, Bild 5. Jedes Modell eines bestimmten Moduls (zum Beispiel Schwungrad) hat so stets die gleichen Schnittstellen und Kausalitäten. Werden die Module physikalisch modelliert, sind bei den Antriebsstrangkomponenten stets die Eigenschaften Trägheit, Steifigkeit/Kapazität, Dissipation und eventuell Transformation charakterisierend. Für jedes Modul muss klar sein, ob und welche Phänomene beobachtet werden sollen. Das schränkt nicht die Möglichkeit ein, jederzeit beliebige Zustandsgrößen des Modells anzeigen zu können. Gleichzeitig können so „Hilfsmodelle“ implementiert werden, die vereinfachte Restsysteme gemäß dem XiL-Ansatz zulassen. Zwischen einer Antriebsstrangkomponente und der Mensch-Maschine-Schnittstelle liegen gegebenenfalls komplexe Übertragungspfade, so dass diese wahlweise ebenfalls implementiert werden müssen oder ersatzweise eine komponentenbasierte Bewertung des Antriebsstrangverhaltens vorgenommen wird. 52
Automotive Engineering Partners
Bei Einhaltung der Schnittstellenvereinbarungen für jedes Modul ist es möglich, Modelle mit unterschiedlicher Genauigkeit zu entwickeln. So können spezialisierte Modelle für bestimmte Manöver und Phänomene erstellt werden und Entwicklungsiterationen von Modellen einfach ausgetauscht werden. Da auch das Restsystem den Konventionen unterliegt, lassen sich auch generische vereinfachte Restsysteme und einfache Manöverprofile anwenden. Allerdings steigt durch diese Flexibilität die Anzahl der verfügbaren implementierten Modelle. Die Modellbibliothek wird daher vollständig mit einem so genannten Concurrent Versioning System (CVS) verwaltet. Es erlaubt die serverbasierte Speicherung aller Entwicklungsstufen und Entwicklungszweige von Modellen sowie die Beteiligung mehrerer Entwickler an einer einzigen Bibliothek. Ein implementiertes Modell stellt zunächst nur eine Bauform dar. Zum konkreten Produktmodell wird das Modell erst durch seine richtige Parametrierung. Daher werden nicht nur die Modelle selbst verwaltet, sondern mit Hilfe einer Datenbank auch die dazugehörigen Parametersätze. Vorteilhaft ist die Austauschbarkeit von Modellen einer Komponente mit unterschiedlichen Genauigkeiten unter Beibehaltung eines Parametersatzes.
4.3 IDE-basierte Validierung Entsprechend der Validierungsabsicht, die ein Entwickler zu Beginn seiner Arbeit mit der IDE formuliert, werden durch das Programm automatisch die in Frage kommenden Phänomene und die dazugehörigen Manöver ausgewählt. Die Genauigkeitsstufen der Komponentenmodelle werden gemäß ihrer Eignung automatisch ausgewählt und mit einem zur Komponente passenden Parametersatz versehen. Im Anschluss an alle numerischen Gesamtsystemsimulationen werden für bestimmte Zustandsvariablen Auswer tungsalgorithmen durchgeführt, um charakteristische Größen zu ermitteln, die sich dann mit Referenzwerten vergleichen lassen. Beispielhaft soll ein bestimmtes Zweimassenschwungrad (ZMS) auf Resonanzempfindlichkeit beim Motorstart untersucht werden. Die IDE wählt für alle Komponenten nach der Kupplung leere Modelle und reduziert so das Gesamtsystem auf Motor und ZMS. Die Genauigkeitsstufe des Motormodells erlaubt Motorstartmanöver, die Genauigkeitsstufe des ZMS beinhaltet alle Spiele und nichtlineare Steifigkeiten. Nach der numerischen Simulation wird der relative Verdrehwinkel ausgewertet und gezählt, wie oft der Winkel eine bestimmte Grenze überschreitet. Diese charakteris-
tische Größe wird mit einem Referenzwert verglichen; damit kann eine Aussage über die Validität des ZMS beim Motorstart getroffen werden.
5 Zusammenfassung Entwicklungswerkzeuge werden heute im Automobilbereich eingesetzt, um Versuche zu validieren und den Produktentwicklungsprozess zu verkürzen und zu optimieren. Die integrierte Entwicklungsumgebung IDE fügt sich sehr gut in den X-in-the-Loop-Ansatz für Antriebssysteme beim Institut für Produktentwicklung (IPEK) der Universität Karlsruhe ein. Sie
baut auf einer etablierten Simulationsumgebung auf und erlaubt dem Entwickler, sich auf Problemstellungen des Antriebssystems zu konzentrieren. Durch die Automatisierung von Simulationsund Datenmanagementaufgaben wird der Entwickler entlastet. Gleichzeitig wird durch in der IDE hinterlegtes Expertenwissen bei verringertem Gesamtaufwand die Validierungsqualität erhöht.
Literaturhinweise
[1] Albers, A.; Behrendt, M.; Ott, S.: Entwicklungs methodik für Kupplungssysteme – Modellbildung, Versuch und Simulation. VDI-Tagung Kupplungen und Kupplungssysteme in Antrieben, Wiesloch, 25. und 26. April 2007
[2] Albers, A.; Krüger, A.; Lux, R.; Albrecht, M.: Prüfen von Antriebssträngen am Beispiel des Kupplungsrupfens – Ganzheitliche Antriebsstrang entwicklung. In: ATZ 103 (2001), Nr. 1, S.44-49 [3] Albers, A.; Düser, T.; Ott, S.: X-in-the-Loop als integrierte Entwicklungsumgebung von komplexen Antriebssystemen. Tagung Hardware-in-theLoop-Simulation, Kassel, 16. und 17. September 2008 [4] Albers, A.; Düser, T.; Ott, S.; Seifermann, A.: Virtuelle Streckenbibliothek für die Antriebsstrang entwicklung. SimPEP – Kongress für Simulation im Produktentwicklungsprozess, Würzburg, 14. und 15. Juni 2007 [5] Schyr, C.; Spreitzer, H.: Digitaler Streckenatlas für die alpine Antriebsstrangerprobung. In: Automotive Engineering Partners, Nr. 1, Februar 2004, S. 44–47
– the synonym for ROBOT DRIVERS Driver Characteristics for FTP Test ● Strecken-
10000
∑ Speed error
8000 6000
● STÄHLE
4000
various ● single
2000
0
AUTOPILOT
50
100
150
drivers driver
200
∑ Throttle
abweichung < 1 Radumdrehung pro 10 km ● Typische
Fahrgenauigkeit < 0,2 km/h ● Menschliches
Fahrverhalten ● Unterschiedliche
Fahrstile wählbar ● Umgebungstemperatur
- 40°C ... + 80°C
STÄHLE GmbH · Maybachstraße 12 · 71299 Wimsheim · Germany Tel. +49 (0) 70 44 - 91561-0 · Fax +49 (0) 70 44 - 91561-29 Internet: www.stahle.com · Email:
[email protected]
ATZextra I Juni 2009
53