Modellbildung und Testautomatisierung für die Hardware-in-the-Loop Simulation
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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) Simu-
lation 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 automa-
tisiert 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 Er-
wartungen der Kunden bezüglich Fahrkomfort, Leistung und Sicherheit nimmt die Komplexi-
tät des Antriebsstrangs moderner Kraftfahrzeuge rasant zu. Die geltenden und zukünftigen
Umwelt-Gesetzgebungen können unter anderem nur durch moderne Motoren mit einer Viel-
zahl 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 – verbun-
den mit kürzer werdenden Entwicklungszyklen – ist die Anwendung neuer Methoden bei der
Entwicklung und Bedatung der Software notwendig. Aufgrund des zunehmenden Kosten-
drucks 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 ver-
stä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 Test-
prozesses 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 12 Simulation im Software- und Funktionsentwicklungsprozess
Der Einsatz der Simulation lässt sich anhand des sogenannten V-Modells darstellen. In Ab-
hängigkeit des Entwicklungsschrittes kommen verschiedene Simulationsarten zum Tragen.
Ausgangspunkt der Softwareentwicklung sind die Anforderungen des Kunden, die zum Be-
ginn der Softwareentwicklung in Form eines Lastenheftes vorliegen (Bild 1). Nach der
Systemspezifikation erfolgt die Funktionsspezifikation, die durch die Model-in-the-Loop Si-
mulation 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 Work-
station 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 Lasten-
heft vor.
Kunde
Anforderung 4 5 Applikation
Systemspezifikation 4 Systemtest
Rapid-Prototyping
Funktionsspezifikation 1 2 4 Funktionstest
Programmentwurf 4 Integrationstest
Modulentwurf 3 Modultest
Softwarentwicklungsprozess Codierung
1 Model-in-the-Loop Simulation 3 Software-in-the-Loop Simulation
Modell der Software
Fahrzeugmodell Fahrzeugmodell
Software Seriencode
PC PC
2 Rapid-Prototyping 4 Hardware-in-the-Loop Simulation
Regelstrecke Modell der Fahrzeugmodell Steuergerät
im Fahrzeug Software Steuer-
Steuer- DSP gerät
Bypass- gerät
Rechner
5 Offline-Simulation
Fahrzeugmodell Kennfeld-
optimierung
Stellgrößen, z.B. Zündwinkel PC
Bild 1: Software- und Funktionsentwicklungsprozess
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 Funk-
tionen in eine serientaugliche Software schließen sich in den Prozessschritten Programm-
Seite 2entwurf, 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) un-
terstützt. Auch die sich nun anschließenden Funktions- und Systemtests sind ohne den Ein-
satz eines Hardware-in-the-Loop Simulators in der geforderten Prüftiefe nicht mehr zu be-
wä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 Softwareent-
wicklung 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 implemen-
tierenden Modelle müssen daher so einfach wie möglich in ihrer mathematischen Beschrei-
bung 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 physi-
kalische Grundstruktur wird durch die Einbindung phänomenologischer Beschreibungs-
modelle ergänzt. Die Methoden zur Modellierung werden im folgenden anhand der in der IAV
GmbH entwickelten Modellbibliothek VeLoDyn zum HiL-Getriebesteuergerätetest verdeut-
licht.
Ein komplettes Modell für den Getriebesteuergerätetest enthält neben der reinen Längs-
dynamiksimulation insbesondere für die automatisierte Testdurchführung ein Fahrermodell,
die Berücksichtigung unterschiedlicher Strecken und Umweltbedingungen sowie die Mög-
lichkeiten, 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 Ge-
triebe-Steuergeraet stellt die Anbindung des Modells an das Steuergerät her. Es enthält Mo-
dule, über die Aktuatorenansteuerungen ins Modell eingelesen werden können, z. B. Duty-
cycle für Lastventile. Zudem werden hier die Sensorsignale wie z. B. Drehzahlsignale gene-
riert. Das Subsystem Fahrzeug und Umgebung enthält das eigentliche Fahrzeuglängs-
dynamikmodell und darüber hinaus Module, über die die Fahrereingaben eingespeist wer-
den. 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öglich-
keit, 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.
In1 Out1
Fahrzeug und Umgebung
Out1 In1
Getriebe-Steuergeraet
Bus_Input
Bus_Fahrzeug
Bus_Umgebung
Fahrzeug-Laengsdynamik
1
In1 1
Out1
Bus_Fahrzeug
Bus_Umgebung
Bus_Input
Bedienung und Umgebung
Bild 2: Das VeLoDyn Simulink-Fahrzeugmodell
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
Seite 4Das Subsystem Fahrzeug-Laengsdynamik (Bild 4) enthält mit dem Motor-, dem Getriebe-
und dem Radmodell das Modell des kompletten Antriebstrangs. Ausgehend vom Motor wer-
den jeweils Momente generiert, die von Teilsystem zu Teilsystem weitergereicht werden. Die
Rückkopplung erfolgt über die Drehzahlen, die vom Rad in Richtung Motor übergeben wer-
den. Auf diese Art und Weise ergibt sich die modulare Struktur des Triebstrangs.
Fahrzeug
Bild 4: VeLoDyn Simulink®-Modell der Fahrzeuglängsdynamik
3.1 Modellbildung - Motor
Für die Simulation eines Verbrennungsmotors kann grob zwischen den physikalisch basier-
ten Ansätzen und der phänomenologischen Beschreibung des Eingangs-/Ausgangsverhal-
tens durch mathematische Modelle auf der Grundlage beobachteter Messungen unter-
schieden werden. Bei der physikalischen Modellbildung werden noch die betrachteten Di-
mensionen (drei-, ein- und nulldimensional) unterschieden. Die Gewinnung und Parametrie-
rung der Modelle rein aus Konstruktionsdaten haben sich in der Vergangenheit als sehr auf-
wä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 5Fü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).
Störgrößen u i
• Umgebungstemperatur
•
Einflussgrößen xi Zielgrößen yi
• Drehzahl • Moment
• Last
• spez. Kraftstoffverbrauch
• Zündwinkel
• Einlassnockenwellen- • HC, NOx – Emissionen
spreizung • Abgastemperatur
• Auslassnockenwellen- • Klopfgrenze
spreizung • ...
• Lambda
yy1 ==ff1 (x) +e
1 1 (x) + e11
yy2 ==ff2 (x)
(x) ++ ee2
2 2 2
yyN ==ffN (x) +e
N N (x) + eNN
Bild 6: Modellansatz für die statistische Versuchsplanung
Im vorliegenden Beitrag wurde die Methode der multiplen Regression in Verbindung mit der
Auswahl der optimalen Experimente (d-Optimalität) angewandt. Ausgehend von einem ma-
thematischen Modell wählt man diejenigen Versuche aus, die zur Schätzung der Modellpa-
rameter am geeignetsten sind. Im Allgemeinen wählt man ein Polynommodell, das linear in
den Parametern ist (Beispiel: Polynom 2. Ordnung mit zwei Eingangsgrößen)
Seite 6y = a0 + a1 ⋅ x1 + a2 ⋅ x2 + a12 ⋅ x1 ⋅ x2 + a11 ⋅ x12 + a22 ⋅ x22 + ε = Xa + ε
(1)
Konstante Haupteffekte Wechselwirkung quad. Effekte Fehler
und schätzt dessen Parameter
aˆ = ( XT X) −1 X T y (2)
mit Hilfe der Methode der kleinsten Fehlerquadrate. Die d-Optimale Versuchsplanung maxi-
miert dabei die Determinante der Fischerinformationsmatrix (XT·X)-1.
Anschließend werden statistische Tests über die Signifikanz der einzelnen Parameter durch-
gefü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ß R2 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 die-
ses Polynomansatzes sehr gut wiedergegeben. Die Umsetzung eines Motormodells in ein für
die HiL Simulation geeignetes echtzeitfähiges Programm soll anhand eines Beispiels darge-
stellt 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 = a0 +
a1 ⋅ n + a 2 ⋅ rl + a3 ⋅ ZW +
a11 ⋅ n 2 + a22 ⋅ rl 2 + a33 ⋅ ZW 2 +
a12 ⋅ n ⋅ rl + a13 ⋅ n ⋅ ZW + a 23 ⋅ rl ⋅ ZW + (3)
a123 ⋅ n ⋅ rl ⋅ ZW +
a112 ⋅ n 2 ⋅ rl + a113 ⋅ n 2 ⋅ ZW + a233 ⋅ rl ⋅ ZW 2 + a223 ⋅ rl 2 ⋅ ZW +
a111 ⋅ n 3 + a3 ⋅ ZW 3
für 720 min −1 ≤ n ≤ 4200 min −1
Seite 7Für die Bestimmung der Modellparameter waren 45 Messungen notwendig, wovon 5 Mes-
sungen zur Validierung verwendet wurden. Diese Modellgleichung gilt nur für den vorliegen-
den Motor in den definierten Grenzen. Im Allgemeinen muss jedoch für den Zündwinkel-
einfluss 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®.
1 -1 ..1 Enable
n [1/min] Normierung Drehzahl
Polynom effektives Motormoment
720 1/min < N < 4200 1/min
2 -1 ..1 f(u) 1
rl [mg/AsZyl] Normierung Last
effektives Motormoment
3 -1 ..1
ZW [Grad KW] Normierung ZW
M D = a0 + a1 ⋅ n + a2 ⋅ rl + a3 ⋅ 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
Die Nichtlinearitäten eines Motors lassen sich jedoch häufig nicht vollständig durch ein Poly-
nom 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 Dreh-
zahlbereiche 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 Un-
stetigkeiten eine Filterung beider Modellausgangswerte zu einem Wert vorgenommen.
effektives Motormoment Bereich 1
720 1/min3.2 Modellbildung – Stufenautomaten
Um die dynamischen Vorgänge im Planetengetriebe während des Gangwechsels ausrei-
chend 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 Verein-
fachung des Systems Grenzen gesetzt sind. Eine ausreichend genaue Simulation setzt das
mechanische Ersatzmodell (Bild 9) voraus.
JKupp / 2
G
JKupp
JKupp / 2
JkleineSonne F
C
JKupp
JgroßeSonne JSonneNS
JMotor +JPumpe JTurbine+JWK
JGetriebeeing.welle B
JKupp
MMotor M Fahrzeug
A JStegNS
JKupp
JSteg JPlanetNS
E JPlanet1 JPlanet2
JKupp / 2 JHohlradNS
D
JHohlrad
Bild 9: Mechanisches Ersatzmodell für einen Stufenautomaten
Das Verhalten von Wellen und Zahnräder wird durch ihre Massenträgheiten und Dämp-
fungseigenschaften 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
Torsionselastische Kopplung der Module
MAa ωAa ωe MT MBa ωBa
Modul A Torsionskopplung Modul B
MAe ωAe ωa MT MBe ωBe
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-
Seite 9laufes 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 Testpro-
zesses in den Entwicklungsprozess (Bild 1). Damit in den Phasen Modultest, Integrations-
test, 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 Softwareum-
fängen überproportional angestiegen [4]. Zur Beherrschung des Aufwandes muss unter Be-
rü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
• 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 Soft-
warekomponenten (Simulationshardware, Messgeräte, Applikationstools, Simulations-
modelle, Auswertetools etc.) miteinander verbunden/vernetzt werden. Darüber hinaus müs-
sen 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, Funktions-
entwicklern, Applikateuren und Testplatzentwicklern verstanden wird.
Der zu automatisierende Prozess gliedert sich in die Schritte Testspezifikation, Implemen-
tierung, Testdurchführung, Auswertung und Dokumentation (Bild 11). In dem folgenden Ab-
schnitt wird auf die Spezifikation der einzelnen Prozessschritte mittels der UML eingegan-
gen, um anschließend die Möglichkeiten der Automatisierung aufzuzeigen.
Seite 10Spezifikation 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 ange-
lehnt. 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 Aktivi-
tä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 Aus-
lö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 auszu-
schließende Geschäftanwendungsfälle zu ermitteln, die nicht durch das automatisierte Test-
system unterstützt werden können.
Seite 11Anwendungsfalldiagramm Anwendungsfallbeschreibung Aktivitätsdiagramm
Steuergerät 1. Test durchführen
Das Experiment w ird gestartet, das Simulationsmodell
HIL-Simulato r
geladen und das Fahrzeug in den Betriebspunkt
gebracht. Anschließend ..... Experiment s tarten
Test durchführen 2. Testauswerten
A ppli kati ons-Software Die Testergebnisse werden zusammengestellt.
Anschließend wird der Test ausgewertet, in dem .... Si mulationsmodell laden
3. Test dokumentieren
Testingenie ur
Di agnose -Software Die Testreportdaten werden zusammengestellt.
Anschließend wird der Testreport erstellt und ....
Tes t auswert en Mess mittel Fahrze ug in Betriebspunkt bringen
Auswerte-Software
Testablauf durchführen Datenerfassung durchführen
Dokumentati ons-Software
Te st dokumentieren
Fahrzeug abstellen
Geschäftsklassendiagramm
Electr onic ControlUnit
«Schni ttstelle » «Schni ttstelle » «Schni ttstelle » «Schni ttstelle »
ASAM-MCD 1MC CAN KWP2000 ISO914 1
C alibrationSoftwar e Re portSoftwar e EvaluationSoftware DiagnosticSoftware Meas ur ingEquipment
«Schni ttstelle » «Schni ttstelle » «Schni ttstelle » «Schni ttstelle »
ASAM-MCD 3MC ActiveX DLL Meas uringEquipmentAcces s
«Schni ttstelle » Automa tionSys te m
Graphica lU serInterfac eAcces s
Gra phic alUser Interfac e «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 » RealTimeProce ssor RelayBox PowerSupplyUnit
Re alTimeSignalSeque nc eStim ulation
Hardware InTheLoopSim ulator
Bild 12: Spezifikation der Tests unter UML
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 han-
delt 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 Fach-
klassen. Im Klassenmodell werden auch die Schnittstellen der einzelnen Klassen beschrie-
ben.
Am Ende der Analysephase steht die Komponentenbildung mit der Unterscheidung der ge-
fundenen Komponenten in bereits existierende und noch zu erstellende. Die in Bild 12 (Klas-
sendiagramm) 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 Da-
tenbank z. B. zur Speicherung von persistenten Objekten modelliert.
Den Abschluss der Designphase bildet die automatische Codegenerierung, die bei Verwen-
dung eines UML-Entwicklungswerkzeuges für viele Programmier- und Skriptsprachen auch
für die hier verwendete Skriptsprache Python heute zur Verfügung steht.
Seite 125 Anwendungsbeispiel – HiL Simulator zum Test von Steuergeräten für Stufen-
automaten
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 durch-
gä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 Ver-
wendung eines geeigneten Entwicklungswerkzeuges den Softwarecode automatisch zu ge-
nerieren.
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 13Leitungsfehlertest
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 Versorgungs-
spannung sowie offene Leitungen simuliert. Ein typischer automatisierter Testverlauf stellt
sich wie folgt dar: Das Fahrzeug wird über die Zündung gestartet. Bei einem definierten Zu-
stand wird der Fehler ausgelöst und die Reaktion des Steuergerätes bzw. des Fahrzeuges
aufgezeichnet. Das Getriebesteuergerät sollte den Fehler erkennen, einen Fehlerspeicher-
eintrag durchführen und eine Ersatzreaktion auslösen. Diese Ersatzreaktion und der auto-
matisch 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.
Konfiguration Relaisbox
1 Fahrzeugverhalten
2
nG nMot
Fehlerspeicher
3
009 Shiftventil – Unterbrechung/Kurzschluss nach Plus
Link to tester closed
Bild 14: Leitungsfehlertest, Kabelbruch Shiftventil.
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 Steuer-
gerä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 Automati-
sierung deutlich. Die Prüfzeiten konnten gegenüber einen Simulator ohne Automatisierung
um ungefähr den Faktor 10 reduziert werden.
Seite 146 Zusammenfassung und Ausblick
Die HiL Simulation zum Steuergerätetest ist zu einem festen Bestandteil des Software-
entwicklungsprozesses 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 Steue-
rungsgssysteme – 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 Ver-
lag 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 16Sie können auch lesen
