Paper for Download - FKFS

Virtual Prototyping in der Hardware- und Software-Entwicklung
vernetzter Steuergeräte
Andreas Braun 1 , Stefan Lämmermann 2 , Oliver Bringmann 1 und Wolfgang Rosenstiel 1,2
FZI Forschungszentrum Informatik 1
Systementwurf in der Mikroelektronik
Haid-und-Neu-Str. 10–14
D-76131 Karlsruhe
{abraun, bringmann, rosenstiel}@fzi.de
Universität Tübingen 2
Wilhelm Schickard-Institut für Informatik
Sand 13
D-72076 Tübingen
Moderne eingebettete Hard- und Software wird zunehmend komplexer und
die Verifikation beansprucht einen immer größeren Anteil des Entwicklungsbudgets
um die geforderten Qualitätsanforderungen zu erfüllen. Hier wird
ein unterstützender Ansatz basierend auf virtuellen Prototypen vorgestellt,
der die Testabdeckung und damit die Qualität erhöhen und zudem die Kosten
bzw. die Entwicklungszeit verringern soll.
1 Einleitung
Durch den vermehrten Einsatz von verteilten Systemen im Zusammenspiel mit sicherheitsrelevanten
Anwendungen steigen die Anforderungen in Bezug auf Fehlerfreiheit und
Robustheit gegenüber unvorhergesehenen Betriebssituationen stetig an. Demgegenüber
steht immer komplexer werdende eingebettete Hard- und Software sowie die Notwendigkeit
kurzer Entwicklungszeiten um den Anforderungen des Marktes entsprechen zu
können. Mit einem Entwicklungsprozess, wie dem klassischen V-Modell, sind diese Ziele
nicht in einem akzeptablen Kostenrahmen zu erreichen. Tests können erst mit Hilfe
bestehender Hardware durchgeführt werden und entdeckte Fehler führen zu kosten- und
zeitaufwendigen Iterationen. Um eine frühzeitige Verifikation zu ermöglichen bieten sich
Tests auf virtuellen Plattformen an, die auch häufig zur Entwicklung eingesetzt werden
um die Hard- und Softwareentwicklung zu parallelisieren. Damit können aufwendige Iterationen
über mehrere Entwicklungszyklen vermieden, die Qualität gesteigert und die
Entwicklungszeit verkürzt werden.
Auf abschließende Tests mit der Zielplattform kann auch in Zukunft nicht gänzlich verzichtet
werden. Daher muss es das Ziel sein die Verifikation der virtuellen und der realen
Systeme geschickt miteinander zu verknüpfen, so dass zu Beginn ein möglichst geringer
Zusatzaufwand entsteht. Die Qualitätssteigerung soll im Folgenden durch eine wesentlich
höhere Testabdeckung zustande kommen. Tests mithilfe von realer Hardware sind sehr
zeitraubend und lassen sich nur schwer automatisieren. Bei virtuellen Systemen erfolgt
die Plattformkonfiguration vollautomatisch und die Verifikation kann durch den Einsatz
mehrerer Rechner einfach parallelisiert werden. Bei späteren Tests auf der realen Hardware
wird ein ausgewählter Anteil der entwickelten Testsätze verwendet. Die Kosten bzw.

