Closed Loop Entwicklungsplattform

Universitt Karlsruhe (TH)Schriftenreihe des Instituts fr Technische Mechanik

Bd. 2

Dipl.-Ing. Clemens Reitze

Closed Loop Entwicklungsplattform fr mechatronische Fahrdynamikregelsysteme

universittsverlag karlsruhe

Dissertation, Universitt Karlsruhe (TH), Fakultt fr Maschinenbau, 2004

Universittsverlag Karlsruhe c/o Universittsbibliothek Strae am Forum 2 D-76131 Karlsruhe

www.uvka.de

Universittsverlag Karlsruhe 2004 Print on Demand

ISSN 1614-3914 ISBN 3-937300-19-8

Closed Loop Entwicklungsplattform frmechatronische Fahrdynamikregelsysteme

Zur Erlangung des akademischen Grades eines

Doktors der Ingenieurwissenschaften

von der Fakultt fr Maschinenbauder Universitt Karlsruhe (TH)

genehmigteDissertation

von

DIPL.-ING. CLEMENS REITZEaus Heidenheim

Hauptreferent: Prof. Dr.-Ing. Walter WedigKorreferent: Priv. Doz. Dr.-Ing. Dieter AmmonTag der mndlichen Prfung: 14. Juli 2004

IZusammenfassungReitze, ClemensClosed Loop Entwicklungsplattform fr mechatronischeFahrdynamikregelsystemeFr die Dokumentation: Hardware-in-the-Loop Echtzeit Closed Loop Simu-lationsumgebung Steuergerte Test Fahrdynamik Pkw, Motorrad, Anhnger Modellbildung rumliche Reifenkinematik Schlupf-Definition

Schwerpunkt der vorliegenden Arbeit ist, durch ein aufgabenorientiertes Entwicklungs-werkzeug und entsprechende Technologien dazu beizutragen, die Komplexitt der Ent-wicklungsaufgaben besser zu beherrschen. Die vorliegende Arbeit behandelt die Kon-zeption und Realisierung einer solchen Entwicklungsumgebung. Speziell fr den Ent-wicklungsschwerpunkt Fahrdynamikregelsysteme werden hierbei folgende Anforderun-gen bercksichtigt: Bedienbarkeit, Durchgngigkeit, Modell- und Datenmanagement,Modularitt, Skalierbarkeit, Echtzeitfhigkeit und Automatisierbarkeit. Es wurden leis-tungsfhige, objektorientierte Modellbibliotheken fr die Fahrzeuge Pkw, Motorrad undPkw-Anhnger und deren verschiedene Baugruppen entwickelt. Die Modelle sind Her-stellerbergreifend einsetzbar und gengen den aktuellen Erfordernissen der Fahrdy-namik-Reglerentwicklung. Der Reifen-Fahrbahn-Kontakt hat mageblichen Einfluss aufdas Fahrverhalten und die Fahrsicherheit von Fahrzeugen und stellt fr die meistenFahrdynamik-Regler die wesentliche Eingriffsmglichkeit auf die Fahrdynamik dar. DieKinematik des Reifen-Fahrbahn-Kontakts auf gewlbten Fahrbahnen wird als ein Problemder rumlichen Kinematik verstanden und durchgearbeitet. Die Gren Schlupf undSchrglauf werden zum ersten Mal auch fr rumliche Fahrbahnen prziese definiert.

Alle verwendeten Produktnamen sind Warenzeichen der betreffenden Firmen.

II

VorwortDiese Dissertation entstand whrend meiner Berufsttigkeit als Diplomingenieur imBereich Applikation und Entwicklung bei IPG Automotive GmbH Karlsruhe vorwiegendausserhalb der regulren Arbeitszeit.

Herrn Professor Dr.-Ing. Walter Wedig danke ich sehr fr die Betreuung dieser Arbeit,seine wohlwollende Untersttzung, fr den Freiraum, den er mir bei der Bearbeitung derAufgabe lie und fr die bernahme des Erstgutachtens.Herrn Privatdozent Dr.-Ing. Dieter Ammon danke ich fr das der Arbeit entgegengebrachteInteresse und die bernahme des Korreferats. Er gab mir manchen hilfreichen fachlichenRat.Dem Vorsitzenden des Prfungsausschusses, Herrn Professor Dr.-Ing. Christoph Stiller,gilt ebenfalls mein Dank.

Mein Dank gilt ebenso den beiden Geschftsfhrern der IPG Automotive GmbH Dr.-Ing. Andreas Riedel und Dr.-Ing. Alexander Schmidt. An dieser Stelle will ich es nichtverumen, allen Kolleginnen und Kollegen fr ihre Hilfsbereitschaft und freundliche Zu-sammenarbeit zu danken. Im Speziellen erwhnt seien hier Dr. Felix Pfister fr seine vielenwertvollen Anregungen zu dieser Arbeit und die zahlreichen fruchtbaren Diskussionenund Ratschlge sowie Dipl.-Ing. Eberhard Schmidt fr die Bereitstellung der bentigtenFahrwerk-Simulationsprogramme zur Parametrierung meiner Fahrzeugmodelle.

Meinem Bruder Felix bin ich besonders fr seine Untersttzung bei der Literaturbeschaf-fung zu Dank verpflichtet. Ohne seine kompetente und zuverlssige Hilfe wre mancheLiteraturstelle unerwhnt geblieben. Fr das kritische Korrekturlesen des Manuskriptsdanke ich meinen lieben Eltern. Auch danke ich ihnen fr die vielfltige Untersttzung undden persnlichen Rckhalt, ohne den mein Ausbildungsweg und diese Arbeit sicherlichnicht mglich gewesen wren.

Karlsruhe, im August 2004 Clemens Reitze

INHALTSVERZEICHNIS III

Inhaltsverzeichnis

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IVorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IIInhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

1 Nomenklatur 1

2 Einleitung 9

3 Simulationsumgebung und Softwarearchitektur 133.1 Mechatronische Systeme im Fahrzeug . . . . . . . . . . . . . . . . . . . 133.2 Architektur der Simulations- und Prfstandsumgebung . . . . . . . . . . 15

3.2.1 Bedienkonzept, Struktur und Bestandteile . . . . . . . . . . . . . 153.2.2 Systematik eines Zeitschrittes . . . . . . . . . . . . . . . . . . . 173.2.3 Hardware-in-the-Loop-Echtzeit-Simulation . . . . . . . . . . . . 19

3.3 Funktionsmodule der Umgebung: Anpassung und Erweiterung . . . . . . 223.3.1 Protokollierung, Fehlerhandling . . . . . . . . . . . . . . . . . . 223.3.2 Client-Server-Kommunikation zur Steuerung und berwachung . 263.3.3 Modell-Management Varianten und Alternativen . . . . . . . . 293.3.4 Einbinden von Modellen als Simulink S-Function . . . . . . . . 30

3.4 Funktionsmodule der Umgebung: Durchfhrung von Tests . . . . . . . . 313.4.1 Signal-/Gren-Verzeichnis . . . . . . . . . . . . . . . . . . . . 313.4.2 Aufzeichnen von Signalen . . . . . . . . . . . . . . . . . . . . . 333.4.3 Manipulation von Simulations- und elektrischen Signalen . . . . 343.4.4 Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.5 Fahrbahn und Umwelt . . . . . . . . . . . . . . . . . . . . . . . 373.4.6 Fahrmanver, Fahrer, Fahrzeugbedienung . . . . . . . . . . . . . 393.4.7 Stimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.4.8 Verkehrsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4.9 Testautomatisierung, Versuchsreihen . . . . . . . . . . . . . . . 443.4.10 Steuergerte Diagnose . . . . . . . . . . . . . . . . . . . . . . . 47

3.5 Funktionsmodul Fahrzeugmodelle . . . . . . . . . . . . . . . . . . . . . 483.5.1 Fahrzeugaufbau, Massen und Trgheiten . . . . . . . . . . . . . 503.5.2 Fahrwerk: Kinematik und Kraftelemente . . . . . . . . . . . . . 51

3.5.2.1 Realisierung eines Luftfeder-CDC-HIL-Prfstandes . . 533.5.2.2 Wankstabilisierung . . . . . . . . . . . . . . . . . . . 53

IV INHALTSVERZEICHNIS

3.5.3 Lenksystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.5.4 Reifen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.5.5 Bremsanlage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.5.5.1 Realisierung eines ESP-HIL-Prfstandes . . . . . . . . 593.5.6 Antriebsstrang . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.5.7 Aerodynamik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.5.8 Anhnger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.5.9 Kinematik-Sensoren . . . . . . . . . . . . . . . . . . . . . . . . 663.5.10 Kraft- und Momenten-Manager . . . . . . . . . . . . . . . . . . 68

4 Analytische Fahrzeugdynamik 714.1 Motivation und Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . 714.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2.1 Topologie offener Gelenkketten . . . . . . . . . . . . . . . . . . 754.2.1.1 Koordinatensystem Fj (Frame) . . . . . . . . . . . . . 754.2.1.2 Pfadmatrix Dij . . . . . . . . . . . . . . . . . . . . . . 764.2.1.3 Generalisierter Krper Gj (Generalized Body) . . . . . 76

4.2.2 Notation und Formelapparat . . . . . . . . . . . . . . . . . . . . 764.2.2.1 Synthetische Kinematik . . . . . . . . . . . . . . . . . 764.2.2.2 Analytische Kinematik . . . . . . . . . . . . . . . . . 78

4.2.3 Massengeometrie . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.3.1 Generalisierter Krper Gj (Generalized Body) . . . . . 804.2.3.2 Erweiterter Krper B+j (Augmented Body) . . . . . . . 804.2.3.3 Kinetik und Dynamik . . . . . . . . . . . . . . . . . . 81

4.2.4 Massengeometrische Rekursionen . . . . . . . . . . . . . . . . . 824.2.5 Hamel-Transformation und Maggi-Matrix . . . . . . . . . . . . 824.2.6 Algebraisierung der Kinematik . . . . . . . . . . . . . . . . . . 834.2.7 Bewegungsgleichung nach dem Prinzip von DAlembert/Lagrange 84

4.3 Topologie des Kraftfahrzeugs . . . . . . . . . . . . . . . . . . . . . . . 844.3.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.3.2 Topologische Struktur des Fahrzeugs . . . . . . . . . . . . . . . 854.3.3 Fahrdynamikmodell eines Pkw Car . . . . . . . . . . . . . . 874.3.4 Fahrdynamikmodell eines Pkw-Anhngers Trailer . . . . . . 884.3.5 Fahrdynamikmodell eines Motorrads Motorcycle . . . . . . 88

4.4 Koordinaten des Fahrzeugs . . . . . . . . . . . . . . . . . . . . . . . . . 894.4.1 Externaler Aspekt ein kinematisch ungebundenes System . . . 904.4.2 Internaler Aspekt Modellierung der Radaufhngungen . . . . . 92

4.4.2.1 Kinematik Handling . . . . . . . . . . . . . . . . . . 964.4.3 Drehbewegung der Rder Sonderrolle des drehenden Rades . . 984.4.4 Koordinaten des Fahrzeugmodells bersicht . . . . . . . . . . 100

4.5 Massenmatrix des Fahrzeugs . . . . . . . . . . . . . . . . . . . . . . . . 1014.5.1 Bemerkungen zur direkten Auswertung des Prinzips von DA. . . 1014.5.2 Struktur der Massenmatrix, bersicht . . . . . . . . . . . . . . . 101

INHALTSVERZEICHNIS V

4.5.3 Generalisiertes Fahrzeug-System F1: Externale Bewegung . . . . 1034.5.4 Radaufhngungen: Einfedern, Lenken . . . . . . . . . . . . . . . 1034.5.5 Rder: Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044.5.6 Elemente der Massenmatrix . . . . . . . . . . . . . . . . . . . . 1044.5.7 Optimierung der Transformation eines Tensors 2-ter Stufe . . . . 106

4.6 Aufstellen der Bewegungsgleichungen des Fahrzeugs . . . . . . . . . . . 1074.6.1 Rekursive Verfahren der Kinetik und das Fischer-Frame . . . . . 1084.6.2 Kinematische Basisdaten (F0 F1 F2, aufwrts) . . . . . 1094.6.3 Massengeometrie (F2 F1 F0, abwrts) . . . . . . . . . . 1114.6.4 Kinematik und Dynamik . . . . . . . . . . . . . . . . . . . . . . 111

4.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5 Reifen-Kinematik auf gewlbter Fahrbahn 1155.1 Motivation und Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . 1155.2 Kontaktkraft-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5.2.1 Kinematik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.2.2 Krfte und Momente . . . . . . . . . . . . . . . . . . . . . . . . 1175.2.3 Dynamik Seitenwandtorsion und Querelastizitt . . . . . . . . . 118

5.3 Notation und Formelapparat . . . . . . . . . . . . . . . . . . . . . . . . 1195.3.1 Differentialgeometrie gekrmmter Flchen . . . . . . . . . . . . 1195.3.2 Levi-Civita Bewegung . . . . . . . . . . . . . . . . . . . . . . . 120

