Automatisierter Closed-Loop-Softwaretest eingebetteter Motorsteuerfunktionen

Automatisierter Closed-Loop-Softwaretest eingebetteter Motorsteuerfunktionen Sven Rebeschieß, Thomas Liebezeit, Uzmee Bazarsuren Abstract We present a workflow for automatic software testing of embedded systems which was defined during the SiLEST joint project. The aim is to conduct software-in-theloop tests at an early stage on a cost-effective, reproducible, retraceable and automatic basis. The central element of automated testing is the new test sequence control built up in SiLEST. It links various standard tools, e.g. TestDirector (as test management system), Matlab / Simulink (as simulator) and StarTeam (as version management system). An open interface concept allows the connection to other or more programs. Test cases are defined by using the specially developed test case generator and are filed in XML format. A focus of testing lies in the examination of the effects of the off-nominal behavior of sensors and actuators on the complete system. Models of sensors and actuators come from the extendable Simulink block library SALib ( Sensors and Actuators Library ) that we have developed. Zusammenfassung Wir stellen einen im Rahmen des Verbundprojekts SiLEST definierten Workflow für den automatisierten Softwaretest eingebetteter Systeme vor. Ziel ist die Durchführung frühzeitiger, kostengünstiger, wiederholbarer, rückverfolgbarer und automatischer Software-in-the-Loop-Tests. Das zentrale Element dafür ist die im SiLEST-Projekt entwickelte Testablaufsteuerung, die die automatische Kopplung diverser Standardtools, wie beispielsweise TestDirector (als Testverwaltung), Matlab / Simulink (als Simulator) und StarTeam (als Versionsverwaltung) realisiert. Das offene Schnittstellenkonzept ermöglicht die Anbindung anderer bzw. weiterer Programme. Testfälle werden mit dem selbst erstellten Testfall-Editor definiert und im XML-Format abgespeichert. Ein Schwerpunkt der Tests liegt bei der Untersuchung der Auswirkungen des Fehlerverhaltens von Sensoren und Aktuatoren auf das Gesamtsystem. Entsprechende Sensor- und Aktuatormodelle stammen aus der von uns entwickelten, erweiterbaren Simulink-Bibliothek SALib ( Sensors and Actuators Library ). 1. Einleitung Der Aufwand für die Validierung von Softwaresystemen, die in ein technisches Umfeld eingebettet sind (Embedded Software), beträgt oftmals bis zu 50% des gesam-

ten Entwicklungsaufwands. Trotzdem ist ein fehlerhaftes Verhalten solcher mechatronischer Systeme nicht gänzlich auszuschließen, insbesondere dann nicht, wenn z. B. altersbedingte Verschleißerscheinungen die Hardwareumgebung verändern (vgl. die steigende Anzahl von Rückrufaktionen im Automobilsektor). Die Verbesserung des Testprozesses für Software eingebetteter Systeme bietet daher einerseits ein hohes Einsparpotential bei den Entwicklungskosten und andererseits eine Steigerung der Produktqualität. Im Rahmen des Verbundvorhabens SiLEST 1 (Software-in-the-Loop for Embedded Software Test, vgl. [1]) wird untersucht, welches Potential der Softwaretest eingebetteter Systeme innerhalb einer simulierten Umwelt besitzt. Es sollen die Einsatzmöglichkeiten und -grenzen des Software-in-the-Loop- (SiL-) Testverfahrens ermittelt werden mit dem Ziel, frühzeitig, kostengünstig, wiederholbar, rückverfolgbar und automatisch in-the-loop zu simulieren. Zudem wird ein Vergleich mit dem etablierten Hardware-in-the-Loop- (HiL-) Testverfahren vorgenommen, um Vor- und Nachteile beider Methoden herauszuarbeiten und gegenüberzustellen. Dieser Beitrag definiert zunächst unser Verständnis vom Begriff Software-in-the- Loop. Anschließend werden die SiL-Testumgebung, das SiL-Testmodell sowie der eigentliche SiL-Test beschrieben. Dieses sind die wesentlichen Bestandteile des automatisierten Test-Workflows, der im Rahmen des SiLEST-Projekts entwickelt wurde. Eine Darstellung des aktuellen Projektstatus sowie ein Ausblick auf die nächsten Si- LEST-Aktivitäten runden den Artikel ab. 2. Definition von SiL Zur Abgrenzung des Begriffs Software-in-the-Loop dienen die folgenden Abbildungen, die vier Arten von Closed-Loop-Simulations-Systemen gegenüberstellen: Model-in-the-Loop (Abbildung 1a), Software-in-the-Loop (Abbildung 1b), Processor-inthe-Loop (Abbildung 1c) und Hardware-in-the-Loop (Abbildung 1d). Regler- (ECU-) Modell Umgebungsmodell Abbildung 1a: Model-in-the-Loop (MiL) 1 Das Vorhaben SiLEST wird im Rahmen der Forschungsoffensive Software Engineering 2006" mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 01ISC12A gefördert. Projektpartner sind neben IAV GmbH (Berlin) und TU Berlin / MDT auch DLR / SISTEC (Braunschweig), FhG / FIRST (Berlin) und webdynamix GmbH (Cottbus). Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren.