die Zeitreduktion entsteht durch das Vermeiden von Iterationen über mehrere Entwicklungszyklen,
da eine Vielzahl von Fehlern bereits früh in der virtuellen Umgebung aufgedeckt,
analysiert und beseitigt werden können. Dieses Vorgehen lohnt sich vor allem bei
der Entwicklung von komplexen Systemen mit hohen Anforderungen an die Qualität. Bei
derartigen Projekten übersteigt der Aufwand für die Qualitätssicherung in der Regel den
Aufwand für die Implementierung.
Dieser Artikel behandelt die Verknüpfung eines Softwareverifikationsprozesses, beginnend
bei der Testbeschreibung bis hin zur Ausführung und Analyse, auf virtuellen und
realen eingebetteten Systemen am Beispiel des ” Multimedia Oriented Systems Transport
(MOST)“ Bus. Aus der Vielzahl unterschiedlicher Prüftechniken stehen die transaktionsflussbasierten
Tests, welche den dynamischen Techniken zugeordnet sind, im Fokus. Diese
Tests eignen sich sowohl für Modul- als auch Integrationstests unter Beachtung von
spezifizierten Kommunikationssequenzen und Echtzeitbedingungen. Durch weitgehende
Automatisierung, eine flexible Konfiguration und die Wiederverwendung von Testfällen
für das virtuelle und reale System werden zudem Regressionstests unterstützt. Die Hardwareverifikation
anhand von virtuellen Modellen wird im Folgenden nur kurz behandelt,
da dies den Rahmen der schriftlichen Veröffentlichung sprengen würde.
2 Stand der Technik
Bezüglich der Modellierung und Eignung von virtuellen Prototypen zur frühen Verifikation
von verteilten Systemen existieren verschiedene Arbeiten. [Kim08] stellt einen
Ansatz zur Modellierung und Verifikation des FlexRay-Kommunikationscontrollers vor,
bei dem allerdings die Daten Bit per Bit übertragen werden. Damit kann keine ausreichende
Simulationsperformanz erreicht werden um eine genügend große Testabdeckung
zu erzielen. Zudem ist der Aufwand zur Modellierung wesentlich höher als bei abstrakten
” Transaction Level Modeling (TLM)“ Modellen. [Pas05] gibt einen Überblick über
die Simulationsperformanz und den Modellierungsaufwand von Simulationsmodellen auf
verschiedenen Abstraktionsebenen. [Cha08] beschreibt einen Ansatz zur Modellierung
und Verifikation von Chip-Netzwerken. Hier wurde eine höhere Abstraktionsebene zur
Erhöhung der Simulationsperformanz verwendet, zudem wurden auch Ansätze zur Testautomatisierung
behandelt. Ein Problem stellt aber die Plattformkonfiguration dar. Sobald
zusätzliche Knoten eingefügt werden sollen, muss der Simulationscode modifiziert
werden. [Hab05] zeigt einen Ansatz, der neben einer hohen Abstraktion auch eine konfigurierbare
Plattform vorstellt. Allerdings wird hier nur die Netzwerkkonfiguration behandelt.
Eine flexible Konfiguration, welche auch die Netzwerkgeräte mit einschließt und auf
Erweiterbarkeit einer bestehenden Bibliothek abzielt, wird nicht vorgestellt.
Bei der Verifikation von realen oder auch virtuellen Systemen werden für die Hardwarebzw.
die Softwareverifikation verschiedene Verfahren angewendet. Bei der Hardwareverifikation
kommen häufig bedingungsbasierte Verfahren zum Einsatz. [Hab04] zeigt einen
solchen Ansatz unter Verwendung der ”Property Specification Language (PSL)”. Ein geeignetes
Werkzeug zur bedingungsbasierten Verifikation in virtuellen Modellen wird von
[Ruf06] vorgestellt. Bei der Softwareverifikation kommen funktions- oder strukturorientierte
Testverfahren zum Einsatz. Im Bereich der eigebetteten Software werden in der Praxis
vornehmlich funktionsorientierte Verfahren angewendet. Häufig sind dabei transaktionsflussbasierte
Tests, die mittels verschiedener Sprachen beschrieben werden können.
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
Möglichkeit Python an eine Simulationssprache wie z.B. SystemC anzubinden und zur
Testmodellierung zu verwenden wurde schon durch [Gra06] dargestellt. Allerdings wird
nicht erklärt, wie die Anbindung an den Simulationskern von SystemC ohne eine Modifikation
der Simulationsumgebung erfolgen kann. Die Verwendung von Sequenzdiagrammen
zur Transaktionsmodellierung wird in [Bun01] und [Fra02] behandelt. Hier werden
die Diagramme allerdings nicht als Metaformat verwendet um daraus ganze Testsätze zu
erzeugen.
3 Anwendungsbeispiel MOST-Bus
Der MOST-Bus wurde speziell entwickelt um den Infotainment Anforderungen moderner
Automobile zu entsprechen. Die herkömmlichen Buse wie z.B. CAN und FlexRay eignen
sich nicht, da diese vor allem eine zu geringe Übertragungskapazität besitzen. Beim
MOST-Bus sind drei unterschiedliche Geschwindigkeitsstufen mit 25,50 und 150 Megabit
Datenrate spezifiziert. Zur Übertragung von Audio- und Videodaten wird ein synchroner
Kanal bereitgestellt. Paket und Kontrolldaten können über den asynchronen oder den
Kontrollkanal übertragen werden. Neben der physikalischen und der Übertragungsschicht
werden bei MOST alle 7 Schichten des ISO/OSI Schichtenmodells bis hin zur Applikation
spezifiziert. Zur Paketübertragung auf dem Asynchron- oder dem Kontrollkanal werden
verschiedene Protokolle wie das ” MOST Ethernet Protocol (MEP) “ oder das ” MOST
High Protocols (MHP)“ angeboten. Damit wird die Qualitätssicherung bei MOST zu einem
komplexen Problem, da das zuverlässige Zusammenspiel verschiedenster Protokolle
und anderer Netzwerkelemente über das gesamte Schichtenmodell sichergestellt werden
muss.
Im Folgenden wird der Softwareprüfprozess auf virtueller und realer Hardware am Beispiel
des MHP gezeigt. Das MHP ist ein verbindungsorientiertes Übertragungsprotokoll
vergleichbar mit dem ” Transmission Control Protocol (TCP)“. Es stellt Mechanismen für
den unidirektionalen Verbindungsaufbau, Datenübertragung und Verbindungsabbau zur
Verfügung. Angeordnet ist das MHP zwischen der Applikationsschicht und den Netzwerkdiensten.
Für Tests auf der realen Hardware werden MOST-PCI-Toolkits verwendet.
3.1 Geräte- und Netzwerkmodellierung
Die Modellierung der virtuellen Hardware erfolgt unter Verwendung von SystemC, um
eine genaue Simulation von zeitlichem und funktionalem Verhalten darstellen zu können.
SystemC ist eine auf C++ basierende Modellierungs- und Simulationssprache, die Nebenläufigkeiten
und Zeitaspekte während der Simulation eingebetteter Systeme abdeckt.
Im ersten Schritt der Modellierung muss der als C-Quellcode vorliegende MHP-Stack innerhalb
einer Klasse gekapselt werden um eine Mehrfachinstanziierung des Stack im virtuellen
Netzwerk zu ermöglichen. Im folgenden Schritt erfolgt die Gerätemodellierung.
Das MOST-Gerät muss Applikationen integrieren und den MHP-Stack mit benötigten
Funktionalitäten bedienen können. Im letzten Schritt erfolgt die Netzwerkmodellierung,
damit einen beliebige Anzahl von MOST-Geräten über einen abstrakten Bus miteinander
verknüpft werden können.

