Modellbildung und Testautomatisierung für die Hardware-in-the ...

Modellbildung und Testautomatisierung für die Hardware-in-the-Loop
Simulation
Dr.-Ing. Clemens Gühmann, IAV GmbH
Abstract. Im Software-Entwicklungsprozess werden heutzutage verstärkt die Methoden
Model-in-the-Loop (MiL), Software-in-the-Loop (SiL) und Hardware-in-the-Loop (HiL) Simulation
eingesetzt. Die Einsatzmöglichkeit der Simulation ist nur dann gegeben, wenn die
verwendeten Simulationsmodelle den geforderten Detaillierungsgrad besitzen und vor allem
rechtzeitig d.h. spätestens zum Beginn der entsprechenden Entwicklungsprozessphasen
(z.B. Softwaretestphase) vorliegen. Für die HiL Simulation wird die Gewinnung
echtzeitfähiger Modelle für die Fahrzeuglängsdyamik (Getriebe und Motor) dargestellt.
Die Vorteile der Simulation kommen jedoch erst dann zum Tragen, wenn die Tests automatisiert
durchgeführt werden können. Neben der Beschleunigung des Entwicklungsprozesses
werden Tests im Steuergeräteverbund beherrschbar und die Fehlerquote gesenkt.
Es wird ein durchgängiger, automatisierter Testprozess für die HiL Simulation beschrieben.
Mit Hilfe der Unified Modelling Language (UML) wird die Spezifikation für das gesamte
Testsystem erstellt. Als Anwendungsbeispiel wird ein HiL System der IAV GmbH zum Test
von Getriebesteuerungen für Stufenautomaten vorgestellt.
1 Einführung
Bedingt durch die steigenden Forderungen des Gesetzgebers sowie durch die hohen Erwartungen
der Kunden bezüglich Fahrkomfort, Leistung und Sicherheit nimmt die Komplexität
des Antriebsstrangs moderner Kraftfahrzeuge rasant zu. Die geltenden und zukünftigen
Umwelt-Gesetzgebungen können unter anderem nur durch moderne Motoren mit einer Vielzahl
steuerbarer Komponenten, wie z. B. einer variablen Nockenwellenverstellung oder der
Verwendung moderner Getriebesysteme erreicht werden. Die Anforderungen an moderne
Kraftfahrzeuge können darüber hinaus nur durch eine Vernetzung der Steuergeräte bzw.
durch die Ausführung der über diese Steuergeräte verteilten Funktionen erfüllt werden.
Zur Beherrschung der dadurch gestiegenen Komplexität der Steuergerätesoftware – verbunden
mit kürzer werdenden Entwicklungszyklen – ist die Anwendung neuer Methoden bei der
Entwicklung und Bedatung der Software notwendig. Aufgrund des zunehmenden Kostendrucks
darf der hierfür erforderliche Aufwand nicht erhöht werden. In Abkehr von der früher
ausschließlich eingesetzten Entwicklung und Prüfung im Fahrversuch wird heutzutage verstärkt
die Simulation im Software- und Funktionsentwicklungsprozess eingesetzt.
Die zunehmenden qualitativen und quantitativen Vorgaben im Steuergerätetest können nur
durch einen optimierten Testprozess erreicht werden. Ein Mittel zur Optimierung des Testprozesses
bezüglich der Prüftiefe und des Aufwandes stellt der automatisierte Test in der
Hardware-in-the-Loop Simulation dar. Die Prüftiefe der Tests hängt dabei stark von dem
Detaillierungsgrad und der Verfügbarkeit der echtzeitfähigen Simulationsmodelle ab.
Seite 1

2 Simulation im Software- und Funktionsentwicklungsprozess
Der Einsatz der Simulation lässt sich anhand des sogenannten V-Modells darstellen. In Abhängigkeit
des Entwicklungsschrittes kommen verschiedene Simulationsarten zum Tragen.
Ausgangspunkt der Softwareentwicklung sind die Anforderungen des Kunden, die zum Beginn
der Softwareentwicklung in Form eines Lastenheftes vorliegen (Bild 1). Nach der
Systemspezifikation erfolgt die Funktionsspezifikation, die durch die Model-in-the-Loop Simulation
unterstützt werden kann (MiL 1). Bei der Model-in-the-Loop Simulation werden
sowohl die zu spezifizierenden Funktionen als auch das Fahrzeug auf einem PC/einer Workstation
simuliert. Die Funktionen werden dabei als Softwaremodell in grafisch orientierten
Programmiersystemen wie MATLAB ® /Simulink ® entwickelt. Es werden die Funktionen im
Detail entworfen und festgelegt. Als Ergebnis liegt ein elektronisches, ausführbares Lastenheft
vor.
Seite 2
1
2
Anforderung
Systemspezifikation
Funktionsspezifikation
Model-in-the-Loop Simulation
Fahrzeugmodell
Rapid-Prototyping
Regelstrecke
im Fahrzeug
Programmentwurf
Softwarentwicklungsprozess
Modell der
Software
5
1
Modulentwurf
Modell der
Software
PC
Steuer-
Bypass- gerät
Rechner
Kunde
Rapid-Prototyping
2
Codierung
3
4
Offline-Simulation
Bild 1: Software- und Funktionsentwicklungsprozess
Modultest
Fahrzeugmodell
Kennfeldoptimierung
Stellgrößen, z.B. Zündwinkel PC
3
4
4
Integrationstest
Software-in-the-Loop Simulation
Fahrzeugmodell
Hardware-in-the-Loop Simulation
Fahrzeugmodell
4
DSP
4 5 Applikation
Systemtest
Funktionstest
Software
Seriencode
PC
Steuergerät
Steuergerät
Anschließend können die Softwaremodelle der Funktionen mit entsprechenden Soft- und
Hardwaretools auf einem Bypassrechner im Fahrzeug direkt getestet und optimiert werden
(Rapid-Prototyping 2). Mit Hilfe der Model-in-the-Loop Simulation und des Rapid-Prototyping
lassen sich in einer frühen Phase Spezifikationsfehler auffinden und beseitigen.
Das Softwaredesign und die Codierung für das Zielsystem, d. h. die Umsetzung der Funktionen
in eine serientaugliche Software schließen sich in den Prozessschritten Programm-

