Hardware-in-the-Loop-Test verteilter Kfz- Elektroniksysteme

Transkript

1 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 Absicherung der Elektronik ganzer Fahrzeugplattformen. Durch den konsequenten Einsatz von standardisierten Hardware- und Software-Komponenten und die hierauf aufsetzende systematische Testautomatisierung können die hohen Qualitätsansprüche des Fahrzeugherstellers 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.

2 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, Sensordaten 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, bevor 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. Brettaufbauten). Geeignete Hardware- und Software-Lösungen werden ebenso dargestellt wie die Prozessintegration 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 Simulatoren für die spezifischen Einsatzgebiete und Anwendungsszenarien projektiert und gebaut werden können. Bild 1: Schlüsselfertige Verbundsimulatoren erfordern übergreifende Kompetenzen aus einer Hand.

3 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 gekoppelt 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 befriedigen. 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 Regelkreise, das schnelle Zu- und Wegschalten von Steuergeräten (für Ausstattungs- und Ländervarianten) sowie das gleichzeitige Überwachen aller Steuergeräte-Pins und aller Bussysteme sind nur einige Vorteile dieser Technologie.

4 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 Getriebesteuerung 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 Antriebsschlupfregelung das Fahrzeug durch das Anbremsen der Räder, gleichzeitig werden über CAN Botschaften zur Momentenreduktion an das Motorsteuergerät gesendet, das diese Anforderung durch Zündwinkelrücknahme und Schließen der Drosselklappe in wenigen Millisekunden 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 <= 1 ms die dynamischen Modelle abarbeiten. So ermöglicht das neue DS1006 Processor Board mit einem derzeit auf 2,2 GHz getakteten AMD Opteron Prozessor (x86- Technologie) die Berechnung eines Mittelwert-Motormodells, eines Bremshydraulik- und eines Fahrdynamikmodells einschließlich kompletter I/O für Motor- und ESP- Steuergeräte in weniger als 350 µs. Für noch komplexere Modelle oder die Verkopplung mehrerer Simulatoren lassen sich diese Prozessorkarten zu verteilten Multiprozessor- Systemen vernetzen. I/O-Hardware für hochdynamische Signalverarbeitung: Bei der Motorsimulation müssen Kurbel- und Nockenwellen- sowie Klopfsignale motorwinkelsynchron erzeugt werden, Einspritz- und Zündsignale wiederum winkelsynchron eingemessen werden. Für diese Aufgabenstellung kommt im Allgemeinen Spezial-Hardware zum Einsatz, zum Beispiel das in der Automobilindustrie breit eingeführte DS2210/DS2211 HIL I/O Board (Bild 3 und Tabelle 1). Das kaskadierbare Board stellt auf engstem Raum die gesamte I/O zur Verfügung, zum Beispiel für einen 8-Zylinder-Motor inklusive Signalkonditionierung. Zudem kann mit zwei Betriebsspannungen bis 60 Volt gearbeitet werden (Nutzfahrzeuge und Zweispannungsbordnetz). Einfache I/O-Schnittstellen und komplexe winkelsynchrone Funktionen lassen sich gemeinsam mit dem dynamischen Modell in MATLAB /Simulink spezifizieren und im Testbetrieb konfigurieren. Diese Kombination aus Prozessorkarte und HIL I/O Board bildet inzwischen die Basis für Hunderte von HIL-Testsystemen weltweit.

5 Bild3: Das DS1006 Processor Board für die Simulation dynamischer Modelle und das DS2211 HIL I/O Board (mit winkelsynchroner Signalerfassung und -generierung) als Basis für verschiedenste HIL-Testsysteme. Tabelle 1: Eingangs- und Ausgangsgrößen eines DS2211 HIL I/O Boards

6 3.2 Test der Buskommunikation (CAN, LIN, etc.) Eine wesentliche Voraussetzung für den Verbundtest besteht in der Überwachung der Kommunikation zwischen den Steuergeräten (CAN, LIN etc.). Hier sind das Verhalten im Normalbetrieb, aber insbesondere im Fehlerfall, z. B. bei Ausfall eines Teilnehmers, fehlerhaftem Botschafteninhalt oder elektrischen Fehlern (Kurzschlüsse) auf den Busleitungen, besonders 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 Signalskalierungen) 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 mittels 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 überprüfen (vgl. [3]).