3.1.1 Kapselung des MHP-Quellcodes
Um die mehrfache Instanziierung des MHP-Stacks innerhalb der Netzwerksimulation zu
gewährleisten wurde der vorliegende C-Quellcode in der so genannten MHP-Klasse gekapselt.
Diese bildet das zentrale Element für die virtuellen Geräte. Um die MHP-Klasse
mit Statusdaten und verschiedenen Funktionalitäten wie z.B. Zeitgebern versorgen zu
können wurde die Klasse mit verschiedenen Softwareschnittstellen ausgestattet. Diese
werden bei der Gerätemodellierung näher beschrieben.
Die zentralen Anforderungen an die Kapselung waren zum einen die Einbettung in den
existierenden Entwicklungsfluss und eine minimale Modifikation der Software um das
Ziel der Mehrfachinstanziierung zu erfüllen. Damit kann sichergestellt werden, dass neue
Versionen schnell für die Durchführung von Regressionstest in das Modell eingebunden
werden können. Abgesehen von Array Definitionen konnten alle Änderungen innerhalb
des Codes in zwei zusammenhängenden Blöcken mittels Makros vorgenommen werden.
Ein Block steht zu Beginn des instrumentierten Codes und beinhaltet zusätzlich die Klassendeklaration
sowie zusätzliche Funktionen und Variablen. Der zweite Block steht am
Ende des Codes und beendet die Klassendeklaration und beseitigt die Makros, welche
zur Instrumentierung verwendet wurden. Zur Einbettung in den Entwicklungsfluss wurden
alle Erweiterungen bzw. Änderungen markiert. Damit ist es möglich den Code für die
Einbettung innerhalb der virtuellen Geräte automatisch zu erzeugen.
3.1.2 Gerätemodellierung
Für die Netzwerksimulation ist es nicht ausreichend, den gegebenen C-Code zu kapseln.
Die MHP-Klasse muss mit Statusdaten und Zeitfunktionalitäten versorgt werden.
Zudem müssen Anwendungen integriert werden können, damit spezifische Verifikationsund
Evaluierungszenarien ausgeführt werden können. Für die Bereitstellung der Statusfunktionalitäten
ist die sogenannte Status-Klasse verantwortlich. Die Timer-Klasse stellt
Zeitfunktionalitäten für das Gerät zur Verfügung. Sie verwaltet Zeitgeber, die durch andere
Klassen parametrisiert, gestartet und gestoppt werden können. Sobald einer der Zeitgeber
überläuft wird eine zuvor definierte Funktion aufgerufen, ähnlich einem Interrupt-
Zeitgeber für Mikroprozessoren.
Mit den im Gerät enthaltenen Klassen Transmit und NetInterface wird die Verbindung
zwischen dem ” External Host Controller (EHC)“ und dem ” Intelligent Network Interface
Controller (INIC)“ simuliert. Weiterhin enthält die NetInterface-Klasse eine abstrakte
Puffermodellierung entsprechend dem INIC-Chip. Diese Erweiterung verbessert die
Abstraktion bezüglich des Zeitverhaltens gegenüber realen Systemen. Für die Kommunikation
mit weiteren Geräten schließt die Geräteklasse einen TLM-2.0 Kanal mit ein.
TLM ist ein High-Level-Ansatz für die abstrakte Kommunikationsmodellbildung zwischen
Modulen.
Um Regressionstests und Integrationstests mit unterschiedlichen MHP-Versionen oder
Applikationen durchführen zu können müssen bestimmte Module des MHP-Gerätes austauschbar
bleiben. Dazu werden die Applikations-, Callback, MHP- und die NetInterface-
Klasse von einer Standardklasse für die jeweiligen Module abgeleitet. Mithilfe der Plattformkonfiguration
können dann verschiedene Versionen aus einer bestehenden Bibliothek
dem Gerät zugeordnet werden (siehe Abbildung 1).