entwurf, Modulentwurf und Codierung an. Diese Schritte werden durch statische Analysen
(Reviews) begleitet.
Der folgende Modultest, beim dem das Moduldesign überprüft werden soll, kann durch die
Software-in-the-Loop Simulation (SiL3) unterstützt werden. Hierbei wird das zuvor in der
Model-in-the-Loop Simulation verwendete Softwaremodell durch den späteren Seriencode
ersetzt und in die Simulation eingebunden.
Beim anschließenden Integrationstest, der das Ziel besitzt, das ausführbare Programm im
Zusammenspiel mit dem Betriebssystem und den verwendeten Hardwarekomponenten zu
prüfen, wird der Softwareingenieur durch einen Hardware-in-the-Loop-Simulator (HiL 4) unterstützt.
Auch die sich nun anschließenden Funktions- und Systemtests sind ohne den Einsatz
eines Hardware-in-the-Loop Simulators in der geforderten Prüftiefe nicht mehr zu bewältigen.
Bei der Bedatung der Kennfelder und Kennlinien wird in der Applikation verstärkt
die Offlinesimulation 5 eingesetzt [3], bei der die Optimierung der Kennfelder vorgenommen
wird. Die Applikation an einem HiL Simulationssystem ist in Einzelfällen auch durchführbar.
Anhand des durchgängigen Einsatzes der Simulation in der Funktions- und Softwareentwicklung
wird die zunehmende Bedeutung der Testautomatisierung und der Verfügbarkeit
echtzeitfähiger Simulationsmodelle deutlich.
3 Gewinnung echtzeitfähiger Modelle für die HiL Simulation
Durch die Forderung, die HiL Simulatoren sollten ca. um den Faktor 10 schneller sein als die
zu testenden Steuergeräte, ergeben sich bei den Taktzeiten moderner Steuergeräte des
Antriebsstrangs von unter 10 ms Simulationsschrittweiten von ca. 500 µs. Die zu implementierenden
Modelle müssen daher so einfach wie möglich in ihrer mathematischen Beschreibung
sein und dennoch das dynamische Verhalten des Fahrzeuges unter Einbeziehung aller
Steuergrößen abbilden.
In der HiL Simulation werden zu meist kombinierte Modellstrukturen verwendet. Eine physikalische
Grundstruktur wird durch die Einbindung phänomenologischer Beschreibungsmodelle
ergänzt. Die Methoden zur Modellierung werden im folgenden anhand der in der IAV
GmbH entwickelten Modellbibliothek VeLoDyn zum HiL-Getriebesteuergerätetest verdeutlicht.
Ein komplettes Modell für den Getriebesteuergerätetest enthält neben der reinen Längsdynamiksimulation
insbesondere für die automatisierte Testdurchführung ein Fahrermodell,
die Berücksichtigung unterschiedlicher Strecken und Umweltbedingungen sowie die Möglichkeiten,
Fehler (z. B. Getriebefehler) zu simulieren.
Das Simulink ® -Gesamtmodell gliedert sich in zwei Teilsysteme, das Subsystem Getriebe-
Steuergeraet und das Subsystem Fahrzeug und Umgebung (Bild 2). Das Subsystem Getriebe-Steuergeraet
stellt die Anbindung des Modells an das Steuergerät her. Es enthält Module,
über die Aktuatorenansteuerungen ins Modell eingelesen werden können, z. B. Dutycycle
für Lastventile. Zudem werden hier die Sensorsignale wie z. B. Drehzahlsignale generiert.
Das Subsystem Fahrzeug und Umgebung enthält das eigentliche Fahrzeuglängsdynamikmodell
und darüber hinaus Module, über die die Fahrereingaben eingespeist werden.
Es untergliedert sich in zwei weitere Teilsysteme.
Seite 3

Über das Modul Bedienung und Umgebung wird das Fahrzeug gesteuert. Es wird hier die
Automatisierungsschnittstelle zur Verfügung gestellt, über die sowohl Pedalwertgeber
(PWG), Bremse, Wahlhebel, Zündung, Anlasserwunsch als auch Umgebungsbedingungen
wie Gegenwind und Steigung dem Modell vorgegeben werden. Zudem besteht die Möglichkeit,
diese Vorgaben über verschiedene Automaten zu deaktivieren. Es können im Fahrzeug
gemessene Profile anhand von PWG-, Brems- und Geschwindigkeitsvorgaben nachgefahren
werden. Des Weiteren ist ein Fahrautomat (Bild 3) integriert.
Seite 4
In1 Out1
Fahrzeug und Umgebung
Out1
Bild 2: Das VeLoDyn Simulink ® -Fahrzeugmodell
In1
Getriebe-Steuergeraet
1
In1
Bus_Input
Bus_Umgebung
Bus_Fahrzeug
Fahrzeug-Laengsdynamik
Bus_Fahrzeug
Bus_Umgebung
Bus_Input
Bedienung und Umgebung
Dieser generiert aus einer Geschwindigkeitsvorgabe eine Anforderung für PWG und Bremse.
So lässt sich nicht nur ein definierter Fahrzustand herstellen, es können auch verschiedene
Geschwindigkeitszyklen, wie z. B. MVEG oder zufällige Geschwindigkeitsprofile abgefahren
werden.
Bild 3: VeLoDyn Simulink ® -Modell eines Fahrautomaten
1
Out1