Bei einem Model-in-the-Loop- (MiL-) System liegen sowohl die Regelalgorithmen, welche später auf dem Steuergerät (ECU) laufen sollen, als auch die Umgebung in Form von Simulationsmodellen vor, die beispielsweise aus Simulink- oder ASCET- Blockdiagrammen gebildet sind. Für das Motormanagement eines Kraftfahrzeugs bildet beispielsweise eine zweistufige Aufladung einen Regelalgorithmus. Das Umgebungsmodell besteht dann u.a. aus Motor, Fahrzeugdynamik und Umwelt. Die wesentliche Charakteristik der späteren ECU, z. B. das Taskmanagement, die Fixed- Point-Arithmetik sowie die I/O-Schnittstellen, sind je nach benötigtem Detaillierungsgrad ebenfalls modelliert. Simuliert wird auf einem einzigen Rechner, beispielsweise einem PC. Die Simulation muss deshalb nicht in Echtzeit erfolgen. C-Code auf PC Umgebungsmodell Abbildung 1b: Software-in-the-Loop (SiL) Beim Software-in-the-Loop- (SiL-) System dagegen liegen die Regelalgorithmen und die ECU-Funktionalität in Form von automatisch oder per Hand generiertem C-Code vor. Das Umgebungsmodell unterscheidet sich nicht von dem des MiL-Systems. Die gesamte Simulation erfolgt wiederum auf einem einzigen Simulationsrechner, z. B. einem PC, und muss somit nicht zwangsläufig echtzeitfähig sein. C-Code auf Target-nahem Prozessor (Evaluationsboard) Umgebungsmodell Abbildung 1c: Processor-in-the-Loop (PiL) Die Processor-in-the-Loop- (PiL-) Simulation unterscheidet sich von der SiL-Simulation dadurch, dass der C-Code auf einer Target-nahen Hardware, z. B. einem Evaluationsboard mit dem Zielprozessor, gerechnet wird. Das Umgebungsmodell ist wie-

der dasselbe wie in den vorhergehenden Fällen und wird auf dem Simulationsrechner berechnet. Die Kommunikation zwischen beiden Rechnern erfolgt typischerweise noch nicht über die späteren Schnittstellen. Auch hier ist die Echtzeitfähigkeit kein absolutes Muss, so lange beide Rechner dieselbe Zeitbasis verwenden und der eine Rechner die Systemzeit des anderen manipulieren kann (vgl. Start-Stopp-Betrieb in [2]). C-Code auf ECU Umgebungsmodell Abbildung 1d: Hardware-in-the-Loop (HiL) Bei der Hardware-in-the-Loop- (HiL-) Simulation wird der C-Code mit den Regelalgorithmen auf der Original-ECU gerechnet. Hier ist die Simulation in Echtzeit unerlässlich. Deshalb muss das Umgebungsmodell auf einem echtzeitfähigen Simulationssystem gerechnet werden. Im Gegensatz zu den obigen Umgebungsmodellen werden hier üblicherweise die Sensoren, Aktuatoren und Bussysteme nicht nachgebildet, da sie als Echtteile oder elektrische Ersatzlasten im Gesamtsystem vorliegen. Der Begriff Software-in-the-Loop wird in der Literatur vielfältig verwendet und recht dehnbar gehandhabt. Er deckt teilweise die gesamte Bandbreite von MiL über SiL bis hin zu PiL ab. Auch im SiLEST-Projekt wird versucht, dieser Vielfältigkeit des SiL-Begriffs gerecht zu werden. Im Rahmen von SiLEST behandeln deshalb IAV und TU Berlin schwerpunktmäßig die oben dargestellten Bereiche MiL und SiL, die Projektpartner DLR und FhG dagegen hauptsächlich die Bereiche SiL und PiL. 3. SiL-Testumgebung Die SiL-Testumgebung von SiLEST besteht im wesentlichen aus der Testverwaltung, dem Testsystem und der Versionsverwaltung (vgl. Abbildung 2). Aus der Testverwaltung werden neue Tests angewiesen. Zudem stellt sie den Zugang zu den einzelnen Tests und deren Ergebnissen bereit. Sie beantwortet somit die Frage: Wer hat wann, was, mit welchem Ergebnis getestet. Das Testsystem besteht aus der Testablaufsteuerung, die die Automatisierung von Tests ermöglicht und die Einhaltung eines definierten Testprozesses gewährleistet, dem Simulator, der die Simulationen durchführt, sowie dem eigentlichen Testmodell. Die Versionsverwaltung übernimmt die Versionierung aller im Rahmen des Test- Workflows verwendeten Dateien, um eine vollständige Reproduzierbarkeit zu gewährleisten. Dieses umfasst sowohl die Dateien des Testmodell- und des Testfall- Repositories als auch die automatisch generierte Testdokumentation.

