mit Einbindung vernetzter Elektronik - FKFS
11.12.2012 • Aufrufe
Teilen Einbetten Melden

mit Einbindung vernetzter Elektronik - FKFS

mit Einbindung vernetzter Elektronik - FKFS

mit Einbindung vernetzter Elektronik - FKFS

MEHR ANZEIGEN
WENIGER ANZEIGEN
ePAPER LESEN
ePAPER HERUNTERLADEN
fkfs.de

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

JETZT STARTEN

Werkzeuggestützte Echtzeit-Fahrsirnulation<br />

<strong>mit</strong> <strong>Einbindung</strong> <strong>vernetzter</strong> <strong>Elektronik</strong><br />

Von der Fakultät 11 ascliinenbau<br />

der Uiiiversität Stutt gart<br />

zur Erlailgung der Würde eines<br />

Doktor-Irigeriieurs @r.-11ig.)<br />

geiieliinigt e Al~liaiitlliing<br />

vorgelegt von<br />

Gerd Baurnann<br />

aiis Essliiigen<br />

Hauptberichter: Prof. Dr .-Ing. J. \Yietleiiianri<br />

1Zitb~richter:<br />

Prof. Dr.-Iiig. Dr. 11. C. P. C'.h 10 ner<br />

Tag der iriündlichen Prüfurig: 15. Juli 2003<br />

Institut für \Terbrennungsmotoren und I

Werkzeuggestützte<br />

Echtzeit-Fahrsimulation<br />

<strong>mit</strong> <strong>Einbindung</strong><br />

<strong>vernetzter</strong> <strong>Elektronik</strong><br />

Gerd Baumann<br />

Schriftenreihe des Instituts<br />

für Verbrennungsmotoren und Kraftfahrwesen<br />

der Universität Stuttgart<br />

Lehrstuhl Kraftfahtwesen<br />

Herausgegeben von Prof. Dr.-lng. Jochen Wiedemann<br />

Band 22

Bibliografische Information Der Deutschen Bibliothek<br />

Die Deutsche Bibliothek verzeichnet diese Publikation<br />

in der Deutschen Nationalbibliografie;<br />

detaillierte bibliografische Daten sind im lnternet über<br />

httrxlldnb.ddb.de abrufbar.<br />

Bibllographic Information published by Die Deutsche Bibliothek<br />

Die Deutsche Bibliothek lists this Publication<br />

in the Deutsche Nationalbibliografie;<br />

detailed bibliographic data is available in the lnternet at<br />

http://dnb.ddb.de .<br />

ISBN 3-8169-231 1-9<br />

Bei der Erstellung des Buches wurde <strong>mit</strong> großer Sorgfalt vorgegangen; trotzdem können Fehler<br />

nicht vollständig ausgeschlossen werden. Verlag und Autoren können für fehlerhafte Angaben und<br />

deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen.<br />

Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Autoren dankbar.<br />

O 2004 by expert verlag, Wankelstr. 13, D -71 272 Renningen<br />

Tel.: +49 (0) 71 59-92 65-0, Fax: +49 (0) 71 59-92 65-20<br />

E-Mail: expert@expertverIag.de, Internet: www.expertverlag.de<br />

Alle Rechte vorbehalten<br />

Printed in Germany<br />

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außer-<br />

halb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig<br />

und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und<br />

die Einspeicherung und Verarbeitung in elektronischen Systemen.

Vorwort<br />

Diese Arbeit ist während meiner Tätigkeit als wissenschaftlicher hlitar-<br />

beiter am Forschungsinstitut für Kraftfahrwesen und Fahrzeugmotoren<br />

Stuttgart (<strong>FKFS</strong>) entstanden.<br />

Ilein besonderer Dank gilt Herrn Prof. Dr.-Ing. J. IViedemann, dem<br />

Ordinarius für Kraftfahrwesen an der Universität Stuttgart. für die Eber-<br />

nahme des Hauptberichtes und die wohlwollende Förderung der Arbeit.<br />

sowie Herrn Prof. Dr.-Ing. Dr. h. C. P. Göhner, dem Leiter des Insti-<br />

tuts für Automatisierungs- urid Software-Technik (IAS) der Universität<br />

Stuttgart, für die freundliche Übernahme des Mitberichts.<br />

Bei den Mitarbeitern der Institute <strong>FKFS</strong> und IVK, insbesondere al-<br />

len Kollegen aus dem Bereich Kfz-Mechatronik und Software, bedan-<br />

ke ich mich für die gute Zusammenarbeit und Unterstützung bei der<br />

Durchführung der Arbeiten. Stellvertretend seien die Herren 3lichael<br />

Grimm, Jens Neubeck und Werner Krantz genannt.<br />

Besonders erwähnen möchte ich auch die früheren Kollegen Dieter Hötzer<br />

und Ulrich Sailer, die <strong>mit</strong> kreativen Anregungen und fachlichen Diskus-<br />

sionen zum Gelingen der Arbeit beigetragen haben.<br />

Meiner Frau Andrea danke ich herzlich für die stetige Motivation, die<br />

Arbeit fertig zii stellen, obwohl dies für sie und unsere beiden Kinder<br />

zeitweise Verzicht bedeutet hat.<br />

Stilttgart,, in1 Juli 2003 Gerd Baumanri

Inhalt<br />

Vorwort 3<br />

Formelzeichen und Abkürzungen 8<br />

Zusammenfassung 20<br />

Abstract<br />

1 Einleitung 24<br />

1.1 Motivation .......................... 24<br />

1.2 Stand der Forschung und Technik .............. 25<br />

1.2.1 Fahrsimulatoren ................... 27<br />

1.2.2 Hardware-in-the-Loop-Simulation .......... 30<br />

1.2.3 Echtzeitsimulation von Kraftfahrzeugen ...... 34<br />

1.2.4 Datenkommunikation im Kraftfahrzeug ...... 38<br />

1.2.5 Das CAN-Protokoll ................. 43<br />

1.3 Aufgabenstellung ....................... 45<br />

1.4 Inhalt und Aufbau der Arbeit ................ 46<br />

2 Methoden und Werkzeuge 48<br />

2.1 Definition der Echtzeitsiniulation .............. 48<br />

2.1.1 Anwendungen in der Fahrzeugtechnik ....... 50<br />

2.1.2 Fahrsimulatoren ................... 52<br />

2.2 Erstellung echtzeitfähiger Modelle ............. 54<br />

2.2.1 Grundlegende Anforderungen ............ 54<br />

2.2.2 Numerische Anforderungen ............. 55<br />

2.2.3 Strukturierung .................... 57<br />

2.3 Auswahl und Kopplung von Software-Werkzeugen .... 59<br />

2.3.1 Konzept ........................ 59<br />

2.3.2 Auswahl des Basis-UTerkzeugs . ........... 63<br />

2.3.3 Auswahl des FSM-Werkzeugs ............ 64<br />

2.3.4 Auswahl des MKS-Werkzeugs ............ 64<br />

2.3.5 <strong>Einbindung</strong> von NEWEUL in SIMULINK . . . . 65<br />

2.3.6 <strong>Einbindung</strong> von SIh4PACK in SIIlIULINK .... 67

3 Elektronische Steuerungen und CAN-Netzwerke<br />

3.1 Verfahren zur <strong>Einbindung</strong> von elektronischen Steuer-<br />

71<br />

geräten und Aggregaten ................... 71<br />

3.1.1 Definition von Schnittstellen ............ 71<br />

3.1.2 <strong>Einbindung</strong> von Steuergeräte-Quellcode ...... 75<br />

3.1.3 Rechnerkopplung (Echtzeit-Cosimulation) ..... 75<br />

3.1.4 <strong>Einbindung</strong> realer Steuergeräte (HIL) . . . . . . . 76<br />

3.1.5 <strong>Einbindung</strong> realer Aggregate ............ 79<br />

3.1.6 <strong>Einbindung</strong> <strong>vernetzter</strong> Steuergeräte . ........ 82<br />

3.1.7 Funktions-Nachbildung (Steuergeräte-Modell) . . . 84<br />

3.2 Behandlung von CAN-Ketzwerken . . . . . . . . . . . . . 86<br />

3.2.1 Simulatiori des gesamten Netzwerks . . . . . . . . 87<br />

3.2.2 Simulation der Steuergeräte . realer CLAN-Bus . . . 88<br />

3.2.3 Simulation von Fahrzeugen <strong>mit</strong> mehreren CAK-<br />

Netzwerken ...................... 90<br />

3.2.4 Autorrratisierte Impleinentierung der CAN-<br />

Kommunikation in der Simulation . . . . . . . . . 92<br />

4 Ein Fahrsimulator für ASG im Nutzfahrzeug 94<br />

4.1 Einleitung ........................... 95<br />

4.1.1 Zielsetzung und Anforderungen ........... 95<br />

4.2 Funkt ionsweise der Antriebs-St euerung .......... 96<br />

4.2.1 Halbautomatische Steuerung ............ 96<br />

4.2.2 Autoinatisiertes Schaltgetriebe (AiSG) . ...... 96<br />

4.3 Konzeption und Aufbau ................... 98<br />

4.3.1 Darstellung des Verbrennungsmotors ........ 99<br />

-2.3.2 Darstellung von Kupplung und Getriebe ...... 99<br />

4.3.3 Darstellung der weiteren Komponenten . . . . . . 103<br />

4.3.4 Realisierter Hardn-are-.4 ukau ............ 104<br />

4.4 Simulationsniodell ...................... 106<br />

4.4.1 Verbrennungsmotor ................. 108<br />

4.4.2 Motor-Steuergerät .................. 109<br />

4.4.3 Kupplung ....................... 111<br />

4.4.4 Getriebe . ....................... 112<br />

4.4.5 Hydrodynamische Dauerbremse (Retarder) .... 114<br />

4.4.6 Hinterachse ...................... 116<br />

3.4.7 Elektro-pneumatische Bremsanlage ......... 117<br />

4.4.8 Längsdynamik .................... 121<br />

2.4.9 Rad-Umfangsgeschwindigkeiten ........... 123<br />

4.4.10 Steuergerät Fahrregelung (FR) . . . . . . . . . . . 123

4.5 Implementierung ....................... 127<br />

4.6<br />

4.5.1 Simulationsprogramm und Echtzeitrechner .... 127<br />

4.5.2 CAN-Kommunikation ................ 127<br />

4.5.3 Interface-<strong>Elektronik</strong> ................. 128<br />

Ausge~~hlte Versuchsergebnisse .............. 128<br />

4.6.1 Validierung der Simulationsanlage ......... 128<br />

4.6.2 Assistenzfunktionen ................. 130<br />

5 Fahrdynamik und MMI 134<br />

5.1 Ubersicht ........................... 134<br />

5.2 Nf ehrkörpermodell ...................... 136<br />

5.3 Berechnung der Reifenkräfte ................. 140<br />

5.3.1 Anforderungen .................... 140<br />

5.3.2 Radhalbmesser, Radlast und Umfangsgeschwiridigkeit<br />

......................... 141<br />

5.3.3 Schlupf und Schräglaufwinkel ........... . 142<br />

5.3.4 Umfangs- und Seiterlkraft .............. 145<br />

5.3.5 Rückst ellmoment ................... 148<br />

5.3.6 Instationäres Verhalten ............... 149<br />

5.3.7 Schwenkmoment ................... 150<br />

5.3.8 Rollwiderstand .................... 152<br />

5.3.9 Einleitung der Reifenkräfte in das MKS ...... 152<br />

5.4 Bremsen und Raddrehung .................. 153<br />

5.4.1 Bremsanlage ..................... 153<br />

5.4.2 Raddrehung . ..................... 153<br />

5.5 Lenkung ............................ 155<br />

5.5.1 Lenkwinkel ...................... 155<br />

5.5.2 Lenkradmoment ................... I59<br />

5.5.3 Servolenkung ..................... 161<br />

5.6 PC-basierte Echtzeitsimulation ............... 161<br />

5.6.1 Portabilität ...................... 162<br />

5.6.2 Numerische Integration ............... 163<br />

5.6.3 Rechenzeitbedarf ................... 163<br />

5.7 Labor-Fahrsimulator ..................... 166<br />

5.7.1 Übersicht ....................... 166<br />

5.7.2 Lenkeinheit ...................... 167<br />

5.7.3 Visualisierung . .................... 168<br />

5.8 Geräuscherzeugung ...................... 169<br />

5.8.1 Einführung ...................... 169<br />

5.8.2 Grundlagen des Verfahrens ............. 170

5.8.3 Geräuschaufnahme . . . . . . . . . . . . . . . . . . 171<br />

5.8.4 Geräuscherzeugurig irn Simulationsbetrieb . . . . . 173<br />

5.8.5 Technische Realisierung . . . . . . . . . . . . . . . 175<br />

6 Schlussbemerkung und Ausblick 176<br />

Literatur 178<br />

Anhang 194<br />

Al: L4uslegungsrechnung zu Abschnitt 4.3.2 . . . . . . . . . . . 194

Formelzeichen und Abkürzungen<br />

Verwendete Formelzeichen<br />

Bei physikalischen Größen, die als Skalar und als Vektor auftreten, wird<br />

in der folgenden Liste nur die skalare Form angegeben.<br />

Formel-<br />

zeichen<br />

Einheit Beschreibung<br />

maximale Beschleunigung/Verzögerung<br />

Soll-Verzögerung<br />

Gewichtsfunktion bei der Geräuscherzeugung<br />

Fahrzeug-S tirnfläche<br />

Zahl der geräuschbeeinflussenden Parameter<br />

Abstand der Lenkachsen<br />

Auslegungsfaktor der Lenkung<br />

Torsionssteifigkeit des Reifens um die z-Achse<br />

Geometriekonstante (Lenkung)<br />

Torsionssteifigkeit des Kupplungsdämpfers<br />

Federkonstante des Reifens in z-Richtung<br />

Luftwiderst ands-Beiwert<br />

Durchmesser des Lenkrads<br />

Reibkoeffizient des Kupplungsdämpfers<br />

Durchmesser des Retarders<br />

Basis des natürlichen Logarit hmiis<br />

Exzentrität des Reifens<br />

Vektor der CAN-Fehlersignale<br />

mathematische Funktionen, allgemein<br />

Abtastfrequenz bei der Geräuschaufnahme<br />

Abtastfrequenz bei der Geräuscherzeugung<br />

Rückmeldungen eines Aggrega,tes<br />

höchste Eigenfrequenz<br />

Rollwiderst ands-Beiwert<br />

Rückmeldungen eines Steuergerät es<br />

Rückmeldungen der Umgebung

Frequenz der K-ten 114otorordnung<br />

Kraft (allgemein)<br />

Antriebskraft<br />

Anfahrwiderstand<br />

Bremskraft an einem einzelnen Rad<br />

Bremskraft der Auflieger-Achse<br />

Summe der Bremskräfte aller Achsen<br />

Bremskraft der Hinterachse<br />

Bremskraft der i-ten Achse<br />

Bremskraft am linken Rad der i-ten Achse<br />

Bremskraft am rechten Rad der i-ten Achse<br />

Längskraft an der Sattelkupplung<br />

Bremskraft der Vorderachse<br />

Umfangskraft arn Lenkrad<br />

Luftwiderstand<br />

Radlast<br />

Achslast der Auflieger-Achse<br />

Radlast zur Schwenkmoment-Bestimmung<br />

Achslast der Hinterachse<br />

Radlast des linken Hinterrades<br />

Radlast des rechten Hinterrades<br />

Achslast der i-ten Achse<br />

Radlast des linken Rades der i-ten Achse<br />

Radlast des rechten Rades der i-ten Achse<br />

Sattellast<br />

Achslast der Iorderachse<br />

Radlast des linken lTorderrades<br />

Radlast des rechten Vorderrades<br />

Reifenkraft vekt or<br />

Rollwiderstandskraft an einem Rad<br />

Rollwiderstandskraft (Gesamt fahrzeiig)<br />

Reifen-Seitenkraft<br />

stationäre Reifen-Seitenkraft<br />

Reifen-Seit enkraft bei reinem Schräglauf<br />

Steigungswiderstand<br />

Reifen-Umfangskraft (ohne Rollwiderst and)<br />

Reifen-Umfangskraft im gleit enden Zustand<br />

Reifen-ürnfangskraft (<strong>mit</strong> Rollwiderstarid)<br />

Reifen-Cmfarigskraft am linken Hinterrad<br />

Reifen- Lrnfangskraft am rechten Hinterrad

stationäre Reifen-Umfangskraft<br />

Reifen-Umfangskraft am linken Vorderrad<br />

Reifen-Umfangskraft am rechten Vorderrad<br />

Reifen-Umfangskraft bei reinem Längsschlupf<br />

Bet ätigungskraft eines Radbremszylinders<br />

Hilfsgröße (Längsdynamik)<br />

Hilfsgröße (Längsdynamik)<br />

Erdbeschleunigung<br />

Gewicht des unbeladenen Aufliegers<br />

Gewicht der Ladung<br />

Gewicht des beladenen *4ufliegers<br />

Gewicht der Zugmaschine<br />

Simulations-Schrittweite<br />

Schwerpunkt höhe des unbeladenen Auf liegers<br />

Koeffizient für Schwenkmoment-Berechnung<br />

Höhe der Sattelkupplung<br />

Schwerpunkthöhe der Ladung<br />

maximal zulässige Schrittweite<br />

Schwerpunkthöhe des beladenen Aufliegers<br />

Schwerpunkthöhe der Zugmaschine<br />

Indexvariable (allgemein)<br />

verzögerte Getriebe-Gesamtübersetzung<br />

Getriebe-gesamt Übersetzung<br />

Übersetzung der Getriebe-Hauptgruppe<br />

Übersetzung der Hinterachse<br />

Übersetzung des Lenkantriebs<br />

Übersetzung der Getriebe-Nachschaltgr~~pe<br />

Übersetzung des Retarders<br />

kinematische Lenkübersetzung<br />

Lenkübersetzung in Geradeausstellung<br />

Übersetzung des Starters<br />

Übersetzung des Lenkgestänges<br />

Übersetzung des Lenkgestänges (links)<br />

Übersetzung des Lenkgestänges (rechts)<br />

Übersetzung der Getriebe-VorschaltgrupPe<br />

Strom der Betriebsbremsventil-Nachbildung<br />

Strom eines ABS-Ventils<br />

Indexvariable (allgemein)<br />

Trägheitsmomeilt (allgemein)<br />

Trägheitsmoment eines Elektromotors

kgm2<br />

kgm2<br />

kgm'<br />

kgm'<br />

kgm'<br />

kgm2<br />

kgm2<br />

kgm2<br />

(-)<br />

N<br />

(-1<br />

s2<br />

(-1<br />

Srns/rad<br />

m<br />

kg<br />

Nm<br />

Nm<br />

Nm<br />

Nlri<br />

Nin<br />

Nm<br />

Trägheitsmoment des Getriebeeingangs<br />

wirksames Trägheitsmoment an der Kupplung<br />

Trägheitsmoment des Getriebeausgangs<br />

Trägheitsmoment der Kupplung<br />

Trägheitsmoment des Kurbeltriebs<br />

Trägheitsmoment des Rades um die Radachse<br />

Trägheitsmoment der Vorgelege~velle<br />

Trägheitsmoment (Elektromotor <strong>mit</strong> Last )<br />

Kraftschluss- Ausnutzung<br />

Kreisel- Zentrifugal- und Corioliskräfte<br />

~aftreibungs-¿iberhöhung der Radbremse<br />

Bauform-Konst ante für Servomotoren<br />

cberlast-~aktor für Servornot oren<br />

Steigung der S t arter- Kennlinie<br />

A4bstand Sattelkupplung-Auflieger-Achse<br />

Schwerpunktlage des unbeladenen Aufliegers<br />

Abstand Sch~erpunkt-Hinterachse<br />

Schwerpunktlage der Beladung<br />

Schwerpunktlage des beladenen Aufliegers<br />

Schwerpunktlage der Zugmaschine<br />

Radstand der Zugmaschine<br />

Radstand<br />

Relaxationslänge (Sch~venkmoment)<br />

Relaxat ionslänge (Reifen-Seitenkraft)<br />

Relaxationslänge (Reifen-Umfangskraft)<br />

Indexvariable (allgemein)<br />

%lasse des unbeladenen Aufliegers<br />

mechanische L4usgangsgrößen (Aggregat)<br />

mechanische Eingangsgrößen (Aggregat)<br />

Fahrzeug-Gesarritmasse<br />

hlasse der Beladung<br />

hlasse des Zugfahrzeugs<br />

Drehmoment (allgemein)<br />

Massenmatrix eines MKS<br />

hloment an der Kardanwelle<br />

Schwenkmoment<br />

Grenzmoment (E-Riiotor am Getriebeeingang)<br />

max. hloirient (E- hlotor am Getriebeeingang)<br />

Nennmomeiit (E-Motor am Getriebeeitigang)<br />

Grenzmonient (E-hlotor arn Getriehcaiisgang)

Moment arn Getriebeausgang<br />

Moment a,m Getriebeeingang<br />

maximales Moment am Getriebeeingang<br />

Reibmoment am Getriebeeingang<br />

Lenkradmoment<br />

Lenksäulenmoment (ohne Lenkhilfe)<br />

Dauer-Lenkradmoment<br />

kurzzeitiges Lenkr admoment<br />

Antriebsmoment an der Hintera.chse<br />

Antriebsmoment am linken Hinterrad<br />

Antriebsmoment am rechten Hinterrad<br />

Kupplungsmoment<br />

Kupplungsmoment im Gleitzustand<br />

Kupplungsmoment im Haftzustand<br />

Kupplungs-Grenzmoment (wegabhängig)<br />

maximales Kupplungsmoment (absolut)<br />

Mot ormoment<br />

Motormoment (ohne Reibung)<br />

begrenztes Motormoment (ohne Reibung)<br />

Motor-Sollmoment (ohne Reibung)<br />

Reibmoment des Verbrennungsmotors<br />

Motormoment bei Schleppbetrieb<br />

Motormoment bei Volllastbetrieb<br />

Bremsmoment der Motorbremse<br />

Reifen-Rückstellmoment<br />

stationäres Reifen-Rückstellmoment<br />

binäre CAN-Empfangsnachrichten<br />

Moment an der Retarderwelle<br />

Ret arder-Sollmoment<br />

begrenztes Ret arder-Sollmoment<br />

maximales Retardermoment<br />

Rollwiderst andsmoment<br />

gesamtes Lenkmoment<br />

Lenkmoment aufgrund Bremskraft<br />

gesamtes Lenkmoment (linkes Rad)<br />

gesamtes Lenkmoment (rechtes Rad)<br />

Lenkmoment aufgrund Längskraft<br />

Lenkmoment aufgrund konstrukt . Nachlaufs<br />

Lenkmoment aufgrund Gewichtsr~ckstellun~<br />

Startermoment an der Kurbelwelle

ns<br />

P<br />

PBP<br />

PL'<br />

Porg<br />

-+<br />

Porg<br />

Psim<br />

-+<br />

Psim<br />

Pzyz<br />

4<br />

Geräuschprobe (nach Frequenzmodulation)<br />

Zeit<br />

Verarbeitungszeit<br />

Periodendauer einer Geräuschprobe<br />

Totzeit des Retarders<br />

Gesamtdauer einer Geräuschprobe<br />

Eingangsgröße (allgemein)<br />

Eingangsgrößen des Antriebsstrangmodells<br />

Spannung eines ABS-Drehzahlsensors<br />

Bezugsgeschwindigkeit<br />

Fahrzeuggeschwindigkeit<br />

Minimale Translationsgeschwindigkeit<br />

Radträger-Geschwindigkeit in der Ebene<br />

Anhaltegeschwindigkeit<br />

Reifen-Umfangsgeschwindigkeit<br />

Reifen-Umfangsgeschwindigkeit (Hinterachse)<br />

Reifen-Umfangsgeschwindigkeit (Vorderachse)<br />

Längsgeschwindigkeit des Radtragers<br />

Quergeschwindigkeit des Radträgers<br />

Vektor der Führungsgrößen (vom Fahrer)<br />

Zustandsgröße (allgemein)<br />

verallgemeinerte Koordinaten<br />

verallgemeinerte Geschwindigkeiten<br />

ver allgemeiner te Beschleunigungen<br />

Position des Anhängers (X-Richtung)<br />

Position der Ladung (Anhänger)<br />

Position des Radträgers<br />

Position des Zugfahrzeugs (X-Richtung)<br />

Position der Ladung (Zugfahrzeug)<br />

Anfangsbedingung<br />

Ausgangsgröße (allgemein)<br />

Stellgrößen eines Aktuators<br />

Position des Anhängers (Y-Richtung)<br />

Stellgrößen (vom Fahrer)<br />

verallgemeinerte Koordinaten des MKS<br />

verallgemeinerte Geschwindigkeiten des MKS<br />

Ausgangsgrößen eines Steuergerätes<br />

Position des Zugfahrzeugs (Y-Richtung)<br />

Abbremsung<br />

Position des Anhängers (z-Richtung)

PAA<br />

PAH<br />

PAR<br />

PAV<br />

PFH<br />

Pg es<br />

PK<br />

PZ A<br />

PZR<br />

VZL7<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

rad<br />

Einfederung der Hinterachse (Anhänger)<br />

Einfederung der Vorderachse (Anhänger)<br />

Einfederung des Fahrerhauses<br />

Schaltzustand des Getriebes<br />

Bet ätigungszustand der hlotorbremsen<br />

-4bstand Radnabe-Fahrbahn<br />

Sollwert der -4bbrenisung<br />

Betätigungszustand des Starters<br />

Schalt zustand eines ABS-lTentils<br />

Position des Zugfahrzeugs (z-Richtung)<br />

Einfederung der Hinterachse (Zugfahrzeug)<br />

Einfederung der irorderachse (Zugfahrzeug)<br />

Schräglaufwinke1<br />

Steigungswinkel der Fahrbahn<br />

Lenkwinkel eines Rades<br />

Lenkwinkel des kurvenäußeren Rades<br />

Ackermannwinkel<br />

Lenkwinkel des Anhängers<br />

Lenkradwinkel<br />

Lenkwinkel des kurveninneren Rades<br />

maximaler Lenkwinkel (kurveninneres Rad)<br />

Lenkwinkel des linken Rades<br />

Winkel des Lenkantriebs<br />

<strong>mit</strong>tlerer Lenkwinkel<br />

Lenkwinkel des rechten Rades<br />

\rorspurwinkel<br />

Lenk-Differenzwinkel<br />

Haftgreiize bei Auslenkung des Rades<br />

Auslenkung des Rades aus der Ruhelage<br />

itTankwinkel des Anhängers<br />

TVankwinkel der Hinterachse (Anhänger)<br />

Rahmen-Torsionswinkel (Anhänger)<br />

Wankwinkel der Vorderachse (Anhänger)<br />

Warikwinkel des Fahrerhauses<br />

Reifen-Schlupf~vinkel<br />

Torsionswinkel der Kupplung<br />

TtTankwinkel des Zugfahrzeugs<br />

Rahmen-Torsioriswinkel (Zugfahrzeug)<br />

TYankwinkel der Vorderachse (Zugfahrzeug)

ad<br />

rad<br />

(-1<br />

(-1<br />

(-><br />

(-><br />

rad<br />

(-)<br />

(-1<br />

(- ><br />

(-1<br />

(-<br />

(- ><br />

(-)<br />

(-)<br />

(-><br />

(-1<br />

rad<br />

rad<br />

rad<br />

kg/m3<br />

kg/m3<br />

rad<br />

(-><br />

(-1<br />

(- 1<br />

rad<br />

Wankwinkel der Hinterachse (Zugfahrzeug)<br />

Sturz<br />

Index für Motorordnungen<br />

Reifen-Längsschlupf<br />

Reifen-Gesamtschlupf<br />

Schlupf der Hinterräder<br />

Spurhebelwinkel<br />

Kupplungsschlupf<br />

Kupplungs-Grenzschlupf<br />

Leisturigszahl des Retarders<br />

Schlupf der Vorderräder<br />

Gleit reibungs-Beiwert (Radbremse)<br />

Haftreibungs-Beiwert (Radbremse)<br />

Gleitreibungs-Beiwert (Reifen/Fahrbahn)<br />

Haftreibungs-Beiwert (Reifen/Fahrbahn)<br />

Indexvariable (allgemein)<br />

Kreiszahl<br />

Nickwinkel des Anhängers<br />

Nickwinkel des Fahrerhauses<br />

Nickwinkel des Zugfahrzeugs<br />

Luft dichte<br />

Öldichte im Retarder<br />

Spreizung<br />

Hilfsgröße (Reifenkraft-Berechnung)<br />

Hilfsgröße (ReifenkrafbBerechnung)<br />

Hilfsgröße (Reifenkraft-Berechnung)<br />

Nachlaufwinkel<br />

Zeitfaktor beim Schwenkmoment- Aufbau<br />

Zeitkons tante (Schwenkmoment-Berechnung)<br />

minimale Schaltzeit des Getriebes<br />

Zeitkonstante der Getriebe-Synchronisation<br />

Zeit konst ante des Lenkmoment- Aufbaus<br />

bezogene Verarbeitungszeit<br />

Zeit kontante des Motormomentenaufbaus<br />

minimaler Zeitfaktor (Reifenkraftaufbau)<br />

Zeitfaktor (Seitenkraft aufbau)<br />

Zei tfaktor (Umfangskraftaufbau)<br />

Winkelgeschwindigkeit (allgemein)<br />

Winkelbeschleunigung (allgemein)<br />

Winkelgeschwindigkeit (Kardanwelle)

ad/s<br />

rad/s<br />

rad/s<br />

rad/s<br />

rad/s<br />

rad/s2<br />

ra,d/s2<br />

rad/s<br />

rad/s<br />

rad/s<br />

rad/s<br />

ra,d/s<br />

rad/s<br />

rad/s<br />

rad/s<br />

rad/s<br />

rad/s2<br />

rad/s<br />

rad/s<br />

rad/s<br />

rad/s<br />

(-1<br />

rad<br />

rad<br />

rad<br />

rad<br />

Soll-Winkelgeschwindigkeit (E-Llotor)<br />

Winkelgeschwindigkeit (Getriebeausgang)<br />

Winkelgeschwindigkeit (Getriebeeiiigang)<br />

minimale Winkelgeschwindigkeit (GE)<br />

konstante Winkelgeschwindigkeit (E-Mot or)<br />

maximale Winkelbeschleunigung (GE)<br />

konstante ~Tinkelbeschleunigung (GE)<br />

IVinkelgeschwindigkeit (Lenkrad)<br />

Winkelgescliwindigkeit (Hinterachse)<br />

Winkelgeschwindigkeit (linkes Hinterrad)<br />

Winkelgeschwindigkeit (rechtes Hinterrad)<br />

\Vinkelgeschwindigkeit (Kupplung)<br />

ITink(~1geschwindigkeit (Lenkantrieb)<br />

iVinkelgeschwindigkeit (hlotor)<br />

maximale Winkelgeschwindigkeit (Motor)<br />

iVinkelgeschwindigkeit (Rad)<br />

iVinkelbeschleunigung (Rad)<br />

Winkelgeschwindigkeit (Retarderwelle)<br />

Winkelgeschwindigkeit (Starter)<br />

Leerlauf-Winkelgesch~vindigkeit (Starter)<br />

Winkelgeschwindigkeit (Vorgelegewelle)<br />

normierte Motorlast (Geräuschaufnahme)<br />

Gierwinkel des Anhängers<br />

Rad-Gierwinkel (entspannter Zustand)<br />

Rad-Gierwirikel<br />

Gierainkel des Ziigfahrzeugs

Verwendete Abkürzungen<br />

ABS<br />

A/D<br />

ALB<br />

AM<br />

ASG<br />

ASR<br />

BEOP<br />

BWGL<br />

CACE<br />

CAN<br />

CP<br />

CRC<br />

DIA<br />

DAE<br />

DIN<br />

ELSA<br />

EMV<br />

EPB<br />

FEM<br />

FHG<br />

<strong>FKFS</strong><br />

FSM<br />

GUI<br />

HA<br />

HIL<br />

ID<br />

INT<br />

INTF<br />

110<br />

ISO<br />

IVK<br />

Kfz<br />

KREL<br />

LIN<br />

LKW<br />

MKS<br />

Antiblockiersystem<br />

Analog /Digital (-Wandlung)<br />

Automatischer lastabhängiger Bremskraftregler<br />

Aggregate-Modell<br />

Automatisiertes Schaltgetriebe<br />

Antriebsschlupf-Regelung<br />

Beobachtungspunkte (eines MKS)<br />

Bewegungsgleichungen (eines MKS)<br />

Computer Aided Control Engineering<br />

Controller Area Network<br />

Control Prototyping<br />

Cyclic Redundancy Check<br />

Digital/ Analog (-Wandlung)<br />

Differential Algebraic Equation<br />

Deutsche Industrie-Norm<br />

Elektrisches Leitungssystem im Automobil<br />

Elektromagnetische Verträglichkeit<br />

Elektro-pneumatische Bremsanlage<br />

Finite-Elemente-Methode<br />

Freiheitsgrad<br />

Forschungsinstitut für Kraftfahrwesen und<br />

Fahrzeugmotoren Stuttgart<br />

Finite State htachine<br />

Graphical User Interface<br />

Hinterachse<br />

Hardware-in-the-Loop<br />

C AN-Ident ifier<br />

Numerische Integration<br />

Physikalische CAN-Schnittstelle<br />

Input /Output<br />

International Standardisation Organisation<br />

Institut für Verbrennungsmotoren und Kraftfahrwesen<br />

der Universität Stuttgart<br />

Kraftfahrzeug<br />

Kraftelemente (eines MKS)<br />

Local Interconnect Network<br />

Lastkraftwagen<br />

hIehrkörpersystem

hll\.II<br />

Nfz<br />

ODE<br />

PC<br />

PKW<br />

RK4<br />

S AE<br />

SCP<br />

SG<br />

SGII<br />

SIL<br />

SK<br />

TD31-4<br />

TTC14N<br />

TTP<br />

UART<br />

unl<br />

VAN<br />

Man-Machine Interface<br />

Nutzfahrzeug<br />

Ordinary Differential Equation<br />

Personal Computer<br />

Persoiienkraftwagen<br />

Runge-Kutt &-Verfahren vierter Ordnung<br />

Society of Autornotive Engineers<br />

Standard Corporate Protocol<br />

Steuergerät<br />

Steuergeräte-Mode11<br />

Software-in-the-Loop<br />

Starrkörper<br />

Time Division hlultiple ,lccess<br />

Time-Triggered C AN<br />

Time-Triggered Protocol<br />

Universal AsynchronousFtecei~er/Trans<strong>mit</strong> ter<br />

Umgebungs-Modell<br />

Vehicle Area Network

Zusammenfassung<br />

Das Verhalten von Kraftfahrzeugen wird in zunehmendem Maße durch<br />

vernetzte elektronische Steuerungen und Regelungen beeinflusst. Bei der<br />

Entwicklung solcher Kraftfahrzeuge stellt der Einsatz von Siniulations-<br />

verfahren eine wichtige Ergänzung zum Fahrversuch dar. Um aussage-<br />

kräftige Ergebnisse zu erhalten, muss neben den mechanischen Teilsys-<br />

temen eines Kraftfahrzeugs, z.B. Antriebstrang und Fahrdynamik, auch<br />

die <strong>Elektronik</strong> detailliert in der Simulation abgebildet werden.<br />

Einen Sonderfall stellt dabei die Simulation des Fahrzeugverhaltens in<br />

Echtzeit dar. Echtzeitverhalten eines Simulationsprogramms ist z.B. für<br />

Fahrsimulatoren notwendig, bei denen der Mensch interaktiv in die Simu-<br />

lation eingebunden ist. Auch für Hardware-in-the-Loop-Prüfstände, bei<br />

denen elektronische Steuergeräte im geschlossenen Regelkreis <strong>mit</strong> einer<br />

Fahrzeug-Nachbildung betrieben werden, ist Echtzeitverhalten erforder-<br />

lich. Beide Verfahren werden in zunehmendem Maße für Forschungs-,<br />

Entwicklungs- und Ausbildungszwecke eingesetzt.<br />

Gegenstand der vorliegenden Arbeit ist die Entwicklung und Anwen-<br />

dung einer Verfahrensweise zur Erzeugung von Simulationsprogram-<br />

men für Echtzeit-Anwendungen in der Kraftfahrzeugtechnik. Dabei<br />

wird insbesondere die Behandlung elektronischer Steuerungen <strong>mit</strong> CAN-<br />

Vernetzung und die Abbildung von \tTechselwirkungen zwischen elektro-<br />

nischen und mechanischen Teilsystemen in der Simulation betrachtet.<br />

Die Implementierung der Simulationsmodelle erfolgt unter ITerwendung<br />

moderner Software-Werkzeuge <strong>mit</strong> grafischer Modellbeschreibung und<br />

automatischer Code-Generierung, wodurch die manuelle Erstellung von<br />

Programm-Code vermieden wird.<br />

Im ersten Teil der Arbeit wird zunächst eine Einführung in die Echtzeit-<br />

simulation und deren besondere Anforderungen gegeben. Verschiedene<br />

Software-Werkzeuge werden im Hinblick auf ihre Eignung für Echtzeit-<br />

Anwendungen untersucht. Ein Verfahren zur Kopplung mehrerer aus-<br />

gewählter Werkzeuge, welches auf dem Austausch von Programmcode<br />

beruht, wird vorgestellt. Daraiif basierend wird eine \'orgehensweise<br />

zur Beschreibung mechanischer und elektronischer Komponenten und

deren \Vechselwirkungen in der Simiilation <strong>mit</strong>tels einheitlicher Schnittstellen<br />

erarbeitet. Hierbei wird insbesondere darauf geachtet, dass eine<br />

gemischte Verwendung bzw. ein Austauscli von realen und simulierten<br />

Komponenten ermöglicht wird. Nach einer Einführung zur Vernetzung<br />

im Kraftfahrzeug und zum CAN-Protokoll wird die er~vähiite<br />

Iorgehensu~eise zur Beschreibung elektronischer Steuergeräte <strong>mit</strong> C.4N-<br />

Irernetzung erweitert. Verschiedene Konfigurationen zur Darstellung von<br />

CAN-Netzwerken in der Simulation werden diskutiert.<br />

Der zweite Teil befasst sich der praktischen Erprobung der erarbeiteten<br />

l'erfahren anhand der Realisierung zweier Fahrsimulatoren.<br />

Zunächst wird eine Anlage zur Ausbildung von LKW-Fahrern irn Um-<br />

gang <strong>mit</strong> der elektronischen Antriebs- und Breinsensteiieru~ig eines<br />

schweren Nutzfahrzeugs vorgestellt. Als Besonderheit sind elektroni-<br />

sche Steuergeräte <strong>mit</strong> C AN-Vernetzung sowie Aktuatoren als reale Teile<br />

in diesen Fahrsimulator integriert. Tfeitere elektronische Steuergeräte<br />

und der Antriebsstrang sind dagegen in einem Simulationsrnodell abge-<br />

bildet. Es wird ein echtzeitfähiges Modell des Antriebsstranges schwe-<br />

rer Nutzfahrzeuge vorgestellt, das den besonderen Anforderungen von<br />

Fahrsimulatoren Rechnung trägt. Ein Fahrsimulator <strong>mit</strong> vergleichbarer<br />

Konzeption ist aus der Literatur bisher nicht bekannt.<br />

Ein weiterer Fahrsimulator zur Untersuchung der Fahrdynamik von<br />

LKW-Zügen wird beschrieben. Neben einer detaillierten Abbildung der<br />

Fahrdynamik als hlehrkörpersystein wird auf die Berechnung von Reifen-<br />

kräften und die Er<strong>mit</strong>tlung des Lenkradmoments für alle in einem Fahr-<br />

simulator auftretenden Betriebszustäride eingegangen. Abschließend er-<br />

folgt eine Beschreiburig der Mensch-h4aschiiie-Schnittstelle. insbesondere<br />

einer aktiven Lenkeinheit sowie eines ICrfahrens zur Erzeugung \-On rea-<br />

lit ät snaheii r\lotorgeräiischeii in Fahrsirnulatoreri.

Abstract<br />

The behavior of motor vehicles is influenced increasingly by networked<br />

electronic control systems. In the development of motor vehicles of this<br />

type, simulation procedures are an important supplement to driring<br />

tests. Apart from the mechanical sub-systems of a motor vehicle, such<br />

as the drive train and driving dynamics, its electronics must also be<br />

represented in simulation in great detail in order to obtain meaningful<br />

results.<br />

A special case here is the real-time simulation of vehicle behavior. Real-<br />

time behavior of a simulation program is required for example for driving<br />

simulators where the driver is participating interactively in the simula-<br />

tion. Real-time behavior is also required in hardware-in-the-loop test<br />

stands, where electronic control units are operated in a closed loop con-<br />

trol circuit with a vehicle representation. Both procedures are increas-<br />

ingly used for research, development and training purposes.<br />

The goal of the thesis at hand is the development and application of<br />

a method for generating simulation programs for real-time applications<br />

in automotive engineering . The treatment of electronic control systems<br />

with CAN (Controller Area Network) and the interactions between elec-<br />

tronic and mechanical subsystems is given particular consideration in<br />

the simulation. The simulation models are implemented with the help<br />

of modern software tools working with graphical model description and<br />

automatic code generation, thus av-oiding the manual creation of pro-<br />

gram code.<br />

The first part of this thesis provides an introduction to real-time simulation<br />

and its special requirements. Various software tools are discussed<br />

with respect to their suitability for real-time applications. A procedure<br />

for linking several selected tools is introduced, based on the exchange<br />

of program code. Based on this, a method for describing mechanical<br />

and electronic components and their interactions in si~nulation models<br />

is developed by means of exactly defined interfaces. Parti~ula~r care is<br />

given to the aspect that a mixed application, i.e. an exchange of real and<br />

simulated component s is made possible. -4fter an introduction to net-

lvorking in motor rehicles and tlie CAN protocol, the abore-meritioned<br />

method for describing electronic control iinit,s with CAN is expanded.<br />

Jarious configurations used for representing CAN networks in simula-<br />

tion are discussed.<br />

The second part describes the practical testing of the developed pro-<br />

cedures presenting the realization of two driving simulators. First, a<br />

training facility for truck drivers is introduced, where the handling of<br />

the electronic drive and brake control system of a heavy commercial ve-<br />

hicle can be practised. A special feature here is that the electronic control<br />

units and the CAN bus as well as actuators are integrated as real compo-<br />

nents into this driving simulator. Other electronic control units and the<br />

drive train, however, are represented in a simulation model. Areal-time<br />

capable drive train model of heavy commercial vehicles is introduced.<br />

which rneets the special requirements of driving simulators. A driving<br />

simulator using a comparable approach is not known from literature until<br />

now.<br />

A further driving simulator for the investigat ion of the driving dyna-<br />

mies of truck-trailer combinations is described. In addition to a detailed<br />

representation of the driving dynamics as a multi-body system, the cal-<br />

culation of tire forces and the determination of the steering-wheel torque<br />

for driving simulator applications are discussed in detail. In conclusion,<br />

the man-machine interface is described, particularly an active steering<br />

unit as weil as a proccdure for gcnerating realistic engine noise in driving<br />

simulators.

1 Einleitung<br />

Die numerische Simulation besitzt große Bedeutung im Entwicklungs-<br />

Prozess von Kraftfahrzeugen, unter Anderem bei der Entwicklung kom-<br />

plexer elektronischer Steuerungen. Neben der theoretischen hlodellbil-<br />

dung verursacht die Implementierung der abgeleiteten Modellgleichun-<br />

gen in einer Simulationsumgebung erheblichen Aufwand. Der Einsatz<br />

leistungsfähiger Software-Werkzeuge stellt hierbei einen Weg zur Stei-<br />

gerung der Effizienz und der Zuverlässigkeit dar. Allerdings sind heute<br />

keine Software-Werkzeuge verfügbar, <strong>mit</strong> denen sich das gesamte Aufga-<br />

benspektrum effizient abdecken läßt . ITielmehr tendiert die Entwicklung<br />

zu höherer Spezialisierung der Werkzeuge. Daraus ergibt sich die Not-<br />

wendigkeit, eine begrenzte Anzahl von Werkzeugen auszuwählen und<br />

sinnvoll zu kombinieren.<br />

Neben der ,,herkömmlichenu Nicht-Echtzeit-Simulation erfordern eini-<br />

ge Anwendungen die Ausführung von Simulationen in Echtzeit. Der<br />

Hardware-in-the-Loop-Betrieb von neu entwickelten elektronischen Steu-<br />

ergeräten ermöglicht deren Erprobung bereits vor der Verfügbarkeit eines<br />

Fahrzeug-Prototyps. Dabei können auch Betriebszustände nachgebildet<br />

werden, die im Fahrversuch <strong>mit</strong> hohem Risiko für Leib und Leben der<br />

Testfahrer verbunden sind.<br />

Ein weiteres Echtzeit-Testverfahren stellt die interaktive Erprobung neu-<br />

er Software-Funktionen dar. Hierbei wird der menschliche Bediener in<br />

die Simulation eingebunden. Wenn die Bedienung der Simulation über<br />

eine realitätsnahe Mensch-Maschine-Schnittstelle erfolgt und ausreichen-<br />

de Rückmeldungen verfügbar sind, wird eine subjektive Bewertung von<br />

Fahrfunktionen möglich. Solche Anlagen werden als Fahrsimulatoren be-<br />

zeichnet. Sie werden für Schulungs-, Demonstrations- und Forschungs-<br />

zwecke eingesetzt.<br />

I .1 Motivation<br />

Sowohl für Hardware-in-the-Loop-Anwendungen als auch für Fahrsimu-<br />

latoren werden aufwändige Simulationsmodelle benötigt, die bisher zu-

meist manuell in Programm-Code umgesetzt werden. Die rnaiiuelle Co-<br />

dierung ist jedoch zeitraubend und fehleranfällig. Durch den Einsatz<br />

von Code-Generatoren kann eine schnellere und zuverlässigere Erzeu-<br />

gung von Simulationsprogrammen erreicht werden. Diese Tendenz wird<br />

dadurch begünstigt, dass die verfügbare Rechenleistung in den vergari-<br />

genen Jahren rasch zugenommen hat. So können heute aucli komplexe.<br />

unter Einsatz von MKS-Gleichuiigsgeneratoren erzeugte Siinulationsmo-<br />

delle der Fahrzeugdynamik auf preiswerten Einprozessor-Rechnern in<br />

Echtzeit ausgeführt werden, während dies noch vor wenigen Jahren nur<br />

<strong>mit</strong> Parallelverarbeitung möglich war.<br />

Bis heute werden häufig getrennte i2'ege bei der Realisierung von Si-<br />

~nulationsmodellen für Nicht-Echzeit- und Echt,zeit-Ann-eildungeil be-<br />

schritten, indem jeweils eigene Modell-Bibliotheken erstellt und auf un-<br />

einheitliche Jt'eise implementiert werden. Ilit zeitgemäßen Software-<br />

Iyerkzeugen ist für viele Anwendungen eine Jkreinheitlichung möglich.<br />

Eine aktuelle Herausforderung fiir die Simulation stellt die rasche Zu-<br />

nahme elektronischer Steuerungen im Fahrzeug dar. Neben den mechani-<br />

schen Aggregaten eines Fahrzeugs und deren Wechselwirkungen müssen<br />

die Steuergeräte sowie die Sensorik und Aktuatorik im Simulationsmo-<br />

dell abgebildet werden. Hierbei ist auch die Datenkommunikation zwi-<br />

schen den Steuergeräten, die heute überwiegend unter Einsatz des CAN-<br />

Protokolls realisiert wird, in der Simulation darzustellen.<br />

In Bild 1.1 sind beispielhaft die liechselwirkurigen zwischen den .\ggre-<br />

gaten und den elektronischen Steuergeräten eines Fahrzeugs dargestellt.<br />

Eine ähnliche Fahrzeug-Konfiguration wird z.B. in [I] beschrieben.<br />

Zusätzlich sind die iiechselwirkungen zwischen Fahrzeug, Fahrer lind<br />

Urngebiing eingezeichnet (ohne _Ilrispruch auf Jollständigkeit). Diese sind<br />

insbesondere bei der Realisierung der Betriebs-Softn-are für Fahrsimula-<br />

toren zu berücksichtigen.<br />

1.2 Stand der Forschung und Technik<br />

Die vorliegende Arbeit befasst sich <strong>mit</strong> der Erzeugung von Simulationsprogrammen<br />

für Echtzeit-Anwendungen unter Berücksichtigung oernetzter<br />

<strong>Elektronik</strong>. Zwei wichtige A~iwendungsfälle für solche Sirnulationsprogramrne<br />

sind interaktive Fahrsimulatoren sowie Hardware-in-the-<br />

Loop-Simulatiorisanlagen. Im Verlauf dieser Arbeit wird gezeigt? dass für<br />

diese beiden Ann~endungen nahezu identische Aiiforderungeii bezüglich

., r---'------------------------------------------------------------------------------,<br />

I I<br />

I<br />

1<br />

I<br />

I<br />

Elektronische Fahrzeug I<br />

Steuergeräte<br />

I<br />

i i I<br />

I ! !<br />

I<br />

instrument<br />

Aggregate<br />

Verbren-<br />

+ nungs- -I I<br />

Luftmasse, ... motor<br />

Schaltung<br />

....................<br />

L / Pedalkraft !<br />

1 I I<br />

j / Brems- I<br />

! / betätigung : Ventil-<br />

Automatik-<br />

Brems-<br />

i i anlage, - I<br />

1 I<br />

1<br />

I I<br />

Rad- I<br />

I I<br />

! regelung<br />

drehung<br />

I<br />

I i<br />

i i L----------------------------- Raddrehzahlen<br />

I<br />

I i<br />

I I<br />

I<br />

I<br />

1 I / L ............................. Lenkwinkel I<br />

I I I<br />

I<br />

I<br />

I<br />

1 Lenkmoment 1<br />

i* i i<br />

Lenkung -<br />

i j Lenkeinschlag 1<br />

1 i I<br />

I<br />

I<br />

Gierrate,<br />

I I<br />

I 1<br />

I<br />

; I<br />

Querbeschleunigung<br />

I--------------------------------------<br />

Fahrwerk, - 1<br />

I I<br />

I<br />

Reifen,<br />

I<br />

j Beschleunigung<br />

I<br />

I i dynamik - I<br />

Fahrzeug- I<br />

1 ; I<br />

i 1<br />

-1 L----------------------------------------------------------------- ------j<br />

Umgebung<br />

- !<br />

- Mechanik ------W Elektrik ---- CAN<br />

Sonstige<br />

Bild 1.1: Informatio~~saustaus~h<br />

zwischen Fahrzeug, Fahrer und Umge-<br />

bung sowie fahrzeuginterne Wechsel\virkungen (Beispiel)<br />

i<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

t<br />

I<br />

I<br />

1<br />

I

I\lodellierungsumfang und Eigenschaften des ausführbaren Sirnulations-<br />

Programms bestehen. Deshalb wird zunächst der aktuelle Stand der Ent-<br />

wicklung im Zusammenhang <strong>mit</strong> den wichtigsten Einsatzgebieten beider<br />

Verfahren aufgezeigt.<br />

Anschließend wird der Stand bei der hlodellbildung und der numerischen<br />

Simulation von Kraftfahrzeugen unter Anwendung von Software-<br />

Werkzeugen dargestellt. Aufgrund der in dieser Arbeit betrachteten An-<br />

1%-endungen steht hierbei die Echtzeitsimulation von Xutzfahrzeugen im<br />

TTordergrund. Abschließend erfolgt eine Einführung in die aktuellen und<br />

zukünftige Technologie zur Datenkommunikation irr1 Kraftzfahrzeug.<br />

1.2.1 Fahrsimulat oren<br />

Der Wunsch nach einer Berücksichtigung des komplexen Regelverhaltens<br />

des Menschen als Fahrer und die bis heute unbefriedigende Nachbildung<br />

dieses Verhaltens in AlTodellen führt in den 1960er Jahren zur Entwick-<br />

lung der ersten interaktiven Fahrsimulatoren [2]. Aufwändige TJnt ersu-<br />

chungen werden zur Auslegung des Bewegungssystems durchgeführt. In<br />

[3] wird untersucht, welche Beschleunigungen erzeugt werden müssen;<br />

da<strong>mit</strong> die simulierte Fahrt, für den „Fahrercc realistisch erscheint. Ei-<br />

ne Fahrsimulations-Anlage <strong>mit</strong> Bewegungs- und Sichtsystem (Ilodell-<br />

Landschaft) wird beschrieben. Zur Berechnung der Fhhrzeugbem-egung<br />

werden zunächst Analogrechner eingesetzt .<br />

In der Folgezeit werden Fahrsimulatoren <strong>mit</strong> digitaler Steuerung rea-<br />

lisiert und in Forschung und Entwicklung eingesetzt. Über aufwändige<br />

Bewegungs- und Sichtsysteme verfügen z.B. die derzeit größten Anlagen<br />

in Berlin [4] lind an der Iowa State University [5].<br />

Anwendungen in der Forschung:<br />

Fahrsimulatoren werden auf vielfältige U7eise zur Erforschung und Mo-<br />

dellierung des Fahrerverhaltens verwendet.<br />

Ein Fahrermodell zur Beschreibung des Lenkverhaltens auf der Ba-<br />

sis von neuronalen Netzen beschreibt [6]. Das Training des neurona-<br />

len Netzes erfolgt unter k'erwendung von aufgezeichneten Daten aus<br />

Fahrsimulator-Versuchen. In [7] wird ein Fahrermodell vorgestellt, das<br />

sowohl in Verkehrssimulations-Programmen als auch zur Simulation an-<br />

derer Terkehrsteilnehmer in interaktiven Fahrsirriulatorc3n eingesetzt wer-

den kann. Hier<strong>mit</strong> werden insbesondere die Fahrsituationen Folgefahrt<br />

und Spurwechsel abgedeckt. Ein Verfahren zur Untersuchung des indi-<br />

viduellen Interaktions- und Selbstorganisations-lTerhaltens von Fahrern<br />

<strong>mit</strong>tels zweier gekoppelter Fahrsimulatoren beschreibt 181.<br />

Auch in der Unfallforschung kommen in zunehmendem Maße Fahrsi-<br />

mulatoren zum Einsatz. So ist z.B. die Erkennung veränderten Fah-<br />

rerverhaltens bei Ablenkung durch die Benutzung von Mobiltelefo-<br />

nen Gegenstand einer in [9] vorgestellten Fahrsimulator-Untersuchung.<br />

Die Beeinträchtigung der Spurhaltung bei der Betätigung komplexer<br />

Fahrzeug-Bedienelemente <strong>mit</strong> Bildschirmanzeige (z.B. Navigationssys-<br />

teme) während der Fahrt wird in [10] untersucht.<br />

In einer weiteren Studie [ll] wird festgestellt, dass viele Fahrer in Ge-<br />

fahrensituationen den Abstand zum vorausfahrenden Fahrzeug falsch<br />

einschätzen. Auch die Erkennung der Ermüdung des Fahrers ist Ge-<br />

genstand von Fahrsimulator-Studien. Beispielsweise beschreibt [12] ein<br />

Verfahren zur Klassifikation des Ermiidungszustandes aus dem im Fahr-<br />

simulator erfassten Lenkwinkelverlauf.<br />

Anwendungen in der Kraftfahrzeug-Entwicklung:<br />

Ein relativ neues Anwendungsgebiet für Fahrsimulatoren ist die Ent-<br />

wicklung und Erprobung elektronischer Kfz-Systeme, insbesondere von<br />

Fahrerassistenzsystemen und Drive-by- Wire-Technologien.<br />

Ein kompakter Fahrsimulator ohne Bewegungssystem zum Einsatz bei<br />

der Entwicklung von Steuergeräte-Software wird vom Autor der vorlie-<br />

genden Arbeit bereits 1997 beschrieben [13]. Diese Anlage wird in [14]<br />

bei der Entwicklung einer Schaltstrategie für Automatisierte Schalt ge-<br />

triebe verwendet. Im Mittelpunkt steht die subjektive Bewertung der<br />

Steuergeräte-Funktionen, z.B. der Schalthäufigkeit.<br />

In den darauffolgenden Jahren werden weitere Aukaukonzepte für kom-<br />

pakte, preiswerte Fahrsimulatoren und deren Verwendung im Entwick-<br />

lungsprozess für Kfz-<strong>Elektronik</strong> beschrieben 115, 161.<br />

Eine vergleichende Untersuchung von konventionellen und neuarti-<br />

gen Fahrzeug-Bedienelementen wie Joysticks im Fahrsimulator wird in<br />

[17] vorgelegt. In 1181 wird das Sicherheitskonzept von Steer-by-Wire-<br />

Lenkungen <strong>mit</strong> variabler Lenkübersetzung im Fahrsimulator untersucht.<br />

Es wird u.il. festgestellt, dass eine sprunghafte Änderung der Lenküber-<br />

setzurig, die bei der Aktivierung einer theoretisch denkbaren, mechani-

schen Rückfallebene eintreten kann, vom Fahrer nicht beherrscht würde.<br />

Diese Anwendungen zeigen beispielhaft den Nutzen von Fahrsimulator-<br />

Untersuchungen bereits in der Frühphase der Entwicklung neuartiger<br />

Fahrzeugtechnologien auf. Einerseits können unbrauchbare t'echnische<br />

Lösungen bereits irn lTorfeld ausgesondert werden, wodurch die Anzahl<br />

kostspieliger Fahrzeug-Prototypen reduziert wird. Andererseits sind zu-<br />

mindest qualitative Aussagen zum Fahrzeug- ilild Fahrerverhalten in<br />

Grenzsituationen gefahrlos möglich.<br />

Anwendungen in der Ausbildung:<br />

Bild 1.2: Ein früher Ausbildungs-Fahrsimulator! Der Fahrschüler erhält<br />

Anweisungen über eine Diaprojektion (oben). Die Fahrsituation<br />

wird durch ein mechanisches Sichtsy~t~em dargestellt (Quelle:<br />

Sicherheit im Automobilrennsport , Lausariiie, ca. 1970).

Bereits frühzeitig wird die Bedeutung von Fahrsimulatoren für die Schu-<br />

lung von Kraftfahrern erkannt, Bild l .2. Trotzdem werden Fahrsimula-<br />

toren zur Schulung von PKW- und LKW-Fahrern bis heute nur verein-<br />

zelt eingesetzt. In [19] wird eine Anlage <strong>mit</strong> aufwändigem Sichtsystem<br />

beschrieben. Ziel dieser Simulator-Ausbildung ist die Beherrschung von<br />

schweren LKW-Zügen in fahrdynamischen Grenz- und Notsituationen.<br />

In Japan ist die Simulator-Ausbildung seit 1996 ein Pflichtbestandteil<br />

der Motorrad-Ausbildung (201.<br />

Ein zukünftiges, kommerzielles Einsatzgebiet für Fahrsimulatoren ist<br />

die Demonstration des Nutzens neuartiger Fahrerinformations- und<br />

Assistenzsysteme gegenüber potenziellen Fahrzeugkäufern und die<br />

Einführung in deren Bedienung. Zu diesem Zweck wurde auch der in<br />

Kapitel 4 beschriebene LKW-Fahrsimulator konzipiert und realisiert.<br />

In den 1980er Jahren wird die Hardware-in-the-Loop-Simulation (HIL) ,<br />

also der Betrieb von elektronischen Steuergeräten und Kraftfahrzeug-<br />

Komponenten im geschlossenen Regelkreis <strong>mit</strong> einem echtzeitfähigen Si-<br />

mulationsmodell, in der Kfz-Entwicklung eingeführt. Zunächst werden<br />

HIL-Anlagen <strong>mit</strong> einem einzelnen eingebundenen Steuergerät für ein au-<br />

tonom arbeitendes Aggregat realisiert.<br />

ABS, Fahrwerk und Fahrdynamikregelung:<br />

Eine frühe Anwendung ist die Laborerprobung von elektronischen Blo-<br />

ckierverhinderern. Bereits 1984 wird in [21] ein HIL-Prüfstand für ABS<br />

im PKW beschrieben. Hierbei wird ein stark vereinfachtes Modell<br />

der PKW-Fahrzeugdynamik auf einem Digitalrechner ausgeführt. Die<br />

Raddrehzahl-Sensorsignale werden synthetisch generiert und dem ABS-<br />

Steuergerät zugeführt. Die Aktuatorik (d.h. die Bremshydraulik) wird<br />

ebenfalls vereinfacht im Simulationsmodell abgebildet.<br />

Dieses Grundprinzip wird bis heute nahezu unverändert für ,4BS und<br />

Fahrdynamikregelungen angewandt, wobei die verwendeten Simulations-<br />

modelle für die Fahrzeugdynamik und die Bremshydraulik aufgrund der<br />

gestiegenen Verarbeitungsleistung von Echtzeitrechnern immer det ail-<br />

lierter werden 1221.<br />

Allerdings stößt die Echtzeitsimulation mechanisch-hydraulischer Aggre-

gate (z.B. Bremsen und Lenkungen) auch heute noch an numerische<br />

Grenzen. Vor allem hochfrequente Schwingungen und Strömungseffekte<br />

der Hydraulikflüssigkeit in den Leitungen führen bei detaillierter Mo-<br />

dellierung zu steifen Differenzidgleichungs-Systemen. die im Echtzeitbe-<br />

trieb kaum lösbar sind.<br />

Da diese Effekte jedoch für die -4uslegung von Regelalgorithmen von<br />

großer Bedeutung sind, werden auch Prüfstandskonzepte beschrieben,<br />

bei denen neben dem elektronischen Steuergerät Teile der Aktuatorik<br />

und Sensorik als reale Hardware eingebunden sind, z.B. die Bremshy-<br />

draulik bei einem in [23] beschriebenen HIL-Prüfstand für ABS.<br />

Dieses ITerfahren wird auch für andere Fahrmrerkskomponenten ange-<br />

wandt. So wird in [21] eine HIL-Anordnung beschrieben: bei der eine<br />

reale PKW-Radaufhängung <strong>mit</strong>samt den Giimmilagern, den Aufbaufe-<br />

dern und der Lenkung auf einem Prüfstand im geschlossenen Kreis ~nit<br />

einem Simulationsmodell der Fahrdynamik erprobt wird.<br />

Motor und Antriebsstrang:<br />

HIL-Prüfstande zur Untersuchung von h/lotorsteuerungen sind seit etwa<br />

zehn Jahren im Gebrauch. Gegenstand der Betrachtung ist häufig die<br />

korrekte Funktion der Sensorik und Aktuatorik des 140tors. Das ITerhal-<br />

ten des lTerbrennungsmotors wird im Simulationsmodell meist durch eine<br />

Kombination von stationären, gemessenen Kennfeldern und vereinfach-<br />

ten physikalischen Beziehungen abgebildet, da eine detaillierte a-priori-<br />

Berechnung von Ladungswechsel und ITerbrennung aufgrund der hohen<br />

erforderlichen Rechenleistung in Echtzeit nicht möglich ist.<br />

Eine ,\nwendung des HIL-Verfahrens bei der Ent~vicklurig der elektro-<br />

nisch geregelten Kraftstoff-Einspritzung von Nutzfahrzeugmotoreri be-<br />

schreibt [25]. Über die Erprobung von llotorsteuerungen für Ottornoto-<br />

ren unter IJerm-endung echtzeitfähiger Simulationsmodelle in einer HIL-<br />

Konfiguration wird in [26] berichtet.<br />

Die Entwicklung von Regelalgorithmen für Verbrennungsmotoren und<br />

die Parameteroptimierung im HIL-Betrieb stehen dagegen noch am An-<br />

fang, da heute keine echtzeitfähigen Simulationsmodelle von Ierbren-<br />

nungsmotoren bekannt sind, welche die thermodynamischen Vorgänge<br />

<strong>mit</strong> hinreichender Qualität wiedergeben. Dies gilt L-or allem für das in-<br />

stationäre ITerhalten.<br />

Ein weiteres Einsatzgebiet des HIL-LTerfahrens ist die Entwicklung von

Getriebesteuerungen. So wird z.B. in [27] die Labor-Erprobung neuer<br />

Steuerungsfunktionen eines Vier gang- Automatikgetriebes unter Einsatz<br />

eines PC-basierten Hardware-in-the-Loop-Systems beschrieben. Gegen-<br />

stand von [28] ist ebenfalls die Entwicklung einer HIL-Umgebung für<br />

Steuergeräte von Automatikgetrieben. Beschrieben wird ein umfangrei-<br />

ches Simulationsmodell des Antriebs, der Fahrzeuglängsdynamik, der<br />

Fahrstrecke und des Fahrers. Die Anlage wird zur Entwicklung adapti-<br />

ver Schaltalgorithmen verwendet. Über die HIL-Erprobung der elektro-<br />

nischen Steuerung für einen parallelen Hybrid-Antrieb <strong>mit</strong> elektrischem<br />

Zusatzantrieb am Getriebeeingang wird in [29] berichtet.<br />

Bei der Entwicklung von Antriebssträngen ist auch der Betrieb realer<br />

Aggregate. 2.B. \*erbrennungsmotor, Kupplung und Getriebe einschließ-<br />

lich der zugehörigen Steuerelektronik auf einem dynamischen Prüstand<br />

im geschlossenen Regelkreis <strong>mit</strong> einem Simulationsmodell des „Restfahr-<br />

zeugs" gebräuchlich. Auch diese Konfiguration wird als Hardware-in-<br />

the-Loop bezeichnet. Das Fahrzeugmodell berechnet in der Regel die<br />

Fahrwiderstände und den Fahrzustand. Daraus werden Steuersignale für<br />

das zu untersuchende Aggregat er<strong>mit</strong>telt, z.B. die Drosselklappenstel-<br />

lung für einen Verbrennungsmotor. Der Prüfstand wird ebenfalls aus<br />

der Simulation gesteuert, z.B. durch Vorgabe des Lastmoments für eine<br />

Bremsmaschine.<br />

Einen HIL-Aufbau, bestehend aus einem dynamischen Verbrennungs-<br />

motor-Prüfstand <strong>mit</strong> drehmomentgeregelter E-Maschine sowie einem<br />

Echtzeit-Simulationsmodell der Fahrzeug-Längsdynamik <strong>mit</strong> drei Frei-<br />

heitsgraden und einem Fahrermodell beschreibt [30]. Eine ähnliche An-<br />

wendung wird in [31] vorgestellt, um das Irerbrauchs- und Emissions-<br />

verhalten von \Terbrennungsmotoren bei standardisierten Fahrzyklen<br />

zu untersuchen und zu verbessern. Der Aufsatz [32] befasst sich <strong>mit</strong><br />

numerischen Aspekten bei der Modellbildung für solche Prüfstands-<br />

Anwendungen.<br />

HIL für vernetzte Kfz-<strong>Elektronik</strong>:<br />

Mit der Iernetzung der elektronischen Systeme im Kraftfahrzeug wird<br />

es notwendig, Datennetzwerke in die Hardware-in-the-Loop-Simulation<br />

einzubeziehen. Hierbei wird bis heute zumeist das Konzept der Rest-<br />

bussirnulation angewendet, d.h. die Daten, die das zu prüfende Steuer-<br />

gerät benötigt, werden im Simulator er<strong>mit</strong>telt und über eine Schnitt-<br />

stelle ausgegeben. In [33] wird ein Prüfstand für Getriebe-Steuergeräte

<strong>mit</strong> CXN-Restbussimulation beschrieben. Hierbei werden die Botschaf-<br />

ten nachgebildet, die im realen Netzwerk vom hlotorsteuergerät ausgege-<br />

ben werden. Dieses Konzept wird in den Folgejahren für umfangreichere<br />

Netzwerke erweitert. In [34] wird die CLAN-Simulation mehrerer Stleuer-<br />

geräte vorgenommen, wobei ein Dieselmotor-Steuergerät real vorhanden<br />

ist.<br />

Bei neueren HIL-Konzepten uerden mehrere vernetzte Steuergeräte<br />

gleichzeitig als reale Hardware betrieben. Den ersten Aufbau dieser Art<br />

<strong>mit</strong> drei CAN-vernetzten Steuergeräten (Motor. Getriebe und Antriebs-<br />

Schlupfregelung) beschreibt [35].<br />

HIL-Anlagen für vernetzte <strong>Elektronik</strong> werden häufig realisiert, in-<br />

dem mehrere HIL-Anlagen für einzelne Steuergeräte <strong>mit</strong>tels schnel-<br />

ler Datenverbilidungen zusamn~engeschaltet werden. Die zugehörigen<br />

Simulations-Teilmodelle werden entweder auf einem zentralen Echtzeit-<br />

rechner oder auf mehreren Einzelrechnern verteilt ausgeführt. Eine sol-<br />

che Anordnung <strong>mit</strong> drei CAN-vernetzten Steuergeräten wird z.B. in [36]<br />

vorgestellt.<br />

Den HIL-Simulator für die vernetzte <strong>Elektronik</strong> in einem schweren<br />

Nutzfahrzeug beschreibt [37]. Zunächst wird das System zum Betrieb<br />

von drei Steuergeräten (I\Iotorsteuerung, Bremsanlage und Fahrzeug-<br />

Koordinator) <strong>mit</strong> C-AN-Vernetzung konzipiert. In [38] wird eine erwei-<br />

terte Anlage für acht St,euergerät e vorgestellt.<br />

Systematik der HIL-Verfahren<br />

Bei den bisher zitierten Arbeiten steht die Realisierung von HIL-<br />

Systemen für eine bestimmte Anwendung im lTordergrund. Llit der wei-<br />

t en Verbreitung von HIL-Systenien in der Aut omobilindustrie in jüngs-<br />

ter Zeit und der da<strong>mit</strong> verbundenen hohen Investitionskosten rücken<br />

Fragestellungen zur Standardisierung, Erweiterbarkeit und Jiiederver-<br />

wendbarkeit von HIL-Anlagen zunehmend ins Bewusstsein der Anbieter<br />

und Anwender. In 1391 wird die systematische Projektierung von HIL-<br />

Anlagen einschlieDlich der zugehörigen Echtzeit-Simulationsmodelle und<br />

deren Schnittstellen diskutiert. Der Autor schlägt eine komponenten-<br />

orientierte Beschreibungsforni sowie die Einführung virtueller Fahrzeug-<br />

komponenten vor.<br />

Maßgebend für den erfolgreichen Einsatz des HIL-l'erfahrens ist auch<br />

die Definition und Bereitstellung von Testszenarien. die einen möglichst

hohen Teil der möglichen Betriebszustände der überprüften Steuergeräte<br />

bzw. der darin enthaltenen Software abdecken. Die Arbeit [40] befasst<br />

sich <strong>mit</strong> der Erzeugung und Durchführung von Testsequenzen am Bei-<br />

spiel der CAN-vernetzten Beleuchtungseinrichtungen eines PKW. Vorge-<br />

stellt wird ein grafisches Werkzeug zur Erstellung von Testprogrammen<br />

in Form von Blockschaltbildern und zur Auswertung der Testergebnisse.<br />

Ein Verfahren zur automatischen Fehlerfall-Erzeugung, dessen Imple-<br />

mentierung auf einem HIL-Simulator und die Erprobung anhand von<br />

hlodellprozessen beschreibt [4l].<br />

1.2.3 Echtzeitsimulation von Kraftfahrzeugen<br />

Für die beschriebenen Anwendungen Fahrsimulator und Hardware-in-<br />

the-Loop werden Simulationsprogramme des Kraftfahrzeugs oder sei-<br />

ner Teilsysteme benötigt, die so beschaffen sind, dass sie in Echt-<br />

zeit auf digitalen Rechnern ausgeführt werden können. Im Folgenden<br />

wird zunächst eine Ubersicht zur numerischen Kfz-Simulation ohne<br />

Echtzeit-Anforderungen gegeben. Anschließend wird der Stand der Tech-<br />

nik bei der Echtzeitsimulation beschrieben. Bei beiden Simulationsver-<br />

fahren wird jeweils auch der Einsatz von proprietären und kommerzi-<br />

ellen Software-Werkzeugen betrachtet. Besondere Beachtung wird den<br />

Nutzfahrzeugen zuteil, da diese im anwendungsnahen Teil dieser Arbeit<br />

(Kapitel 4 und Kapitel 5) im Vordergrund stehen.<br />

Entwicklung der numerischen Kraftfahrzeug-Simulation<br />

Die L7erbreitung digitaler Rechner seit den 1970er Jahren ermöglicht<br />

die Erstellung numerischer Simulationsmodelle für das instationäre iTer-<br />

halten von Kraftfahrzeugen. In [42] wird bereits 1973 ein Simulati-<br />

onsprogramm für LKW-Sattelzüge beschrieben und zur Untersuchung<br />

von Auflieger-Lenkungen verwendet. Die Fahrdynamik von Gliederzügen<br />

wird in [43] modelliert und <strong>mit</strong>tels digitaler numerischer Simulation un-<br />

tersucht. In 1441 erfolgt eine Simulation des Bremsverhaltens von Nutz-<br />

fahrzeugen <strong>mit</strong> Retardern.<br />

Bei Industrieunternehmen werden komplexe Fahrzeug-Simulationspro-<br />

gramme entwickelt, insbesondere für PKW. Ein bekannter Vertreter ist<br />

das Programmpaket F.4SIM der Robert Bosch GmbH [45]. Diese Rea-<br />

lisierungen <strong>mit</strong> hohem Detaillierungsgrad basieren auf der manuellen<br />

Ableitung und Codierung von Modellgleichungen, zumeist in den Pro-

grammiersprachen FORTRAN oder C. Die manuelle Ableitung von Be-<br />

wegungsgleichungen für Kraft>fahrzeuge wird ausführlich in [46] behan-<br />

delt.<br />

Zur automat~sch~en Generierung der Bewegungsgleichungen für<br />

Fahrdynamik-Modelle werden Mehrkörperdynanrik-Sirnulationspro-<br />

gramme (hlKS-Werkzeuge) wie ADAMS [ii] und SIlIPACK [48]<br />

eingesetzt. In [49] wird die automatische Generieruiig von Bewe-<br />

gungsgleichungen für einen Sat.telzug <strong>mit</strong> beweglicher Ladung unter<br />

Verwendung des I1IKS-Programms MESA VERDE beschrieben.<br />

Die Simulation von Standard-Fahrmanövern für einen Ierteiler-LKW<br />

<strong>mit</strong> SISLPACK wird in [50] durchgeführt. Ebenfalls unter Einsatz von<br />

SIXIP.4CK werden in [51] Unt ersucliiingen riir Fahr(lynamikregr1ung<br />

schwerer LKW beschriebcri.<br />

Afit zunehmender Rechenleistung und Speicherkapazität werden numeri-<br />

sche Simulationen <strong>mit</strong> hohem Detaillierungsgrad möglich. So wird in [52]<br />

das in SIMPaCK implementierte Fahrdynamik-Modell eines Sattelzuges<br />

vorgestellt, welches Ca. 180 Freiheitsgrade besitzt und zum Entwurf von<br />

Funktionen für eine Fahrdynamikregelung dient.<br />

Die heute erreichte, hohe Qualität bei der Fahrdynamiksimulation<br />

ermöglicht es, eine Bewertung des Fahrverhaltens für standardisierte<br />

Fahrrnanöver in der Simulation vorzunehmen. In [53] werden solche Fahr-<br />

rnanöver, die im PKW-Bereich seit vielen Jahren genormt sind, auch für<br />

Yutzfahrzeuge definiert und unter Einsatz eines in ADAXIS prograrn-<br />

rnierten Simulationsmodells auf ihre Eignung untersucht.<br />

Echtzeitsimulat ion<br />

Bei den im vorherigen Abschnitt aufgeführten Arbeiten wird die<br />

Ausführung von Simulat ionsmodellen im Echtzeit bet rieb zunächst nicht<br />

betrachtet. hlit der Verbreitung von Echtzeit-Anwendungen wie HIL seit<br />

den 1990er Jahren rückt dieser Aspekt jedoch immer rriehr in den Vor-<br />

dergrund.<br />

In [54] wird eine für Echtzeit-Anwendungen geeignete, umfangreiche Mo-<br />

dellbibliothek <strong>mit</strong> der Bezeichnung FADYS beschrieben und bei der<br />

Entwicklung einer Fahrdynainikregelung für PKW eingesetzt. Auch von<br />

dem bereits erwähnten Programmpaket FASIAI existiert eine für HIL-<br />

Anwendungen geeignete Echtzeit-Version [55]. Solche manuell codier-<br />

ten hIodel1-Bibliotheken besitzen aufgrund der langjährigen Entwicklung

einen hohen Reifegrad und sind sehr effizient bezüglich des Rechenauf-<br />

wandes. Deren Pflege und die Implementierung zusätzlicher Komponen-<br />

ten verursacht jedoch erheblichen Aufwand.<br />

Daher werden seit einigen Jahren bei der Fahrzeugsimulation Software-<br />

Werkzeuge <strong>mit</strong> grafischer Beschreibung von Simulationsmodellen einge-<br />

setzt. Diese sind auch zur Abbildung von elektronisch geregelten Kfz-<br />

Systemen geeignet. Die Erstellung von Programm-Code erfolgt automa-<br />

tisch unter Verwendung von Code-Generat oren.<br />

In [56] wird die Modellierung eines Sattelzuges und die echtzeitfähi-<br />

ge Modell-Implementierung in dem Werkzeug ASCET-RSF vorgestellt.<br />

Da<strong>mit</strong> werden Untersuchungen zur Koppelkraftregelung <strong>mit</strong>tels elektro-<br />

pneumatischer Nutzfahrzeug-Bremsanlagen durchgeführt. Das Nachfol-<br />

geprodukt ASCET-SD wird z.B. in [57] zur Spezifikation der Steu-<br />

ergeräte-Software, zur Simulation sowie zur prototypischen Fahrzeug-<br />

Implementierung verwendet.<br />

In [14] ~ ird über die Entwicklung einer Schaltstrategie für PKW <strong>mit</strong><br />

Automatisiertem Schaltgetriebe ( ASG) unter Einsatz von SIMULINK<br />

und STATEMATE berichtet.<br />

SIMULINK ist in der Automobilindustrie <strong>mit</strong>tlerweile weit verbreitet.<br />

Aufgrund der Möglichkeiten zur automatischen Erzeugung von C-Code<br />

wird es häufig zur Generierung von Echtzeit,-Simulationsprogrammen<br />

für den Antrieb und die Längsdynamik von Kraftfahrzeugen verwendet.<br />

Beispielsweise wird in [58] ein in SIMULINK implementiertes, modu-<br />

lares Simulationsmodell zur Prädiktion des Kraftstoffverbrauches und<br />

der Fahrleistungen von Hybridantrieben auf der Basis von stationären,<br />

gemessenen Kennfeldern vorgestellt.<br />

Auch für hhrdynamische Berechnungen wird dieses Werkzeug gelegent-<br />

lich eingesetzt, wobei die zugrunde liegenden Simulationsmodelle in der<br />

Regel nur wenige Freiheitsgrade z. B. des Fahrzeugaufbaus unabhängig<br />

voneinander abbilden. Diese Vereinfachung reduziert den numerischen<br />

Berechnungsaufwand erheblich, ist jedoch nur für einfache Anwendun-<br />

gen geeignet.<br />

Ein so beschaffenes Modell für Handling-Untersuchungen und dessen<br />

Implementierung in SIMULINK wird in [59] dargestellt. Ein ähnliches<br />

Simulationsmodell der Fahrdynamik <strong>mit</strong> 18 Freiheitsgraden und des-<br />

sen Anwendung bei der Entwicklung des Regelalgorithmus für ein ak-<br />

tives Fahrwerk beschreibt [60]. In 1611 wird ein adaptives Echtzeit-<br />

Fahrzeugmodell vorgestellt, welches in elektronischen Steuergeräten zur

Be~bacht~ung des Fahrzustands in1 Fahrbetrieb dient.<br />

Ein eclitzeitfähiges Modell des Antriebs und des Fahrverlialtens von<br />

PKW und dessen Anwendung in einem Fahrsimulator bei Untersuchun-<br />

gen zur Konzeption eines Rollover-Warnsystems wird in [62] vorgestellt.<br />

In [63] wird ein weiteres, sehr detailliertes Modell des Antriebs und der<br />

Fahrzeugdynamik beschrieben, das auch die Steuergrößen für das Bewe-<br />

gungssystem eines Fahrsimulators in Echtzeit berechnet.<br />

In [Gd] wird ein Echtzeit-Simulationsprogramm für die Geländefahrt von<br />

Nutzfahrzeugen vorgestellt. Die zugrunde liegenden Modelle, z.B. des<br />

Reifen-Boden-Kontakts sind zum Einsatz bei Fahrsimiilatoren, insbesondere<br />

fiir militärische IArisvendunge~i, konzipiert.<br />

Zur detaillierten XIodellierung des Fahrwerks und der Fahrzeugbe~egung<br />

im dreidimensionalen Raum werden auch bei Echtzeit-Anwendungen<br />

in zunehmendem Maße hlKS-TVerkzeuge eingesetzt. Da der Detaillie-<br />

rungsgrad der Modelle jedoch stets durch die verfügbare Rechenleis-<br />

tung begrenzt ist, war diese Form der Echtzeitsimulatio~i der Fahrdy-<br />

namik zunächst nur auf Parallelrechnern realisierbar. Ein Hardware-in-<br />

the-Loop-Simulator für ABS im Nutzfahrzeug wird in [65] vorgestellt.<br />

Die Bewegungsgleichungen wurden <strong>mit</strong> dem MKS-Gleichungsgenerator<br />

WEWEUL automatisch generiert und manuell auf einem Transputer-<br />

Cluster verteilt.<br />

Die rasche Verbreitung elektronischer Regelungen im Kraftfahrzeug er-<br />

fordert auch bei der Simulation die Koinbination von Steuer- und Regel-<br />

algorit hmen <strong>mit</strong> detaillierten Modellen des Kraftfahrzeugs. Die hierbei<br />

auftretenden, interdisziplinären Rlodellierungsaufgaben legen die Korn-<br />

bination mehrerer Klassen von Software-Werkzeugen nahe.<br />

In [66] wird eine Verknüpfung des YlKS-Verfahrens <strong>mit</strong> Regelalgoritlimen<br />

vorgeschlageii und unter numerischen .4spekten arn Beispiel des Folge-<br />

falirens von Kraftfahrzeugen untersucht. Die Kopplung eines in ADAIMS<br />

realisierten Fahrdynamik-hIodells <strong>mit</strong> einem in SILlULINK impleinen-<br />

tierten .Aiitriebsstrang-Modell wird in [G71 beschrieben und zur Untersu-<br />

chung des Einflusses von Lastwechseln auf das Fahrverhalten eingesetzt.<br />

Eine .Ausführung des Simulationsprogramms in Echtzeit ist <strong>mit</strong> dieser<br />

Kombination aufgrund der Struktur der von .IDA?IIS erzeugten Diffe-<br />

renzialgleichungssysteme jedoch nicht möglich.<br />

Dagegen wird in [68] die <strong>Einbindung</strong> von Simulations-Code, welcher von<br />

einem MKS-Gleichungsgenerator <strong>mit</strong> der Bezeichnung AUTOSIAI er-<br />

zeugt wird. in SIMULINK beschrieben. Die aiif diese \$'eise generierten

Simulationsprogramme sind für Echtzeit-Anwendungen geeignet.<br />

1.2.4 Datenkommunikation im Kraftfahrzeug<br />

Einsatzgebiet<br />

Viele Kraftfahrzeuge des unteren Preissegments enthalten nur wenige<br />

elektronische Steuergeräte, z.B. ein Motor-Steuergerät und ein Airbag-<br />

Steuergerät. Diese arbeiten weitgehend unabhängig voneinander, es be-<br />

steht so<strong>mit</strong> nur geringer Kommunikatiorisbedarf. Die Vernetzung der<br />

Steuergeräte erfolgt hierbei kostengünstig durch elektrische Punkt-zu-<br />

Punkt-Verbindungen.<br />

Neue Fahrzeuge der Oberklasse enthalten bis zu 80 elektronische Steuer-<br />

geräte. Deren gegenseitige Beeinflussung und da<strong>mit</strong> die auszutauschende<br />

Datenmenge nimmt stetig zu. Eine Vernetzung dieser zahlreichen Steuer-<br />

geräte durch Einzelleitungen scheidet aufgrund der Kosten, des Gewichts<br />

und des Bauraum-Bedarfs des Leitungssatzes aus.<br />

Statt dessen wird die Datenübertragung heute zunehmend <strong>mit</strong> digitalen<br />

Kommunikationssystemen realisiert. Hierbei tauschen alle angeschlosse-<br />

nen Teilnehmer Nachrichten auf einer gemeinsamen Datenleitung (Da-<br />

tenbus) aus. Der Zugriff der einzelnen Teilnehmer auf das Busmedium<br />

erfolgt zeitlich versetzt (Zeitmultiplex-Verfahren) . Für den Fall, dass<br />

mehrere Teilnehmer gleichzeitig eine Nachricht senden wollen, enthal-<br />

ten alle in der Fahrzeugtechnik verwendeten Kommunikationprotokolle<br />

Verfahren zur Kollisionsvermeidung.<br />

Der Einsatz von Datenbussen im Kraftfahrzeug bietet weitere Vorteile:<br />

Realisierbarkeit von hierarchischen Steuerungen und Regelungen.<br />

Ein Beispiel ist die Vorgabe des Leerlaufdrehzahl-Sollwerts durch<br />

einen Antriebs-Koordinator. Die eigentliche Drehzahlregelung fin-<br />

det dagegen im (untergeordneten) Motor-Steuergerät statt.<br />

Einfache Erweiterbarkeit einer Fahrzeugbaureihe <strong>mit</strong> zusätzlichen<br />

elektronischen Ausstattungen und<br />

Möglichkeit einer zentralen Diagnose und Wartung für alle<br />

<strong>Elektronik</strong>-Komponenten.<br />

Einige wichtige Verfahren und Protokolle werden in den folgenden Ab-<br />

schnitten kurz vorgestellt.

Frühe Entwicklungen<br />

In der Fi-ühphase der ITernetzung wurden von vielen Firmen pro-<br />

prietäre Bussyst,eme entwickelt und eingesetzt. Bereits 1978 stellte VD 0<br />

unter der Bezeichnung ELSA (Elektrisches Leitungssystem im Auto-<br />

mobil) einen Datenbus zur Lernetzung von Scheiiiwerfern, *41izeige-<br />

Instrumenten usw . vor [69].<br />

Spätere Realisierungen basieren häufig auf dem UA4RT-Protokoll ( Uni-<br />

versal Asynchronous ~eceiver/Transrnitter)'. Mit ISO 9111 wurde 1989<br />

ein Kfz-Bussystem nach dem UART-Prinzip spezifiziert, das in der Dia-<br />

griosetechnik weit verbreitet ist [iO].<br />

LIN<br />

LIN (Local Interconnect Network) wurde 2000 von einer Vereinigung von<br />

Fahrzeug-, Halbleiter- und Software-Herstellern vorgestellt [71]. Das Pro-<br />

tokoll stellt eine Erweiterung des UART-Verfahrens dar. Pro Nachricht<br />

werden 2, 4, oder 8 Byte Nutzdaten <strong>mit</strong> maximal 20 kBit/s übertragen.<br />

Dienste für das Netzwerk- und Energie-Management sind Bestandteil<br />

der Spezifikation. LIN ist zur Vernetzung von kostengünstigen Sensoren.<br />

Aktuatoren und Steuergeräten der Karosserie-<strong>Elektronik</strong> ~orgesehen.<br />

Protokolle <strong>mit</strong> bitweiser Arbitrierung<br />

Aufwändigere Kommunikationsprotokolle beinhalten R4echanisinen zur<br />

kollisionsfreien Zuteilung des Busmediums unter Lrerwendung voll<br />

Nachrichten-Prioritäten. Dieser IJorgang wird als Arbitrierung bezeichnet<br />

[72]. Jede Nachricht beinhaltet eine eindeutige, garizzahlige Kennung<br />

(Identifier) . Diese spezifiziert die Bedeutung und evtl. den Absender sowie<br />

den Empfänger der Nachricht. Die Erkennung von Übertragungsfehlern<br />

erfolgt durch eine Prüfsumme ( CRC=Cyclic Redundancy Check),<br />

die <strong>mit</strong> jeder Nachricht übertragen wird. Auch Verfahren zur Fehlerbehandlung<br />

sind stets vorhanden, z.B. die automatische Wiederholung<br />

einer fehlerhaften Nachricht.<br />

Der bedeutendste Vertret'er dieser Klasse ist CXN (siehe Abschnitt,<br />

1.2.5). Daneben existieren weitere arbitrierende Protokolle:<br />

'Auch bei der ,,seriellen Schnittstelle.' von PCs wird das UXRT-Pririzip verwendet.<br />

39

Tabelle 1.1: Eigenschaften arbitrierender Bussysteme<br />

Eigenschaft<br />

Maximale Daten-<br />

rate (kBit/s)<br />

Bytes pro<br />

Nachricht<br />

Ident ifier-Länge<br />

(Bit)<br />

Verfahren zur<br />

Fehlererkennung<br />

CAN<br />

1000<br />

0 bis 8<br />

11 oder 29<br />

15 Bit CRC<br />

VAN<br />

5-1850<br />

150<br />

0 bis 7<br />

VAN ( Vehicle Area Network) wurde von mehreren französischen Fahr-<br />

zeugherstellern initiiert und 1992 genormt [73]. In [74] wird die<br />

Vernetzung von Karosserie-<strong>Elektronik</strong> im Cztrotn XM beschrie-<br />

ben. VAN wurde inzwischen weitgehend von CAN verdrängt.<br />

5-1850 basiert auf einem Vorschlag von Chrysler und wurde als SAE-<br />

Standard definiert. Das Protokoll wird von Ford unter der Bezeich-<br />

nung SCP (Standard Corproate Protocol) verwendet und bei Gene-<br />

ral hlotors als Class 2 bezeichnet 1751. Voraussichtlich wird 5-1850<br />

<strong>mit</strong>telfristig ebenfalls durch C14N ersetzt<br />

24<br />

8 Bit CRC<br />

Diese Protokolle besitzen ähnliche Eigenschaften wie C4N, sind jedoch<br />

untereinander und zu CAN nicht kompatibel. In Tabelle 1.1 sind wichtige<br />

technische Daten der arbitrierenden Bussysteme zusammengestellt.<br />

Zeitgesteuerte Datenkommunikation<br />

250<br />

0 bis 28<br />

12<br />

15 Bit CRC<br />

CAN und ähnliche Kommunikationsprotokolle bieten eine hohe Zu-<br />

verlässigkeit bei der Sicherstellung der Konsistenz der übertragenen Da-<br />

ten zwischen Sender und Empfänger im Wertebereich, gewährleisten je-<br />

doch nicht die Einhaltung maximaler Antwortzeiten. Diese nehmen <strong>mit</strong><br />

steigender Bus-Belastung zu. Nach (761 ist die Antwortzeit (response<br />

time) definiert als die Zeitspanne zwischen der Seiideanforderung für ei-<br />

ne Nachricht und dem Eintreffen dieser Nachricht bei den Empfängern.

Tabelle 1.2: Eigenschaften zeitgesteuerter Bussysteme<br />

Eigenschaft<br />

h/f aximale<br />

Datenrate<br />

(lIBit/s)<br />

Bytes pro<br />

Nachricht<br />

TTP<br />

5<br />

0 bis 16<br />

Byteflight<br />

FlexRay<br />

> 5<br />

0 bis 246<br />

Für sicherheitsrele~ante Kfz-Anwendungen2 ergeben sich ziisätzliclie An-<br />

forderungen an die Datcnkornmunikation:<br />

10<br />

0 bis 12<br />

TTCAN<br />

Die Ailtwortzeiten müssen bereits bei der Netzwerk-Auslegung vor-<br />

hersagbar sein. Die Er<strong>mit</strong>tlung der maximalen Ausführungszeit<br />

von Software, die <strong>mit</strong> Hilfe modellbasierter Methoden erstellt wird,<br />

ist Gegenstand von [77].<br />

Der Verzicht auf mechanische Rückfallebenen erfordert redunda>nte<br />

Datenkommunikation <strong>mit</strong> Fehlerkorrektur zur Xufrechterhaltung<br />

der Datenübertragung bei Ausfall einzelner Komponenten.<br />

Das deterministische Zeitverhalten wird erreicht, indem für jede Nach-<br />

richt vorab die Sendezeitpunkte festgelegt werden. Dies erfordert eine<br />

konsistente Zeitinforniation bei allen Teilnehmern. Alle Protokolle bein-<br />

halten deshalb Verfahren zur Synchronisation der lokalen Zeitgeber über<br />

das Netzwerk.<br />

1<br />

0 bis 8<br />

llehrere Protokolle befinden sich in der Entwicklung oder Erprobung.<br />

Tabelle 1.2 enthalt eiriige technische Daten.<br />

TTP/C (Tzme Triggered Protocol Class C) wurde 1994 von der TU<br />

Wien vorgestellt [78]. Die Buszuteilung erfolgt zyklisch nach ei-<br />

nem Zeitscheiben-Verfahren ( TDMA= Time Division filtiple Ac-<br />

cess) <strong>mit</strong> festen Zeitfenstern, die unterschiedliche Längen aufwei-<br />

sen können. Dadurch wird eine exaktle Einhaltung der vorgege-<br />

benen Kommunikations-Zeitpunkte sichergestellt. Maßnahmen zur<br />

%.B. zukünftige elektromechanische Bremsen ohrie hj-draulische bzw. pneumatische<br />

Rückfallebene.

Fehlererkennung und zur redundanten Datenübertragung sind Be-<br />

standteil des Protokolls. Eine Untersuchung zur Eignung von TTP<br />

für Brake-by-Wire-Anwendungen wird in [79] durchgeführt. In [80]<br />

wird die automatische Generierung von Steuergeräte-Code für ver-<br />

teilte Regelungen unter Einsatz von TTP diskutiert. In Serienfahr-<br />

zeugen wird TTP bisher nicht eingesetzt.<br />

Byteflight wurde im Jahr 2000 von BMW vorgestellt [81]. Ein Master-<br />

Knoten, dessen Funktion im Fehlerfall von einem anderen Knoten<br />

übernommen wird, gibt Zykluszeiten vor. Innerhalb dieser Zyklen<br />

konstanter Dauer erfolgt die Buszuteilung nach einem modifizier-<br />

ten TDhlA-Verfahren. Für eine begrenzte Zahl von Nachrichten<br />

wird eine maximale Antwortzeit garantiert. Die eventuell verblei-<br />

bende Zeit bis zum Beginn des nächsten Zyklus kann für nieder-<br />

priore Nachrichten genutzt werden. 2001 erfolgte der erste Seri-<br />

eneinsatz zur Vernetzung von Airbags (821.<br />

FlexRay wurde von BhfW und DaimlerChrysler im Jahr 2000 als Spe-<br />

zifikation vorgestellt [83]. Jeder Übertragungszyklus gliedert sich in<br />

zwei Teile. In einen statischen Teil werden hochpriore Nachrichten<br />

<strong>mit</strong> TDMA-Buszuteilung übertragen, vergleichbar <strong>mit</strong> TTP/C. Im<br />

dynamischen Teil werden niederpriore Nachrichten wie bei Byte-<br />

flight gesendet. Vorgesehen ist eine sternförmige Topologie unter<br />

Verwendung optischer Busmedien <strong>mit</strong> wahlweise einkanaliger oder<br />

redundanter Anbindung der einzelnen Knoten.<br />

TTCAN (Time Triggered CAN) wurde im Jahr 2000 von der Robert<br />

Bosch GmbH vorgestellt [84] und zur Normung nach ISO 11898-4<br />

eingereicht. Dem bestehenden CAN-Protokoll wird eine Zeitsteue-<br />

rung <strong>mit</strong> Uhrensynchronisation überlagert. Jeder Kommunikati-<br />

onszyklus besteht aus mehreren TDMA-Runden <strong>mit</strong> identischer<br />

Aufteilung der Zeitfenster, innerhalb denen unterschiedliche CAN-<br />

Nachrichten übertragen werden. Jedes Fenster kann entweder für<br />

hochpriore Nachrichten reserviert oder zur prioritätsgesteuerten<br />

Übertragung niederpriorer Nachrichten freigegeben werden. Ein<br />

Master-Knoten, dessen Funktion im Fehlerfall von einem anderen<br />

Knoten übernommeri wird, initiiert den Beginn jedes Kommunika-<br />

tionszyklus. Alle weiteren Eigenschaften entsprechen dem bisheri-<br />

gen CAN-Standard. In Serienfahrzeugen wird TTCAN bisher nicht<br />

eingesetzt.

1.2.5 Das CAN-Protokoll<br />

Grundlagen<br />

Das CAN-Protokoll (Controller Area Network) wurde ab 1983 von der<br />

Robert Bosch GnibH in Zusammenarbeit <strong>mit</strong> dem Halbleiterhersteller<br />

Intel entwickelt und 1992 standardisiert [85]. CAN ist für den Einsatz in<br />

Fahrzeugen konzipiert, wird aber auch in der iridustriellen Automatisie-<br />

rungstechnik als Feldbussystem eingesetzt.<br />

Als erstes Serienfahrzeug wurde 1991 die S-Klasse von hiercedes-Benz<br />

rnit drei CAN-Bussen für Antriebsstrang, Klimaregelung und -1udio-<br />

System ausgestattet [86]. Seitdem wurde das Protokoll von zahlreichen<br />

Fahrzeugherstellern übernornnien und stellt in Europa einen de-facto-<br />

Standard dar.<br />

Eine umfassende Darstellung findet sich in [72]. Die wichtigsten Eigen-<br />

schaften werden kurz zusammengefasst:<br />

CAN ist ein nachrichtenorientiertes Protokoll. Jede Nachricht ist<br />

durch eine Kennzahl (ID= Identifier) eindeutig gekennzeichnet und<br />

darf nur von einem Teilnehmer gesendet werden. Der Empfänger<br />

der Nachricht wird nicht spezifiziert. Alle am Bus angeschlossenen<br />

Teilnehmer entscheiden aufgrund des ID, ob die jeweilige Nach-<br />

richt für sie relevant ist. Der ID umfasst in der ursprünglichen<br />

lTersion 11 Bit, alternativ wird ein 29 Bit-ID verwendet. Xeuere<br />

C AN-Controller unterstützen beide Formate und deren gemischte<br />

Verwendung in einem Netzwerk.<br />

CAN gehört zu den Multi-Master-Protokollen. Es gibt keinen expli-<br />

ziten Busmaster, der den Zugriff auf das Busmediuni steuert. Die<br />

Buszuteilurig erfolgt durch kollisionsfreie, bitweise Arbitrierung un-<br />

ter Verwendung von Prioritäten. Die Priorität einer Nachricht wird<br />

durch die Vergabe des ID festgelegt. Je kleiner der ID, um so höher<br />

ist die Priorität.<br />

Jede Nachricht ent,hält null bis acht Datenbytes, deren Bedeutung<br />

und Inhalt auf Anwendungsebene festgelegt wird. Mit jeder Nachricht<br />

wird eine 15-Bit-Prüfsumme (CRC) übertragen. Dadurch<br />

werden Übertragungsfehler rnit hoher \ahrscheinlichkeit erkannt<br />

und durch alle Empfänger <strong>mit</strong>tels eines Error Frame sigrialisiert.<br />

Die betreffende Nachriclit wird daraufhin .~viederholt. Durch cberwachurig<br />

der phj-sikalischeri Buspegel sowie die Zahliing von S~nde-

und Empfangsfehlern bewertet jeder Teilnehmer seine eigene Funk-<br />

tionstüchtigkeit und schaltet gegebenenfalls in einen passiven Feh-<br />

lerzustand, um eine Blockierung des Netzwerks zu verhindern.<br />

Die Datenübertragung erfolgt bitseriell und asynchron, also oh-<br />

ne zusätzliches Taktsignal. Ein als Bit-Stufing bezeichnetes Ver-<br />

fahren ermöglicht die Rückgewinnung des Bit-Taktes und da<strong>mit</strong><br />

die Nachsynchronisat,ion der Empfänger bei laufender Übertra-<br />

gung. Dadurch können 8bweichungen von der spezifizierten Baud-<br />

rate kompensiert werden, die durch Temperatureinflüsse, Bauteil-<br />

Toleranzen oder Alterung auftreten.<br />

Auf dem Markt ist eine große Zahl preiswerter CAN-Protokoll-<br />

Controller verfügbar, in denen alle Funktionen zur Datenübertra-<br />

gung implementiert sind. Zudem sind verschiedene Microcontroller<br />

<strong>mit</strong> integriertem CAN-Controller verfügbar. Die Ankopplung an<br />

das jeweilige physikalische Busmedium erfolgt durch einen CAN-<br />

Transceiver.<br />

Das Busmedium wird meist als verdrillte elektrische Zweidraht-<br />

leitung ( Twisted Pair) ausgeführt. Die Übertragung erfolgt <strong>mit</strong>-<br />

tels elektrischer Differenzpegel. Dadurch wird ein hoher Störab-<br />

stand bei elektromagnetischen Einstrahlungen und Potenzialdif-<br />

ferenzen erreicht, die im Kraftfahrzeug häufig auftreten. Bei feh-<br />

lertoleranten Ausführungen wird die Datenübertragung über ei-<br />

ne Busleitung und das Massepotenzial <strong>mit</strong> verminderte~n Störab-<br />

stand aufrecht erhalten, falls die Unterbrechnung oder der Kurz-<br />

schluss einer Busleitung eintritt. Infolge der bitweisen Arbitrierung<br />

muss die maximale Signal-Laufzeit auf dem Medium im gesamten<br />

CAN-Netzwerk kleiner als eine Bitzeit sein. Die maximal zulässige<br />

Brutto-Datenrate beträgt 1000 kBit/s.<br />

CAN im Kraftfahrzeug<br />

Typische CAN-Netzwerke in Kraftfahrzeugen umfassen drei bis zehn<br />

Steuergeräte im Antriebsstrang und bis zu 64 Teilnehmer im Karosserie-<br />

und Innenraumbereich. Im Folgenden werden die Eigenschaften und<br />

Einsatzgebiete verbreiteter CAN-Implementierungen in Stichworten be-<br />

schrieben.

Diese unterscheiden sich z .B. bezüglich Datenrate, verwendetem Busme-<br />

dium und der Definition von An~vendungs-Diensten. Alle anderen Eigen-<br />

schaften, sind einheitlich nach ISO 11898 definiert.<br />

High-Speed-CAN (ISO 11898-2) : Standardisierung des Verfahrens<br />

zur Datenübertragung (Buszugriff, Fehlererkennung und Fehlerbe-<br />

handlung, Nachrichtencodierung) und des physikalischen Busrnedi-<br />

ums. Verwendung in der Antriebs- und Fahrwerks-<strong>Elektronik</strong> bei<br />

PKW und Nutzfahrzeugen. Baudrate: 125-1000 kBit /s, üblich sind<br />

250 und 500 kBit/s. Differenzielle Buspegel (+/- 5 V).<br />

High-Speed-CAN (SAE J- 1939) : Industriestandard für Kut zfahr-<br />

zeuge als Erweiterung zu ISO 11898-2. Dcfiiiition von Nachrich-<br />

teninhalten sowie Diensten, z.B. Netzwerk-hlanagement und Dia-<br />

gnose. 29 Bit IDs. Baudrate: 250 kBit/s [87, 881.<br />

Low-Speed-CAN (ISO 115 19- 1) : lTernetzung von Karosserie- und<br />

Innenraum-<strong>Elektronik</strong> im PKW. Fehlertolerante Auslegung<br />

(Eindraht-Betrieb möglich). Baudrate: bis 125 kBit/s. Wird häufig<br />

in Verbindung <strong>mit</strong> Netzwerk- und Energie-Management auf An-<br />

wendungsebene eingesetzt, z.B. OSEK-NM [89].<br />

Low-Speed-CAN (ISO 11992) : Kommunikation zwischen Zugma-<br />

schine und Anhänger, insbesondere zur Koordination der<br />

Bremskraft-lTerteilung bei schweren Nutzfahrzeugen [90]. Fehlerto-<br />

lerante Auslegung (Eindraht-Betrieb möglich). Baudrate: bis 125<br />

kBit/s. Differenzielle Buspegel (+/- 18 V).<br />

Single Wire CAN (SAE 5-2411): ljernetzung von Karosserie- und<br />

Innenraum-<strong>Elektronik</strong> in amerikanischen PKIJT [91]. Energie- und<br />

Netzwerk-Management verfügbar. Busmedium ist als Eindraht-<br />

Leitung ausgeführt. I\iaximale Baudrate: 33 kBit /s.<br />

1.3 Aufgabenstellung<br />

Dem Autor ist keine wissenschaftliche Arbeit bekannt. in der die<br />

vollständig automatische Erzeugung von Echtzeit-Simulationsprogram-<br />

men für Fahrsimulatoren unter Einsatz von gekoppelten Software-<br />

T'iTerkzeugen <strong>mit</strong> Code-Generatoren untersucht und durchgeführt wird.

Auch das in dieser Arbeit vorgestellte Aufbauprinzip für interaktive<br />

Schulungs-Fahrsimulatoren wird bisher nicht beschrieben. Hierbei wer-<br />

den reale, CAN-vernetzte Kfz-Steuergeräte und andere Fahrzeugkompo-<br />

nenenten nach dem Hardware-in-the-Loop-Verfahren in den Fahrsimula-<br />

tor integriert, um ein realitätsnahes Verhalten der Anlage bei v-ertretba-<br />

rem Aufwand zu gewährleisten.<br />

Ziel der vorliegenden Arbeit ist die Herleitung einer neuen Verfah-<br />

rensweise zur schnellen und zuverlässigen Realisierung von echtzeitfähi-<br />

gen Simulationsmodellen für Fahrsimulator- und Hardware-in-the-Loop-<br />

Anwendungen. Dabei wird eine Vereinheitlichung der Modellansätze für<br />

Echtzeit- und Nicht-Echtzeit-Anwendungen angestrebt. um den Auf-<br />

wand zur Erstellung und Pflege unterschiedlicher Modell-Bibliotheken<br />

zu vermeiden.<br />

Um die aufwändige manuelle Implementierung von Sirnulationsprogram-<br />

men zu umgehen, wird untersucht', welche Software-Werkzeuge <strong>mit</strong> der<br />

Möglichkeit zur automatischen Generierung von Programm-Code hierfür<br />

in geeigneter Kombination einset zbar sind. Hierbei wird eine vollständige<br />

Portabilität des generierten Programm-Codes gefordert, d.h. der Quell-<br />

Code soll ohne Änderungen für unterschiedliche Rechnertypen und Be-<br />

triebssysteme compilierbar sein.<br />

Am Beispiel des CAN-Protokolls wird dargelegt, wie der Funktionsurn-<br />

fang elektronischer Steuerungen im Kraftfahrzeug und deren Datenkom-<br />

munikation in die Simulation einbezogen werden kann.<br />

Die hergeleiteten Verfahren werden bei der Entwicklung von Fahrsimu-<br />

latoren eingesetzt und erprobt. Als konkrete Anwendungsfälle dienen<br />

die Ausbildung von LKW-Fahrern im Umgang <strong>mit</strong> dem elektronischen<br />

Antriebsmanagement schwerer Nutzfahrzeuge sowie die Simulation der<br />

Fahrdynamik von Nutzfahrzeug-Zügen im Laborbetrieb.<br />

Die eigentliche h~lodellbildung für elektrische, mechanische, hydraulische<br />

und pneumatische Kraftfahrzeug-Teilsysteme steht nicht im Mittelpunkt<br />

dieser Arbeit. Soweit verfügbar, werden bekannte Modellansätze an die<br />

besonderen Anforderungen der Echtzeit-Fahrsimulation angepasst.<br />

1.4 Inhalt und Aufbau der Arbeit<br />

Kapitel 2 gibt eine Übersicht zu den Aufgabenstellungen in der Echt-<br />

zeitsimulation. Es wird eine Verfahrensweise zur Erstellung echtzeitfähi-

ger Siinulationsmodelle beschrieben, welche auf dein kornbinierteii Ein-<br />

satz mehrerer Klassen von Software-Werkzeugen basiert. Komrrierziell<br />

verfügbare TVerkzeuge werden im Hinblick auf ihre Eignung bewertet<br />

und ausgewählt. Ein Verfahren zur Kopplung dieser IVerkzeuge durcli<br />

Aust auscl-i von Programm-Code wird erarbeitet.<br />

Kapitel 3 befasst sich <strong>mit</strong> der Abbildung der IVechselwirkungen zwi-<br />

schen mechanischen und elektronischen Fahrzeug-Komponente11 in der<br />

Simulation. Der Fahrer und die Fahrzeug-Umgebung werden in die<br />

Betrachtungen einbezogen. Am Beispiel des CAN-Protokolls wird un-<br />

tersucht, wie elektronische Steuergeräte und Netzwerke in Echtzeit-<br />

Simulationsanwendungen eingebunden werden können. Insbesondere<br />

werden verschiedene Erweiterungen des „klassischen" Hardware-in-the-<br />

Loop-I'erfahrens beschrieben. Eiri Softm-are-TYerkzeug zur automatischen<br />

Ge~lerierung von Programm-Code für CAK-.In~riungen wird vorge-<br />

stellt.<br />

Kapitel 4 beschreibt als Anwendungsbeispiel einen Fahrsimulator, der<br />

zur Schulung von LKW-Fahrern im Umgang <strong>mit</strong> dem Automatisierten<br />

Schaltgetriebe eingesetzt wird. Der Fahrsimulator wird unter Verwen-<br />

dung mehrerer realer Antriebskomponenten und elektronischer Steuer-<br />

geräte <strong>mit</strong> CAN-Vernetzung aufgebaut.<br />

Gegenstand von Kapitel 5 ist die Erweiterung des llodellansatzes aus<br />

Kapitel 4 zur Untersuchung der Fahrdynamik schwerer Nutzfahrzeuge.<br />

Unter Lerwendung der Software-IYerkzeuge SIAIPACK und SIMU-<br />

LINK wird das hlehrkörpermodell für einen Gliederzug erstellt. IJerschiedene<br />

hlodellierungsaspekte werden aus der Sicht der Echtzeit-<br />

Fahrsimulation detalliert behandelt, insbesondere die durchgängige Formulierung<br />

von hlodellgleichungen für die Teilsysteme Rad-Bremse.<br />

Reifen-Fahrbahn und Lenkung. Das Simulatio~ismodell wird auf einen1<br />

Labor-Fahrsimulator <strong>mit</strong> Lenkmornent-Rückwirkung implementiert, wobei<br />

ein PC als Echtzeitrechner Verwendung findet. Des Weiteren wird ein<br />

neues \erfahren zur Generierung realistischer Fahrzeuggeräusche rorgrstellt.<br />

Kapitel 6 enthalt eine Schlussbemerkung und einen kurzen Ausblick.

2 Methoden und Werkzeuge<br />

In diesem Kapitel wird ein Verfahren zur Erstellung von Echtzeit-<br />

Sirnulationsmodellen für Kraftfahrzeuge unter Verwendung moderner<br />

Software-l+Terkzeuge erarbeitet.<br />

Zunächst erfolgt eine Definition des Begriffes Echtzeitsimulation. IVich-<br />

tige Anwendungen in der Kr aftfahrzeugtechnik werden vorgestellt. Die<br />

Eigenschaften von Fahrsimulatoren werden dargelegt.<br />

Ein wesentlicher Bestandteil von Fahrsimulatoren (und a,nderer Echtzeit-<br />

Simulationsanlagen) ist ein Simulationsprogramm, welches das dynami-<br />

sche Verhalten eines Kraftfahrzeugs auf einem digitalen Rechner nach-<br />

bildet. Die besonderen Anforderungen an solche Programme werden dis-<br />

kutiert. Anschließend wird ein Weg zur automatischen Erzeugung sol-<br />

cher Rechnerprogramme hergeleitet, der diesen Anforderungen Rech-<br />

nung trägt. Ein wesentliches Merkmal des beschrittenen Weges ist die<br />

kombinierte Verwendung mehrerer Software- Werkzeuge <strong>mit</strong> grafischer<br />

Modellbeschreibung und automatischer Code-Generierung. Aus der Viel-<br />

zahl der am Markt verfügbaren Produkte werden anhand mehrerer Kri-<br />

terien einige geeignete Werkzeuge ausgewählt. Das Vorgehen zur Korn-<br />

bination dieser lFrerkzeuge wird vorgestellt,.<br />

Diese Ausführungen bilden die Grundlage für die in den weiteren Kapi-<br />

teln vorgestellten Anwendungen.<br />

2.1 Definition der Echtzeitsimulation<br />

Echtzeitbetrieb liegt nach DIN 44300 [92] vor, wenn die Verarbeitungs-<br />

ergebnisse eines technischen Systems innerhalb einer vorgegebenen Zeit-<br />

spanne ti. verfügbar sind1. Neben dieser eindeutigen Definition haben<br />

sich die Begriffe harte und weiche Echtzeitsimulation [93] sowie Ofiline-<br />

Simulation etabliert, die häufig zu Verwirrung führen. Eine Abgrenzung<br />

wird anhand von Bild 2.1 vorgenommen.<br />

'DIN 44300 wurde <strong>mit</strong>tlerweile zugunsten der iriternationalen Norm ISO-DIS 2382<br />

zurück gezogen.

)<br />

Abbruch<br />

0 1 2 3 tlh 4<br />

F----:<br />

I I I I P<br />

0 1 2 3 tlh 4<br />

Bild 2.1: Zur Definition der Echtzeitsimulation<br />

Auf der Abszisse ist jeweils die real verstrichene Zeit t seit dem Beginn<br />

der Simulation, bezogen auf die konstante Simulations-Schrit tweite h,<br />

aufgetragen. Jedes Rechteck symbolisiert einen Simulationsschritt <strong>mit</strong><br />

der bezogenen Verarbeitungszeit<br />

Für deterministisches (hartes) Echtzeitverhalten nach Bild 2.1 a) muss<br />

die \rerarbeitungszeit in jedem Schritt kürzer sein als die Schrittn-rite,<br />

G1. 2.2 wird als Rechtzeitigkeits-Forderung bezeichnet [94]. In Bild 2.1 a)<br />

wird diese Forderung wegen 71 > 1 verletzt, die Simulation wird dadurch<br />

ungültig und ist abzubrechen. In dieser Arbeit bezieht sich der Begriff<br />

Echtzeitsimulation stets auf diese strikte Definition.<br />

Bei weicher Echtzeit2, wird GI. 2.2 durch eine weniger restriktive Bedin-<br />

gung ersetzt:<br />

n<br />

'hfit diesem Attribut werden manche Software-Produkte gekennzeichnet, die unter<br />

nicht echtzeitfähigen Betriebssystemen wie Wzndows ausgeführt werden, aber iri<br />

den meisten Fällen akzeptables Zeitverhalten aiifweisen.<br />

49

Zeitüberschreitungen sind zulässig. sofern sie in den folgenden Zeitschritten<br />

wieder aufgeholt werden, wie in Bild 2.1 b) angedeutet. Das Zeitverhalten<br />

der Simulation ist nicht deterministisch. Die Anzahl (n - rn + I)<br />

der zur Mittelung herangezogenen Zeitschritte bestimmt den ,,Grad der<br />

Echtzeitfähigkeit". Für die Sim~la~tion der Fahrdyna~nik und des Antriebsstranges<br />

ist dieses Verfahren ungeeignet. Es wird in dieser Arbeit<br />

nicht betrachtet.<br />

Bild 2.1 C) enthält ein Beispiel für die Ofline-Simulation. Forderungen<br />

nach G1. 2.2 oder G1. 2.3 bestehen nicht, d.h. die Verarbeitungszeit ist<br />

unabhängig von der realen Zeit t. Meist gilt ri >> 1, vor allem bei kom-<br />

plexen Simulationsverfahren wie FEPl (Finite-Elemente-Methode). Im<br />

Folgenden wird dieses Zeitverhalten als Nicht-Echtzeit-Simulation be-<br />

zeichnet.<br />

2.1.1 Anwendungen in der Fahrzeugtechnik<br />

+<br />

W),<br />

Regler Regelstrecke<br />

teuer-<br />

gerät<br />

GO),<br />

Aktuatoren<br />

Aggregat<br />

(Mechanik,<br />

Hydraulik, etc.)<br />

Sensoren -<br />

Bild 2.2: Regelkreis für ein elektronisch geregeltes Kfz-Teil~yst~em<br />

Echtzeitsimulation ist erforderlich, wenn reale technische Komponenten<br />

<strong>mit</strong> eigenem, nicht beeinflussbarem Zeitverhalten oder der Mensch Be-<br />

standteil des Simulationsaufbaus sind.<br />

In Bild 2.2 ist das Blockschalt bild eines einzelnen, elektronisch geregelten<br />

Kfz-Systems dargestellt. Das Steuergerät gibt die elektrischen Signale gR<br />

zur Betätigung der Aktuatoren aus. Der Betriebszustand des zugeord-<br />

neten Aggregats wird von Sensoren erfasst und als Signalvektor F' in das<br />

Steuergerät zurückgeführt.<br />

Abhängig davon, ob das Steuergerät und die Regelstrecke real vorhan-<br />

den sind oder siniuliert werden, werden die Verfahren gemäß Bild 2.3<br />

a) unterschieden. Lediglich das Software-in-the-Loop-Verfahren (SIL)

a)<br />

I Reales System I Control Prototyping (CP) I<br />

I<br />

gerät<br />

Strecke<br />

- Erprobung des Gesamt-<br />

systems im Fahrversuch<br />

Hardware-in-the-Loop (HIL)<br />

Strecken-<br />

:----_------------n<br />

- Erprobung elektronischer<br />

Steuergeräte im Labor<br />

Reales Fahrzeug<br />

Fahrer Fahrzeug<br />

1 I<br />

- Fahrversuch<br />

- Prüfstandsversuch,<br />

z.B. Verbrauchsmessung<br />

Fahrer<br />

Fahrsimulator<br />

.-----..------------<br />

- Unters. des Fahrerverhaltens<br />

- Schulung, Demonstration,<br />

z.B. Fahrerassistenzsysteme<br />

4 h<br />

rj<br />

: Steuergeräte-.<br />

Strecke<br />

Prototyp<br />

I------------------___I<br />

- Erprobung von Steuergerate-<br />

Software im Fahrversuch<br />

oder am Prüfstand<br />

( Software-in-the-Loop (SIL) 1<br />

fl<br />

r--'-------------'- ----------------<br />

7<br />

I I I<br />

M i Strecken- :<br />

b:<br />

.-----------------J<br />

i h m u s L--------------- mode<br />

- Reglerentwurf in der<br />

Nicht-Echtzeit-Simulation<br />

I Fahrzeug <strong>mit</strong> Fahrmaschine<br />

-----------------<br />

! maschine ,<br />

!.--,--,----------I<br />

- Open-Loop-Fahrmanöver<br />

z.B. Len kwinkelvorgabe<br />

<strong>mit</strong>tels Lenkmaschine<br />

I Nicht-Echtzeit-Fahrsimulation<br />

: Fahrer- : Fahrzeug- i<br />

? modell modell h<br />

- Simulation von Closed-Loop.<br />

Manövern, z. B. Spurwechsel<br />

Verbrauchsberechnung<br />

Bild 2.3: Einteilung der Test- und Simulatioiisverfahren bezüglich<br />

a) der Repräsentation von Steuergerät und Regelstrecl

kann <strong>mit</strong>tels Nicht-Echtzeit-Simulation durchgeführt werden. Hardware-<br />

in-the-Loop (HIL) und Control Prototyping (CP) erfordern Echtzeitver-<br />

halten. Diese Verfahren werden in Kapitel 3 näher betrachet.<br />

Eine weitere Einteilung erfolgt gemäß Bild 2.3 b) bezüglich des Kriteri-<br />

ums, ob Fahrer und Fahrzeug real vorhanden sind oder simuliert werden.<br />

Bei den Verfahren Fahrsimulator und Fahrzeug <strong>mit</strong> Fahrmaschine ist<br />

Echt zeitverhalten erforderlich.<br />

2.1.2 Fahrsimulatoren<br />

Der Einsatz von Fahrsimulatoren nimmt stetig zu. In der Fahrzeugent-<br />

wicklung werden <strong>mit</strong> solchen Anlagen neue Technologie11 interaktiv un-<br />

tersucht, noch bevor ein entsprechend ausgerüsteter F'ahrzeugprototyp<br />

zur LTerfügung steht [13]. Im Gegensatz zur SIL- und HIL-Simulation<br />

steht nicht die technische Erprobung von Software-Funktionen oder Steu-<br />

ergeräten anhand reproduzierbarer Betriebszyklen im hlittelpunkt, son-<br />

dern deren subjektive Bewertung durch Menschen.<br />

Fahrsimulatoren werden auch zur Ausbildung von PKW- und LKW-<br />

Fahrern eingesetzt. Typische Anwendungen sind die Fahrzeugbeherr-<br />

schung in Grenzbereichen, die Senkung des Kraftstoffverbrauchs und der<br />

Umgang <strong>mit</strong> Fahrerassistenzsystemen.<br />

-+<br />

MMI<br />

Rückmelde-<br />

teil<br />

-,<br />

Fahrer<br />

-+<br />

MMI<br />

Eingabe-<br />

teil<br />

r-------------------<br />

1 1<br />

j Fahrzeug- i<br />

I<br />

i modelt,<br />

7,<br />

Umgebungs '<br />

j modell<br />

L--------------------i<br />

Bild 2.4: Prinzipieller Aufbau eines Fahrsimulators<br />

Der Mensch (im Folgenden als Fahrer bezeichnet) wird gemäß Bild 2.4 in<br />

den Simulationskreis eingebunden. Hierzu wird eine Mensch-Ljiaschine-<br />

Schnittstelle (MMI= Man-Machine Interface) benötigt, die aus zwei Tei-<br />

len besteht:<br />

Eingabeteil: Der Fahrer steuert die Simulation über Bedienelemente.<br />

Bei einfachen Aufbauten werden grafische Elemente (z.B. Schal-<br />

ter und Schieberegler) auf einem Bildschirm dargestellt und <strong>mit</strong>-

tels Maus oder Tastatur betätigt. Dieses Konzept ist realitätsfern.<br />

da die Bedienung sequenziell erfolgt. Die Resultate der Simulatiori<br />

sind wenig aussagekräftig. Aufwändigere Fahrsimulatoren stellen<br />

einen ergonomischen Fahrerplatz <strong>mit</strong> realen Bedienelenienten wie<br />

Lenkrad und Pedalerie zur Verfügung (siehe Abschnitt 4.1.1).<br />

Rückmeldeteil: Der Fahrer erhält Informationen über den Betriebs-<br />

zustand des si~nulierten F'ahrzeugs . Bei einfachen Realisierungen<br />

werden Instrumente, Lampen, usw. auf einem Bildschirm darge-<br />

stellt. Verbesserte Ausfiihrungen stellen realitätsnahe Rückmel-<br />

dungen zur Verfügung:<br />

Optisch: Anzeigen auf einem realen Kombiinstrument, dreidi-<br />

riiensionale Visualisieru~ig<br />

der Fahrzeugumgebung.<br />

Akustisch: Generierung dynamischer Fahrzeug- und Umgebungs-<br />

gerausche, z.B. des Motorgerausches (siehe Abschnitt 5.8).<br />

Haptisch: Erzeugung von Rückstellkräften am Lenkrad und an<br />

der Pedalerie (siehe Abschnitt 5.7.2), Erzeugung der vom<br />

Fahrer wahrgenommenen Beschleunigungen durch eine Bewe-<br />

gungsplattform [4].<br />

Bei der Entwicklung eines Fahrsimulators bestehen besondere Anforde-<br />

rungen an das verwendete Echtzeit-Fahrzeugmodell:<br />

Vollständigkeit: Das Modell muss alle denkbaren Betriebszustände<br />

des Fahrzeugs und seiner Teilkomponenten abdecken. Hierbei sind<br />

stetige Übergänge zwischen allen Zuständen erforderlich. Insbeson-<br />

dere dürfen Übergänge zwischen verschiedenen Bewegungsrichtun-<br />

gen und dem Stillst arid von hlodellkomponenten weder zu Inkon-<br />

sistenz noch zu numerischer Instabilität führen. Tabelle 2.1 enthält<br />

einige kritische Beispiele, die in dieser Arbeit untersucht werden.<br />

Plausibilität: Ein Fahrsimulator muss auf alle denkbaren Benutzerein-<br />

gaben, also auch auf Fehlbedienungen3, stets plausibel reagieren,<br />

d.h. das Simulationsergebnis muss qualitativ <strong>mit</strong> den Erfahrungs-<br />

werten des Benutzers übereinstimmen. Dagegen ist die absolute<br />

Genauigkeit der Berechnung für viele Anwendungen von unterge-<br />

ordneter Bedeutung, 2.13. bei der Schulung.<br />

3Häufige Fehlbedienungen bei dem in Kapitel -2 beschriebenen Fahrsimulator sirid<br />

das Ausschalten der Zündung bei voller Fahrt und das Abstellen des Fahrzeugs<br />

an einer Steigung ohne Betätigung der Feststellbremse.

Tabelle 2.1: Beispiele für zustandsbehaftete Modellkomponenten in der<br />

Fahr zeugsimulation<br />

Komponente I Zustände I Abschnitt<br />

Verbrennungsmotor Stillstand<br />

Startvorgang<br />

Leerlaufregelung<br />

hlomentenvorgabe<br />

Kupplung<br />

Haften<br />

Gleiten<br />

( geöffneter Zustand<br />

4.4.3<br />

Fa'hrzeug-<br />

Fahrzeugstillst and<br />

Längsdynamik Vorwärtsfahrt<br />

Rückwärtsfahrt<br />

Reifen-Fahr bahn- Stillstand<br />

5.3<br />

Kontakt<br />

Abrollen<br />

Längsschlupf<br />

kombinierter Schlupf<br />

I gleitender Zustand I I<br />

I Raddrehung, Stillstand/Blockierung<br />

, Radbremse Vorwärtsdrehung,<br />

I I Rückwärtsdrehung<br />

2.2 Erstellung echtzeitfahiger Modelle<br />

2.2.1 Grundlegende Anforderungen<br />

5.4.2<br />

Zunächst werden einige Forderungen an den Prozess zur Erstellung und<br />

Implementierung von Simulationssystemen aufgestellt, die im weiteren<br />

Verlauf dieser Arbeit umgesetzt werden:<br />

Durchgängigkeit: Alle erstellten Simulationsmodelle müssen ohne<br />

Änderungen für die Echt zeit- und die Nicht-Echt zeit-Simulat ion<br />

verwendbar sein, um den Aufwand zur Erstellung und Pflege par-<br />

alleler Modell-Bibliotheken zu vermeiden.<br />

Modularität: Gefordert wird die Wiederverwendbarkeit von Teilmo-

dellen. Simulierte Teile und reale Komponenten sollen <strong>mit</strong> gerin-<br />

gem Aufwand austauschbar sein. Dies betrifft sowohl mechanische<br />

Anteile (Aggregate) und die <strong>Elektronik</strong> (Steuergeräte) als auch den<br />

Fahrer. Hierzu ist eine sinnvolle Strukturierurig der Liodelle und<br />

die Definition einlrieit licher Schnitt stellen erforderlich.<br />

Werkzeugeinsatz und Code-Generierung: Die manuelle Imple-<br />

mentierung von Modellgleichungen in einer Prograrnniiersprache<br />

ist aufgrund des hohen Zeitaufwands zu vermeiden. Statt dessen<br />

werden zeitgemäße Software-Werkzeuge <strong>mit</strong> automatisclier Gene-<br />

rierung von Programm-Code eingesetzt.<br />

Portabilität: Der generierte Code rnuss so beschaffen sein, dass er<br />

auf i~nterscliiedlichen Echtzeit-Rechnertj-pc'n lind Betriebssyste-<br />

rneri ablauffähig ist. Für diese Arbeit wird eine Beschränkung<br />

auf Einprozessor-Rechner vorgenommen, da Parallelrechner-<br />

Anwendungen meist nur <strong>mit</strong> hohem Aufwand portierbar sind.<br />

Einsatz von Standard-Hardware: Aus wirtschaftlichen Gründen<br />

wird gefordert, dass die Ausführung der erstellten Echtzeit-<br />

Simulatio~~sprogramme auf Rechnersystemen möglich ist, die in<br />

großen Stückzahlen und <strong>mit</strong> hohem Reifegrad hergestellt werden.<br />

Proprietäre Lösungen sollen vermieden werden, wenn nicht besondere<br />

Griiride wie die l'erfügbarkeit spezieller Software oder I/O-<br />

Hardware deren Einsatz erfordern.<br />

2.2.2 Numerische Anforderungen<br />

Aiifgrund der Forderiiiig aus G1. 2.2 müssen echt zeitfähige Siinula-<br />

tionsmodelle so beschaffen sein, dass eine Lösung der Modellgleicliun-<br />

gen durch numerisclie Integrationsverfahren <strong>mit</strong> konstanter Schrittweite<br />

möglich ist. Nur explizite \erfahren konirnen in Frage, da implizite \'er-<br />

fahren iterativ arbeiten und deren Rechenzeit nicht vorab bekannt ist.<br />

Dies hat weitreichende Konsequenzen für die Erstellung und Echtzeit-<br />

Irriplementierung der Modelle:<br />

ODE-Darstellung: Die AIodellgleichungen müssen als System gewölin-<br />

liclier Differenzialgleichungen (ODE) erster Ordnung in expliziter<br />

Darstellung vorliegen,<br />

2 = f (2,<br />

t) , (2.4

wobei zum Zeitpunkt t = 0 die Anfangsbedingung gilt:<br />

Differenzialalgebraische Gleichungen (DAE) der Form<br />

sind nicht zulässig, da sie nur iterativ lösbar sind.<br />

Schrittweite: Die Integrations-Schrittweite h hängt von der höchsten<br />

Eigenfrequenz je,„„ des ODE-Systems ab und ist so zu wählen,<br />

dass das verwendete Integrationsverfahren ausreichende Genauig-<br />

keit liefert. Zeitz gibt in [95] folgende empirische Regel an:<br />

Steife Systeme, also Differenzialgleichungs-Systeme <strong>mit</strong> Eigenfre-<br />

quenzen, die sich um mehrerer Größenordnungen unterscheiden,<br />

sind zu vermeiden, da die zulässige Schrittweite h aufgrund von<br />

G1. 2.7 sehr klein wird. In der Praxis bedeutet dies, dass für me-<br />

chanische Teilsysteme <strong>mit</strong> hoher Steifigkeit und geringen bewegten<br />

Massen4 eventuell eine starre hlodellierung gewählt werden muss,<br />

auch wenn dadurch höherfrequente Vorgänge nicht erfasst werden.<br />

Da detailliertBe Kraftfahrzeugmodelle stets nichtlinear sind, können<br />

die \'erfahren zur linearen Analyse nur <strong>mit</strong> Einschränkungen<br />

benutzt werden. Durch Linearisierung an ausge~+-ählten ,, Worst-<br />

Case" -Betriebspunkten müssen die höchsten Eigenwerte abgeschätzt<br />

werden. Gegebenenfalls sind Maßnahmen zur Begrenzung<br />

dieser Eigenwerte notwendig. Diese Problematik wird z.B. in<br />

[96] diskutiert.<br />

Komplexität: Aus der Begrenzung der Schrittweite h gemäß G1. 2.7<br />

folgt, dass eine obere Grenze für die Anzahl der Rechenoperationen<br />

pro Zeitschritt existiert. Die Komplexität eines Simulationsmodells<br />

muss so gewählt werden, dass diese Grenze in keinem Zeitschritt<br />

überschritten wird. Für die hier betrachteten Anwendungsfälle<br />

Antriebsstrang und Fahrteugdynam5 sind geringe Schrittweiten<br />

h N 0,s.. . 5 ms erforderlich. Insbesondere bei der automatischen<br />

4~olche Konfigurationen treten u.A. in der Lenkanlage und im Ant,rieb auf.

Generierung von Bewegungsgleichungen für Mehrkörpersysteme<br />

(.Abschnitt 2.3.1) muss die Anzahl der Freiheitsgrade beschränkt<br />

werden, da dieses Verfahren sehr berechnungsintensiv ist.<br />

Das verwendete numerische Integrationsverfahren muss <strong>mit</strong> weni-<br />

gen Berechnungen der rechten Seite von GI. 2.4 auskommen und<br />

zuverlässig konvergieren.<br />

Betriebssystem: Eine streng deterministische Ausführung der Simula-<br />

tion ist für Schrittweiten im h4illisekundenbereich nur bei Verwen-<br />

dung von Echtzeit-Betriebssystemen oder so genannten Mikroker-<br />

nen5 gewährleistet. Der Programm-Code für eiii Si~iiulationsrnodell<br />

darf nur Konstrukte enthalten, die unter dem jeweiligen Betriebs-<br />

systenl verfügbar sind. Der benötigte Speicherplatz darf die Res-<br />

sourcen des Betriebssystems bzw. des Rechners nicht übersteigen.<br />

2.2.3 Strukturierung<br />

Zur Erreichung der Portabilität und Wiederverwendbarkeit müssen Si-<br />

mulationsmodelle sinnvoll strukturiert werden. Im Folgenden werden ei-<br />

nige Empfehlungen gegeben, die in dieser Arbeit durchgehend beacht'et<br />

wer den:<br />

Ein-/Ausgabe (I/O): Der Berechnungsteil eines Simulationsinodells<br />

ist strikt vom I/O-Teil zu trennen, da dieser stets spezifisch für<br />

die Hardware und das Betriebssystem ist. Als I/O-Geräte kommen<br />

Dateien, Benutzeroberflachen, Daterinetzwerke (z.B. GAY) sowie<br />

elektrische Schnittstellen (2.13. X/D-Karten) in Frage.<br />

Wird diese Regel beachtet, so ist die Anpassung an unterschiedliche<br />

Rechnerplattfornien durch ..\ustausch des I/O-Teils ohne Anderuii-<br />

gen am Simulationsrnodell möglich. Weiterhin können I/O-Geräte<br />

durch andere Typen ersetzt werden. Dies ist z.B. notwendig, wenn<br />

eine Simulationsanlage vom Reglerentwurf <strong>mit</strong> SIL zuin Steuer-<br />

gerätetest <strong>mit</strong> HIL erweitert wird.<br />

Maßeinheiten: Im Berechnungsteil eines Simulationsmodells sollen al-<br />

le physikalischen Größen in SI-Einheiten angegeben werden. Je-<br />

'Hier<strong>mit</strong> werden Betriebssystem-artige Software-Produkte bezeichnet, die nur rudi-<br />

mentär ausgeführt sind und häufig kein Dat,eis>-stern aufweisen.

de Abweichung stellt eine potenzielle Fehlerquelle dar6. Die FVie-<br />

derverwendbarkeit von Teilmodellen ist nur gegeben, wenn deren<br />

Schnit tgrößen einheitliche Maßeinheiten aufweisen.<br />

Die Umrechnung zwischen anschaulichen Maßeinheiten und SI-<br />

Einheiten erfolgt im I/O-Teil. Auch die Modellparameter sind in<br />

SI-Größen umzurechnen.<br />

jB.emsdnici<<br />

Eingabe<br />

Il:broibmiangl<br />

Parameter Ausgabe<br />

Ein-/<br />

AUS-<br />

Berech-<br />

nung<br />

[bar] 1 [psi] mm] 1 [inch]<br />

Geschwindigkeit<br />

[kmlh] I [mph]<br />

l~brolj~~fan~<br />

Bremsdruck<br />

[Pa1<br />

Fahrzeugmodell<br />

(Längsdynamik<br />

und Bremsen) Geschwindigkeit<br />

[mlsl<br />

Bild 2.5: Beispiel zur Strukturierung von Simulationsmodellen<br />

In Bild 2.5 werden diese Sachverhalte anhand eines einfachen<br />

Längsdynamik-iLlodells veranschaulicht. Die Eingangsgröße Bremsdruck<br />

wird vom Benutzer über eine grafische Benutzeroberfläche vorgegeben.<br />

Als Berechnungsergebnis wird die Fahrgeschwzndigkeit angezeigt. Der<br />

Parameter Reifen-Abrollumfang kann variiert werden. Im Berechnungs-<br />

teil werden ausschließlich die SI-Einheiten Pa, m und m/s verwendet.<br />

Dagegen erfolgen Eingabe, Ausgabe und Parameter-Definition in den<br />

anschaulichen Einheiten bar, rnrn und km/h. Durch Austausch des I/O-<br />

Teils kann das Simulationsmodell an die angelsächsischen Maßeinheiten<br />

psi, inch und mpla angepasst werden.<br />

61m Jahr 1999 geriet die hlarssonde Climate Orbiter aufgrund einer Verwechslung<br />

der Längeneinheiten Foot und Meter in der Steuerungs-Software in eine zu tiefe<br />

Umlaufbahn und stürzte ab [97].

Zur internen Strukturierung des Berechnungsteils hat sich eine d\uftei-<br />

lung anhand von Kraftfahrzeug-Komponenten bewährt. Die zwischen<br />

den Teilrnodellen ausgetauschten Signale sollen real auftretende, physi-<br />

kalische Größen sein. In Abschnitt 4.4 wird dies anhand eines modular<br />

aufgebauten Xntriebsstrang-Modells erläutert.<br />

2.3 Auswahl und Kopplung von<br />

Software- Werkzeugen<br />

2.3.1 Konzept<br />

Zur Realisierurig echtzeitfähiger Fahrzcugmodelle urerden nielirere Mo-<br />

dellierungsverfahren kombiniert, die jeweils in eirier Klasse I-on Software-<br />

IYerkzeugeri verfügbar sind:<br />

CACE-Werkzeuge (Computer Aided Control Engineering) sind in der<br />

Regelungstechnik weit verbreitet. Sie ermöglichen die grafische,<br />

blockorientierte Abbildung technischer Systeme <strong>mit</strong> eindeutiger<br />

Zuordnung von Eingangs- und Ausgangsgrößen. Gängige Darstel-<br />

lungsformen sind Übert ragungsfunktionen im Zeit- oder Frequenz-<br />

bereich. Sie sind für allgemeine 3lodellierungsaufgaben geeignet.<br />

Die Blockorientierung erlaubt eine übersichtliche Strukturierung.<br />

FSM-Werkzeuge (Finite State Machines) gestatten die Abbildung<br />

technischer Systeme <strong>mit</strong> einer endlichen Anzahl diskreter Zustände<br />

nach der Methode der Zustandsgraphen. Auch zustandsorielitierte<br />

St eueralgorit hrnen können effizient implenie~ltiert werden.<br />

MKS-Werkzeuge (hfehrkörpersgsteme) erlauben eine effiziente Mo-<br />

dellbildung fiir dreidimensionale mechanische hiiordiiiiiigen rnit<br />

komplexen Be~vegungs~erliältnisseri.<br />

Die auszuwählenden Software-Werkzeuge müssen folgende Eigenschaften<br />

Einfache Handhabung durch grafische Benutzeroberflächen,<br />

kommerzielle Verfügbarkeit sowie weite Verbreitung und<br />

Gleitkomrna-Code-Generatoren zur Ausgabe der Modellgleichun-<br />

gen in einer standardisierten Prograrnrniersprache.

Werkzeug 2 Werkzeug 2 . .<br />

Code-Generator Code-Generator<br />

Schnittstellen- Schnittstellen- ...<br />

Software Software<br />

Tl<br />

ANSI-C<br />

Import Import<br />

Block Block<br />

\ CACE-Werkzeug<br />

(Basis-Werkzeug )<br />

I I<br />

J I ANSI-C<br />

ANSI-C<br />

Code-Generator<br />

Basis-<br />

Modell<br />

Integration<br />

< C-Compiler I Linker ><br />

( Ausführbares Echtzeit-Simulationsprogramm<br />

0 0 D<br />

Datei Programm Funktionsblock<br />

(Basis-Werkzeug)<br />

Bild 2.6: Kopplung von Software-Werkzeugen durch <strong>Einbindung</strong> von au-<br />

tomatisch generiertem C-Code in ein Basis-Werkzeug

Die Kopplung der oben genannten Werkzeug-Klassen erfolgt gemäß<br />

Bild 2.6 durch den Export und Import von Programm-Code. Das<br />

CXCE-I%Terkzeug wird als Basis-Werkzeug verwendet. Der von den<br />

Code-Generatoren der übrigen Werkzeuge erzeugte Code wird durch<br />

geeignete Schnittstellen-Software in die standardisierte Programmier-<br />

sprache ANSI-C überführt [98] und jeweils als Funktionsblock in das<br />

Basis-LVerkzeiig eingebettet. Die Bedeutung des exportierten Codes ist<br />

abhängig vom jeweiligeri IIerkzeug. Zumeist repräsentiert der Code die<br />

rechte Seite eines ODE-Systems gemäß GI. 2.4 oder einen rein algebrai-<br />

schen Zusammenhang der Form ij = f (U). Weitere Rfodellanteile (in Bild<br />

2.6 als Basismodell bezeichnet) werden un<strong>mit</strong>telbar im Basis-Werkzeug<br />

implementiert.<br />

Nun kann das Gesaintmodell innerhalb des Basis-I$Terkzeugs <strong>mit</strong>tels<br />

Nicht-Echtzeit-Simulation berechnet werden. Hierbei wird für alle Mo-<br />

dellteile ein einheitliches, im Basis-IVerkzeug verfügbares numerisches<br />

Integrationsverfahren verwendet.<br />

In einem weiteren Schritt erzeugt der Code-Generator des Basis-<br />

Werkzeiigs aus dem Basisniodell ebenfalls ANSI-C-Code und fügt<br />

die eingebetteten C-Code-Anteile aus den übrigen Werkzeugen sowie<br />

ein Simulations-Rahmenprogramm hinzu. Ein C-Compiler/Linker er-<br />

zeugt aus diesem C-Code unter Hinzunahme Betriebssystem-spezifischer<br />

Treiber-Bibliotheken ein ausführbares Programm für den jeweiligen<br />

Echtzeit-Rech~iertyp.<br />

Durch die einheitliche Verwendung von AMI-C wird die geforderte Por-<br />

tabilität gewährleistet, da für alle gängigen Rcchnertypen unti Betriebs-<br />

syst enie C-Compiler/Linkei verfügbar sind.<br />

JToraussetzung für die Echtzeitfähigkeit des gesamten generierten Co-<br />

des ist,, dass die Code-Generatoren aller beteiligten Software-Werkzeuge<br />

die Forderungeii explizite ODE-Darstellung und Vermeidung 2terativer<br />

Algorithmen aus Abschnitt 2.2.2 berücksichtigen. Dagegen obligt die<br />

Einhaltung der übrigen Anforderungen dem Benutzer im Rahmen der<br />

Xlodellbildung .<br />

In Bild 2.7 sind die in dieser Arbeit verwendeten Kopplungen dargestellt.<br />

Diese werden im Folgenden genauer u~ite~suclit. Die Integration<br />

des Werkzeugs CANDB wird iri Abschnitt 3.2.4 beschrieben.

\ SlMULlNK<br />

CANDB<br />

FORTRAN FORTRAN DBC<br />

SL-RD (SPSL-R?J<br />

ANSI-C ANSI-C ANSI-C ANSI-C<br />

S-Function S-Function S-Function<br />

(Basis-Werkzeug)<br />

Real Time Workshop (RTW)<br />

Echtzeitfähiger Programm-Code 1<br />

D C__> 0 0<br />

Datei Programm Erweiterung SIMULINK-<br />

(kommerziell) (IVK / <strong>FKFS</strong>) Block<br />

Bild 2.7: In dieser Arbeit verwendete oder neu entwickelte Kopplungen<br />

von Soft8wa.re-Werkzeugen

2.3.2 Auswahl des Basis-Werkzeugs<br />

Als Basis-Werkzeuge kommen insbesondere die Software-Pakete<br />

AIATLAB/SIhtlULINK und MATRIXx/System-Build in Frage. Bei-<br />

de Programme besitzen vergleichbare Eigenschaften. U7ährend der<br />

Durchführung dieser Arbeit wurde jedoch erkennbar, dass die länger-<br />

fristige Verfügbarkeit und die kontinuierliche Weiterentwicklung von<br />

IIATRIXx nicht gesichert ist. Alternativ kommt ASCET-SD in Be-<br />

tracht. Dieses Werkzeug, das vor allem bei der seriennahen Entwick-<br />

lung von Steuergeräte-Software Anwendung findet [99], ermöglicht eben-<br />

falls die Erstellung von Blockdiagram~nen und die Einbettung von ex-<br />

ternem Progranim-Code. Ein Nachteil von ASCET-SD für Siinulations-<br />

Anwendungen ist jedoch die uncinhcitliche Behandlung 1.011 zeitkonti-<br />

nuierlichen und zeitdiskret en Systemen, wodurch die Implementierung<br />

..gemischterg Simulationsmodelle aufm-endig ist. Außerdem zeigte sich,<br />

dass die zugehörige, vom Hersteller von ASCET-SD angebotene Echtzeit-<br />

Rechner-Hardware während der Frühphase dieser Arbeit zur Ausführung<br />

komplexer MKS-Modelle nicht ausreichend leistungsfähig war7.<br />

Aufgrund der genannten Fakten und der weiten Verbreitung in der<br />

Autornobilindustrie wird für das weitere Vorgehen die Produktgruppe<br />

i\liZTLAB/SISIULINK als Basiswerkzeug ausgewählt.<br />

hlATLAB ist ein allgemeines numerisches Berechnungs- und Analyse-<br />

Programm [IOO]. SIIIULINK ist ein Editor zur grafischen Erstellung<br />

urid Ausführung von Simulationsmodellen [101]. Die Beschreibung erfolgt<br />

<strong>mit</strong>tels hierarchisch strukturierbarer Blockdiagrarnrne. Folgende<br />

Alodellierungs-Ele~nente stehen zur Verfügung:<br />

Lineare und nichtlineare ~bertra~uri~sfuiiktiorien in Zeitbereichs-<br />

Darstellung,<br />

lineare CTbertragungsfuiiktionen in Frequenzbereichs-Darstellung,<br />

ein- und mehrdimensionale Kennfelder <strong>mit</strong> Interpolation und<br />

zeit diskrete Übert ragungsglieder .<br />

SISlULINK verfügt über eine Schnittstelle zum Import von C-Code, die<br />

als S-Fu,nction bezeichnet wird [102]. Diese Schnittstelle wird zur Ein-<br />

bindung externer Llodellteile gemäß Bild 2.7 verwendet.<br />

7~ie zuletzt genannte Einschräilkiing besteht heute nicht rnehr.

Ein Code-Generator <strong>mit</strong> der Bezeichnung RTW (Real Time Workshop)<br />

ist Bestandteil des MATLAB-Programmpakets. Er wird zur Erzeugung<br />

von Gleitkomma-Programm-Code in ANSI-C aus der grafischen Modell-<br />

beschreibung verwendet [103]. Dabei wird auch externer (in S-Functions<br />

enthaltener) Code hinzugefügt. Durch geeignete Programmierung des<br />

RTW können Echtzeit-Programme für unterschiedliche Zielrechner au-<br />

tomatisch erzeugt werden.<br />

2.3.3 Auswahl des FSM-Werkzeugs<br />

Technische Systeme, die durch eine begrenzte Anzahl diskreter Zustände<br />

gekennzeichnet sind, können durch Endliche Zustandsautomaten (FSRZ)<br />

beschrieben werden. Eine verbreitete Darstellungsform ist das von Harel<br />

eingeführte ~ustands-Übergangs-~iagrarnrn [104]. Bei der Entwicklung<br />

von Software für Kraftfahrzeuge sind insbesondere die kommerziellen<br />

Werkzeuge STATEMATE [I051 und STATEFLOW [I061 verbreitet. Beide<br />

Werzkzeuge verfügen über ANSI-C-Code-Generatoren. Eine Kopplung<br />

von STATEMATE und SIMULINK wird in [I071 beschrieben. In<br />

dieser Arbeit wird STATEFLOW verwendet, da dieses Werkzeug Bestandteil<br />

des MATLAB-Programmpakets ist. Die Code-<strong>Einbindung</strong> in<br />

SIMULINK ist als Produkt verfügbar und wird nicht näher betrachtet.<br />

Die Modellierung von Steuergeräte-Funktionen <strong>mit</strong> STATEFLOW wird<br />

beispielhaft in Abschnitt 4.4.2 behandelt.<br />

2.3.4 Auswahl des MKS-Werkzeugs<br />

Zur Ylodellierung von Mehrkörpersystemen (MKS) existiert eine I'iel-<br />

zahl von Programmpaketen. Eine cbersicht zu MKS-Programmen und<br />

den verwendeten Formalismen findet sich in [108].<br />

Zwei Klassen von MKS-Programmen sind zu unterscheiden:<br />

Lineare Programme erzeugen eine linearisierte Form der Bewegungs-<br />

gleichungen. In der Fahrzeugsimulation sind sie lediglich zur<br />

Lösung von Problemen <strong>mit</strong> geringen Relativbewegungen zwischen<br />

den Starrkörpern geeignet, z.B. zur Simulation der Längs- und Ver-<br />

tikaldynamik. Als Beispiel sei MEDYNA erwähnt [log].<br />

Nichtlineare Programme ermöglichen die Berechnung von mechani-<br />

schen Syst'emen <strong>mit</strong> großen Relativbewegungen, die bei der dreidi-

mensioiialen Simulation der Fahrzeugdynamik auftreten können8.<br />

Ein in der Automobilindustrie weit verbreitetes, nichtlineares<br />

RfKS-Programm ist dDAhlS [47].<br />

Für Echtzeit- Anwendungen besteht zusätzlich die Forderung,<br />

dass die Bewegungsgleichungen in symbolischer Form, d. h. als<br />

Programm-Code, ausgegeben werden können. Bei ADAMS ist dies<br />

zum Zeitpunkt dieser Arbeit nicht gegeben. Dagegen verfügen die<br />

Programme MESA VERDE [IIO], NEWEUL und SIRIPACK über<br />

entsprechende Code-Generatoren. Fiir die weiteren Untersuchun-<br />

gen werden lediglich NEWEUL und SIhIPACK näher betrachetet.<br />

da MES24 VERDE dem Autor nicht zur Verfügung steht.<br />

2.3.5 <strong>Einbindung</strong> von NEWEUL in SIMULINK<br />

NEWEUL wird seit den 1970er Jahren am Institut B für hlechanik der<br />

Universität Stuttgart entwickelt [I111 und bereits zur Echtzeitsimiilation<br />

der Fahrzeugdynamik eingesetzt [65].<br />

In Bild 2.8 sind die ~lodellstruktur und der Signalfluss bei der reali-<br />

sierten <strong>Einbindung</strong> von symbolischem Code aus NEIVEUL in SIMU-<br />

LINK dargestellt. Die Beschreibung eines NELVEUL-MKS erfolgt textu-<br />

ell unter Verwendung der Modellierungs-Elemente Starrkörper, Koordi-<br />

natensystem, Lager und eingeprägte Kraff. Aus der Beschreibungsdatei<br />

generiert NETVEUL unter ,4nu-endung des Newton-Euler-Formalismus<br />

und des D'L41embert'schen Prinzips Dateien in der Programmiersprache<br />

FORTRAN 77 [112]. Diese werden unter ITerwendung eines in [65] vorge-<br />

stellten Überset,zungsprogramms NElTJ2C nach ANSI-C konvertiert und<br />

über zwei S-Functions in das SIhlULINK-klodell eingebunden.<br />

Der B lock BTt7GL enthält die Be\vegungsgleicliui-igen in der Form<br />

G1. 2.8 ergibt sich durch Aufstellung des Impuls- und Drallsatzes für die<br />

St,arrkörper des MKS. Eine ausführliche Herleitung enthält [113]. Dort<br />

werden auch die verwendeten Variablen im Detail erläutert.<br />

I\f repräsentiert die so genannte hlassenmatrix. Sie wird in jedem Zeit-<br />

schritt aus den Massen und Trägheitstensoren sowie den verallgemeiner-<br />

ten Koordinaten 2 der Starrkörper er<strong>mit</strong>telt. k ist der Vektor der Kräfte.<br />

8z,~.<br />

die Relativbewegung zwischen Zugmaschine lind Anhänger bzn-. Auflieger bei<br />

einem LKIV-Zug.

I<br />

FORTRAN 77-Code<br />

< NEW2C ><br />

ANSI-C-Code<br />

V<br />

-<br />

Numerische Integration<br />

b BWGL<br />

. .<br />

.-C<br />

NEWEUL-<br />

I<br />

& +<br />

X X<br />

Bewegungsgleichungen<br />

]<br />

0 0 0<br />

Datei<br />

- --<br />

U = (F, M)<br />

KREL<br />

0<br />

Programm Erweiterung SIMULINK-<br />

(kommerziell) (IVK 1 <strong>FKFS</strong>) Block<br />

Bild 2.8: Vorgehen bei der <strong>Einbindung</strong> von symbolischem Code aus<br />

NEWTEUL in SIMULINK<br />

b<br />

SIMULINK-<br />

Kraftelemente<br />

BEOP<br />

NEWEUL-<br />

Beobachter-<br />

größen<br />

-C<br />

Y<br />

-C<br />

Y<br />

-<br />

-

die von 2 unabhängig sind (Kreisel-, Zentrifugal- und Coriuliskräfte) . Der<br />

lTektor (I der verallgemeinerten Kräfte und hloniente wird aus den ein-<br />

geprägten Kräften F und L'iomenten AI errechnet. Diese werden in dem<br />

lTektor lif zusammengefasst und in das IIKS eingegeben.<br />

Durch Invertierung der Massenmatrix 1%-ird GI. 2.8 in jedem Zeitschritt<br />

nach den verallgemeinerten Beschleunigungen 2 aufgelöst. Zur Inrertie-<br />

rung wird das Cliolesky-l17erfahren [l 141 verwendet, welches gegenüber<br />

anderen Verfahren einen wesentlich geringeren Rechenaufwand verur-<br />

sacht und für ITKS-Anwendungen geeignet ist.<br />

Nach zweimaliger numerischer Integration (INT-Block) in SIMU-<br />

LINK ergeben sich die Geschwindigkeits-Koordinaten 2 und die Lage-<br />

Koordinaten 2, mrelclie die Bewegungen der Starrkörper beschreiben.<br />

Iin Block BEOP wird aus Z und 2 eine Anzahl von Beobachtungsgrößen<br />

f und 2 er<strong>mit</strong>telt, z.B. die relative Position und Geschwindigkeit der<br />

Anlenkpunkt e eines Aufbaudämpfers.<br />

Die Kraftelemente selbst werden in SINULINK abgebildet (KREL), da<br />

NEWEUL keine Bibliotheken bereitstellt. Die Berechnung von Feder-,<br />

Dämpfer- und Stabilisator-Kräften erfolgt hierbei <strong>mit</strong>tels nichtlinearer<br />

Kennlinien. Diese Kennlinien werden in Abhängigkeit von der relativen<br />

Lage und Geschwindigkeit der jeweiligen Anlenkungspunkte angegeben.<br />

Zur Modellierung der Reifenkräfte und der Lenkung wird auf Kapitel 5<br />

verwiesen. Alle berechneten Kräfte und I'iomente werden als Vektor G<br />

in den Block BIVGL zurückgeführt.<br />

2.3.6 <strong>Einbindung</strong> von SIMPACK in SIMULINK<br />

Als Alternative zu NEW ECL wird (las kommerzielle MKS-Werkzeug<br />

SIAIPACK zur Generierung von symbolischem Code verwendet. Der For-<br />

malismus dieses Programms wird in [48] ausführlich dargestellt.<br />

Die Definition eines SIRIPACK-MKS erfolgt über eine grafische<br />

Benutzeroberfläche (GUI= Graphical User Interface). Für Echtzeit-<br />

Anwendungen sind folgende hlodellierungs-Elemente verwendbar:<br />

Referenz-Koordinatensysteme (z .B. Inertialsystem),<br />

g~las.tische<br />

Körper können ebenfalls definiert werden. In dieser Arbeit wird dies<br />

nicht betrachtet.

Symbolic Code Interface (SCI)<br />

4L<br />

I + --<br />

V<br />

portabler Konstrukte,<br />

U = (F, M)<br />

0 CT> 0<br />

0<br />

Datei Programm Erweiterung SIMULINK-<br />

(kommerziell) (IVK I <strong>FKFS</strong>) Block<br />

Bild 2.9: Vorgehen bei der <strong>Einbindung</strong> von symbolischem Code aus<br />

SIMPACK in SIMULINK für Echtzeit-Anwendungen

vor definierte Gelenke (z .B. Kugelgelenk),<br />

vordefinierte Kraftelemente (z.B. Federn, Dämpfer),<br />

benutzerdefinierte Gelenke und Kraftelemente und<br />

Sensoren zur Er<strong>mit</strong>tlung der Relativbe~vegi-ing von Koordinatensysternen.<br />

Kinematische Schleifen (Zwangsbedingungen) sind gemäß Abschnitt<br />

2.2.2 zu vermeiden, da sie zu einer differenzial-algabraischen Form der<br />

Bewegungsgleichungen führen. Bei der hfodellierung von Nutzfahrzeugeii<br />

können kinematische Schleifen eliminiert werden (Abschnitt 5.2).<br />

Die Schnittstelle SIlfAT, die als Bestandteil von SIMPACK angebo-<br />

ten wird, ist lediglich für Nicht-Echtzeit-.inwendungen geeignet. In [I 151<br />

wird SI'IIAT im Hinblick auf die Kfz-Simulation untersucht.<br />

Das Vorgehen bei der Code-<strong>Einbindung</strong> ist in Bild 2.9 dargestellt.<br />

Aus der SIMPACK-Beschreibungsdatei erzeugt der Code-Generator SC1<br />

(Symbolic Code Interface) eine Datei, die den symbolischen Code ein-<br />

schließlich der Bibliotheks-Funktionen enthält [116]. Der Code besteht<br />

aus Anteilen in FORTRAN 77 und FORTRAN 90.<br />

Abweichend von SIR4AT wird der generierte Code vor der Ei~lbindung in<br />

SIMULINK gemäß den Anforderungen aus Abschnitt 2.2.1 modifiziert:<br />

Xicht portable Anweisungen werden durch gleichwertige portable<br />

Konstrukte ersetzt oder entfernt (Speiclierver~valtung, 110).<br />

Zur Reduktion des Speicherbedarfs werden überdimensionierte<br />

Afatrizen an den Bedarf des jeweiligen LfKS angepasst.<br />

hIit dem Übersetzungsprogramm F2C wird der FORTRAY-Code<br />

nach ANSI-C konvertiert.<br />

Die enstandenen C-Dateien werden <strong>mit</strong>tels einer S-Function in<br />

SIMULINK eingebunden.<br />

Der in Bild 2.9 dargestellte Block BWGL enthält die Bewegungs-<br />

Differenzialgleichungen des N1ehrkörpersystems in der Form<br />

Dabei ist Z der Vektor der Zustandsgrößen. Er enthält fiir jeden 2IKS-<br />

Freiheitsgrad eine Lage- und eine Gesch~vindigkeits-Koordinate: z.B. den

Gierwinkel und die Gierrate, die dem Freiheit,sgrad Gierbewegung eines<br />

Fahrzeugs zugeordnet sind. Im Vektor ii sind extern berechnete Kräfte<br />

und Momente enthalten (siehe unten).<br />

Aus 2 erhält man durch numerische Integration (INT) den Zustandsvek-<br />

tor 2. Im Block BEOP werden die Ausgangsgrößen berechnet,<br />

z.B. die Lage und Geschwindigkeit der Reifen-Aufstandspunkte zur Be-<br />

rechnung der Reifenkräfte.<br />

Analog zum Vorgehen bei NEWEUL werden bestimmte Fahrzeug-<br />

Komponenten nicht im SIhIPACK-MKS, sondern im umgebenden<br />

SIh4ULINK-Modell abgebildet. Dies betrifft insbesondere die Lenkung<br />

(siehe Abschnitt 5.5) und die Reifen (siehe Abschnitt 5.3). Die extern<br />

er<strong>mit</strong>telten Kräfte F, (z.B. Reifenkräfte) und Momente A? werden wie-<br />

derum als Vektor U in das SIMPACK-MKS zurückgeführt.<br />

Eine Einfügung der hergeleiteten Modellgleichungen dieser Komponen-<br />

ten direkt in SIMPACK wäre zwar durch manuelle Programmierung so<br />

genannter User-Routinen in FORTRAN ebenfalls möglich, würde jedoch<br />

einen wesentlich höheren Aufwand gegenüber der hier vorgestellten „ex-<br />

ternen" Lösung verursachen.

3 Elektronische Steuerungen und<br />

CAN-Netzwerke<br />

In jedem modernen Fahrzeug sind elektronische Steuergeräte vorhanden.<br />

Die Steuergeräte arbeiten entweder unabhängig voneinander oder sind<br />

iiber elektrische Einzelleitungen bzw . Datenbussysteme verbunden. Bei<br />

der (Echtzeit-) Sirnulation von Kraftfahrzeugen miissen die elelitroni-<br />

schen Steuerungen berücksiclitigt werden, da sie das Gesamtverhalten<br />

in hohem Maße bestimmen. Dies gilt insbesondere fiir die Teilbereiche<br />

Antriebsstrang und Fahrxeugdynamik.<br />

In diesem diesem Kapitel werden verschiedene Möglichkeiten zur Inte-<br />

gration einzelner elektronischer Steuergeräte in das Simulationskonzept<br />

aus Kapitel 2 diskutiert.<br />

Anschließend wird die Betrachtung für S teuergeräte-Netzwerke auf Basis<br />

des verbreiteten CAN-Protokolls (Controller Area Network) erweitert.<br />

Des TYeiteren wird die Allodellierung von Aggregaten und deren Einbin-<br />

diing in die Sirnulation als reale Hardware untersucht.<br />

3.1 Verfahren zur <strong>Einbindung</strong> von elektronischen<br />

Steuergeräten und Aggregaten<br />

Zur Einbirlclung elektronischer Steuergeräte bzw. deren Funktio~lsum-<br />

fang som-ie der zugeordneten Aggregate in Echtzeit-Simulationsanlageri<br />

existieren mehrere hIöglichkeiten. Diese werden in den folgenden ilb-<br />

schnitten vorgestellt und bezüglich Realisierbarkeit und Aufwand be-<br />

wertet.<br />

3.1.1 Definition von Schnittstellen<br />

Zunächst werden verallgemeinerte Schnitt stellen für die wesent liclien<br />

Teilsyst eme einer Simulat ionsanlage definiert. Diese Definitionen<br />

ermöglichen die Strukturierung von Si~nulationsmodellen lind die einheitliche<br />

Behandlung verschiedener Sini~lat~ionsverfahren.

Aggregat und Aggregate-Modell<br />

+<br />

r-------------------------------------------------------------------------<br />

/ Aggregate-Modell (AM) 7 i<br />

1<br />

I<br />

I<br />

1 ,<br />

I<br />

I<br />

I<br />

1<br />

yT- 1 +<br />

I<br />

I<br />

-.)<br />

I<br />

m, i-<br />

Aktuator-<br />

Modell<br />

t<br />

.-C<br />

Y ,<br />

KO~PO-<br />

nenten-<br />

Modell<br />

Bild 3.1 : Schnittstellen-Struktur für ein Aggregat<br />

I +<br />

I<br />

i<br />

I<br />

,<br />

m~<br />

Als Aggregat wird entweder eine konstruktiv abgrenzbare Funktions-<br />

einheit eines Kraftfahrzeugs (z.B. das Getriebe) oder eine Wechselwir-<br />

kung (z .B. der Reifen-Fahrbahn-Kontakt) bezeichnet. Ein Aggregat kann<br />

Kopplungen zu anderen Aggregaten, zur Fahrzeug-Umgebung, zum Fah-<br />

rer sowie zu elektronischen Steuergeräten aufweisen (siehe Bild l .I). Zur<br />

Abbildung von Aggregaten im Simiilationsmodell wird in Bild 3.1 ein<br />

verallgemeinertes Aggregate-Modell definiert.<br />

Die Eingänge yR repräsentieren elektrische Signale von einem Steuer-<br />

gerät, die zur Ansteuerung der -4ktuatoren verwendet werden. Im Block<br />

Aktuutor-Modell wird das dynamische Verhalten der elektrisch gesteu-<br />

erten Aktuatorik (Elektromotoren, LIagnetventile etc.) dargestellt. Die<br />

Aktuatorik wirkt über den Vektor f auf das Komponenten-Modell ein.<br />

In diesem Block werden die mechanischen, hydraulischen oder Pneuma-<br />

tischen Teilsysteme des Aggregats modelliert. Der Block Sensor-Modell<br />

bildet die Sensorik ab, also die Umsetzung der Zustandsgrößen I in elek-<br />

trische Sensorsignale T. Diese werden zum Steuergerät zurückgeführt.<br />

Der Vektor ijF enthält Fahrereingaben (z.B. den Lenkradwinkel). Über<br />

fa, werden Rückmeldungen für den Fahrer ausgegeben, z .B. das Rückstellmoment<br />

am Lenkrad.<br />

-C<br />

X<br />

Sensor-<br />

Modell<br />

i<br />

I<br />

I<br />

I<br />

i .r<br />

:<br />

I<br />

I<br />

I<br />

I +<br />

Die Kopplung <strong>mit</strong> anderen Aggregate-Modellen (einschließlich des nach-<br />

folgend eingeführten Umgebungs-Modells) erfolgt über die Eingänge<br />

I<br />

'fAg

6, lind die Ausgänge fi. Diese Vektoren beinhalten nicht-elektrische<br />

Größen wie Drehzahlen, Kräfte und Drücke.<br />

Bei den meisten realen Aggregaten sind nicht alle Typen von Ein- und<br />

L4usgangssignalen vorhanden. Bei Aggregaten ohne elektronische Rege-<br />

lung entfallen beispielweise die Vektoren yR und F.<br />

Umgebungs-Modell<br />

+<br />

m~<br />

..........................................................................<br />

i<br />

! Umgebungs-Modell (UM) 7 I<br />

I<br />

I +<br />

Fahrbahn,<br />

-<br />

I<br />

k<br />

I<br />

I<br />

I Fahrzeug-Umgebung I<br />

I : f"m<br />

Bild 3.2: Schnittstellen-Struktur für die Fahrzeug-Umgebung<br />

Das Modell der Fahrzeug-Umgebung wird als Sonderfall des Aggregate-<br />

Alodells behandelt. Die Schnittstellen sind in Bild 3.2 dargestellt.<br />

Die Wechselwirkungen <strong>mit</strong> anderen Aggregaten werden wiederum durch<br />

die Vektoren %E und mA beschrieben. hlechanische Eingangsgrößen des<br />

Lmgebungs-hlodells sind z.B. die Positionen der Reifenaufstandspunkte<br />

bezüglich eines fahrbahnfesten Koordinatensystems. Das Cmgebungs-<br />

hlodell er<strong>mit</strong>telt die Fahrbahnbeschafferiheit an diesen Stellen und über-<br />

gibt sie an das Fahrzeugrnodell.<br />

Hingegen ist es aus simulationstechnischer Sicht nicht sinnvoll, Kräfte als<br />

Schnittgrößen zur Umgebung zu verwenden, obwohl dies z.B. für Reifen-<br />

und Iriiindkräfte naheliegend erscheint. Vielmehr wird der Fahrbahnkon-<br />

takt dem Aggregat Rezfen zugeschlagen. Analog wird die Aerodynamik<br />

als Komponente in ein Aggregat Fahrwerk und Fahrzeugdynam ein-<br />

gefügt. Da<strong>mit</strong> werden diese Kräfte zu inneren Kräften des Fahrzeugmo-<br />

dells. Dies führt zu einer erheblichen Vereinfachiing der Modellstruktur.<br />

In dem Ikktor f;, werden Informationen für den Fahrer ausgegeben,<br />

z.B. eine Besclireibung der vorausliegenden Fahrbahn, welche von einein<br />

Grafikprogramm in optische Information umgesetzt wird.<br />

+

Fahrer und Fahrermodell<br />

a) Fahrermodell<br />

r---'--'--'--'--'--'--------------------------------------------------------<br />

4 I L 1 7<br />

-b<br />

fum ,<br />

+ I<br />

f% 1 +<br />

Fahrermodell oder<br />

Test-Automatisierungs-Programm<br />

b) realer Fahrer -.<br />

I<br />

.-C I<br />

*<br />

I MMI MMI<br />

I<br />

+ 1 I (Eingabe) (Ausgabe) f I<br />

f ~ g Mensch --+<br />

f"m I + I<br />

I !<br />

Bild 3.3: Schnittstellen-St'rukturen für den Fahrer<br />

Bild 3.3 a) zeigt die Schnitt stelle eines Fahrermodells. Die Eingangs-<br />

größen kommen von elektronischen Steuergeräten (fSc, z.B. Ansteuer-<br />

signale für Warnleuchten), von Aggregaten (fA„ z .B. das Rückstellmo-<br />

ment am Lenkrad) und von der Umgebung (fti,, z.B. der vorausliegende<br />

Fahrbahnverlauf).<br />

Aus diesen Eingangsgrößen er<strong>mit</strong>telt das Fahrermodell zwei Typen von<br />

Ausgangsgrößen. Der Vektor GF enthält Signale, welche den Steuer-<br />

geräten zugeführt werden, z.B . die Stellung eines an der Motor-Steuerung<br />

angeschlossenen. elektronischen Fahrpedals. Aus regelungstechnischer<br />

Sicht können diese Signale als Fiihrungsgrö~en betrachtet werden. Da-<br />

gegen bewirkt der Vektor CF Eingriffe an mechanischen Komponenten<br />

innerhalb von Aggregaten. Ein Beispiel ist die Kraft, <strong>mit</strong> der das Brems-<br />

pedal vom Fahrer betätigt wird. Diese Signale können als Stellgrö$en<br />

interpretiert werden.<br />

Ein Sonderfall des Fahrermodells ist die Test-Automatisierung. Das ist<br />

ein Programm, <strong>mit</strong> dem vordefinierte Testfälle, z .B. Normzyklen zur Ver-<br />

brauchsbestimmung, reproduzierbar ausgeführt werden können.<br />

I<br />

I

Für die in dieser Arbeit betrachtete, interakt i1.e Fahrsimulation wird eine<br />

weitere Blockstruktur realer Fahrer definiert, Bild 3.3 b). Diese besitzt<br />

die gleichen Schnittstellen wie das Fahrermodell. Der Mensch greift über<br />

eine Rlensch-Maschine-Schnittstelle (SIMI) in die Simulation ein (siehe<br />

Abschnitt 2.1.2).<br />

Unter lkrwendung der in diesem Abschnitt definierten Modellstrukturen<br />

werden im Folgenden verschiedene Wege zur Darstellung von Elektroni-<br />

schen Steuergeräten und Aggregaten in der Simulation diskutiert.<br />

3.1.2 <strong>Einbindung</strong> von Steuergeräte-Quellcode<br />

Der Quellcode eines Steuergerätes wird über die Code-Inzport-Schnitt-<br />

stelle in das Basis-IYerkzeug eingebunden und tauscht Daten rilit dern<br />

Simulationsmodell aus. Die <strong>Einbindung</strong> erfolgt auf die gleiche lf7eise wie<br />

die in ,4bschnitt 2.3.1 beschriebene <strong>Einbindung</strong> von generiertem Code<br />

aus anderen Software-Werkzeugen.<br />

Voraussetzung ist, dass der Code in der Programmiersprache vorliegt,<br />

die vom Basis-Werkzeug zur Generierung von Echtzeit-Code verwen-<br />

det wird, in dieser Arbeit also in ANSI-C'. Hardware-Zugriffe und<br />

Betriebssystem-Aufrufe müssen vor der <strong>Einbindung</strong> aus dem Quellcode<br />

entfernt werden. Zudem muss der Code vom Hersteller des Steuergerätes<br />

offengelegt werden, was aus Gründen des Kriow-how-Schutzes nicht zu<br />

ersvarten ist. Aufgrund der vielfältigen Probleme wird dieses Verfahren<br />

nicht näher betrachtet.<br />

3.1.3 Rechnerkopplung (Echt zeit-Cosimulat ion)<br />

Die Schwierigkeiten bei der <strong>Einbindung</strong> von Quellcode können umgaiigen<br />

werden, indem der Steuergeräte-Code auf einem separaten Rechner,<br />

z.B. einem Control-Prototyping-System, ausgeführt wird. Dieser Rechner<br />

kommuniziert <strong>mit</strong> dem Siniulationsrechner über eine echtzeitfähige<br />

Datenverbindung. Beide Rechner können unabhängig voneinander eingerichtet<br />

werden. Da<strong>mit</strong> entfallen die Restriktionen bezüglich Programmiersprache,<br />

Abhängigkeit von der Hardware und vom Betriebssystem<br />

sowie der Offenlegung des Qi~ellcodes. Eine Anwendung bei der Entwick-<br />

l~ie Implen~entierung von Steuergeräte-Code in C ist weit verbreitet, zeitkritische<br />

Funktionen werden jedoch bis heute in (Prozessor-spezifischem) Assembler. programmiert.

Fahrzeugmodell<br />

(SIMULINK)<br />

CAN 1<br />

Echtzeit-<br />

Simulationsrechner CAN 2<br />

Steuergeräte-<br />

Software-Prototyp<br />

(ASCET-SD)<br />

Bild 3.4: Echtzeit-Cosimulation unter Verwendung von SIMULINK und<br />

ASCET-SD<br />

lung elektronischer Nutzfahrzeug-Bremsanlagen wird in [I171 beschrie-<br />

ben.<br />

Das Verfahren wird auch angewandt, um inkompatible Software-<br />

Werkzeuge im Echtzeitbetrieb zu koppeln, z.B. SIMULINK und<br />

ASCET-SD [118]. Im Beispiel nach Bild 3.4 erfolgt der Datenaus-<br />

tausch über separate CAN-iJerbindungen für beide Richtungen. Da<br />

an jedem CAN-Bus nur eine Sendestation vorhanden ist, treten kei-<br />

ne Arbitrierungs-Vorgänge auf. Ein deterministisches Zeitverhalten wird<br />

da<strong>mit</strong> sichergestellt.<br />

3.1.4 <strong>Einbindung</strong> realer Steuergeräte (HIL)<br />

Beim Hardware-in-the-Loop-Verfahren wird ein elektronisches Steuer-<br />

gerät als reale Hardware-Komponente an die Simulation angekoppelt.<br />

Das dem Steuergerät zugeordnete Aggregat wird im Simulationsmodel1<br />

durch eine Blockstruktur gemäß Bild 3.1 abgebildet. Abhängig vom An-<br />

wendungsfall enthält das Simulationsmodell weitere Aggregate-Modelle<br />

bis hin zum vollständigen Fahrzeugmodell, sowie ein Umgebungs-Modell<br />

nach Bild 3.2. Die Implementierung erfolgt unter Verwendung der in<br />

Kapitel 2 vorgestellten Kombination von Software-Werkzeugen.<br />

r<br />

Prototyping-System

a) Gesamtaufbau<br />

r----------------- , r-------------------------------------------------------------------<br />

I I I<br />

I I Fahrer I MMI 1<br />

/ Reale 14<br />

1 I<br />

I <strong>Elektronik</strong> / I i .....................................................................<br />

(Interaktive Bedienung <strong>mit</strong> GUI)<br />

I<br />

k<br />

- I<br />

! +<br />

Iv I<br />

(YR)<br />

I<br />

I<br />

/<br />

I<br />

r--------------------------------------------------------------------.<br />

I<br />

I SBP<br />

b) Fahrzeugmodell<br />

r--------------------------------------------------------------------------<br />

i<br />

I Aggregate-<br />

/<br />

Simulator 1<br />

I<br />

ABS- v ~ ~ g<br />

I<br />

+ I<br />

j<br />

Steuer- I [<br />

I I<br />

i gerät<br />

GI )<br />

UAg)<br />

I I<br />

-<br />

siehe<br />

I ! + +<br />

/ / I*v -<br />

+<br />

b) Signal-<br />

I ii4*A/D Iv , q,<br />

gene-<br />

(YR)<br />

- (T) rator<br />

i / Hardware- Fahrzeug- Hardware-<br />

1 Eingabe modell Ausgabe<br />

i ----------------- l i<br />

(7) I 1 i (Y*R)<br />

I<br />

/ I<br />

Last<br />

I<br />

i<br />

1<br />

I<br />

I I<br />

SBP I<br />

(E) I<br />

+<br />

F"<br />

+<br />

ABS-<br />

Magnet-<br />

Ventile<br />

-t<br />

zv -. F<br />

(Y)<br />

Pneumatik-<br />

Komponenten<br />

Modell<br />

"Bremsanlage" !<br />

I<br />

I<br />

-C<br />

I<br />

I<br />

1<br />

Fzy,<br />

I<br />

I<br />

I<br />

I I<br />

I<br />

-b<br />

F<br />

-<br />

Mechanik<br />

(Radbremsen,<br />

Raddrehung)<br />

+<br />

WR<br />

+<br />

(X)<br />

Rad-<br />

drehzahl-<br />

Sensoren<br />

Bild 3.5: a) HIL-Prüfstarid für ein Nut zfahrzerig- ABC-Steuergerät<br />

b) St,ruktur des Fahrzeugmodells<br />

I<br />

I<br />

----,------------------------------<br />

1<br />

i Aktuator- Komponenten-<br />

(m~)<br />

r-------------------------------------------------------------------------<br />

I<br />

4 weitere Aggregate-Modelle I<br />

I (Fahrzeugdynamik, Reifen etc.)<br />

L--------------------------------------------------------------------------l (r,)<br />

Sensor-<br />

Modell Modelle Modell I<br />

i .......................................................................... j<br />

--+ I<br />

up I<br />

I -<br />

1 SP - 1 +<br />

(r)<br />

I<br />

I<br />

I<br />

!<br />

I<br />

I<br />

+<br />

oR -<br />

(mA)<br />

/ VF<br />

F<br />

I

wesentlich einfacheren Simulator-Aufbau. Ein weiterer Vorteil ist. dass<br />

ein Prüfstands-Betrieb des betreffenden A4ggregats möglich wird. Im Ge-<br />

gensatz zur HIL-Anordnung gemäß Abschnitt 3.1.4 werden bei real vor-<br />

handenen Aggregaten die elektrischen Steuersignale für die Aktuatorik<br />

nicht erfasst. Vielmehr werden mechanische Größen wie Wege, Drehzah-<br />

len und Drücke dynamisch gemessen und in die Simulation eingeleitet.<br />

Sensoren können ebenfalls als reale Teile eingebunden werden, sofern die<br />

entsprechenden Messgrößen realistische Werte annehmen.<br />

Beispiel: ABS <strong>mit</strong> realer Pneumatik<br />

Vorgestellt wird eine im Rahmen dieser Arbeit entwickelte, modifizierte<br />

IJersion der HIL-Anordnung für ABC in Nutzfahrzeugen [119]. In Bild 3.6<br />

a) ist der Aufbau der Simulationsanlage dargestellt3. Die real vorhande-<br />

ne Pneumatik und <strong>Elektronik</strong> (oben) ist <strong>mit</strong> einem Simulationsrechner<br />

(unt,en) verbunden, <strong>mit</strong> den1 eine Fahrzeug-Nachbildung realisiert wird.<br />

Ein Ausschnitt aus der Struktur des verwendeten Simulationsmodells ist<br />

in Bild 3.6 b) abgebildet.<br />

Die Pneumatik besteht zum großen Teil aus Serien-<br />

Fahrzeugkomponenten und ist wie folgt aufgebaut: Ein Vorratsbehälter<br />

liefert die Druckluft zur Versorgung der Bremsanlage. Der LTorratsdruck<br />

wird von einem (nicht gezeichneten) Kompressor auf Ca. 8 bar gehalten.<br />

Das Betriebsbremsventil, <strong>mit</strong> dem der Fahrer im realen Fahrzeug durch<br />

Betätigung des Bremspedals den Bremsdruck in die Radbremsen einsteuert,<br />

wird für jeden Bremskreis durch eine Betriebsbremsventil-<br />

Nachbildung ersetzt, die als Druckregelkreis ausgeführt ist. In der Simulation<br />

wird aus dem vom Fahrer oder einem Testautomatisierungs-<br />

Program~n vorgegebenen Bremspedalweg s ~ der p Druck berechnet, der<br />

am Ausgang des realen Betriebsbremst-entils anliegen würde. Dieser<br />

Druck wird in der Nachbildung durch ein Proportional- Ventil aufgebaut,<br />

das <strong>mit</strong> dem Strom Iip angesteuert wird. Ein Drucksensor meldet den<br />

Istwert pgp an einen im Simulationsmodell implementierten Druckregler<br />

zurück, der eventuelle Abweichungen ausregelt. Der Signalpfad des<br />

Druckregelkreises ist im Bild verstärkt eingezeichnet.<br />

3~ei<br />

der beschriebenen Anlage ist die Pneumatik <strong>mit</strong> separaten Kreisen für 'i'order-<br />

achse und Hinterachse sowie je zwei ABS-'i'entilen und Radbremszylindern pro<br />

Achse aufgebaut. In Bild 3.6 ist zugunsten der Übersichtlichkeit nur ein Zweig für<br />

eine Achse dargestellt. Der Aufbau der weiteren drei Zweige ist identisch.

-----------<br />

Fahrzeugmodell<br />

- .....................<br />

(Ausschnitt)<br />

---------------_-_ ..........................<br />

I<br />

I Aggregate-Modell /<br />

PBP<br />

I Druckregler für die<br />

I<br />

Betriebsbremsventili<br />

SBP<br />

,+ Nachbildung<br />

- "Brernsanlage"<br />

IBP<br />

i<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

Mechanik<br />

I --C<br />

i Pzyi (Radbremsen,<br />

I F Raddrehung)<br />

I .<br />

i I<br />

'-C<br />

+ ABS-<br />

1<br />

W,<br />

Raddrehzahl- SP ;<br />

I<br />

Sensoren<br />

I<br />

I<br />

J<br />

c - - - - - - - - - - ---------------- - - - ~ -----------------------------*<br />

Bild 3.6: a) Hardware-in-t,he-Loop-Simulationsanlage iriit realer Pileumatik<br />

f'ür ABS im Nutzfahrzeug<br />

b) Struktur des irrweiidetrn Fahrzeuginodells (Ausschiiit t )<br />

i +

Diese Anordnung ermöglicht einen automatisierte11 Simulatorbetrieb oh-<br />

ne Bremspedal-Betätigung durch den Anwender. Hier<strong>mit</strong> können z.B.<br />

Dauerprüfungen von ABS-Komponenten anhand reproduzierbarer Fahr-<br />

zyklen durchgeführt werden [120].<br />

Wie im realen Fahrzeug ist in die Zuleitung zu jedem Radbremszylinder<br />

ein ABS-Ventil eingefügt. Die ABS-Ventile sind am Steuergerät ange-<br />

schlossen und bewirken beim ABS-Regelvorgang eine Modulation des<br />

Radbremszylinder-Druckes. Die Zylinder-Kraft wird durch eine Feder<br />

abgestützt, deren Steifigkeit in etwa dem Kraft / Weg-Verhältnis einer<br />

realen Radbremse entspricht.<br />

Der dynamische Luftdruck pz,r im Radbremszylinder wird gemessen<br />

und in das Simulationsmodell eingegeben. Das Komponenten-Modell<br />

Radbremsen und Raddrehung sowie die weiteren Aggregate-Modelle (im<br />

Bild nicht gezeichnet) entsprechen den Ausführungen in Abschnitt 3.1.4.<br />

Auch die Substitution der ABS-Raddrehzahl-Sensorsignale erfolgt<br />

auf gleiche Weise (da das drehende Rad nicht Bestandteil des Prüfstands-<br />

aufbaus ist, können die ABS-Raddrehzahlsensoren nicht als reale Teile<br />

verbaut werden).<br />

Das Fahrzeugrnodell wird unter Verwendung der Verfahrensweise aus<br />

Kapitel 2 <strong>mit</strong> SIhlULINK als Basis-Werkzeug implementiert. Die Be-<br />

wegungsgleichungen zur Beschreibung der Fahrdynamik werden <strong>mit</strong><br />

NEWEUL generiert und gemäß Abschnitt 2.3.5 eingebunden.<br />

3.1.6 <strong>Einbindung</strong> <strong>vernetzter</strong> Steuergeräte<br />

Neuere Fahrzeuge enthalten in der Regel mehr als ein elektronisch ge-<br />

regeltes Aggregat. Eine typische Konfiguration wurde in Bild 1.1 vorge-<br />

stellt. Durch Erweiterung der in Bild 3.5 beispielhaft dargestellten HIL-<br />

Grundstuktur ergibt sich das verallgemeinerte HIL-Blockschaltbild für<br />

vernetzte Steuergeräte nach Bild 3.7.<br />

Kennzeichnend für diese Anordnung ist, dass alle Steuergeräte<br />

SG1 . . . SG, als reale Hardware existieren und über ein reales Daten-<br />

bussystem (CAN) verbunden sind. Bei interaktivem Betrieb ist der Fah-<br />

rer ebenfalls real vorhanden. Er tauscht über eine Mensch-hllaschine-<br />

Schnittstelle (MMI) Daten <strong>mit</strong> der <strong>Elektronik</strong> und <strong>mit</strong> dem Fahrzeug-<br />

modell aus. Dagegen sind alle Aggregate und die Fahrzeug-Umgebung<br />

im Simulationsniodell abgebildet.<br />

Die Zuordnung von Aggregaten zu Steuergeräten ist nicht immer eindeii-

Fahrer I MMI<br />

Bild 3.7: Hardware-in-the-Loop-Verfahren für vernet'zte <strong>Elektronik</strong>

tig. Ein Steuergerät kann auf die Aktuatorik mehrerer .4ggregate einwir-<br />

ken. Ein Beispiel ist die integrierte Motor- und Getriebe-Steuerung des<br />

MCC Smart <strong>mit</strong> Automatisiertem Schaltgetriebe [121]. Häufig empfängt<br />

ein Steuergerät Sensorsignale von mehreren Aggregaten, z.B. die Fahrdy-<br />

namikregelung in Bild 1 .l. Manche Steuergeräte (Anzeigeinstrumente)<br />

besitzen Sensor-Eingange, jedoch keine externen Aktuatoren.<br />

Die Aggregate-Modelle Ahh . . . AMm sind untereinander sowie <strong>mit</strong> dem<br />

Umgebungs-Modell (UM) über mechanische Größen GE und +iA ge-<br />

koppelt, z.B. die Drehzahlen und Drehmoment,e in einem Modell des<br />

Antriebsstranges. Deren Zuordnung erfolgt im Block Signalverteilung.<br />

Ein derartiger Aufbau ist als interaktiver Prüfstand für die gesamte Elek-<br />

tronik eines Fahrzeugs geeignet. Der Aufwand ist relativ hoch, da zahl-<br />

reiche Sensorsignale zu substituieren sind. Dasselbe gilt für die Erfas-<br />

sung der Aktuator-Betätigungen. Kachteilig ist auch, dass die Anlage<br />

erst dann in Betrieb genommen werden kann, wenn alle Steuergeräte<br />

verfügbar sind. Bei der Entwicklung einer neuen Fahrzeug-Baureihe ist<br />

dies in der Regel frühestens ein Jahr vor dem Serienanlauf gegeben, d.h.<br />

zu einem Zeitpunkt, an dem tief greifende Änderungen am <strong>Elektronik</strong>-<br />

Konzept nicht mehr möglich sind. Im folgenden Abschnitt wird ein Weg<br />

zur Vermeidung dieser Nachteile aufgezeigt.<br />

3.1.7 Funktions-Nachbildung (Steuergeräte-Modell)<br />

Eine weitere Möglichkeit zur Berücksichtigung von elektronischen Steu-<br />

ergeräten ist die Nachbildung des Funktionsumfangs in der Simulations-<br />

Software, d.h. die Anfertigung von Steuergeräte-Modellen. Dieses hrge-<br />

hen ist für folgende Szenarien zu empfehlen:<br />

Eine Sirnulationsanlage soll in Betrieb genommen werden, obwohl<br />

nur wenige Steuergeräte real verfügbar sind. Die Funktions- und<br />

Schnittstellen-Spezifikationen der fehlenden Steuergeräte liegen be-<br />

reits vor. In diesem Fall ist eine detaillierte Abbildung der fehlen-<br />

den Steuergeräte in der Simulation anzustreben.<br />

Dies gilt auch, wenn ein Steuergerät unter Verwendung des Rapid-<br />

Prototyping-Verfahrens entwickelt wird. Durch Implementierung<br />

auf einem geeigneten Rechner dient das Steuergeräte-hlodell zu-<br />

gleich als Software-Prototyp und kann im Fahrversuch irnter Ver-<br />

wendung realer Aggregate erprobt und optimiert werden.

Die HIL-Eiribindung eines realer1 Steuergeräts ist zu aufwändig.<br />

Für die gegebene Anwendung reicht eirie vereinfachte Darstellurig<br />

aus. Die Nachbildung kann auf die relevantJen Funktionsanteile be-<br />

schränkt werden.<br />

Ein Steuergerät dient ausschließlich als Sender von CAN-<br />

Nachrichten, deren Inhalt von geringer Bedeutung für die gegebene<br />

L~nwendurig ist. Das Ausbleiben der Nachrichten verursaclitjedoch<br />

Fehlermeldungen roll der1 realen Steuergeräten. Dir Naclibildung<br />

der Steuergeräte erfolgt in stark vereinfachter Form und<br />

kann arischaulich als CA~-Durnrn~g~ bezeichiiet werden.<br />

I<br />

I<br />

j Botschafts-<br />

Decodierung<br />

1 Fehler- und<br />

!<br />

I<br />

+ r i<br />

Bild 3.8: h4odellstrukur für ein elektronisches Steuergerät init CAN-<br />

Kominunikation (SGM)<br />

Ein S teuergeräte-Modell (SGRI) wird unter konibinierter Iern~endung<br />

der iri Abschnitt 2.3 ausgewählten CACE- und FSM-B'erkzeuge angefer-<br />

tigt. Insbesondere die Verweridung von Zustandsgraphen ist bei diesen1<br />

hlodelltyp sehr effizient. Das SGh3 wird zu einen1 Bestandteil des Si-<br />

mulationsmodells und kann sowohl in der Nicht-Echtzeit-Siniulation als<br />

auch für die Echtzeitsimiilation verwendet werden.<br />

hlodelliert wird das ITerhalteii des Steuergerätes bezüglich der Ibhängigkeit<br />

der .Ausgarigssignale von den Eirigarigssignalen. Auf eiri~ (ietaillierte<br />

Simulatiori der Hardware wird verzichtet.<br />

'zu deutscli: CA5-Schnuller<br />

SR k<br />

-t<br />

ER<br />

I<br />

I +<br />

I<br />

I<br />

I<br />

I<br />

I<br />

Timeout-<br />

Erkennung<br />

Regel-<br />

algo-<br />

rithmus<br />

85<br />

s T F<br />

Botschafts- [<br />

Codierung<br />

I<br />

Er<strong>mit</strong>tlung<br />

der Sende-<br />

zeitpunkte<br />

L----------------------------------------------------------------------------j<br />

1<br />

j I<br />

I<br />

I<br />

I<br />

B ,<br />

I<br />

I

In Bild 3.8 ist die Blockstruktur eines SGhl dargestellt. Dem SGM wer-<br />

den dieselben CAN-Nachrichten zugeführt, die das reale Steuergerät<br />

im CAN-Netzwerk empfangen würde. Im CAN-Decoder werden die ent-<br />

haltenen Signale decodiert und als Vektor & an den Regelalgorithmus<br />

übergeben. Mit jeder Nachricht wird auch der Empfangszeitpunkt über-<br />

tragen. Hier<strong>mit</strong> wird für zyklische Nachrichten das Ausbleiben über einen<br />

festgelegeten Zeitraum hinaus detektiert ( Timeout). Zusätzlich wird die<br />

Gültigkeit und der Wertebereich jedes Signals überprüft. Erkannte Feh-<br />

ler werden durch den Vektor ER signalisiert.<br />

Nach der Ierarbeitung gibt der Regelalgorithrnus die Sendesignale 6<br />

aus. Aus diesen Signalen werden im CAN-Encoder die codierten Sen-<br />

denachrichten iQT gebildet. Ziisätzlich wird für jede Nachricht eine Sen-<br />

deanforderung generiert, entweder jeweils nach Ablauf einer vorgegebe-<br />

nen Zykluszeit oder beim Eintreten eines Ereignisses, z.B. der Änderung<br />

eines bestimmten Signals.<br />

Die Vektoren F und yR bilden die Schnittstellen zu den Sensoren und<br />

Aktuatoren von Aggregate-Modellen bzw. real vorhandenen Aggregaten,<br />

siehe Bild 3.1. Über CF und fsG findet der Datenaustausch <strong>mit</strong> dem<br />

Fahrer oder einem Fahrermodell statt, siehe Bild 3.3.<br />

Ein Beispiel zur Implementierung eines SGhl <strong>mit</strong> dem Software-<br />

Werkzeug STATEFLOJV findet sich in Abschnitt 4.4.2.<br />

3.2 Behandlung von CAN-Netzwerken<br />

Die vorgestellten Modellierungs-Elemente und die <strong>Einbindung</strong> realer<br />

Steuergeräte bzw. Aggregate gestatten einen gemischten Aufbau von<br />

Echtzeit-Simulationsanlagen <strong>mit</strong> realen und simulierten Teilsystemen.<br />

Die einheitliche Schnittstellen-Struktur vereinfacht den Austausch simu-<br />

lierter und realer Teile. Da<strong>mit</strong> kann eine Anlage schneller an aktuelle<br />

Erfordernisse angepasst werden als bei „unstrukturiertemU Vorgehen.<br />

Zunächst wird die Kombination mehrerer SGM behandelt. Anschließend<br />

wird die Kombination von SGM und realen Steuergeräten betrachtet.<br />

Zugunsten der Über~icht~lichkeit sind die Schnittstellen zur Anbindung<br />

von Aggregaten in den folgenden Grafiken nicht mehr eingezeichnet.

+<br />

I+--+<br />

1<br />

FI<br />

F,<br />

I+-+ F,<br />

Simulationsmodell<br />

3 -t<br />

MR,l<br />

-<br />

MT,,<br />

+ SGM,<br />

b<br />

- + * +<br />

MR,2<br />

I<br />

I "virtueller" CAN-Bus I<br />

Bild 3.9: Vollständige Si~nulat~ion eines CAN-Netzwerks<br />

3.2.1 Simulation des gesamten Netzwerks<br />

-+<br />

SGM,<br />

+ -C<br />

MR,n MT>"<br />

+ SGM, ---t<br />

Modell der<br />

Busvergabe<br />

und des Zeit-<br />

verhaltens<br />

Bei der *Anordnung nach Bild 3.9 wird das gesamte CAN-Netzwerk im<br />

Simulationsniodell abgebildet. Die von den hfodellen SGhli . . . SGM„<br />

generierten CAN-Nachrichten werden in einer1 Simulationsblock einge-<br />

geben, der die Arbitrierung und das Zeitverhalten der Datenübertra-<br />

gung nachbildet. Die Aiisil-ahl der jeweiligen Empfangsnachrichten er-<br />

folgt durch die Filter Fl . . . F„ .<br />

Die hlodellieriing des Bus-I7erhaltens ist sehr aufwändig, iiisbesoiide-<br />

re bei Berücksichtigiirig von Sende~viederholuiigeri aufgrund vor1 cber-<br />

tragungsfehlern. Sindell gibt ein Verfahren zur Analyse des Worst-<br />

Case-Zeit verhaltens von priorität sgesteuerten Datenkommunikations-<br />

Systemen an [122]. Da<strong>mit</strong> ist eine Vorhersage der maximalen Antik-ort-<br />

reiten von Nachrichten <strong>mit</strong> gegebener Länge, Priorität und Zykluszeit<br />

in einen1 CAN-Netzwerk möglich [76]. In [I231 wird die Optimierung der<br />

Prioritätsvergabe für CAN-Netzwerke untersucht.<br />

In der vorliegenden Arbeit wird die Bussystem-Simulation nicht bet rach-<br />

tet: da der Aufwand zur Erstelliing eines ausreichend detaillierten, echt-<br />

zeitfähigen Bus-YIodells unangemessen hoch erscheint.<br />

F<br />

Y<br />

:

3.2.2 Simulation der Steuergeräte, realer CAN-Bus<br />

Die Modellierung des Bus-Verhaltens wird vermieden, indem der CAN-<br />

Bus als reale Hardware eingebunden wird.<br />

Die von den SGM erzeugten CAK-Nachrichten werden unter Verwen-<br />

dung von CAN-Schnittstellen (im Folgenden <strong>mit</strong> INTF bezeichnet) auf<br />

dem realen Bus gesendet und von anderen SGM empfangen. Zwei unter-<br />

schiedliche Konfigurationen werden näher betrachtet.<br />

Bei der Konfiguration in Bild 3.10 a) wird jedem Steuergeräte-hlodell<br />

SGhll . . . SGhI„ eine eigene CAN-Schnittstelle INTFl . . . INTF, zu-<br />

geordnet, welche die generierten Nachrichten auf dem realen Bus aus-<br />

sendet und Nachrichten von anderen SGhl empfängt. Diese Anordnung<br />

bildet die Hardware eines realen Netzwerks <strong>mit</strong> sehr guter Näherung<br />

ab und ermöglicht realistische Arbitrierungs-Vorgänge. Sie ist zu emp-<br />

fehlen, wenn Buslast-Spitzen bei der Initialisierung des Netzwerks oder<br />

die Elektromagnetische Verträglichkeit (EhlV) Gegenstand der Untersu-<br />

chung sind. Nachteilig ist der Aufwand zur Bereitstellung der zahlreichen<br />

C AN-Schnittst ellen bei umfangreichen Netzwerken.<br />

Die Variante nach Bild 3.10 b) erfordert nur zwei CAN-Schnittstellen5.<br />

Über die Sende-Schnittstelle INTET werden die Nachrichten aller SGM<br />

gesendet. Da INTFT jeweils nur eine Nachricht senden kann, wird die<br />

Reihenfolge von einem Scheduler bestimmt. Da<strong>mit</strong> entfällt die bitweise<br />

Arbitrierung. In dieser Arbeit wird ein einfacher Scheduler verwendet,<br />

der die Sendenachrichten in der Reihenfolge ihrer Prioritäten ausgibt,<br />

d.h. Nachrichten <strong>mit</strong> niedriger Kennung (Identzfier) werden zuerst ge-<br />

sendet, vgl. Abschnitt 1.2.5.<br />

Der Empfang aller Nachrichten erfolgt durch die Empfangs-Schnittstelle<br />

INTFR. Die Filter F1 . . . F, führen jedem SGI\I die benötigten Nach-<br />

richten zu.<br />

Diese Konfiguration kommt zur Anwendung, wenn die Einhaltung maxi-<br />

maler Antwortzeiten für alle Nachrichten im Netzwerk sichergestellt ist<br />

und das Zusammenwirken der Funktionsumfänge mehrerer St,euergeräte<br />

untersucht werden soll. Die in Kapitel 4 beschriebene Anlage wird auf<br />

diese Weise realisiert.<br />

In Bild 3.11 ist der Aufbau einer CAN-Schnittstelle (INTF) dargestellt.<br />

Diese besteht aus der Gerät'etreiber-Software zum Senderi und Empfan-<br />

5~ie<br />

Verwendung einer einzelnen Schnittstelle ist nicht möglich, da die gängigen<br />

CAN-Controller eine Nachricht nicht zugleich senden und empfangen können.

Simulationsmodell<br />

-C + Schnittstellen<br />

MR, I<br />

F SGM,<br />

MT, I<br />

-+<br />

j INTF, -<br />

realer<br />

-.L --C<br />

MR,2 M,, CAN-<br />

SGM, A b P BUS<br />

i INTF2-I<br />

:<br />

- F,<br />

Simulationsmodell<br />

4 --t<br />

-<br />

MR.l<br />

MT,,<br />

-<br />

i<br />

:<br />

1 CAN-<br />

- F2<br />

+<br />

SGM,<br />

+<br />

3 i<br />

U :<br />

SGM, b I Schnittstellen<br />

MR,2 M,, I INTFT -<br />

--t +<br />

a, ;<br />

I: :<br />

0 i<br />

V, ;<br />

MR,n 'T,<br />

SGM, b :<br />

- i INTFR-<br />

:<br />

realer<br />

CAN-<br />

Bus<br />

Bild 3.10: Zwei Varianten zur Simulation von S teuergeräte-Netzn-erken<br />

unter Verwendung des realen CAN-Bussysterris

i Gerätetreiber Physikalische Schnittstelle i<br />

(~oftware) (Hardware)<br />

i :<br />

Senden<br />

Protokoll-<br />

Controller<br />

Bild 3.11: Struktur einer C AN-Schnittstelle<br />

Trans- CAN-<br />

gen von Nachrichten, einem CdN-Protokoll-Controller gemäß ISO 11898<br />

und einem CAN-Transceiver zur Ankopplung an das Busmedium.<br />

3.2.3 Simulation von Fahrzeugen <strong>mit</strong> mehreren<br />

CAN-Netzwerken<br />

Viele Kraftfahrzeuge enthalten mehrere CAN-Netzwerke. Im PKW wird<br />

häufig ein High-Speed-CAN für den Antriebsstrang und ein Low-Speed-<br />

CAN für den Innenraum eingesetzt. Einige Nutzfahrzeuge enthalten<br />

mehr als fünf CLAN-Busse <strong>mit</strong> hierarchischer Strukturierung [124].<br />

In vielen Fällen werden ausgewählte Nachrichten von einem CAN-<br />

Netzwerk an ein anderes weitergegeben, z.B. Diagnose-Informationen.<br />

Dieser Datenaustausch wird innerhalb eines Steuergerätes realisiert. das<br />

an mehrere Netzwerke angeschlossen ist und daher mehr als eine physi-<br />

kalische CAN-Schnittstelle besitzt. Ein solches Steuergerät wird in der<br />

Simulation durch eine Struktur gemäß Bild 3.12 abgebildet. ,4ls Erweite-<br />

rung von Bild 3.8 ist jedem CAN-Bus (A: B, . . . ) ein CAN- Encoder und<br />

ein CAN-Decoder zugeordnet, deren Funktion jeweils den Ausführungen<br />

in Abschnitt 3.1.7 entspricht.<br />

Unter Verwendung dieses erweiterten Steuergeräte-Modells und der<br />

in Abschnitt 3.2.2 vorgestellten Varianten zur Abbildung von CAN-<br />

Netzwerken können auch komplexe <strong>Elektronik</strong>-Konfigurationen <strong>mit</strong> mehreren<br />

CAN-Bussen in der Sim~lat~ion dargestellt werden.<br />

Des Weiteren ist ein gemischter Betrieb von Steuergeräte-Rlodellen und<br />

realen Steuergeräten niöglicli. Eine beispielhafte Konfiguration <strong>mit</strong> zwei

-t<br />

MR,A f+<br />

--t<br />

R B<br />

I<br />

I<br />

I<br />

I<br />

CAN- CAN-<br />

Decoder ,<br />

Encoder<br />

A<br />

A<br />

-C I<br />

-<br />

r i ,<br />

I<br />

I<br />

CAN-<br />

Decoder<br />

B<br />

Bild 3.12: Steuergeräte-hfodell <strong>mit</strong> niehreren CAN-Schnit tstellen<br />

................................................. ----<br />

I<br />

I<br />

CAN-Bussen ist in Bild 3.13 angegeben. Diese Konfiguration stellt eine<br />

Erweiterung von Bild 3.10 b) dar. Das Netzwerk C.4Na besteht aus<br />

einem simulierten Steuergerät SGhIi und einem realen Steuergerät SG3.<br />

SGM2 ist gemäß Bild 3.12 ausgeführt und an beide CAN-Netzwerke<br />

angeschlossen. C ANs umfasst zwei reale Steuergeräte (SG4 und SG 5).<br />

Eine derartiger, modularer Aufbau von Simulationsanlagen ermöglicht<br />

deren Erweiterung im Verlauf des Entwicklungsprozesses für ein neu-<br />

es Kraftfahrzeug: indem z.B. die St,euergeräte-Modelle sukzessive durch<br />

reale Steuergeräte ersetzt werden, sobald diese verfügbar sind.<br />

3.2.4 Automatisierte Implementierung der<br />

CAN-Kommunikat ion in der Simulation<br />

Eine wiederkehrende Aufgabe bei der Implementierung von St,euer-<br />

gerätje-hlodellen gemäß Bild 3.8 bzw. Bild 3.12 ist die Programmierung<br />

der <strong>mit</strong> CAN-Decoder und CAN-Encoder bezeichneten Funktionsblöcke.<br />

Der CAN-Encoder bewirkt die Umsetzung von physikalischen Größen<br />

(z.B. Drehzahlen und Temperaturen), logischen Werten (z.B. Schalter<br />

ein/aus) oder anderen Dat,en in C AN-Nachrichten, die auf dem Bus<br />

gesendet werden. In der Regel werden jeweils mehrere Größen in ei-<br />

ner CAN-Nachricht zusammengefasst. Hierzu ist eine Codierung not-<br />

wendig, d.h. eine Abbildung der physikalischen Größen auf ganzzahlige<br />

Werte (Binärwerte) <strong>mit</strong> einer vom Anwender festgelegten Auflösung.<br />

Dazu gehört auch die Zusamnienfügung dieser Binärwerte zu CAN-<br />

Nachrichten <strong>mit</strong> maximal 8 Byte Länge, wobei die Anordnung ebenfalls<br />

vom Anwender bestimmt wird.<br />

Umgekehrt werden diese Da'ten irn CAN-Decoder aus empfangenen<br />

Nachrichten zurückgem-onnen (Decodierung) .<br />

In umfangreichen CAN-Netzwerken werden in der Regel zahlreiche CAN-<br />

Nachrichten <strong>mit</strong> insgesamt mehreren hundert Einzelsignalen übertragen.<br />

Die manuelle Erstellung von Programmcode zur Codierung und Decodie-<br />

rung von CAN-Nachrichten ist zeitraubend und fehleranfällig. Da dieser<br />

Programmcode stets die gleiche Struktur aufweist, wurde im Rahmen<br />

dieser Arbeit ein Software-Werzeug <strong>mit</strong> der Bezeichnung CA4NULINK<br />

entwickelt, das zur Automatisierung dieser Aufgabe dient 11251.<br />

Die Beschreibung eines CAN-Netzwerks erfolgt zunächst <strong>mit</strong> dem kom-<br />

merziellen Software-J17erkzeug CANDB, das in der Kfz-Industrie weit<br />

verbreitet ist. Irn Editor dieses Programms werden alle relevanten Para-

meter definiert, z.B. der Sender und die Kennung von CXN-Nachrichten.<br />

Auch die Parameter aller enthaltenen Größen, z.B. deren Vertebereich,<br />

Auflösung und hllaßeinheit , werden eingegeben. Zusätzlich werden die<br />

liorschriften zur Umrechnung von physikalischen Größen in deren binäre<br />

Repräsentation innerhalb einer CAN-Nachricht angebeben. Alle Infor-<br />

mationen werden in einer Datenbank gespeichert.<br />

Diese Datenbank wird von CANULINK eingelesen. Nach einer Prüfung<br />

der enthaltenen Beschreibungsdaten auf eventuelle Fehler wird automatisch<br />

iZI\TSI-C-Pr~grammcode erzeugt, der die Codierung und Decodierung<br />

von CAN-Nachrichten bewirkt. Der Code entspricht den in Abschnitt<br />

2.2.1 aufgestellten Regeln, ist also portabel. Er kann für Nicht-<br />

Echtzeit- Anwendungen, z.B . die Auswertung von aufgczeiclmetcrl CA4N-<br />

Daten aus Falirversuchen verwendet werden. ist aber auch fiir Echtzeit-<br />

Sirnulat ioneli geeignet.<br />

In einem weiteren Schritt erzeugt CANULINK ein SIMULINK-31odell.<br />

das für alle vorhandenen CAN-Nachrichten die erwähnten Funktions-<br />

blöcke CAN-Decoder und CAN-Encoder enthält. Der generierte C-Code<br />

11-ird darin ailtomatisch eingebunden. Die erzeugten Strukturen können<br />

anschließend zrim Aufbau von Steuergeräte-Modellen verwendet werden.

4 Ein Fahrsimulator für ASG im<br />

Nutzfahrzeug<br />

Bild 4.1: Eirisatz des Fahrsimulators in der Schulung<br />

Vorgestellt wird ein Fahrsimulator zur Schulung von LKW-Fahrern<br />

im Umgang <strong>mit</strong> dem elektronischen Antriebsstrang-Management eines<br />

schweren Nutzfahrzeugs. Bild 4.1 zeigt den Fahrsimulator im Schulungs-<br />

einsatz. Zur Gewährleistung eines realistischen Simulator-Betriebs wird<br />

die Anlage unter Verwendung serienmäßiger elektronischer Steuergeräte<br />

aufgebaut, die im Hardware-in-the-Loop-Modus betrieben werden. Das<br />

Automatisierte Schaltgetriebe (ASG) und die Kupplungsanlage sind<br />

ebenfalls als reale Komponenten integriert. Eirie Anlage <strong>mit</strong> vergleich-<br />

barer Konzeption ist aus der Literatur nicht bekannt.

4.1 Einleitung<br />

4.1.1 Zielsetzung und Anforderungen<br />

Für die Schulung werden folgende Ziele definiert:<br />

Kennenlernen der Alensch-Ilaschi~ie-Schnittstelle des Fahrzeugs,<br />

gefahrloses Erlernen der für viele Fahrer ungewohnten Bedienung<br />

der Getriebe-Steuerung in kurzer Zeit,<br />

Niitzung der <strong>Elektronik</strong>-Cntcrstützurig fiir einen vcrbrauchs- lind<br />

ernissions-optimierten Fahrbetrieb und<br />

Demonstration von Sonder- und Notfunktionen, die im Fahrbetrieb<br />

nur selten auftreten.<br />

Akzeptanz und Erfolg der Schulungen hängen un<strong>mit</strong>telbar von der Qualität<br />

der Lehr<strong>mit</strong>tel ab. lTon LKW-Fahrern, die durch praktische Erfahrungen<br />

geprägt sind, werden signifikante Unterschiede zwischen den<br />

Mensch-hlaschine-Schnittstellen im Simulator und im realen Fahrzeug<br />

nicht akzeptiert. Der Fahrsimulator wird daher in Form eines LKW-<br />

Fahrerhauses unter ierwendung serienniäßiger Bedienelemente aufgebaut.<br />

Zur Rückmeldung des Bet riebczutandes werden optische, akustische<br />

und haptische Informationen bereitgestellt. Ebenso wichtig ist ein<br />

realistisches dj-nanlisches lTerhalten des Simulators, da die Fahrer über<br />

Erfahrungswerte, z.B. für das Bcscllleunigungsv~rmtjgen eines Fahrzeugs.<br />

verfügen.<br />

Unbedingt zu vermeiden ist ein \:ersagen der ,4nlage wiihrend Schu-<br />

lungssitzungen, da dies von den Teilnehmern <strong>mit</strong> einer mangelnden<br />

Zuverlässigkeit des dargestellten Fahrzeugs oder dessen elektronischer<br />

Steuerung assoziiert würde.<br />

Im Schulungsbetrieb wird die Anlage von Instruktoren bedient, die zwar<br />

detaillierte technische Kenntnisse des dargestellten Fahrzeugs besitzen,<br />

jedoch wenig Erfahrung <strong>mit</strong> Siniulationen haben. Es ist daher zu for-<br />

dern, dass die Anlage ohne EDV-Kenntnisse in Betrieb genommexi n-er-<br />

den kann (,, Ein-Knopf-Gerät .' ) und dass verschiedene Falirsit iiat ionen<br />

auf einfache Weise vorgegeben werden kiinnen.

4.2 Funktionsweise der Antriebs-Steuerung<br />

Das betrachtete Fahrzeug wird in mehreren Ausbaustufen der Antriebs-<br />

Steuerung <strong>mit</strong> unterschiedlichem Automatisierungsgrad angeboten [126].<br />

4.2. I Halbautomatische Steuerung<br />

Bei der hiarkteinführung des Fahrzeugs im Jahr 1996 war zunächst eine<br />

halbautomatische FTersion (,,Telligent-Schaltung") verfügbar. 1998 wird<br />

eine erste Version des Fahrsimulators vorgestellt [I271 uiid im Schulungs-<br />

betrieb eingesetzt.<br />

Bedienkonzept und Funktionsweise der elektronisch-pneumatischen<br />

Getriebe-Betätigung werden in [128, 1291 dargelegt. Der Fahrer erteilt<br />

über ein Gebergerät Befehle zur Hoch- oder Rückschaltung, wobei eine<br />

Gangvorwahl möglich ist. Das Getriebe-Steuergerät er<strong>mit</strong>telt aus dem<br />

aktuellen Betriebszustand von Fahrzeug und Motor einen geeigneten Xn-<br />

schlussgang. Bei Betätigung der Kupplung durch den Fahrer wird der<br />

Schalt vor gang eingeleitet. Durch Ansteuerung der Getriebe- Aktuatorik,<br />

bestehend aus Magnetventilen und Pneumatik-Zylindern, werden alle<br />

Getriebe-Gruppen (siehe Abschnitt 4.3.2) vom Steuergerät geschaltet.<br />

Die Rückmeldung des Schaltzustandes an das Steuergerät erfolgt über<br />

Wegsensoren. Zusätzlich werden die Drehzahlen der JTorgelegewelle und<br />

der Abtriebswelle sensiert. Die Trockenkupplung wird vom Fahrer über<br />

das Kupplungspedal <strong>mit</strong>tels hydraulisch-pneumatischer Kraftübertra-<br />

gung betätigt. Mit einem Sensor erfasst das Getriebe-Steuergerät den<br />

Kupplungs- Ausrückweg.<br />

4.2.2 Automatisiertes Schaltgetriebe (ASG)<br />

Aufgrund des guten \%Tirkungsgrades bei geringen Kosten hat das ASG<br />

bei schweren Nutzfahrzeugen erhebliche Bedeutung erlangt [130, 1311.<br />

Bei der ASG-Variante des betrachteten Fahrzeugs (:,Telligent-Schalt-<br />

automatik") sind die Schaltvorgänge vollständig automatisiert. Der An-<br />

triebsstrang und die Regelungsstrategie werden in [I321 ausführlich be-<br />

schrieben. Eine kurze Zusammenfassung erfolgt anhand von Bild 4.2.<br />

Ein Steuergerät Fahrregelung (FR) koordiniert die ,4ntriebs- und Brems-<br />

funktionen unter Berücksichtigung der Stellung des elektronischen Fahr-<br />

pedals und weiterer Fahrereingaben. Das Getriebe-Steuergerät (GS) und

Bild 4.2: Aufbaii des Antriebsstranges beim betrachteten Nutzfahrzeug<br />

rnit ;\utornatisiertem Srlialtgetriebe. Quelle: [I321<br />

die elektro-pneumatisclie Getriebe-Betätigung entsprechen der halbaut,o-<br />

mat ischeri Version.<br />

Ein zusätzlirlies Kupplungs-Steuergerät (KS) führt <strong>mit</strong> Hilfe eines<br />

elektrisch-hydraulischen Stellglieds (KB) während der Infalir- und<br />

Schalt\-orgänge eine Lageregelung der Kupplung durch. Der Ikrbren-<br />

nungsmotor wird hierbei durch Vorgaben an das Motor-Steuergerät<br />

(?IR) <strong>mit</strong> Drehzahlregelung und hIornentenbegrenzung betrieben. Die<br />

mechanische Ausrückung der Kupplung erfolgt über einen hydraulisch-<br />

pneumatischen Verstärker. Ein thermisches Modell im I

parameter, insbesondere die Fahrzeugmasse und die Fahrbahnsteigung.<br />

Unter Berücksichtigung des Fahrerwunsches wird ein geeigneter Gang<br />

er<strong>mit</strong>telt und gegebenenfalls eine Schaltung ausgelöst.<br />

Als Rückfallebene bei Störungen der <strong>Elektronik</strong> ist ein ausklappbares<br />

Kupplungs-Notpedal vorhanden, das eine manuelle Betätigung <strong>mit</strong> hy-<br />

draulischer Kraftübertragung ermöglicht. Der Notbetrieb entspricht der<br />

oben beschriebenen Halbautomatik.<br />

Am Getriebeausgang ist eine hydrodynamische Dauerbremse (Retar-<br />

der) angebaut, die von einem eigenen Steuergerät (RS) in Abhängigkeit<br />

der Retarder-Hebelstellung und anderer Einflussgrößen angesteuert wird.<br />

Auch die elektro-pneumatische Bremsanlage wird von einem Brenisen-<br />

Steuergerät (BS) elektronisch geregelt (siehe auch Abschnitt 4.4.7).<br />

Der Datenaustausch zwischen den <strong>Elektronik</strong>-Komponenten erfolgt über<br />

ein hierarchisch strukturiertes Datenbus-System, das den übergeordne-<br />

ten Fahrzeug-CAN-Bus und weitere CAN-Busse für einzelne Aggregate<br />

wie Motor, Kupplung und Bremse umfasst.<br />

4.3 Konzeption und Aufbau<br />

Im Fahrsimulator ist der Funktionsumfang der Antriebs-Steuerung für<br />

die ASG-Variante des Fahrzeugs vollständig zu implementieren. Insbe-<br />

sondere müssen folgende Fahrfunktionen im Simulator realistisch de-<br />

monstrierbar sein:<br />

Anfahren und Anhalten bei Vorwärts- und Rückwärtsfalirt,<br />

Automatische Hoch- und Rückschaltungen sowie manuelle Schalt-<br />

eingriffe in der Ebene, an Steigungen und im Gefälle,<br />

Bremsungen <strong>mit</strong> der Betriebs- und Feststellbremse,<br />

Funktion der Dauerbremsen (Motorbremse und Retarder),<br />

Tempomat- und Geschwindigkeitsbegrenzer-Funktionen,<br />

Notfunktionen der Kupplung und des Getriebes bei <strong>Elektronik</strong>-<br />

Fehlern.

Zur Erreichung dieses Ziels rniissen alle in Bild 1.2 dargestellten Korn-<br />

ponenten des Antriebsstranges sowie die Fallrzeug-Längsdynainik in der<br />

Simulation abgebildet werden1.<br />

Theoretisch kann jede Komponente entweder als reale Hardware oder<br />

als Software-Nachbildung in den Fahr~imulat~or eingebunden werden. Die<br />

verschiedenen Verfahren wurden in Abschnitt 3.1 vorgestellt. L4iisgehend<br />

von der Konfiguration des realen Antriebs (Bild 4.2) wird zunächst eine<br />

geeignete Kombination von realen und simulierten Komponenten er<strong>mit</strong>telt.<br />

Die Bewertung erfolgt unter den Aspekten hlachbarkeit. Realitätsnähe<br />

lind Aufwand.<br />

4.3.1 Darstellung des Verbrennungsmotors<br />

Der Einbau eines realen Verbrerinungsniotors in den Fahrsinlulator schei-<br />

det aufgrund der Baugröße, der Geräuschentwicklung und der Emissio-<br />

nen aus. Der 1Iotor und das Motor-Steuergerät (R?R) werde11 im Simu-<br />

lationsmodell abgebildet (siehe Abschnitt 4.4.1).<br />

4.3.2 Darstellung von Kupplung und Getriebe<br />

Zur Darstellung der Kupplung und des Getriebes sowie der zugeordneten<br />

elektronischen Steuergeräte und Aktuatoren im Fahrsinlulator existieren<br />

inehrere Alöglichkeiten:<br />

Eine Nachbildung des Kupplungs-Steuergerätes (KS) und des Getriebe-<br />

Steuergerätes (GS) in der Siinulations-Software kommt airfgrund der um-<br />

fangreichen und korriplexen Funktionen nicht iii Betracht. Diese Struer-<br />

geräte niüssen als reale Hardware integriert werden.<br />

Auch der Einbau des realen Getriebes erscheint aus zwei Grüridcn not-<br />

wendig und sinnvoll:<br />

Eine elektronische Nachbildung der zahlreichen Wegsensoren des<br />

betrachteten Getriebes wäre sehr aufwändig.<br />

Die bei Betätigung der pneumatisch-mechanischen Getriebehktuatorik<br />

entstehenden Schaltgeräusche stellen i~n Fahrsirnulat or<br />

eine wichtige ak~st~ische Rückrneldung für den Fahrer dar.<br />

i~nit<br />

Ausnahme der Ni\.eau-Regulierung (NR). welche für die A4ntriebsfunktioneri<br />

riiclit von Bedeutung ist.

Unter diesen Rahmenbedingungen werden zwei Aufbau-Varianten unter-<br />

sucht und bewertet:<br />

Variante 1: Reales Getriebe <strong>mit</strong> zwei Elektroantrieben<br />

-<br />

E oll<br />

Simulationsrechner<br />

I I<br />

MEd,lirn Steuergerät (KS) Steuergerät (GS)<br />

r--+--,<br />

I I / Split- Haupt- Range- 1<br />

i I j Gruppe gruppe Gruppe 1<br />

Servo-<br />

Servoantrieb<br />

Kupplung Getriebe antrieb<br />

Bild 4.3: Betrieb des Getriebes <strong>mit</strong> realen Drehzahlen<br />

Die Trockenkupplung und das Getriebe werden <strong>mit</strong>samt der elektro-<br />

pneumatischen Aktuatorik und der Sensorik im Fahrsimulator ver-<br />

baut. Die Ansteuerung erfolgt durch das Kupplungs- bzw. Getriebe-<br />

Steuergerät, die ebenfalls als reale Komponenten vorhanden sind,<br />

Bild 4.3.<br />

Der Verbrennungsmotor wird durch einen elektrischen Servoantrieb (MI)<br />

ersetzt. Ein weiterer Elektroantrieb (M2) ist am Getriebearusgang mon-<br />

tiert. Er bildet die von der Fahrgeschwindigkeit abhängige Abtriebs-<br />

Drehzahl nach.<br />

Bei dieser Konfiguration werden Kupplung und Getriebe bei realisti-<br />

schen Drehzahlen betrieben. Die Kupplung kann betätigt und das Ge-<br />

triebe geschaltet werden. Dies hat den Vorteil, dass alle in Abschnitt<br />

4.2.1 erwähnten Drehzahl- und Wegsensor-Signale plausibel sind, d.h.,<br />

es ist keine elektronische Substitiition von Sensorsignalen erforderlirli.

Auch die fehlerfreie F~nkt~ion der Kupplungs- und Getriebe-Aktuatoren<br />

ist ge~vtrährleistet .<br />

Das Getriebe ist als 16-Gang-s yrichrongetriebe iri Vorgelege-B auweise<br />

ausgeführt urid besteht aus drei Schaltgruppen [133]:<br />

Bezeichnung<br />

Split-Gruppe<br />

Eigenschaften<br />

Zweigang-hrschaltgruppe <strong>mit</strong> geringer Spreizung<br />

Haupt'gruppe e r ITorwärtsgäiige <strong>mit</strong> direktem Gang und<br />

I Schnellgang, ein Rückwärtsgang<br />

I Range- / Znreigaiig-Nachschaltgruppe <strong>mit</strong> hoher Spreizung, 1<br />

I Gruppe I ausgeführt als zuschaltbarer Planetensatz 1<br />

Die Drehzahlen wLt, an der Kupplung und w ~ am a Getriebeausgang<br />

werden in der Simulation berechnet und den Steuereinheiten der bei-<br />

den Elektro-Antriebe als Sollwerte LJE~,+~~L bzw. W ~ 2 , ~ ~ l l<br />

zugeführt. Die<br />

Drehzahlregelung selbst erfolgt innerhalb dieser Steuereinheiten. Zusätz-<br />

lich können Drehmoment-Grenzwerte dfEl,lim bzw. für beide<br />

Antriebe vorgegeben werden. Hierbei sind folgende Betriebszustände zu<br />

unterscheiden:<br />

1. I

I Simulationsrechner I<br />

- Getriebe-<br />

Steuergerät (GS)<br />

etätigungs- Lastnach - Elektro-<br />

zylinder - bildung motor Getriebe<br />

Bild 4.4: Betrieb des real vorhandenen Getriebes bei konstanter Dreh-<br />

zahl und Substitution der Drehzahlsensor-Signale<br />

Variante 2: Reales Getriebe, Betrieb <strong>mit</strong> konstanter Drehzahl<br />

Auch bei der in Bild 4.4 dargestellten Aufbauvariante wird da,s reale Getriebe<br />

einschließlich Steuergerät, Schalt-Aktuatorik und Wegsensorik im<br />

Fahrsimulator eingebaut. Gegenüber Variante 1 entfallen jedoch die beiden<br />

Servoantriebe. Lediglich am Getriebeeingmg wird ein kleiner Elektromot'or<br />

angebaut, der das Getriebe <strong>mit</strong> kon~t~anter, geringer Drehzahl<br />

w c 0 ~ bewegt. Dadurch kann das Getriebe ohne mechanische Probleme<br />

geschaltet werden.<br />

Der jeweilige Schaltzustand der verschiedenen Getriebe-Gruppen wird<br />

vom Getriebe-Steuergerät erfasst und an ein Simulationsmodell der<br />

Getriebe-Drehung über<strong>mit</strong>telt. Da das reale Getriebe nicht <strong>mit</strong> realis-<br />

tischen Drehzahlen bewegt wird, sind die Sensorsignale zur Erfassung<br />

der Drehzahl der Vorgelegewelle wv(: lind des Getriebeausgangs w c ~<br />

nicht plausibel. Deshalb werden diese Sensorsignale in der Simulation be-<br />

rechnet (siehe Abschnitt 4.4.4), elektronisch erzeugt und dem Getriebe-<br />

Steuergerät zugeführt .<br />

Das Kupplungs-Steuergerät <strong>mit</strong> der in Abschnitt 4.2.2 beschriebenen<br />

Kupplungs-Aktuatorik wird ebenfalls real verbaut und ist betriebsfähig.<br />

Die Kupplung selbst ist jedocli nicht vorhanden, der pneumatische

Betätigungszylinder arbeitet statt dessen gegen eine Federnlechanik.<br />

\I-elche die Kraft der Kupplungs-Rückst ellfeder nachbildet (Lastnach bil-<br />

dung). Der Kupplungs-Ausrückweg s~ wird vom Getriebe-Steuergerät<br />

<strong>mit</strong> dem serienrnäßigen, an1 Betätigungszylinder montierten M7egsensor<br />

erfasst und dient als Eingabegröße für eiri Simulatioiismodell der Kupp-<br />

lung (siehe Abschnitt 4.4.3).<br />

Diese Variante wird zur Realisierung des Fahrsimulators ausgewählt, da<br />

der konstruktive Aufwand ~vesentlich geringer ist als bei Variante 1. Der<br />

simulationsseitige Aufwand erhöht sich dagegen nur geringfiigig.<br />

4.3.3 Darstellung der weiteren Komponenten<br />

Bild 4.5: A~izeige des Fahrzustandes auf dem realer1 I

Eine Integration des realen Steuergerätes Fahrregelung (FR) war<br />

zum Zeitpunkt der Konzeption des Fahrsimulators aus technischen<br />

Gründen nicht möglich. Daher wird dieses in der Simulation durch<br />

ein Steuergeräte-Modell nachgebildet (Abschnitt 4.4.10).<br />

Das Steuergerät Ganger<strong>mit</strong>tlung (AG) wird dagegen als reale Seri-<br />

enkomponente integriert, um ein realistisches Schaltverhalten des<br />

ASG-Systems zu gewährleisten.<br />

Reale und simulierte Steuergeräte sind durch einen CAN-Bus ver-<br />

bunden. Die Behandlung des CAN-Netzwerks im Fahrsimulator<br />

erfolgt unter Anwendung der in Abschnitt 3.2 vorgestellten Ver-<br />

fahren.<br />

Zur Erreichung maximaler Realitätsnähe werden alle Bedien- und<br />

Anzeige-Elemente als reale Serienkomponenten in1 Fahrerhaus ver-<br />

baut. Dies betrifft die Pedale, das Zündschloss, den Lenkstockhe-<br />

bel, das Kombiinstrument (Bild 4.5), den Tachographen und das<br />

Fest stellbrems-Ventil. Alle aufgeführten Elemente werden aus der<br />

Simulation angesteuert und sind vollständig funktionsfähig.<br />

4.3.4 Realisiert er Hardware- Aufbau<br />

Aus den Betrachtungen in den vorherigen Abschnitten ergibt sich der<br />

Gesamtaufbau des Fahrsimulators gemäß Bild 4.6. Dargestellt sind die<br />

realen, im Fahrerhaus verbauten Serienkomponenten und deren elektri-<br />

sche, hydraulische und pneumatische Verschaltung, sowie die ITerbiridun-<br />

gen zum Simulationsrechner.<br />

Ini oberen Teil ist die Mensch-Maschine-Schnittstelle <strong>mit</strong> den Bedien-<br />

und Anzeige-Elementen skizziert. Der 13etätigungszustand der meisten<br />

Bedienelemente wird un<strong>mit</strong>telbar vom Simulationsrechner erfasst und<br />

ausgewertet. Das Schabt- Gebergerät ist, wie im realen Fahrzeug, <strong>mit</strong> dem<br />

Getriebe-Steuergerät verbunden.<br />

Die Anzeigen im Kombiinstrument werden über einen CAN-Bus an-<br />

gesteuert, auf dem auch die elektronischen Steuergeräte (Kupplungs-<br />

Steuergerät, Gang-Er<strong>mit</strong>tlung und Getriebe-Steuergerät) untereinander<br />

und <strong>mit</strong> dem Simulationsrechner Daten austauschen (<strong>mit</strong>tlerer Teil).<br />

Unten links ist die Kupplungs-Aktuatorik dargestellt. Abgesehen von der<br />

Lastnaehbildung? welche die reale Kiipplung ersetzt, ent'spricht der Auf-<br />

bau dem Srrienfalirzeug. Bei störungsfreiem Betrieb wird die Kupplung

I(=<br />

0<br />

L<br />

V)<br />

.-<br />

.Ci<br />

- (13<br />

E<br />

5<br />

Zündschloss ,<br />

ventil<br />

K~PP-<br />

lungs-<br />

Verstärker I<br />

Tcamnnm-rt- I ind<br />

Wl I iyw1 I l U L U 1 IU<br />

lauerbremsen- I I<br />

K~PP- Brems- Fahr- Fest-<br />

lungs- pedal pedal stell-<br />

Notpedal bremse<br />

i<br />

i<br />

i<br />

i<br />

I I<br />

V -<br />

Kupplungs-<br />

Steuergerät<br />

(KS)<br />

I<br />

Kupplungs-<br />

Stellglied (KB)<br />

/ 7<br />

Lastnachbildung<br />

Antrieb<br />

-----------+.----<br />

I<br />

Kombiinstrument<br />

und Tachograph<br />

I<br />

j Getriebe<br />

!<br />

Schalt-<br />

Geber-<br />

gerät<br />

7.J Druckluft-Versorgung<br />

Elektrik CAN . Hydraulik ---- Pneur natik<br />

Bild 4.6: Gesamtaufbau des Falirsiinulators<br />

I<br />

------ Magnet-<br />

I<br />

ventile<br />

+<br />

Weg-<br />

I<br />

I I sen-<br />

!<br />

I stell- ,-'-, soren

elektronisch gesteuert und über mehrere elektromechanische, hydrauli-<br />

sche und pneumatische Komponenten betätigt (Kupplungs-Stellglied und<br />

Kupplungs- Verstärker). Bei Ausfall der <strong>Elektronik</strong> kann die Kupplung<br />

über ein ausklappbares Kupplungs-Notpedal und ein Umschaltventil vom<br />

Fahrer auf hydraulischem Weg betätigt werden 11321. Im Fahrsimulator<br />

kann diese Notfunktion demonstriert werden.<br />

Das rechts unten dargestellte Getrzebe wird einschließlich der elektro-<br />

pneumatischen Betätigung (Magnetventile und Stellzylinder) sowie den<br />

Wegsensoren zur Erfassung der Schaltwege gemäß den Ausführungen in<br />

Abschnitt 4.3.2 (Variante 2) verbaut'.<br />

Die Druckluft für die pneumatischen Teile der Aktuatorik wird extern er-<br />

zeugt und dem Fahrsimulator über einen Druckluft-Anschluss zugeführt.<br />

4.4 Sirnulationsmodell<br />

In Ab~chnit~t 4.3 wurde ausgeführt, welche Fahrzeug-Komponenten im<br />

Fahrsimulator als reale Hardware verbaut und betrieben werden. Alle<br />

verbleibenden Teilsysteme werden in einem echtzeitfähigen Simulationsmodell<br />

abgebildet und auf einem Simulationsrechner implementiert.<br />

Im Fahrsimulator wirken reale und simulierte Komponenten so zusammen,<br />

dass der gesamte, in Abschnitt 4.3 spezifizierte Funktionsumfang<br />

verfügbar wird.<br />

Den Kern der Simulation bildet ein Modell des Antriebsstranges und<br />

der Längsdynamik eines LKl~T-Sattelzuges <strong>mit</strong> variabler Beladung. Als<br />

Grundlage wird das in [I41 beschriebene Modell eines PKW-Antriebs<br />

<strong>mit</strong> ASG verwendet. Dieses Rlodell wird für schwere Ntitzfahrzeuge modifiziert<br />

und erweitert. Das Sirnulationsrnodell besteht aus mehreren,<br />

in Bild 4.7 dargestellten Aggregate-hllodellen (vgl. Abschnitt 3.1 .I), die<br />

durch mechanische Größen (Drehzahlen und Drehmomente) gekoppelt<br />

sind.<br />

Als Eingabegrößen werden den Aggregate-Modellen Führungs-, Sensor-,<br />

und Stellgrößen zugeführt, welche entweder von real vorhandenen elek-<br />

tronischen Steuergeräten, von Steuergeräte-b1 odellen oder von den Be-<br />

dienelementen kommen. Mehrere berechnete Größen werden ausgegeben,<br />

welche z.B. auf dem Kombiinstrument angezeigt werden oder als Sensor-<br />

signale den real vorhandenen Steuergeräten zugeführt werden.<br />

In Abschnitt 2.1.2 wurde festgestellt, dass das Simulationsmode11 für<br />

einen Fahrsimulator alle denkbaren Fahrzustände abdecken muss, daniit

I<br />

Eingabe- Aggregate-Modelle Ausgabe-<br />

größen größen<br />

I - r-------,<br />

MM,i I I<br />

j ZMB Motor,<br />

I<br />

I zs<br />

b<br />

I I +<br />

I I<br />

I I<br />

I I<br />

Motor-<br />

bremsen,<br />

Starter<br />

WM 1<br />

I I<br />

1 I -M,/ WM I r : I<br />

i S~ ! O l<br />

I<br />

I CJI<br />

I<br />

Kupplung<br />

1 C l<br />

1 3 ;<br />

I r I<br />

I O i I l o ;<br />

MK 4 GE l O l<br />

; : I - @VG I f<br />

/ g j Z ~ Getriebe- 1x1<br />

I -<br />

WGA j :z i<br />

i i dynamik<br />

; W : ? l Eo i l<br />

; u ~ MG, J GA ~ r ;<br />

1 s : -<br />

1 3<br />

131<br />

'i 0 ;<br />

I M„ I<br />

j L I<br />

; o :<br />

Retarder I ~ I<br />

I C o 1 C l<br />

I C I I O .- ) j<br />

I O l<br />

I m I<br />

I W I MAW~ GA i o i<br />

i i i ; V ) :<br />

IO,I<br />

I r :<br />

Hinterachse<br />

-<br />

I C I<br />

l O 1<br />

I W I<br />

I L I<br />

/Si<br />

-<br />

--t M M ~ HA<br />

/ LL sBP<br />

I I +<br />

-<br />

FN,i<br />

I<br />

Brems- Reifen,<br />

I<br />

I<br />

-+ anlage Rad-<br />

I<br />

FBi - '<br />

I<br />

drehung<br />

I<br />

I<br />

I<br />

' O i<br />

i a i<br />

I --<br />

"VA 1 5 3 ! 1<br />

wHA s i<br />

3 i<br />

h m l I I<br />

I I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

/ m,-<br />

I<br />

"F<br />

*<br />

Fahrzeug-<br />

Längs-<br />

VF 1<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I<br />

I ast<br />

L ------- i I%b<br />

dynamik<br />

I<br />

I<br />

I<br />

I<br />

I<br />

irI<br />

I I<br />

L ------- _i<br />

Bild 4.7: Struktur lind signalfliiss des Simulatioiisnioc~rlls

die Simulation stets plausibel ist. In den folgenden Unter abschnitten<br />

werden mathematische Formulierungen der hlodellgleichungen für die<br />

in Bild 4.7 dargestellten Aggregate angegeben, die diese Anforderungen<br />

erfüllen und numerisch für die Echtzeitsimulation geeignet sind.<br />

Auch besondere Betriebszustände werden hier<strong>mit</strong> korrekt behandelt, z.B.<br />

das Anrollen im Gefälle, das Anfahren am Berg bei rückwärts rollendem<br />

Fahrzeug, das ,,Abwürgena des Verbrennungsmotors und Schaltabbrüche<br />

durch fehlerhafte manuelle Bedienung im Kupplungs-Notbetrieb.<br />

Die in Bild 4.7 eingetragenen Formelzeichen werden im Zusammen-<br />

hang <strong>mit</strong> den entsprechenden Aggregaten erläutert. Eine ausführliche<br />

Beschreibung der realen Antriebskomponenten enthält [133].<br />

4.4.1 Verbrennungsmotor<br />

Der Verbrennungsmotor wird in der Simulation als steuerbare Drehmomentquelle<br />

abgebildet. Yom Modell des Motor-Steuergerätes wird in<br />

Abhängigkeit von der Fahrpedalstellung und anderer Einflussgrößen eine<br />

fiktive Größe A~M,i,soll er<strong>mit</strong>telt. Diese repräsentiert einen Sollwert<br />

für das „innereG, d.h. durch die Gaskräfte an der Kurbelwelle erzeugte<br />

Drehmoment ohne Berücksichtigung von Reibungsverlusten.<br />

Dieses Moment wird durch die Volllastkennlinie hfhf,„(wM) und die<br />

Schleppkennlinie AIM,~ (wM) begrenzt,<br />

Diese Kennlinien sind als gemessene, stationäre Verläufe in Abhängigkeit<br />

von der Motordrehzahl abgelegt. Die Größen hfnr.u und repräsen-<br />

tieren ebenfalls „innere6' Momente ohne Berücksichtigung der Reibung.<br />

Stark vereinfachend wird angenommen, dass dieses begrenzte Moment<br />

vom Motor <strong>mit</strong> einer Verzögerungsfunktion erster Ordnung <strong>mit</strong> der Zeitkonstanten<br />

TM aufgebaut wird. Da<strong>mit</strong> gilt folgende Differenzialgleichung<br />

für das innere h/lotormoment hfM,i :<br />

Das mechanische Motor-Reibmoment hfn~,~<br />

[I341 ist in MAIJi nicht ent-<br />

halten. Es wird als separate Kennlinie angegeben, wobei der Einfluss der

Ölviskosität verriachlässigt wird.<br />

Die zu-eistufige Motorbremse bewirkt im betätigten Zustand ein<br />

zusatzliches, drehzahlabhängiges hfornent an der Kiirbelwelle,<br />

Aiuch dieses Yloment ist in Form gemessener Kennlinien im Modell hin-<br />

terlegt. Der Betätigungszustand iMs t {AUS, STUFE 1 , STCFE 2)<br />

der llotorbrernse wird vom Modell des A'fotor-Steuergerätes vorgegeben.<br />

Der Starter wird vereinfacht als Gleichstrom-llaschine <strong>mit</strong><br />

Nebenschluss-Erregung abgebildet2. Dieser klotortyp erbringt bei<br />

Stillstand das rnaxiniale Drehmoment ~lisi.o. Mit steigender Drehzahl<br />

fällt das hlorrient linear <strong>mit</strong> der Steigung -kst ab und erreicht bei<br />

der Leerlaufdrehzahl wct,~ den UTert Null [136]. Der Starter-Zustand<br />

zst E {AUS , EIN) wird vom hlodell des Motor-Steuergerätes vorgegeben.<br />

Beim Startvorgang (zst = EIN) erzeugt der Starter ein<br />

Zusatz-Drehmoment an der Kurbelwelle. Dieses ergibt sich unter<br />

Berücksichtigung der Übersetzung ist zwischen Schwungrad und<br />

Starter-Ritzel sowie des Freilaufs zu<br />

= ist . (Mst,o - kst . min(ist . WM , wst,o)) . (4.5)<br />

Die berechneten Drehmomente sowie das vom Kupplungs-hlodell (Xb-<br />

schnitt 4.4.3) er<strong>mit</strong>telte Kupplungmoment AfK sind an der Kiirbelwelle<br />

wirksam. Da<strong>mit</strong> ergibt sich die folgende Differerizialgleichung für die<br />

Motor-IVinkelbeschleunigung:<br />

repräsentiert das hlassenträgheitsmoment des Kurbeltriebs.<br />

Durch numerische 1nt)egratiori von Wn4 erhält riiari die 3 fotor-<br />

I{-inkelgessch~$-indigkeit wnr, die an das Kupplurigs-hlodell (siehe Ab-<br />

schnitt 4.4.3) iibergeben wird.<br />

4.4.2 Motor-Steuergerät<br />

Die für den Fahrsi~nulator wesentlichen Betriebszustände des 3Iotor-<br />

Steuergerätes werden in der Siiriiilation unter Einsatz des Werkzeugs<br />

'~eale Nutzfahrzeug-Starter sind meist als kombiniert^ Reihen- urid Nebenschluss-<br />

hlaschirie ausgeführt [133]. Für den Fahrsiriiulator ist dies ohne Bedeiltuiig.

Startabbruch<br />

[Start == 01<br />

Zündung<br />

- [Zdg == 11<br />

Motor-Start/<br />

Anlassen<br />

"Abwürgen" Abstellen<br />

Anrollen<br />

hzahl erreicht ,.,J , n-M-onl<br />

Drehzahlregelung<br />

Event-M-Vorgabe<br />

[Bedingung]<br />

U e--i><br />

0<br />

Zustand Zustands-Übergang lnitialisierung Verzweigung<br />

Bild 4.8: Vereinfachter Zust andsgraph der Motor-Steuerung<br />

STATEFLOW als Zustandsgraph abgebildet (vgl. -4bschnitt 2.3.3).<br />

Bild 4.8 zeigt eine vereinfachte Darstellung der Zustände und Übergänge.<br />

lom Zustand Motor- Aus erfolgt bei eingeschalteter Zündung <strong>mit</strong> dem<br />

Drehen des Zündschlüssels in die Startstellung der Übergang in den<br />

Zustand Motor-Start. Der Starter im IlTotormodell wird aktiviert. Sobald<br />

die Motordrehzahl nM die Startdrehzahl n ~,„ überschreitet, wird<br />

der Zustand Motor-An erreicht. Im Unterzustand n-Regelung wird bei<br />

blotorleerlauf und während Schaltvorgängen ein Drehzahlregler aktiviert.<br />

Dieser Drehzahlregler ist außerhalb des Zustandsgraphen realisiert<br />

und im Bild nicht dargestellt. Im Unterzustand M-Vorgabe erfolgt<br />

eine Vorgabe des Motor-Sollmome~its durch das elektronische Antriebs-<br />

Management. Beim Ausschalten der Zündung oder bei Unterschreitung<br />

einer unteren Grenzdrehzahl rl~,~ff (,,Abwürgenu des Motors) wird wieder<br />

der Zustand Motor-Aus erreicht.

4.4.3 Kupplung<br />

Bild 4.9: a) Qualitativer \'erlauf des übertragbaren Kuppluiigsnioments<br />

in Abhängigkeit vom Ausrückweg (normiert)<br />

b) Kupplungs-Gleitmoment in ,4bhängigkeit vom Kupplungs-<br />

schlupf bei verschiedenen Ausrückwegen (normiert)<br />

Im Fahrsimulator wird der Ausrückweg SK der Trockenkupplung von der<br />

real verbauten Kupplungs-Aktuatorik ei~igestellt und von einem IVegsen-<br />

sor erfasst. SK wird dem Kupplungsmodell zugeführt. Dieses unterschei-<br />

det zwischen den Zuständen Haften und Gleiten. Der Zustand Kupplung<br />

geöflnet stellt einen Sonderfall des Zustands Gleiten dar.<br />

Irn Haftzustand wird das Kupplungsmoment hfK.h durch die Torsionssteifiglteit<br />

CK und den Reibungskoeffizienteri dK des Torsionsdämpfers<br />

bestimmt [137]. Das Jloinent wird durch das maximal übertragbare<br />

Kupplungsmonient ,llK,li„, begrenzt, das als gemessene oder berechnete<br />

Funktion des _iusrückweges s~ srorliegt. Bild 4.9 a) zeigt ein B~ispic.1 in<br />

norrriierter Darstellung. Man erhält<br />

hfK,h = sign(w~) . min ((CK . p~ + d~ . W K I , A'f~.[im(s~)) . (4.7)<br />

~ I K ist der lrerdrehwinkel des Torsionsdämpfers. Die Kupplungsdrehzahl<br />

WK wird definiert als Differenz der Motordrehzahl wAjr und der<br />

Getriebeeingangs-Drehzahl WGE,<br />

Irn Gleitzustand wird die Federkonstante c~ zu Null gesetzt. Für das

Kupplungs-Gleitmoment AlK,, ergibt sich<br />

Zur Veranschaulichung wird der Kupplungsschlupf XK als Kupplungs-<br />

drehzahl, bezogen auf die maximale Motordrehzahl definiert,<br />

In Bild 4.9 b) ist das normierte Gleitmoment in Abhängigkeit vom Kupp-<br />

lungsschlupf und vom Ausrückweg dargestellt. Bei geringen Schlupfwer-<br />

ten ist das hlornent proportional zum Schlupf (strichlierte Gerade). Bei<br />

höheren Schlupfwerten erfolgt wiederum eine Begrenzung durch das ma-<br />

ximal übertragbare Alomeiit in Abhängigkeit vom Ausrückweg (durch-<br />

gezeichnete Geraden).<br />

Der Grenzwert XK,0 hängt von den Parametern der betrachteten Kupplung<br />

ab und liegt in der Größenordnung XK,0 = 0,001 . . . 0,005. Der<br />

stetige Verlauf des Kupplungsmoment~s für XK -+ 0 gewährleistet eine<br />

numerisch stabile Berechnung von Anfahr- und Lastwechselvorgängen.<br />

4.4.4 Getriebe<br />

LVie in Abschnitt 4.3.2 ausgeführt wurde, kann das real vorhandene Ge-<br />

triebe irn Fahrsimlator zwar geschaltet werden, dreht sich jedoch nur<br />

<strong>mit</strong> geringer, konstanter Drehzahl. Der aktuelle Schaltzustand wird vom<br />

Getriebe-Steuergerät er<strong>mit</strong>telt und als lTektor & dem Simulationsmodell<br />

der Getriebe-Dynamik zugeführt.<br />

Im Getriebe-Modell lvird aus zunächst die Getriebe-Gesamtüberset-<br />

zung ic und die Übersetzung der Split-Gruppe iv berechnet. Für die<br />

Gesamtübersetzung gilt<br />

iG > 0 : lTorwärtsgänge geschaltet<br />

iG = 0 : Neutralstellung (4.11)<br />

iG < 0 : Rückwärtsgänge geschaltet<br />

Unter zusätzlicher Berücksichtigung des Kupplungszustands werden im<br />

Getriebemodell vier Betriebszustände unterschieden, welche bereits in<br />

Abschnitt 4.3.2 definiert wurden. Im Folgenden werden für jeden Zustand<br />

die Beziehungen zwischen der Getriebeaiisgangs-Drehzahl w e und ~ der<br />

Getriebeeingangs-Drehzahl WGE sowie zwischen den Momenten MGE am

Getriebeeingang und hlGl an1 Getriebeausgang angegeben. Die Bedeu-<br />

t ung der Hilfsgröße ig wird anschließend erläutert,.<br />

1. Kupplung geöffnet, kein Gang geschaltet: Getriebeeingang und<br />

\rorgelegewelle werden durch Reibung niit der konstanten Win-<br />

kelbeschleunigung wGEIO abgebremst.<br />

"'GE,() (WGE/ >'JGE,nuin<br />

G = { 0 : sonst . (4.12)<br />

Die Konstante WGE,niriir ermöglicht eine nunierisch zuierlässige Erkennung<br />

des Stillstands der Getriebeeingaiigs-IYelle. ¿jc:i~,., n L,7n ist<br />

1-011 der Simulations-Schrit tweit e 12 abhängig,<br />

Die Getriebeeingangs-Drehzahl u~l;~. ergibt sich durch numerische<br />

Integration von WGE.<br />

2. Kupplung geöffnet, Gang geschaltet: Getriebeeingang und Getrie-<br />

beausgang sind formschlüssig verbunden.<br />

3. Kupplung haftend oder gleitend, kein Gang geschaltet: llotor. Ge-<br />

triebeeingang und Vorgelegewelle sind l-erburiden.<br />

1. Kupplung haftend oder gleitend, Gang ge~chalt~et: Kraftübertragung<br />

zwischen klotor und Getriebeausgang.<br />

Für die Dreliz,ahl der Vorgelege~velle gilt stets<br />

'JG E<br />

CVVG = - .<br />

2 1'

Beim Gangwechsel ändert sich der berechnete Wert ic sprunghaft. Der<br />

Synchronisationsvorgang bei Schaltungen wird im Getriebeinodell durch<br />

eine stetige Anpassung der Gesamtübersetzung zwischen altem und neu-<br />

em Gang <strong>mit</strong> der Zeitkonstanten Te,sync angenähert,<br />

Dadurch wird zugleich der aus numerischen Gründen erforderliche, stetige<br />

Verlauf der berechneten Drehmoment- und Drehzahlwerte erreicht.<br />

Bei der vorliegenden Realisierung muss der Synchronisationsvorgang im<br />

Modell spätestens bei Abschluss eines Schaltvorgangs irn realen Getriebe<br />

beendet sein, sonst werden vom Getriebe-Steuergerät unplausible Drehzahlen<br />

sensiert, die zum Schaltabbruch führen. Mit der Abschätzung<br />

T G , ~ 0,5 ~ . TG,min ~ ~ wird diese Forderung erfüllt. Die minimale Schaltzeit<br />

TG ,rnin des realen Getriebes wird experimentell bestimmt.<br />

Die berechneten Drehzahlen der Vorgelegewelle und des Getriebeaus-<br />

gangs werden zur Ansteuerung von Signalgeneratoren verwendet. Die er-<br />

zeugten elektrischen Signale werden dem Getriebe-Steuergerät zugeführt<br />

und ersetzen die fehlenden Sensorsignale (siehe Abschnitt 4.3.2).<br />

4.4.5 Hydrodynamische Dauerbremse (Retarder)<br />

Das betrachtete Fahrzeug ist <strong>mit</strong> einer hydrodynamischen Dauerbremse<br />

ausgestattet, die ein zusätzliches Bremsmoment <strong>mit</strong>tels eines Stirnradge-<br />

triebes <strong>mit</strong> der Übersetzung iRet auf den Getriebeausgang überträgt (so<br />

genannter Sekundär-Retarder). Dieses Aggregat sowie das zugeordnete<br />

Retarder-Steuergerät wird vereinfacht im Simulationsmodell abgebildet.<br />

Das Wirkungsprinzip des Retarders entspricht einer hydrodynamischen<br />

Kupplung <strong>mit</strong> feststellender Turbine. Die Bremsleistung geht als WTärme<br />

in das Arbeitsmedium (Öl) <strong>mit</strong> der Dichte PRet über und wird über<br />

einen Wärmetauscher und die Motorkühlung abgeführt. Die Theorie der<br />

Strömungsmaschinen liefert für das maximale Bremsmoment<br />

wobei die Leistungszahl XRet von der Rotordrehzahl bJRet, der Stellung<br />

der Turbinenschaufeln und von einem Steuerdruck abhängt, der den<br />

Füllungsgrad des Retarders und da<strong>mit</strong> die Bremsleistung beeinfliisst.<br />

DRel ist eine geometrische Größe, die als Durchmesser des Retarders<br />

bezeichnet wird [138].

t 1.<br />

M Ret<br />

MRet.rnax<br />

0.5 -<br />

0 1000 2000 3000 0 1 2 3<br />

nRet I min-I -+ tls +<br />

Bild 4.10: a) AIaxiniales Retarderrriomeiit in Abhängigkeit der Rotor-<br />

drehzahl (Beispiel)<br />

b) Zeitlicher Verlauf des auf seinen Maximalwert bezogenen<br />

Retardermoments (durchgezogene Kurve) nadi einem Soll-<br />

wertsprung (strichliert)<br />

Da diese Parameter schwierig zu er<strong>mit</strong>teln sind und G1. 4.19 das Ver-<br />

halten eines realen Retarders nur unzureichend beschreibt (u.a. wird die<br />

maximal mögliche IVarmrabfuhr nicht berücksichtigt), wird in1 Simu-<br />

lationsmodell das niaximale Retarderrnoment als stationär geiiiessene<br />

Kennlinie in Abhängigkeit von der Rotordrehzahl abgelegt.<br />

Af~et.lr2cl.r = ilf~etjnnx (UR&) . (4.20)<br />

Iri Bild 1.10 a) ist dies beispielhaft dargestellt. Die Rotordrehzahl ergibt<br />

sich aus der Getriebeausgangs-Drehzahl zu<br />

Ein von der Dauerbremsen-Steuerung vorgegebenes Retarder-<br />

Sollmoment hlRet„,il wird auf das maximal mögliche 14oment nach GI.<br />

4.20 begrenzt,<br />

Der dynamische Rfonientenaukau des Retarders wird durch eine<br />

I>rzögerungsfuiiktion zweiter Ordnung und eine zusätzliche Tot reit TRet

angenähert. Bild 4.10 b) zeigt beispielhaft den zeitlichen Verlauf des Re-<br />

tardermoments AlRet nach einem Sollwertsprung.<br />

Dieses Moment wird durch das erwähnte Stirnradgetriebe auf den Getrie-<br />

beausgang übersetzt. Da<strong>mit</strong> erhält man das an der Kardanwelle wirkende<br />

Gesamtmoment :<br />

4.4.6 Hinterachse<br />

.MAw = AiGA - iRet ' MRet .<br />

(4.23)<br />

Das an der Hinterachse wirkende Drehmoment AlHA ergibt sich unter<br />

Berücksichtigung der ~interachs-cbersetzurig irri aus dem hloment an<br />

der Kardanwelle,<br />

h1H,4 = ZHl4 AlAW . (4.24)<br />

Unter Berücksichtigung des Ausgleichsgetriebes ergibt sich das Antriebs-<br />

rnoment am rechten und am linken Hinterrad zu<br />

Die Hinterachs-Drehzahl wird aus den Drehzahlen des rechten und des<br />

linken Rades der Hinterachse berechnet,<br />

Bei der im Fahrsimulator bertrachteten. reinen Fahrzeug-Längsbewe-<br />

gung und unter der Annahme gleichen Schlupfes am rechten und linken<br />

Hinterrad (siehe Abschnitt 4.4.9) ergibt sich die Drehzahl der Hinterach-<br />

se <strong>mit</strong> G1. 4.50 aus der Umfangsgeschwingigkeit vth ,h der Hinterräder und<br />

dem Reifen-Halbmesser rd„ zu<br />

Die Größe rdgn wird als Näherung für den dynamischen Rollradius rd„<br />

verwendet, da dieser nur rnesstechnisch bestimmt werden kann, in der<br />

Simulation jedoch nicht bekannt ist (siehe Abschnitt 5.3.2).<br />

Aus WHA wird <strong>mit</strong> der ~interachs-Übersetzung die Kardanwellen-<br />

Drehzahl w ~u- berechnet, die auch der Getriebeausgangs-Drehzahl WGA<br />

entspricht,<br />

WAL\' = W C:,~ = iH.4 ' w HA (4.28)

4.4.7 Elektro-pneumatische Bremsanlage<br />

V1 ,V2,V3 = Vorratsdruckbehälter<br />

Pneumatik-Leitung<br />

Bild 4.11: Vereinfachter Aufhau der elektro-pneumatischen Bremsanlage<br />

(nach [133]). Die elektrischen Verbindungen sind nicht einge-<br />

zeichnet.<br />

Das betrachtete Nutzfahrzeug ist <strong>mit</strong> einer elektro-pneumatischen<br />

Bremsanlage (EPB) ausgerü~t~et . Nach einer kurzen Besclireibiing der<br />

IYirkungsweise wird eine vereinfachte .4bbilduiig der EPB in1 Siniulationsmodell<br />

für den im Falirsimulator dargestellten Sattelzug <strong>mit</strong> 1-ariabler<br />

Beladung hergeleitet.<br />

Aufbau und Wirkungsweise:<br />

Elektro-pneumatische Bremsanlageri sind seit 1993 für Zugfahrzeuge und<br />

Anhänger bzw. Sattelauflieger verfügbar [139, 1401. Da die 6bertragung<br />

der Bremspedal-Betätigung zu den Radbremsen teilweise elektrisch er-<br />

folgt, handelt es sich um ein Brake-by- Wzre-System [141]. Zusätzlich exis-<br />

tiert eine redundante, rein pneumatische Zweikreis-Bremsanlage, wel-<br />

che nur bei <strong>Elektronik</strong>-Fehlern aktiv wird. In Bild 4.11 ist der Aufbau<br />

der Bremsanlage vereinfacht dargestellt. Das Regelungskonzept wird in<br />

[142, 1431 ausführlich beschrieben und hier kurz zusammengefasst:<br />

Der Betätigungsweg s ~ p<br />

des Brernspedals wird durch einen Brems-<br />

wertgeber erfasst und vom elektronischen Bremsen-Steuergerät als Soll-

Abbremsung z„rr interpretiert, d.h. als Quotient der Soll-Verzögerung<br />

-a„ll und der Erdbeschleunigung g:<br />

Durch eine im Bremsen-Steuergerät implementierte Verxögerungsrege-<br />

lung wird für eine gegebene Bremspedalstellung bei jedem Beladungszu-<br />

stand die gleiche Ist-Abbremsung z erreicht, sofern der Kraftschluss zwi-<br />

schen Reifen und Fahrbahn ausreicht. Hierzu werden die Luftdrücke in<br />

den Radbremszylindern der Vorderachse durch ein gemeinsames Druck-<br />

regelventil Vorderachse und zwei ABS- Ventile eingeregelt. Die Druckre-<br />

gelung für die Radbremszylinder der Hinterachse erfolgt <strong>mit</strong>tels zweier<br />

Regelkreise, die im Hinterachs-Modul zusammengefasst sind.<br />

Bei konventionellen Nutzfahrzeug-Bremsanlagen wird die lastabhängige<br />

Anpassung der Brernskrafi- Verteilung durch ein ALB-\'enti13 realisiert.<br />

Dagegen erfolgt diese Anpassung bei der EPB durch Differenzschlupf-<br />

Regelung. Es wird stets eine Minimierung der Schlupfdifferenz zwi-<br />

schen Vorder- und Hinterachse angestrebt. Die Schlupfdifferenz wird im<br />

Bremsen-Steuergerät aus den Raddrehzahlen berechnet, die <strong>mit</strong>tels in-<br />

duktiver Raddrekxahl-Sensoren erfasst werden.<br />

Wenn bei einem Sattelzug der Auflieger ebenfalls <strong>mit</strong> EPB aus-<br />

gerüstet ist, wird zusätzlich eine Koppelkraft-Regelung durchgeführt<br />

[145]. Die Kombination von Differenzschlupf- und Koppelkraft-Regelung<br />

ermöglicht eine annähernd ideale Bremskraft-ierteilung [146], d.h. die<br />

Kraftschluss-Ausnutzung k nimmt an der Vorder- und Hinterachse des<br />

Zugfahrzeugs sowie an der Auflieger-Achse den gleichen Wert an,<br />

ph ist der Haftreibungs-Beiwert zwischen Reifen und Fahrbahn.<br />

Abbildung der EPB irn Simulationsmodell:<br />

Die Aufgabe des Simulationsmodells der EPB-Anlage ist die Berechnung<br />

der dynamischen Achslasten FN,~ und der Bremskräfte FB,i für alle Achsen<br />

eines Sattelzuges in Abhäiigigkeit des Bremspedalweges sßp, der im<br />

Fahrsimulator vom Fahrer vorgegeben wird.<br />

3~~~=Automatischer<br />

lastabhängiger Bremskraftregler. Bei Stahlfederung erfolgt<br />

die Ventilbetätigung mechanisch (durch Einfederung der Hinterachse), bei Luft-<br />

federung pneumatisch (z.B. durch die Niveauregelung) [144].

Bild 4.12: Zur Er<strong>mit</strong>tlung der dynamischen ,ichslasten beim beladenen<br />

Sattelzug<br />

Hierbei wird vereinfachend angenommen, dass die Ist-Abbremsung z der<br />

Soll-Abbremsung z„,l nach G1. 4.29 stets entspricht und dass die ideale<br />

Bremskraft-Verteilung gemäß G1. 4.30 gegeben ist. Anhand von Bild<br />

Bild 4.12 erfolgt die Bereclinung der dynamische~i Achslasten. Im Bild<br />

sind die wirksamen Kräfte irnd die geoinetrischen Größeii der Zugmaschine,<br />

des -4ufliegers und der Ladung eingetragen. Dcr Eirifliiss der<br />

Fahrbahnsteigung sowie des Luftwiderstandes auf die Achslasten wird<br />

vernachlässigt. Ferner wird vereinfachend da-on ausgegangen, dass sich<br />

die Sattelkupplung genau über der Hiiiterachse des Zugfahrzeugs befindet.<br />

Die Schlupfregelungs-Funktionen und ASR. die c~beiifalls iin<br />

Bremsen-Steuergerät implementiert sind. werden i11 der Si~nulatioii nicht<br />

berücksichtigt.<br />

Bei einem in der Ebene fahrenden Fahrzeug <strong>mit</strong> n~ gebremsten dclisen,<br />

an denen die Bremskräfte auftreten, ist die i\bbremsung gernaß DIN<br />

ISO 611 definiert durch<br />

wobei r n die ~ Fahrzeug-Gesamtmasse bezeichnet [147].<br />

Für einen Sattelzug, bestehend aus der Zugniascliine <strong>mit</strong> den1 Gewicht<br />

Gz und einem beladenen Sattelauflieger <strong>mit</strong> dem Gewicht Gc. lautet

GI. 4.31 wie folgt:<br />

-(FB,c + FB,~ + FB,A) - -(FB.r + FB,~ + FB,A)<br />

X = . (4.32)<br />

(G2 + G's) fij + FN,~ + FN,A<br />

Durch Einsetzen von G1. 4.30 in GI. 4.32 findet man<br />

Nun werden Aufbau und Ladung des Aufliegers zusammengefasst. Für<br />

das Ersatzsystem beladener Auf lieger gilt:<br />

G~=GA+GL (Gesamtgewicht) ,<br />

GA ' t 4,h + GL ' eL.h<br />

ls.h (Schwerpunktlage) ,<br />

GA + GL<br />

hs =<br />

GA * h4 + GL - h~<br />

GA + GL<br />

(Schwerpunkthöhe)<br />

Stellt man den Impuls- und den Drallsatz für das Zugfahrzeug und den<br />

beladenen Auflieger auf und berücksichtigt zusätzlich G1. 4.30 und G1.<br />

4.33 für das Gesamtfahrzeug, so ergeben sich die Achslasten FN,%, und<br />

FN,~ der Vorder- und Hinterachse des Zugfahrzeugs, die Achslast FN A<br />

des Aufliegers sowie die Sattellast FN,~ in Abhängigkeit von der Abbremsung<br />

X zu<br />

FN,K = GS - FN,A (Satt ellast)<br />

P", L7.h- h<br />

"~,n<br />

FN,~, = GZ . + FA~,K. 2. - (Vorderachse)<br />

ez,o f z,o<br />

I ' C L I ~ K<br />

FN,~ Gz + FN,K - FN,U (Hinterachse)<br />

In Bild 4.13 sind beispielhaft die nach G1. 4.35 berechneten, dynami-<br />

schen Achslasten über der Abbremsung aufgetragen. Die angegebenen<br />

Fahrzeug-Parameter sind geschätzt. GI. 4.35 gilt auch für Bremsungen<br />

bei Rückwärtsfahrt (i < 0).<br />

RIit Cl. 4.30 erhält man die gesuchten Bremskräfte an den Achsen,<br />

Diese gehen in die Berechnung der Fahrzeug-Längsdynamik (Abschnitt<br />

4.4.8) und der Raddrehung (Abschnitt 4.4.9) ein.

100<br />

FN<br />

Bremsung rückwärts Bremsung vorwärts<br />

I<br />

F,, (Auflieger-Achse)<br />

- 1 - .<br />

- # - , -, - - -%--,=- - -- - - - -----,- 20 Zugfahrzeugs) -- I,<br />

h,<br />

= 2,7 m<br />

= 0.8 m<br />

Is.~ = 3,O m<br />

h, = 2,O m<br />

h, =1.0m<br />

0<br />

Bild 4.13: Achslasten eines Sattelzuges in Abhangigkeit von der Abbrem-<br />

sung bei idealer Bremskraft-Vert,eilung (Beispiel)<br />

4.4.8 Längsdynamik<br />

Bei der Berechnung der Fahrzeug-Längsbe~veguiig im Simulationsniodell<br />

sind die Zustände ,.Fahrzeug steht" und .,Fahrzeug fährt" zu unterscheiden.<br />

Dies ist notwendig, da die Siinulationsanlage mehrere Signale ausgibt,<br />

die bei Fahrzeugstillstand besondere Werte annelirneri.<br />

Im Folgenden wird eine Formulierung angegeben, die für lorwärts- und<br />

Rückwärtsfahrt, bei Steigung und im Gefälle so~vie für Antrieb und<br />

Bremsung gültig ist und den numerischen Anforderungen der Echtzeitsimulation<br />

genügt.<br />

Beim stehenden Fahrzeug gilt für die Fahrzeug-Geschwindigkeit und die<br />

Beschleunigung<br />

I

Für das fahrende Fahrzeug gilt der Impulssatz<br />

1<br />

Die Gesamtmasse m~ das Fahrzeugs setzt sich aus den konstanten hIassen<br />

mz der Zugmaschine und m~ des Aufliegers sowie der variablen<br />

Masse rn~ der Ladung zusammen,<br />

Die Summe Fl der von der Bewegungsrichtung des Fahrzeugs unabhängi-<br />

gen Kräfte setzt sich aus der Antriebskraft FA und dem Steigungswider-<br />

stand Fst zusammen4,<br />

Das Antriebsmoment AlHA an der Hinterachse ergibt sich aus G1. 4.24.<br />

'<br />

'dyn ist der Radhalbmesser (vgl. Abschnitt 5.3.2).<br />

F2 ist die Summe der Kräfte, die der Fahrzeugbewegung stets entgegen<br />

wirken. F2 besteht aus der Rollreibungskraft FRw,ges, dem Luftwiderstand<br />

FLiv [148j5 und der Summe der Bremskräft'e aller Achsen Fs:g„<br />

(siehe G1. 4.36),<br />

Der ilbergang vom fahrenden in den stehenden Zustand erfolgt, wenn<br />

die Anhalte bedingung erfüllt ist:<br />

Die Anhaltegeschwindigkeit vSt„ ist in Abhängigkeit von der<br />

Integrations-Schrittweite h und der maximal auftretenden Beschleuni-<br />

gung bzw. Verzögerung des Fahrzeugs U„, zu wählen6. Es gilt:<br />

vstop > h . Iarnai 1 . (4.43)<br />

4~m Fahrsimulator kann die Beladung mL sowie der Fahrbahn-Steigungswinkel aSt<br />

vom Bediener vorgegeben werden.<br />

"Hei Windstille und unter Vernachlässigung des Einflusses der Fahrbahnsteigung<br />

auf den Rollwiderstand.<br />

'~eis~iel: lamm 1 =10ni/s2, h=lms i u,iop > 0,01 rn/s. Wähle ztst„ = 0,02 m/s.

Für den Übergang vorn stehenden iii den fahrenden Zustand gilt dir<br />

Anfahrbedingung<br />

(4.44)<br />

IFll - F2 > F4nf .<br />

Die Konstante FJ4nf kann als Anfahrwiderstand erklärt werden, der nach<br />

die Haftreibungskräfte in den Radlagern und im Antriebsstrang sowie<br />

den „RollwiderstandL. des stehenden Fahrzeugs umfasst 11-19]. F4„f kann<br />

experinientell er<strong>mit</strong>telt werden.<br />

'nlit dieser Formulierung werden alle denkbaren Vorzeichenkombinatio-<br />

nen von Geschwindigkeit, Beschleu~iigung, Antriebsmoment und Brerns-<br />

kraft korrekt behandelt.<br />

4.4.9 Rad-Umfangsgeschwindigkeit en<br />

Bild 1.14: a) Cmfangskraft eines Nutzfahrzeugreifens über dem Schlupf<br />

bei verschiedenen Radlasten (Quelle: <strong>FKFS</strong>)<br />

b) Iii~ertiertes Kennfeld für den stabilen Bereich<br />

Die reale <strong>Elektronik</strong> im Fahrsimulator benötigt zur korrekten Funktion<br />

plausible Werte für die Umfangsgeschwindigkeiten der Jorder- und<br />

Hinterräder des Zugfahrzeugs. Hierbei ist der Reifen-Längsschlupf im<br />

Antriebs- und Bremsfall zu berücksichtigen. In der Siniulation werden<br />

diese Geschwindigkeiten unter der bereits erwähnten L%niial~rne ausreichenden<br />

Kraftschlusses berechnet. Zusätzlich wird angenoiniiieii, dass dir<br />

Cinfangsgeschi~indigkeiten beider Räder einer Achse stets gleich sind.

Die Reifen-Umfangskraft an einem Vorderrad und an einem (angetrie-<br />

benen) Hinterrad ergibt sich <strong>mit</strong> GI. 4.36 und G1. 4.24 zu:<br />

Bei reiner Längsdynamik gilt für die Radlasten (<strong>mit</strong> G1. 4.35):<br />

Im Folgenden wird <strong>mit</strong> Fr die an einem einzelnen Rad wirkende Um-<br />

fangskraft und <strong>mit</strong> FaV die Radlast bezeichnet. Auf die Indices v,h für<br />

die Vorder- und Hinterachse sowie t,r für das linke bzw. rechte Rad wird<br />

verzichtet.<br />

In Bild 4.14 a) ist die Umfangskraft eines Nutzfahrzeugreifens über dem<br />

Schlupf X bei verschiedenen Radlasten angegeben. Der stabile Bereich<br />

der Kennlinien (dFLr / dX > 0) wird invertiert und als Kennfeld im Si-<br />

mulationsmodell abgelegt, Bild 4.14 b). Aus der Umfangskraft und der<br />

Radlast wird durch Interpolation der Schlupf bestimmt,<br />

Der Schlupf wird definiert zu<br />

X = {<br />

Vth - "JF<br />

max(I'-th , '-F')<br />

: Iuth 1 > vnurn V I ~ F 1 > vnum<br />

. (4.48)<br />

0 : sonst<br />

Die Bedeutung dieser Definition wird in Abschnitt 5.3.3 erläutert.<br />

G1. 4.48 wird für die Betriebszustände Vorwärts- und Rückwärtsfahrt<br />

sowie für Antrieb und Bremsung jeweils nach ~ t aufgelöst. h Da irn betrachteten,<br />

stabilen Bereich des Umfangskraft,-Kennfeldes nur geringe<br />

Schlupfwerte auftreten, werden zusätzlich die Näherungen<br />

1 I<br />

N 1 - X und --- xl+X : IXI

verwendet. Darnit erhält inan folgende Gleichungen für die gesuchte11<br />

Umfangsgeschwindigkeiten an der Jrorder- u11d Hiriterachse:<br />

@th,v = 'UF ' (1 + X„ . sign(~~)) ,<br />

c ~ UF ~ . , (1 + ~ Xh . sign(u~)) .<br />

Die Schlupfwerte X , und Xh werden jeweils <strong>mit</strong> G1. 4.47 bestimmt. Diese<br />

Formulierung ist für alle Betriebszustände gültig lind numerisch stabil.<br />

4.4.10 Steuergerät Fahrregelung (FR)<br />

Das FR-Steuergerät koordiniert die Antriebs- urid Brernsfunktioneii 1124.<br />

1-50]. Dieses Stc'uergerät ist iin Fahrsirriulator nicht als reale Koinponente<br />

vorhariden, Statt dessen werden die folgenden, für den Fahrsiinulator<br />

relevanten Funktionell in einem Steuergeräte-;\Tode11 geniäß Abschnitt<br />

3.1.7 detailliert nachgebildet:<br />

Erfassung der Betätigungen des elektronischen Fahrpedals, des<br />

Tempomat- und Dauerbremsenschalters, der Zündschlüsselstellung<br />

sowie anderer Bedienelemente,<br />

Interpretation der Fahrereingaben (Er<strong>mit</strong>tlung des ,,Fahrerwun-<br />

sches" bezüglich Antrieb und Bremsung) ,<br />

Er<strong>mit</strong>tlung der Drehzahl- und Dreliinoment-Sollvierte fiir den \er-<br />

brerinungsmotor ,<br />

Koordination der Bremseinrichtungen (Bet,riebsbreinse, XIotor-<br />

brernsen und hj-drody-narnischer Retarder) .<br />

Variation der Motor-Leerlaufdrehzahl,<br />

Geschm-indigkeitsregelung (Antriebs- und Dauerbreriisen-Tempo-<br />

mat, kombinierte Tempomatfunktion),<br />

Begrenzung der Fahrgeschwindigkeit (Fahrervorgabe oder gesetz-<br />

liche Höchstgeschwindigkeit),<br />

Berechnung und Ausgabe der CAN-Nachrichten, die von den real<br />

verbauten Steuergeräten erwartet werden und<br />

Verarbeitung roii CAN-Dat,en, die von realen Steiiergerätrri oder<br />

anderen Steuergeräte-hlodellen erzeugt werden.

Anhand eines einfachen Beispiels wird die Implementierung einer ver-<br />

balen Funktionsbeschreibung in diesem Steuergeräte-Modell betrachet.<br />

Die Betriebsanleitung des Fahrzeugs [150] enthält (sinngemäß) folgende<br />

Erläuterung zur Bedienung der Dauerbremsen:<br />

Neben der Stellung des Dauerbremsen-Schalters hängt die Aktivierung<br />

von der Zündung ab: War der Dauerbremsen-Schalter beim Einschal-<br />

ten der Zündung bereits betätigt, so werden die Dauerbremsen zunächst<br />

nicht aktiviert. Die Kontrolllampe blinkt. Nachdem der Fahrer den Schal-<br />

ter einmal in die Nullstellung bringt und ihn danach erneut betätigt, sind<br />

die Dauerbrernsen aktiv. Die Kontrolllampe leuchtet.<br />

0ffl<br />

entry: DB-Lampe = AUS; DB Zustand = AUS;<br />

n<br />

[DB-Schalter >= I] [D8 - Schalter == 01<br />

V<br />

0n-standby<br />

-<br />

P<br />

Standbyl<br />

entry :<br />

DB-Lampe = BLINKEN;<br />

[KL15 == 01<br />

DB - Zustand = AUS;<br />

DB-Lampe = EIN;<br />

L J DB - Zustand = EIN;<br />

Bild 4.15: Vereinfachter Zustandsgraph der Steuergeräte-Teilfunktion<br />

„ Dauerbremsen- Aktivierung"<br />

In Bild 4.15 ist ein STATEFLOWT-Diagramm zur Implementierung die-<br />

ser Teilfunktion dargestellt7. Eingangsgrößen des Zustandsdiagramms<br />

sind die Schalterstellung DB-Schalter und das Zündungssignal KLl5. Si-<br />

gnalanderungen wie das Einschalten der Zündung bewirken Übergänge<br />

zwischen den Zuständen Off (Dauerbremsen abgeschaltet), On (Dau-<br />

erbremsen aktiv) und Standby (Schalter war beim Einschalten der<br />

Zündung betätigt). Die Ausgangsgröße DB-Zustand beschreibt den<br />

Aktivierungszustand der Dauerbremsen ( Aus/Ein) . Ein weiteres Aus-<br />

7~usätzlich hängt die Aktivierung der Dauerbremsen von weiteren Zustandsgrößen,<br />

z.B. der Fahrzeuggeschwindigkeit und der Motordrehzahl, ab. Auf eine Darstellung<br />

des gesamten, sehr umfangreichen Zustandsgraphen wird verzichtet.<br />

126<br />

\<br />

2

gangssignal DB-Lampe re~rä~sentiert den Zustand der I(ontroll1arnpe<br />

( Aus/Blinken/Ein) .<br />

4.5 Implementierung<br />

4.5.1 Simulationsprogramm und Echtzeitrechner<br />

Die Implementierung des beschriebenen Simulationsmodells erfolgt<br />

gernäß ;lbsclinitt 2.3 und Abschnitt 3.2.4 unter Einsatz der Werkzeuge<br />

SIlltTLINK, ST,ATEFLOTT7 und CANCLINK. Das IIotfell enthält kei-<br />

nen manuell erstellten Programm-Code. Durch Einsatz des SIMULIXK-<br />

Code-Generators RTTV wird automatisch ein ausführbares Programm<br />

erzeugt, welches auf einem Industrie-PC in Echtzeit abläuft. Nach dem<br />

Einschalten der Anlage <strong>mit</strong>tels eines Hauptschalters wird das Programm<br />

automatisch geladen, initialisiert und gestartet . Der Fahrsimulat or ist<br />

nach wenigen Sekunden betriebsbereit. Dadurch ist die in Abschnitt 4.1.1<br />

geforderte Benutzerfreundlichkeit gewährleistet.<br />

Hohe Anforderungen bestehen bei der CAN-Kommunikation. Zur<br />

Gewährleistung eines fehlerfreien Betriebs der realen <strong>Elektronik</strong> niüssen<br />

alle CIAN-Kachricliten für jeden Fahrziistarid plausibel sein. Irn Fahrsi-<br />

mulator werden ca. 20 C14N-Nachrichten, bestehend aus rund 330 Ein-<br />

zelsignalen, <strong>mit</strong> kurzen Zykluszeiten vom Simulationsrecliner generiert<br />

und gesendet bzw. empfangen und ausgewertet. Der C-Code zur Codie-<br />

rung und Decodierung der Nachrichten wird unter lTerivendung des in<br />

Abschnitt 3.2.4 vorgestellten Code-Generators C ANULINK automatisch<br />

generiert und in SIMULINK eingebunden.<br />

Die CAN-Konfiguration entspricht Bild 3.10 b). Eingesetzt wird eine<br />

PC-Steckkarte rriit zwei unabhängigen CAN-Kanälen und einem eige-<br />

nen hIikroprozessor [15l]. Diese Karte führt die Sende- lind Empfangs-<br />

vorgänge autonom durch. Der Siinulationsrechrier wird durch die CAN-<br />

Kornrriunikat ion nur geringfügig belastet .

4.5.3 Interface-<strong>Elektronik</strong><br />

Zum Austausch der elektrischen Signale zwischen dem Simulations-<br />

rechner und den realen Hardware-Komponenten wird eine Interface-<br />

<strong>Elektronik</strong> verwendet. Diese besteht aus mehreren kommerziell verfügba-<br />

ren PC-Steckkarten sowie einer im Rahmen dieser Arbeit entwickelten<br />

Signalkonditionierung zur Nachbildung der elektrischen Eigenschaften<br />

passiver und aktiver Sensoren. In der Simulation werden mehrere Si-<br />

gnale zur Substitution der Drehzahlsensoren im Getriebe sowie weitere<br />

Sensorsignale erzeugt und über die Signalkonditionierung ausgegeben.<br />

Alle über die Bedienelernerite (Schalter, Pedale, etc.) vorgegebenen<br />

Größen werden in Aiialogspannungen umgewandelt und in die Simula-<br />

tion eingegeben. Störungen durch prellende Schalter oder elektromagne-<br />

tische Einstreuungen werden durch Hardware-Filter unterdrückt. Eine<br />

zusätzliche Signalaufbereitung erfolgt in der Software.<br />

4.6 Ausgewählte Versuchsergebnisse<br />

Zur Überprüfung der Qualität der Simulation und zur Veranschaulichung<br />

der Schulungsmöglichkeiten werden repräsentative Fahrmanöver unter-<br />

sucht. Die Versuchsergebnisse werden dargestellt und interpretiert.<br />

4.6.1 Validierung der Simulationsanlage<br />

In Bild 4.16 sind Messergebnisse für das Fahrnianöver Anfahren und<br />

Hochschaltung in der Ebene im Fahrversuch und im Fahrsimulator darge-<br />

stellt. Beide Versuche wurden im automatischen Schaltmodus interaktiv,<br />

d.h. <strong>mit</strong> realen Fahrern, durchgeführt. Da die Einflüsse auf den Fahr-<br />

widerstand (Fahrzeugmasse, Luft- und Rollwiderstand) im Fahrversuch<br />

nicht genau bekannt sind, erfolgt lediglich ein qualitativer Vergleich.<br />

Der Fahrpedalweg und der Kupplungs-Ausrückweg ist in normierter Dar-<br />

stellung angegeben. Die Gang-Angaben bestehen aus Gang-Nummer und<br />

Split-Schaltung (L = langsam, S = schnell).<br />

Der Vergleich zeigt, dass Anfahr- und Schaltvorgänge im Simulator plau-<br />

sibel nachgebildet werden. Vom Sirnulationsmodell werden die Drehzah-<br />

len des hlotors und des Getriebeeingangs. die Fahrgeschwindigkeit sowie<br />

weitere, nicht dargestellte Betriebsgrößen <strong>mit</strong> hinreichender Genauigkeit<br />

berechnet und an die realen Steuergeräte ausgegeben. Da<strong>mit</strong> ist deren

t<br />

60<br />

a) Fahrversuch b) Fahrsirnulator<br />

I I<br />

- Geschwindigkeit 6L<br />

kmlh --- Gang<br />

40<br />

2s<br />

-----------J<br />

20<br />

r-------<br />

I<br />

0 0 5 10 t 15<br />

- -+<br />

S<br />

Bild 4.16: Anfahren und Hochschaltungen im Automatik-hlodus<br />

a) im Fahrversuch<br />

b) irn Fahrsirriulator

fehlerfreie Funktion auch im Fahrsimulator gegeben. Das Überschwingen<br />

der Getriebeeingangs-Drehzahl im Falirversuch wird durch Elastizitäten<br />

im Antriebsstrang verursacht. Diese werden im Simulationsmodell nicht<br />

berücksichtigt, da sie für die korrekte Funktion des Fahrsimulators nicht<br />

relevant sind.<br />

Analog wurden weitere Fahrversuche durchgeführt, z.B. Ausrollen in der<br />

Ebene und Rückwärtsfahrt. Durch Vergleich <strong>mit</strong> Simulator-Versuchen<br />

wird eine gute qualitative Übereinstimmung festgestellt.<br />

4.6.2 Assistenzfunktionen<br />

Ein wichtiges Ziel der Fahrsimulator-Schulung ist die Demonstration<br />

von Assistenzfunktionen des Antriebsstrang-Managements, die im rea-<br />

len Fahrbetrieb nur dann aktiviert werden, wenn Gefahr für den Fahrer,<br />

die Umwelt oder das Fahrzeug besteht. Irn Fahrsimulator können sol-<br />

che Situationen gefahrlos nachgestellt werden. Die folgenden I11essungen<br />

wurden im Fahrsimulator bei interaktiver Bedienung aufgezeichnet. Ver-<br />

gleichsdaten aus dem Fahrversuch liegen nicht vor.<br />

In Bild 4.17 sind zwei Anfahrvorgänge a'n einer Steigung von 10 % dar-<br />

gestellt. Die Fahrzeugmasse beträgt jeweils 38 t (beladener Sattelzug).<br />

Im Teilbild a) wird der Anfahrgang (1s) von der ASG-<strong>Elektronik</strong> auto-<br />

matisch gewählt. Der Fahrer löst die Bremsen, betätigt jedoch nicht so-<br />

fort das Fahrpedal. Das Fahrzeug rollt rückwärts bergab. Bei Betätigung<br />

des Fahrpedals (tl) wird die Kupplung von der <strong>Elektronik</strong> in den Gleit-<br />

zustand geregelt ( s ~ / s X ~ 0,4), , ~ bis ~ die ~ Drehzahldifferenz zwischen<br />

hlotor und Getriebeeingang verschwindet. Erst dann wird vollständig<br />

eingekuppelt. Das Fahrzeug beschleunigt und führt zwei Hochschaltungen<br />

durch. Während des Einkuppelns signalisiert eine Warnleuchte kurzzeitig<br />

die drohende thermische Überlastung der Kupplung. Das Simulationsergebnis<br />

zeigt eine gute Übereinsti~mmun~ <strong>mit</strong> der Darstellung des<br />

Kupplungs-Regelungskonzeptes in [132].<br />

Im Teilbild b) wählt der Fahrer manuell einen zu hohen Anfahrgang<br />

(2s) und läßt das Fahrzeug zunächst zurückrollen. Nach der Fahrpedal-<br />

Betätigung (t ) wird aufgrund der hohen Kupplungs-Verlustleist ung<br />

(> 200 kW für mehrere Sekunden) wieder eine drohende Überhitzung<br />

signaliert. Da der Fahrer den Anfahrversuch fortsetzt (,,Vollgasa), wird<br />

bei t2 eine Schutzfunktion aktiviert, um die Zerstörung der Kupplung<br />

zu verhindern [150]: Durch vollständiges Einkuppeln und Abstellen des

proportional zur Xuslenkiing Aqi aus der Rlihelage $I, und wirkt der<br />

Rotation um die Hochachse entgegen. Beim C~berschreiten der Haftgren-<br />

ze erfolgt der Übergang in deii Gleitzustand. Das Gleitrnomeiit wird<br />

proportional zur Winkelgeschindigkeit / angesetzt.<br />

Das Schwenkmomei-it ergibt sich zu<br />

wobei A$ die Auslenkung des Reifens aus der entspannten Lage be-<br />

schreibt. c~ bezeichnet die Torsionssteifigkeit des Reifens um die Hoch-<br />

achse. Der Winkel $, setzt sich a.us dem Fahrzeug-Gierwinkel QzB und<br />

dein Lenkwinkel 6 des betreffenden Rades ziisarnnieri und gibt desseii<br />

absoluten Gierwirikel gegenüber der Fahrbahn an,<br />

Alnalog zur Berechnung der Horizontalkräfte wird eine Relaxationslänge<br />

Lr,B eingeführt. Diese beschreibt den Abrollnreg, den der Reifen in<br />

Längsrichtung zurücklegen muss, um das Schwenkmoment abzubauen<br />

(z.B. beini Anfahrvorgang). Unter Verwendung dieser Ansätze wird in<br />

[I701 die folgende Differenzialgleichung für die Ruhelage $„ d.h. den<br />

Rad-Gierwinkel im entspa~int~en Zustand hergeleitet,<br />

<strong>mit</strong> dem geschsvindigkeitsabhängigen Zeitfakt'or<br />

Der erste Term in G1. 5.29 bewirkt den wegabhängigen Ilorne~itenabbau.<br />

Der zweite Term berücksichtigt den Einfliiss der Radlast und bewirkt tleil<br />

Cbergarig zwischen Haft- lind Glritzustaiid. Der Parameter<br />

beschreibt die Haftgrenze. Er wird bestimmt, indem bei einer vorgegebenen<br />

Radlast F,v,B die Auslenkung A$, aus der Ruhelage gemessen wird,<br />

-<br />

bei der der Reifen zu gleiten beginnt. Die Zeitkonstante T$ bestimmt die<br />

Dynamik des ~aft-/~leit-¿'herganges. Sie wird iiii Falirsimulator esperimeritell<br />

abgestimmt. Es gilt 5 . TB .<br />

Aiiha1ts~~-erte zur Er<strong>mit</strong>tlung der Parameter sind in 11691 angegeben. Ini<br />

Falirsirriulator eririöglicht diese Forinulierung eine plausible Berechnung<br />

des Schn-enkmonlents bei allen denkbaren Fahrziistäiitlen.

5.3.8 Rollwiderstand<br />

Aufgrund der ungleichmäßigen Druckverteilung im Latsch greift die Nor-<br />

malkraft FN nicht in der Reifen<strong>mit</strong>te an, sondern um die Exzentrität e~<br />

in Richtung der momentanen Bewegung des Radträgers versetzt. Da-<br />

durch entsteht ein Drehmoment um die Radachse, das stets der Raddre-<br />

hung entgegen wirkt. Der Betrag dieses Rollmoments ergibt sich zu<br />

Die Wirkungsrichtung, d.h. das Sbrzeichen von Atril, wird in Abschnitt<br />

5.4.2 betrachtet. Bildet man das Lfomentengleichgewicht bezüglich der<br />

Radachse,<br />

I<br />

FN . e~ - FRW . rdyn = 0 ,<br />

so erhält man die Rollwiderstandskraft.<br />

<strong>mit</strong> dem Rollwiderstands-Beiwert fRw .<br />

(5.33)<br />

Diese Kraft wirkt in Fahrzeug-Längsrichtung über den Radträger und<br />

die Achse auf den Fahrzeugaufbau und bremst das Fahrzeug ab6.<br />

Der Einfluss der Fahrgeschwindigkeit auf die Rollreibung, wird aufgrund<br />

der vergleichsweise geringen Höchstgeschwindigkeit von Nutzfahrzeugen<br />

vernachlässigt, d.h. der Koeffizient fRF1~ wird als konstant betrachtet.<br />

5.3.9 Einleitung der Reifenkräfte in das MKS<br />

Im Simulationsmodell wird FRur für jedes Rad vorzeichenrichtig zu der<br />

schlupfbedingten Umfangskraft Fu aus (Gl. 5.20) addiert. Da<strong>mit</strong> erhält<br />

man die Gesamt-Umfangskraft<br />

6~urch Summation der Rollwiderstandskräfte aus G1. 5.34 über alle Räder ergibt<br />

sich der gesamte Rollwiderstand des Fahrzeugs in fibereinstimmi~ri~ <strong>mit</strong> G1. 4.41.<br />

Der Rollwiderstand verursacht sowohl bei PKW als auch bei Nutzfahrzeugen einen<br />

erheblichen Teil des Kraftstoffverbrauchs [148].

.Aus Fo,„, sowie der Seitenkraft (Gl. 5.21) und der Normalkraft (GI.<br />

5.3) n-ird für jedes Rad ein Reifenkraft-lTektor gebilciet,<br />

Dieser wird in das radtxägerfeste Koordinatensystcni des Rades traris-<br />

formiert und in das SIAIPLACK-IZIKS eingeleitet (sielie Bild 3.2).<br />

5.4 Bremsen und Raddrehung<br />

5.4.1 Bremsanlage<br />

&Arialog zu Ahschriit t -2.4.7 wird ein stark vereinfacht es Simulationsmodrll<br />

für elektro-pneuri~at~isclie Bremsanlagen verwendet7. Die dynainisehen<br />

Achslasten Fll;., werden jedoch riicht in Abhängigkeit von der Abbremsung<br />

i berechnet (sielie G1. 1.35), sondern ergeben sicli un<strong>mit</strong>telbar<br />

durch Addition der dynamischen Radlasten aus G1. 5.3,<br />

Die Indices l und r bezeichnen das linke und das rechte Rad der<br />

i-ten Achse. Unter Berücksichtigung der vom Fahrer vorgegebenen Soll-<br />

Abbremsung z„l, liefert das l/'Iodell gleiche Bremskräfte für beide Räder<br />

einer Achse,<br />

In1 Folgende11 n-ird <strong>mit</strong> FR die an einem einzelnen Rad wirkeride Brcrnskraft<br />

bezeichnet. Auf die Indices i für die A2chs-Numiner lind !.r fiir das<br />

linke bzw. rechte Rad wird verzichtet.<br />

5.4.2 Raddre hung<br />

In der Simulation ist eine Fallunterscheidung zwischen drehendem<br />

lind stehendem (bzw. blockiertem) Rad erforderlich. Dies gilt inbe-<br />

sondere für HIL-Anlagen ziir Untersuchuiig elektronischer Radschlupf-<br />

Regelungssysterne wie .ABC und ASR (siehe Abschnitt 3.1.5).<br />

7~lternativ karin ein in SIMITLINIi implementiertes Ifodell iur kon\entior~clle<br />

Sutzfahrzeilg-Bremsanlagen verwendet werden [I 193.<br />

153

In Analogie zur Behandlung des stehenden und des bewegten Fahrzeugs<br />

(siehe Abschnitt 4.4.8) wird das am Rad wirkende Drehmoment M, auf-<br />

geteilt. Das hloment setzt sich aus der instationären Umfangskraft<br />

nach G1. 5.20 und dem Antriebsmoment aus G1. 4.24 zusammen8,<br />

Seine \Virkungsrichtung ist unabhängig von der Drehrichtung des Rades.<br />

Das Moment ergibt sich aus der Bremskraft FB (Gl. 5.38) und der<br />

Rollwiderstandskraft FRw. (Gl. 5.34) zu<br />

Es wirkt stets entgegen der Drehrichtung des Rades. Für die Winkelge-<br />

schwindigkeit UR des drehenden Rades gilt der Drallsatz<br />

wobei JR das Trägheitmoment des Rades (Felge <strong>mit</strong> Reifen) um die Radachse<br />

ist. Der Zustandsübergang vom drehenden zum stehenden Rad erfolgt<br />

bei Erkennung eines \Torzeichenwechsels der Raddrehzahl während<br />

eines Simulationsschrittes. Die 77Blockierbedingung" lautet<br />

sign(w~(t + h)) # sign(wR(t)) . (5.42)<br />

Für das stehende bzw. blockierende Rad wird gesetzt:<br />

Der Haftreibungs-Beiwert p~,h zwischen den1 Bremsbelag und der<br />

Bremstrommel bzw. Bremsscheibe der Radbremse ist stets größer als<br />

der Gleitreibungs-Beiwert p ~ (Coulomb7sche , ~ Reibung). Für die Simulation<br />

wird abgeschätzt:<br />

Der Übergang vom stehenden zum drehenden Rad erfolgt, wenn die Summe<br />

der ,,antreibendenR Momente das Haftreibungssnioment der Bremse<br />

übersteigt. Die „LösebedingungC' lautet<br />

-<br />

'~ei nicht angetriebenen Achse11 wird das Antriebsmoment zu Null gesetzt<br />

154

5.5 Lenkung<br />

Zur Berechnung der Lenkwinkel der jiorderräder und zur Er<strong>mit</strong>tlung<br />

des Lenkrad~noments wird ein vereinfachtes Modell der Lenkanlage verwendet.<br />

Durch geeignete I+7ahl weniger Parameter ~virtl eine gute Säherung<br />

für vcrschiedei~e konstruktive Ausführungen vor1 Nutzfahrzeug-<br />

Lenkungen erreicht. Die Elastizitäten und Trägheiten der Lenkanlage<br />

sowie Reibung und Spiel werden nicht berücksichtigtY. Die folgenden<br />

Herleitungen basieren auf den Ausführungen iii [172, 173, 1741.<br />

5.5.1 Lenkwinkel<br />

Bild 5.12: Kinematischer Zusammenhang der Rad-Leiikwinkel <strong>mit</strong> dem<br />

Ackermanris3-inkel<br />

Bei Fahrsimulatoren wird der Lenkradninkel hH vom Fahrer vorgegeben<br />

und von einem Sensor in der Lenkeinheit (Abschnitt 5.7.2) erfasst. Aus<br />

SH werden die Lenkwinkel am linken und rechten Vorderrad berechnet.<br />

Hierbei werden folgende in DIN 70000 definierte Größen verm-endet:<br />

Der <strong>mit</strong>tlere Lenkwinkel 6„, ist das arithmetische Mittel des inneren und<br />

'~ie<br />

auftretenden hohen Eigenfrequenzen sind <strong>mit</strong> der vorgestellten Irerfahrensiveise<br />

im Echtzeithetrieb nunierisch nicht beherrschbar. Eine detaillierte hlodrllierung<br />

der Lerikung für Nicht-Eclitzeit-Annendungen unter Berücksichtigung dieser Ei-<br />

genschaften n ird in [I711 vorgestellt.

äußeren Rad-Lerikwinkels,<br />

Die kinematische Lenkübersetxung is ist der Differenzialquotient des<br />

Lenkradwinkels und des <strong>mit</strong>tleren Lenkkvinkels?<br />

Der Acker~mannwinkel dA ist derjenige Lenkwinkel, der an einem ge-<br />

dachten, einzelnen Rad in der Mitte der ibrderachse eingestellt werden<br />

inüsste, darnit der Fahrzrugschwerpunkt (SP) den gleicher1 Kurvenra-<br />

dius R beschreibt wie bei eiiienl realen Fahrzeug <strong>mit</strong> einer exakt nach<br />

Ackermann ausgelegten Lenkung (Bild 5.12). Wenn to der Radstand des<br />

Fahrzeugs und lh der ,kbstand des Fahrzeug-Schwerpunktes von der Hiri-<br />

terachse ist, so gilt<br />

Die Ackermannschen Gleichungen geben die Abhängigkeit der Lenkwin-<br />

kel am kurvenäußeren und kurveninneren Rad bei exakter Ackermann-<br />

Auslegung an:<br />

cot 6, = cot SA + CG<br />

(5.49)<br />

Die Konstaiite cc beschreibt die Fahrzeuggeometrie, wobei bir den ,\b-<br />

stand der Lenkachsen bei vernaclilässigter Spreizung bezeichnet.<br />

In der Simulation wird unter Verweiidung von G1. 5.47 zunächst der<br />

<strong>mit</strong>tlere Lenkwinkel in *Abhängigkeit des Lenkradwinkels berechnet.<br />

Die Funktion is(hH) ergibt sich aus der Kinematik von Lenkgetriebe,<br />

Lrnkstockhebel und Spur~t~a~ige. Sie karin z.B. aus hlessungen des Bahnradiiis<br />

bei larigsarner Fahrt <strong>mit</strong> verschiederien Lerikradwinkelri bestimmt

werderi. Falls die Er<strong>mit</strong>tlung von is(&) nicht nlöglicli ist, wird in GI.<br />

5.51 die koristaiite Lerikiibersetzung is,o iri Geradeaiisstelluiig vtlrn.er1dt.t.<br />

Der Xckernlannwirikel hA4 aus G1. 5.48 und der rilittlere Lenkwirlkel<br />

6„ nach G1. 5.46 untersclieiden sich bei realen Nutzfal~rzeugen riur ge-<br />

ringfügig, der maximale Fehler beträgt etwa 1 %. In der Siinulation wird<br />

deshalb die Näherung 6„, z verweridet. Durch LTrnforniung der Acker-<br />

manilschen Gleichungen und unter Beriicksicl-itigiirig des J70rspur~+-irikels<br />

6\7 erliält man die Leiikwinkel 6! uiid 6, des linken und rechten Rades1"<br />

aiis den1 rnit t leren Lerikwirikel:<br />

Zusätzlich wird der Xuslegungsfaktor ca4 E (0 . . . 1) eingeführt. Durch<br />

Jyariatiori von CA können unterschiedliche Lenkungs-Auslegungen uriter-<br />

sucht werden. Für CA = 0 ergibt sich eine Parallel-Xuslegiing, cZ4 = 1<br />

gilt für die Auslegung nach Ackermann.<br />

-41s Beispiel wird das in Bild 5.13 dargestellte Lenktrapez eines LKW<br />

betrachtet. Die exakte Berechnung der Lerikkinematik führt auf ein Gleichungssystem,<br />

welches nur iterativ, d.h nicht in Echtzeit lösbar ist [172].<br />

In Bild 5.14 ist der exakte iTerlauf des Lenk-Differerizn-inkels für das<br />

Leriktrapez aus Bild 5.13 dargestellt. Der Leilk-Diffeienzn-i~ikel ist definiert<br />

als Differenz der Lcnk.cvirike1 des jewriligen kiirvc~iiinnrre~l und<br />

kurv(3riäußercn Rades,<br />

Iui Beispiel ist die Kiiiematik so ausgelegt, dass AS hcirn Erreichen des<br />

iiiaxiriialen Lenkeirisclilags (bi,rnX = 40") init dein theoretisrheii Wert<br />

für die ,2ckermarii1-~%uslegung übereiristirii~rit .<br />

tTnter Jkr\~endung von G1. j.52 ergeben sich in Abhängigkeit des Auslegungsfaktors<br />

CA unterschiedliche Näherungen. Im Bild sind beispielhaft<br />

die Verläufe für CA = 1 (Ackermann-Auslegung) und cl = 0.85 dargestellt.<br />

Die meisten realen Lerikanlagen werden bei geeigrieter \\alil xr»n<br />

c 4 liinreichend genau beschrieben.<br />

1031an kaiiri zeigen, dass (.:I. 6.52 sowolil fiir J„, > 0 (Linkirinschlag) als aiicli fiir<br />

6% < U (Reclitsein5clilag) gültig ist. obwohl (r2 i~rid 6„ clic Rollen als innercr und<br />

äiißerer Rad-Leiikurinkcl taiische~i.

4 b"<br />

Lenkachse<br />

r, = 0,28 m<br />

Achskörper<br />

Bild 5.13: Lenktrapez eines LKFY in Geradeausstellung (inassiv) und<br />

bei maximalem Lenkeinschlag (strichliert). Der lrorspurn-in-<br />

kel wird vernachlässigt (Quelle: [l72]).<br />

- - Exakte Rechnung<br />

Näherung <strong>mit</strong> C, = 1,00<br />

- . - . B<br />

- - - Näherung <strong>mit</strong> C, = 0,85<br />

Bild 5.14: Exakter und angenäherter Verlauf des Lenk-Differenzwinkels<br />

in Abhängigkeit des kurveninneren Lenku~inkels (Beispiel)

Die errnittelteri Lenkwinkel und 6, werden in das SII1IPACK-IIKS<br />

eingegeben und dort zur Koordinateritransformatio~i bei der Bereclinuiig<br />

der Relativbewegung zwischen Reifen und Fahrbahn (GI. 5.5) sowie bei<br />

der Einleitung der Reifenkräfte (Gl. 5.36) verwendet.<br />

5.5.2 Lenkradmoment<br />

Zur Berechnung des Rückstellmoments ain Lenkrad wird zunächst das<br />

Lenkmoment Als am linken und recliten Rad der Vorderachse er<strong>mit</strong>telt.<br />

Als ist definiert als Summe aller Ilomente urn die Lenkachse und setzt<br />

sich nach [I741 aus mehreren Anteilen zusarnrneri:<br />

Das Schwenkmoment -liB gemäß GI. 5.27 verursacht heirri stehen-<br />

den Fahrzeug den größten Anteil des Lenkmomeilts.<br />

Bei höherer Fahrgeschwindigkeit und Kurvenfahrt wird das Lenk-<br />

moment vor allem durch das Reifen-Rückstelln~oment AlR nach G1.<br />

5.22 bestimmt. Dieses Moment ergibt sich als Produkt aus Seiten-<br />

kraft und p~leumatischer Nachlaufstrecke.<br />

Ein zusätzliches Rückstellmoment ergibt sich als Produkt<br />

der Seitenkraft Fs (Gl. 5.21) und des Seitenkraft-Hebelarms n„<br />

welcher von der konstruktiven Nachlaufstrecke T?,+ und dem Nach-<br />

laufwinke1 r abhängt.<br />

Dieser Anteil wird bei der Llessung von ,?IR (siehe Bild 5.1 1) i11 der<br />

Regel nicht erfasst, da die llessung ohne koristri~ktiven Nachlauf<br />

durchgefülirt wird [16 I].<br />

Ein weiteres AIoment Als, ergibt sich als Produkt der Längskraft<br />

und des ~än~skraft-Hebelarms T,. Bei schweren Nutzfahrzeugen<br />

<strong>mit</strong> Hinterradantrieb beinhaltet die Längskraft keine -411triebskraft<br />

sondern lediglich die Rollwiderstandskraft hW. Ein<br />

beträchtlicher Beitrag dieses Moments zuIn Lenkradmoment entsteht<br />

durch unterschiedliche Roll~viderstände, z.B. bei einseitiger<br />

~Tasserdurchfahrt. Bei lrernachlässigung des Sturzes (T = 0) gilt<br />

rnit der Spreizung a und dem Lenkrollradius rs:

I<br />

r, = rs . cos o + rdyn . sin o . (5.56)<br />

Das Moment ist das Produkt aus der Bremskraft FB gemäß<br />

GI. 5.38 und dem Bremskraft-Hebelarm r b = rs . cos o. Ein be-<br />

deutender Einfluss auf die Lenkung ergibt sich bei ungleicher Wir-<br />

kung der linken und rechten Radbremse. Unter Berücksichtigung<br />

der Raddrehrichtung erhält man<br />

Das Gewichts-Rückstellrnoment AfsIz entsteht durch Anhebung<br />

das Fahrzeugs beim Schwenken des Rades (Radlast FN) um die<br />

Lenkachse <strong>mit</strong> dem Lenkrollhalbmesser rs und dem Reifenhalb-<br />

I<br />

messer rdyn ,<br />

Ag,, = FN . sin b . (rs + rdyn . tan o) . cos 0 . sin o . cos T . (5.58)<br />

Es weist nur bei nennenswerter Spreizung a und für große Lenk-<br />

winke1 161 >> 0 signifikante Werte auf.<br />

G1. 5.54 bis G1. 5.58 gelten für beide Räder, die berechneten Werte<br />

können jedoch rechts und links unterschiedliche Werte aufweisen. Im<br />

Folgenden werden die für das linke und rechte Rad gültigen Größen des-<br />

halb <strong>mit</strong> einem zusätzlichen Index t bzw. r versehen.<br />

Die gesamten Lenkmorne~ite an1 linken und rechten Rad ergeben sich<br />

durch Addition aller Xlomentenanteile unter Berücksichtigung der Wir-<br />

kungsrichtung, d.h des Vorzeichens, zu<br />

Das Moment hf& an der Lenksäule (ohne Servo-Unterstützung) ergibt<br />

sich durch Division der Lenkmomente durch die jeweilige Gesamtüber-<br />

setzurig und Addition des linken und rechten Anteils,

Die ~bersetzungen ir,[ und irr des Lenkgestänges erhält iiiari diirch<br />

,4bleitung von GI. 3.52 nach derri <strong>mit</strong>tleren Lerikwirikel,<br />

d 6e -<br />

1<br />

V<br />

Z T , ~ = --d<br />

L (COS<br />

da - C„, * cc . sin 6„)2 + sin2 firn '<br />

d6, - I<br />

%T., = -<br />

d L (cos 6, + c_r . ci: . sin 6„,)' + siii' 6„,<br />

5.5.3 Servolenkung<br />

Das Lenksäuleiimoment ,ZI& nach G1. 5.60 erreicht bei schweren Nutzfahrzeugen<br />

im Stand Wert)e von bis zu ca. 300 Nm [169]. Diese Falirzcuge<br />

sirid deshalb stets <strong>mit</strong> einer Lenkhilfe ausge~tatt~et . die zuiiieist als hj-draulisclie<br />

Kugelurnlaufleiikung ausgeführt wird [li3].<br />

Die physikalische llodellierung von Hydrolenkungeii, z.B. [li5], wird in<br />

dieser Arbeit nicht betrachtet. Statt dessen wird die Servolenkung ver-<br />

einfacht als stationärer Zusammenhang zwischen Alk und dem Lerik-<br />

radmoment AlH in Form einer geinessenen Kennlinie abgebildet, die vor<br />

allem den Einfluss der Handlaraftbegrenzung berücksichtigt,<br />

AlH = f(A4;) . (5.62)<br />

Die Kennlinie wird so gewählt, dass ein maximales Lenkradmoment von<br />

ca. 10 Kni nicht überschritten wird. Im Fahrsimulator wird ,\Iri- durch<br />

einen elektrischen Antrieb arn Lenkrad aufgebracht (Ihscliiiitt 5.7.2).<br />

5.6 PC-basierte Echtzeitsimulation<br />

.Abschliefiend wird die Eihtzeitfähigkeit des in diesem Kapitel be-<br />

schriebenen Fahrzeugmodells bei Aiisfülirung aiif gebräuchlidien<br />

Eirizelprocessor-Rechnern nachgewiesen.<br />

Da bei Al~schluss der Arbeit keine ausreichend detaillierten llessdaten<br />

für einen Nutzfahrzeug-Gliederzug verfügbar sind, können einige Para-<br />

meter des in Abschnitt 5.2 beschriebenen MKS nicht exakt bestimmt<br />

werden. Dies betrifft insbesondere die Geometrie und die Trägheitstenso-<br />

ren der verschiedenen Starrkörper, deren Er <strong>mit</strong> tlung bei sch~veren Nutz-<br />

fahrzeugen aufwändig ist. Da jedoch diese Größen das Fahrverhalten<br />

entscheidend beeinfliissen, wird aiif die qiiarititati~e Darstelluiig voii Si-<br />

rnulationsergebnissen für falirdynamische Ilanöver (z.B. Kreisfahrt und<br />

Spilrivechsel) verzichtet.

Tabelle 5.1: Verwendete Echtzeit-Rechnersysteme zum Nachweis der<br />

Portabilität (Stand: 1999)<br />

Prozessor-Typ<br />

DEC Alpha, 500 MHz<br />

Intel Pentium 11, 350 MHz<br />

hlotorola MPC 604, 200 Mhz<br />

5.6.1 Port abilit ät<br />

Compiler<br />

GNU C++<br />

Watcom C++<br />

GNU C++<br />

Betriebssystem<br />

dSpace RTI<br />

RealLink/32<br />

Lynx OS<br />

Zunächst wird untersucht, ob die in Abschnitt 2.2.1 geforderte Poitier-<br />

barkeit des generierten Programm-Codes durch das beschriebene Verfah-<br />

ren zur Kopplung von MKS-, FSAI- und CACE-Werkzeugen gewährleis-<br />

tet wird. Diese Untersuchung wurde bereits im Jahr 1999 durchgeführt.<br />

Aufgrund der geringen Verarbeitungsleistung und des beschränkten Spei-<br />

cherangebots damaliger Einzelprozessor-Rechner wird das vereinfachte<br />

SIMPACK-MKS eines zweiachsigen Zugfahrzeugs <strong>mit</strong> 10 Freiheitsgraden<br />

ohne Anhänger verwendet. Die Beschreibung folgt in Abschnitt 5.6.3.<br />

Dort wird dieses MKS als Variante a) bezeichnet.<br />

Die weiteren Modellteile (Reifen, Raddrehung, Bremsen und Lenkung)<br />

sind in SIMULINK implementiert und entsprechen den Ausführungen in<br />

den vorangegangenen Abschnitten.<br />

Aus dem SIMULINK-Modell <strong>mit</strong> dem eingebundenen NKS wird C-Code<br />

unter Verwendung des Code-Generators RTIV erzeugt. Mittels eines C-<br />

Compilers und eines Linkers wird jeweils ein ausführbares Programm für<br />

die in Tabelle 5.1 aufgeführten Rechriersysteme erstelltll.<br />

Auf allen betrachteten Systemen ist eine numerisch stabile Ausführung<br />

des Simulationsprogram~ns <strong>mit</strong> einer Schrittweite unter 2 ms möglich.<br />

Die Berechnungsergebnisse sind identisch.<br />

Es ist davon auszugehen, dass eine Ausführung der generierten Software<br />

auf weiteren Kombinationen von Rechner und Betriebssystem möglich<br />

llDie Liste umfasst einen repräsentativen Ausschnitt der damals gebräuchlichen<br />

Rechnertechnik, erhebt jedoch keinen Anspruch auf Vollständigkeit. Einige der<br />

aufgeführten Produkte sind bereits drei Jahre später nicht mehr verfügbar, was<br />

als weiteres Argument zugunsten der geforderten Portabilität betrachtet werden<br />

kann.

ist, sofern ausreichende Ressourcen verfügbar sind.<br />

5.6.2 Numerische Integration<br />

Seit dieser Untersuchiing ist ein rapider Anstieg der verfügbaren Pro-<br />

zessorleistung zu verzeichnen. Dies gilt insbesondere für Personal Coln-<br />

puter (PCs) <strong>mit</strong> Prozessoren der Hersteller Intel und Ah1D. Aufgrund<br />

der geringen Kosten kann eine Simulationsarilage auf PC-Basis in kurzen<br />

Zeitabständen auf die jeweils neueste Generation umgestellt werden.<br />

Für die folgenden Betrachtungen wird als Echtzeit-Rechner ein Industrie-<br />

PC <strong>mit</strong> dem Prozessortyp .,L4hlD Athlon 1800 XP" eingesetzt. Als Be-<br />

triebssystem dient ein hllikrokerri <strong>mit</strong> der Bezeichniing ..XPC Target".<br />

welcher als Bestandteil der ?rlXTL.AB-Produktreihe angeboten viiid.<br />

Zunäcllct werden verschiedene \erfahren zur numerischen Integration<br />

des Differenzialgleichungs-Systems für das beschriebene Fahrzeugmodell<br />

verglichen. Zur Erläuteriing der \erfahren wird auf 195, 961 verwiesen.<br />

EULER : Das Euler-Vorm-ärts-lTerfahren (1. Ordnung)<br />

HEUN : Ein modifiziertes Runge-Kutta-Verfahren 2. Ordnung<br />

RK4 : Das „klassische '' Runge-Kutta-Verfahren 4. Ordnung<br />

Für das XlKS eines Nutzfahrzeiig-Gliederzuges (Abschnitt 5.2) in TTer-<br />

bindung <strong>mit</strong> den hlodellariteilen für Reifen, Bremsen und Lenkung wird<br />

enipirisch die maximal zulässige Zeitschrittweite h„„ bestimmt, bei der<br />

eine numerisch stabile Lösung für alle auftretenden Falirzust ände gege-<br />

ben ist.<br />

Die Ergebnisse sind in Tabelle 5.2 dargestellt. Der Quotient aus maximaler<br />

Schrittweite h„„ und Anzahl 7 1 der ~ Berechnungen der rechten<br />

Seite des Differerizialgleichungs-Systems pro Zeitschritt stellt ein h4aß<br />

für die Effizienz der riiimerischen Iiitegrations~erfahren dar. Es zeigt<br />

sich, dass die Verfahren HEUN und RKl einen vergleichbaren Berechnungsauf~varid<br />

erfordern. Dagegen ist das EULER-Verfahren wesentlich<br />

ineffizienter und da<strong>mit</strong> für die vorliegende Anwendung wenig geeignet.<br />

5.6.3 Rechenzeitbedarf<br />

Die Auswertung der Bea~egungsgleichungeii für das I1KS beaiispruclit<br />

einen ~vesent lichen Anteil der gesamten Rcchen~~it. Dieser Anteil wachst

Tabelle 5.2: Eigenschaften verschiedener numerischer Integrationverfah-<br />

ren für ein beispielhaftes Simulationsmodell<br />

a) .<br />

b) .<br />

Integrationsverfahren<br />

Maximal zulässige Schritweite<br />

für das Beispiel-Modell (h„,)<br />

Anzahl Berechnungen der rech-<br />

ten Seite pro Zeitschritt (nß)<br />

,.Effizienzii (h„, InB)<br />

Modell-Variante<br />

..<br />

. ..<br />

. ..<br />

C) I- --<br />

d, ..<br />

EULER<br />

0,5 ms<br />

Bild 5.15: Yerarbeitungszeiten für verschiedene Modell-Varianten bei<br />

ITerwendung eines Echtzeit-Rechners <strong>mit</strong> dem Prozes~ort~yp<br />

?: AMD Athlon 1800 XP"<br />

1<br />

0,s ms<br />

Beschreibung<br />

Zweiachsiges Zugfahrzeug,<br />

<strong>mit</strong> starrem Aufbau,<br />

Fahrerhaus starr <strong>mit</strong> dem<br />

Aufbau verbunden<br />

Zugfahrzeug wie Variante a),<br />

zweiachsiger Anhänger<br />

<strong>mit</strong> starrem Aufbau und<br />

Drehschemellenkung<br />

HEUE<br />

2,1 ms<br />

Dreiachsiges Zugfahrzeug,<br />

<strong>mit</strong> Rahmentorsion,<br />

elast. Fahrerhauslagerung<br />

und Ladungsverschiebung<br />

Zugfahrzeug wie Variante C),<br />

dreiachsiger Anhänger <strong>mit</strong><br />

Rahmentorsion, Drehschemellenkung,<br />

Ladungsverschieb.<br />

2<br />

1,05 ms<br />

SK<br />

3<br />

7<br />

7<br />

14<br />

RK4<br />

4>4 ms<br />

4<br />

1.1 ms<br />

FHG<br />

10<br />

21<br />

16<br />

30<br />

t, (ms)<br />

0,23<br />

0,62<br />

0,33<br />

1,56

<strong>mit</strong> der Anzahl der Starrkörper und Freiheitsgrade sowie der Anzahl iirid<br />

Art der Gelenke und Kraftelemente des hIKS an. Iiii Echtzeitbetrieb<br />

ist die mögliche hlodell-Komplexit ät begrenzt, da gemäß Abcclinit t 2.1<br />

die Verarbeiturigszeit ti- für jeden Zeitschritt kleiner sein muss als die<br />

Schrittweite h. Diese wiederum wird durch die riunierischen Eigenschaf-<br />

ten des hlodells begrenzt, wie in Abschnitt 5.6.2 ausgeführt wurde.<br />

Um Anhaltswerte für die Abhängigkeit der Rechenzeit von der Koniple-<br />

xität des 3IKS zu erhalten, werden zusätzlich mehrere vereinfachte la-<br />

rianten des in ,Ibschnitt 5.2 beschriebenen SIhIPACK-AIKS erstc4lt und<br />

unter Eirisc>hluss der Teilnioclelle für Reifen, Raddrehung. Brerriseii uritl<br />

Lenkung auf einem P C-basiert eri Echtzeit-Rechnt.rsyst clm irriplerrierit icrt .<br />

In Bild 5.15 ist cler st rukturclle Aufbau der hIodcll-I'ariariteri sowie die<br />

LAri7.ah1 der Starrkörper (SEI;) und Freiheitsgrade (FHG) angegeben. Die<br />

larianteii C) uiltl d) entsprecheri den Ausfiihrung~n<br />

in Xbscliiiitt 5.2.<br />

Die C4esamtzahl der Freiheitsgrade erhält man für j~de lrariante durch<br />

Addition der FHG-Anzahlen der Einzelhewegu~~gen (siehe auch Bild 5.3<br />

und Bild 5.3):<br />

Variante a) Räumliche Bewegung des Fahrzeug-i4ukaus gegenüber<br />

dem ortsfesten Koordinatensystem (6 FHG) , Einfederung und<br />

Wankbeu-egung der lTorder- und Hinterachse gegenüber dem ,4uf-<br />

bau (je 2 FHG). Summe: 10 FHG.<br />

Variante b) Zugfahrzeug <strong>mit</strong> 10 FHG wie Variante a). Zusätzlicher<br />

Anliänger snit I1 FHG: Aufbau-Bewegung gegeniiber dern ortsfes-<br />

tcri Koordinatesisystem (6 FHG), Eiiifedcrurig uncl iV~rili1)eweguiig<br />

der 1ordf.r- urid Hinteracxhsc gegenüber dern Aiikaii (jc 2 FHC;).<br />

Drcl~schciiicllerikiilig (I FHG). Siinirric: 21 FHG.<br />

Variante C) Zugfahrzeiig <strong>mit</strong> folgeiideri zusätzlicheii FHG gegenüber<br />

lrariante a): Zweite Hinterachse <strong>mit</strong> Einfederung und Jiankben-e-<br />

gung gegeniiber dem Aiifbau (2 FHG), Torsion des Falirzeiigrah-<br />

mens um die Längsachse (1 FHG), elastische Lagerung des Fahrer-<br />

haiises <strong>mit</strong> Eiiifederiing. Nick- uncl IVanlcbewegung (3 FHG). Die<br />

translatorische lerscliirbiitig der Ladiing wird \.On außcn 1-orge-<br />

geben (eingeprägt) und bewirkt im hIKS-Sinne keine ziisätzliclien<br />

Freiheitsgrade. Sunime: 16 FHG.<br />

Variante d) Ziigfahrzeug iiiit 16 FHG \T-ie Variarite C). Aiiliäriger rriit<br />

14 FHG. ziisätzliclie FHG gegcniibcr d~rri AInhängcir aus \-ariante<br />

1)) : Zii-eite Hiiitcraclise niit Einf~deriirig iirid Vank~ii gegciiiibri.

Aufbau (2 FHG), Rahnientorsion (1 FHG) , eingeprägte Ladungs-<br />

verschiebung (0 FHG). Surnnie: 30 FHG.<br />

Für jede Variante wird die in Abschnitt 2.1 definierte lTerarbeitungszeit<br />

h- pro Zeitschritt gemessen. Als Integrationsverfaliren wird jeweils das<br />

HEUN-Ierfahren <strong>mit</strong> einer Schrittm-eite -\-On h = 2 ms eirigesetzt,.<br />

Die er<strong>mit</strong>telten Werte für tv sind ebenfalls in Bild 5.15 eingetragen.<br />

Qualitativ zeigt sich, dass die Verarbeitungszeit für einfache SIMPXCK-<br />

h1KS <strong>mit</strong> weniger als 20 Freiheitsgraden in etwa linear rriit der Anzahl<br />

der Freiheitsgrade ansteigt. Bei komplexeren hIKS erfolgt ein progres-<br />

siver Anstieg, jedoch kann auch die aufwändigste Variante d) auf dem<br />

gewählten Rechnertyp problenilos iri Echtzeit berechnet m-erder-i. Da die<br />

verfügbare Rechenleistung Iveiterliin rascli ansteigt, ist davon auszuge-<br />

hen, dass zukünftig noch wesentlich komplexere llehrkörperniodelle iri<br />

Echtzeit auf preiswerten, PC-basierten Rechnern ausführbar sind.<br />

5.7 Labor-Fahrsimulator<br />

5.7.1 Übersicht<br />

Das I-orgestellte Fahrdynamik-Sirnulationsmdell wird auf einem Labor-<br />

Fahrsiniulator implementiert, der aus rnehrereri IIodulen besteht:<br />

Ergonomisch gestalteter Fahrerplat z,<br />

Lenkeinheit <strong>mit</strong> elektrischem Riickst ell- Arit rieb,<br />

Pedalerie <strong>mit</strong> mechanischer Nachbildung der Rückstellkräfte,<br />

austauschbarer Schalthebel,<br />

Kombiinstrument ,<br />

Geräuschmodul für Fahrzeuggeräusche,<br />

Echtzeit-Visualisierung der Fahrzeugbewegung und<br />

Industrie-PC als Simulationsrechner.

Bild 5.16: Gesanitansicht des Labor-Fahrsilnulators<br />

Bild 5.16 zeigt eine Gesamtansicht der Aiilage. Der inechanische urid<br />

elektrische -1iiflJau wird iri [13] beschriebeiil? .i2irsgen.ählte 3locllile der<br />

1Iensc.h-Maschine-Schnittstelle IX-erden im Folgriideri naher betrachtet.<br />

5.7.2 Lenkeinheit<br />

liirgcstellt wird ein akt,ives Leiikmodul zur Darstellung der<br />

Lenkinoirierit-Rückn-irkiing bei Fahrsiiriulatoreli. Das I\fodul erzeugt<br />

arri Lenkrad ein maximales Dauerrnonient von ~ 2 1 = ~ 5.2 , ~ Nni<br />

und eil1 Spitzeninolnent vo~i ,= 16 Nm. Alit deni Durchmesser<br />

dH = 360 rnin des rerweiideten ~Lnkrads ergibt sich eine rnaxin~alc<br />

Lenkrad-Umfangskraft voii FH = 89 N 11761. Der dynamische llomeiitenaufbau<br />

erfolgt binrien TH < 20 ms. Mit dieser ,\uslegung wird der<br />

Lenkirioment-Bereich rnod~rrier PKW urid Nutzfahrzeuge <strong>mit</strong> Lenkhilfc<br />

abgedeckt [172].<br />

"»er -4utor dankt der Porsche AC: für die freundlicfie Ber-eitqtrllung rilliger SrriPri-<br />

koniporient~n<br />

des Borster.

Lenkrad Servoantrieb Winkelgeber<br />

(Wickel band) riemen<br />

Bild 5.17: Konstruktiver Aufbau der Lenkeinheit<br />

Aus Bild 5.17 geht der konstruktive Aufbau hervor. Ein Grundrahmen<br />

(nicht dargestellt) nimmt eine höhenverstellbare Lenksäule <strong>mit</strong> montier-<br />

tem Lenkrad auf. Das nach (GI. 5.62) berechnete Lenkradmoment wird<br />

von einem Servoantrieb erzeugt [I771 und durch einen spielfreien Zahn-<br />

riementrieb <strong>mit</strong> der Übersetzung iLM = 4 auf die Lenksäule übertragen.<br />

Die Übersetzung ermöglicht den Einsatz eines hfotors <strong>mit</strong> relativ gerin-<br />

ger elektrischer Leistung, wodurch das frlodiil kompakt und preiswert<br />

realisierbar ist.<br />

Der Motorwinkel SLhl sowie die Wfotordrehzahl WLM wird durch Sensoren<br />

erfasst und in die Simulation zuriickgeführt. Mit der Übersetzung iLnr<br />

wird der Lenkradwinkel SH sowie die Lenkrad-LYinkelgeschwindigkeit, WH<br />

berechnet. Diese Werte stellen Eingangsgrößeri des Fahrzeugmodells dar<br />

(siehe Bild 5.1). Da<strong>mit</strong> ergibt sich ein geschlossener Regelkreis zwischen<br />

Fahrer, Lenkeinheit und Fahrzeugmodell.<br />

5.7.3 Visualisierung<br />

Die Visualisierung der Fahrzeugbewegung und der Fahrbahn erfolgt<br />

in Echtzeit durch ein OPEN-GL-Programm, das auf einem separa-<br />

ten Rechner ausgeführt wird. Die grafische Repräsentation des Fahr-<br />

zeugs stimmt <strong>mit</strong> der in Bild 5.3 dargestellten Struktur des SIMPACK-<br />

hIKS überein, d.h. die Grafik weist die selben Starrkörper und Gelenk-<br />

Freiheitsgrade auf. Dadurch können die vom MKS errechneten verall-<br />

gemeinerten Koordinaten un<strong>mit</strong>telbar zur Ansteuerung des Grafikpro-

Bild 5.18: Moment aufnahriie der Echt zcit-Visualisierurig<br />

gramms verwendet werden. Die Ankopplung an die Simulation erfolgt<br />

wahlweise über RS 232, CAN oder Ethernet. Zusätzlich kann ein beliebiger,<br />

ebener Fahr bahnverlauf vom Anwender vorgegeben und grafisch<br />

dargestellt werden [178]. In Bild 5.18 ist eine Iblomentauf~lahrne der<br />

Echtzeit-Visualisierung dargestellt.<br />

5.8 Geräuscherzeugung<br />

Akustische MTalirnehniungen liefern dern Fahrer wichtige Informationen<br />

zum Betriebszustand seines Fahrzeugs und beeinflussen seine Handlungen.<br />

Beispielsiveise erfasst ein geübt er Falirer anlland tles Ifotorgeräusclies<br />

die Drehzahl und leitet daraus die Schaltpunkte ab. Auch<br />

Reifen- und IVindgeräusche erlai~beri Rückschlüsse auf den Fahrzustand.<br />

Deshalb sind Geräusclie bei Fahrsiniulatoreti von großer Bedeutung.<br />

5.8.1 Einführung<br />

Zur Generierung von Geräuschen auf elektronischem \Veg sind verschie-<br />

dene Verfahren bekannt, die insbesondere bei elektroliischeri hlusikin-<br />

strumenten [179], vereinzelt aber aucli zur Nachbildung von .\I aschinen-<br />

geräuschen eingesetzt werden. Synthetische Verfahren wie die Pourier-<br />

s ynthese und dit~ Frequenzvi odulatim [I SO] koiiimt-ri oliiir aiif~i-äiidige

Aufnahmen von Originalgeräuscheii aus, sie liefern jedoch keine realisti-<br />

schen Klänge. Beim Wuuetable- Verfal~ren wird eine Periode eines natürli-<br />

chen, periodisclien Geräusches digital aufgezeichnet und bei der Wieder-<br />

gabe zyklisch wiederholt [181]. Durch gewichtete Addition verschiedener<br />

Proben wird ein besserer Höreindruck als bei synthetischen \'erfahren<br />

erreicht. In [182] wird ein digitaler Geräuscherzeuger für Fahrsirriula-<br />

toren beschrieben, dessen Arbeitsweise niit den1 Wa\-etable-iTerfal1ren<br />

vergleichbar ist.<br />

Im Folgenden wird ein neues, digitales Verfahren zur dynamischen<br />

Geräusch-Simulation am Beispiel der Erzeugung von i\lotorgeräuschen<br />

beschrieben. Das Verfahren wurde patentiert [183].<br />

5.8.2 Grundlagen des Verfahrens<br />

Das Verfahren basiert auf dem Grundgedanken, dass die meisten kon-<br />

tinuierlichen Fahrzeuggeräusche ITon einem oder mehreren unabhängi-<br />

gen Parametern pi . . . pb abhängen. Als Parameter werden physikalische<br />

Größen bezeichnet, die sich während des Fahrbetriebs kontinuierlich oder<br />

in Stufen verändern und sich auf das Geräusch auswirken.<br />

Zwei Klassen von Parametern werden definiert:<br />

Ein Frequenzparameter bewirkt eine proportionale Ierschiebung der<br />

im Frequenzspektruni enthaltenen Anteile. Im Allgemeirien n-ird zusätz-<br />

lich eine hderung der Arnplitiideii bewirkt.<br />

Bild 5.19 verdeutlicht dies arn Beispiel des gemesseneii Geräuschspek-<br />

t rums eines J'ierzylinder-0 t to-Reihenmotors in Abhängigkeit von der<br />

hfotordrehzahl. die eiiien Frequenzparaineter ini Sinne dieser Defini-<br />

tion darstellt. Die dunklen Bereiclie repräseiitiereri Schallpegel über<br />

60 dB(A). Die zugehörigen Frequenzen f, werden als Sfotorordnuiigeii<br />

bezeichnet und sind 17ielfache der halben Kurbelwellendrehzalil n~r.<br />

Ein Amplitudenparameter bewirkt eine *4nderung der Amplituden<br />

der Spektralanteile eines Geräusches, jedoch keine Frequenzverschie-<br />

bung. Beispielsweise stellt das Drehmoment eines ITrrbrennungsriiotors<br />

einen Arnplit udenparameter dar.

Bild 5.19: Gemessenes Frequenzspektrum eines Verbrennungsmotors in<br />

Abhängigkeit von der Drehzahl (Quelle: <strong>FKFS</strong>). Pegel über<br />

60 dB(A) sind dunkel dargestellt.<br />

5.8.3 Geräuschaufnahme<br />

-Als Grundlage zur Geräuscherzeiigung werden Stichproberi 1-ori Origi-<br />

rialgeräusche~i ver~vcndet, die bei einer hegreiizten Alrizalil stationärer<br />

Bet riebspunkt e eiries 124otors alifgeiioriirnen I\-erderi. ,Als Bet rie1)spulikt<br />

Zi„„ wird die Paraiiieterkornbiriation bczeichiict , bei der ririe Stirshprobe<br />

aufgenonimeri wird.<br />

In Bild 5.20 ist ein Ausschnitt aus einen1 Schema zur ,%ufnahme von<br />

Geräuschprobeii eines \lTerbrennungsrnotors dargestellt. Die Stichproben<br />

Szj werden bei logarithmisch abgestuften Drehzahl~~erte~i ra~f,, (liier im<br />

Terzabstand) aufgenonimen, da auch die Wahrnehmung von Tonliöhen<br />

diirch das nienschliche Gehör nähcrungsweise logaritliniiscli erfolgt [184].<br />

Für jeden Drelizaliln-ert werden Proben bei verscliiedenen Lastziiständen<br />

Jll.~i aufgcrioinmen. Die iiorrriirrtr Gri'>Be tnr re~>räse~iticrt eritn-eder die

Bild 5.20: Zweidimensionale Parameter-Matrix zur Aufnahme von Ge-<br />

räuschproben eines Verbrennungsmotors (Ausschnitt)<br />

Fahrpedalstellung oder das Motordrehmoment.<br />

Periodische Geräusche weisen im stationären Betrieb häufig stochasti-<br />

sche Unterschiede zwischen einzelnen Perioden auf. Bei Ierbrennungs-<br />

motoren werden diese durch abweichende Brennverläufe bei einzelnen<br />

Arbeitsspielen verursacht. Die JViedergabe dieser Abweichungen in der<br />

Simulation ist entscheidend fiir einen natürlichen Höreindruck. Deshalb<br />

muss die Aufnahmedauer Ts einer Stichprobe wesentlich größer als die<br />

Periodendauer T, gewählt werden und einem ganzzahligeri Vielfachen<br />

von T, entsprechen,<br />

Für hIotorgeräusche soll jede Stichprobe mindestens 20 Arbeitsspiele<br />

umfassen. Bei der Leerlaufdrehzahl nnl FZ 800 min-I entspricht dies ei-<br />

ner Aufnahmedauer von 3 Sekunden.<br />

Die aufgenommenen Stichproben werden <strong>mit</strong> der konstanten Frequenz<br />

f A,„., abgetastet, digitalisiert und gespeichert,.

5.8.4 Geräuscherzeugung im Simulationsbetrieb<br />

Im Simulationsbetrieb werden dynaiiiische Fahrzeuggeräusclie für beliebige<br />

Betriebspunkte durch mehrdimensioliale Interpolation erzeugt. Das<br />

Geräusch für einen Betriebspunkt Ci„, = (i>i,sini, . . . , pb.s,nl) entsteht<br />

stets durch Tkrknüpfung von 2"tichproberi, deren originale Parameterwerte<br />

&, die geriiigsten ;Ibweichungen gegenüber jsim aiifweisen. Irn<br />

Beispiel gemäß Bild 5.20 wird das Gesamtgeräusch Sg„ aus deri Stichproben<br />

S32? S33? S42 und S13 erzeugt.<br />

Hierzu werden bei der Wiedergabe mehrere Signalverarbeitungs-Schritte<br />

auf alle relevanten Stichproben aiigewandt. Diese Schritte weiden irn<br />

Echtzeit-Betrieb in riachstehender Reihenfolge ausgefiihrt:<br />

Schleifenbildung: Da die Dauer der aufgezeichneten Stichproben le-<br />

diglich einige Sekunden umfasst. werden diese zur Erzeugung kon-<br />

tinuierlicher Geräusche zyklisch wiederholt.<br />

Variation der Abtastfrequenz: Bei Variation eines Frequenzpara-<br />

rneters wird die Wiedergabe-Abtastfrequenz f;z,i j,sim einer Stich-<br />

probe Sij proportional gegenüber der Aufnahme-Abtastfrequenz<br />

fA,oTg verändert. Bei Variation der Motordrehzahl gilt<br />

n ist die Drehzahl bei Aufnahme der Stichprobe Sv. Alit<br />

nn~.~„, wird die niomentaiie Drehzahl bezeichnet, für die in1 Sirnulatiorisbetrieb<br />

ein l\lotorgeräuscli erzeugt wird.<br />

Im Beispiel (Bild 5.20) werden die Proben S3') und SQ3 schneller,<br />

die Proben S4? und Si3 langsamer wiedergegeben. Dadurch werden<br />

die erwähnten Rlotorordriungeli in den Spektren aller beteiligten<br />

Stichproben zu den Frequenzen verschoben, bei deneri sie nach GI.<br />

5.63 für die Drehzahl n ~ zu erwarten , ~ sind13. ~ ~ ~<br />

Amplitudenmodulation und Mischung: Für jede Stichprobe wird<br />

eine Gewichtsfunktion in Anhärigigkeit aller b Parameter definiert,<br />

d.h. es werden so\$-ohl E'i-equenz- als auch Amplitudenparameter<br />

berücksichtigt,<br />

'%1lerdings nrerderr dabei auch frequenzfeste, durch Resonanzen bedingte Ariteile des<br />

Geräusches verschoben. Bei hohen Pegeln dieser Xriteile entsteht ein unnatürlicher<br />

I-Iöreiridruck. Deshalb sollen bei der Aiifnahnie Drchzahl~n ~~er.inieder1 werden, bei<br />

denen Resonanzen auftreten.

Bild 5.21: Gewichtsfunktionen in Abhängigkeit von der hlotordrehzahl<br />

Bild 5.21 verdeutlicht dies beispielhaft für den eindimensionalen<br />

Fall, (b = 1). Hierbei wird angenommen, dass das Motorgeräusch<br />

nur von dem Parameter n~ abhängt. Zur Bildung des Gesamt-<br />

Geräusches Sges werden zunächst die Abtastfrequenzen aller Stich-<br />

proben Si gemäß G1. 5.66 verändert. Anschließend werden diese<br />

modifizierten Stichproben S$ <strong>mit</strong> den zugeordneten Gewichtsfunk-<br />

tionen Ai multipliziert und aufsummiert,<br />

Dies führt zu einer linearen cberblendung von einer Stichprobe zur<br />

nächsten und bewirkt die gewünschte Interpolation des Geräiisches<br />

bei kontinuierlicher Variation der hlotordrehzahl.<br />

Im mehrdimensionalen Fall, d.h. bei lTariation mehrerer Parameter<br />

pl . . .pb: werden für jede Stichprobe zunächst b Teil-Gewichtsfunktionen<br />

Apl (p,) . . . -4pb (pb) analog zu Bild 5.21 definiert. Durch Multiplikation<br />

erhält man die mehrdimensionalen Gewichtsfunktionen<br />

Das Gesamt-Geräusch ergibt sich wiederum diircli Gewichtung und Ad-<br />

dit ion aller Stichproben.

5.8.5 Technische Realisierung<br />

Das beschriebene Verfahren wird zur Erzeugurig von hlotorgerä~is~hen<br />

beim Labor-Fahrsimulator in einer elektronischer1 Geräuscherzeugiings-<br />

Einheit implementiert. Die Anlage ermöglicht die Variation der Parame-<br />

ter Motordrehxahl und Motormoment iin Echtzeitbetrieb. Diese \leite<br />

werden irn Simulationsmodell er<strong>mit</strong>telt iind dein Geräuscherzeuger über<br />

eine seridle Schnittstelle zugeführt [183]. Eirie detailliertr rnatheniati-<br />

sche Formulierung des Verfahrens und eine technische Beschreibung der<br />

TTorricht1iiig zur Geräuscherzeugiiiig findet sich in [183].

6 Schlussbemerkung und Ausblick<br />

Mit der in dieser Arbeit vorgestellten Verfahrensweise können echt-<br />

zeitfähige Simulationsprogramme zum Einsatz in Fahrsimulatoren zu-<br />

verlässig und effizient erstellt werden. Am Beispiel des Antriebs, der<br />

Fahrdynarnik und der <strong>Elektronik</strong> schwerer Nutzfahrzeuge wird nachge-<br />

wiesen, dass die aufwändige manuelle Erstellung von Programm-Code<br />

durch den Einsatz moderner Software-Merkzeuge <strong>mit</strong> automatischer<br />

Code-Generierung vermieden werden kann.<br />

Bedingt durch den raschen Anstieg der verfügbaren Rechenleistung sind<br />

heute wesentlich komplexere MKS-Liodelle der Fahrzeugdynamik in<br />

Echtzeit auf Einzelprozessor-Rechnern ablauffähig als noch vor wenigen<br />

Jahren. Es wird festgestellt, dass insbesondere PCs als Echtzeit-Rechner<br />

eine außerordentlich hohe iTerarbeit ungsleist ung bei vernachlässigbaren<br />

Kosten bereitstellen. Die Portabilität des Programm-Codes, welcher<br />

vollständig in ANSI-C vorliegt, erlaubt eine Implementierung der Simulationsmodelle<br />

auf unterschiedlichen Rechnertypen. Im Hinblick auf die<br />

stets begrenzte Lebensdauer proprietärer Lösungen (man denke an das<br />

,,Aussterbenu der Transputer-Parallelrechner) stellt dies einen wesentlichen<br />

Beitrag zur Sicherung der beträchtlichen Investitionen in Simulationsmodelle<br />

dar.<br />

Anhand des CAN-Protokolls wird ein Weg zur systematischen Einbin-<br />

dung von elektronisch geregelten Kfz-Komponenten <strong>mit</strong> hohem Vernet-<br />

zungsgrad in die Echtzeitsimulatiori aufgezeigt. Als besonders effizient<br />

erweist sich die <strong>Einbindung</strong> realer Steuergeräte und Aggregate nach<br />

dem Hardware-in-the-Loop-Verfahren sowie die Nachbildung von Steuer-<br />

geräte-Funktionen im Simulationsmodell unter Verwendung von CA4CE-<br />

und FSM-Werkzeugen.<br />

Durch zwei realisierte: funktionstüchtige Fahrsimulatoren für unter-<br />

schiedliche Anwendungen (ASG und Fahrdynamik) wird die praktische<br />

Anwendbarkeit der beschriebenen lTerfahrensweise bestätigt.<br />

Aufgrund des zu erwartenden, weiteren Anstiegs der Rechenleistung ist<br />

zukünftig eine weitere Erhöhung der Modellkomplexität bei Echtzeit-<br />

Anwendungeti möglich. Zur Erfassung höherfrequenter Schwingungen

erscheint eine Darstellung des Antriebsstranges als dreidimensionales<br />

hlelirk6rperniodell und dessen Einbindurig iri (las h1KS der Fahrzeugdy-<br />

namik sinnvoll. Aus (lern gleichen Grund ist eine vcrh~sserte Xbbil-<br />

dung der Lenkung niit Elastizitäten und bewegten Massen anzustreben.<br />

Die Berücksichtigung von kurzwelligen Fahrbahn-Unebenheiten erfor-<br />

dert den Einsatz eines Reifenmodells <strong>mit</strong> detaillierter Betrachtung der<br />

Druckverteilung in der Kontaktläche. Aufgrund hohen Rechenaufwands<br />

solcher hIodelle bestellt hierbei noch erheblicher Forschungsbedarf.<br />

Abschließend sei betorit, dass das beschriebene 'CTorgehen lediglich mat<br />

liernatische Forniiilicriingeri, z .B. l-ori Bewegurigsgleichurige11. sowie die<br />

Lrnsetzu~ig iri ausführbaren Programrri-Code erleichtert. Die eigentliche<br />

Alodellbildung n-irtl hierdiirch keineswegs vereirifaclit, auch n-rnri dies t-ori<br />

den Herstellern rriaricher Soft\varc-IVerk7e11gc siiggcriert n-ird.<br />

Die sorgfältige Erstellung und i7alidieriing der Motlelle ist jedoch von<br />

zentraler Bedeutung für die Aiissagekraft jeder Simulation urid da<strong>mit</strong><br />

fiir die Glaubn-iircligkeit ihrer Protagoriisteri. Diese koniplexc ,4iifgab~<br />

erfordert heute wie zukünftig fundierte Faclikeririt riisse tler Fahrzeug-<br />

und hIotorentechnik und anderer Fachgebiete, die an der stetiger1 TVei-<br />

t erent \T-icklung des Kraftfahrzeugs beteiligt siricl.

Literatur<br />

[l] Winterkorn, M.; König. H.: Der neue VW Polo. ATZ, Bd. 103<br />

(2001), Nr. 12: S. 1116-1127.<br />

[2] Beinke, R.; J .K., IY.: Driuing Sinaulator. (Autoniotive Safety Se-<br />

minar) Gerieral hlotors Corporation, 1969.<br />

(31 Richter, B.: Beitrag zum Problem der Beschleunigungssinll~lierung<br />

an Fahrsimulator.en. TU Berlin, Dissertation: 1971.<br />

[4] Käding, JT.; Hoffnieyer, F.: The aduanced Daimler-Benz driving<br />

simulator. SAE Paper (1995), Nr. 950175.<br />

[5] Freeman, J. et al.: The Iowa Driuing Simulator: an implementation<br />

und application overview. SAE Paper (1995): Nr. 950174.<br />

[6] Chikamori, S.; Kobayashi, M.; Shimizu, Y.: Structuring neural net-<br />

work: driver model. FISITA Paper (2000), Nr. F20001405. XXVIII<br />

FISITA Congress, Seoul.<br />

[7] Hochstaedter, A.; Zahn, P.; Breuer, K.: Ein uniuerselles F'ahrer-<br />

modell <strong>mit</strong> den Einsatzbeispielen Verkehrssimulation und Fahrsi-<br />

mu.lator. (9. *4achener Kolloquium Fahrzeug- und 1\Iotorentechnik,<br />

Bd. 2). Aachen: RLTTH *\achen, 2000, S. 1343-1360.<br />

[8] Demirkaya, M.: Mikrouerkehrsdemonstrator fiir echtzeitfähige Fah-<br />

rerrnodelle und Assistenzsystenle. TU Berlin, Dissertation: 1998.<br />

[9] de JI'aard, D.; Brookhuis, K.: The feasibility of detecting phone-use<br />

related driver distraction. Int. Journal of Veliicle Design, Bd. 26<br />

(2001), Nr. 1: S. 85-95.<br />

[I01 Baker, G.; Boardman, A.: Human factors studies of vehicle interior<br />

products - interactive driving sim,ulator applied research. S4E<br />

Paper (2001), Nr. 2001-01-03.58.<br />

[I11 Burgett, A.; Miller, R.: A nlew paradzgrn for rear-end cro,sh preven-<br />

tion driving perforrr~artce. SAE Paper. (2001), Nr. 2001-01-0163.

[12] Sayed, R.; Eskandariaii, A.: U~zobstmsior d~v~iisiness dptection bv<br />

r~e~iral networ.k. Proc. of the Iiistitiitioii of 2lecli. Eng. Part D.<br />

Bd. 215 (2001), Nr. 9: C. 969-973.<br />

[13] Baumann, G.: Höt,zer. D.: Eine Mensch-Maschine-Schl2ittstelle für<br />

Echtzeitsimulato~~en.<br />

ATZ, Bd. 99 (1997). Nr. 6: C. 606-612.<br />

[14] Hotzri-, D.: Entu)ickluny einer Schaltstrategie für einen PKW ,<strong>mit</strong><br />

uutornatisie~~tern Schaltgetriebe. Vnivrrsitat Stutt,gart , Dissertation:<br />

1999.<br />

[15] Allen. R.; Rosenthal. T.; Aponso. L.; Chrstos, 3.: Real time vehicle<br />

dyn,ornics simrilntiorr: Ennbling tool for fiiridonrrntnl liurnarr fiictnr*r<br />

r.esearch. SXE Papcr (1998), Nr. 950222.<br />

[16] MTelles. R.; Craft. F.: A low cost upproach to firlly-,n~n1ersizle<br />

engineerzng-capable, wh,eeled-vehicle driving simulation. SrlE Pa-<br />

per (2001), Nr. 2001-01-1278.<br />

[17] hlarstaller, R.: Fahrerverhaltensänderungen bei der fahrerassistierenden<br />

Kfz-Steuerung <strong>mit</strong> aktiven Bedienelementen gegenüber dem<br />

konver~tionellen Bedienkonxept. (VDI-Bericht Nr. 1613: Der Fahrer<br />

iin 21. Jahrhundert). Düsseldorf: VDI-'lerlag. 2001, S. 297-313.<br />

[18] Freitag. R.; Hartl, 11.; '\loser, AI.; Koeperiiik. J.: Anforderungen<br />

an das Sicherheitskonxept von Len,ksysternen <strong>mit</strong> Steer-by-l.l/ire.<br />

('lTDI-Bericht Nr. 1646: <strong>Elektronik</strong> im Kraftfalirzeiig) . Diisseltlorf:<br />

'l-Di-'lkrlag, 2001, S. 837-854.<br />

[19] N.N.: SimuCerte Fahrt, echter Nutzen. .iiitoiiiohil Irirlostrie (1998).<br />

Xr. 9: S. 44-45,<br />

[20] \*ainasaki, C:.: Aoki. K.: lIiyamaril, Y.; Ohni~rria. K.: Developmer~t<br />

of m,otorcycle trainirzg simulator. JS-IE Review, Bd. 19 (19981,<br />

Nr. I: S. 81-85.<br />

[21] Palmkvist, G.; Nordström, 0.: Hybrid Laboratory Test Method For<br />

Anti-Lock Spstems. (Proc. 8th INSD Syniposium). Cariibridge:<br />

Int. ,Issociation for 'lehicle Systern Dynarnics. 1984. S. 407-421.<br />

[22] Suh, 11. et nl.: Hardware-in-the-loop sirnulation for ABS based on<br />

PC. Iiit. Joiiriial of 'lTr2iicle Design, Ud. 2-1 (2000). Ni.. 2/3: C. 157-<br />

170.

1231<br />

H.; Gao, B.and Song, J.: Approach of debugglng control<br />

laws of ABS combined with hardware-in-the-loop simulation and<br />

road experi~nent. SAE Paper (2001), Kr. 2001-01-2729.<br />

[24] Olfens, C.: Er<strong>mit</strong>tlung objektiver fahrdynamischer Bewertungskri-<br />

terien durch Hardware-in-the-Loop-Simulationen an einem Achs-<br />

prüfstand. RWTH Aachen, Dissertation: 2002.<br />

[25] Sinsel, S.; Schaffnit , J .; Isermann, R. : Hardware-in-the- Loop Si-<br />

mulation von Dieselmotoren fiir die Entwicklung moderner Mo-<br />

tormanagententsysteme. (6'DI-Bericht Nr. 1315: XIechatroriik irr1<br />

Xlaschirien- lind Falirzeugbau). Düsseldorf: VDI-irerlag, 1997.<br />

S. 181- 199.<br />

[26] Liebl. J.; hlurik, F.; Schneider, J.; Kaemmer , A.: Automatzsierter,<br />

modellbasierter Test von Motormanagementsystemen. (4. St,uttgarter<br />

Symposiiim Kraftfahrm-eseii und 1-erbrennungsmotoren) . Bargende,<br />

M.; JT7iedrmann, J. (Hrsg.) . Renningen: expert-Verlag,<br />

2001, S. 746-758.<br />

[27] Deiss, H.; Kriminel, H .: Hardware-in-the-Loop Simulation der Spe-<br />

xifikation. (VDI-Bericht Nr. 1315: Mechatronik im Maschinen- und<br />

Fahrzeugbau). Düsseldorf: VDI-tTerlag, 1997, S. 103-116.<br />

[28] Brendecke, T.: Virtuelle Echtzeitumgebung für Getrzebesteuer-<br />

gerate <strong>mit</strong> Hardware-in-the-Loop. TU Braunschweig, Dissertation:<br />

2001.<br />

[29] hIarco, J.; Ball, R.: Jonrs, R.: Roxburgh. A.: The design and<br />

hnrdmare-in-the-loop sinzulation test of a parallel hybrid trn~tsmis-<br />

siori corttrol systern. Int. Journal of Iehicle Design, Bd. 30 (2002),<br />

Kr. 4: S. 362-385.<br />

[30] Pfeiffer, K.: Fahrsimulation eines Kraftfahrzeuges <strong>mit</strong> einem dy-<br />

namischen Motorenprufstand. TH Da'rmstadt, Dissertation: 1996.<br />

[31] Walker, M.; Ford, R.: Hardware-in-the-10% dynamometer based<br />

driver und veh,icle simulator. SAE Paper (2000). Nr. 2000-01-0289.<br />

[32] Leimegger, C .; Schröder, D.: Hochdynamische Verbrennung.srnotor-<br />

und Rad-Stlajle-Simulation an einem modellgefiihrten Hardware-<br />

in-the-Loop P~uI-Antriebsstmngprüfstnnd. (1-DI-Bericht e<br />

Nr. 1631: I7DI Mechabronik-Tagung). Düsseldorf: 13--\erlag,<br />

2001. S. 389-409.

[33] Fleischhauer, T.; voii Klitzing, \TT.; Scliwarz. G.; Zulxr-Gcios. F.:<br />

lrer~breri~rurigsnimuletion an rlektro7notor~sch betrfebenen Getriebeprüfststnnden.<br />

(17DI-Bericht Nr. 1189: SIess- urid iersuchstechriik<br />

in1 Autoinobilbau). Düsseldorf: i7DI-\'erlag, 1995, S. 35-54.<br />

[34] Aitchisori, K.; Goody. K.: Efective bench testing of ECUs. (ISATA<br />

2000. Xutornotive Elec-troiiics) 2000, S. 1G5-170. ISXA Paper<br />

Xr. 0OA4EO0S.<br />

[35] Grohrnaiin, D.: Ein hybrides Fuhrzeugreferenzmodell für die<br />

Priifsysteme~itwicklung. TU 3lfünchen, Dissertation: 1995.<br />

[36] Jairirs. ;\.: Riidolpti. AI.: Geliriiig. J.: Pölilriiaiiii. T.: Ha?il~~lare-infl~r.-Loop<br />

bei A~~dz-,4r~tri~bsstl.ii~~g(lr). -ATZ. B(1. 101 (2002). Nr. 1:<br />

S. 340-346.<br />

[37] Sienel. W.; Ebinger. B.; Spoerl, T.: A hardware-irr-the-loop test<br />

environ.rnent for interconnected ECUs for passenger curs nnd com-<br />

mercial vehicles. FISITA Paper (2000), Nr. F2000A-1113. SXVIII<br />

FISITA4 Congress, Seoul.<br />

[38] Beineke, hl.: Acht auf einen Streich. Real Times (Kundenzeit-<br />

schrift der ETAS GmbH, Stuttgart (2002), Yr. 2: S. 6-8.<br />

[39] Laniberg, I

(451 Schnelle, K.; van Zanteri, A.; Hiller, 51.: Simulation of nonline-<br />

ur vehicle dynamics with the modular sinlulation package FASIM.<br />

(Proc. 12th IL4\TSD-Symposiuni). Lyon: Int . Association for Vehic-<br />

le System Dynarnics, 1992, S. 551-565.<br />

[46] 1 G.: Simulation von Kraftfahrzeugen. Braunschweig: Vieweg-<br />

Verlag, 1994.<br />

[47] Zamow, J.; Witte, L.: Fahrzeugsimulation unter Verwendung des<br />

Starrkoerperprograntms ADAMS. (JTDILBericht Nr. 699: Bereih-<br />

nung im Aiitomobilbaii). Düsseldorf: VDI-\erlag. 1988. S. 287-<br />

309.<br />

[48] hleinke, P.; '\lauer, L.; Rulka, \IT.: Zur rechnergestUttten Fahrdy-<br />

namik von Nut&hrzeugen <strong>mit</strong> linearen und nichtlinearer1 Pro-<br />

grammen. (YDI-Bericht Kr. 699: Berechnung im Automobilbau).<br />

Düsseldorf: 17DI-\'erlag, 1988, S. 137-156.<br />

[49] Schieschke, R.: Konzeption und Realisation komplexer fahrdynami-<br />

scher Simulationsmodelle am Beispiel eines Sattelzuges <strong>mit</strong> beweg-<br />

licher Ladung. Universität Karlsruhe, Dissertation: 1988.<br />

[50] Holdmann, P.; Holle, LI.: Possibilities to improve the ride and<br />

handling performance of delivery trucks by modern mechatronic<br />

systems. JSAE Review, Bd. 20 (1999), Nr. 4: S. 505-510.<br />

[SI] Hirschberg. F$'.; IVeinfurter, H .; Jung. C .: Er<strong>mit</strong>tlung der Poten-<br />

ziale zur Lkw-Stabilisierung durch Fahrdynarniksim,ulation. (17DI-<br />

Bericht Nr. 1559: Berechnung und Simulation in1 Fahrzeugbau).<br />

Düsseldorf: lTDI-l'erlag, 2000. S. 167-188.<br />

[52] Hecker, F.; Schramm, H. et al.: Fahrdynamikregelung für Sat-<br />

telzüge. (VDI-Bericht Kr. 1350: Reifen, Fahrwerk, Fahrbahn).<br />

Düsseldorf: VDI-Jerlag, 1997, S. 63-77.<br />

[53] Faber. A.: Untersuchungen zu simulationsgeeigneten Normen für<br />

das Fahrverhalten schwerer Nutzfahrzeuge. Lniversität Hannover,<br />

Dissertation: 2001.<br />

[54] Dragon, L.: FADYS handling simulatior~s used in a real-time<br />

hardu~are-in-the-loop application with the ESP-controller. (M'EC<br />

96 - International Symposium on Advanced ~'ehicle Control. 10-<br />

lurrie 1) 1998, S. 559-672.

[35] van Zaiiteii, A.; Erhardt, R.; Bartels, H.; Hesselbartli. J.: Simulution<br />

bei der Entwicklung der Bach-Fah~dynarr~ikrcyelung. (17DIL<br />

Bericht Nr. 1374: S\.-sternengineeri~ig in der Kfz-Eritn-ickliiiig) .<br />

Diisseldorf: 17DI-Ierlag, 1998, S. 89-114.<br />

[Xi] Torre-Flores, P.: Zur analytischen Modellbildung urid schiitzerbu-<br />

sierten Koppelkraftregelung plort Sattelziiger~. Crii\-ersität-GH Duis-<br />

burg, Dissertat,ion: 2000.<br />

[57] Kopischke, S.: En,twicklung einer Notbremsfunktion <strong>mit</strong> Rapid Pro-<br />

totyping Methoden,. TU Braunschweig, Dissertation: 2000.<br />

[38] I

I661 Rükgauer, A.: Modulare Simulation rnechatronischer Systeme <strong>mit</strong><br />

Anwendung in der Fahrzeugdyr~amib. Universität Stuttgart, Dis-<br />

sertation: 1997.<br />

[67] Petrone, F.; Fichera, G.; Lacagnina, LI.: A numerical model to<br />

analyze the dynamic response of a vehicle to vibrations on torque<br />

trans<strong>mit</strong>ted by the drive-line. SAE Paper (2001), Nr. 2001-01-3334.<br />

[68] Sayers, M.: Vehicle models for RTS application. iehicle System<br />

Dynamics, Bd. 32 (1999); Nr. 4-5: S. 421-438.<br />

[69] N.N.: Drei Adern ersetzen Kabelbaum. Elektronisches Leitungssys-<br />

tem. Auto Tecli. U. lkrkchr (1979), Nr. 6: S. 46-48.<br />

[70] ISO 9141: Road Vehicles-Diagnostic Systems- Requiremerlts for<br />

Interchange of Digital Information. 1st Edition, 1989.<br />

(711 I\'ense, H.: Introduction to Local Interconnect Network. S.4E Paper<br />

(2000), Nr. 2000-01-0153.<br />

[72] Etschberger, K.: Controller Area Network. Grundlagen - Pro-<br />

tokolle - Bausteine. Dritte Auflage. München: Hanser-Verlag,<br />

2001.<br />

[73] ISO 11591-2: Road Vehicles - Low speed serial communication<br />

- Part 2: Vehicle Area Network (VAN), 1992.<br />

[74] Martin, P.; Bichet, C.: Multiplexing in the vehicle of 21st century.<br />

(6th European EAEC Congress, Cernobbio) 1997, S. 201-208.<br />

['Ei] N.N.: Class 2: Introduct%on to medium-speed multip1en:ing. Auto-<br />

niotive Engineering, Bd. 100 (1992), Nr. 9: S. 37-30.<br />

[76] Tindell, K.; Burns, A.: Guaranteeing Message Latencies on CAN.<br />

(Ist International CAN Conference, lllainz). Erlangen: CAN in<br />

Automation GmbH, 1991. S. 201-208.<br />

[77] Ringler, T.: Entwicklung und Analyse zeitgesteuerter Systeme. C~ii-<br />

versität Stuttgart Dissertation: 1989.<br />

[78] Kopetz, H.; Grünsteidl, G.: TTP - A Protocol for Fault- Tolerant<br />

Real-Time Systems. IEEE Computer (1994): Nr. 1: S. 14-23.<br />

1791 Belschner. R. et al.: Trockenes Brabe-by- Wire <strong>mit</strong> fehlertoleran,tem<br />

TTP/C-Kommunikationssystem. 1 Bericht Kr. 687: Elektro-<br />

nik im Kraftfalirzeiig). Düsseldorf: \TDI-\erlag. 1998, S. 325-314.

[SO] Iloser, R.; IT~iedenlanri, J.; Zahir. ;\.: Derelopmer~t support for tinie<br />

triggered applicatioris in rond vehicles. (ISATA 2000. ;\utoiiiotivp<br />

Electronics). Epsorii, UI

[91] SAE Standard 5-2411: Single IVire CAN Networlc for Vehzcle Ap-<br />

plications, 2000.<br />

[92] DIN 44300: Realzeitverarbeitung, 1985.<br />

1931 Göhner, P.: Prozessautomatisierung I. Cniversität Stutt,gart , Insti-<br />

tut für Automatisierungs- und Softwaretechnik (IAS), 2001. Um-<br />

druck zur Vorlesung.<br />

[Si] Heimann, B.; Gertli, W.; Popp, K.: Mechatronik - Komponenten,<br />

Methoden, Beispiele. München: Hanser-Verlag, 1998.<br />

[95] Zeitz, hl.: Simulationstechr~ik. Universität Stiittgart, Institut fiir<br />

Systeindyriariiik und Regelungstechnik (ISR) . 1993. Umdruck zur<br />

lTorlesung.<br />

[96] Preuß, W.: JVenisch, G.: Lehr- und Übungsbuch Numerische hla-<br />

thematik. Leipzig: Fachbuchverlag Leipzig, 2001.<br />

1971 Huckle, T.: Klein,e BUGS, groj'e GA Us - Sofiwarefehler und ihre<br />

Folgen. TU München, Institut für Informatik, 1999. Vortrag.<br />

[98] Kernighan, B.; Ritchie, D.: Programmieren in C. Zweite Auflage.<br />

bfünchen: Hanser-'lrerlag, 1990.<br />

[99] N.N.: ASCET SD Benutxerhandbuch (Version 4.0). ETAS GmbH,<br />

Stuttgart, 2000.<br />

[I001 N.N.: Using MATLAB (Version 6). The LfathWorks Iric., Natick,<br />

MA, 2001.<br />

[I011 N.K.: Using SIMULINK (Version 4). Tlie hlathbVorks Iiic., Natick.<br />

M,4. 2001.<br />

[I021 N.N.: SIMULINK. Writing S-Functions (Version 4). The Math-<br />

Works Inc., Natick, MA, 2001.<br />

[I031 N.N.: Real Time Workshop User's Guide. (Version 4). The hlath-<br />

Works Inc., Natick, MA, 2001.<br />

[I011 Harel, D.: Statecharts: A Visual Forrnalism for Complex Systems.<br />

Science of Coriiputer Prog., Bd. 8 (1987), Nr. 3: S. 231-247.<br />

[I051 Fuchs. M.; Eckrich. M.; hfüller. 0.: Phillips. J.: Advanced design<br />

und validation techniques for electronic control u~azts. SA4E Paper<br />

(1998): Nr. 981099.

[I061 'T.N.: STATEFLOW User's Guide (Version 4). The \IatlllVorks,<br />

Iiic., Natick. IIA, 2001.<br />

[I071 Hötzer. D.; Essers, C.: Modellunterstützter Entwurf von Steuerungssystemen<br />

fiir die Automatisierung von S~h~altgetrieberr. (SJ-rnposiuni:<br />

Steuerungss>-sterne im .intriebistrang). Appel, H. (Hrsg.) .<br />

Bcrlin 1998.<br />

[I081 Schielilen, W. (Hrsg.): Multibody Systenzs Hundbook. Berlin:<br />

Springer-lerlag, 1990.<br />

(1091 \T7allrapp, 0.: Entwickl~~n,g rechnergestützter APethoden der<br />

iZfehrkörgerdgnumiX: in der Fnhrxeugttjch~~ik. TV Berliri. Disse1.tatioli:<br />

1989.<br />

[I101 Schrnidt, A.: Entwicklung und Anwendung von Simulationsrnodel-<br />

Zen zur Untersuchung der Lenkungsunruhe von Pkw. Unil-ersität<br />

Karlsruhe, Dissertation: 1984.<br />

[I111 Schiehlen, \IT.; Kreutzer, E.: Rechnergestütztes Aufstellen der Bewegungsgleichungen<br />

ge~öh~nlicher Mehrkörpersysteme. Ingeriieur-<br />

Archiv, Bd. 46 (1977).<br />

[I121 DIN EN 21 5.39: Informationsteclin,~ Progmmmier~~pmchen:<br />

FORTRAN. 1993.<br />

[I 131 Schielilen, M:.: Programmsystem NE MTE UL (Version 96.6). Cni-<br />

vcrsitiit Stuttgart. Institiit B für Mechanik, 1996.<br />

[I141 Bronsteiri, 1.: Sernelldjajew, K. et al.: Taschenb7~rh der Aiutl~e~i)(~-<br />

tik. Fiinfte auflag^. Tllun, Frarikfurt: \'erlag Harri Deutscli. 2000.<br />

[I 151 Neubeck, J .: \1701inhaas, .A.: Werkzeugunterstützte Erstellung Kfz-<br />

technischer Mehrkörperdynamikmodelle für SIMULINK. (ASIII<br />

12. Symposium Simulationstechriik, Zürich). Erigeli, \I. ; Hrdliczka.<br />

V. (Hrsg.), Zürich: vdf Hochschiilverlag AG: 1998, C . 57-65.<br />

[I161 N.N.: FUND 7.1 0: Symbolic Code. intec GmbH, ;2lünchen. 1999.<br />

SIhIP,iCK Jersion 8.0; O~iline-Hilfedatei.<br />

[I171 Zerfowslti, D.: ASCET-SD irn Praxis-Ebnsntr bei Knol-r-Bremse.<br />

Xiitonioti~-e Electronics (2001), Nr. 4: S. 10-14.

181 Baumann, G.; Wiedemann, J.: Werkzeuggestutzte hlodellbildung<br />

für Nutzfahrzeuge und Anwendur~geti in der Echtzeitsirnulation. (3.<br />

Tagung hlecliatronik ini Automobil, hlüncheri). Essen: Haus der<br />

Technik, 2001.<br />

[I191 Baumann, G.: Entwicklung eines Echtzeit-Nutzfahrzeugsimzllators<br />

als Prüfeinrichtung für p~teumatische ABS-Bremsanlagen. For-<br />

schungsinstitut für Kraftfahrwesen und Fahrzeugmot,oren Stutt-<br />

gart (<strong>FKFS</strong>), 1998. Abschlussbericht .<br />

[120] Gutniayer. H.-J .: Konzeption und Programtnierung einer<br />

Fahrzyklen-Steuerung für einen Nwtxfahrzeug-E~htzeit~simulator<br />

Institut für Verbrerinungsmotoren und Kraftfahru-esen, Univer-<br />

sität Stuttgart: Studietiarbeit, 1998.<br />

[I211 Goppelt, G.: Der Smart. Entwicklung und Technik. ATZ: Bd. 101<br />

(1999), Nr. 6: S. 415-442.<br />

[122] Tindell, K.: Fzxed Priority Scheduling for Hard Real- Time Systems.<br />

University of York, Dissertation: 1993.<br />

[I231 Stümpfle, hl.: Planung und Optimierung von prioritätsbasierten<br />

Steuergerätenetzwerken für Fahrzeuge. Universität Stuttgart, Dis-<br />

sertation: 1999.<br />

[I241 Stephan, V.; Fritz, M.; Appel, Y.: <strong>Elektronik</strong> im Actros von<br />

Mercedes-Benz. ATZ, Bd. 99 (1997). Xr. 2: S. 64-72.<br />

112.51 Baurilanri. G .: Hardware-in-the-Loop Sirnulatzon Methods in a<br />

CAN bus Environnient. (Internatiotial Aiitomotire Cotifcr~nce).<br />

Mürichen: Scientific Computers GmbH, 1998. Vortragsumdruck.<br />

[I261 Paulsen, L.: Das Antriebsmanngement schwerer Nutzfahrzeuge -<br />

ein Beitrag zur Erhöhung der aktiven Sicherheit. Verkehrsunfall<br />

und Fahrzeugteclinik, Bd. 30 (1992). Nr. 7/8: S. 195-199.<br />

[I271 Baumann, G.; Wiedemann, J.: Ein Fahrsimulator für elektr~n~isch<br />

gesteuerte Nutzfahrzeuggetriebe. (3. Stuttgarter Symposium Kraft-<br />

fahrwesen und Verbrennungsmotoren). Bargende, hl. ; Jyiedemann,<br />

J. (Hrsg.) , Rennirigen: expert,-Verlag. 1999, S. 659-671.<br />

[128] Paulseii, L.: Die neue Telligent-Schaltung von Daimler-Benz. Teil<br />

112. &4TZ, Bd. 100 (1998), Nr. 9/10: S. 596-602 und 752-760.

[I291 Paiilseii, L.: Die neue Tell~gen~t-Schult7ing L ~ ~ IAfercedrs-Bens. L<br />

(I'DI-Reiiclit Yr. 1311: Nutzfalirz~uge). Düsscldorf: \TDI-I>rlag.<br />

1997.<br />

[I301 Schaller, K.: Automatisiertes Getriebeschaltsystem SAMT B.<br />

(VDI-Bericht Yr. 1341: Nutzfalirzeiigc.). Diisseldorf: VDI---\Prlag.<br />

1997.<br />

[I311 Ett,weiri, B.: Auton~utic transmission in the MAN TG-..I. Auto<br />

Teclinology, Bd. 1 (2001).<br />

[I321 Hofmann, R.: Bauiiigart~ier, F.: Paiilsen. L.: Raiser. H.: Die<br />

Telli,yent-Schaltn~stomutik des Actros von A4e1.red~s-Ben~. (ITDI-<br />

Bericht Yr. 1418: Iriiiouati~c~ F;ihr~eugaiit rihe). Diisc;cldorf: \-DIP<br />

Ierlag. 1998, S. 499-516.<br />

[I331 N.N.: Technisclle Information Nutzfahrzeuge: Actros. Dairnlrr-<br />

Chrysler AG, TVört h, 2000. Broschüre.<br />

[I341 Bargende, AI.; Greiner, R.: Verbrennungsmotoren I. Universität<br />

Stxttgart, Institut für \'erbrennungsmotoren und Kraftfahrn-esen<br />

(IVK) , 2001. Umdruck zur Irorlesuiig.<br />

[I351 N.N.: Kraftfnhrtechnisch~es Taschenbuch. 22. Auflage. Berlin:<br />

Springer-Ikrlag, 1998.<br />

C1361 Boehringer, -4.: Einführung in die Energietechn,ik I. Uriiversit3t<br />

Stuttgart , Institut für Leistungsclektronik 1111d Regeliingst ecliriik<br />

(ILR) . 1990. Uindruck zils Ioslesiii~g.<br />

[I371 Steinel, K.: Schwi~lgungen frn PK \V- Antriebsstrung beun Leer Iaaf-<br />

Einkuppelvorgang Analyse und Optirnfer~~ng durt.1~ Versuch und<br />

rech,ne~-isc:he Si~n,ulation. (VDI-Bericht Yr. 1220: Kupplilrigeri in<br />

Llntriehssysternen). Düsseldorf: ITDI-Ii.rlag. 1995.<br />

[I381 Lechner, G .: Fahrteuggetriebe. Grundlagen. iluswahl, Alrslegung<br />

und Kon,struktion. Berliri: Springer-]'erlag, 1994.<br />

[I391 Decker; H.; Wede, J. : Elektronisch geregelte 1Y~stzfahrzeu,qb7-rmse.<br />

-ATZ, Bd. 96 (1994). Nr. 9: S. 506-510.<br />

[I401 \lTitte. X. : Elektron,isches B7rmssy.s tem im Anhiingef(r1tlseug. (Ta-<br />

gung: BrernsTech 2000). \Iüriclieii: TUT- Süd. 2000.

[I411 Decker, H.; T\Tede, J.: Brake-by- Wire, Solutions, Advantages und<br />

the Need for Standardisation. (Int. Congress on Transportation<br />

Elektronics). Dearborn, hlI 1994. Vortrag.<br />

[I421 Pressel, J.; Reiner, M.: Die Basisregelitrategie der elektropneu-<br />

matischen Bremsanlage von Mercedes-Benz. (VDI-Bericht Kr.<br />

1224: Reifen, Fahrwerk, Fahrbahn). Düsseldorf: VDI-Verlag, 1995,<br />

S. 221-236.<br />

[143] hlarwitz, H.; Junghans, H.; Fischer, J.: Current Positions und De-<br />

tielopment Trends in Air Brake Systems for Mercedes-Benz Com-<br />

mercial Vehicles. SXE Paper (1995), Sr. 952303.<br />

[144] Klug, H.: Nutzfahrzeug-Bremsanlagen. lvürzburg: I'ogel-Verlag,<br />

1986.<br />

[145] IViehen, C.; Neuhaus, D.: Potential elektronisch geregelter Brems-<br />

systeme. (VDI-Bericht Nr. 1188: Das sichere Yutzfahrzeug).<br />

Düsseldorf: \TDI-lTerlag, 1995, S. 119-139.<br />

[146] V. Glasner, E.: Beitrag zur Auslegung von Kraftfahzeugbremsanla-<br />

gen. Universität Stuttgart, Dissertation: 1973.<br />

[I471 Hoepke, E.; Brähler, H. et al.: Nutzfahrteugtechliik. Grundlagen,<br />

Systeme, Komponenten. Braunschweig: Vieweg-Verlag, 2000.<br />

[I481 Wiedemann, J .: Kraftfahrzeuge I. Universität Stuttgart , Institut<br />

für lTerbrennungsmotoren und Kraftfahrwesen (IITK) , 2001. Umdruck<br />

zur Vorlesung.<br />

[I491 Alitschke, 11.: Dynarnik der Kraftfahrzeuge. Band A: Antrzeb und<br />

Bremsung. Zweite Auflage. Berlin: Springer-\'erlag, 1982.<br />

[I501 N.N.: ACTROS BerEienungsanZeitung. Daimler-Chrj-sler AG.<br />

Stuttgart, 1999.<br />

[I511 N.N.: CAN AC2 PCI User Manual. Version 4.03. Softing GmbH,<br />

München, 1998.<br />

[I521 DIN 70000: Straßenfahrzeuge; Fahrzeugdynamik und Fahrverhal-<br />

ten; Begrzfle, 1994.<br />

[I531 Wiedemann. J .: Kraftfahrzeuge II. Universität Stuttgart . Institut<br />

fiir \~rbrrnriririgsmotorrn und Kraftfahrwesen (IITK), 2001. Lni-<br />

druck zur Tbrlesung.

[lS] Reinipell. J .: Sponagel. P.: Falir~i:erktechnik: Rfjifrn nrid R iider.<br />

ITÜrzburg: lbgel\'crlag, 1986.<br />

[I551 Scbieschke, R.: RALPHS - ein efizientes Rechenmodell zur Er-<br />

<strong>mit</strong>tlung von Reifenkräften auf physikalischer Basis. .~iitoniohil-<br />

Industrie, Bd. 31 (1986), Nr. 4: S. 459-462.<br />

[I561 Scliieschke, R.; Gnadler, R.: Alodellbildl~ng und Simulation von<br />

Rezfeneigen,schaj?er~. (VDI-Bericht Xr. 650: Reifen. Fahrwerk.<br />

Fahrbahn). Düsseldorf: VDI-Verlag, 1987, S. 95 -1 14.<br />

[I571 a l j 4. Guentlier, D.: Ellis, J.: Experimental Deaelopnlent of<br />

Tyre Force arid illornent Afodels. Iiit. Jouriial of \tliirle Design.<br />

Bd. 10 (1989). Yr. 1: S. 34-51.<br />

[I581 nTeber. R.: Schlupflntifte und Fiihr~ungskräfte arn Relferi. (17DI-<br />

Bericht Kr. 5-26: Falirdynariiik urid F'ed~rungskomfort) . Diisseldorf:<br />

VDI-\erlag. 1984, S. 189-201.<br />

[I591 Braess, H.; Seiffert , G. (Hrsg.): Vzeweg Handbuch KraJlfahrzeug-<br />

techn,iki. Braunsch~veig: Vieweg-Ierlag, 2000.<br />

[160] V. Glasner? E.: Fahr- und Bremsverhalten von Nutzfahrzeugen. Cni-<br />

r-ersitzt Stuttgart, 2000. Gmdruck zur lrorlesung.<br />

[161] Haken. K.: Konzeption und Anwendur~g eines Mc$fahrzeugs zur<br />

Er<strong>mit</strong>tlung zion Reifenkennfeldern aui G#entlichen StraPen. Cni-<br />

1-ersität Stuttgart, Dissertation: 1993.<br />

11621 IfTeber, R.; Münster. h1.: Zum Verhalten von Nutzfahrzeugreifen<br />

bei instationiirern Schrägl~~f auf echten Fahrbahr~en. Aiito~nol~il-<br />

Indi~strie, Bd. G (1989); S. 735739.<br />

[I631 Siissle. AI.: Gnatller, R.: Alesseinrzrht?~ng zur B t n n g zlon<br />

Reifenkennlilt2en im Fahrbetrieb. ATZ. Bd. 103 (2001). Sr. 7'18:<br />

S. 628-634.<br />

[l64] AIaulick, T.: Ein neues Verfah.ren zur Berechnung von Reifenkienn-<br />

feldern. Universität Stuttgart, Dissertation: 2000.<br />

[I651 Gipser, M.: FTire, a New Fast Sire Alodel for Ride Comfort Si-<br />

mulations. FH Esslingen, Fachbereicli Fahrzeugtecl-inik, 2000.<br />

[I661 Schiesclike, R.; Hiernenz, R.: The Relevante of Tiw Dynnniici in<br />

Vehicle Simulatiorzs. FISITA Paper (1990). Xr. 905221.

11671 Bakker, E.; Pacejka, H.; Lidner, L.: A New Tire Model with an<br />

Application in Vehicle Dynamics Studzes. SAE Paper (1989),<br />

Nr. 890087.<br />

[I681 Rill, G .: Fahrzeugdynarnik. Fachhochschule Regensburg, 2001. Cm-<br />

druck zur lrorlesung.<br />

[169] Mitschke, M.: Dynamik der Kraftfahrzeuge. Band C: Fahruerhal-<br />

ten. Zweite Auflage. Berlin: Springer-Verlag, 1990.<br />

[170] Krantz, W.: Erstellung eines Lenku~igsrnodells und Implernentierung<br />

auf einem Echtzeit-Sim~~latzonsprüfstand. Institut für Ierbrennungsmotoren<br />

11nd Kraftfahrweseri, Universität Stut tgart : Diplomarbeit<br />

, 1998.<br />

[I711 Wohnhaas, A.: Simulation von Kfz-Lenkungen unter besonderer<br />

Berü.ck:sichtigung von Reibung und Spiel. Universität Stuttgart,<br />

Dissertation: 1994.<br />

[172] Reimpell, J.: Fahrwerlctechnzk: Lenkung. IVurzburg: Vogel-Verlag,<br />

1984.<br />

[l73] Stoll, H.: Fahrwerktechnik: Lenkanlagen und Hilfskra~lenkanlagen.<br />

Würzburg : lTogel-Verlag , 1992.<br />

[I741 Stoll, H.: Fahrwerktechnik: Grundlagen. Dritte Auflage. Würz-<br />

burg: Vogel-Verlag, 1995.<br />

I1751 AIeitinger, T.: Breitfeld. C.: Simulation des dynamischen Verhal-<br />

tens von Zahnstangen-Hydrolenkungen. (7. Aachenclr Kolloquiurri<br />

Fahrzeug- und hfotorentechnik. Bd. 2). Aacheri: RWTH Aacheri,<br />

1998, S. 1105-1124.<br />

[176] Grimm, M.: Aufbau eines Lenkrads <strong>mit</strong> Momentenrückwirkung<br />

zum Einsatz in der Fahrsimulation. Inst. für irerbrennungsmotoren<br />

und Kraftfahrwesen, Universität Stuttgart: Studienarbeit, 1997.<br />

[I771 N.N.: UNIDRIVE Betriebsanleitung. Ausgabe 1.00. Control Techniques<br />

GmbH, Hennef, 1996.<br />

[I781 Guo. Y.: Erstellung ein,er Echtzezt-Animation für den Ein,satz in<br />

Fahrsirnulatoren. Institut für \'erbrennungsmotoren und Kraft-<br />

falirwesen, Ciiiversität Stuttgart : Studienarbeit , 1998.

[li9] Eiriiert . H.; Hoinpert , H.: Das Lexikon dcr elcktlnnischen Alu,sib.<br />

Regensbiirg: Bosse. 1973.<br />

[I801 Hofrnaiiri, R.: Klänge aus der Retorte. Elektronische AhLsikir~stli~-<br />

m,ente und Eflektgeriite. Süddeutsclier Rundfiink, Stutt gart. 1993.<br />

Seminariinidrilck.<br />

[I811 Fazio, L. et al.: Verfahren zur elektro~izschen Simulation, von periodisch,en<br />

Tönen oder Geräuschen rnit Hilfe elektronischer digitaler<br />

Speicherlemente und einen elektronsichen Simulator dafür. DE-<br />

Patent (1976): 26 08 347.<br />

[I821 XIert, AI.; Hahii, C.: Kädiiig, W.: Das digitale Geriiasthsystem drs<br />

Dui~nl~r- Benx 8"nhr.sinsulatol-s. (lTDI-Bericlit Nr. 791: Aless- iiricl<br />

l*ersucl~stctcli~iilc ii~i _\iitoiiiol~ilbau). Diisscldorf: l'DIGlCrlag. 1990.<br />

S. 109--119.<br />

11831 Baurnann, G.; Hötzer: D.: Verfall ren urad Vorrichtu~ag zur Nuchbildun9<br />

von Maschinengeräuschen. DE-Patent (2001), 197 26 271.<br />

[I841 Schwarze, D.: Elektroakustik. Universität Stuttgart, 1993. Um-<br />

druck zur Vorlesung.<br />

[I851 Haselberger: F.: Konzeption und Realzsierung eines Verfahrens zur<br />

realitätsnahen Erzeugung von Fuhr-zeuggerüuschen für Fahrsimu,la-<br />

toren. Iiistitiit für Ierbreririiings~llotorell uild 1iraftf:illru-eseri. Urii-<br />

vtrsität Stut tgart : Studienarbeit , 1997.<br />

[I861 Y.N.:<br />

Servogetriebemotom. SEIT' Eiirodri~e GiiibH, Briirlisril.<br />

1999. Prodilktkat~ilog.

Anhang<br />

Al: Auslegungsrechnung zu Abschnitt 4.3.2<br />

OJEI<br />

M1<br />

WM<br />

Split- Haupt- Range-<br />

- Gruppe gruppe Gruppe<br />

Jm<br />

e 11 9 JGE 1 1, I ,Jw<br />

WG<br />

J E 2 ~<br />

A M2<br />

J,<br />

Servo- ' JVG -IN Servo-<br />

antrieb Kupplung Getriebe antrieb<br />

Bild 6.1: Zur Auslegung der elektrischen Servoantriebe<br />

Zur Beurteilung von Realisierbarkeit und Aufwand der in Abschnitt 4.3.2<br />

beschriebenen Aufbauvariante „Reales Getriebe <strong>mit</strong> zwei Elektroantrie-<br />

beri'. wird im Folgenden eine Auslegungsrechnung für die beiden Elektro-<br />

antriebe vorgenomriien. Die verwendeten Bezeicliriungeri sind in Bild 6.1<br />

eingetragen.<br />

Für den Antrieb am Getriebeeingang (MI) ergibt sich die höchste dynamische<br />

Momentenanforderung beim Starten oder Hochdrehen des hlotors<br />

ohne Last (Kupplung geschlossen, Getriebe in Neutralstellung). Gefordert<br />

wird eine Beschleunigung des Getriebeeingarigs vom Stillstand<br />

auf 2000Jmin binnen 2 s. Die maximale Drehzahl beträgt 2500/min. Sie<br />

wird z.B. bei Rückschaltungen im Schubbetrieb erreicht. Die hohen Anforderungen<br />

an Regelgüte urid Dynamik werden durch einen Servoantrieb<br />

erfüllt. welcher aus einem Frequenzumrichter und einer permanenterrcgten<br />

Synchronrnaschi~ie besteht. Für handelsübliche Servoantriebe<br />

rnit einem Drehzahlbereich von Null bis 3000/miri ergibt sich folgende<br />

Auslegli~ig :

Bild<br />

Das Trägheitsmoment der elektrischen 1 faschine JEl hängt von der Bau-<br />

größe und der Bauform ab. In Bild 6.2 sind die Trägheitsmomente zwei-<br />

er Bauforrrien über dern Yennmornent eingetragen [186]. Zur Auslegung<br />

wird dieser Zusamrneriharlg durch Geraden angenä2iert,<br />

Das Nennnloment ist so zu wählen, dass der hlotor das Reihrnoinerit<br />

-IfC:E. r. arn Gd rieheeirigang dauerhaft iilxrn-indcii kann.<br />

Das kurzzeitige hfaximalrnomerit AfEi>„„ ist um der1 C-berlast-faktor<br />

kE,rn höher als das Neririmoment AfE1,,. Der Antrieb wird so ausge-<br />

legt, dass das nlaximalmoment die geforderte ~lasirnalbeschleuriigung<br />

¿I'C:E.m„ des Getriebeeingarigs gewährleistet.<br />

Das xirksanie Träglieitsniomei~t Jl,„, setzt sich aus tler Trägheit des<br />

Elcktrornotors JEl, der I

*JcE und der \orgelegemelle ?JiG zusammen und ergibt sich <strong>mit</strong> der<br />

Übersetzung ii; der Split-Gruppe zu<br />

-<br />

.TGE ist das gesamte an der Kiipplung wirksame Trägheitsmoment.<br />

Durch Einsetzen von G1. 6.4 und G1. 6.1 in G1. 6.3 erhält man das für<br />

erforderliche Neiiiimornent<br />

Eine Abschätzung für das betrachetete Getriebe ergibt jcE x 0,15 kgm2<br />

und AfGE,r. N 1 Xm. Die Koiistanten für Servoantriebe der Bauform A<br />

4 betragen kE,b = 1.45 . 10- s- ', und kE,„, = 2,s. Das erforderliche Nennnioment<br />

beträgt lllEl,n = 6,7 Nm. Ausgewählt wird ein Servomotor <strong>mit</strong><br />

MEl,n = 7,s Nm sowie ein geeigneter F'requenzumrichter.<br />

Für den Antrieb am Getriebeausgang (M2) ergibt sich die höchste Be-<br />

anspruchung beim Abbremsen des Fahrzeugs im kleinsten Gang <strong>mit</strong> ge-<br />

schlossener Kupplung. Die Auslegung erfolgt in Analogie zu den obigen<br />

Ausführungen. Für eine maximale Fahrgeschwindiggkeit von 110 km/h<br />

und eine maximale Verzögerung von 4 m/s2 wird ein Antrieb der Bau-<br />

form B <strong>mit</strong> dem Drehzahlbereich Null bis 3000/min bei einem Nenn~no-<br />

ment von ca. 35 Nm benötigt.<br />

Servoaritriebe, die den er<strong>mit</strong>telten Auslegungsdaten entsprechen. sind als<br />

Standard-Produkte rnit vertretbarer1 Kosten verfiigbar.

logo

Produkte

Ressourcen

Unternehmen

AGB
Datenschutzerklärung
Cookie-Richtlinien
Cookie-Einstellungen
Impressum
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!