Automatisierter Motorsteuergerätetest mit Hardware-in-the-Loop Prüfständen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Automatisierter Motorsteuergerätetest mit Hardware-in-the-Loop Prüfständen Engl.: Automatic ECU Test with HiL-Simulation Autoren: Prof. Dr.-Ing. H.-C. Reuss, Dipl.-Ing. R. Deutschmann TU Dresden/IVK-EE Dipl.-Ing. J. Liebl, Dipl.-Ing. F. Munk, Dr.-Ing. C. Schmidt BMW AG Vortragender: Dipl.-Ing. R. Deutschmann Abstrakt: Im Rahmen eines Kooperationsprojektes zwischen der BMW AG und der TU Dresden wurde ein Softwaretool für die Automatisierung des Tests von Motorsteuergeräten für dSpace Hardware-in-the-Loop (HiL) Prüfstande entwickelt. Die Software vereinigt die Möglichkeiten der Stimulierung, Diagnose, Auswertung der Steuergeräte (EDIABAS, INCA, ASAP2) und deren simulierter Umgebung (Motormodell). Die erzeugten Sequenzen sind beliebig reproduzierbar und stehen damit für jeden weiteren Entwicklungsschritt zur Verfügung (Regressionstest). Außerdem werden in einem zusätzlichen Modul mit Hilfe einer intuitiven Bedienoberfläche alle möglichen Fehlerfälle an allen möglichen Steuergeräteendstufen automatisch getestet. Diese Software bildet die Grundlage für weitere wissenschaftliche Untersuchungen im Bereich der automatischen bzw. optimierten Testvektorgenerierung. Zur Testquantitätsverringerung werden bekannte Methoden wie das Äquivalenz- klassenverfahren in Verbindung mit kombinatorischen Algorithmen untersucht. Abstract: BMW and Dresden University of Technology developed the software tool ECU-TEST to automate ECU Hardware-in-the-Loop (HiL) testing on a dSpace platform. This software combines all kinds of stimulation, diagnosis of ECUs (EDIABAS, INCA, ASAP2) and the simulated environment. Sequences created once are reproducible and can be used for next development steps (regression testing). Besides that ECU- TEST has a SwitchBox module with a intuitive graphical user interface for wire harness failure diagnosis test. ECU-TEST is a platform to start from for other researches like combinatorial algorithm for reducing test vector quantity.
1. Einleitung
Um die immer weiter steigende Komplexität der Steuergerätesoftware zu testen,
werden immer mehr Hardware in the Loop (HiL) - Systeme in den Steuergeräte-
Entwicklungsprozess eingebunden. Sie bieten die Möglichkeit, Umgebungs-
bedingungen zu realisieren, die in der realen Welt nur selten vorkommen oder sehr
schwer zu erzeugen sind. Dabei ist die Reproduzierbarkeit der Ergebnisse für die
Fehlersuche von großem Vorteil.
Ziel war es, den Testablauf, die Testsequenzgenerierung bzw. die Testdatenanalyse
zu automatisieren. Dafür wurde an der TU Dresden in Zusammenarbeit mit der BMW
AG das Software Tool ECU-TEST entwickelt. Das Tool ist auf dSpace-Systeme
abgestimmt, und wurde in der Interpretersprache Python (wxPython) programmiert
und nutzt die Funktionalitäten der dSpace-ControlDesk Software.
EDIABAS ECU-TEST STIMULUS EDIABAS
GUI
Switch-Box Regression Motor-
Modell
Motor-
Modell Dokumentation Dokumentation
INCA
Abbildung 1 ECU-TEST Übersicht Funktionalitäten
Prinzipiell ist das Programm in zwei Module unterteilt. Das SwitchBox-Modul bietet
die Möglichkeit, mit einer intuitiven Bedienoberfläche alle im Fahrzeug auftretenden
Fehlerarten zu simulieren und deren richtige Diagnose zu überprüfen. Das
Regression-Modul dient zur Erstellung von Testsequenzen, welche auf das
Motormodell und das Steuergerät zugreifen und gemessene Werte mit
Erwartungswerten vergleichen. Die Dokumentation der Testergebnisse für beide
Module erfolgt in Excel-Tabellen.
2. SwitchBox-Modul
Häufig auftretende Probleme im Automobil sind Kontaktprobleme, Abriss von
Sensoren bzw. Aktoren und Kurzschlüsse gegen Masse oder Batteriespannung.
Diagnosefunktionen im Motorsteuergerät sollen den Verlust von Signalquellen und
das Auftreten von Kurzschlüssen erkennen und richtig reagieren z.B. mit der
Abschaltung und der Registrierung des Fehlerortes im Fehlerspeicher.
Der SwitchBox-Test ist ein Black-Box-Test nach der Methode der
Funktionsabdeckung und bietet dem Benutzer die Möglichkeit Diagnosefunktionen zu
validieren. Der erste Schritt zu einem automatisierten Testablauf war die Erstellung
des Teilmoduls SwitchBox für den Test der Endstufendiagnose. Über eine intuitive
grafische Bedienoberfläche (Abbildung 2), welche sich automatisch an den jeweiligenUSP (Universeller Steuergeräte Prüfstand) anpasst, können die im Fahrzeug
möglichen Fehlerarten (Kurzschluss, Unterbrechung) im Kabelbaum ausgewählt
werden.
Abbildung 2 SwitchBox- Modul (User Interface)
Außerdem ist es möglich, zwischen drei verschiedenen Fehlertypen zu
unterscheiden ( Abbildung 3). Die Fehlerdauer und die Entprellzeit sind frei wählbar.Abbildung 3 Wählbare Fehlertypen
Pro Pin ergeben sich somit drei mal drei verschiedene Testfälle. Damit können
folgende Diagnosen auf ihre Funktion automatisch überprüft werden.
Getestete Diagnosen:
- Fehlerart (Masse, Batteriespannung, Unterbrechung)
- Entprellzeit
- Fehler anliegend/ nicht anliegend
- Fehlerortzuordnung
- Fehleranzahl
Während des Tests werden die ausgesuchten Modellgrößen in Echtzeit
aufgezeichnet. Dies bietet die Möglichkeit die Umweltbedingungen während eines
Tests zu reproduzieren und eventuelle Rückschlüsse auf Modell- bzw.
Steuergerätefehler zu ziehen. Die Daten werden bewertet und in einer Excel- Tabelle
abgelegt. Aus dieser ist für den Nutzer sofort erkennbar, welche Diagnosen
fehlgeschlagen und welche erfolgreich ausgeführt worden sind.
3. Regression-Modul
Da das SwitchBox-Modul nur die Endstufendiagnosen und damit nur einen
begrenzten Teil der Steuergerätesoftware testen kann, wurde ein flexibleres Modul
zur Testsequenzerstellung entwickelt. Es vereinigt alle Möglichkeiten, um auf das
Steuergerät und den Echtzeitrechner zuzugreifen. So können Labels im Steuergerät
via INCA-Tool oder EDIABAS Laufzeitsystem geschrieben bzw. gelesen werden.
Dazu ist es möglich, bestimmte Variablen und Konstanten im Motormodell zu
stimulieren, zu modifizieren oder zu lesen.
Im folgenden wird beschrieben, welche Aktionen als einzelner Testschritt in die
Testsequenz eingefügt werden können.
ECU-TEST ermöglicht es, alle steuergerätespezifischen SGBD (Steuer- Geräte-
Beschreibungs- Datei) Jobs mit Hilfe des EDIABAS- Laufzeitsystems auszuführen
z.B. Fehlerspeicher lesen oder löschen. Die zurückgelieferten Werte werden mit vom
Nutzer vorgegebenen Erwartungswerten verglichen. Die Kommunikation erfolgt über
eine serielle K- Line Schnittstelle mittels eines Aktiven Diagnose Steckers (ADS).
Damit können über den SGBD- Job „RAM- Zelle lesen“ auch alle im dazugehörigen
ASAP2- File festgelegten Labels im Steuergerät ausgelesen werden. Dazu wird dasfür den Softwarestand spezifische ASAP2-File nach der Adresse, der
Umrechnungsformel und dem Datentyp durchsucht. Die gelesenen Werte können
entweder direkt oder mit dem korrespondierenden physikalischen Umrechnungswert
zu einem erwarteten Ergebnis in Relation gesetzt werden.
Da der Lesezugriff auf die steuergeräteinternen Variablen über die K-Line sehr
langsam und das Schreiben derselben nicht möglich ist, wurde zusätzlich das Tool
INCA eingebunden. INCA ist ein Applikations- und Messsystem der Firma ETAS.
Der Zugriff auf das Steuergerät kann parallel unter Verwendung eines ETK
(Emulatortastkopf) oder auch seriell via CAN-Bus bzw. K-Line erfolgen. Für den
schnellen Lese- und Verstellzugriff werden die Funktionalitäten der ETK Anbindung
für ECU-TEST genutzt. Die Fernsteuerung des INCA-Tools erfolgt über ein
Component-Object-Model (COM)-Interface, das auf objektorientierter Technologie
basiert. Das Interface besteht aus einer Liste von Pointern, die auf Methoden des
COM- Objekts zeigen.
Testsequenz
Fenster
Aktionen
Fenster
LOG Fenster
Abbildung 4 ECU-TEST Modul RegressionFür die Generierung von definierten schnellen transienten Vorgängen z.B. Spannungseinbrüchen ist es notwendig, mehrere Modellparameter in festgelegten Zeitschritten zu stimulieren. In ECU-TEST wurde dazu eine Option STIMULUS vorgesehen, damit lassen sich die in einem speziellen ControlDesk Editor erstellten Echtzeitsequenzen in ECU-Test importieren und auszuführen. Es ist möglich, mehrere Modellparameter parallel zu setzen und es können mehrere vordefinierte Signalverläufe gewählt werden z.B. Sägezahn, Sinus etc.. Außerdem können Matlab spezifische MAT- Files, z.B. um gemessene Fahrzyklen auszuführen, genutzt werden. Eine zusätzlich definierte Triggervariable ermöglicht die Synchronisation des Echtzeitrechners mit dem PC, das heißt der steigenden Flanke dieses Signals können verschiedene Aktionen zugeordnet werden, die dann auf dem PC ausgelöst und parallel zur Echtzeitsequenz berechnet werden. Damit ist es möglich mehrere SGBD- Jobs auszuführen und ASAP- Variablen zu messen bzw. zu lesen. So kann, während einer Echtzeitsequenz z.B. das richtige Zählen von Counter-Variablen überprüft werden. ECU-TEST erlaubt weiterhin das Schreiben und Lesen aller Modellgrößen. Über einen Modellbaum kann die gewünschte Modellgröße herausgesucht werden. Die gelesenen Werte werden mit vom Nutzer definierten Erwartungswerten verglichen. Als Utilitys sind hilfreiche Funktionen für die Testsequenzerstellung abgelegt. Es können z.B. LOOPS (Schleifen) oder WAIT (Warte) Funktionen ausgewählt werden. Diese zuvor genannten einzelnen Aktionen sind Testschritte, die in eine Testsequenz eingefügt werden. Einmal erstellte Testsequenzen können in einer selbst definierbaren Ordnerstruktur abgespeichert und wiederverwendet werden. Damit ist es möglich aus Standardbausteinen schnell neue Testsequenzen zu erstellen bzw. steuergerätespezifische Testsequenzen zu einem Test für einen neuen Softwarestandtest zusammenzufassen. Die Auswertung erfolgt nach dem durchgeführten Test in einem Excel-File. Dabei werden die Daten offline ausgewertet und verschiedene Analysen ausgeführt. Ausgewählte Daten werden grafisch in einem Diagramm dargestellt. Für jeden Schritt in der Testsequenz wird festgelegt , ob dieser erfolgreich oder fehlgeschlagen war. Der Nutzer legt bei der Testsequenzerstellung fest, inwieweit der einzelne Testschritt einen Einfluss auf das Gesamtergebnis nimmt. Zu dem Vergleich von gemessenen Werten mit erwarteten Werten besteht die Möglichkeit, unter anderem Sprunganalysen und Max/Min-Bestimmungen durchzuführen.
6.970 INCA-V Art Istwert Sollwert Bewertung Adresse
K_TVVLRUKS Verstellen 14,99961852 15 SUCCESS 0x857730
6.990 WAIT400
7.451 INCA-M Art Messung Relation Erwartung Bewertung Adresse
St_vvtlru.B_evvtlr Lesen FALSCH = 0SUCCESS 0x7fa134
7.511 WAIT4000
11.547 MotorModell Art Wert Bewertung Datentyp
FW1[%]-Value Schreiben 1 SUCCESS
11.547 WAIT500
12.077 MotorModell Art Wert Bewertung Datentyp
FW1[%]-Value Schreiben 100 SUCCESS
12.087 INCA-M Art Messung Relation Erwartung Bewertung Adresse
Cou_er_vlru Lesen 30< 30FAILED 0x7fa138
12.127 WAIT400
12.568 INCA-M Art Messung Relation Erwartung Bewertung Adresse
St_vvtlru.B_evvtlr Lesen FALSCH = 0SUCCESS 0x7fa134
12.588 WAIT1000
Abbildung 5 Auswertung Testschritte detailliert
200
180
160
140
120
Cou_vlru\ETKC-A
Cou_er_vlru\ETKC-A
100
Exw ink_soll\ETKC-A
Exw ink_ist\ETKC-A
80
60
40
20
0
1081
1216
1351
1486
1621
1756
1891
2026
2161
2296
2431
136
271
406
541
676
811
946
1
Abbildung 6 Auswertung grafisch4. Optimierte bzw. Automatische Testvektorgenerierung
Die manuelle Erstellung von Testsequenzen erfordert einen hohen Einsatz von Zeit
und Kreativität des Testers. Deshalb werden kombinatorische Algorithmen zur
optimierten Testvektorgenerierung untersucht. Weiterhin gibt es Überlegungen,
inwieweit formale Methoden bei der Generierung von Testvektoren aus
Spezifikationsmodellen verwendet werden können.
Heuristische Kombinatorik
Dieses Verfahren beruht auf dem Prinzip des Black-Box-Tests. Der Eingaberaum für
eine zu testende Funktion wird in einzelne Äquivalenzklassen eingeteilt, bei denen
davon ausgegangen werden kann, dass mit jedem Repräsentanten einer Klasse die
gleichen Fehler wie mit jedem anderen Repräsentanten dieser Klasse gefunden
werden (Äquivalenzklassenmethode). Wählt man nun Testpunkte an den Grenzen
einer Klasse, wird ein endlicher Eingaberaum definiert, indem für jeden
Eingangsparameter der zu testenden Funktion eine endliche Anzahl zu testender
Werte festgelegt wird. Werden nun alle Werte aller Parameter miteinander
kombiniert, wird durch das exponentielle Wachstum die Anzahl der zu testenden
Kombinationen zu groß, um alle Möglichkeiten in einer vertretbaren Zeit zu testen.
Deshalb wurde ein Zusatzmodul für ECU-TEST entwickelt, welches durch gezieltes
Wählen des Kombinationsgrades eine Quantitätsverringerung der Testvektoren-
anzahl bei hoher Funktionsabdeckung gewährleistet. Dies soll folgendes Beispiel
verdeutlichen: Es handelt sich um eine abstrahierte ASCET-
1000, 2000, 3000
nmot
nmot 0,1
1500, 1000, 750
leerl_Value
leerl_Value
15, 20, 30
tans
tans 0,1
B_SU
0,1 B_SU
80, 90, 110
tka
tka
60, 70, 80
rl
rl
Abbildung 7 ASCET Funktion
Funktion, wie sie in jedem Funktionsrahmen für ein Motorsteuergerät gefunden
werden kann. Es wird angenommen, dass die Funktion keine inneren Zustände
besitzt.n_mot leerl_Value tans tka rl
1000 1500 15 80 60
2000 1000 20 90 70
3000 750 30 110 80
Abbildung 8 Eingangsparameter mit gewählten Werten
Die Kombination aller Parameter und Werte miteinander liefert 35 und damit 243
Testvektoren. Im Gegensatz zu einem zufälligen Auswählen wird durch einen
speziellen Algorithmus sichergestellt, dass für einen gewählten Abdeckungsgrad für
jedes beliebige Tupel (Länge entspricht Abdeckungsgrad) der Eingangsparameter
jede mögliche Kombination der dazugehörigen Werte untereinander innerhalb der
generierten Testvektoren enthalten ist. Bei diesem kombinatorischen Algorithmus
wurde die Greedy-Strategie: „Bearbeite immer als nächstes den noch nicht erledigten
attraktivsten Teilbrocken des Problems“ angewendet. Der Übersicht wegen wird im
Programmablauf (Abbildung 10) nur der Algorithmus für die Zweifachabdeckung
dargestellt.
Wird dieses Verfahren nun auf die Eingangsparameter der Beispielfunktion
angewendet, werden 13 Testvektoren erzeugt, bei denen sichergestellt ist, dass für
jede beliebige Paarung der Eingangsparameter alle möglichen Wertekombinationen
innerhalb dieser 13 Testvektoren vorhanden sind. Bei einer Dreifachabdeckung
werden 41 Möglichkeiten generiert.
nmot leerl_Value tans tka rl Abgedeckte
Kombinationen
TV1 1000 1500 15 80 60 10
TV2 2000 1500 20 90 70 10
TV3 3000 1500 30 110 80 10
TV4 1000 1000 20 110 60 9
TV5 2000 1000 15 80 80 9
TV6 3000 1000 30 90 60 8
TV7 1000 750 30 80 70 9
TV8 3000 750 15 90 70 7
TV9 2000 750 20 110 60 6
TV10 1000 1000 20 90 80 4
TV11 3000 1000 20 80 70 4
TV12 2000 750 30 110 70 2
TV13 1000 750 15 110 80 2
Abbildung 9 Generierte Testvektoren Zweifach- Abdeckung
Nutzt man diese generierten Vektoren zu einem Test der Beispielfunktion, kann
schon mit 5,4% der möglichen Testfälle 100% der Funktion 1 und bei Annahme der
Gleichverteilung des Ausgangsbits der Funktion 1 werden auch 90,57% der
Eingangsmöglichkeiten der Funktion 3 getestet werden.Abbildung 10 Greedy Algorithmus Zweifach Abdeckung
1000, 2000, 3000 Funktionsabdeckung: 100%
bei zweifacher Parameterabdeckung
nmot
nmot 0,1
1 Funktionsabdeckung: 90,57%
1500, 1000, 750
(5,4% aller Kombinationen)
leerl_Value
leerl_Value
15, 20, 30
tans
tans 0,1
3 B_SU
0,1 B_SU
80, 90, 110
tka 2
tka
60, 70, 80 Funktionsabdeckung: 99,99%
(16,9 % aller Kombinationen)
rl
rl
Funktionsabdeckung: 100%
bei dreifacher Parameterabdeckung
Abbildung 11 Funktionsabdeckung
Bei dreifacher Abdeckung ist sichergestellt, dass es neben Funktion 1 auch bei
Funktion 2 zu einer 100% Funktionsabdeckung kommt. Bei einer Gleichverteilung
des Ausgangsbits kann dann auch für Funktion 3 eine 99,99%ige Abdeckung
angenommen werden ( Abbildung 11).
In [1] wird bewiesen, dass die Anzahl der generierten Testfälle nur logarithmisch mit
der Anzahl der Parameter wächst.
Viele Funktionen in Motorsteuergeräten besitzen jedoch auch innere Zustände.
Diese Heuristik muss daher insoweit verändert werden, dass Werte eines
bestimmten Parameters durch vorher identifizierte Signalverläufe ersetzt werden.
1. Literaturverzeichnis
[1] David M. Cohen, R. Dalal, Michael L. Fredman, Gardner C. Patton: The AETG
System An Approach to Testing Based on Combinatorial Design, IEE
TRANSACTIONS ON SOFTWARE ENGINEERING VOL.23, NO.7, July 1997,
S. 437-444
[2] R. Dalal, A. Jain, N. Karunanithi, B.M. Horowitz : Model-Based Testing in
Practice, ICSE ´99 Los Angeles CA, 1999 S. 285-294
[3] Sven Grabow: Implementierung der INCA- Funktionalitäten in ECU-TEST, TU
Dresden, IVK, Lehrstuhl Kraftfahrzeugelektronik und -elektrik, 2002
[4] Rocco Deutschmann: Systematischer Test von Motorsteuergeräten, TU
Dresden, IVK, Lehrstuhl Kraftfahrzeugelektronik und -elektrik, 2001Sie können auch lesen