Testsystem (Testablaufsteuerung, Simulator, Prozessorboard, Testmodell,...) Testverwaltung Versionsverwaltung Arbeitsplatz des Testingenieurs Ethernet Testmodell-Repository Testfall-Repository Testdokumentation Abbildung 2: Hardware-Topologie der SiL-Testumgebung Die Bedienung erfolgt vom Arbeitsplatz des Testingenieurs aus. Die in der Abbildung 2 dargestellten Rechner müssen nicht zwangsläufig separate Geräte sein. Gewisse Funktionen können auch auf ein und demselben Rechner realisiert sein. 4. SiL-Testmodell Der SiL-Test basiert auf der Nutzung der Simulation und untersucht das Verhalten der implementierten Steuergerätesoftware. In einem Testmodell wird dafür der zu validierende Steuergerätecode in ein Closed-Loop-Modell aus Steuergerät und Umgebung integriert. Die zu testenden Funktionen nehmen somit aus ihrer Umgebung Informationen auf und üben selbst Einfluss auf diese aus. Das in der Abbildung 3 dargestellte SiL-Testmodell besteht aus: dem Steuergerätemodell mit Motorsteuerfunktionen (z. B. zweistufige Aufladung), Steuergerätecharakteristik (z. B. Scheduler, Fixed-Point-Arithmetik) und Schnittstellen zur Umgebung (I/O) sowie der Umgebung mit Modellen für Fahrzeug (z. B. Motor, Getriebe, Längsdynamik), Fahrer, Umwelt (z. B. Straßenbelag, Steigung, Wind), Sensorik (S) und Aktuatorik (A). Das SiLEST-Testmodell zeichnet sich dabei durch drei Besonderheiten aus: Das Modell kann die zu testenden Funktionen gleichzeitig oder ausschließlich auf zwei unterschiedliche Weisen einbinden: Erstens in Form der ausführba-

ren Spezifikation (wie bei MiL) und zweitens als fertigen Steuergerätecode (wie bei SiL). Im Gegensatz zur HiL-Simulation wird hier das Steuergerät inklusive seiner I/O-Schnittstellen durch ein Modell nachgebildet. Auch Sensorik und Aktuatorik werden modelliert und besitzen ein Nominal- sowie ein Fehlerverhalten. Fehler können mittels geeigneter Parametrierung zur Laufzeit zu- und abgeschaltet werden. Scheduler I Steuergerätemodell Funktionsmodul 1 O... O A A Umgebungsmodell Fahrzeug, Motor, Getriebe,...) S S I Funktionsmodul N O Fahrer Umwelt Abbildung 3: SiL-Testmodell 5. SiL-Test Das Ziel der SiL-Tests ist die frühzeitige Validierung von bereits integrierten Softwarekomponenten im geschlossenem Regelkreis. Dabei wird vorausgesetzt, dass im Unterschied zu den sich anschließenden Hardware-in-the-Loop-Tests noch nicht auf die vollständig als C-Code vorliegende Steuergeräte-Funktionalität zurückgegriffen werden kann. Deshalb werden beim Test-Workflow von SiLEST nur die bereits codierten Software- Bestandteile in Verbindung mit der ausführbaren Spezifikation noch fehlender Funktionen und dem Umgebungsmodell simuliert. Auf diese Weise lassen sich bereits im frühen Entwicklungsstadium automatisierte Regressionstests durchführen, bei denen der aktuelle Softwarestand auf sein statisches und dynamisches Systemverhalten hin untersucht werden kann. Der Ablauf eines SiL-Tests im Test-Workflow von SiLEST umfasst die Testauswahl, die Testerstellung, die automatische Testdurchführung und die automatische Testauswertung. Diese Schritte werden im Folgenden näher beschrieben. 5.1 Testauswahl Zunächst ist ein zu untersuchendes Testmodell aus dem Testmodell-Repository auszuwählen. Dieses ist eng verknüpft mit der Testkonfiguration, die den Systemaufbau für die gewählte Testmethode (MiL, SiL, PiL, HiL) beschreibt. Für die Closed-Loop- Simulation fehlende Komponenten und Testkonfigurationen müssen wie im nächsten Kapitel beschrieben neu erstellt werden.

