Replay-basiertes Testen von MOST-Bus-Anwendungen im Automotive-Umfeld
Holger Machens1, Reinhold Kr¨oger1, Sylvia Jell2, Klaus Grabenweger3 1Labor f¨ur Verteilte Systeme, Fachhochschule Wiesbaden,
Kurt-Schumacher-Ring 18, 65197 Wiesbaden machens, kroeger@informatik.fh-wiesbaden.de
2CT SE 1, Siemens AG Otto-Hahn-Ring 6, 81739 M¨unchen
sylvia.jell@siemens.com
3SV I IS RD AD SEI, Siemens VDO Automotive AG Otto-Hahn-Ring 6, 81739 M¨unchen
klaus.grabenweger@siemens.com
Abstract: Dieses Papier stellt ein Testsystem f¨ur Replay-basiertes Regressionstes- ten nachrichtenbasierter Anwendungen auf Bussystemen im Automotive-Umfeld vor.
Es basiert auf einem Capture-Replay-Verfahren f¨ur Nachrichtenverkehr zwischen An- wendungskomponenten und realisiert einen L¨osungsansatz f¨ur eine speziell in der be- trachteten Anwendungsdom¨ane der Feldbusse auftretende Besonderheit bzgl. des “Ru- heverhaltens” des zu testenden Systems. Das entwickelte Testsystem ber¨ucksichtigt aktuelle Standards f¨ur automatisiertes Testen und ist in ein generisches Rahmenwerk zur automatisierten Software-Qualit¨atssicherung eingebettet.
1 Einf¨uhrung
Heutige Fahrzeuge zeichnen sich durch einen hohen Anteil an digitalen Komponenten aus, die durch Bussysteme vernetzt sind. Neben Mehrzweckbussen wie beispielsweise CAN [Ets02a] hat sich f¨ur den Multimediabereich im Fahrzeug der MOST-Bus (Media Oriented Systems Transport) [Coo06] zur Vernetzung von Radio, Telefoneinheit, Naviga- tionssystem, R¨uckfahrkameras u.¨a. etabliert.
Hohe Komplexit¨at, bedingt durch viele vernetzte Komponenten, steigert allgemein die Fehlerwahrscheinlichkeit und den Testaufwand. Eine Effizienzsteigerung kann durch ei- ne Testautomatisierung erreicht werden. Hierzu geh¨oren beispielsweise Konformit¨atstests, generiert aus existierenden Entwurfsmodellen der Anwendung [Leg07], oder das Capture- Replay-Verfahren [Hus02] f¨ur Regressionstests, das in dem hier vorgestellten Ansatz Ver- wendung findet.
F¨ur das Capture-Replay-Verfahren wird allgemein zun¨achst ein Use Case ausgef¨uhrt und es werden Ereignisse (z.B. Nachrichtenverkehr) an definierten Interfaces im laufenden System (auch System Under Test, SUT) beobachtet und in einem Referenz-Log proto- kolliert. Die Nachrichten werden unterschieden in an das SUT gerichtete Stimuli und Re- aktionen darauf. Die Stimuli k¨onnen in der Replay-Phase wieder abgespielt werden. Im Falle von Regressionstesten werden dabei die Reaktionen des SUTs mit dem Referenz-Log verglichen, um automatisiert ein Testurteil (pass,fail,inconclusive) verfassen zu k¨onnen.
Auch kann man durch Replay das Kommunikationsverhalten nicht vorhandener System- teile simulieren, was als Restbussimulation [Gal99] bezeichnet wird.
Testsysteme werden allgemein in gr¨oßere Testplattformen eingebettet. Um Interoperabi- lit¨at zu gew¨ahrleisten, haben sich hier Standards wie TTCN-3 [ETS02b] und UML2TP [OMG04] etabliert, die Anwendungsmodelle und Austauschformate zwischen Testsyste- men spezifizieren. Basierend auf diesen Modellen existieren Testplattformen wie die des Eclipse Testing and Profiling Tools Projects (TPTP, ehem. Hyades), die UML2TP un- terst¨utzt. Ebenfalls wurde ein Vorgehensmodell f¨ur die von den TPTP-Projektpartnern so genannte automatisierte Softwarequalit¨atssicherung (ASQ) [Gro02] skizziert, das f¨ur den betrachteten Replay-Fall vereinfacht aus folgenden Phasen besteht:
1. Aufnahme eines Referenz-Logs (in TPTP auch Record genannt) f¨ur ein Replay.
2. Transformation des Referenz-Logs in eine Testdarstellung im Testmodell.
3. Editieren des Testmodells.
4. Generierung von Code zur Ausf¨uhrung der Stimuli und Validierung der Reaktionen.
5. Deployment und Ausf¨uhrung des Tests sowie Einsammeln von Ergebnissen.
6. Analyse der erhaltenen Logs und Testurteile.
Das hier beschriebene Testsystem realisiert eine Werkzeugkette f¨ur das Replay-basierte Testen einzelner Komponenten in verteilten, nebenl¨aufigen MOST-Bus-Anwendungen auf Basis von TPTP, eingegliedert in das oben skizzierte Vorgehensmodell. Ziele bei der Ent- wicklung waren die Evaluation der TPTP-Umgebung als Rahmen f¨ur Replay-basiertes Testen und die Anwendung der bekannten Capture-Replay-Verfahren auf MOST, letztlich auch zur Eruierung etwaiger Besonderheiten f¨ur das Replay im Automotive-Umfeld.
2 Anwendungsdom¨ane
Der MOST-Standard spezifiziert ein Anwendungsmodell, ein Kommunikationsprotokoll f¨ur die OSI-Schichten 1 bis 7, sowie Eigenschaften der unterlagerten Bus-Hardware. Das Anwendungsmodell f¨ur MOST-Anwendungen ist angelehnt an den von der IEC definier- ten Standard 61499 [Lew01]. Die Software besteht danach aus Function Blocks (FBs), die Schnittstellen implementieren, wie z.B. eine Kontrolleinheit f¨ur eine R¨uckfahrkamera.
Diese Schnittstellen erlauben synchrone und asynchrone Aufrufe an Methoden und of- ferieren implizit Operationen zum Setzen und Auslesen von Properties der FBs. Beides wird von der Middleware auf MOST-Nachrichten, sogenannte Control Messages, abge- bildet. Parallel dazu kann auf reservierten Bandbreiten des Busses synchrone oder asyn- chrone ¨Ubertragung von Multimediadaten erfolgen, was eine Besonderheit des MOST-
Busses darstellt. F¨ur die Evaluierung des Capture-Replay-Verfahrens in der beschriebenen Dom¨ane wurde zun¨achst auf die Einbeziehung von Multimediaverkehr verzichtet.
Instanzen der FBs sind auf Hardware-Einheiten, sogenannten MOST-Devices, installiert, die gemeinsam an der Busstruktur angebunden sind und MOST-Nachrichten austauschen.
Da s¨amtliche Kommunikation ¨uber den Bus geht, kann hier zentral ein Capturing erfolgen.
Die Verarbeitung von MOST-Nachrichten in einem Device ist implementierungsabh¨angig, erfolgt aber i.d.R. sequenziell.
Eine Besonderheit der beschriebenen Anwendungsdom¨ane, z.B. im Vergleich zu klassi- schen RPC-basierten verteilten Anwendungen, ist ihr “Ruheverhalten”, also der Zustand, in dem keine Eingaben in das System erfolgen. Das hier zu beobachtende Ruheverhalten zeichnet sich durch einen zyklischen Austausch von Statusmeldungen zwischen den FBs aus, der nicht von außen getriggert wird. Betrachtet man Ausschnitte des Verhaltens, so erh¨alt man aufgrund der Nebenl¨aufigkeit jeweils unterschiedliche Folgen von Nachrich- ten.
Ein ¨ahnliches Verhalten ist auch in anderen Feldbussystemen wie CAN oder FlexRay [Con05] zu beobachten. Das Prinzip, Zustandsmeldungen zyklisch auszutauschen und da- durch ein einheitliches Prozessabbild zu gew¨ahrleisten, hat seinen Ursprung in der Au- tomatisierungstechnik. Dort ist der zyklische Datenaustausch sogar meist Grundlage des Kommunikationsprotokolls und die azyklische, Event-basierte Kommunikation eher die Ausnahme, wie z.B. bei PROFIBUS [Ele02]. Die zyklische Kommunikation in MOST- Anwendungen wird auf Anwendungsebene realisiert. Das f¨uhrt zu dem als Besonderheit zu identifizierenden, unruhigeren Kommunikationsbild auf dem MOST-Bus, das u.a. durch sich zueinander verschiebende Sendezyklen gekennzeichnet ist.
3 Vorgehensweise
Abbildung 1: Capture-Replay-Vorgehensweise nach ASQ
Das Capture-Replay-Verfahren und die entwickelten Erweiterungen des Testsystems sind wie folgt in die o.a. ASQ-Phasen eingegliedert (vgl. Abb. 1 und 2). Nach der Erzeugung desReferenz-Logsdurch ein Capturing Tool (nicht Teil des Testsystems) am MOST-Bus erfolgt mit Hilfe eines Log Parserszun¨achst der Import des Referenz-Logs in Eclipse (Log Model) und durch einenImport Wizard die Transformation des Referenz-Logs in eine Testdarstellung imTest Model. Anschließend kann das Testmodell mit einem speziell erweitertenTest Editoreditiert werden (Edit) und der Code (Executable) desTest Drivers mit einemCode Generatorgeneriert (Generate) werden. Der Test Driver kann schließlich
ausgef¨uhrt (Execute) werden, wobei er Stimuli sendet und Reaktionen validiert (Validate).
Bei negativem Testausgang k¨onnen zur Analyse (Analyse) mittelsDiff ViewUnterschiede und ¨Ubereinstimmungen zwischen einem aufgenommenenTraceaus dem Replay und dem urspr¨unglichen Referenz-Log visualisiert werden.
Abbildung 2: Systemarchitektur (entwickelte Erweiterungen grau dargestellt)
Das f¨ur den Test irrelevante Ruheverhalten der MOST-Anwendungen macht einen direkten Vergleich der Reaktionen im Replay mit dem urspr¨unglichen Referenz-Log unm¨oglich.
Zur L¨osung dieses Problems kann der Benutzer im Editor die Sequenz der testrelevanten Nachrichten als “Validierungsmuster” definieren und f¨ur das verbleibende Ruheverhalten einen Filter anlegen, um dieses zu eliminieren.
Filter und Validierungsmuster werden mit dem Test Case im Testmodell assoziiert (vgl.
Abb. 3). Alle drei sind jeweils zus¨atzlich mit einer Liste von Nachrichten assoziiert: der Test Case mit den Nachrichten aus dem Referenz-Log, der Filter mit den Nachrichten des Hintergrundrauschens und das Validierungsmuster mit der Test-relevanten Nachrichtense- quenz. Eine Nachricht wird durch Attribute des Protokolls wie Sender, Empf¨anger, FB, Function, etc. und die ¨ubertragenen Nutzdaten wie Methoden-Parameter und R¨uckgabe- werte repr¨asentiert. Sowohl Filter als auch Validierungsmuster k¨onnen generalisiert wer- den, indem f¨ur jedes Attribut der Nachricht ein regul¨arer Ausdr¨uck eingesetzt wird. Die
¨Ubereinstimmung einer Nachricht mit solch einem ”Nachrichtenmuster” ist dann festge- stellt, wenn die oben genannten Attribute die zugeh¨origen regul¨aren Ausdr¨ucke erf¨ullen.
Abbildung 3: UML2TP basiertes Testmodell
Der Testeditor erlaubt die ¨Anderung aller Attribute einer Nachricht oder eines Nachrich- tenmusters, sowie der Reihenfolge der Nachrichten innerhalb des Validierungsmusters und des Test Cases. Auch das manuelle Hinzuf¨ugen oder L¨oschen von Nachrichten wird un- terst¨utzt.
Das zeitliche Verhalten, das in der Capturing-Phase in Form von Zeitstempeln festgehal- ten wurde, wird im Replay ber¨ucksichtigt, um z.B. das Verhalten eines Benutzers an den Bedienelementen des Fahrzeugs m¨oglichst realistisch nachzubilden. Dazu werden die ab- soluten Zeitstempel in die jeweiligen zeitlichen Differenzen zum vorangehenden Ereignis umgerechnet. Im Editor besteht dann die M¨oglichkeit, solche Zeitdifferenzen individuell anzupassen. Im Replay werden die Zeitdifferenzen genutzt, um den Sendezeitpunkt eines Stimulus oder zusammen mit einem globalen Timeout die maximal zul¨assige Reaktions- zeit des Systems auf einen Stimulus festzulegen.
Ein Filter verwirft eine Nachricht, wenn er eine ¨Ubereinstimmung mit einem ihm zuge- ordneten Nachrichtenmuster entdeckt. Die Validierung w¨ahrend der Ausf¨uhrung erfolgt anhand des Validierungsmusters einschließlich der durch die definierten regul¨aren Aus- dr¨ucke eingef¨uhrten Variabilit¨at und setzt die erfolgreiche Herausfilterung des Ruheverhal- tens voraus. Sind alle Nachrichten des Validierungsmusters in der erwarteten Reihenfolge aufgetreten, gilt der Test als erfolgreich (pass), wohingegen das Auftreten unerwarteter Nachrichten als Fehler beurteilt wird (fail). Falls weder pass noch fail eintritt, (z.B. nur Ruheverhalten auftritt), gilt der Test als unentscheidbar (inconclusive).
Abbildung 4: Experimentalumgebung
Das beschriebene Testsystem wurde in einer Experimentalumgebung von Siemens VDO getestet (vgl. Abb. 4). Dabei wurden zwei OptoLyzer-Ger¨ate [SMS06] von SMSC als zus¨atzliche MOST-Devices eingesetzt: Ein Device diente dem Testtreiber zum Senden und Empfangen von Stimuli und Reaktionen, das andere wurde zum parallelen Capturing ver- wendet. Das SUT bestand aus einer Telefoneinheit als MOST-Device, die ¨uber Bluetooth mit einem Mobiltelefon (TCU) verbunden war.
In dieser Experimentalumgebung wurden Test Cases wie der Rufaufbau mit dem Mobilte- lefon getestet. Durch das parallele Capturing stand ein Log zur Verf¨ugung, der zus¨atzlich im Diff View auf Unterschiede zum Referenz-Log untersucht werden konnte.
4 Ergebnisse und Ausblick
Das vorgestellte Testsystem erlaubt Replay-basiertes Regressionstesten einzelner Kompo- nenten in einer MOST-Anwendung und ist f¨ur den Einsatz im Kontext von Automotive-
Anwendungen konzipiert. Das Ruheverhalten in MOST-Anwendungen, das nach bisheri- gen Erfahrungen bis zu drei Viertel des Verkehrsaufkommens ausmacht, wird dabei durch ein spezielles, auf regul¨aren Ausdr¨ucken basierendes Verfahren herausgefiltert, um die Be- urteilung des Systemverhaltens im Replay zu gew¨ahrleisten.
Bei Tests stellte sich heraus, dass das Verfahren dem Testentwickler viel Arbeit bei der De- finition von Testf¨allen und der Entwicklung von Testtreibern abnehmen kann. Die Auswahl der testrelevanten Ereignisse erfordert aber immer noch eine besondere Sorgfalt. Dabei steigt der Aufwand mit zunehmender L¨ange des Testfalls innerhalb eines Logs. Gleich- zeitig steigt aber auch mit der L¨ange eines Logs die Wahrscheinlichkeit, dass anhand ei- ner einzigen Aufnahme das Hintergrundrauschen hinreichend beschrieben werden kann.
Dar¨uberhinaus ist die generelle M¨oglichkeit der Nachbesserung und Wiederverwendung von Filtern, auch f¨ur andere Testf¨alle im gleichen System, f¨ur diesen Fall von Vorteil.
Als weiterer Vorteil f¨ur die Praxis wurde identifiziert, dass ein bestehender Filter zu ei- nem existierenden System auch zum Auffinden der Test-relevanten Ereignisse in einem Referenz-Log geeignet ist.
Die Verl¨asslichkeit des Testurteils ist allgemein vergleichbar mit gew¨ohnlichen Kompo- nententests, da der beobachtete Nachrichtenaustausch nichts anderes als die Folge der Ein- und Ausgaben an der Schnittstelle einer Komponente, hier einer Function-Block-Instanz, ist. Ver¨anderungen an der Systemkonfiguration haben nat¨urlich Auswirkungen auf den Testfall, sobald sie das an der beobachteten Schnittstelle sichtbare Verhalten der getes- teten Komponente beeintr¨achtigen. Dar¨uber hinaus gibt es bei dem vorgestellten Ansatz den Umstand, dass sich das Hintergrundrauschen bei ¨Anderung der Zusammensetzung des SUT, z.B. durch Hinzuf¨ugen einer zuvor unbekannten Komponente, ¨andern kann und der Filter entsprechend einmalig angepasst werden muss.
Die Testplattform TPTP erwies sich als reichhaltige Grundlage f¨ur die Entwicklung des Testsystems und stellte den gr¨oßeren Anteil der verwendeten generischen Komponenten.
Die Erweiterung der TPTP-Basiskomponenten um spezifische Applikationsteile war auf- grund der Quelloffenheit und der offenen Architektur von Eclipse und TPTP weitgehend problemlos. In Zahlen belief sich der Aufwand auf ca. 25.000 Zeilen Java Code.
Da CAN-Bus- und FlexRay-Anwendungen im Austausch von Zustandsmeldungen ein
¨ahnliches Verhalten wie MOST-Bus-Anwendungen aufweisen, auch wenn die Zyklen in der Kommunikation insbesondere auf FlexRay durch statische Vorplanung kaum Instabi- lit¨at aufweisen, ist die prinzipielle Eignung des Verfahrens f¨ur diese und ¨ahnliche Busse aus dem Automotive-Bereich gegeben. Anpassungen des Testsystems w¨aren erforderlich, um eine Abbildung der dort verwendeten Nachrichtenstrukturen in das Testmodell zu er- halten, einen entsprechenden Testeditor zu realisieren und einen geeigneten Testtreiber zu generieren. Die ¨Anderungen daf¨ur belaufen sich sch¨atzungsweise auf 5.000 Zeilen Code.
Dar¨uber hinaus gehende Unterschiede, wie z.B. der planbare Verkehr auf FlexRay- oder CAN-Bussen, w¨aren u.U. gewinnbringend zu integrieren.
Als Erweiterung des Prototypen w¨are die Einbeziehung der parallel ¨ubertragenen Multi- media-Daten in den Regressionstests m¨oglich, um weitere Informationen zur Beurteilung des Test Cases nutzen zu k¨onnen.
Dieser Arbeit ging eine Studie voraus, die Ans¨atze f¨ur das Replay von nebenl¨aufigen,
verteilten Anwendungen im CORBA-Umfeld untersuchte, worin auch Mengen von Kom- ponenten als SUT betrachtet und auch der interne Nachrichtenverkehr im SUT bei der Testbeurteilung ber¨ucksichtigt wurde. Die dort entwickelten Konzepte k¨onnen in einem n¨achsten Schritt in das vorgestellte Testsystem integriert werden. Damit l¨asst sich der An- wendungsbereich auf komplexe Szenarien im MOST-Umfeld erweitern.
Danksagung: Wir bedanken uns f¨ur die konstruktiven Diskussionen im Projekt und das Mitwirken an dieser Ver¨offentlichung bei folgenden Mitarbeiten von Siemens CT SE 1:
Andrej Pietschker, Horst Sauer, Andreas Ulrich und Peter Zimmerer.
Literatur
[Con05] Flexray Consortium.FlexRay Communications System - Protocol Specification. October 2005.
[Coo06] MOST Cooperation.MOST Specification. MOST Cooperation, September 2006.
[Ele02] PROFIBUS Workinggroup Electromechanics.PROFIBUS Technology and Application - System Description. PROFIBUS Nutzerorganisation e.V., Germany, Karlsruhe, Oktober 2002.
[Ets02a] Konrad Etschberger.CAN Controller Area Network - Grundlagen, Protokolle, Bausteine, Anwendungen. Hanser, Leipzig, Deutschland, April 2002.
[ETS02b] ETSI.The Testing and Test Control Notation version 3. ETSI, France, Dezember 2002.
[Gal99] Thomas Galla. Cluster Simulation in Time-Triggered Real-Time Systems. Dissertation, Technische Universit¨at Wien, Austria, 1999.
[Gro02] Hyades Group. The Hyades Project Automated Software Quality for Eclipse. Eclipse, Dezember 2002.
[Hus02] Joel Huselius. Debugging Parallel Systems - A State of the Art Report. M¨alardalens University, V¨asteras, Sweden, September 2002.
[Leg07] Mark Utting; Bruno Legeard. Practical Model-Based Testing: A Tools Approach.
Morgan-Kaufmann, 2007.
[Lew01] Robert Lewis.Modelling control systems using IEC 61499 - Applying function blocks to distributed systems. The Institution of Electrical Engineers, United Kingdom, Dez. 2001.
[OMG04] OMG.UML 2 Testing Profile Specification. Object Management Group, April 2004.
[SMS06] SMSC.OptoLyzer Professional - Tool Platform for Analysis and Simulation. 2006.