Das Subsystem Fahrzeug-Laengsdynamik (Bild 4) enthält mit dem Motor-, dem Getriebe-
und dem Radmodell das Modell des kompletten Antriebstrangs. Ausgehend vom Motor werden
jeweils Momente generiert, die von Teilsystem zu Teilsystem weitergereicht werden. Die
Rückkopplung erfolgt über die Drehzahlen, die vom Rad in Richtung Motor übergeben werden.
Auf diese Art und Weise ergibt sich die modulare Struktur des Triebstrangs.
Bild 4: VeLoDyn Simulink ® -Modell der Fahrzeuglängsdynamik
3.1 Modellbildung - Motor
Fahrzeug
Für die Simulation eines Verbrennungsmotors kann grob zwischen den physikalisch basierten
Ansätzen und der phänomenologischen Beschreibung des Eingangs-/Ausgangsverhaltens
durch mathematische Modelle auf der Grundlage beobachteter Messungen unterschieden
werden. Bei der physikalischen Modellbildung werden noch die betrachteten Dimensionen
(drei-, ein- und nulldimensional) unterschieden. Die Gewinnung und Parametrierung
der Modelle rein aus Konstruktionsdaten haben sich in der Vergangenheit als sehr aufwändig
erwiesen. Zum einen sind die damit verknüpften Simulationsmodelle meist nicht
echtzeitfähig, zum anderen ist es oft nicht möglich, in kürzester Zeit die Konstruktionsdaten
zu beschaffen.
• Einsatz der Statistischen Versuchsplanung
•Neuronale Netze
Bild 5: Kombinierte Modellstruktur
Seite 5

Für die HiL Simulation sind auf Grund des sehr hohen Rechenaufwandes die drei- und
eindimensionalen Modelle ungeeignet. Bei den nulldimensionalen Modellen unterteilt man
den Motor in Baugruppen (z.B. Zylinder, Abgas-Turbine etc.) und bestimmt die jeweils
vorherrschenden Zustände [5]. Dieser Ansatz stellt ein Kompromiss zwischen
Rechenaufwand und Rechengenauigkeit dar. In vielen Fällen werden nulldimensionale
Modelle mit den phänomenologischen Modellen kombiniert.
Während zur Beschreibung des Kraftstoffpfades und des Luftpfades ein nulldimensionales
Modell verwendet wird (Bild 5), wird die Momentenerzeugung d.h. der Verbrennungsprozess
durch ein phänomenologisches Submodell dargestellt. Für diese Modellierung können
verschiedene mathematische Ansätze wie Rasterkennfelder, Neuronale Netze oder auch
Polynome verwendet werden. Durch die zunehmende Anzahl steuerbarer Komponenten
eines Motors nimmt zwangsläufig auch der Aufwand zur messtechnischen Modellgewinnung
zu. Für die Bestimmung der Parameter eines Polynommodells hat sich der Einsatz der
statistischen Versuchsplanung bewährt. Im Verhältnis zur Rastervermessung sind nur
wenige Messungen durchzuführen.
3.1.1 Statistische Versuchsplanung
Der Begriff „statistische Versuchsplanung” (auch DoE – Design of Experiments) bezeichnet
eine Vielzahl von Verfahren. Allen gemeinsam ist jedoch das Ziel, eine Aussage über die
Beziehung zwischen definierten Ausgangsgrößen und deren Einflussfaktoren aufgrund von
wenigen Versuchen treffen zu können (Bild 6).
Seite 6
Einflussgrößen x i
•Drehzahl
• Last
• Zündwinkel
• Einlassnockenwellenspreizung
• Auslassnockenwellenspreizung
• Lambda
Störgrößen u i
• Umgebungstemperatur
•
y y 1 =
1 = ff1 (x)
1 (x) + e
1 = ff1 (x)
1 (x) + e
1 = ff1 (x)
1 (x) + e e 1 1
y y 2 =
2 = ff2 (x)
2 (x) + e
2 = ff2 (x)
2 (x) + e
2 = ff2 (x)
2 (x) + e e 2 2
y y N =
N = ffN (x)
N (x) + e
N = ffN (x)
N (x) + e
N = ffN (x)
N (x) + e e N
N
Bild 6: Modellansatz für die statistische Versuchsplanung
Zielgrößen y i
• Moment
• spez. Kraftstoffverbrauch
•HC, NO x –Emissionen
• Abgastemperatur
•Klopfgrenze
•...
Im vorliegenden Beitrag wurde die Methode der multiplen Regression in Verbindung mit der
Auswahl der optimalen Experimente (d-Optimalität) angewandt. Ausgehend von einem mathematischen
Modell wählt man diejenigen Versuche aus, die zur Schätzung der Modellparameter
am geeignetsten sind. Im Allgemeinen wählt man ein Polynommodell, das linear in
den Parametern ist (Beispiel: Polynom 2. Ordnung mit zwei Eingangsgrößen)