Die Auswahl der Testfälle für den jeweiligen Test erfolgt aus der Gesamtheit der im Testfall-Repository definierten Nutzungs- und Fehlerszenarien. Noch nicht definierte Testfälle müssen ebenfalls erstellt werden. 5.2 Testerstellung Die Testerstellung unterteilt sich in die Erstellung des Testmodells, der Testkonfiguration sowie der Testfälle: 5.2.1 Erstellung des Testmodells Testmodelle werden komponentenweise (vgl. z. B. die Aufteilung in Abbildung 3) erstellt und in einem Testmodell-Repository abgelegt. Aus den Einzelkomponenten wird dann ein Closed-Loop-Modell gebildet. Im Rahmen von SiLEST setzen wir folgende Eigenentwicklungen der IAV ein: Task- Control für die Verwaltung von Prozessen unter Simulink, Soft-ECU zum rudimentären Nachbilden der wichtigsten Motorsteuergerätefunktionalitäten, THEMOS für Motormodelle, VeLoDyn für die Getriebe-, Fahrzeug-Längsdynamik-, Fahrer- und Umwelt-Modellierung sowie SALib für die Modellierung von Sensoren und Aktuatoren. All diesen Tools ist gemeinsam, dass es sich um Simulink-Blockbibliotheken handelt. TaskControl und SALib wurden im Rahmen von SiLEST von uns entwickelt. 5.2.2 Erstellung der Testkonfiguration Ein wesentliches Ziel von SiLEST besteht in der Weiter- und Wiederverwendung von Testfällen. Die Weiterverwendung reduziert den Aufwand für die Erstellung neuer Testfälle, während die Wiederverwendung einen Vergleich der erzielten Ergebnisse mit denen anderen Testmethoden zulässt. Aus diesem Grunde wird ein SiLEST- Testfall mittels zweier XML-Dateien definiert. Die Testkonfiguration beschreibt die Ein- und Ausgänge des Testsystems, auf dem die Simulation durchgeführt wird, in abstrakter Form. Sie ist an die jeweilige Testmethode, wie beispielsweise MiL, SiL, PiL oder HiL, anzupassen, jedoch für alle Testfälle einer Testsuite identisch. Die Testkonfiguration wird in einem SiLEST-spezifischen XML-Format gespeichert. Der eigentliche Testfall dagegen ist identisch, egal welche Testmethode aktuell eingesetzt wird. 5.2.3 Erstellung der Testfälle Die Testfälle werden ebenso wie die Testkonfiguration mit dem im SiLEST-Projekt erstellten Testfall-Editor definiert und in einem Testfall-Repository abgelegt. Mehrere Testfälle bilden eine Testsuite. Aufgrund des verwendeten, SiLEST-spezifischen XML-Formats ist es möglich, Testfälle aus verschiedenen Ansätzen (z. B. Blackbox-, Whitebox-Tests) heraus zu erstellen. Hierfür sollten möglichst Tools zur automatischen Testfall-Generierung, wie z. B. MOTCaseX von der IAV, verwendet werden.

