Hardware-in-the-Loop-Test verteilter Kfz-Elektroniksysteme
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Hardware-in-the-Loop-Test verteilter Kfz-
Elektroniksysteme
Peter Wältermann, Herbert Schütte, Klaus Diekstall
dSPACE GmbH
Mit seiner umfassenden Lösungskompetenz im Bereich HIL-Simulation bietet dSPACE
maßgeschneiderte Simulatoren für den Verbundtest im Rahmen der funktionalen Absi-
cherung der Elektronik ganzer Fahrzeugplattformen. Durch den konsequenten Einsatz
von standardisierten Hardware- und Software-Komponenten und die hierauf aufsetzen-
de systematische Testautomatisierung können die hohen Qualitätsansprüche des Fahr-
zeugherstellers prozesssicher erfüllt werden.
Autoren:
Dr.-Ing. Peter Wältermann ist Gruppenleiter im Bereich Applications/Engineering der dSPA-
CE GmbH.
Dr.-Ing. Herbert Schütte ist Leiter des Bereichs Applications/Engineering der dSPACE
GmbH.
Dipl.-Ing. Klaus Diekstall ist Leiter der Abteilung Kundenspezifische Simulator-Hardware
der dSPACE GmbH.
1 Einleitung Neue Funktionen für mehr Sicherheit, geringere Umweltbelastung und mehr Komfort werden in modernen Fahrzeugen zu 90% durch elektronische Steuergeräte ermöglicht. Die wachsende Anzahl von Steuergeräten und der Datenaustausch über CAN und LIN ermöglichen es, Sen- sordaten und steuergeräteinterne Größen mehrfach zu nutzen und komplexe Funktionen über mehrere Steuergeräte zu verteilen. Der Fahrzeughersteller hat hierbei die Verantwortung für das Gesamtsystem Fahrzeug und das Zusammenspiel der von verschiedenen Zulieferern stammenden Steuergeräte. Um dieser Verantwortung gerecht zu werden, müssen die Steuergeräte im Verbund getestet werden, be- vor sie im Fahrzeug verbaut werden. Der vorliegende Beitrag beschreibt, ausgehend von der grundsätzlichen Problemstellung „Test des Steuergeräte-Verbunds“, die angewandte Hardware-in-the-Loop (HIL)-Technologie (vgl. auch [1]) und ihre Vorteile gegenüber konventionellen Testmethoden (z. B. Brettaufbau- ten). Geeignete Hardware- und Software-Lösungen werden ebenso dargestellt wie die Pro- zessintegration beim OEM. Letztere ist von entscheidender Bedeutung für den erfolgreichen Einsatz der HIL-Technologie in der täglichen Praxis. Bild 1 zeigt schematisch die für eine umfassende Lösungskompetenz notwendigen Teildisziplinen, durch deren Beherrschung Si- mulatoren für die spezifischen Einsatzgebiete und Anwendungsszenarien projektiert und ge- baut werden können. Bild 1: Schlüsselfertige Verbundsimulatoren erfordern übergreifende Kompetenzen aus einer Hand.
2 Verteilte Steuergeräte-Architekturen Bild 2 zeigt eine Steuergeräte-Architektur, wie sie typischerweise in einem Fahrzeug der O- berklasse zu finden ist. Häufig kommen hier mehr als 50 (Mittelklasse ca. 30) Steuergeräte zum Einsatz, die über verschiedene Signalbusse (CAN, LIN, MOST etc.) miteinander gekop- pelt sind und Informationen austauschen. Bild 2: Typische Steuergeräte-Architektur eines Oberklassenfahrzeugs: Powertrain- und Body Electronics-CAN-Bus sowie Infotainment-Bus. Vergegenwärtigt man sich, dass hier Hunderte verteilter Funktionen in unterschiedlichsten Ausstattungs- und Ländervarianten (teilweise mit geschlossenen Regelschleifen) zum Einsatz kommen, wird sehr schnell klar, dass manuelle Tests im Fahrzeug oder am Brettaufbau kaum die notwendige Testabdeckung bieten, um die Qualitätsansprüche der Endkunden zu befriedi- gen. Daher gehört inzwischen der automatisierte Verbundtest am HIL-Simulator zum Stand der Technik. Der Test verteilter Funktionen, die Möglichkeit zum Schließen dynamischer Regel- kreise, das schnelle Zu- und Wegschalten von Steuergeräten (für Ausstattungs- und Länderva- rianten) sowie das gleichzeitige Überwachen aller Steuergeräte-Pins und aller Bussysteme sind nur einige Vorteile dieser Technologie.
3 Problemstellungen beim Test des Steuergeräte-Verbunds
Beim Test des Steuergeräte-Verbunds lassen sich immer wieder ähnliche Problemklassen
identifizieren, für die nachfolgend Lösungen vorgestellt werden.
3.1 Test verteilter Funktionen
Der Test verteilter Funktionen stellt ein wichtiges Anwendungsgebiet der HIL-Simulation dar.
Beim VW Phaeton sind beispielsweise bis zu 12 Steuergeräte unterschiedlicher Hersteller
beteiligt, wenn das Fahrzeug per Funkfernbedienung entriegelt wird [2].
Im Antriebsstrang sind die Momenten- oder Drehzahlführung des Motors durch die Getriebe-
steuerung oder der Eingriff der Fahrdynamikregelung (ESP) wichtige sicherheitskritische
Funktionen, die intensiv im Labor getestet werden müssen. Gerät beispielsweise ein Fahrzeug
beim Beschleunigen auf eine Eisfläche, so verzögert die im ESP integrierte Antriebsschlupf-
regelung das Fahrzeug durch das Anbremsen der Räder, gleichzeitig werden über CAN
Botschaften zur Momentenreduktion an das Motorsteuergerät gesendet, das diese Anforde-
rung durch Zündwinkelrücknahme und Schließen der Drosselklappe in wenigen Millisekun-
den umsetzt.
Zum Test dieser Antriebsstrangfunktionen im Labor werden folgende Lösungen benötigt:
• Dynamische Modelle für Motor, Getriebe, Antriebsstrang sowie Fahrdynamik: Um diese
Modelle zu simulieren, benötigt man leistungsfähige Prozessorkarten, die mit Abtastraten
von
Bild3: Das DS1006 Processor Board für die Simulation dynamischer Modelle und das DS2211 HIL I/O Board (mit winkelsynchroner Signalerfassung und -generierung) als Ba- sis für verschiedenste HIL-Testsysteme. Tabelle 1: Eingangs- und Ausgangsgrößen eines DS2211 HIL I/O Boards
3.2 Test der Buskommunikation (CAN, LIN, etc.) Eine wesentliche Voraussetzung für den Verbundtest besteht in der Überwachung der Kom- munikation zwischen den Steuergeräten (CAN, LIN etc.). Hier sind das Verhalten im Normalbetrieb, aber insbesondere im Fehlerfall, z. B. bei Ausfall eines Teilnehmers, fehler- haftem Botschafteninhalt oder elektrischen Fehlern (Kurzschlüsse) auf den Busleitungen, be- sonders wichtig. Werden spezifische Steuergeräte zunächst getrennt untersucht oder sind beim Verbundtest noch nicht alle Steuergeräte vorhanden, so wird die dynamische Restbussimulation eingesetzt, bei der die fehlenden Busteilnehmer vom HIL-Simulator emuliert werden. Dazu muss die gesamte Kommunikation auf Basis der CAN- oder LIN-Datenbasis (einschließlich der Signal- skalierungen) gemeinsam mit dem dynamischen Verhalten spezifiziert werden können, z. B. in MATLAB®/Simulink® (Bild 4). Hier sind häufig einige hundert Nachrichten und Tausende von Signalen zu berücksichtigen. Bild 4: Blockbibliotheken zur Definition/Spezifikation/Parametrierung der I/O-Funktionalität des Testsystems in MATLAB®/Simulink®. Zur gezielten Untersuchung des Netzwerks im Fehlerfall hat sich die Signalmanipulation mit- tels eines Fehler-Gateways bewährt, bei dem die Busleitungen eines Teilnehmers auf einen Fehlerbus des Simulator geschaltet, die Nachrichten bei Bedarf manipuliert und dann auf dem Original-CAN-Bus zurückgespielt werden. So lassen sich Änderungen einzelner CAN- Signale (z. B. Prüfsummen), ganzer Nachrichten (Ausfall, falsches Timing) oder sogar der komplette Ausfall eines Teilnehmers darstellen und der Einfluss auf das Restnetzwerk über- prüfen (vgl. [3]).
3.3 Test des Netzwerkmanagements Aus der großen Anzahl an Steuergeräten resultieren erhöhte Anforderungen hinsichtlich des Netzwerkmanagements und des Stromverbrauchs der einzelnen Steuergeräte. Nach dem Abstellen des Fahrzeugs müssen die Steuergeräte in einen Sleep-Modus versetzt werden, in dem sie ihren Strombedarf auf ein Minimum (typisch < 300µA) reduzieren; mo- derne Steuergeräte sind heute mit speziellen CAN-Transceivern (z. B. Philips TJA1041) oder separaten Weckleitungen ausgestattet, um andererseits auch jederzeit wieder aktiviert werden zu können. Aufgrund der hohen Busvernetzung und der damit einhergehenden verteilten Funktionalitäten gelingen diese Übergänge nur bei korrekter Funktion aller an der Buskommunikation beteilig- ten Geräte. Eine wirkliche Überprüfung dieser Netzwerkfunktionalität ist deshalb nur im Ver- bund aller Steuergeräte (also beim OEM) möglich. Wie wichtig diese Überprüfung ist, zeigt sich im „Flughafentest“, bei dem Fahrzeuge mit Fehlfunktionen im Netzwerkmanagement nach ein- bis zweiwöchigem Abstellen wegen entladener Batterie nicht mehr gestartet werden können. Die eingesetzten HIL-Simulatoren müssen sich auf dem CAN-Netzwerk neutral verhalten; deshalb werden sie mit CAN-Transceivern ausgestattet, die identisch mit den Transceivern der zu testenden Steuergeräte sind. Eine reine Überprüfung von Busaktivitäten ist allerdings noch kein hinreichendes Kriterium, den korrekten Sleep-Modus einzelner Steuergeräte zu überprüfen. Vielmehr wird die Stromaufnahme jedes beteiligten Steuergeräts vermessen und als Indikator für den ordnungsgemäßen Wechsel der Betriebszustände herangezogen. Das dafür benötigte PowerSwitch-Modul (Bild 5) misst über ein hochgenaues Messwerk den gesamten Versorgungsstrom eines Steuergeräts. Fünf unterschiedliche Messbereiche zwi- schen 1,25 mA und 50 A mit automatischer und manueller Bereichsumschaltung ermöglichen sowohl eine präzise Ruhestrommessung als auch die genaue Erfassung der Betriebsströme in unterschiedlichen Betriebsmodi. Die Konfiguration und das Auslesen der Messwerte erfolgen über einen eigenen CAN-Bus. Bild 5: PowerSwitch-Modul zur Messung der Betriebsströme (im Ampere-Bereich) und der Ruheströme (im µA-Bereich) der Steuergeräte im Netzwerk. Die einzelnen Steuergeräte werden über verschiedene Klemmen (KL30, KL15, KL87, ...) versorgt, die zu unterschiedlichen Zeiten eingeschaltet werden. Daher wird die Nachbildung dieser Klemmen ebenfalls auf dem PowerSwitch-Modul durch Leistungsschalter realisiert (vgl. Kapitel 3.4).
3.4 Test bei unterschiedlichen Ausstattungs- und Ländervarianten
Neben den verteilten Funktionen und dem Netzwerkmanagement sind beim Verbundtest ins-
besondere unterschiedlichste Ausstattungs- (von der Basis- bis zur Vollausstattung) und Län-
dervarianten (Links- und Rechtslenker, gesetzliche Regelungen) zu berücksichtigen. Darüber
hinaus werden die Fahrzeuge mit unterschiedlichen Motoren (Zylinderzahl, Diesel oder Ben-
ziner) und Getrieben (Handschalter, Stufenautomat, stufenlos) sowie mit oder ohne ESP aus-
gerüstet.
Unterschiedliche Steuergeräte bzw. Steuergeräte-Varianten müssen miteinander korrekt arbei-
ten (Positivtest), anderenfalls dürfen sie teilweise gar nicht miteinander arbeiten (Negativtest,
insbesondere bei sicherheitskritischen Anwendungen). Für den Verbundtest lässt sich daraus
ableiten, dass unterschiedlichste Steuergeräte- bzw. Bus-Topologien automatisiert hergestellt
werden müssen, d. h. ohne Änderung der Verkabelung.
Das Zu- und Abschalten der Steuergeräte-Versorgungsleitungen erfolgt mittels des o. g. Po-
werSwitch-Moduls oder einfacher Relais, während die CAN-Topologie über ein CAN-
Matrix-Modul variabel umgeschaltet wird. Der Einsatz dieser Module erlaubt neben der Kon-
figuration beliebiger CAN- oder LIN-Subnetze und dem Aufschalten von Abschlusswider-
ständen auch die elektrische Fehlersimulation auf den CAN-Leitungen (vgl. Kapitel 3.5).
3.5 Elektrische Fehlersimulation
Um die Diagnosefunktionalität und das Verhalten des gesamten Verbunds bei elektrischen
Fehlern zu überprüfen, können alle I/O-Pins der angeschlossenen Steuergeräte einer elektri-
schen Fehlersimulation (Fault Insertion Unit, FIU) unterzogen werden.
Nachfolgend aufgeführte Fehlerbedingungen können über elektrische Fehlersimulationskarten
simuliert werden:
• Leitungsunterbrechungen
• Harte Kurzschlüsse und Schlüsse über variable Ableitwiderstände gegen verschiedene,
im Fahrzeug vorhandene Potenziale (KL30, KL15, KL31, KL50 usw.), wahlweise
mit/ohne angeschlossener Last
• Variable Leitungswiderstände zwischen Steuergerät und Aktuator-/Sensor-Pin
• Schlüsse zwischen Signalleitungen, sowohl als harte Kurzschlüsse, als auch mit vari-
ablem Widerstand
Aufgrund gestiegener Anforderungen an die elektrische Fehlersimulation bietet dSPACE in-
zwischen die dritte Generation von FIU-Systemen an, die über einen CAN-Bus gesteuert wer-
den.
In ControlDesk implementierte GUI-Komponenten ermöglichen dem Anwender die Defini-
tion und das Aufschalten von Fehlern über eine grafische Oberfläche (Bild 6). Fehlerhafte
Benutzereingaben könnten hier zur Beschädigung von Steuergeräten oder nicht dauerkurz-
schlussfesten Lasten führen. Deshalb werden alle Eingaben automatisch gegen vordefinierte
Fehlerklassen überprüft und nur die „erlaubten“ Fehler simuliert.
Außerdem lassen sich interaktiv erzeugte Fehlermuster abspeichern und direkt in automati-
schen Tests (vgl. Kapitel 4) anwenden.Bild 6: FIU-Komponente in ControlDesk, der Experiment-Software von dSPACE, zur inter- aktiven Bedienung der Fehlersimulation. Der zulässige Maximalstrom eines Fehlerkanals beträgt 8 A. Die Fehlersimulation auf Last- kanälen mit höheren Fehlerströmen wird durch Parallelschaltung mehrerer Kanäle realisiert; auch hier übernimmt der interne Prüfmechanismus ohne zusätzlichen Anwendereingriff die parallele Ansteuerung der Kanäle, um Kanalüberlastungen sicher auszuschließen. 4 Testautomatisierung Erst durch eine systematische Automatisierung und eine geeignete Strukturierung und Wie- derverwendung von Tests sind die angestrebten Ziele bezüglich Testtiefe und Testbreite, und somit letztlich hinsichtlich der Qualität, erreichbar. Während Testautomatisierungsanwendun- gen bisher häufig in Programmiersprachen kundenspezifisch entwickelt wurden, kommen mittlerweile auch höherwertige, generische Testautomatisierungstools (AutomationDesk, vgl. Bild 7) zum Einsatz. Gegenüber den bisherigen Lösungen erlauben sie eine grafische Tester- stellung ohne Programmierkenntnisse. Weitere Vorteile sind ein integriertes Testmanagement, ein leistungsfähiger Mechanismus zur Erstellung von eigenen Testbibliotheken, eine Ergeb- nisverwaltung und eine integrierte Reportgenerierung. Während Tests der On-Board- Diagnose (OBD II) häufig bereits an Komponentenprüfständen für einzelne Steuergeräte durchgeführt werden, ist der automatisierte Test verteilter Funktionen erst am Verbundsimula- tor möglich.
Bild 7: Integrierte Testumgebung AutomationDesk [4]. 5 Integration in den Entwicklungsprozess Wie aus Bild 8 beispielhaft hervorgeht, planen Automobilhersteller heute typischerweise 36 bis 42 Monate für die Entwicklung eines neuen Fahrzeugs ein. Ein Hardware-in-the-Loop- Integrationstest der bis zu 70 Steuergeräte ist in diesem Entwicklungsprozess bei vielen OEMs zu einem festen Bestandteil geworden, um die Elektrik/Elektronik-Qualität sicherzu- stellen. Bild 8: Projektplan zur qualitativen zeitlichen Einplanung des HIL-Testsystems in den Gesamtentwicklungsprozess eines Fahrzeugherstellers (OEM). Besonders hervorzuheben ist in diesem Zusammenhang, dass schon frühzeitig, d. h. idealer- weise parallel zur Erstellung der Steuergeräte-Lastenhefte ein enger Kontakt zum Lieferanten
des HIL-Testsystems genutzt wird, um den Funktionsumfang des Simulators festzulegen. Weiterhin sind interne Bestelllaufzeiten beim OEM (ca. 1 Monat) und die Projektierungs- und Produktionszeit beim HIL-Systemlieferanten (ca. 3 bis 5 Monate) im Projektplan zu berück- sichtigen, damit das Testsystem zeitgleich mit den ersten Prototyp-Steuergeräten geliefert werden kann. Der HIL-Systemlieferant ist somit sehr eng in die Entwicklungsprozesse des OEMs eingebunden und muss seine eigenen Strukturen und Prozesse hierauf konsequent ab- stimmen, damit das Testsystem für die gesamte B- und C-Muster-Testphase zur Verfügung steht. Der Testsystemlieferant muss zudem in der Lage sein, einen extrem hohen Verfügbar- keitsgrad des Systems sicherzustellen, damit besonders in Übergangsphasen (z. B. vom B- zum C-Muster, vgl. Zeile 16 in Bild 8) durch Umbauten und Ergänzungen des Simulators keine unnötigen Verzögerungen entstehen. Auch die Erstellung der automatischen Tests kann schon während der Projektierung des Ver- bundtestsystems (Zeile 9 in Bild 8) (ggf. noch früher) begonnen werden und sollte ebenfalls konsequent in den Projektplänen berücksichtig werden. Eine optimale Effizienz kann erreicht werden, wenn der Steuergeräte-Zulieferer sein Einzel- steuergerät bereits mit einem HIL-Simulator getestet hat, der sich als „Teiltestsystem“ im Verbundsimulator des OEMs wiederfindet (Bild 9). Neben einem reduzierten zeitlichen und finanziellen Aufwand bei der Erstellung des Verbundtestsystems selbst ergeben sich hier- durch zusätzliche Synergien bei der Entwicklung und der Nutzung der automatischen Tests, d. h. zum Beispiel, dass Tests, die am Einzelsteuergerät bereits durchgelaufen sind, am Ver- bundsimulator wiederverwendet werden können oder aber als redundante Tests unnötig sind. Bild 9: Zusammenarbeit zwischen Automobilhersteller (OEM), Steuergeräte- und Testsys- tem-Zulieferer. 6 Beispiele für realisierte Verbundsimulatoren Die wachsende Bedeutung des Themas „Test des Steuergeräte-Verbunds“ lässt sich auch an der steigenden Anzahl von Veröffentlichungen zu diesem Thema festmachen. So sind An- wendungen aus den Bereichen Antriebsstrang und Innenraum bei Opel [3], Audi [5, 6], Fi- at/Elasis [7] sowie aus dem Rennsport [8] bekannt geworden. Ein aktuelles und technisch besonders anspruchsvolles Projekt stellt der in Bild 10 dargestell- te Verbundsimulator für den Antriebsstrang des Bugatti Veyron 16.4 dar, einem Sportwagen mit 1001 PS (736 kW) und einer Höchstgeschwindigkeit von mehr als 400 km/h. Aufgrund der geringen Serienstückzahlen dieses Fahrzeugs stehen nur sehr wenige Prototypen für Steu-
ergeräte-Tests zur Verfügung. Daher wurde hier konsequent auf die HIL-Technologie gesetzt
[9]. Das Netzwerk besteht aus folgenden Komponenten:
Zwei Motorsteuergeräte für den 16-Zylinder-Motor (Bosch ME9 in Master/Slave-
Konfiguration)
Steuergerät für ein 7-Gang-Doppelkupplungsgetriebe
ESP-Steuergerät
Allrad-Steuergerät
Kombi-Instrument
Für diese Konfiguration wurde ein Simulator entwickelt, der sowohl Einzelsteuergeräte- als
auch Verbundtests erlaubt, je nach Konfiguration der CAN-Topologie (vgl. Kapitel 3.3
und 3.4). Die MATLAB®/Simulink®-Modelle für die Closed-Loop-Simulation wurden von
der Volkswagen-Entwicklung (Motor und Getriebe), von TESIS, München, (Fahrdynamik)
und von dSPACE (Sensorik, Aktorik, CAN) entwickelt und anschließend gemeinsam integ-
riert.
Bild 10: HIL-Simulator für den Test des Steuergeräte-Verbunds des Bugatti Veyron 16.4. Die
interaktive Bedienung erfolgt über ControlDesk, die 3D-Animation des Fahrverhaltens mit
dem Tool MotionDesk.
Heute eingesetzte Verbundsimulatoren besitzen bis zu neun Racks und unterstützen 40 bis
50 Steuergeräte mit über 2000 Pins, 4 bis 5 CAN-Busse (ca. 6000 CAN-Signale) und ver-
schiedene LIN-Sub-Busse. Das Titelbild dieses Beitrags zeigt einen Teil eines solchen Sys-
tems.7 Literaturhinweise
[1] Schütte, H.; Schütte, F.; Thomsen, T.: Echtzeitsysteme für die Motorenentwicklung.
In: Modellgestützte Steuerung, Regelung und Diagnose von Verbrennungsmotoren,
Isermann, R. (Hrsg.), Springer-Verlag, Berlin, 2003.
[2] Kille, P.; Rewald, H.; Dierker, U.; Kluge, J.; Oldening, J.; Leohold, J.: VW Phaeton:
Das elektrische Bordnetz. ATZ/MTZ-Sonderausgabe: VW Phaeton, Juli 2002.
[3] Köhl, S.; Lemp, D.; Plöger, M.; Otterbach, R.: Steuergeräteverbundtests mittels Hard-
ware-in-the-Loop-Simulation. ATZ 10/2003, S. 948.
[4] Lamberg, K.; Richert, J.; Rasche, R.: A new Environment for Integrated Development
and Management of ECU Tests. Society of Automotive Engineers, SAE Paper No.
2003-01-1024.
[5] Gehring, J.; Schütte, H.: Automated Test of ECUs in a Hardware-in-the-Loop Test
Bench for the validation of Complex ECU Networks. Society of Automotive Engi-
neers, SAE Paper No. 2002-01-0801.
[6] James, A.; Rudolph, M.; Gehring, J.; Pöhlmann, T.: Hardware-in-the-Loop bei Audi-
Antriebssträngen. ATZ 4/2002.
[7] Plöger, M.; Sauer, J.; Büdenbender, M.; Held, J.; Costanzo, F.; de Manes, M.; di Mare,
G.; Ferrara, F.; Montieri, A.: Testing Networked ECUs in a VirtualCar Environment.
Society of Automotive Engineers, SAE Paper No. 2004-01-1724.
[8] Urban, P.; Wältermann, P.; Henking, B.: Toyota Motorsport mit dSPACE auf der Ü-
berholspur. Automotive Engineering Partners 6/2001, S. 40.
[9] Baeker, W.; Lichtenthäler, D.: Bugatti: Starke Tests für starke Autos. dSPACE News
01/2004, dSPACE GmbH, Paderborn (www.dspace.de).Sie können auch lesen
