Paper for Download - FKFS
Paper for Download - FKFS
Paper for Download - FKFS
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Virtual Prototyping in der Hardware- und Software-Entwicklung<br />
vernetzter Steuergeräte<br />
Andreas Braun 1 , Stefan Lämmermann 2 , Oliver Bringmann 1 und Wolfgang Rosenstiel 1,2<br />
FZI Forschungszentrum In<strong>for</strong>matik 1<br />
Systementwurf in der Mikroelektronik<br />
Haid-und-Neu-Str. 10–14<br />
D-76131 Karlsruhe<br />
{abraun, bringmann, rosenstiel}@fzi.de<br />
Universität Tübingen 2<br />
Wilhelm Schickard-Institut für In<strong>for</strong>matik<br />
Sand 13<br />
D-72076 Tübingen<br />
Moderne eingebettete Hard- und Software wird zunehmend komplexer und<br />
die Verifikation beansprucht einen immer größeren Anteil des Entwicklungsbudgets<br />
um die ge<strong>for</strong>derten Qualitätsan<strong>for</strong>derungen zu erfüllen. Hier wird<br />
ein unterstützender Ansatz basierend auf virtuellen Prototypen vorgestellt,<br />
der die Testabdeckung und damit die Qualität erhöhen und zudem die Kosten<br />
bzw. die Entwicklungszeit verringern soll.<br />
1 Einleitung<br />
Durch den vermehrten Einsatz von verteilten Systemen im Zusammenspiel mit sicherheitsrelevanten<br />
Anwendungen steigen die An<strong>for</strong>derungen in Bezug auf Fehlerfreiheit und<br />
Robustheit gegenüber unvorhergesehenen Betriebssituationen stetig an. Demgegenüber<br />
steht immer komplexer werdende eingebettete Hard- und Software sowie die Notwendigkeit<br />
kurzer Entwicklungszeiten um den An<strong>for</strong>derungen des Marktes entsprechen zu<br />
können. Mit einem Entwicklungsprozess, wie dem klassischen V-Modell, sind diese Ziele<br />
nicht in einem akzeptablen Kostenrahmen zu erreichen. Tests können erst mit Hilfe<br />
bestehender Hardware durchgeführt werden und entdeckte Fehler führen zu kosten- und<br />
zeitaufwendigen Iterationen. Um eine frühzeitige Verifikation zu ermöglichen bieten sich<br />
Tests auf virtuellen Platt<strong>for</strong>men an, die auch häufig zur Entwicklung eingesetzt werden<br />
um die Hard- und Softwareentwicklung zu parallelisieren. Damit können aufwendige Iterationen<br />
über mehrere Entwicklungszyklen vermieden, die Qualität gesteigert und die<br />
Entwicklungszeit verkürzt werden.<br />
Auf abschließende Tests mit der Zielplatt<strong>for</strong>m kann auch in Zukunft nicht gänzlich verzichtet<br />
werden. Daher muss es das Ziel sein die Verifikation der virtuellen und der realen<br />
Systeme geschickt miteinander zu verknüpfen, so dass zu Beginn ein möglichst geringer<br />
Zusatzaufwand entsteht. Die Qualitätssteigerung soll im Folgenden durch eine wesentlich<br />
höhere Testabdeckung zustande kommen. Tests mithilfe von realer Hardware sind sehr<br />
zeitraubend und lassen sich nur schwer automatisieren. Bei virtuellen Systemen erfolgt<br />
die Platt<strong>for</strong>mkonfiguration vollautomatisch und die Verifikation kann durch den Einsatz<br />
mehrerer Rechner einfach parallelisiert werden. Bei späteren Tests auf der realen Hardware<br />
wird ein ausgewählter Anteil der entwickelten Testsätze verwendet. Die Kosten bzw.
die Zeitreduktion entsteht durch das Vermeiden von Iterationen über mehrere Entwicklungszyklen,<br />
da eine Vielzahl von Fehlern bereits früh in der virtuellen Umgebung aufgedeckt,<br />
analysiert und beseitigt werden können. Dieses Vorgehen lohnt sich vor allem bei<br />
der Entwicklung von komplexen Systemen mit hohen An<strong>for</strong>derungen an die Qualität. Bei<br />
derartigen Projekten übersteigt der Aufwand für die Qualitätssicherung in der Regel den<br />
Aufwand für die Implementierung.<br />
Dieser Artikel behandelt die Verknüpfung eines Softwareverifikationsprozesses, beginnend<br />
bei der Testbeschreibung bis hin zur Ausführung und Analyse, auf virtuellen und<br />
realen eingebetteten Systemen am Beispiel des ” Multimedia Oriented Systems Transport<br />
(MOST)“ Bus. Aus der Vielzahl unterschiedlicher Prüftechniken stehen die transaktionsflussbasierten<br />
Tests, welche den dynamischen Techniken zugeordnet sind, im Fokus. Diese<br />
Tests eignen sich sowohl für Modul- als auch Integrationstests unter Beachtung von<br />
spezifizierten Kommunikationssequenzen und Echtzeitbedingungen. Durch weitgehende<br />
Automatisierung, eine flexible Konfiguration und die Wiederverwendung von Testfällen<br />
für das virtuelle und reale System werden zudem Regressionstests unterstützt. Die Hardwareverifikation<br />
anhand von virtuellen Modellen wird im Folgenden nur kurz behandelt,<br />
da dies den Rahmen der schriftlichen Veröffentlichung sprengen würde.<br />
2 Stand der Technik<br />
Bezüglich der Modellierung und Eignung von virtuellen Prototypen zur frühen Verifikation<br />
von verteilten Systemen existieren verschiedene Arbeiten. [Kim08] stellt einen<br />
Ansatz zur Modellierung und Verifikation des FlexRay-Kommunikationscontrollers vor,<br />
bei dem allerdings die Daten Bit per Bit übertragen werden. Damit kann keine ausreichende<br />
Simulationsper<strong>for</strong>manz erreicht werden um eine genügend große Testabdeckung<br />
zu erzielen. Zudem ist der Aufwand zur Modellierung wesentlich höher als bei abstrakten<br />
” Transaction Level Modeling (TLM)“ Modellen. [Pas05] gibt einen Überblick über<br />
die Simulationsper<strong>for</strong>manz und den Modellierungsaufwand von Simulationsmodellen auf<br />
verschiedenen Abstraktionsebenen. [Cha08] beschreibt einen Ansatz zur Modellierung<br />
und Verifikation von Chip-Netzwerken. Hier wurde eine höhere Abstraktionsebene zur<br />
Erhöhung der Simulationsper<strong>for</strong>manz verwendet, zudem wurden auch Ansätze zur Testautomatisierung<br />
behandelt. Ein Problem stellt aber die Platt<strong>for</strong>mkonfiguration dar. Sobald<br />
zusätzliche Knoten eingefügt werden sollen, muss der Simulationscode modifiziert<br />
werden. [Hab05] zeigt einen Ansatz, der neben einer hohen Abstraktion auch eine konfigurierbare<br />
Platt<strong>for</strong>m vorstellt. Allerdings wird hier nur die Netzwerkkonfiguration behandelt.<br />
Eine flexible Konfiguration, welche auch die Netzwerkgeräte mit einschließt und auf<br />
Erweiterbarkeit einer bestehenden Bibliothek abzielt, wird nicht vorgestellt.<br />
Bei der Verifikation von realen oder auch virtuellen Systemen werden für die Hardwarebzw.<br />
die Softwareverifikation verschiedene Verfahren angewendet. Bei der Hardwareverifikation<br />
kommen häufig bedingungsbasierte Verfahren zum Einsatz. [Hab04] zeigt einen<br />
solchen Ansatz unter Verwendung der ”Property Specification Language (PSL)”. Ein geeignetes<br />
Werkzeug zur bedingungsbasierten Verifikation in virtuellen Modellen wird von<br />
[Ruf06] vorgestellt. Bei der Softwareverifikation kommen funktions- oder strukturorientierte<br />
Testverfahren zum Einsatz. Im Bereich der eigebetteten Software werden in der Praxis<br />
vornehmlich funktionsorientierte Verfahren angewendet. Häufig sind dabei transaktionsflussbasierte<br />
Tests, die mittels verschiedener Sprachen beschrieben werden können.<br />
Beispiele dafür sind die ”Testing und Test Control Notation (TTCN-3)”, die ” Unified Mo-
delling Language (UML)“ oder auch gewöhnliche Programmiersprachen wie Python. Die<br />
Möglichkeit Python an eine Simulationssprache wie z.B. SystemC anzubinden und zur<br />
Testmodellierung zu verwenden wurde schon durch [Gra06] dargestellt. Allerdings wird<br />
nicht erklärt, wie die Anbindung an den Simulationskern von SystemC ohne eine Modifikation<br />
der Simulationsumgebung erfolgen kann. Die Verwendung von Sequenzdiagrammen<br />
zur Transaktionsmodellierung wird in [Bun01] und [Fra02] behandelt. Hier werden<br />
die Diagramme allerdings nicht als Meta<strong>for</strong>mat verwendet um daraus ganze Testsätze zu<br />
erzeugen.<br />
3 Anwendungsbeispiel MOST-Bus<br />
Der MOST-Bus wurde speziell entwickelt um den Infotainment An<strong>for</strong>derungen moderner<br />
Automobile zu entsprechen. Die herkömmlichen Buse wie z.B. CAN und FlexRay eignen<br />
sich nicht, da diese vor allem eine zu geringe Übertragungskapazität besitzen. Beim<br />
MOST-Bus sind drei unterschiedliche Geschwindigkeitsstufen mit 25,50 und 150 Megabit<br />
Datenrate spezifiziert. Zur Übertragung von Audio- und Videodaten wird ein synchroner<br />
Kanal bereitgestellt. Paket und Kontrolldaten können über den asynchronen oder den<br />
Kontrollkanal übertragen werden. Neben der physikalischen und der Übertragungsschicht<br />
werden bei MOST alle 7 Schichten des ISO/OSI Schichtenmodells bis hin zur Applikation<br />
spezifiziert. Zur Paketübertragung auf dem Asynchron- oder dem Kontrollkanal werden<br />
verschiedene Protokolle wie das ” MOST Ethernet Protocol (MEP) “ oder das ” MOST<br />
High Protocols (MHP)“ angeboten. Damit wird die Qualitätssicherung bei MOST zu einem<br />
komplexen Problem, da das zuverlässige Zusammenspiel verschiedenster Protokolle<br />
und anderer Netzwerkelemente über das gesamte Schichtenmodell sichergestellt werden<br />
muss.<br />
Im Folgenden wird der Softwareprüfprozess auf virtueller und realer Hardware am Beispiel<br />
des MHP gezeigt. Das MHP ist ein verbindungsorientiertes Übertragungsprotokoll<br />
vergleichbar mit dem ” Transmission Control Protocol (TCP)“. Es stellt Mechanismen für<br />
den unidirektionalen Verbindungsaufbau, Datenübertragung und Verbindungsabbau zur<br />
Verfügung. Angeordnet ist das MHP zwischen der Applikationsschicht und den Netzwerkdiensten.<br />
Für Tests auf der realen Hardware werden MOST-PCI-Toolkits verwendet.<br />
3.1 Geräte- und Netzwerkmodellierung<br />
Die Modellierung der virtuellen Hardware erfolgt unter Verwendung von SystemC, um<br />
eine genaue Simulation von zeitlichem und funktionalem Verhalten darstellen zu können.<br />
SystemC ist eine auf C++ basierende Modellierungs- und Simulationssprache, die Nebenläufigkeiten<br />
und Zeitaspekte während der Simulation eingebetteter Systeme abdeckt.<br />
Im ersten Schritt der Modellierung muss der als C-Quellcode vorliegende MHP-Stack innerhalb<br />
einer Klasse gekapselt werden um eine Mehrfachinstanziierung des Stack im virtuellen<br />
Netzwerk zu ermöglichen. Im folgenden Schritt erfolgt die Gerätemodellierung.<br />
Das MOST-Gerät muss Applikationen integrieren und den MHP-Stack mit benötigten<br />
Funktionalitäten bedienen können. Im letzten Schritt erfolgt die Netzwerkmodellierung,<br />
damit einen beliebige Anzahl von MOST-Geräten über einen abstrakten Bus miteinander<br />
verknüpft werden können.
3.1.1 Kapselung des MHP-Quellcodes<br />
Um die mehrfache Instanziierung des MHP-Stacks innerhalb der Netzwerksimulation zu<br />
gewährleisten wurde der vorliegende C-Quellcode in der so genannten MHP-Klasse gekapselt.<br />
Diese bildet das zentrale Element für die virtuellen Geräte. Um die MHP-Klasse<br />
mit Statusdaten und verschiedenen Funktionalitäten wie z.B. Zeitgebern versorgen zu<br />
können wurde die Klasse mit verschiedenen Softwareschnittstellen ausgestattet. Diese<br />
werden bei der Gerätemodellierung näher beschrieben.<br />
Die zentralen An<strong>for</strong>derungen an die Kapselung waren zum einen die Einbettung in den<br />
existierenden Entwicklungsfluss und eine minimale Modifikation der Software um das<br />
Ziel der Mehrfachinstanziierung zu erfüllen. Damit kann sichergestellt werden, dass neue<br />
Versionen schnell für die Durchführung von Regressionstest in das Modell eingebunden<br />
werden können. Abgesehen von Array Definitionen konnten alle Änderungen innerhalb<br />
des Codes in zwei zusammenhängenden Blöcken mittels Makros vorgenommen werden.<br />
Ein Block steht zu Beginn des instrumentierten Codes und beinhaltet zusätzlich die Klassendeklaration<br />
sowie zusätzliche Funktionen und Variablen. Der zweite Block steht am<br />
Ende des Codes und beendet die Klassendeklaration und beseitigt die Makros, welche<br />
zur Instrumentierung verwendet wurden. Zur Einbettung in den Entwicklungsfluss wurden<br />
alle Erweiterungen bzw. Änderungen markiert. Damit ist es möglich den Code für die<br />
Einbettung innerhalb der virtuellen Geräte automatisch zu erzeugen.<br />
3.1.2 Gerätemodellierung<br />
Für die Netzwerksimulation ist es nicht ausreichend, den gegebenen C-Code zu kapseln.<br />
Die MHP-Klasse muss mit Statusdaten und Zeitfunktionalitäten versorgt werden.<br />
Zudem müssen Anwendungen integriert werden können, damit spezifische Verifikationsund<br />
Evaluierungszenarien ausgeführt werden können. Für die Bereitstellung der Statusfunktionalitäten<br />
ist die sogenannte Status-Klasse verantwortlich. Die Timer-Klasse stellt<br />
Zeitfunktionalitäten für das Gerät zur Verfügung. Sie verwaltet Zeitgeber, die durch andere<br />
Klassen parametrisiert, gestartet und gestoppt werden können. Sobald einer der Zeitgeber<br />
überläuft wird eine zuvor definierte Funktion aufgerufen, ähnlich einem Interrupt-<br />
Zeitgeber für Mikroprozessoren.<br />
Mit den im Gerät enthaltenen Klassen Transmit und NetInterface wird die Verbindung<br />
zwischen dem ” External Host Controller (EHC)“ und dem ” Intelligent Network Interface<br />
Controller (INIC)“ simuliert. Weiterhin enthält die NetInterface-Klasse eine abstrakte<br />
Puffermodellierung entsprechend dem INIC-Chip. Diese Erweiterung verbessert die<br />
Abstraktion bezüglich des Zeitverhaltens gegenüber realen Systemen. Für die Kommunikation<br />
mit weiteren Geräten schließt die Geräteklasse einen TLM-2.0 Kanal mit ein.<br />
TLM ist ein High-Level-Ansatz für die abstrakte Kommunikationsmodellbildung zwischen<br />
Modulen.<br />
Um Regressionstests und Integrationstests mit unterschiedlichen MHP-Versionen oder<br />
Applikationen durchführen zu können müssen bestimmte Module des MHP-Gerätes austauschbar<br />
bleiben. Dazu werden die Applikations-, Callback, MHP- und die NetInterface-<br />
Klasse von einer Standardklasse für die jeweiligen Module abgeleitet. Mithilfe der Platt<strong>for</strong>mkonfiguration<br />
können dann verschiedene Versionen aus einer bestehenden Bibliothek<br />
dem Gerät zugeordnet werden (siehe Abbildung 1).
3.1.3 Netzwerkmodellierung<br />
Abbildung 1: Aufbau eines MOST-Gerätes.<br />
Für die Kommunikation zwischen den virtuellen Geräten wurde ein abstraktes Netzwerk<br />
modelliert, das die Nachrichtenübertragung auf dem Asynchron- oder dem Kontrollkanal<br />
des MOST-Busses repräsentiert. Die Umsetzung erfolgt unter Verwendung von TLM-<br />
Techniken. Im Gegensatz zum realen Netzwerk, das entweder in einer Ring- oder Sterntopologie<br />
aufgebaut ist, wurde sich für das sogenannte ” Many-to-Many“ Bindung entschieden.<br />
Dabei sind alle Teilnehmer direkt miteinander verknüpft (siehe Abbildung 2).<br />
Dies erhöht die Simulationsper<strong>for</strong>manz der virtuellen Hardware. Ein weiterer entscheidender<br />
Faktor bezüglich der Per<strong>for</strong>manz ist, dass Nachrichten nicht Bit für Bit sondern als<br />
komplette Nachrichten auf dem virtuellen Bus übertragen werden, sobald ein Kommunikationsereignis<br />
auftritt. Eine Übertragungsverzögerung auf dem Bus wurde nicht modelliert,<br />
dahinter steckt die Annahme, dass dies aufgrund der hohen Datenübertragungsrate<br />
von MOST nur eine geringe Auswirkung auf die Genauigkeit der Simulation besitzt. Der<br />
Hauptengpass wird durch die Datenübertragung zwischen EHC und INIC verursacht, indem<br />
gepufferte Pakete nicht immer schnell genug ausgelesen werden, um einen Überlauf<br />
im INIC-Puffer zu vermeiden.<br />
3.2 Testbench-Entwicklung<br />
Abbildung 2: Netzwerkmodellierung mit TLM-2.0.<br />
Für Tests mithilfe des virtuellen Netzwerkes wird neben dem Simulationsmodell eine<br />
Testbench benötigt, die zusätzlich Funktionen bereitstellt um die Steuerbarkeit und Beobachtbarkeit<br />
zu gewährleisten. Die integrierten Elemente werden im Folgenden beschrieben.
3.2.1 Netzwerkkonfiguration<br />
Die Konfiguration der Netzwerksimulation erfolgt mittels einer XML-Datenstruktur. Die<br />
Netzwerkkonfiguration beschreibt die Simulations- und die Platt<strong>for</strong>mkonfiguration. Die<br />
Simulationskonfiguration definiert z.B. die Simulationszeit während die Platt<strong>for</strong>mkonfiguration<br />
die Anzahl und Verknüpfung von virtuellen Geräten auf Netzwerkebene und die<br />
Gerätekonfiguration selbst umfasst. Das zur Konfiguration erstellte XML-Schema wurde<br />
generisch gehalten, damit ist es möglich das Simulationsmodell um weitere Bausteine<br />
zu erweitern ohne das Schema zu verändern. Die Instanziierung der Modellkomponenten<br />
und die Erweiterung der Simulation um neue Bausteine geschehen allein in einer<br />
zentralen Fabrik-Klasse, deren Aufbau dem Fabrik-Entwurfsmuster entspricht. Die<br />
Gerätekonfiguration umfasst die Auswahl verschiedener Bausteinversionen aus einer Bibliothek<br />
und die Konfiguration der Bausteine selbst.<br />
3.2.2 Simulationsaufzeichnung<br />
Zur Analyse werden, wie in Abbildung 3 dargestellt, zahlreiche Daten durch eine zentrale<br />
Trace-Klasse aufgezeichnet. Neben der Kommunikation auf dem virtuellen Bus können<br />
beliebige Statusdaten innerhalb der Klassen, die MHP-Debug-In<strong>for</strong>mationen und Funktionsaufrufe<br />
zwischen den Klassen zusammen mit Zeitstempeln aufgezeichnet werden.<br />
Diese Daten können während und nach den Tests zur Überprüfung herangezogen werden.<br />
Um die In<strong>for</strong>mationsflut steuern zu können, ist die Trace-Klasse ebenfalls konfigurierbar<br />
gehalten. Dazu wurde ein generisches Notifikationsprinzip integriert, so dass während der<br />
Simulation nur ausgewählte Daten an die Trace-Klasse weitergeleitet werden. So kann die<br />
Simulationsper<strong>for</strong>manz beträchtlich gesteigert werden, da zum einen eine Vielzahl von<br />
Funktionsaufrufen und zum anderen aufwendige Dateizugriffe am Ende der Simulation<br />
eingespart werden. Für die Speicherung stehen unterschiedliche Formate zu Verfügung.<br />
3.2.3 Testhost<br />
Abbildung 3: Simulationsaufzeichnung anhand der Trace-Klasse.<br />
Zusätzlich zu den MOST-Geräten kann ein optionaler Testhost im Netzwerk integriert<br />
werden. Dieser dient dem Modul- oder Integrationstest von Protokollen oder Applikationen<br />
(siehe Abbildung 4). Der Testhost kann Nachrichten auf dem Bus anstoßen oder emp-
fangen bzw. überprüfen. Bei der Überprüfung werden Zeit- und Sequenzbedingungen beachtet.<br />
Gegenüber dem realen besitzt der virtuelle Testhost einige Vorteile, so kann dieser<br />
z.B. beim Anstoßen von Nachrichten beliebig viele Sender simulieren. Zudem ist es dem<br />
virtuellen Testhost möglich durch Kommunikation mit einer speziell geschaffenen Applikation<br />
andere Geräte zu steuern. Damit können z.B. Protokolltests durchgeführt werden,<br />
ohne dass eine spezielle Steuerung auf dem Zielgerät implementiert werden muss.<br />
3.2.4 Testdurchführung<br />
Abbildung 4: Testdurchführung unter Einsatz des Testhost.<br />
Mithilfe des Simulationsmodells können einzelne Tests aber auch große Testsätze automatisiert<br />
ablaufen. Für die Automatisierung großer Testsätze wird ein Python-Programm<br />
verwendet, das einzelne Tests auf den Prozessorkernen mehrerer Rechner parallelisiert.<br />
Werden innerhalb eines Testfalles Fehler entdeckt, so werden diese Testfälle zentral für<br />
eine spätere Analyse markiert.<br />
Entscheidend für den Testdurchsatz ist neben der eingesetzten Rechner-Hardware vor allem<br />
die Per<strong>for</strong>manz der Simulationsmodelle. Abbildung 5 zeigt eine Per<strong>for</strong>manzbetrachtung<br />
des virtuellen Netzwerks mit 2 bis 10 Geräten. Während der Simulation übertrugen<br />
die Geräte zyklisch alle 500 Millisekunden ein Datenpaket von 1 oder 10 Kilobyte, je nach<br />
Szenario. Die simulierte Zeit beträgt 5 Minuten, damit ergibt sich bei zwei Geräten eine<br />
Beschleunigung um den Faktor 600. Das Szenario mit 10 Kilobyte übertragenen Daten<br />
ist etwas langsamer, da durch das erhöhte Kommunikationsaufkommen mehr Ereignisse<br />
auftreten. Ausgeführt wurden die Simulationen auf einem der Prozessoren des DELL<br />
PE2950 III Quad-Core Xeon E5320 Board mit 1.86 GHz Taktung. Zu beachten ist, das<br />
die Platt<strong>for</strong>mkonfiguration in der Simulationszeit mit inbegriffen ist. Bei Tests mit Hardware<br />
müssen Boards programmiert, Kabel verbunden und weitere Schritte durchgeführt<br />
werden, bevor der Test starten kann.<br />
3.2.5 Testmodellierung, Erzeugung und Analyse<br />
Eine moderne Testbeschreibung muss heutzutage verschiedenen An<strong>for</strong>derungen gerecht<br />
werden. Zum einen sollen Tests schnell und einfach umsetzbar sein, zum anderen muss<br />
eine lesbare und übersichtliche Testspezifikation entstehen. Zu diesem Zweck wurde eine<br />
Kombination aus Python und UML zur Testbeschreibung entwickelt. Mittels Python<br />
werden einzelne Testfälle beschrieben und können direkt auf der virtuellen und zum Teil
Abbildung 5: Vergleich von realer und simulierter Zeit.<br />
auch auf der realen Hardware ausgeführt werden. Mittels UML können Testfälle visualisiert<br />
und für Spezifikationen verwendet werden, zudem dient die UML-Beschreibung<br />
als Meta<strong>for</strong>mat. Das heißt, aus einer UML-Beschreibung können viele einzelne Testfälle<br />
automatisch generiert werden.<br />
Für die Beschreibung eines Metatests werden in UML Sequenz- und Kompositionsstrukturdiagramme<br />
angeboten. Aus dem Sequenzdiagramm werden transaktionsflussorientierte<br />
Tests in Python erzeugt, aus dem Kompositionsstrukturdiagramm werden XML-Platt<strong>for</strong>mkonfigurationen<br />
erzeugt. Neben der Platt<strong>for</strong>mbeschreibung mittels XML kann auch<br />
Python-Code zur Konfiguration genutzt werden. Zur UML-Testbeschreibung können derzeit<br />
die UML-Werkzeuge Enterprise Architect, Rhaposdy und Papyrus genutzt werden.<br />
Über die ” XML Metadata Interchange (XMI)“ Schnittstelle werden die enthaltenen In<strong>for</strong>mationen<br />
bezogen und in einem folgenden Schritt übersetzt. Nach der Testdurchführung<br />
können Simulationsaufzeichnungen in das UML-Werkzeug zurückgeführt werden. Dieses<br />
Modellierungs- und Visualisierungskonzept wird in Abbildung 6 dargestellt.<br />
3.2.6 Testmodellierung mit Python<br />
Bei der Testmodellierung mittels Python dient die Sprache zum einen der Testbeschreibung<br />
und zum anderen wird der Code direkt zur Steuerung und Überprüfung des Tests<br />
verwendet. Die Anbindung an die virtuelle und reale Hardware erfolgt über den Testhost,<br />
der einen Python-Interpreter integriert. Die Kommunikation zwischen Testhost und dem<br />
Python-Code erfolgt über vordefinierte Schnittstellen, die mittels des ” Software Interface<br />
Generators (SWIG)“ erzeugt werden. Diese Schnittstellen bieten Funktionen zum Senden,<br />
Empfangen, zur Zeitsteuerung und zur Statusabfrage am Testhost.<br />
Der Aufruf des Python-Programmes erfolgt durch den Testhost zu Beginn der Simulation.<br />
Im Falle der SystemC-Simulation wird das Python-Programm aus einem SystemC-Thread<br />
heraus aufgerufen, damit werden Zeit- und Eventgesteuerte Unterbrechungen ermöglicht,<br />
ohne die SystemC-Bibliothek modifizieren zu müssen. Im Falle eines Wartebefehls wird
Abbildung 6: Testmodellierungs- und Visualisierungskonzept mit UML und Python.<br />
das Python-Programm angehalten und erst weiter ausgeführt, sobald die gewünschte Simulationszeit<br />
erreicht ist.<br />
Zur Erzeugung verschiedener Nachrichten zum Versenden und Empfangen wurden im<br />
Python-Code weitere Funktionen untergebracht. Diese können von der Python-Testbeschreibung<br />
verwendet werden. Damit bleibt die Testbeschreibung einfach und lesbar. Sollen<br />
Systemtests durchgeführt werden können dort Funktionen zur Filterung von testrelevanten<br />
Daten untergebracht werden. Damit eignet sich die Python-Beschreibung auch<br />
für die Durchführung komplexer kontrollflussbasierter Testfälle. Ein Beispiel für die Beschreibung<br />
mittels Python wird in Abbildung 7 gezeigt.<br />
Abbildung 7: Transaktionsmodellierung mit Python.<br />
3.2.7 Testmodellierung mit UML<br />
Die Testmodellierung in UML dient der Metabeschreibung von Testszenarien und der Visualisierung<br />
innerhalb einer Testspezifikation. Für die Transaktionsmodellierung werden<br />
Sequenzdiagramme (siehe Abbildung 8) und für die Platt<strong>for</strong>mkonfiguration Kompositionsstrukturdiagramme<br />
verwendet. Aus dem Transaktionsmodell können ganze Testsätze<br />
bzw. mehrere Testfälle entsprechend der Beschreibung im Metamodell erzeugt werden.
Während die Python-Testbeschreibung zum großen Teil auch auf der realen Hardware<br />
ausführbar ist, kann die Platt<strong>for</strong>mkonfiguration nur von der virtuellen Hardware verwendet<br />
werden.<br />
Die Sequenzdiagramme der UML-2.1 bieten neben der Transaktionsmodellierung auch<br />
die Möglichkeit Kontrollstrukturen und Zeitbedingungen zu modellieren. Zeitliche Bedingungen<br />
bei am Testhost ankommenden Nachrichten werden durch die generierten<br />
Python-Testfälle auf Einhaltung überprüft. Mit Hilfe von zeitlichen Bedingungen für Sendenachrichte<br />
werden ganze Testsätze zur automatischen Ausführung erzeugt. Dabei finden<br />
alle Permutationen der zeitlichen Grenzen aller Sendenachrichten Beachtung. Die<br />
im Sequenzdiagramm verwendeten Kontrollstrukturen können dagegen direkt auf Python<br />
übertragen und während des Ablaufs ausgeführt werden.<br />
Bei der Platt<strong>for</strong>mkonfiguration werden die Netzwerkgeräte als Komponenten modelliert<br />
und mittels Assoziationen über Ports miteinander verknüpft. Innerhalb der Komponenten<br />
werden Objekte integriert, welche den Typ des Gerätes spezifizieren z.B. Testhost<br />
oder MOST-Gerät. In einem den Objekten zugeordneten Kompositionsstrukturdiagramm<br />
werden die einzelnen Bausteinversionen der Geräte spezifiziert. Abschließend werden in<br />
einem weiteren Unterdiagramm die Konfigurationsparameter der einzelnen Bausteine beschrieben.<br />
Dieses Prinzip kann beliebig um mehrere Ebenen erweitert werden, falls bestimmte<br />
Bausteine wiederrum aus verschiedenen Bausteinen aufgebaut werden sollen.<br />
Abbildung 8: Transaktionsmodellierung mit UML.
3.2.8 Analyse<br />
Gegenüber der Hardware bieten die virtuellen Modelle eine Vielzahl von verbesserten<br />
Analysemöglichkeiten. Mit einem einfachen Debugger kann das Modell Schrittweise ausgeführt<br />
und zu jedem Zeitpunkt angehalten werden. Alle Statusdaten und weitere In<strong>for</strong>mation<br />
können aufgezeichnet und gespeichert werden. Für die spätere Visualisierung<br />
werden verschiedene Formate angeboten. Darunter befinden sich Text-, XML-, UMLund<br />
weitere Formate zur Visualisierung mit Werkzeugen für die Hardwareanalyse. Damit<br />
kann ein Übergang von den virtuellen auf die realen Tests am Ende der Entwicklungsphase<br />
erleichtert werden. Mittels einer Erweiterung wurden sogar die Analysemöglichkeiten<br />
der bestehenden Hardware auf die Visualisierung mittels der UML-Werkzeuge erweitert<br />
um die Integration der virtuellen Tests weiter zu unterstützen.<br />
4 Zusammenfassung<br />
Tests anhand von virtuellen Systemen besitzen eine Vielzahl von Vorteilen und eignen<br />
sich vor allem in frühen Entwicklungsphasen und bei Regressionstests von komplexen<br />
Systemen. In späten Entwicklungsphasen müssen weiterhin Tests mit realen Systemen<br />
erfolgen, da zum einen bestimmte Fehler aufgrund von Abstraktionen in den Modellen<br />
nicht gefunden werden können. Zum anderen schleichen sich Fehler in spätere Entwicklungsphasen<br />
ein, die nicht durch virtuelle Tests eingeschlossen werden. Um den Übergang<br />
zwischen virtuellen und realen Tests zu erleichtern wurden die Testfälle auf reale Hardware<br />
übertragen. Allerdings können nicht alle Tests auf der Hardware ausgeführt werden. So<br />
kann der reale Testhost z.B. nicht mehrere Geräte gleichzeitig simulieren. Eine Steuerung<br />
der Applikation vom Testhost aus ist theoretisch möglich aber nur schwer umsetzbar.<br />
Virtuelle Tests können auf mehreren Rechnern einfach parallelisiert und automatisiert<br />
werden. Aufgrund der hohen Per<strong>for</strong>manz und einer vollautomatischen Platt<strong>for</strong>mkonfiguration<br />
kann eine hohe Testabdeckung erzielt werden. Bei der Analyse bieten Wiederholbarkeit<br />
und Beobachtbarkeit beträchtliche Vorteile. Alle Simulationen liefern bei gleichbleibender<br />
Konfiguration und Startbedingungen immer die gleichen Ergebnisse. Die Simulationen<br />
lassen sich zu jeder Zeit anhalten und über einen Debugger Schritt für Schritt<br />
ausführen. Weiterhin können alle erdenklichen Statusdaten zusammen mit Zeitstempeln<br />
beobachtet und gespeichert werden. Für Robustheitstest oder eine ” Fehler-Möglichkeitsund<br />
Einflussanalyse (FMEA)“ ist die Steuerbarkeit der Modelle von großem Vorteil. Fehler<br />
können zu jeder Zeit an jeder Stelle injiziert und die entstehenden Auswirkungen simuliert<br />
werden.<br />
Neben dem hier vorgestellten Prüfprinzip lassen sich auch strukturorientierte Tests, auch<br />
als white box Tests bezeichnet, einfach auf virtueller Hardware umsetzen. Diese ermöglichen<br />
eine Codeüberdeckungsanalyse und können durch zahlreiche frei erhältliche Werkzeuge<br />
unterstützt werden. Regressionstests werden durch den hohen Grad der Automatisierung<br />
unterstützt.<br />
5 Danksagung<br />
Diese Arbeit wurde durch das BMBF im Rahmen des Projekts SANITAS unter Fkz.<br />
01M3088C gefördert. Besonders möchten wir der MOST Cooperation und der Firma
SMSC Europe für die umfangreiche Unterstützung bei der vorgestellten Arbeit danken.<br />
Literatur<br />
[Hab05] A. Habibi und S. Tahar. Design and Verification of SystemC Transaction-Level<br />
Models. TVLSI ’05: Transaction on Very Large Scale Integration Systems.<br />
[Moi06] H. Moinudeen, A. Habibi und S. Tahar. Model Based Verification of SystemC<br />
Designs. IEEE ’06: North-East Workshop on Circuits and Systems.<br />
[MOST] MOST Cooperation. www.mostcooperation.com.<br />
[SYC] Open SystemC Initiative. www.systemc.org.<br />
[Lig09] P. Liggesmeyer. Software Qualität: Testen, Analysieren und Verifizieren von Software.<br />
Spektrum Akademischer Verlag ’09.<br />
[Lam08] W. K. Lam. Hardware Design Verification:Simulation and Formal Method-<br />
Based Approaches. Prentice Hall Computer ’08.<br />
[Bun01] A. Bunker und G. Gopalakrishnan. Using Live Sequence Charts <strong>for</strong> Hardware<br />
Protocol Specification and Compliance Verification. High-Level Design Validation and<br />
Test Workshop ’01.<br />
[Fra02] F. Fraikin und T. Leonhardt. SeDiTeC - Testing Based on Sequence Diagrams.<br />
ASE ’02: Automated Software Engineering.<br />
[Kim08] W. S. Kim, H. A. Kim, J. H. Ahn and B. Moon. System-Level Development<br />
and Verification of the FlexRay Communication Controller Model Based on SystemC.<br />
FGCN ’08: Second International Conference on Future Generation Communication<br />
and Networking.<br />
[Pas05] S. Pasricha, N. Dutt and M. Romdhane. Using TLM <strong>for</strong> Exploring Bus-based<br />
SoC Communication Architectures. ASAP ’05: 16th IEEE International Conference<br />
on Application-Specific System, Architecture Processors.<br />
[Cha08] S. Chai, C. Wu, Y. Y. Li and Z. Yang. A NoC Simulation and Verification Plat<strong>for</strong>m<br />
Based on SystemC. CSSE ’08: International Conference on Computer Science<br />
and Software Engineering.<br />
[Yon10] Y. Bu, Z. Tao, M. Lei, C. Wu and C. Wu. A Configurable SystemC Virtual Plat<strong>for</strong>m<br />
<strong>for</strong> Early Software Development and its Sub-system <strong>for</strong> Hardware Verification.<br />
VLSI-DAT ’10: VLSI Design Automation and Test.<br />
[Gra06] Cool Verification. www.coolverification.com/2006/06/python as an hv.html.<br />
[Let08] D. Lettnin, P. K. Nalla, J. Ruf, T. Kropf and W. Rosenstiel. Verification of Temporal<br />
Properties in Automotive Embedded Software. DATE ’08: Design, Automation<br />
and Test in Europe.<br />
[Hab04] A. Habibi, A. Gawanmeh and Sofiene Tahar. Assertion Based Verification of<br />
PSL <strong>for</strong> SystemC Designs. SOC ’04: International Symposium on System-on-Chip.<br />
[Ruf06] J. Ruf, R. Weiss, D. V. Lettnin, S. Lämmermann, T. Kropf und W. Rosenstiel.<br />
SystemC Temporal Checker. Tübingen ’06: Department of Computer Engineering.