2
2
y = a + a ⋅ x + a ⋅ x + a ⋅ x ⋅ x + a ⋅ x + a ⋅ x + ε = Xa+
ε
0
1
1
2
2
12
Konstante Haupteffekte Wechselwirkung quad. Effekte Fehler
und schätzt dessen Parameter
1
2
11
T −1
T
aˆ
= ( X X)
X y
(2)
mit Hilfe der Methode der kleinsten Fehlerquadrate. Die d-Optimale Versuchsplanung maximiert
dabei die Determinante der Fischerinformationsmatrix (X T ·X) -1 .
Anschließend werden statistische Tests über die Signifikanz der einzelnen Parameter durchgeführt.
Nichtsignifikante Terme werden eliminiert. Eine Analyse der Residuen (Differenz
zwischen Modellvorhersage und Messwert) gibt Aufschluss über die Qualität des Modells
und die Vorhersagegenauigkeit. Danach erfolgt eine Validierung des Modells: Messungen,
die nicht zur Modellierung verwendet wurden, werden mit den Modellprädiktionen verglichen.
Liegen die Messwerte innerhalb des Vertrauensbereiches der Modellvorhersage, so kann
das Modell angenommen werden. Ist das nicht der Fall, so liegt entweder ein Fehler bei der
Modellierung vor (z.B. sind signifikante Einflüsse nicht berücksichtigt) oder die Messwerte
sind fehlerhaft. Die Qualität des entstandenen Modells wird mit verschiedenen statistischen
Testfunktionen wie z.B. dem Bestimmtheitsmaß R 2 oder dem Effektivwert der Residuen
überprüft.
3.1.2 Umsetzung der Modelle für die Anwendung in der HiL Simulation
Die empirische Beschreibung der Abhängigkeit der Zielgröße y von den Einflussgrößen ui
(siehe Bild 6) erfolgt durch quasilineare Polynome (Gleichung 1). Hierdurch lassen sich
Nichtlinearitäten und Wechselwirkungen der Einflussgrößen darstellen. Die in der Technik
häufig vorkommenden linearen, quadratischen und kubischen Effekte werden mit Hilfe dieses
Polynomansatzes sehr gut wiedergegeben. Die Umsetzung eines Motormodells in ein für
die HiL Simulation geeignetes echtzeitfähiges Programm soll anhand eines Beispiels dargestellt
werden. Dieses Beispiel beschreibt die Modellierung des effektiven Moments MD eines
Ottomotors.
Für die Modellierung des effektiven Motormoments in Abhängigkeit des Lastsignals (relative
Füllung rl), der Drehzahl n und des Zündwinkels ZW ist für den Drehzahlbereich 720 min -1 ≤
n ≤ 4200 min -1 ein Polynom 3. Ordnung mit Wechselwirkungen notwendig (Gleichung 3):
M D
=
a
0
a ⋅n
+ a ⋅ rl + a ⋅ ZW +
a
a
a
a
a
1
11
12
123
112
111
+
2
2
2
⋅n
+ a ⋅rl
+ a ⋅ ZW
22
⋅n
⋅rl
+ a
3
13
2
⋅n
⋅rl
+ a
113
3
3
⋅n
+ a ⋅ ZW
233
für 720 min
−1
≤ n ≤ 4200 min
−1
3
⋅n
⋅rl
⋅ ZW +
33
⋅n
⋅ ZW + a
23
2
+
2
⋅n
⋅ ZW + a
⋅rl
⋅ ZW +
⋅rl
⋅ ZW
2
+ a
223
1
2
⋅rl
⋅ ZW +
22
2
(1)
(3)
Seite 7

Für die Bestimmung der Modellparameter waren 45 Messungen notwendig, wovon 5 Messungen
zur Validierung verwendet wurden. Diese Modellgleichung gilt nur für den vorliegenden
Motor in den definierten Grenzen. Im Allgemeinen muss jedoch für den Zündwinkeleinfluss
eine fünfte Ordnung angesetzt werden.
Nach der Bestimmung der Polynomkoeffizienten muss für den Einsatz in der HiL Simulation
aus dieser mathematischen Beschreibung ein ausführbares Programm generiert werden.
Hierfür geeignet sind die grafisch orientierten Simulationsprogramme wie z.B. ASCET-SD
oder auch Simulink ® . Das Bild 7 zeigt die Umsetzung des Modells zur Berechnung des
effektiven Motormoments in Simulink ® .
Seite 8
1
n [1/min]
2
rl [mg/AsZyl]
3
ZW [Grad KW]
-1 ..1
Normierung Drehzahl
-1 ..1
Normierung Last
-1 ..1
Normierung ZW
Polynom effektives Motormoment
720 1/min < N < 4200 1/min
M D
f(u)
Enable
1
effektives Motormoment
= a + a ⋅n
+ a ⋅ rl + a ⋅ ZW + ... ( Gleichung 3)
Bild 7: Simulink ® -Modell für die Bestimmung des effektiven Motormoments – Teilmodell für den
Drehzahlbereich 720 min -1 ≤ n ≤ 4200 min -1
0
Die Nichtlinearitäten eines Motors lassen sich jedoch häufig nicht vollständig durch ein Polynom
wiedergeben, so dass in Abhängigkeit z.B. der Drehzahl verschiedene Polynome zur
Modellierung notwendig sind. Auch in dem hier diskutierten Beispiel wurden für die Drehzahlbereiche
720 min -1 ≤ n ≤ 4200 min -1 und 4100 min -1 ≤ n ≤ 6000 min -1 jeweils ein Polynom
bestimmt. Die Modellgrenzen werden derart gewählt, dass es zu einer Überschneidung der
Gültigkeitsbereiche kommt (Bild 8). Da an den Modellgrenzen die Momente nicht zwingend
den selben Wert annehmen, wird in dem Überschneidungsintervall zur Vermeidung von Unstetigkeiten
eine Filterung beider Modellausgangswerte zu einem Wert vorgenommen.
2
rl [mg/AsZyl]
1
n [1/min]
Modellauswahl
3
ZW
Modell 1 [0/1]
n [1/min]
Modell 2 [0/1]
Modellgueltigkeit
n [1/min]
rl [mg/AsZyl]
ZW [Grad KW]
1
effektives Motormoment Bereich 1
720 1/min