7 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; moderne 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 beteiligten Geräte. Eine wirkliche Überprüfung dieser Netzwerkfunktionalität ist deshalb nur im Verbund 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 zwischen 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).

8 3.4 Test bei unterschiedlichen Ausstattungs- und Ländervarianten Neben den verteilten Funktionen und dem Netzwerkmanagement sind beim Verbundtest insbesondere unterschiedlichste Ausstattungs- (von der Basis- bis zur Vollausstattung) und Ländervarianten (Links- und Rechtslenker, gesetzliche Regelungen) zu berücksichtigen. Darüber hinaus werden die Fahrzeuge mit unterschiedlichen Motoren (Zylinderzahl, Diesel oder Benziner) und Getrieben (Handschalter, Stufenautomat, stufenlos) sowie mit oder ohne ESP ausgerüstet. Unterschiedliche Steuergeräte bzw. Steuergeräte-Varianten müssen miteinander korrekt arbeiten (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. PowerSwitch-Moduls oder einfacher Relais, während die CAN-Topologie über ein CAN- Matrix-Modul variabel umgeschaltet wird. Der Einsatz dieser Module erlaubt neben der Konfiguration beliebiger CAN- oder LIN-Subnetze und dem Aufschalten von Abschlusswiderstä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 elektrischen 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 variablem Widerstand Aufgrund gestiegener Anforderungen an die elektrische Fehlersimulation bietet dspace inzwischen die dritte Generation von FIU-Systemen an, die über einen CAN-Bus gesteuert werden. In ControlDesk implementierte GUI-Komponenten ermöglichen dem Anwender die Definition 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 dauerkurzschlussfesten 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 automatischen Tests (vgl. Kapitel 4) anwenden.

9 Bild 6: FIU-Komponente in ControlDesk, der Experiment-Software von dspace, zur interaktiven Bedienung der Fehlersimulation. Der zulässige Maximalstrom eines Fehlerkanals beträgt 8 A. Die Fehlersimulation auf Lastkanä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 Wiederverwendung von Tests sind die angestrebten Ziele bezüglich Testtiefe und Testbreite, und somit letztlich hinsichtlich der Qualität, erreichbar. Während Testautomatisierungsanwendungen 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 Testerstellung ohne Programmierkenntnisse. Weitere Vorteile sind ein integriertes Testmanagement, ein leistungsfähiger Mechanismus zur Erstellung von eigenen Testbibliotheken, eine Ergebnisverwaltung 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 Verbundsimulator möglich.

10 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 sicherzustellen. 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. idealerweise parallel zur Erstellung der Steuergeräte-Lastenhefte ein enger Kontakt zum Lieferanten

11 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ücksichtigen, 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 abstimmen, 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ügbarkeitsgrad 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 Verbundtestsystems (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 Einzelsteuergerä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 hierdurch 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 Verbundsimulator wiederverwendet werden können oder aber als redundante Tests unnötig sind. Bild 9: Zusammenarbeit zwischen Automobilhersteller (OEM), Steuergeräte- und Testsystem-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 Anwendungen aus den Bereichen Antriebsstrang und Innenraum bei Opel [3], Audi [5, 6], Fiat/Elasis [7] sowie aus dem Rennsport [8] bekannt geworden. Ein aktuelles und technisch besonders anspruchsvolles Projekt stellt der in Bild 10 dargestellte 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-

12 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 integriert. Bild 10: HIL-Simulator für den Test des Steuergeräte-Verbunds des Bugatti Veyron 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 CAN-Signale) und verschiedene LIN-Sub-Busse. Das Titelbild dieses Beitrags zeigt einen Teil eines solchen Systems.

13 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, [2] Kille, P.; Rewald, H.; Dierker, U.; Kluge, J.; Oldening, J.; Leohold, J.: VW Phaeton: Das elektrische Bordnetz. ATZ/MTZ-Sonderausgabe: VW Phaeton, Juli [3] Köhl, S.; Lemp, D.; Plöger, M.; Otterbach, R.: Steuergeräteverbundtests mittels Hardware-in-the-Loop-Simulation. ATZ 10/2003, S [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 [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 Engineers, SAE Paper No [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 [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 (