Typischerweise handelt es sich bei den im Automotive- sowie im Raumfahrt-Anwendungsbereich von SiLEST untersuchten Funktionen um Regler aus Steuergeräten, die abgetastete analoge Signale verarbeiten. Dementsprechend ist auch das Testfall- Format von SiLEST definiert. Ein Testfall beinhaltet u. a.: Eine von der Standard-Kalibration abweichende Bedatung von Steuergeräteund Umgebungsmodell, die Eingangsverläufe (Vorgaben) und Events (Fehler, Ausfälle) für das Testmodell sowie die zu überwachenden Ausgänge mitsamt den Parametern des Ähnlichkeitsmaßes (vgl. unten) für die automatische Testauswertung. Das Sollverhalten der Ausgänge muss im Testfall nicht explizit beschrieben werden, wenn es im Testmodell von einem Referenzmodell basierend auf der ausführbaren Spezifikation erzeugt wird. Die Testfälle des SiL-Tests setzen sich aus zwei grundsätzlichen Klassen zusammen: Die erste Klasse umfasst Testfälle, die das Nominalverhalten der Software für gängige Eingangsverläufe untersuchen. Die in der zweiten Klasse definierten Testfälle betrachten das Softwareverhalten bei einer Fehlfunktion der Sensorik und / oder Aktuatorik bzw. der I/O-Ports des Steuergeräts. Das SiLEST-Testfall-Format wird detailliert in [3] beschrieben. 5.3 Testdurchführung Für die Durchführung von Regressionstests ist ein automatisierter Ablauf von Bedeutung, der nach dem Starten ohne jede weitere Interaktion selbstständig vom Testsystem zum geplanten Zeitpunkt ausgeführt wird. Das zentrale Element dafür ist die im SiLEST-Projekt entwickelte Testablaufsteuerung. Diese Java-Applikation koppelt diverse kommerzielle bzw. freie Standardtools, wie beispielsweise TestDirector bzw. Testmaster (als Testverwaltung), Matlab / Simulink (als Simulator) und StarTeam bzw. Subversion (als Versionsverwaltung). Das offene Schnittstellenkonzept ermöglicht die Anbindung anderer bzw. weiterer Programme. Der prinzipielle Ablauf eines Tests in SiLEST ist in der Abbildung 4 dargestellt. Der Anstoß für den Test erfolgt aus der Testverwaltung heraus (1). Die Testablaufsteuerung übernimmt die automatische Abarbeitung der übergebenen Testfälle auf dem Testsystem, wozu sie die Testkonfiguration nutzt (2, 3). Dazu werden automatisch der Simulator geöffnet, das Testmodell geladen, die Simulation initialisiert und durchgeführt. Anschließend erfolgt eine automatische Auswertung der Simulation. Als Ergebnis entstehen je Testfall ein XML-Testreport inkl. Grafiken und ein Testresultat (vgl. unten) (4). Über einen Konverter werden der Testreport und die Grafiken in das anschaulichere PDF-Format gewandelt (5, 6). Der PDF-Testreport und das Testresultat werden von der Testablaufsteuerung (7) an die Testverwaltung zurückgeliefert, wo die Ergebnisse aller Tests durch die Versionsverwaltung übersichtlich dargestellt werden (8).

Abbildung 4: Ablauf der Testdurchführung 5.4 Testauswertung Am Ende der Simulation liegen die Ergebnisse in Form von Ausgangsverläufen vor. Diese werden in der automatischen Testauswertung mit ihrem Referenzverhalten aus der Testfall-Definition oder aus der ausführbaren Spezifikation verglichen. Der dafür eingesetzte Vergleichsalgorithmus analysiert sowohl Abweichungen im Amplitudenverhalten (Schranken- und Bändertests) als auch zeitliche Abweichungen (Dynamic Time Warping). Über ein Ähnlichkeitsmaß, dessen Parameter Teil der TestfallDefinition sind, wird dann eine automatische Entscheidung über die Gleichheit beider Signalverläufe getroffen. Dabei sind die Testurteile Passed bei korrektem Ergebnis sowie Failed bei inkorrektem Ergebnis möglich (vgl. Abbildung 5). Inconclusive Passed / Ergebnisse korrekt / Vorbedingungen nicht erfüllt / Absturz Disposed / Initialisierung Aborted / Ergebnisse inkorrekt / Vorbedingungen nicht erfüllt / Automatische Auswertung / Absturz / Ausführung Running Failed Executed Abbildung 5: Während der Testdurchführung durchlaufene Zustände