3.2 Modellbildung – Stufenautomaten
Um die dynamischen Vorgänge im Planetengetriebe während des Gangwechsels ausreichend
wiederzugeben, müssen die einzelnen Trägheiten der Zahnräder und die Verdreh-
und Biegesteifigkeiten berücksichtigt werden. Die Abbremsung und Beschleunigung von
Zahnräderkombinationen verläuft bei jeder Schaltung unterschiedlich, so dass der Vereinfachung
des Systems Grenzen gesetzt sind. Eine ausreichend genaue Simulation setzt das
mechanische Ersatzmodell (Bild 9) voraus.
M Motor
J Motor +J Pumpe
J Turbine +J WK
J Getriebeeing.welle
J Kupp
J Kupp
J Kupp
J Kupp / 2
C
B
A
E
J / 2 Kupp
D
J kleineSonne
Bild 9: Mechanisches Ersatzmodell für einen Stufenautomaten
Das Verhalten von Wellen und Zahnräder wird durch ihre Massenträgheiten und Dämpfungseigenschaften
bzw. Steifigkeiten gegenüber Verdrehbeanspruchungen beschrieben.
Hinzu kommen der Wandler sowie die Bremsen und Kupplungen.
Bei der Modellierung wurde eine modulare Struktur gewählt, bei der das Gesamtmodell aus
den Modulen Kupplung, Torsionswelle, Wandler, und Massenträgheiten zusammengesetzt
werden kann. Durch diese modulare Struktur ist die Modellierung verschiedener Getriebe
und Getriebearten (CVT, automatisierte Handschaltgetriebe und Stufenautomaten) leicht
möglich.
Kupplung Torsionswelle Rad
Modul A Torsionskoppl. Modul B
M Aa
M Ae
ω Aa
ω Ae
ω e
ω a
J Steg
Torsionselastische Kopplung der Module
JPlanet1
M T
M T
J großeSonne
J Planet2
M Ba
M Be
J Hohlrad
Modul A Torsionskopplung
Modul B
Bild 10: Modularisierung des mechanischen Ersatzmodells
Für jedes Modul wurden Simulink ® -Modelle erstellt, die entsprechend der Getriebestruktur
miteinander kombiniert werden. Zur Steuerung der Kupplungen und Bremsen sowie des Ab-
G
J Kupp
J Kupp / 2
F
J HohlradN S
ω Ba
ω Be
J SonneNS
J StegNS
J PlanetNS
M Fahrzeug
Seite 9

laufes werden Zustandsautomaten eingesetzt, die mit Hilfe des Werkzeuges Stateflow ® unter
Simulink ® eingebunden werden können.
4 Automatisierter Testprozess
Die HiL Simulation zum Steuergerätetest muss wie die eigentliche Softwareentwicklung in
einem definierten Prozess erfolgen. Zwingend notwendig ist die Integration des Testprozesses
in den Entwicklungsprozess (Bild 1). Damit in den Phasen Modultest, Integrationstest,
Funktionstest und Systemtest die HiL Simulation einsetzbar ist, ist am Anfang eines
Projektes auch das Simulationssystem zu entwickeln.
Durch die stark gestiegenen Qualitätsanforderungen und durch die hohe Komplexität der
Steuergeräte sind in den letzten Jahren die Testumfänge im Verhältnis zu den Softwareumfängen
überproportional angestiegen [4]. Zur Beherrschung des Aufwandes muss unter Berücksichtigung
der Kosten der Testprozess optimiert werden. Eine Qualitätssteigerung und
eine Reduzierung des Aufwands lässt sich insbesondere durch die Automatisierung des
Testprozesses erreichen. Als Vorteile sind
Seite 10
• Minimierung des Testaufwandes (Light Switch Off Tests),
• Reproduzierbarkeit der Testergebnisse,
• einheitliche, automatische Testdokumentation,
• Minimierung der Fehler bei der Testdurchführung � Erhöhung der Zuverlässigkeit,
• Wiederverwendbarkeit der Tests oder von Teilen des Tests
zu nennen.
In dem Maße, in dem die Steuergeräte und Steuergerätenetze komplexer werden, gewinnen
auch die HiL Simulationssysteme an Komplexität. Es müssen oft mehrere Hard- und Softwarekomponenten
(Simulationshardware, Messgeräte, Applikationstools, Simulationsmodelle,
Auswertetools etc.) miteinander verbunden/vernetzt werden. Darüber hinaus müssen
die für den Entwurf der Testsysteme notwendigen Informationen und die Testergebnisse
in Datenbanksystemen verwaltet werden. Für den zielgerichteten Entwurf eines HiL Tests in
allen Phasen bietet sich die Unified Modeling Language (UML) an. Der Einsatz der UML
• erzwingt die Analyse des Testbedarfs
• ermöglicht die Erfassung der Komplexität eines Testsystems
• ermöglicht die plattformunabhängige Beschreibung der Tests und des Testplatzes
• liefert die Dokumentation zum Testplatz und
• erhöht die Wiederverwendbarkeit
in einer standardisierten Notation, die von Programmierern, Testingenieuren, Funktionsentwicklern,
Applikateuren und Testplatzentwicklern verstanden wird.
Der zu automatisierende Prozess gliedert sich in die Schritte Testspezifikation, Implementierung,
Testdurchführung, Auswertung und Dokumentation (Bild 11). In dem folgenden Abschnitt
wird auf die Spezifikation der einzelnen Prozessschritte mittels der UML eingegangen,
um anschließend die Möglichkeiten der Automatisierung aufzuzeigen.