5.4 Geometrie-Mapping: Von Radmitte C zum Kontaktpunkt P . . . . . . . . 1215.4.1 Geometrische Begriffe . . . . . . . . . . . . . . . . . . . . . . . 1215.4.2 Bezugssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225.4.3 Karlsruher Kinematische Kette K3 . . . . . . . . . . . . . . . . 128

5.5 Reifenkinematische Referenzgren . . . . . . . . . . . . . . . . . . . . 1295.5.1 Lngsschlupf s, Querschlupf s und Schrglaufwinkel . . . . . 1295.5.2 Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.6 Organisation des Auswertungsablaufs . . . . . . . . . . . . . . . . . . . 133

6 Zusammenfassung und Ausblick 135

Literaturverzeichnis 137

VI INHALTSVERZEICHNIS

1Kapitel 1

Nomenklatur

Abkrzungen und Begriffe, allgemein

Antiblockiersystem

Adaptive Cruise Control

Antriebsschlupfregelung

Controller Area Network

Central Processing Unit

Steuergert, Electronic Control Unit

Elektronisches Stabilitts-Programm

Time-Triggered Protocol

Keyword protocol 2000, Protokoll zur Steuergerte-Diagnose, [ISO03]

! #"%$'&(! #)

Unter Datensatz . . .*,+! #)-",.

Ein System, das auf ein Ereignis innerhalb einer vorgegebenen Zeitspanne,der Reaktionszeit, garantiert reagiert, arbeitet in Echtzeit. Die Zeitskalen derSimulation auf einem Echtzeitsimulator und die der real ablaufenden, absolutenZeit sind identisch.

/102

Input/Output, Erfassung und Ausgabe von Signalen

2 KAPITEL 1. NOMENKLATUR

3"%45&-6,*'+

Unter Versuch . . .

Vektor-, Matrix- und Tensorrechnunga, A, ,

Skalare Gren

a, A, ,Vektoren im dreidimensionalen Raum

a,A,,Matrizen, Spaltenmatrizen

a, A, ,Tensoren 1. Stufe (:= Vektor)

a, A, ,Tensoren 2. Stufe

[n]i Vektor n, dargestellt in der Basis Fi

Tij Transformationsmatrix, die einen Vektor von der Basis i in die Basis j berfhrt:[n]j = Tij [n]i

Funktionen und Rechenregeln 74

( ) Spur-Funktion

( )T transponiert-Funktion

a b Skalarprodukt von a und b

a b Vektor- oder Kreuzprodukt von a und b.

a Das Symbol a steht fr schiefsymmetrischen Tensor 2. Stufe des Vektors a.Es gilt:

[a b

]=

a

b1b2b3

(1.1)

=

0 a3 a2a3 0 a1a2 a1 0

b1b2b3

(1.2)

a b = (a) b = a b (1.3)

3a b Tensor- oder Dyadisches Produkt der Vektoren a und b

Es gelten folgende Beziehungen:(a b

) c = a

(b c

)(1.4)

[a b

]=

a1b1 a1b2 a1b3a2b1 a2b2 a2b3a3b1 a3b2 a3b3

(1.5)

(a b

)T= b a (1.6)

A BDoppelkontrahierendes Produkt

A BT

= tr(A B) =i,j

aij bji (1.7)

qi(a b) =

a

qi b + a

b

qi(1.8)

Mechaniki, j, k, l,m, . . .

Indizes (= 1, . . . , n)

N Anzahl der Partikel eines Systems

q (qi, . . . , qn)Holonome oder globale oder Lagrangesche oder System-Koordinaten, generali-sierte Koordinaten

q 8 qi Generalisierte Koordinaten, i-te generalisierte Koordinate

pii i-te Quasi-Koordinate.pii ist das Integral der zugehrigen Quasi-Geschwindigkeit: pii =

qidt

i piii-te Quasi-Geschwindigkeit. Quasi-Geschwindigkeiten sind (i.Allg. nicht integra-ble) Linearkombinationen generalisierter (oder Lagrangescher) Geschwindigkei-ten qi.Generalisierte Geschwindigkeiten sind zeitliche Ableitungen generalisierter Ko-ordinaten qi = dqi/dt, siehe auch Hamel-Transformation, Gleichung (1.26).

i =Hij qj

wobei Hij Funktionen der qj sind.


Oi 8 M Punkte im Raum

O = O0Ursprung (origin), Ursprung des Systems F0

C Schwerpunkt, (Massen-)Schwerpunkt (center of mass)

OiM Vektor vom Punkt Oi zum Punkt M

Fi {Oi, X i Y i Zi

}Rechtwinkliges, kartesisches, rechtssinniges Koordinatensystem i mit dem Ur-sprung im Punkt Oi und den drei Basisvektoren X i, Y i, Zi.

F0 Galileisches (Newtonsches) Koordinatensystem F0 ={O0, X0 Y 0 Z0

}, absolu-

tes Bezugssystem, Inertialsystem

F1 Mitbewegtes Bezugssystem, Basis-Koordinatensystem des Fahrzeugs.

Es dient der Beschreibung der globalen Fahrzeugbewegung im Raum. Alle ande-ren Krper des Fahrzeugs werden bez. dieses (mitbewegten) Koordinatensystemslokal parametriert.

F 9i 8;:. &

5ek P/qkSystem-Vektor oder Heuns Begleitvektor [Heu02], partielle Ableitung desPunktes P nach der Koordinaten qk

pk pk(M)Translationsachse der Koordinaten qkprismatischer Anteil des Begleitvektors der Koordinaten qk

rk Rotationsachse der Koordinate qkrotatorischer Anteil des Begleitvektors im Punkt M der Koordinaten qk

Bi Krper (body) i, stets fest mit Koordinatensystem Fi verbunden

B1 Krper 1, Fahrzeugaufbau; stets fest mit Koordinatensystem F1 verbunden

{B2} Krper 2; alle Krper des Fahrzeugs, die sich bez. des FahrzeugaufbausystemsF1bewegen, werden als B2 bezeichnet.Krper B2 und Krper vom Typ B2 werden synonym verwendet.

Gi Generalisierter Krper (generalized body) i

B+i Erweiterter Krper (augmented body) i

dm Masse eines Partikels

i Materielles System

M Materieller Punkt M des Systems

mk Masse des Partikels k

M i Masse des Systems i

j

Binetscher Trgheitstensor des Systems j bez. des Punktes Oj bzw. bez. desPunktes Oi

j

j

OjM OjM dm (1.9)

j(Oi) =

j+OiOj OiOj mj (1.10)

Ij

Segnerscher oder klassischer Trgheitstensor des Systems j bez. des PunktesOj bzw. bez. des Punktes Oi

Ij

j

OjM OjM dm (1.11)

Ij(Oi) = I

j+ OiOj

OiOj mj (1.12)


A Massenmatrix des DGL-Systems, Matrix [n n]

aij Element (i, j) der Matrix A oder eines Tensors in Zeile i und Spalte j