Daneben können weitere Testurteile auftreten, die anzeigen, dass der Testfall nicht komplett durchlaufen wurde bzw. abgestürzt ist: Ganz zu Beginn der Testdurchführung befindet sich der Testfall im Zustand Disposed. Sind nicht alle Vorbedingungen zur Durchführung des Testfalls erfüllt, so gibt es das Testurteil Inconclusive. Nach erfolgreicher Initialisierung des Testmodells wird der Zustand Running eingenommen. Stellt die Testablaufsteuerung den Absturz des Simulators fest, so erhält der Testfall das Testurteil Aborted. Nach der Durchführung der Simulation, allerdings vor der Auswertung der Ergebnisse befindet sich der Testfall im Zustand Executed. Die erzielten Ergebnisse werden für jeden Testfall in einem automatisch generierten Testreport festgehalten. Dieser enthält sowohl das Testurteil als generelle Aussage über die Einhaltung des Referenzverhaltens als auch sämtliche Ausgangsvektoren. Die Resultate des Ähnlichkeitsmaßes werden gleichfalls dokumentiert. Die Ergebnisse werden dabei zur anschaulichen Darstellung mittels Grafiken aufbereitet. Zusätzlich werden die Versionsnummern des verwendeten Testfalls, der Testkonfiguration, des Testmodells und aller Modellbibliotheken mit in den Testreport aufgenommen. Damit wird eine vollständige Dokumentation und Wiederholbarkeit des Tests ermöglicht. Aufgrund der Ausgabe der Testreporte im XML-Format ist eine spätere maschinelle Weiterverarbeitung der Daten möglich (vgl. beispielsweise die oben beschriebene Erzeugung eines PDF-Reports). 6. Projektstatus und Ausblick Im Rahmen des Verbundprojekts SiLEST haben wir zusammen mit unseren Projektpartnern aus dem Raumfahrt-Sektor einen Workflow für den automatisierten Softwaretest eingebetteter Systeme definiert und erfolgreich implementiert. Die Testablaufsteuerung als zentrales Element des Test-Workflows liegt als Prototyp vor und wird aktuell an der Motorsteuerungsfunktion Zweistufige Aufladung sowie der Lageregelung eines Kleinsatelliten zur Hot-Spot-Erkundung erprobt. Ein Schwerpunkt der Tests in SiLEST liegt bei der Untersuchung der Auswirkungen des Fehlerverhaltens von Sensoren und Aktuatoren auf das Gesamtsystem. Aus diesem Grunde wurde ein erweiterbares Bibliotheks-Konzept entwickelt, das es erlaubt, mittels geeigneter Parametrierung während der Simulationslaufzeit zwischen dem Nominal- und dem Fehlerverhalten von Sensoren und Aktuatoren umzuschalten. Daraus ist die Simulink-Bibliothek SALib hervorgegangen, die gängige Sensor- und Aktuatormodelle aus dem Automotive-Sektor beinhaltet. Der Testfall-Editor zur komfortablen Eingabe von Testkonfigurationen und Testfällen, die im XML-Format abgespeichert werden, hat sich bereits jetzt bewährt. Seine Bedienung erfordert keinerlei XML-Kenntnisse. Die Erprobung des SiLEST-Test-Workflows in einem realen Kundenprojekt steht noch aus. Sie wird zeigen, inwieweit sich das Ziel frühzeitiger, kostengünstiger, wiederholbarer, rückverfolgbarer und automatischer Software-in-the-Loop-Tests in der Praxis realisieren lässt.

Abkürzungsverzeichnis ECU HiL MiL PiL SALib SiL XML Electronic Control Unit Hardware-in-the-Loop Model-in-the-Loop Processor-in-the-Loop Sensors and Actuators Library Software-in-the-Loop Extensible Markup Language Literatur [1] www.silest.de. SiLEST-Projektseite [2] O. Maibaum, S. Rebeschieß. Test von adaptiven Softwaremechanismen zur Fehlerkompensation, 2. Tagung Simulation und Test in der Funktions- und Software-Entwicklung für die Automobilelektronik, 14.3.-15.3.2005 [3] Th. Liebezeit, H. Schumann, S. Rebeschieß, U. Bazarsuren. XML-Format für den automatischen Software-in-the-Loop-Test, 26 th Automotive Electronics Conference Elektronik im Kraftfahrzeug, 27.6.-28.6.2006

Autoren: Dipl.-Ing. Sven Rebeschieß, IAV GmbH / Abt. MS-T43, Carnotstr.1, 10587 Berlin, Tel.: 030/ 39978-9550, Fax: 030/ 39978-9299, Email: sven.rebeschiess@iav.de Dr.-Ing. Thomas Liebezeit, TU Berlin / MDT, Einsteinufer 17, 10587 Berlin, Tel.: 030/ 314-23950, Fax: 030/ 314-22120, Email: thomas.liebezeit@tu-berlin.de Dipl.-Ing. Uzmee Bazarsuren, TU Berlin / MDT, Einsteinufer 17, 10587 Berlin, Tel.: 030/ 314-25612, Fax: 030/ 314-22120, Email: uzmee.bazarsuren@tu-berlin.de