Spezifikation Implementierung Durchführung Auswertung Dokumentation
Bild 11: Testprozess für die Hardware-in-the-Loop Simulation
Testspezifikation
Die Phase der Testspezifikation stellt die Analysephase einer objektorientierten Modellierung
dar. Das dargestellte Vorgehen ist an den in [5] beschriebenen Vorgehensleitfaden angelehnt.
An erster Stelle steht die Formulierung der Zielsetzung. Nach der Klärung der Ziele
werden die Personen identifiziert die Anforderungen und Erwartungen an den hier als Ziel
betrachteten automatisierten Testablauf eines elektronischen Steuergerätes stellen könnten.
Zu dieser Gruppe gehören z. B. die Personen, die den Test bisher von Hand durchgeführt
haben oder die Entwickler der zu testenden Funktionalität. Ergänzend werden die
Funktionsspezifikationen herangezogen.
Nachdem alle beteiligten Personen bekannt sind, werden die Geschäftsprozesse ermittelt,
die durch das automatisierte Testsystem unterstützt werden sollen und die beteiligten
Akteure. Ein Geschäftsprozess ist die Zusammenfassung von fachlich zusammenhängenden
Aktivitäten, die gewöhnlich in einer zeitlichen und logischen Abhängigkeit stehen und
notwendig sind, um einen konkreten Geschäftsvorfall (z. B. einen OBDII-Test)
durchzuführen. Bild 12 zeigt die Darstellung der wichtigsten Akteure und Geschäftsprozesse
des zu realisierenden automatisierten Testsystems in einem Anwendungsfalldiagramm der
UML.
Die gefundenen Geschäftsprozesse Test durchführen, Test auswerten, Test dokumentieren
werden nun durch einfache Aktivitätsdiagramme der UML näher beschrieben. Dabei wird die
Darstellung auf die wesentlichen Aktivitäten des Geschäftsprozesses beschränkt und noch
keine Aussage darüber getroffen, wie eine Aktivität durchgeführt wird. Die einzelnen Aktivitäten
des Geschäftprozesses sind wieder Anwendungsfälle, die noch detaillierter untersucht
werden.
Die Abläufe der Geschäftsanwendungsfälle werden nun textuell in Szenarien beschrieben.
Ein Geschäftsanwendungsfall beschreibt eine oder mehrere Anforderungen zumeist eines
Akteurs an das automatisierte Testsystem. Aus der abstrakten Beschreibung werden Auslöser,
Vorbedingungen und eingehende Informationen sowie Ergebnisse, Nachbedingungen
und ausgehende Informationen der Anwendungsfälle bestimmt. Das Ergebnis sollte eine
Tabelle mit dem folgenden Inhalt sein: Der Name, eine Kurzbeschreibung, die Akteure, die
Auslöser und die Ergebnisse des Geschäftsanwendungsfalles. Anschließend sind auszuschließende
Geschäftanwendungsfälle zu ermitteln, die nicht durch das automatisierte Testsystem
unterstützt werden können.
Seite 11

Anwendungsfalldiagramm
Testingenie ur
Seite 12
Test Test durchführen
durchführen
Test auswerten
Test dokumentieren
Steuergerät
HIL-Simulator
Mess mittel
Auswerte-Software
Applikations-Software
Diagnose-Software
Dokumentati ons-Software
Anwendungsfallbeschreibung
«Schni ttstelle »
ASAM-MC D 1MC
Electr onic ControlUnit
CalibrationSoftware ReportSoftware EvaluationSoftware DiagnosticSoftwar e
«Schni ttstelle »
ASAM-MC D 3MC
1. Test durchführen
Das Experiment w ird gestartet, das Simulationsmodell
geladen und das Fahrzeug in den Betriebspunkt
gebracht. Anschließend .....
2. Testauswerten
Die Testergebnisse werden zusammengestellt.
Anschließend wird der Test ausgewertet, in dem ....
3. Test dokumentieren
Die Testreportdaten werden zusammengestellt.
Anschließend wird der Testreport erstellt und ....
«Schni ttstelle »
Graphica lU serInterfac eAcces s
«Schni ttstelle »
CAN
«Schni ttstelle »
ActiveX
AutomationSystem
«Schni ttstelle »
KWP2000
«Schni ttstelle »
DLL
GraphicalUserInterface «Schni ttstelle »
«Schni ttstelle »
«Schni ttstelle »
«Schni ttstelle »
Rea lTimeProces sor Acces s R elais BoxAcces s Powe rSupplyU nitAcces s Data Captur eAccess
«Schni ttstelle »
Re alTimeSignalSeque nc eStim ulation
Bild 12: Spezifikation der Tests unter UML
Geschäftsklassendiagramm
RealTimeProce ssor
HardwareInTheLoopSimulator
«Schni ttstelle »
ISO914 1
RelayBox PowerSupplyUnit
MeasuringEquipment
«Schni ttstelle »
Meas urin gEq ui pmen tAcces s
Aktivitätsdiagramm
Experiment starten
Simulationsmodell laden
Fahrzeug in Betriebspunkt bringen
Testablauf durchführen Datenerfassung durchführen
Fahrzeug abstellen
Nachdem alle Anwendungsfälle beschrieben sind, werden die Geschäftsklassen identifiziert
und in dem Klassendiagramm der UML dargestellt. Bei den Geschäftsklassen handelt es
sich um die wichtigsten Klassen des zu erstellenden automatisierten Testsystems. Es handelt
sich dabei z. B. um Gegenstände, Software oder Personen aus dem realen Umfeld. Die
Geschäftsklassen werden während der Designphase weiter zerlegt und führen zu den Fachklassen.
Im Klassenmodell werden auch die Schnittstellen der einzelnen Klassen beschrieben.
Am Ende der Analysephase steht die Komponentenbildung mit der Unterscheidung der gefundenen
Komponenten in bereits existierende und noch zu erstellende. Die in Bild 12 (Klassendiagramm)
dargestellten Klassen entsprechen weitgehend den im späteren Verlauf der
Entwicklung des Testsystems verwendeten Komponenten.
An die Analysephase schließt sich nun die Designphase an. In der Designphase werden die
Fachklassen und ihre Beziehungen identifiziert, die Operationen und Attribute der Klassen
spezifiziert, die Objektzustände und Objektinteraktionen sowie die Anbindung einer Datenbank
z. B. zur Speicherung von persistenten Objekten modelliert.
Den Abschluss der Designphase bildet die automatische Codegenerierung, die bei Verwendung
eines UML-Entwicklungswerkzeuges für viele Programmier- und Skriptsprachen auch
für die hier verwendete Skriptsprache Python heute zur Verfügung steht.