3.1.3 Netzwerkmodellierung
Abbildung 1: Aufbau eines MOST-Gerätes.
Für die Kommunikation zwischen den virtuellen Geräten wurde ein abstraktes Netzwerk
modelliert, das die Nachrichtenübertragung auf dem Asynchron- oder dem Kontrollkanal
des MOST-Busses repräsentiert. Die Umsetzung erfolgt unter Verwendung von TLM-
Techniken. Im Gegensatz zum realen Netzwerk, das entweder in einer Ring- oder Sterntopologie
aufgebaut ist, wurde sich für das sogenannte ” Many-to-Many“ Bindung entschieden.
Dabei sind alle Teilnehmer direkt miteinander verknüpft (siehe Abbildung 2).
Dies erhöht die Simulationsperformanz der virtuellen Hardware. Ein weiterer entscheidender
Faktor bezüglich der Performanz ist, dass Nachrichten nicht Bit für Bit sondern als
komplette Nachrichten auf dem virtuellen Bus übertragen werden, sobald ein Kommunikationsereignis
auftritt. Eine Übertragungsverzögerung auf dem Bus wurde nicht modelliert,
dahinter steckt die Annahme, dass dies aufgrund der hohen Datenübertragungsrate
von MOST nur eine geringe Auswirkung auf die Genauigkeit der Simulation besitzt. Der
Hauptengpass wird durch die Datenübertragung zwischen EHC und INIC verursacht, indem
gepufferte Pakete nicht immer schnell genug ausgelesen werden, um einen Überlauf
im INIC-Puffer zu vermeiden.
3.2 Testbench-Entwicklung
Abbildung 2: Netzwerkmodellierung mit TLM-2.0.
Für Tests mithilfe des virtuellen Netzwerkes wird neben dem Simulationsmodell eine
Testbench benötigt, die zusätzlich Funktionen bereitstellt um die Steuerbarkeit und Beobachtbarkeit
zu gewährleisten. Die integrierten Elemente werden im Folgenden beschrieben.