b rechte Seite des DGL-Systems, Vektor [n 1]"@&A 7B"C&(*,+ED "%6E$.GF6E$'F

Beschleunigungsanteil, der keine zweiten Ableitungen nach Koordinaten qi, piienthlt

F ij Kraft (Force) von System i auf System j

T ij(P )Moment (torque) bez. des Punktes P von System i auf System j

W ij(P )Kraftwinder (Wrench) 2-Tupel von Kraft und Moment (bez. eines Punktes),

W ij(P ) =

[F ij

T ij(P )

](1.13)

Kraft F ij von System i auf System j (:= [3 1]) und Moment T ij(P )von System i auf System j bez. des Angriffspunktes P (Point of Attack)(:= [3 1]).

Tij(P ) Kinematische Schraube (twist) in dem mit Punkt P im System Fj koinzidie-

renden Punkt bez. des Systems Fi

Unter Verwendung obiger Notation lauten die relativkinematischen Grundformeln wiefolgt:

i

k = i

j + j

k (1.14)

vik(A) = vij(A) + v

jk(A) (1.15)

und

ik = ij +

jk +

i

j j

k (1.16)

aik(A) = aij(A) + a

jk(A) + 2

i

j vjk(A) (1.17)

Die analytische Mechanik formuliert die Kinematik des Punktes A mit Hilfe der Quasi-Geschwindigkeiten i und partiellen Ableitungen Ai entsprechend:

v0(A) =

ni=1

Aii (1.18)

a0(A) =n

i=1

Aii +n

i,j=1

Aijij (1.19)

70

k =

ni=1

ii (1.20)

0k =n

i=1

ii +n

i,j=1

ijij (1.21)

wobei die Vektoren A und

Ai A

pii=v0(A)

i(1.22)

Aij Aipij

=2v0(A)

piji=2a0(A)

ji(1.23)

i

0

k

i(1.24)

ij

0

k

i=

20kpiji

=20kji

(1.25)

als Begleitvektoren (accompanying vectors) bezeichnet werden. i pii ist die i-te Quasi-Geschwindigkeit, deren Zeit-Integral die i-te Quasi-Koordinate pii ergibt. n bezeichnet dieAnzahl der Freiheitsgrade des betrachteten Systems.Die Quasi-Geschwindigkeiten i werden definiert durch die lineare kinematische Diffe-rentialgleichung (Hamel-Transformation)

i =

j

H ij qj . (1.26)

qj sind wahre oder Lagrangesche Geschwindigkeiten, d.h. Ableitungen von Lagegrenqi, und H ij ist die Hamelsche Transformationsmatrix. Die Elemente H ij der Hamel-Ma-trix H sind i.Allg. Funktionen der generalisierten Koordinaten qi: H ij = H ij(q1, . . . qN).

Fahrdynamik und Reifenkinematik Schwimmwinkel, Winkel zwischen der Fahrzeug-Schwerpunktsgeschwindigkeit

und der Mittelebene des Fahrzeugs

Schrglaufwinkel

Sturzwinkel des Rades gegenber der Fahrbahn

Gierwinkel%HE,*,+'&A"

Raddrehachse (C, Y C), d.h. Achse, um die sich die Felge dreht: 0

R = b Y C


Y C Einheitsvektor der Radachse, um die sich Rad und Felge drehen,H"%B"%$'"

(C)Die Radebene (C) steht senkrecht auf Y C und bildet die Mittelebene des Rades.

C Radmittelpunkt C, Durchstopunkt der Radachse durch die Radebene

P Kontaktpunkt P Reifen/Fahrbahn.

Definition:P ist derjenige Punkt der Schnittgeraden der Radebene mit Fahrbahno-berflche S, der den Abstand zum Radmittelpunkt C minimiert.

IE6E4

(P,XH)Schnittgerade der Radebene (C) mit der Fahrbahn-Tangentialebene (P ) imKontaktpunkt P . XH bezeichnet einen Einheitsvektor in Richtung der Spur.

J! #&(*,+

8 FBGummistollen des Reifen belt in der Umgebung des KontaktpunktesP . Der Latsch befindet sich im Kontakt mit der Fahrbahn-Tangentialebene(P ) (ausgedehnte Kontaktflche bzw. Kontaktzone Reifen-Fahrbahn). DasKoordinatensystem FB ist Latsch-fest. Eine exakte Definition wird im Abschnitt5.4.2 gegeben.

9Kapitel 2

Einleitung

Die Wettbewerbssituation auf globalisierten Mrkten hat sich auch fr die Automobilin-dustrie verschrft. Nur wer mit ausgereiften und bezahlbaren Lsungen am schnellsten aufden Markt kommt eine Reduktion der durchschnittlichen Time-to-Market-Zeiten um fast20% von 2004 auf 2005 wird prognostiziert [Kif02], wer die gestiegene Komplexitt unddie Verwendung elektronischer Bauteile beherrscht und sie zu erweiterter Funktionalittund erhhtem Bedienkomfort umzusetzen wei, der hat Erfolg. Der Anteil der Elektronikan der Wertschpfung des Autos steigt kontinuierlich und wird nach Expertenschtzungenbis 2010 die Marke von 40 Prozent erreichen [Hub04]. Eines der Hauptziele bei derEntwicklung moderner Fahrzeuge ist ein mglichst hohes Ma an wahrnehmbaremKundennutzen in Form von Fahrkomfort, Funktionalitt und Fahrsicherheit, bei verkrz-ten Entwicklungszeiten und reduzierten Entwicklungs- und Herstellungskosten. StrksteAntriebskraft sind hierbei die Entwicklungen im Elektronikbereich. Ein wesentliches Leit-prinzip stellt die Entwicklung von mechanischen und elektrischen Systemkomponentenals integrierte Einheiten unter Ausnutzung von Synergieeffekten zwischen den einzelnenFachdisziplinen (Abbildung 2.0.1) dar.

MechanikInformations-

TechnikElektronik

Elektro-

technik

Mechatronik

Abbildung 2.0.1: Mechatronik Synergie-Effekt durch disziplinbergreifende Entwick-lung

Mechatronische Systeme zeichnen sich oft durch komplizierte Eigendynamik aus. Ehe-mals rein mechanische Wirkprinzipien und Kopplungen zwischen Aggregaten werden

10 KAPITEL 2. EINLEITUNG

ersetzt durch elektronische Wirkprinzipien und elektrische Verbindungen. Neue Funktio-nalitt und Flexibilitt wird durch Softwareentwicklung ohne neue mechanische Hardwarerealisiert. Die funktionale und rumliche Integration von intelligenten Sensoren undAktuatoren ermglicht es den beschrnkten Bauraum im Fahrzeug optimal zu nutzen.Diese Integrationsleistung wird von den Entwicklungsingenieuren aus verschiedenenAbteilungen beim Fahrzeughersteller und seinen Zulieferern in interdisziplinrer Zu-sammenarbeit erbracht. Systemkomponenten und ganze Module werden bei Zulieferernund Systemlieferanten entwickelt und gefertigt und beim Automobilhersteller zu einemFahrzeug zusammengefgt. Der gesamte Entwicklungs- und Produktionsprozess muss andiesen Randbedingungen ausgerichtet werden.

Aufgrund der gestiegenen Anzahl komplexer, mechatronischer Komponenten mit kom-plizierter, variabler und regelbarer Eigendynamik und umfangreicher Vernetzung, diesich alle auf das Systemverhalten auswirken, ist eine Erprobung und Absicherungmit Prototypen in voller Breite ausgeschlossen. Vielmehr muss whrend des gesamtenEntwicklungsprozesses konsequent das Werkzeug der Simulation eingesetzt werden:Bereits in frhen Konzept- oder Entwicklungsphasen wird das Verhalten von Systemkom-ponenten analysiert. Die einzelne Komponente muss zum einen autark den spezifiziertenAnforderungen gengen, zum anderen muss sich auch im Gesamtsystem-Verbund dasgeforderte Verhalten einstellen.Den Ausgangspunkt der Entwicklung bilden meist sogenannte reine Model-in-the-Loop(MIL)-Experimente, bei denen die in reine Softwaremodelle umgesetzten Spezifikationenberprft werden. Sobald aus Konzepten konkrete Entwicklungsvorgaben geworden sind,wird auf Software-in-the-Loop (SIL) bergegangen. Konkrete Funktionsmodelle einzel-ner Komponenten und Aktuatoren, wie z.B. von Fahrwerksdmpfern, Servo-Motoren zurLenkuntersttzung oder einem Zndschloss, werden entsprechend konkreter Vorgabenaufgebaut und parametriert. Der zugehrige Reglercode wird implementiert und alsreines Software-Modul ohne elektrisches Signalinterface in die Simulationsumgebungintegriert. Sind diese Tests erfolgreich durchlaufen und erste Prototypen-Steuergerte alsHardware verfgbar, folgen Tests auf Hardware-in-the-Loop -Prfstnden (HIL). Hierbeiwerden die Software-Regler gegen reale Steuergerte getauscht. Das Signal-Interfacedieser Hardware-Steuergerte wird ber spezielle Schnittstellen mit leistungsstarkenEchtzeit-Computern verbunden. Per Simulation wird den Steuergerten eine vollstndigeUmgebung in Echtzeit vorgetuscht: Fahrversuche knnen so reproduzierbar virtuelldurchgefhrt werden und dabei das Verhalten von Reglern, Signalinterface, Aktuatoren,Diagnose und Gesamtsystem berprft werden. Elektrische Fehler, Diagnosefunktionalittund Kompatibilitt im Steuergerteverbund werden kontrolliert. Der Austausch vonPrototypen-Steuergerten durch Serien-Steuergerte folgt.

11

Aufgabenstellung und ZieleSchwerpunkt der vorliegenden Arbeit ist, durch ein aufgabenorientiertes Entwicklungs-werkzeug und entsprechende Technologien dazu beizutragen, die Komplexitt der Ent-wicklungsaufgaben besser zu beherrschen. Im ersten Teil der vorliegenden Arbeit, Kapitel3, wird die Konzeption und Realisierung einer solchen Entwicklungsumgebung vorge-stellt, die fr Fahrzeug-Regelsysteme allgemein und speziell fr den Entwicklungsschwer-punkt Fahrdynamikregelsysteme folgende Anforderungen bercksichtigt:

Bedienbarkeit: Anwender des Entwicklungswerkzeugs sind nicht nur Simulations-spezialisten aus den Berechnungsabteilungen der Automobil-Hersteller, sondern vorallem auch Applikationsingenieure und Versuchsfahrer. Die intuitive, an aus derPraxis bekannten Begriffen, Funktionseinheiten und Strukturen, wie z.B. Fahrzeug,Reifen, Fahrwerk, Achsfeder, Versuch, Fahrbahnbreite, orientierte Bedienung hltden Schulungsaufwand gering und erlaubt einen flexiblen Einsatz der Mitarbeiter.Auerdem wird hierdurch schon im Vorfeld Fehlinterpretationen aufgrund vonFehlbedienung entgegen getreten.

Durchgngigkeit: Der gesamte Entwicklungsproze soll durchgngig von der Kon-zeptphase bis hin zur Erprobung auf Hardware-in-the-Loop -Simulatoren unter har-ten Echtzeitbedingungen in einer Entwicklungsumgebung mit den gleichen Simu-lationsmodellen, Parameterstzen und Testszenarien erfolgen. Bei der Konzeptionund Realisierung des Entwicklungswerkzeugs ist auf eine im Hinblick auf geringenund vor allem pro Zeitschritt konstanten Rechenzeitbedarf der Simulationsmodellezu achten.

Aufgabenorientiertheit: Die Entwicklungsumgebung soll die Untersuchung vonFahrdynamik-Regelsystemen fr Pkws und Motorrder, als Einzelfahrzeug und imGespann-Betrieb mit einem Hnger, ermglichen. Die Modellgte muss den hohenAnforderungen von Fahrdynamik-Regelsystemen gengen.

Modell- und Datenmanagement: Im Rahmen der interdisziplinren, firmenber-greifenden Zusammenarbeit ist der stete Austausch von Parameter-, Modell- undHardware-Stnden zwischen allen Projektpartnern und den verschiedenen Simulati-onsplattformen (Software-in-the-Loop, Hardware-in-the-Loop) notwendig. Hierfrist es wichtig, dass Parameterstze einzelnen Baugruppen oder Funktionseinheitenzugeordnet sind und so modular ausgetauscht werden knnen. Gleiches gilt fr dieSimulationsmodule oder Hardware-Komponenten. Der einfache Wechsel zwischenverschiedenen Versionsstnden ist fr die Entwicklungs- und besonders fr dieValidierungsarbeit notwendig.

Modularitt und Skalierbarkeit: Wachsender Bedarf an Input/Output -Signalen oderdetailliertere Simulationsmodelle stellen hhere Anforderungen an die eingesetzteHardware in Bezug auf Zeitbedarf und Hauptspeicher. Neuere, schnellere Rech-ner oder die Verteilung von Aufgaben auf mehrere CPUs bieten hier Auswege.

12 KAPITEL 2. EINLEITUNG

Industriestandards bei Hardware, Infrastruktur (Bus-System) und Systemsoftwaregarantieren herstellerunabhngige Systemerweiterungen entsprechend der am Marktgerade verfgbaren maximalen Rechnerleistung und Funktionalitt.

Automatisierbarkeit, Reproduzierbarkeit: Bei jeder nderung an Steuergertesoft-ware, elektrischer Verkabelung oder an den Simulationsmodellen und ihrer Para-metrierung mssen automatisiert Testreihen mit Standard-Szenarien durchgefhrtwerden knnen. Die reproduzierbaren Versuchsbedingungen sichern die Rck-wirkungsfreiheit von Softwarenderungen und damit den Entwicklungsprozessund das Entwicklungswerkzeug ab. nderungen im Reglercode lassen sich unterverschiedenen Witterungsverhltnissen unabhngig von der aktuellen Jahreszeitberprfen. Darber hinaus steht durch die Automatisierung die Mglichkeit zurAbsicherung von Toleranzen und Systemkomponenten-Haltbarkeit zur Verfgung.

Schwerpunkt des zweiten Teils, Kapitel 4, ist die Bereitstellung einer modular strukturier-ten, auf geringen Rechenzeitbedarf hin optimierten Simulationsplattform fr die Fahrzeug-typen Pkw, Pkw mit Anhnger und Motorrad. Die Modelle mssen herstellerbergreifendeinsetzbar sein und den aktuellen Erfordernissen der Fahrdynamik-Reglerentwicklunggengen.

Der dritte Teil, Kapitel 5, behandelt die spezielle Thematik Kinematik des Reifen-Fahrbahn-Kontakts auf gewlbten Fahrbahnen. Der Reifen-Fahrbahn-Kontakt hat ma-geblichen Einfluss auf das Fahrverhalten und die Fahrsicherheit von Fahrzeugen undstellt fr die meisten Fahrdynamik-Regler die wesentliche Eingriffsmglichkeit auf dieFahrdynamik dar. Zur Parametrierung der dort bertragenen Krfte und Momente wirddas Reifenverhalten auf Prfstnden oder mit Messfahrzeugen vermessen. Den damitparametrierten Simulationsmodellen kommt anschlieend die Aufgabe zu, die unterspeziellen analytischen Randbedingungen vermessenen Reifeneigenschaften auf dieaktuellen Gegebenheiten beim Befahren modellierter, realer Fahrbahnoberflchen zubertragen. Hierzu mssen den aktuellen Kontaktkrften, Geschwindigkeitsbedingungenund Reibwertverhltnissen im Kontaktbereich die korrespondierenden Messsituationenzugeordnet werden.

13

Kapitel 3

Simulationsumgebung undSoftwarearchitektur einer modernenEntwicklungsplattform: CarMaker vonIPG

Das CarMaker-Simulationspaket von IPG Automotive GmbH ist ein umfangreichesProgrammpaket fr Entwicklung und Test von Steuergerten in Kraftfahrzeugen. Darinintegriert sind zahlreiche, von den Ingenieuren, Informatikern und Mathematikern vonIPG entwickelte Soft- und Hardware-Module wie z.B. Modelle fr Fahrbahn, Reifenund Fahrer, Programme zur Darstellung von Zeitverlufen und 3D-Animationen, dieIntegration in die Matlab/Simulink-Welt, Hardware zum Generieren elektrischer Fehleroder Bibliotheken zur Kommunikation mit Steuergerten und deren Diagnose-Interface.Der Autor hat am Konzept und an der Realisierung des CarMaker-Simulationspaketsmageblichen Anteil.

3.1 Mechatronische Systeme im FahrzeugIn die Automobilindustrie hat eine technologische Vernderung Einzug gehalten. Ausehemals rein mechanischen Komponenten sind mittlerweile hoch integrierte Mechatronik-Systeme geworden. Hierdurch werden Systemeigenschaften in weiten Bereichen variabel.Damit einer mechatronischen Lsung gegenber der traditionellen, rein mechanischen derVorzug gegeben wird, muss sie Vorteile in Bezug auf hohe Zuverlssigkeit, Funktionalittund Sicherheit fr den Endanwender, reduziertes Bauvolumen, hheren Wirkungsgradbieten und kostengnstiger bei Herstellung, Wartung und spterer Entsorgung sein.Mechatronische Systeme stellen gegenber traditionellen Lsungen wesentlich erweiterteAnforderungen:

Erfassung des Systemzustands durch Sensoren: Mit Hilfe von Sensoren verschafftsich der Regler alle relevanten Zustandsgren, sowohl ber das zu regelnde System,

14 KAPITEL 3. SIMULATIONSUMGEBUNG UND SOFTWAREARCHITEKTUR

als auch ber die von ihm kontrollierten Aktuatoren. Signale mssen eindeutigplausibilisiert werden. Den Ausfall einzelner Sensoren muss die Regelstrategiemglichst kompensieren knnen und ein sicheres und fr den Fahrer beherrschbaresSystemverhalten gewhrleisten. Fllt z.B. das Dehzahlsignal eines Rades aus, wirdauf Basis der verbleibenden Drehzahlsignale eine Ersatzdrehzahl ermittelt. Hufigstehen weitere Alternativ-Signale bei vernetzten Steuergerten zur Verfgung: Z.B.ist die Gre Fahrgeschwindigkeit in der Bremsanlage ber die Raddrehzahlsignalevorhanden und im Antriebsstrang ber Getriebedrehzahl unter Annahme des Rei-fenradius; aus Lenkradwinkel, Gierrate und Querbeschleunigung kann ebenfalls aufdie Fahrgeschwindigkeit geschlossen werden.

Energiemanagement: Elektromechanische Aktuatoren bentigen in einem 12 VoltBordnetz hohe Stromstrken und damit kurze Kabellngen und groe Leitungsquer-schnitte. Das Zusammenbrechen der Versorgungsspannung muss auch bei einemmeist nur kurzzeitigen hohen Energiebedarf zuverlssig verhindert werden. Beigleichzeitigem Bedarf mehrerer elektrischer Verbraucher verhindert eine gezielte,priorisierte Verteilung der zur Verfgung stehenden Ressourcen Engpsse. Hierzuein Beispiel: Die Aktivierung der Hydraulikpumpe durch das Bremsen-Steuergertist ein sicherheitsrelevanter Eingriff. Eine Leistungs-Anforderung des Klimakom-pressors parallel hierzu wird abgewiesen.

Zuverlssigkeit, Ausfallsicherheit: Durch den Einsatz in sicherheitsrelevanten Be-reichen wie z.B. Airbag, elektrische Lenkung und Bremsanlage kommt der Null-Fehler-Toleranz besondere Bedeutung zu. Das mechatronische System muss unterallen Randbedingungen und ber die gesamte Lebensdauer des Fahrzeugs zu-verlssig funktionieren. Fehlfunktion wird nicht akzeptiert, Totalausfall ist durchRckfallebenen zu verhindern.

Gefhrdungsvermeidung: Passive Systeme werden nicht von selbst aktiv, sie rea-gieren, sie bedrfen einer Einwirkung aus der Umwelt oder durch den Fahrer.Passive Systeme enthalten in diesem Sinne kein zustzliches Gefahrenpotential.Aktive Systeme dagegen greifen selbstndig in das Systemverhalten ein: Eine Aktiv-Lenkung ndert die Radstellung ohne dass der Fahrer am Lenkrad dreht, ein Fahr-dynamikregler bremst einzelne Rder oder fordert zur Verhinderung blockierenderAntriebsrder zustzliches Motormoment an. Fragen der Systemsicherheit und derProdukthaftung kommt zentrale Bedeutung zu.

Vernetzung: Im Verbund arbeitende, vernetzte Regelsysteme erschlieen ein deut-lich erweitertes Potential an realisierbarer Funktionalitt. Durch Kommunikation derRegler untereinander wird die Qualitt der Regelung deutlich gesteigert. Redundanzund Sicherheit wird durch die breite Verfgbarkeit der im Systemverbund ermittel-ten Zustandsgren erhht. Mehrfachnutzung von Informationen erffnet die Mg-lichkeit zur Einsparung von Sensoren und damit zur Reduktion der Bauteilanzahlund mglicher Fehlerquellen.

3.2. ARCHITEKTUR DER SIMULATIONS- UND PRFSTANDSUMGEBUNG 15

Funktionalitt ist nicht mehr an ein spezielles Steuergert gekoppelt: So lassen sichbrachliegende Ressourcen vorhandener Steuergerte fremdnutzen oder gezielt ineinem Steuergert zusammenfassen.

Dezentrale, intelligente Sensor-Aktuator-Module werden von bergeordneten Mo-dulen im Netzwerk kontrolliert und bernehmen eigenstndig Regelungsaufgaben.

Diesen Anforderungen kann durch den Einsatz angepasster Entwicklungsprozesse undgeeigneter Entwicklungs- und Testwerkzeuge begegnet werden.

3.2 Architektur der Simulations- und Prfstandsumge-bung

3.2.1 Bedienkonzept, Struktur und BestandteileFr Entwurf und Realisierung von regelungstechnischen Systemen und fr die Simulationvon dynamischen Systemen stehen leistungsfhige Werkzeuge zur Verfgung. Ihr Schwer-punkt liegt meist entweder im Bereich regelungstechnischer Systeme oder im Bereichallgemeiner Simulation. Was der Entwickler eines mechatronischen Fahrdynamikregel-systems bentigt, ist eine Umgebung, die beide Bereiche miteinander verbindet (sieheAbbildung 3.2.1). Der Anwendungsbereich erstreckt sich von der Simulation mit konzep-tionellen Software-Regelalgorithmen und einfach parametrierten Fahrzeugmodellen alsRegelstrecke bis hin zu Simulationen im fahrdynamischen Grenzbereich auf Hardware-in-the-Loop-Prfstnden mit als Hardware ausgefhrten Steuergerten und aufwndig imFahrversuch validierten Fahrzeugmodellen.

environment

control

pathcontroller

Abbildung 3.2.1: Regler und Regelstrecke Bestandteile einer gemeinsamen Umgebung

Die hier vorgestellte Entwicklungsplattform fr mechatronische Fahrdynamikregelsyste-me ist auf dieses Arbeitsgebiet an der Schnittstelle unterschiedlicher Fachdisziplinen aus-gerichtet. In einer Matlab/Simulink-Version steht sie dem Reglerentwickler zur Verfgung.Hier kann er sich in der ihm vertrauten Arbeitsumgebung auf seine Entwicklungsarbeit


konzentrieren. Als Streckenmodelle fr die Regelsysteme stehen Fahrzeugmodelle vonPkws und Motorrdern zur Verfgung. Diese Modelle sind modular strukturiert und daraufausgerichtet, einzelne Baugruppen, wie z.B. den Motor oder den Reifen, oder auch ganzeFunktionseinheiten, wie z.B. das Lenksystem oder den kompletten Antriebsstrang, durchunterschiedliche Simulationsmodelle abdecken zu knnen. Die Fahrzeugmodelle bietenhierfr zahlreiche Schnittstellen und ein leistungsfhiges Modul zur Verwaltung undAuswahl verschiedener Modellvarianten einer Baugruppe. Die Ergebnisse der verschie-denen, speziellen Entwicklungsumgebungen sind in Form von exportierten Modellen undParameterstzen direkt bernehmbar. In Matlab/Simulink oder in C formulierte Modellesind direkt nutzbar.Fertige, vom Spezialisten validierte Parameterstze knnen fr die Simulation per Refe-renz einfach angewhlt werden. Durch ihre bauteilorientierte, modulare Struktur ist dieParametrierung sehr anschaulich. Gewnschte Variationen lassen sich von vorhandenenParameterstzen meist auch ohne Spezialkenntnisse direkt ableiten.Eine Anforderung an das Bedienkonzept war die intuitive Bedien- und Anwendbarkeit. Zuder angesprochenen Zielgruppe zhlen speziell Versuchsfahrer und Applikationsingenieu-re, deren Alltag ansonsten weniger von der numerischen Simulation und Berechnung ge-prgt ist. Spezialisten aus dem Bereich Simulation drfen fr den alltglichen Einsatz nichterforderlich sein. Die Bedienung ist deshalb am praktischen Fahrversuch ausgerichtet. Eswurde versucht, das gewohnte Arbeitsumfeld als virtuelle Umgebung bereitzustellen. Diesbedeutet:

Mit einem Fahrzeug, bereift mit einem bestimmten Reifensatz, werden

mit oder ohne angehngtem Hnger,

auf einer Teststrecke oder einem Testgelnde unter speziellen Umweltbedingungen,wie z.B mit Seitenwind oder bei nasser, glatter Fahrbahn,

von einem Fahrer

Fahrmanver und Tests durchgefhrt.

Die Zusammenstellung dieser Angaben werden als Versuch oder TestRun bezeichnet. Sieumfasst alle Angaben, die zur vollstndigen Beschreibung einer Simulation notwendigsind, sei es, dass sie direkt im Versuchsdatensatz spezifiziert wird oder dass sie perReferenz erfolgt. Eine Simulation ist die Durchfhrung eines Versuchs.Der Versuch, die Umgebung, das Arbeitsumfeld der Fahrdynamikregler, stehen als virtu-elle Umgebung zur Verfgung. Mit dieser muss der Entwicklungsingenieur interagieren.Hierfr bentigt er geeignete Hilfsmittel:

Konfiguration von Versuchen: Dialoge zur Parametereingabe, Editoren zur Definiti-on der Fahrstrecke oder der Fahraufgabe etc.

Durchfhrung und berwachung: Start- und Stop-Befehle, berwachung aussage-krftiger Gren in Form von numerischen Anzeigen, als Zeigerinstrumente oder


The Virtual VehicleEnvironment

The CIT

Communication

Control and Direct AccessTools

File ManagementTools

Analysis and VisualizationTools

ParametrizationTools

Abbildung 3.2.2: Virtuelle Umgebung und Interface-Toolbox

anderer spezieller Anzeigen, als Zeitverlufe und als 3D-Animation des in dervirtuellen Umgebung ablaufenden Geschehens. Die rumliche Animation stellt einsehr wichtiges Hilfsmittel zur Beobachtung und Beurteilung von Fahrmanvern dar.

Analyse und Auswertung: Aufzeichnung von Signalen, deren Analyse, Ermittlungvon Kennwerten

Protokollierung: Dokumentation der durchgefhrten Versuche und deren Ergebnis-se.

Die virtuelle Fahrzeug-Umbegung (Virtual Vehicle Environment, VVE) mit leistungsfhi-gen Simulationsmodellen und angeschlossenen Hardware-Reglern auf der einen Seite unddie Toolbox spezialisierter Werkzeuge (Car Interface Toolbox, CIT) zu deren Bedienungbilden die zwei groen Teilbereiche der Entwicklungsplattform (siehe Abbildung 3.2.2).

3.2.2 Systematik eines ZeitschrittesIn einer Closed-Loop-Simulations- und Prfstandsumgebung fr mechatronische Fahrdy-namikregelsysteme sind zur Berechnung eines Zeitschritts folgende, funktional unterglie-derte Teilaufgaben durchzufhren:

1. Signal-Erfassung (I/O = Input/Output)Einlesen und Auswerten der Ausgaben von Steuergerten, Sensoren und andererMesselektronik. Die Signale werden eingelesen, kalibriert und falls notwendig mit entsprechenden Sensormodellen aufgearbeitet, so dass in der virtuellenUmgebung reale Signale zur Verfgung stehen.

2. AktuatorenInput-Signale werden von als Hardware vorhandenen Aktuatoren entgegengenom-men oder an Aktuator-Modelle weitergeleitet. Es handelt sich dabei z.B. um


Servomotoren, die den Fahrer beim Lenken untersttzen, oder Fahrwerks-Dmpfer,deren Dmpferhrte von einem Regler gezielt gesteuert wird.

3. Umwelt des FahrzeugsErmitteln der ueren Bedingungen fr die aktuelle Kursposition, an der sich dasFahrzeug gerade befindet. Dazu zhlen u.a. die Windverhltnisse, die Temperaturund der Luftdruck.

Bei der Beschaffenheit der Fahrbahnoberflche, z.B. trockener oder nasser Asphaltoder Spiegeleis, handelt es sich um ortsgebundene, Eigenschaften des befahrenenKurses. Das Reifenmodell ermittelt whrend seiner Berechnung die Beschaffenheitder Fahrbahnoberflche fr die Kontaktstellen Reifen-Fahrbahn direkt ber eineAnfrage an das Fahrbahnmodul.

4. Fahrer- und Manver-AktivittenDer Fhrer eines Kraftfahrzeugs bernimmt zahlreiche allgemeine Bedienaufgaben.Dazu zhlen z.B. das Aufschliessen des Fahrzeugs per Funkschlssel, ffnen undSchlieen von Tren, Drehen des Schlssels im Zndschlo, Drcken von Tasternzur Fahrwerks- oder Getriebe-Abstimmung oder das Einschalten des Fernlichts.

Fr Fahraktivitten im Speziellen regelt oder steuert der Fahrer ber Lenkrad,Fahrpedale und Gangwahl die Quer- und Lngsdynamik des Fahrzeugs.

5. Fahrzeug und weitere ModelleNachdem alle Bedieneingriffe erfolgt sind und auch die Einwirkung der Aktuatorenbereitstehen, werden das Fahrzeugmodell und seine Submodule berechnet. Hierzuzhlen, angeordnet nach der Chronologie ihrer Berechnung

das Lenksystem,

die Fahrzeug-Kinematik und

die Fahrwerkskrfte,

die Reifen,

der Anhnger (falls vorhanden),

die Fahrzeugdynamik,

das Bremssystem und

der Antriebsstrang.

6. Signal-Ausgabe (I/O Output)Zustandsgren aus den verschiedenen Simulationsmodulen des Fahrzeugs und derrestlichen virtuellen Umgebung werden durch Sensormodelle geleitet oder direktbernommen und damit Ausgangssignale fr Steuergerte, Aktuatoren oder andereModule generiert.


7. Simulationsberwachung, -Steuerung und BasisdiensteDie Zustandsinformationen der verschiedenen Simulationsmodule werden ausge-wertet. Verlassen einzelne Werte den zulssigen Bereich oder werden Fehlerzu-stnde detektiert, werden entsprechende Reaktions-Manahmen eingeleitet. Diesbedeutet gegebenenfalls auch das Abschalten der Simulation oder des Simulators.

Relevante Ereignisse wie der Start eines Tests, sein fehlerfreies Ende oder seinAbbruch aufgrund von Fehlerzustnden oder ermittelte Kennwerte werden proto-kolliert.

Zur Kommunikation mit Interface Tools werden von dort eingetroffene Nachrichtenausgewertet, darin enthaltene Befehle ausgefhrt und Anfragen beantwortet. Daten-vektoren und zyklische Nachrichten werden versendet.

Die skizzierte Systematik trifft auf den gesamten Bereich von reinen Software-Simula-tionsumgebungen bis hin zu komplexen Hardware-in-the-Loop-Prfstnden mit realenSteuergerten und in Hardware ausgefhrten Fahrzeug-Baugruppen zu.

3.2.3 Hardware-in-the-Loop-Echtzeit-SimulationFahrdynamik-Regelsysteme sind mechatronische Systeme: Die Regelstrecke ist das me-chanische System Fahrzeug. Die Situation wird ber elektrische Sensoren erfasst und vondem im Steuergert ber Software implementierten Regelalgorithmus verarbeitet. Umge-setzt werden die Regeleingriffe ber elektromechanische oder hydraulische Aktuatoren.

Object of Investigation

Simulator

Input / Output Interface

Abbildung 3.2.3: Regler und Mechatronik-Komponenten, der Gegenstand der Entwick-lungsarbeit (Object of Investigation), ber ein Input/Output-Interface gekoppelt mit demSimulator

Modellbildung und Erprobung in der reinen Offline-Simulation sind die ersten Phasenin der Entwicklung eines Reglers. Sind diese abgeschlossen, werden das Signal- und


Aktuatorinterface der Steuergerte-Hardware spezifiziert und nach diesen Vorgaben ersteHardware-Prototypen aufgebaut, die anschlieend experimentell erprobt werden mssen.In dieser Entwicklungsphase kommt das Werkzeug der Hardware-in-the-Loop-Simulationzum Einsatz: Die Regelstrecke wird ber numerische Simulation von Softwaremodellennachgebildet und verhlt sich gegenber dem ber ein Signalinterface angekoppeltenHardware-Prototypen-Regler wie die echte Regelstrecke. Die physikalischen Grenaller Sensorsignale werden von Simulationsmodellen berechnet und konditioniert auf dieelektrischen Sensoreingnge des Reglers gelegt. Die Steuersignale des Reglers werdenan seinen Aktuator-Ausgngen erfasst und von den Aktuator-Simulationsmodellen wei-terverarbeitet. Bei Bedarf werden reale Aktuatoren an das Steuergert angeschlossen, umLasten, d.h. vor allem die Strme, wie im realen Betrieb flieen zu lassen (siehe Abbildung3.2.3).Simulation in Echtzeit ist deshalb notwendig, da ein als Hardware realisierter Reglerimmer in Realzeit arbeitet, Signale einliest, verarbeitet und Aktuatoren bedient.

In der hier vorgestellten Entwicklungsumgebung erfolgt der bergang von der reinenOffline-Simulation zur Hardware-in-the-Loop-Echtzeitsimulation fast unmerklich:

Die Entwicklungsumgebung und die Simulationsmodelle sind die gleichen.

Die Struktur des Berechnungsablaufs bleibt unverndert. Software-Simulationsmo-delle fr den Regler werden deaktiviert, die Signalleitungen werden abgetrennt undber einen Block zur Signalkonditionierung auf den Treiber eines I/O-Moduls zurSignalerfassung bzw. Signalausgabe gelegt.

Die Simulation luft nicht mehr direkt auf dem Bedienrechner, sondern in Echtzeitauf einem separaten Rechner. Dieser Simulationsrechner luft unter dem Echt-zeitbetriebssystem LynxOS. LynxOS ermglicht einen harten Echtzeit-Betrieb undstellt alle notwendigen Dienste, wie z.B. die Netzwerkprotokolle TCP/IP und UDPund den lesenden und schreibenden Filesystemzugriff ber Netzwerk per NFS, zurVerfgung. Hierdurch knnen die CarMaker-Interface-Tools zur Konfiguration undSteuerung der Simulation unverndert eingesetzt werden.

Die Zykluszeit betrgt typischerweise 1 Millisekunde. Verschiedene, hochdynami-sche Signale, wie z.B. die Ansteuerung der Hydraulikventile eines ESP-Systemswerden mit 0.25 Millisekunden oder schneller erfat.

Zum Einsatz kommen PowerPC-Prozessoren auf VMEbus-Platinen. Zur Signalerfassungund -ausgabe werden Industriestandard-Module eingesetzt auf Basis von Mezzanine-I/O-Modulen. Es handelt sich hierbei um Trgerplatinen mit einem VMEbus-Interface, auf diedie eigentlichen I/O-Module aufgesteckt werden. Die auf einem Simulator eingesetztenModule richten sich nach bentigter Signalanzahl, Signaltyp und den Anforderungen andie Signale. Gngige Signal- bzw. Modultypen sind

Analog Input (analog digital Wandlung A/D)

Digital Input


Analog Output (digital analog Wandlung D/A)

Digital Output

Signal-/Frequenzgenerator Output

CANbus [Law94][Ets00] Input/Output

Zur Signalerfassung ist teilweise zustzliche Elektronik erforderlich: Ein hochfrequentes,pulsweitenmoduliertes Signal (PWM) wird fr die anschlieende, niederfrequente Ana-log-Digital-Wandlung mit einem Analog-Input-Modul vorbereitet; die hohen Ansteuer-Strme eines elektrisch verstellbaren Fahrwerksdmpfers werden ber eine Strommess-brcke zugnglich gemacht; die ber Stromniveaus kodierten Drehzahl-Informationenaktiver Raddrehzahlsensoren werden von dem analogen Spannungssignal eines hochoh-migen Digital-Analog-Output-Moduls abgeleitet. Spezielle Ausgabesignale: Im BereichMotor, Kurbelwelle und Getriebe sind Signale hufig winkelsynchron und das Steuergerttriggert auf die Signalflanke. Die Signale intelligenter Raddrehzahlsensoren enthaltenzustzlich zum eigentlichen Rechteck-Drehzahl-Signal weitere kodierte Informationenfr Stillstand, Drehrichtung etc. Solche Signale mssen ber I/O-Module mit program-mierbarer Signalform realisiert werden. Entsprechend der Parametrie-Vorgabe werden dieSignale vom Modul autonom erzeugt.Der Simulationsrechner greift ber den VMEbus direkt auf die I/O-Module zu. Mit zustz-lichen PowerPC-CPUs lsst sich der Simulator problemlos aufrsten und an gesteigertenBedarf fr Rechenleistung anpassen. ber VMEbus werden hierzu weitere CPUs in denSimulator integriert und bernehmen Simulationsaufgaben oder auch die zeitintensiveSignalerfassung oder Signalausgabe.

Simulatorkopplung

Die Anforderungen an die Detaillierung der Simulationsmodelle oder die Komplexitt derzu regelnden Prfstandshardware machen bisweilen den Einsatz mehrerer, untereinandergekoppelter Simulatoren notwendig:

Simulation der Umfelderkennung und Objektverfolgung mittels eines Radarsensors(Abbildung 3.4.7),

Simulation der Verbrennungsvorgnge und Sensorsignale zum Test und zur Appli-kation von Motorsteuergerten,

Hydraulik-Aktuatoren zur Belastung eines als Hardware ausgefhrtes Lenksystems,

Simulationsmodelle, fr deren Echtzeit-Berechnung die Rechenleistung eines ein-zelnen Computers nicht ausreicht.

Die Realisierung der Kopplung richtet sich nach den Erfordernissen und den Gegeben-heiten. Die verfgbare Hardware, die Anforderungen an die Direktheit der Kopplung,


die auszutauschende Datenrate, die Geschwindigkeit und die Zuverlssigkeit sind Aus-wahlkriterien fr den Kopplungsmechanismus: Verwenden mehrere Simulatoren jeweilsRechner mit VMEbus-Interface, so knnen diese in einem gemeinsamen VMEbus-Rechner-Gehuse installiert werden und ber Shared-Memory-Bereiche auf dem VMEbusmiteinander kommunizieren. Aktion und Reaktion werden innerhalb weniger Millisekun-den ausgetauscht. Ebenfalls sehr enge Kopplungen lassen sich auf Basis einer CANbus-Verbindung oder ber Lichtwellenleiter realisieren. Eine kompatible Rechner-Hardwareist hierfr nicht erforderlich. Fr Kopplungen mit geringer Datenrate und relativ hoherZykluszeit lassen sich z.B. auch Ethernet-Netzwerk-Verbindungen einsetzen.

3.3 Funktionsmodule der Entwicklungsumgebung:Anpassung und Erweiterung

Die in den Fahrdynamikreglern und anderen Steuergerten implementierten Regelalgorith-men unterliegen der kontinuierlichen Weiterentwicklung und Verbesserung. Damit einhergehen auch Modifikationen in der angeschlossenen Sensorik und Aktuatorik: Sensorenfr bisher nicht detektierte Signale kommen hinzu, werden durch verbesserte ersetzt oderentfallen, da sich das Steuergert die notwendige Information auf anderem Wege beschafft.Die Ausgabesignale der Regler werden entsprechend der vernderten Anforderungen neudefiniert. Modifizierte oder neue Aktuatoren bieten verbesserte Eingriffsmglichkeiten.Speziell im Bereich der Vorentwicklung mechatronischer Systeme unterliegen deshalbauch die Entwicklungswerkzeuge einem kontinuierlichen Anpassungs- und Weiterent-wicklungsprozess. Die hierfr in der vorgestellten Entwicklungsplattform vorgesehenenSchnittstellen und Module sind Gegenstand dieses Abschnitts.

3.3.1 Protokollierung, Fehlerhandling

Wesentliche Bestandteile jeder Art von Steuergerteentwicklung sind Protokollierungund Dokumentation. Damit Entwicklungsschritte spter nachvollziehbar und Ergebnissekorrekt bewertbar sind, wird die Konfiguration der Testumgebung festgehalten, Art,Umfang und Anzahl der durchgefhrten Versuche, Versionsstnde von Regler-Softwareund Steuergerte-Hardware usw. Whrend der Tests selbst sind eingetretene Ereignissezu dokumentieren, wie z.B. vom Steuergert diagnostizierte Fehler, Signale auerhalbdes zulssigen Toleranzbandes oder auch dass alles korrekt ablief und keinerlei Auffl-ligkeiten festgestellt wurden. All diese Informationen mssen ohne manuelle Aktivierungautomatisch festgehalten werden. Jede manuelle Aktivierung wird im entscheidenden Fallpotentiell vergessen.Fr die Simulation bietet sich hierfr ein eigenstndiges Modul an. Es muss u.a. folgendeFunktionalitt und Eigenschaften besitzen:

Ausgabe aus dem Programm heraus: Unterschiedliche Arten von Ausgaben sind zuuntersttzen.

3.3. FUNKTIONSMODULE DER UMGEBUNG: ANPASSUNG UND ERWEITERUNG 23

Fehlermeldungen werden ausgegeben, wenn ein harter Fehler auftritt, d.h. einEreignis eintritt, bei dem die Fortsetzung des Tests nicht sinnvoll oder mglich ist.Die Simulationssteuerung leitet hierauf das Simulationsende ein oder bricht den Testals Notaus-Manahme unmittelbar ab.

Warnungen sind Hinweise auf besondere Ereignisse, die nicht unmittelbar undbeim ersten Auftreten zum Ende des Tests fhren sollen. Sie knnen auch alsweiche Fehler bezeichnet werden.

Meldungen sind textuelle Ausgaben, die z.B. dazu dienen, zu einem bestimmtenZeitpunkt die zurckgelegte Wegstrecke oder den notwendigen Bremsweg auszuge-ben.

Protokolldatei: Alle Ausgaben werden zustzlich zu den auf dem Bildschirmangezeigten Dialogen dauerhaft in einer Protokoll-Datei archiviert. Zur eindeutigenZuordnung wird automatisch der Beginn jedes Tests mit einem Weltzeit-Zeitstempelund jede Ausgabe whrend des Tests mit einem Zeitstempel bezogen auf Testbeginnversehen.

Einfach zu handhabende Anwenderschnittstelle: Nur wenn ein Modul einfach zunutzen ist, wird es konsequent eingesetzt.

Der Entwickler kann eine Meldung an beliebiger Stelle im Simulationsprogrammgenau dort erzeugen und ausgeben, wo es notwendig ist. Die Simulationsumge-bung prft an zentraler Stelle zu Beginn jedes Simulationszeitschrittes, ob in derZwischenzeit Fehler oder Warnungen aufgetreten sind. Gegebenenfalls leitet sie dasSimulationsende ein oder bricht die Simulation ab.

Portabel: Verfgbarkeit in den verschiedenen Simulationsumgebungen und Fachab-teilungen, von Software-in-the-Loop bis zum Hardware-in-the-Loop-Prfstand. DieAnpassungsarbeiten erfordern aufgrund der einfachen, ber nur wenige Funktionenrealisierten Schnittstelle nur geringen Aufwand. Meist ist nur das ffnen vonFehlerdialogen anzupassen.

Fehlerklasse, individuell erweiterbar: Auftretende Fehler lassen sich nach Zeitpunktund Stelle des Auftretens klassifizieren. Der Anwender muss die Liste bekannterFehler nach seinen Bedrfnissen einfach erweitern knnen.

Fehler bei der Initialisierung: Notwendige Parameter sind nicht angege-ben oder haben unzulssige Werte, Parameterstze sind nicht vorhanden,Prfstands-Hardware befindet sich nicht im geforderten Zustand, z.B. derDruckspeicher des Pneumatik-Zylinders zur Bettigung des Bremspedals lsstsich nicht befllen oder eine Versorgungsspannung fehlt.

Simulations-Fehler: Simulationsmodelle detektieren eine Situation, in der dieFortsetzung der Simulation nicht sinnvoll erscheint oder mglich ist: DasFahrzeug ist von der Strasse abgekommen, der Motor wurde abgewrgt unddas Fahrzeug steht.


Steuergertefehler: Ein Steuergert erkennt ganz allgemein auf Fehler odermeldet einen bestimmten Fehlercode, z.B. Drehzahlfhler vorne links aus-gefallen.

Allgemeiner Fehler: Diese Fehlerklasse wird verwendet, wenn ein Fehlerkeiner speziellen Klasse zugeordnet wurde.

Unterdrckung bzw. Verzgern von Reaktionen bei Auftreten von Fehlern: Zum Testder Diagnosefunktionalitt eines Steuergertes werden bewusst Fehler generiert, wiez.B. Sensorsignale verflscht oder unterdrckt. Erkennt das Steuergert einen extraherbeigefhrten Fehler nicht, ist dieses Nicht-Erkennen als Fehler festzuhalten.

Test der Abschaltstrategie und Rckfallebene: Wird untersucht, wie sich das Ge-samtsystem z.B. nach Ausfall eines Sensorsignals verhlt, darf dieses Ereigniss nichtmehr zum sofortigen Simulationsende fhren. Es muss aber dennoch protokolliertwerden. Hierfr ist die Mglichkeit vorgesehen, Fehler auf den Status einerWarnung zurckzustufen.

Untersuchung als sporadisch detektierter Fehler: Nur selten, scheinbar nicht repro-duzierbar auftretende, wieder verschwindende Fehler sind schwierig zu analysieren.Sie sind bei jedem Eintreten zu protokollieren. Der Test soll jedoch fortgesetzt wer-den. Erst bei berschreiten einer individuell festzulgenden Auftretens-Hufigkeitliefert ein Versuch keine zustzliche Aussage mehr und ist deshalb abzubrechen.ber die Angabe von Ereignisse pro Zeit kann der Anwender eine individuelleKonfiguration vornehmen.

Abspeichern im Fehlerfalle: Zur zeitversetzten Analyse automatisch ablaufenderVersuche ist es notwendig, bei Auftreten von Fehlern die Zeitverlufe der invol-vierten Gren abzuspeichern. Fr jede Fehlerklasse kann deshalb Abspeichernja/nein parametriert werden. Generell whrend aller Simulationen abzuspeichernist nicht frderlich: Die wenigen, relevanten Ergebnisse gehen in der hohen Zahlvon Datenstzen unter, es ist mit hohem Speicherbedarf verbunden und luft einerkonsequenten Archivierung und Backup-Strategie zuwider.

C-Code Interface

Das Modul zur Protokollierung und zum Fehlerhandling verfgt im wesentlichen berfolgende Schnittstelle: Jede Fehlerklasse (error class) wird eindeutig ber ihren Identgekennzeichnet.


KLNM,O,OEPQOSR%T%UV,V'WVXL!K

W!Y,Z![]\

M%R^!_W!YW!OU,Ta` bc KLedW!YWQOEU,TafU!ZT!g L!K

M%R^h-Yi-gj` kc KLji-Yi-gli!U,TEi'V!U!gli!PQYjfU!ZTQg L!K

M%R^,min[o` pc KLXV%in[ZT%UQgiQPQYjfUQZT!g L!K

M%R^'R!qrQT%WQslin[?Wa` tc KLjr-qrQT,W!glin[?WXWQurQW,W'v?i@Y%d L!K

w,w%w,w

xy

Initialisiert wird das Modul einmalig unter Angabe des Namens der Protokolldatei berden Aufruf der Funktion

z

P!d?h@Yli@g|{7rQP!Y?V@gr@}UQO~L

z

P!d%?iQT%WQEU@[?W?

w

Mit der Funktion

z

P!d'EW!fli-YW'M'O%OR%T%UV%V{

Z,YlV%i@d,YW'v MREhCvc

g

z

P!d,MR!r-gli!PQY r-giQPQYc

rQP!Y?V@gr@}UQO LCM,O,O%s,u,gc

rQP!Y?V@gi@Y,g m%UQEWCEP'vW?

knnen weitere Fehlerklassen erzeugt werden. ber weitere Argumente wird das Default-Verhalten dieser Fehlerklasse konfiguriert: '' legt fest, wie bei Auftreten dieserKlasse zu verfahren ist, ob es sich um eine Warnung handelt oder einen Fehler, bei dem derVersuch beendet, sofort oder verzgert abgebrochen oder ob der Fehler unterdrckt werdensoll. llElE ist der Text, der ausgegeben werden soll, falls bei Auftreten des Fehlerskeine Erluterung angegeben wurde. Der Parameter l% gibt an, ob Abspeichernvon Zeitverlufen aktiviert werden soll oder nicht.

Fehler, Warnungen und Meldungen werden aus dem Simulationsprogramm heraus berdie Funktionen

z

P!d,M,O,O {Z%Y?V%iCd'YEW!vM%REhCvcrQP!Y?VCg]r@}U!O~LQfP!O![?U!g;c

w,w%w

z

P!d!?UQO%Y%|{Z%Y?V%iCd'YEW!vM%REhCvcrQP!Y?VCg]r@}U!O~LQfP!O![?U!g;c

w,w%w

z

P!d {r!PQY?VCgr-}U!OoLQfP!O![?U!g;c

w,w%w

ausgegeben. Fehler und Warnungen sind jeweils einer Fehlerklasse , zugeordnet undknnen ber einen erluternden Text, der ber Formatstring und variable Argumentlisteindividuell ausgefhrt werden kann, verfgen.

Durch den Aufruf der Funktion

z

P!d%RT,PV!W{7

wird die Protokollierung beendet und die Protokolldatei geschlossen.


3.3.2 Client-Server-Kommunikation zur Steuerung und berwachungDie Simulationsumgebung ist realisiert als ein modulares Baukastensystem mit inClient-Server-Architektur verteilten Aufgaben. Einzelne Komponenten (Anwendungen,Programme) bieten Informationen, Funktionalitt oder allgemein Dienste an, sogenannteServer (deutsch: Diensteanbieter) oder Back-End-Komponenten. Ein Beispiel hierfr istein Simulationsprogramm, das ein virtuelles Fahrzeug bereitstellt, mit dem Fahrmanverdurchgefhrt werden knnen. Andere Komponenten, sogenannte Clients (deutsch: Kun-den) oder Front-Ends, greifen auf Server zurck. Dies ist z.B. eine Tachometeranzeige,die vom Simulations-Server die Information ber die aktuelle Fahrzeuggeschwindigkeitbezieht und sie auf dem Bildschirm anzeigt, oder ein Bedienknopf, ber den derAnwender einen Start-/Stop-Befehl an den Simulations-Server schickt. Die Verteilung

port xxxxx

port yyyy

port zzzz

Client 1Server ACommunicationRequest for Connection

Abbildung 3.3.1: Client-Server-Kommunikation

beschrnkt sich nicht auf verschiedene Anwendungsprogramme, sondern umfasst auch dieNutzung verteilter, z.B. ber Netzwerk, gekoppelter Hardware. Bei einem Hardware-in-the-Loop-Prfstand berechnet ein Echtzeitrechner die Simulationsmodelle und liest Input-Signale von und generiert Output-Signale fr die angekoppelten Hardware-Komponenten.Der Testingenieur steuert und berwacht den Prfstand von einem Bedienrechner mitAnzeigen, Eingabe-Oberflchen, Zeitverlufen und 3D-Animationen.Eine Client-Server-Architektur vermeidet die Konzentration der gesamten Funktionalittan einer Stelle. Unterschiedliche Aufgaben werden von verteilten, untereinander gekop-pelten Systemen wahrgenommen. Eine solche Systemarchitektur ist flexibel erweiterbarund durch neue Spezialkomponenten an besondere Anforderungen anpassbar. Existie-rende Komponenten mssen hierfr nicht modifiziert werden. Diese Vorteile gegenbereiner monolithischen Struktur sind mit zustzlichen Anforderungen an anderer Stelleverbunden: Die Kopplung verschiedener Teilsysteme wird lockerer. Ein Kommunika-tionsprotokoll wird nowendig. Ein Client muss einen Server suchen, finden und mitihm Kontakt aufnehmen knnen. Der Client muss Befehle an den Server senden undStatusinformationen vom Server empfangen. Bei der Kommunikation entstehen zwischen


Befehl und Antwort Verzgerungen.

Die Umgebung verfgt ber ein eigenes, von IPG Automotive GmbH entwickeltes undspeziell auf ihre Anforderungen zugeschnittenes Kommunikationsprotokoll. Entsprechen-de Bibliotheken stehen sowohl als C-Schnittstelle fr Anwendungsprogrammierung alsauch fr die bei der Testautomatisierung eingesetzte Scriptsprache zur Verfgung.

Jeder Server wird ber eine eindeutige Kennung, ber Bezeichnung und Klassifizierungder Anwendung (z.B. Steuergert 0815/HIL, Wankregler/SL, Fahrzeug abc/ESPxyz), den Rechnernamen und die Benutzer-Kennung, mit der der Server luft und weitereMerkmale identifiziert. Ein Client fragt nach einer Liste der vorhandenen Server an. Ausdieser Liste whlt er den passenden Server aus und nimmt Verbindung zu ihm auf. DieKommunikation zwischen Client und Server findet in zweierlei Modi statt:

1. Gesicherte Verbindung: Der Sender erhlt den Empfang seiner versandten Botschaftbesttigt bzw. er erfhrt, dass der Versuch ihrer Zustellung erfolglos war. DieserKommunikationsmodus wird fr Steuerbefehle und fr Anfrage-Antwort-Dialogeeingesetzt.

2. Ungesicherte Verbindung: Es ist fr den Sender nicht notwendig, dass alle versand-ten Botschaften beim Gegenber auch ankommen und empfangen werden. Fr denEmpfnger gilt im umgekehrten Sinne das Gleiche. Kurzzeitige Unterbrechungenoder Verluste, z.B. weil der Empfnger gerade mit anderen Aufgaben beschftigt ist,sind zulssig. Dieser Modus wird verwendet bei der kontinuierlichen bermittlungvon Zustandsvektoren an Anzeigen und Plott- oder Animationsprogramme.

ber Zugriffsbeschrnkungen und Zugriffsrechte wird sichergestellt, dass auf einen Servernur privilegierte Clients zugreifen knnen, um ihn zu berwachen und zu steuern.

Beispiel: Server-Anwendung (C-Code Interface)

Serverseitig initialisiert lQ!@ die Kommunikation.Signale werden per l'???@ bekanntgegeben. Ist der Server bereit,schliet '?l- die Vorbereitungsphase ab und gibt den Server fr Clients frei.Whrend der Simulation knnen Botschaften per l?%,- versendet werden. Ein-treffende Botschaften werden mit l,'E,- beschafft und ausgewertet. Die Kom-munikation mit den Clients und der ungesicherte Datenaustausch wird von l'??-abgewickelt.


KL,L%L%OW!UQOEUQgiQPQY]L'K

,PV%h@Yli-g|{Am%WQO%WQOR%T%UV,VcbcR!}EUQY,YEW,TQEUVCy

,PV@EWrQT%UQOEWQP!Z,ET,W{-nRUQO

w

UQuc([lKVQplcR%U!O

w

UQuy

,PV@EW,U!v,q{ny

KL,L%LaVi7[ZT,U!gli!PQYoT,P%PQ]L!K

}li!T,W{AmEi7[ZET,U!gli-Ydle\

KLV'UQEW!v]rQP!Y,YWEr-giQPQY]L'K

%PV'm,W!Y%v!VCd{

w,w%w

y

}liQT%W{,EPVCWr@'VCd{7r-}EUQY,YEW,Tc

w%w,w

`%`jb?e\

w,w%w

x

KLZ%Y?V'UQW'v]rQPQY%YWEr-gli!PQY]L!K

%PVQP%T,T{ny

x

KL,L%Lr!T,W%UQYXZ,cfli-Yi'V@}]L'K

,PVCM,uli-g{7y

Beispiel: Client-Anwendung (Tcl-Code Interface)

Verfgbare Server werden ermittelt, der passende ausgewhlt und die Verbindung mitihm aufgebaut. Der Client abonniert vom Server per ungesicherter Verbindung die inder %l?,!l' -Liste aufgefhrten Signale. Die Funktion % nimmt diehierfr eintreffenden Datenvektoren entgegen, wertet sie aus und weist sie an die Client-Datenstruktur zu. Fr den Datenkanal 2 wird die Auswertefunktion 'E,E%leingerichtet. Eine Nachricht wird mit dem gesicherten Befehl %, an den Serververschickt.

rQPQY%YWEr-g

UQEPr'ZEWQO,qk@b,b,b

m,W%T,WEr-gm%WQO%WQOU!PEraV'WQO%WQOlVC

vU!gU!,OPErQWV,VNv?i,r@gli!PQYU!O,qo,m%WQO%WQO

vU!gU!,OPErQWV,VV@Z,lV%r@Oli-EW ,m%WQO%WQOSbk-b%baUQYvT%WQU!gU!Wre,m!Z,lV%r-Oi-%gliQP!Y?V

vU!gU!,OPErQWV,Vg,OUErQWC[VCd ,m%WQO%WQOopWEr-,lVCd^'R'}UQY%YW%T,p

PQO%li@Y%d

vU!gU!,OPErQWV,VV!WQYvQ[VCdS,m%WQO,EWQOo'R'}U!Y,YW%T7Tlk@XPQY

rQT,W%UQYXZ,cf?i-Yi'VC}

vU!gU!,OPErQWV,VNvW,T%WQgEW%m,W!O,W!O


3.3.3 Modell-Management Varianten und AlternativenIm Zentrum der virtuellen Modelle der Simulationsumgebung steht das Fahrzeugmodell.Es bernimmt die Rolle einer integrativen Plattform, die entsprechend der Projektanforde-rungen angepasst und erweitert werden kann.Whrend des Entwicklungsprozesses wird das Wissen ber die einzelnen beteiligtenBaugruppen kontinuierlich immer weiter przisiert. Ein Parameter, der anfangs einerKonzeptstudie entstammt, wird spter aus Messungen an realen Prototypen oder ausdetaillierten FEM-Modellen gewonnen. Auch die Modellierung selbst wird entspechenddem aktuellen Wissensstand verfeinert werden. Vergleiche mit (einfacheren) Vorgn-germodellen dienen der Kontrolle und der Beurteilung mglicher Vernderungen imSystemverhalten.Die Variantenvielfalt moderner Fahrzeuge ist sehr hoch. Verschiedene Motorisierungen,Benzin- oder Dieselmotor, Handschalt- oder Automatikgetriebe, Sportfahrwerk mit ge-nderter Bremsanlage, Klimaanlage, Navigationssystem, um nur einige zu nennen, kannder Kufer whlen. Diese verschiedenen Konfigurationen mit der Simulation abdeckenzu knnen, erfordert ein ausgereiftes geeignetes Konzept. Fr jede Konfiguration eineigenes Simulationsprogramm aufzubauen ist keine befriedigende und praxistauglicheLsung. Gefragt ist die Mglichkeit, automatisiert, aus Versuchsreihen heraus, zwischenverschiedenen Modellkonfigurationen wechseln zu knnen. Diese Mglichkeit darf sichnicht nur auf die Standard-Modelle beschrnken. Sie muss auch fr die vom Anwenderselbst beigestellten Modelle verfgbar sein.Gerade im Bereich Hardware-in-the-Loop-Simulation steht immer nur eine beschrnkteRechenleistung zur Verfgung. Mit dieser mssen alle Modelle und anfallenden Aufgabenrealisiert werden. Zwischen detaillierteren Modellen im Fokus der aktuellen Fragestellungund vereinfachten an deren Peripherie wechseln zu knnen, stellt einen Ausweg ausdieser Situation dar. Beispiel: Das Hydraulik-Modell einer Bremsanlage mit Ventilen,Bremszylindern, Drcken und Volumenstrmen zum Betrieb eines ABS- oder ESP-Steuergertes; ein einfaches Modell zur Bremsmomentenverteilung abhngig von derBremspedalkraft im Zusammenhang mit einem Kurvenlicht-Regler.

Die Simulationsumgebung bietet fr diese Anforderung eigens ein Modul zum Modell-Management an, das folgende Standard-Submodell-Klassen des Fahrzeug-Kernmodellsverwaltet: Reifen, Fahrwerk, Lenksystem, Bremsanlage, Antriebsstrang, Motormodell,Kupplung, Getriebe, Triebstrang, incl. Differentialsperre und Hang-On-Kupplung, Aero-dynamik. Fr Details zu einzelnen Modellen sei auf Abschnitt 3.5 verwiesen.Unabhngig von seiner Modell-Klasse kann oder muss jedes Modell ber folgendeFunktionalitt verfgen:

Initialisierung: Beim Start einer Simulation wird eine Instanz des Modells erzeugt.Sie wird entsprechend des gewhlten Datensatzes parametriert und fr die eigentli-che Simulation vorbereitet.

Berechnung: Whrend der Zeitsimulation ruft das Modell seine Eingangsgren ab,fhrt die Berechnung durch und liefert seine Ausgangsgren zurck.


Freigabe: Nach der Simulation wird die eigens fr diese erzeugte Instanz und alledynamisch angeforderten Ressourcen, wie z.B. Hauptspeicher, wieder freigegeben.

Signale zur Beobachtung: Ein Modell kann eigene Signale in das Signal-Verzeichniseintragen und so dem Anwender Einblick in interne, modellspezifische Grenbieten (siehe Abschnitt 3.4.1).

Registrierung: Damit die Simulationsumgebung ein Modell kennt, muss es be-kannt gemacht worden sein. Zusammen mit einer eindeutigen Kennung, ber diedas Modell vom Anwender spter angesprochen wird, werden obige Schnittstellen-funktionen an das Modell-Management-Modul bergeben.

Durch das Modell-Management-Modul knnen im Simulationsprogramm beliebig vieleModelle einer Modell-Klasse parallel vorgehalten werden. Der Anwender spezifiziert dasModell, das er bei einer Simulation verwenden mchte, einfach ber die Angabe dessenKennung im Parameterfile. Das Modell-Management whlt ber diese Kennung und dieModell-Klasse das zugehrige Modell aus und aktiviert dessen Initialisierung, Signal-Deklaration, Berechnung und abschlieend wieder dessen Freigabe.Das Modell-Management-Modul bietet groe Flexibilitt. Dadurch, dass die an zentralerStelle gepflegte und weiterentwickelte Standard-Bibliothek fr den Kern der Fahrzeug-Plattform in allen Anwendungen zum Einsatz kommt, steigt deren Qualitt und Zuverls-sigkeit. Weiterentwicklungen stehen automatisch allen Anwendern zur Verfgung.Das Modell-Management ist Bestandteil des Fahrzeugmodells. Sein Einsatz zum Aus-tausch des Fahrzeugmodells selbst ist nicht vorgesehen. Die Berhrpunkte mit derrestlichen Simulationsumgebung sind zu umfangreich, als dass ein Umschalten auf einanderes Fahrzeugmodell mit vertretbarem Aufwand realisierbar wre.

3.3.4 Einbinden von Modellen als Simulink S-Function

Matlab/Simulink ist vor allem im Umfeld der Reglerentwicklung eine weit verbreiteteEntwicklungsumgebung. Simulationsmodelle knnen direkt im Simulink-Blockschalt-bild aufgebaut werden. Im Rahmen des Concurrent Engineering werden hufig Ent-wicklungsstnde abgeglichen und notwendige Simulationsmodelle unter den beteiligtenEntwicklungspartnern ausgetauscht. Hierfr werden Modelle als ganzes oder einzelneFunktionsblcke aus der eigenen Simulationsumgebung herausgelst und versehen mitgeeigneten Schnittstellen fr eine andere Umgebung exportiert. Dies geschieht durchden direkten Austausch des Simulink-Modellblocks, dem Quellcode des Modells. Seineinterne Struktur, seine Implementierung und Parametrierung ist in diesem Fall offengelegt.Ist der damit verbundene Know-How-Transfer nicht erwnscht, erfolgt der Export alsBlack-Box-Funktionsmodul in Form einer Simulink-Funktion oder S-Function. EineS-Function kann in zwei Arten vorliegen:

binre, ausfhrbare Modellbibliothek (DLL): Das Modell lsst sich direkt als S-Function-Block in ein Simulink-Modell einbinden.

3.4. FUNKTIONSMODULE DER UMGEBUNG: DURCHFHRUNG VON TESTS 31

ber den RealTimeWorkshop als C-Quellcode exportiert: Diese Form des Modell-austauschs wird gewhlt, wenn es sich bei der Ziel-Umgebung um eine von dereigenen abweichende Umgebung handelt. Ein anderes Betriebssystem oder eineProzessor-Architektur mit unterschiedlichem Binrformat machen eine spezielleEntwicklungsumgebung notwendig. Meist steht sie und entsprechendes Know-Hownur auf Seiten des Modell-Imports zur Verfgung. Der Weg ber C-Quellcodeermglicht es dem Importierenden Parameter, wie z.B. die Compiler-Einstellungen,selbst zu whlen. Ein typisches Beispiel hierfr ist der Modellexport von einemWindows-PC fr einen mit dem Betriebssystem LynxOS laufenden Echtzeit-Rech-ner eines Hardware-in-the-Loop-Simulators.

ber bei IPG Automotive GmbH entwickelte speziell auf die Entwicklungsumgebungzugeschnittene Export-Targets gestaltet sich der Modell-Import in diese Umgebungbesonders einfach: Die Initialisierungs-, Berechnungs- und Freigabe-Funktionen werdenautomatisch mit den passenden Schnittstellen und Verhalten erzeugt. Die SimulinkBlock-Library wurde um Funktions-Blcke erweitert. ber sie wird im Simulink-Modellder Zugriff auf Funktionalitt der Entwicklungsumgebung ermglicht. Z.B. messenKinematik-Sensor-Blcke im Fahrzeug fr beliebige Punkte Position, Gechwindigkeit undBeschleunigung. Mit sog. Dictionary-Blcken werden Simulink-Signale in das Signal-Verzeichnis eingetragen (siehe Abschnitt 3.4.1) und damit fr das Abspeicher-Modul(siehe Abschnitt 3.4.2) und das Manipulationsmodul (siehe Abschnitt 3.4.3) zugnglichgemacht. ber spezielle Read/Write-Blcke ist der lesende und schreibende Zugriff direktauf Variablen der Umgebung realisiert.

3.4 Funktionsmodule der Entwicklungsumgebung: Durch-fhrung von Tests

3.4.1 Signal-/Gren-Verzeichnis

Fr den interaktiven oder den automatisierten Simulationsbetrieb ist es wichtig, dasSimulationsgeschehen online berwachen zu knnen. Online meint in diesem Zu-sammenhang schon whrend der laufenden Simulation die Zeitverlufe reprsentativerGren zu verfolgen, anstatt sich nach Simulationsende abgespeicherte Ergebnisdatenanzusehen.Die vorliegende Simulationsumgebung ist komplex und verfgt aus ihren verschiedenenTeilmodellen und Steuergerten ber sehr viele hufig sind es mehrere hundert Signale.Von Anwendung zu Anwendung oder abhngig von der aktuellen Konfiguration derSimulationsumgebung stehen unterschiedliche Signale zur Verfgung.Damit auf die Signale zugegriffen werden kann, werden sie in einem zentralen Verzeichniszusammengefasst und verwaltet. In Abbildung 3.4.1 sind einige Eintrge in einem solchenVerzeichnis beispielhaft wiedergegeben. Jedes Modell trgt dort bei der Initialisierung dievon ihm bereitgestellten Signale mit folgenden Angaben ein:


'[iQWQY%g

w

li-O'OEWV,VCZ,OEW U!O vP!Z,ET,W b b b!uk@U%U?k-b%

'[iQWQY%g

w

sW@[W!OUQg%Z,OEW vP!Z,ET,W b b b!uk@U%U'b'f

OU!W

w

,W!vU%T vP!Z,ET,W b b b!up?k-f,,%

OU!W

w

'ER U!O vP!Z,ET,W b b b!up?k-f,W,

OU!W

w

'

^!

z

U!O vP!Z,ET,W b b b!up?k-f,,fb

RUQO

w

min[,}UV'W T,P!Y%d k@p b b!up,p,t%W!%

RUQO

w

U

OU'v fT%P,U!g b b b!up,p,t'fp,b

RUQO

w

U

EUQgW OU'vKV fT%P,U!g b b b!up,p,t'fp'

RUQO

w

U

r,r OU'vKV%Qp fT%P,U!g b b b!up,p,t'fp,

RUQO

w

U,T!P!Oli [?KV%!p fT%P,U!g b b b!up,p,t'f%b?r

RUQO

w

UQg%P!Oli [?KV%!p fT%P,U!g b b b!up,p,t'f%b%

RUQO

w

[?KV fT%P,U!g b b b!up,p,t'f%b%b

,

w

_UV fT%P,U!g b b b!up,p,'f?r%r

,

w

_W,U!O,EP T,P!Y%d b b b!up,p,'fW,

,s

w

M'Y%dli-YEW

w

OEPQg% OU'vKV vP!Z,ET,W b b b!up,p',W,

m,R

w

mQgU!gW T,P!Y%d kn b b!up,p%,rQb

m!gW%WQO

w

%}ETQ,Yd OU'v vP!Z,ET,W b b b!up,p'p'b,

m!gW%WQO

w

%}ETQs,O ![ vP!Z,ET,W b b b!up,p'p?k'r

%}lr!T

w

VCP%U!v [ vP!Z,ET,W b b b!up,p%,,p,b

Abbildung 3.4.1: Ausschnitt aus dem Signal-/Gren-Verzeichnis eines Simulationspro-gramms. Dargestellt sind Name, Einheit, Gre in Byte und Typ, Anzahl mglicherZustnde, Speicheradresse etc.

Name: Eine sprechende, lesbare Bezeichnung, ber die der Anwender auf das Signalzugreift. Dieser Realisierung wurde der Vorzug gegenber fehlertrchtigen und inder Handhabung unkomfortablen Indices innerhalb einer Tabelle gegeben.

Einheit: Der Zahlenwert bezieht sich auf diese Einheit. Fast alle Signale liegenprogrammintern in SI-Einheiten vor.

Datentyp: Die einem Signal zugehrige Variable hat einen bestimmten, vomModellentwickler gewhlten, Datentyp. Z.B. wird fr die Gangnummer ein Integerverwendet und fr die Gangbersetzung ein Float oder Double. Damit die Signalekorrekt interpretiert und bertragen werden knnen, muss ihr Datentyp bekannt sein.

Adresse: Adresse im Hauptspeicher des Computers, an der die Variable liegt undvon der ihr Wert gelesen werden kann.

Zustzliche Angaben: Anzahl mglicher Zustnde bei zhlbaren Gren, Monoto-nitt, u.a.

Eine Client-Anwendung, z.B. ein Programm zur Darstellung von Zeitverlufen, kannsich jetzt ber Netzwerk mit dem Simulations-Server verbinden (siehe Abschnitt 3.3.2)und eine Liste aller aktuell verfgbaren Signale anfordern. Der Simulations-Ingenieur


whlt sich dann aus dieser bersicht die Signale aus, die fr ihn bei der aktuellenSimulation von Interesse sind. Steht in der aktuellen Versuchskonfiguration ein Signalgerade nicht zur Verfgung, kann meist auf eine hnliche Gre ausgewichen werden. Beider Testautomatisierung werden alternative Signale angegeben. Nur wenn auch diese nichtverfgbar sind, wird eine Fehlermeldung ausgelst.Vom Simulations-Server zum verbundenen Client werden nur die ausgewhlten Grenbertragen. Hierdurch wird die verfgbare Rechenleistung und die bertragungskapazittder Netzwerkverbindung effektiv genutzt.Das Signal-Verzeichnis schafft die Voraussetzung zu weiterer Funktionalitt, wie demAbspeichern (siehe Abschnitt 3.4.2) oder dem Manipulieren von Signalen (siehe Abschnitt3.4.3).

3.4.2 Aufzeichnen von Signalen

Beim Versuchs- und Simulationsbetrieb besitzt das Aufzeichnen und Abspeichern vonSignalen und der Vergleich zweier oder mehrerer Tests einen groen Stellenwert. Zeitver-lufe von Signalen werden deshalb zur spteren detaillierten Analyse, Weiterverarbeitungund Archivierung festgehalten.Im Gegensatz zur Messung im Fahrversuch stehen bei Simulationsmodellen sehr vieleSignale meist automatisch zur Verfgung, ohne dass aufwndige Messtechnik installiertund kalibriert werden muss. Das Erfassen und Abspeichern von Signalen verbrauchtwhrend der Simulation Rechenzeit und anschlieend Speicherkapazitt auf der Festplatte.Die Aufgabe lautet hier deshalb, aus der Vielzahl zur Verfgung stehender Signalediejenigen auszuwhlen, die fr den aktuellen Arbeitsschwerpunkt relevant und notwendigsind. Hierfr wurde ein leistungsfhiges Konzept in Form eines Aufzeichnungs-Modulsrealisiert.Vor Beginn eines Versuchs konfiguriert der Anwender das Aufzeichnungs-Modul. Dieaufzuzeichnenden Signale werden ber ihren Namen spezifiziert. Zusammenstellungenvon Namen lassen sich in Datenbasen ablegen und referenzieren. So knnen z.B. frjeden Arbeitsschwerpunkt einheitlich die gleichen Signale erfasst werden. Die Datenratewird festgelegt, d.h. mit welcher Zeitschrittweite bzw. jeden wievielten Simulationszyklusein Datenvektor aufzuzeichnen ist. ber das Signal-Verzeichniss (siehe Abschnitt 3.4.1)gelangt das Aufzeichnungsmodul an die einzelnen Variablen und ihre Werte.Das Abspeichern ber Netzwerk auf eine Festplatte ist nicht echtzeitfhig. Fr Hardware-in-the-Loop-Anwendungen muss jedoch Echtzeitfhigkeit garantiert werden. Deshalbwerden in der Echtzeitanwendung die Datenvektoren in einen mehrere Megabyte groenPuffer im Hauptspeicher des Simulationsrechners geschrieben. Ein zweiter Prozess oderThread bernimmt die Daten aus dem Puffer und wickelt unter Nicht-Echtzeit-Bedingun-gen, mit niedrigerer Prioritt als der eigentliche Simulationsprozess, das bertragen undAbspeichern der Daten ab.Von Beginn bis zum Simulationsende alles abszupeichern ist auch ohne einen Datenpuffermglich. Mit Hilfe des Datenpuffers sind zustzliche, sehr ntzliche Abspeicher-Modirealisiert: Rckwirkendes Abspeichern zuvor gepufferter Datenvektoren. Whrend der


Simulation werden die Datenvektoren nur gepuffert. Der Anwender sendet von einerBedienoberflche aus per Client-Server-Kommunikation (siehe Abschnitt 3.3.2) denBefehl, mit dem Abspeichern zu beginnen. Es kann entweder die verfgbare Historiekomplett oder anteilig mit ausgegeben werden. ber Ereignisse (siehe Abschnitt 3.3.1)getriggertes Abspeichern incl. eines Zeitabschnitts vor Auftreten des Ereignisses istmglich.Die Ergebnisdatenstze tragen automatisiert den Namen des Versuchs, bei dem sie aufge-zeichnet werden. Durch Datum und Uhrzeit des Versuchsbeginns und einer fortlaufendenNummer fr jedes Abspeichern innerhalb des Versuchs sind sie eindeutig bezeichnet.Die Aufzeichnung selbst erfolgt in einem kompakten Binrformat. Importfilter fr denMatlab-Workspace, fr Excel und IPG-CONTROL sind verfgbar. Importiert werden dieNamen der Signale, ihre Einheit und die Anzahl ihrerer Zustnde. Andere Postprocessing-Werkzeuge werden ber einen Exportfilter fr ein ASCII-Tabellenformat untersttzt.

3.4.3 Manipulation von Simulations-Gren und elektrischen Signa-len

Die virtuellen Modelle werden durch Eingriffe eines Fahrers oder andere Eingriffebedient. Hierfr werden blicherweise vorab Versuche definiert, die anschlieend von dervirtuellen Umgebung geladen und durchgefhrt werden. Dem gegenber steht eine inter-aktive Bedienung oder eine Bedienung aus der Testautomatisierung heraus whrend eineslaufenden Versuchs. Das Simulationsgeschehen wird beobachtet und zum gewnschtenZeitpunkt oder Zustand eines Modells wird in das Simulationsgeschehen eingegriffen.Hierbei handelt es sich z.B. darum, das Gaspedal voll durchzutreten, das Lenkradloszulassen oder die Fahrwerksabstimmung von Sport auf Komfort umzustellen. Einzweites, fr die Reglerentwicklung besonders wichtiges Aufgabenfeld ist die Manipulationvon Sensor-Signalen. Signale knnen durch Wackelkontakt oder Leitungsbruch gestrtwerden. Sie knnen wegdriften oder ein Sensor kann seine Empfindlichkeit ndern.Zur softwaretechnischen Manipulation von Signalen wurde ein DirectVariableAccessModul (DVA) realisiert. Es bietet folgende Mglichkeiten:

Zugriff auf Signale ber ihren Namen, realisiert ber das Signal-Verzeichnis (sieheAbschnitt 3.4.1)

Manipulation der Signale an verschiedenen vordefinierten Positionen innerhalbeines Simulations-Schrittes: Nach Einlesen von Input-Signalen, nach der Manver-steuerung und dem Fahrermodul, nach Berechnung des Fahrzeugmodells, vor derAusgabe der Signale an die Steuergerte, u.a.

Zeitdauer der Manipulation: fr eine bestimmte Zeitdauer oder unbegrenzt

Arten der Manipulation: absoluter Wert oder relativer Offset, Skalierungsfaktor,konstante oder anwachsende Manipulation

Freigabe aller aktiven Manipulationen


Client-Anwendung knnen per Online-Kommunikation (siehe Abschnitt 3.3.2) diese Ab-fragen und Manipulationen vornehmen. Dies sind z.B. eine Bedienoberflche mit Tasternoder die Testautomatisierung. In der Manversteuerung stehen sie als Erweiterung derFunktionalitt der Mini-Manver (siehe Abschnitt 3.4.6) zur Verfgung. Darber hinausstellt dieses Modul ein gutes Werkzeug bei der Modellentwicklung und Inbetriebnahmevon Prfstnden dar. Mit ihm lassen sich einfach gewnschte Konstellationen von Signalensetzen, wie es z.B. zur Kalibrierung von Sensorsignalen fr ein Steuergert hilfreich ist.

Abbildung 3.4.2: FailSafeTester zur elektrischen Manipulation von Signalen. Ausfhrungmit vertieftem Einbau oder normal, verschiedene Einsteckkarten (Quelle: IPG AutomotiveGmbH)


Zur elektrischen Manipulation von Signalen auf Hardware-in-the-Loop-Prfstnden wur-de der von IPG Automotive GmbH entwickelte FailSafeTester in die Simulationsumge-bung mit integriert[WH03]. Er kann mit unterschiedlichen Karten bestckt werden (sieheAbbildung 3.4.2):

Standard- oder Hochstrom-Relais-Karten zur Erzeugung von Leitungsbrchen durchTrennen oder elektrischen Kurzschlssen durch untereinander Verschalten vonSignalen

Widerstandskarten zur Simulation von Leitungs-Alterung und Korrosion von Kon-takten durch Einbauen von programmierbaren Widerstnden in einzelne Leitungs-strnge

Wackelkontakt-Karten zur hochfrequenten Unterbrechung von Signalen

Der FailSafeTester ist ber CAN-Bus an den Hardware-in-the-Loop-Simulator ange-schlossen. Bedient werden kann er entweder interaktiv ber eine eigene Bedienoberflche,ber Befehle aus den Manvern eines Versuches oder ber die Testautomatisierung perKommunikations-Botschaften.

3.4.4 DatenmanagementFr alle Bereiche der Simulation Modelle, Simulationsumgebung, Visualisierung sind Daten notwendig. Sie besitzen eine hierachische Struktur, bei der ein Datensatzauf Subdatenstze zurckgreift. Die einzelnen Datenstze haben unterschiedliche Formateund Umfnge. Beispiele: Ein Fahrzeug-Modell erfordert Angaben zu Geometrie, Massenund Trgheiten, Steifigkeitskennlinien, Reibwerte, Zeitverhalten, Hydraulik, Gangberset-zung; eine Simulationsumgebung muss konfiguriert und Signale konditioniert werden; frdie Visualisierung sind 3D Grafikmodelle notwendig. Fr den Anwender ist es wichtig,die fr ihn relevanten Daten und Informationen einfach aufzufinden und zu verwalten. DerDatenaustausch zwischen verschiedenen Rechner- und Betriebssystemplattformen mussvor allem vor dem Hintergrund der Hardware-in-the-Loop-Simulation und der abteilungs-und firmenbergreifenden Entwicklungsprozesse mglich sein. Ein einheitliches, platt-formbergreifendes Datenformat ist erforderlich.Fr das Datenmanagement ist eine ber Verzeichnisse und Dateien realisierte Datenbankimplementiert. Die Daten selbst werden in einem lesbaren ASCII-Dateifromat abgelegt.Untersttzt werden die Datentypen Double, Long, String und Text. Kennlinien undKennfelder werden mit den Typen String oder Text abgespeichert. Das Dateiformat istplattformunabhngig. Eine Kontrolle der Datenbestnde mit einem normalen Texteditorist mglich. Die Datenstze knnen flexibel aufgebaut sein, da schlsselwortorientiertzugegriffen wird. Die hierachische Strukturierung der Daten kann ber ebenenbildendePunkte im Schlsselnamen erfolgen analog zu Strukturen in der ProgrammierspracheC. Durch die Verwendung eines einheitlichen Formates fr alle Datenstze, kombiniertmit dem schlsselwortorientierten Zugriff und der Definition von Standard-Schlsseln zurKennzeichnung und Beschreibung eines Datensatzes, knnen dem Anwender einheitliche


Dialoge zur Suche und Auswahl der Datenstze angeboten werden. Schnittstellen zumlesenden und schreibenden Zugriff auf die Datenbank stehen fr Bedienoberflchen,fr Anwendungsprogramme und fr die Testautomatisierung zur Verfgung. In derBedienoberflche wurden hiermit Importfunktionen realisiert, z.B. fr die Minimanver,die Fahrercharakterisierung, die Fahrbahn etc.

Modellparameter Zur Organisation der Daten wurde ein kombinierter Ansatz gewhlt.Die einzelnen Modelle werden modulbasiert, d.h. an Bauteilen oder Baugruppen undfunktionalen Einheiten orientiert parametriert. Dies ermglicht es, sehr viele Daten ausbereits vorhandenen Bauteil-Datenbanken direkt zu bernehmen. Aus den einzelnenModulen werden anwendungsorientierte Einheiten gebildet. So werden z.B. die Datenzur Fahrzeug-Geometrie und Massenverteilung, zum Lenksystem, zum Antriebsstrangetc. in einem Fahrzeugdatensatz abgelegt. Nachteilig ist hierbei eine Redu

Documents

Closed Loop Entwicklungsplattform