5 Anwendungsbeispiel – HiL Simulator zum Test von Steuergeräten für Stufenautomaten
Bild 13 zeigt das in der IAV GmbH betriebene automatisierte Testsystem zum Test von
Getriebesteuergeräten. Im Zentrum steht das Automatisierungssystem mit den Schnittstellen
zu den Komponenten Applikationssoftware (z. B. ETAS IncaPC), Diagnosesoftware (z. B.
Softing DTS), Auswertesoftware (z. B. Mathworks Matlab ® ), Reportsoftware (z. B. Microsoft ®
Office, HTML) und Bedienoberfläche (z. B. dSPACE ControlDesk).
Bild 13: Anwendung: Hardware-in-the-Loop Simulation zum Test von Getriebesteuergeräten
Der Zugriff auf die Applikationssoftware ermöglicht zusätzlich zur Datenerfassung
steuergeräteinterner Daten auch den automatisierten Wechsel der Steuergerätesoftware. Ein
Vergleich verschiedener Softwarestände ist damit automatisiert durchführbar. Darüber
hinaus stehen Schnittstellen zu der Komponente Hardware-in-the-Loop-Simulator (z. B.
dSPACE ® MidSize-Simulator) zum Zugriff auf die Echtzeitvariablen, die Relaiskarte zur
Fehlersimulation und dem Netzteil zu Simulation von Spannungseinbrüchen zur Verfügung.
Durch die in der IAV GmbH unternommenen Anstrengungen zur Erstellung eines durchgängig
mit der Notation der UML beschriebenen automatisierten Testsystems, ist es nun
möglich, die in Bild 12 als Testablauf durchführen beschriebene Aktivität für neue Tests mit
Hilfe der UML zu beschreiben, bestehende Tests anzupassen, zu erweitern und unter Verwendung
eines geeigneten Entwicklungswerkzeuges den Softwarecode automatisch zu generieren.
Automatisierte Tests für Getriebesteuergeräte
Mit dem spezifizierten System werden HiL Tests von
• CAN-Bus-Fehlern
• Einbrüchen der Bordspannung
• OBDII-Überprüfungen
• mechanische Fehler
• Leistungsfehlern
durchgeführt. Exemplarisch wird anhand des Leitungsfehlertests der Ablauf beschrieben.
Seite 13

Leitungsfehlertest
Die Funktionsfähigkeit der Aktuatoren und Sensoren werden in elektronischen Steuergeräten
ständig überwacht. Es müssen durch die Steuergerätediagnosen insbesondere Kurzschlüsse
und offene Leitungen erkannt werden. Im so genannten Leitungsfehlertest werden mittels der
im Simulator integrierten Relaisbox Kurzschlüsse gegen Masse und gegen die Versorgungsspannung
sowie offene Leitungen simuliert. Ein typischer automatisierter Testverlauf stellt
sich wie folgt dar: Das Fahrzeug wird über die Zündung gestartet. Bei einem definierten Zustand
wird der Fehler ausgelöst und die Reaktion des Steuergerätes bzw. des Fahrzeuges
aufgezeichnet. Das Getriebesteuergerät sollte den Fehler erkennen, einen Fehlerspeichereintrag
durchführen und eine Ersatzreaktion auslösen. Diese Ersatzreaktion und der automatisch
ausgelesene Fehlerspeichereintrag wird mit der Sollvorgabe im Fehlerlastenheft
verglichen. Der Fehlereintrag wird gelöscht und abschließend das Fahrzeug abgestellt. Das
Ergebnis wird in einem Testreport zusammengefasst und mit n.i.O. oder i.O. bewertet.
Bild 14: Leitungsfehlertest, Kabelbruch Shiftventil.
Seite 14
1
2
3
n G
Konfiguration Relaisbox
n Mot
Fahrzeugverhalten
Fehlerspeicher
009 Shiftventil – Unterbrechung/Kurzschluss nach Plus
Link to tester closed
Plot 1: Fehlerflag.
Plot 2: Motordrehzahl nMot, Getriebeeingangsdrehzahl nG und Wandlerkupplung.
Plot 3: Fahrgeschwindigkeit und Fahrgang.
Bei einer Volllastbeschleunigung eines Fahrzeuges mit Automatikgetriebe wird im dritten
Gang ein Shiftventil vom Getriebesteuergerät getrennt (siehe Bild 14, Plot 1). Das Steuergerät
erkennt den Fehler, öffnet die Wandlerkupplung (siehe Bild 14, Plot 2) und schaltet in
den Notlauf, d. h. alle Ventile werden stromlos geschaltet. Damit wird automatisch der vierte
Gang (Bild 14, Plot 3) eingelegt, und es kann in diesem Gang weiter gefahren werden.
Geht man davon aus, dass für die Freigabe eines Softwarestandes sämtliche relevante Pins
eines Steuergerätes mit den Fehlerfällen „Kurschluss gegen Masse“, „Kurzschluss gegen die
Versorgungsspannung“ sowie „offene Leitung“ geprüft werden, wird der Vorteil der Automatisierung
deutlich. Die Prüfzeiten konnten gegenüber einen Simulator ohne Automatisierung
um ungefähr den Faktor 10 reduziert werden.