3.2.1 Netzwerkkonfiguration
Die Konfiguration der Netzwerksimulation erfolgt mittels einer XML-Datenstruktur. Die
Netzwerkkonfiguration beschreibt die Simulations- und die Plattformkonfiguration. Die
Simulationskonfiguration definiert z.B. die Simulationszeit während die Plattformkonfiguration
die Anzahl und Verknüpfung von virtuellen Geräten auf Netzwerkebene und die
Gerätekonfiguration selbst umfasst. Das zur Konfiguration erstellte XML-Schema wurde
generisch gehalten, damit ist es möglich das Simulationsmodell um weitere Bausteine
zu erweitern ohne das Schema zu verändern. Die Instanziierung der Modellkomponenten
und die Erweiterung der Simulation um neue Bausteine geschehen allein in einer
zentralen Fabrik-Klasse, deren Aufbau dem Fabrik-Entwurfsmuster entspricht. Die
Gerätekonfiguration umfasst die Auswahl verschiedener Bausteinversionen aus einer Bibliothek
und die Konfiguration der Bausteine selbst.
3.2.2 Simulationsaufzeichnung
Zur Analyse werden, wie in Abbildung 3 dargestellt, zahlreiche Daten durch eine zentrale
Trace-Klasse aufgezeichnet. Neben der Kommunikation auf dem virtuellen Bus können
beliebige Statusdaten innerhalb der Klassen, die MHP-Debug-Informationen und Funktionsaufrufe
zwischen den Klassen zusammen mit Zeitstempeln aufgezeichnet werden.
Diese Daten können während und nach den Tests zur Überprüfung herangezogen werden.
Um die Informationsflut steuern zu können, ist die Trace-Klasse ebenfalls konfigurierbar
gehalten. Dazu wurde ein generisches Notifikationsprinzip integriert, so dass während der
Simulation nur ausgewählte Daten an die Trace-Klasse weitergeleitet werden. So kann die
Simulationsperformanz beträchtlich gesteigert werden, da zum einen eine Vielzahl von
Funktionsaufrufen und zum anderen aufwendige Dateizugriffe am Ende der Simulation
eingespart werden. Für die Speicherung stehen unterschiedliche Formate zu Verfügung.
3.2.3 Testhost
Abbildung 3: Simulationsaufzeichnung anhand der Trace-Klasse.
Zusätzlich zu den MOST-Geräten kann ein optionaler Testhost im Netzwerk integriert
werden. Dieser dient dem Modul- oder Integrationstest von Protokollen oder Applikationen
(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.
Gegenüber dem realen besitzt der virtuelle Testhost einige Vorteile, so kann dieser
z.B. beim Anstoßen von Nachrichten beliebig viele Sender simulieren. Zudem ist es dem
virtuellen Testhost möglich durch Kommunikation mit einer speziell geschaffenen Applikation
andere Geräte zu steuern. Damit können z.B. Protokolltests durchgeführt werden,
ohne dass eine spezielle Steuerung auf dem Zielgerät implementiert werden muss.
3.2.4 Testdurchführung
Abbildung 4: Testdurchführung unter Einsatz des Testhost.
Mithilfe des Simulationsmodells können einzelne Tests aber auch große Testsätze automatisiert
ablaufen. Für die Automatisierung großer Testsätze wird ein Python-Programm
verwendet, das einzelne Tests auf den Prozessorkernen mehrerer Rechner parallelisiert.
Werden innerhalb eines Testfalles Fehler entdeckt, so werden diese Testfälle zentral für
eine spätere Analyse markiert.
Entscheidend für den Testdurchsatz ist neben der eingesetzten Rechner-Hardware vor allem
die Performanz der Simulationsmodelle. Abbildung 5 zeigt eine Performanzbetrachtung
des virtuellen Netzwerks mit 2 bis 10 Geräten. Während der Simulation übertrugen
die Geräte zyklisch alle 500 Millisekunden ein Datenpaket von 1 oder 10 Kilobyte, je nach
Szenario. Die simulierte Zeit beträgt 5 Minuten, damit ergibt sich bei zwei Geräten eine
Beschleunigung um den Faktor 600. Das Szenario mit 10 Kilobyte übertragenen Daten
ist etwas langsamer, da durch das erhöhte Kommunikationsaufkommen mehr Ereignisse
auftreten. Ausgeführt wurden die Simulationen auf einem der Prozessoren des DELL
PE2950 III Quad-Core Xeon E5320 Board mit 1.86 GHz Taktung. Zu beachten ist, das
die Plattformkonfiguration in der Simulationszeit mit inbegriffen ist. Bei Tests mit Hardware
müssen Boards programmiert, Kabel verbunden und weitere Schritte durchgeführt
werden, bevor der Test starten kann.
3.2.5 Testmodellierung, Erzeugung und Analyse
Eine moderne Testbeschreibung muss heutzutage verschiedenen Anforderungen gerecht
werden. Zum einen sollen Tests schnell und einfach umsetzbar sein, zum anderen muss
eine lesbare und übersichtliche Testspezifikation entstehen. Zu diesem Zweck wurde eine
Kombination aus Python und UML zur Testbeschreibung entwickelt. Mittels Python
werden einzelne Testfälle beschrieben und können direkt auf der virtuellen und zum Teil

Abbildung 5: Vergleich von realer und simulierter Zeit.
auch auf der realen Hardware ausgeführt werden. Mittels UML können Testfälle visualisiert
und für Spezifikationen verwendet werden, zudem dient die UML-Beschreibung
als Metaformat. Das heißt, aus einer UML-Beschreibung können viele einzelne Testfälle
automatisch generiert werden.
Für die Beschreibung eines Metatests werden in UML Sequenz- und Kompositionsstrukturdiagramme
angeboten. Aus dem Sequenzdiagramm werden transaktionsflussorientierte
Tests in Python erzeugt, aus dem Kompositionsstrukturdiagramm werden XML-Plattformkonfigurationen
erzeugt. Neben der Plattformbeschreibung mittels XML kann auch
Python-Code zur Konfiguration genutzt werden. Zur UML-Testbeschreibung können derzeit
die UML-Werkzeuge Enterprise Architect, Rhaposdy und Papyrus genutzt werden.
Über die ” XML Metadata Interchange (XMI)“ Schnittstelle werden die enthaltenen Informationen
bezogen und in einem folgenden Schritt übersetzt. Nach der Testdurchführung
können Simulationsaufzeichnungen in das UML-Werkzeug zurückgeführt werden. Dieses
Modellierungs- und Visualisierungskonzept wird in Abbildung 6 dargestellt.
3.2.6 Testmodellierung mit Python
Bei der Testmodellierung mittels Python dient die Sprache zum einen der Testbeschreibung
und zum anderen wird der Code direkt zur Steuerung und Überprüfung des Tests
verwendet. Die Anbindung an die virtuelle und reale Hardware erfolgt über den Testhost,
der einen Python-Interpreter integriert. Die Kommunikation zwischen Testhost und dem
Python-Code erfolgt über vordefinierte Schnittstellen, die mittels des ” Software Interface
Generators (SWIG)“ erzeugt werden. Diese Schnittstellen bieten Funktionen zum Senden,
Empfangen, zur Zeitsteuerung und zur Statusabfrage am Testhost.
Der Aufruf des Python-Programmes erfolgt durch den Testhost zu Beginn der Simulation.
Im Falle der SystemC-Simulation wird das Python-Programm aus einem SystemC-Thread
heraus aufgerufen, damit werden Zeit- und Eventgesteuerte Unterbrechungen ermöglicht,
ohne die SystemC-Bibliothek modifizieren zu müssen. Im Falle eines Wartebefehls wird

Abbildung 6: Testmodellierungs- und Visualisierungskonzept mit UML und Python.
das Python-Programm angehalten und erst weiter ausgeführt, sobald die gewünschte Simulationszeit
erreicht ist.
Zur Erzeugung verschiedener Nachrichten zum Versenden und Empfangen wurden im
Python-Code weitere Funktionen untergebracht. Diese können von der Python-Testbeschreibung
verwendet werden. Damit bleibt die Testbeschreibung einfach und lesbar. Sollen
Systemtests durchgeführt werden können dort Funktionen zur Filterung von testrelevanten
Daten untergebracht werden. Damit eignet sich die Python-Beschreibung auch
für die Durchführung komplexer kontrollflussbasierter Testfälle. Ein Beispiel für die Beschreibung
mittels Python wird in Abbildung 7 gezeigt.
Abbildung 7: Transaktionsmodellierung mit Python.
3.2.7 Testmodellierung mit UML
Die Testmodellierung in UML dient der Metabeschreibung von Testszenarien und der Visualisierung
innerhalb einer Testspezifikation. Für die Transaktionsmodellierung werden
Sequenzdiagramme (siehe Abbildung 8) und für die Plattformkonfiguration Kompositionsstrukturdiagramme
verwendet. Aus dem Transaktionsmodell können ganze Testsätze
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
ausführbar ist, kann die Plattformkonfiguration nur von der virtuellen Hardware verwendet
werden.
Die Sequenzdiagramme der UML-2.1 bieten neben der Transaktionsmodellierung auch
die Möglichkeit Kontrollstrukturen und Zeitbedingungen zu modellieren. Zeitliche Bedingungen
bei am Testhost ankommenden Nachrichten werden durch die generierten
Python-Testfälle auf Einhaltung überprüft. Mit Hilfe von zeitlichen Bedingungen für Sendenachrichte
werden ganze Testsätze zur automatischen Ausführung erzeugt. Dabei finden
alle Permutationen der zeitlichen Grenzen aller Sendenachrichten Beachtung. Die
im Sequenzdiagramm verwendeten Kontrollstrukturen können dagegen direkt auf Python
übertragen und während des Ablaufs ausgeführt werden.
Bei der Plattformkonfiguration werden die Netzwerkgeräte als Komponenten modelliert
und mittels Assoziationen über Ports miteinander verknüpft. Innerhalb der Komponenten
werden Objekte integriert, welche den Typ des Gerätes spezifizieren z.B. Testhost
oder MOST-Gerät. In einem den Objekten zugeordneten Kompositionsstrukturdiagramm
werden die einzelnen Bausteinversionen der Geräte spezifiziert. Abschließend werden in
einem weiteren Unterdiagramm die Konfigurationsparameter der einzelnen Bausteine beschrieben.
Dieses Prinzip kann beliebig um mehrere Ebenen erweitert werden, falls bestimmte
Bausteine wiederrum aus verschiedenen Bausteinen aufgebaut werden sollen.
Abbildung 8: Transaktionsmodellierung mit UML.

3.2.8 Analyse
Gegenüber der Hardware bieten die virtuellen Modelle eine Vielzahl von verbesserten
Analysemöglichkeiten. Mit einem einfachen Debugger kann das Modell Schrittweise ausgeführt
und zu jedem Zeitpunkt angehalten werden. Alle Statusdaten und weitere Information
können aufgezeichnet und gespeichert werden. Für die spätere Visualisierung
werden verschiedene Formate angeboten. Darunter befinden sich Text-, XML-, UMLund
weitere Formate zur Visualisierung mit Werkzeugen für die Hardwareanalyse. Damit
kann ein Übergang von den virtuellen auf die realen Tests am Ende der Entwicklungsphase
erleichtert werden. Mittels einer Erweiterung wurden sogar die Analysemöglichkeiten
der bestehenden Hardware auf die Visualisierung mittels der UML-Werkzeuge erweitert
um die Integration der virtuellen Tests weiter zu unterstützen.
4 Zusammenfassung
Tests anhand von virtuellen Systemen besitzen eine Vielzahl von Vorteilen und eignen
sich vor allem in frühen Entwicklungsphasen und bei Regressionstests von komplexen
Systemen. In späten Entwicklungsphasen müssen weiterhin Tests mit realen Systemen
erfolgen, da zum einen bestimmte Fehler aufgrund von Abstraktionen in den Modellen
nicht gefunden werden können. Zum anderen schleichen sich Fehler in spätere Entwicklungsphasen
ein, die nicht durch virtuelle Tests eingeschlossen werden. Um den Übergang
zwischen virtuellen und realen Tests zu erleichtern wurden die Testfälle auf reale Hardware
übertragen. Allerdings können nicht alle Tests auf der Hardware ausgeführt werden. So
kann der reale Testhost z.B. nicht mehrere Geräte gleichzeitig simulieren. Eine Steuerung
der Applikation vom Testhost aus ist theoretisch möglich aber nur schwer umsetzbar.
Virtuelle Tests können auf mehreren Rechnern einfach parallelisiert und automatisiert
werden. Aufgrund der hohen Performanz und einer vollautomatischen Plattformkonfiguration
kann eine hohe Testabdeckung erzielt werden. Bei der Analyse bieten Wiederholbarkeit
und Beobachtbarkeit beträchtliche Vorteile. Alle Simulationen liefern bei gleichbleibender
Konfiguration und Startbedingungen immer die gleichen Ergebnisse. Die Simulationen
lassen sich zu jeder Zeit anhalten und über einen Debugger Schritt für Schritt
ausführen. Weiterhin können alle erdenklichen Statusdaten zusammen mit Zeitstempeln
beobachtet und gespeichert werden. Für Robustheitstest oder eine ” Fehler-Möglichkeitsund
Einflussanalyse (FMEA)“ ist die Steuerbarkeit der Modelle von großem Vorteil. Fehler
können zu jeder Zeit an jeder Stelle injiziert und die entstehenden Auswirkungen simuliert
werden.
Neben dem hier vorgestellten Prüfprinzip lassen sich auch strukturorientierte Tests, auch
als white box Tests bezeichnet, einfach auf virtueller Hardware umsetzen. Diese ermöglichen
eine Codeüberdeckungsanalyse und können durch zahlreiche frei erhältliche Werkzeuge
unterstützt werden. Regressionstests werden durch den hohen Grad der Automatisierung
unterstützt.
5 Danksagung
Diese Arbeit wurde durch das BMBF im Rahmen des Projekts SANITAS unter Fkz.
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.
Literatur
[Hab05] A. Habibi und S. Tahar. Design and Verification of SystemC Transaction-Level
Models. TVLSI ’05: Transaction on Very Large Scale Integration Systems.
[Moi06] H. Moinudeen, A. Habibi und S. Tahar. Model Based Verification of SystemC
Designs. IEEE ’06: North-East Workshop on Circuits and Systems.
[MOST] MOST Cooperation. www.mostcooperation.com.
[SYC] Open SystemC Initiative. www.systemc.org.
[Lig09] P. Liggesmeyer. Software Qualität: Testen, Analysieren und Verifizieren von Software.
Spektrum Akademischer Verlag ’09.
[Lam08] W. K. Lam. Hardware Design Verification:Simulation and Formal Method-
Based Approaches. Prentice Hall Computer ’08.
[Bun01] A. Bunker und G. Gopalakrishnan. Using Live Sequence Charts for Hardware
Protocol Specification and Compliance Verification. High-Level Design Validation and
Test Workshop ’01.
[Fra02] F. Fraikin und T. Leonhardt. SeDiTeC - Testing Based on Sequence Diagrams.
ASE ’02: Automated Software Engineering.
[Kim08] W. S. Kim, H. A. Kim, J. H. Ahn and B. Moon. System-Level Development
and Verification of the FlexRay Communication Controller Model Based on SystemC.
FGCN ’08: Second International Conference on Future Generation Communication
and Networking.
[Pas05] S. Pasricha, N. Dutt and M. Romdhane. Using TLM for Exploring Bus-based
SoC Communication Architectures. ASAP ’05: 16th IEEE International Conference
on Application-Specific System, Architecture Processors.
[Cha08] S. Chai, C. Wu, Y. Y. Li and Z. Yang. A NoC Simulation and Verification Platform
Based on SystemC. CSSE ’08: International Conference on Computer Science
and Software Engineering.
[Yon10] Y. Bu, Z. Tao, M. Lei, C. Wu and C. Wu. A Configurable SystemC Virtual Platform
for Early Software Development and its Sub-system for Hardware Verification.
VLSI-DAT ’10: VLSI Design Automation and Test.
[Gra06] Cool Verification. www.coolverification.com/2006/06/python as an hv.html.
[Let08] D. Lettnin, P. K. Nalla, J. Ruf, T. Kropf and W. Rosenstiel. Verification of Temporal
Properties in Automotive Embedded Software. DATE ’08: Design, Automation
and Test in Europe.
[Hab04] A. Habibi, A. Gawanmeh and Sofiene Tahar. Assertion Based Verification of
PSL for SystemC Designs. SOC ’04: International Symposium on System-on-Chip.
[Ruf06] J. Ruf, R. Weiss, D. V. Lettnin, S. Lämmermann, T. Kropf und W. Rosenstiel.
SystemC Temporal Checker. Tübingen ’06: Department of Computer Engineering.