6 Zusammenfassung und Ausblick
Die HiL Simulation zum Steuergerätetest ist zu einem festen Bestandteil des Softwareentwicklungsprozesses
in der Automobilelektronik geworden. Ein Mittel zur Optimierung des
Testprozesses bezüglich der Prüftiefe und des Aufwandes stellt der automatisierte Test in
der Hardware-in-the-Loop Simulation dar. Die Prüftiefe der Tests hängt dabei stark von dem
Detaillierungsgrad und der Verfügbarkeit der echtzeitfähigen Simulationsmodelle ab. Die
Modellbildung und Testautomatisierung sind der Schlüssel zum erfolgreichen und effizienten
Einsatz der HiL Simulation.
Die statistische Versuchsplanung ist zur Gewinnung echtzeitfähiger Motormodelle für den
Einsatz in der HiL Simulation geeignet. Die mit der statistischen Versuchsplanung
gewonnenen Polynommodelle lassen sich direkt in die für die Echtzeitsimulation geeignete
Programmiersprache Simulink ® umsetzen.
Für die Modellierung von Getrieben hat sich eine Modularisierung in die Komponenten
Kupplung, Bremse, Torsionswelle und Rad bewährt. Mit Hilfe dieser Modularisierung können
alle gängigen Getriebearten CVT, Stufenautomaten, automatisierte Schaltgetriebe für die
Echtzeitanwendung dargestellt werden.
Zur Beherrschung des Testaufwandes wurde ein durchgängiger, automatisierter Testprozess
für die HiL Simulation dargestellt. Durch den Einsatz der Unified Modeling Language können
die Tests unabhängig von der Simulationsplattform analysiert und entworfen werden.
Anhand des Beispiels der HiL Simulation zum Test einer Getriebesteuerung für
Stufenautomaten sind die Möglichkeiten des automatisierten Tests dargestellt worden.
Die vorgestellte Vorgehensweise zur Analyse und zum Entwurf des Testsystems mit Hilfe
der UML sollte zukünftig auch auf MiL und SiL Simulationen übertragen werden. Das
vorgestellte HiL System ist um eine automatische Codegenerierung aus der
Beschreibungssprache UML heraus zu erweitern.
7 Literatur
[1] Gühmann, C.; Riese, J.: Testautomatisierung in der Hardware-in-the-Loop Simulation.
VDI/VDE Symposium Steuerung und Regelung von Motoren – Autoreg 2002. 15/16.
April 2002.
[2] Gühmann, C.; Röpke, K.; Lindemann, M.: Gewinnung echtzeitfähiger Modelle für die
Hardware-in-the-Loop Simulation mit Hilfe der statistischen Versuchsplanung. VDI
Symposium Mess- und Versuchstechnik im Fahrzeugbau. VDI-Berichte Nr. 1616, 2001
[3] Röpke, K; Fischer, M.: Effiziente Applikation von Motorsteuerungsfunktionen für
Ottomotoren, MTZ Motortechnische Zeitschrift 61, 9, 2000
[4] Stahl, M.; Dornseiff, M.; Sax, E.: Durchgängige Testmethoden für komplexe Steuerungsgssysteme
– Erhöhung der Prüftiefe durch Testautomatisierung. Tagungsband 3.
Symposium Steuerungssysteme für den Antriebsstrang von Kraftfahrzeugen. 25-26
Oktober 2001. Berlin
Seite 15

[5] Offer, T.; Häntschel, U.: Virtuelle Entwicklung und Test von Steuergerätefunktionen im
dynamischen Fahrzeugbetrieb. VDI/VDE Symposium Steuerung und Regelung von
Motoren – Autoreg 2002. 15/16. April 2002.
[6] Oestereich, Bernd: Objektorientierte Softwareentwicklung: Analyse und Design mit der
Unified Modeling Language - 4. aktualisierte Aufl. – München; Wien: Oldenbourg Verlag
1998
[7] Boot, R.; Richert, J.; Schütte, H.; Jegminat, D.: Eine automatisierte Testumgebung für
Seriensteuergeräte auf Basis eines Hardware-in-the-Loop Simulators. VDI Berichte
1470, VDI-Gesellschaft Fahrzeug- und Verkehrstechnik, Mess- und Versuchstechnik
im Fahrzeugbau, Kongress Mainz, 29/30. April 1999
Seite 16