Test-Beschreibung und -Automatisierung zur Software-Verifikation
Virtuelle Prototypen unter Einsatz der TTWorkbench

In modernen Fahrzeugen wachsen die Komplexität und die sicherheitsrelevanten Anforderungen von verteilten eingebetteten Systemen ständig. Das führt in der traditionellen automobilen Systementwicklung zu einem hohen Verifikationsaufwand und kostenintensiven Entwicklungsiterationen über verschiedene Entwicklungsphasen hinweg. Um die Verifikation verteilter Systeme schon in frühen Entwicklungsphasen zu ermöglichen, schlagen wir einen flexiblen und effizienten virtuellen Prototyping-Ansatz vor, der Modul- und Integrationstests für Protokoll- und Applikationssoftware ermöglicht.
Über die letzten Jahre hinweg sind zum einen die Anforderungen und die Komplexität von verteilten Systemen in der Automobilindustrie drastisch angestiegen. Die neu integrierten Fahrerassistenzsysteme müssen hohe Sicherheitsstandards erfüllen. Auf der anderen Seite zwingt hoher Konkurrenzdruck die Unternehmen zu kosteneffizienten Entwicklungsprozessen und kurzen Markteinführungszyklen. Diese Notwendigkeiten stehen im Gegensatz zu den hohen Verifikationsanstrengungen und den steigenden Sicherheitsanforderungen.

Verifikationskosten reduzieren

Softwaretests auf virtuellen Prototypen in frühen Entwicklungsstadien sind dabei eine Möglichkeit, die Verifikationskosten zu reduzieren. Obwohl die frühe Verifikation zusätzlichen Test- und Modellierungsaufwand erfordert, können damit die Kosten durch den Wegfall kostenintensiver Entwicklungsiterationen über verschiedene Entwicklungsphasen reduziert werden. Dies gilt vor allem für komplexe verteilte Systeme. Weit verbreitete Techniken für frühe Verifikation sind Model-In-the-Loop (MIL) und Software-In-the-Loop (SIL). Beide Techniken erlauben frühes Testen von Software ohne die Betrachtung der Zielhardware. Der Hauptnachteil dieser Techniken ist, dass durch die Nichtbeachtung der Hardwarecharakteristika und des Zeitverhaltens hardwarebezogene Softwarefehler nicht auffindbar sind. Um diese Lücke zwischen MIL, SIL und Hardware-In-the-Loop (HIL) zu schließen, schlagen wir den Einsatz von Virtual-Hardware-In-the-Loop (VHIL) als zusätzlichen Verifikationsschritt vor. Der vorgeschlagene VHIL-Ansatz wurde auf das MOST (Multimedia Oriented Systems Transport) High Protokoll angewandt. Das MOST High Protokoll (MHP) leistet den Datentransfer in MOST Netzwerken. Es ist ein verbindungsorientiertes Protokoll, das einige Mechanismen des Übertragungskontrollprotokolls TCP benutzt. Der virtuelle Prototyp liefert präzise Zeitinformationen und das funktionelle Verhalten der endgültigen Hardwareimplementierung auf Softwareebene. Testbeschreibung, Ausführung und Analyse werden mit Hilfe der TTWorkbench von Testing Technologies durchgeführt. Die TTWorkbench ist eine TTCN-3-basierte Testmodellierungs- und Automatisierungsumgebung. Durch Anbindung des virtuellen und des realen Netzwerkes erlaubt dieser Ansatz die Wiederverwendung der entwickelten Testfälle für Modul-, Integrations- und Regressionstests auf virtueller und realer Hardware.

Virtueller Prototyp für die MHP-Verifikation

Der virtuelle Prototyp für MOST MHP besteht aus einer konfigurierbaren Anzahl an Geräten und den dazugehörigen Vernetzungskomponenten. Die Geräte integrieren den originalen MHP Protokoll-Stack und werden als nebenläufige Prozesse durch Einsatz von SystemC und C++ modelliert. SystemC ist eine Modellierungs- und Simulationssprache, die basierend auf C++ Nebenläufigkeits- und Zeitaspekte während der Simulation von eingebetteter Software und der zugrundeliegenden Hardwareplattform abdeckt. Die Geräteverbindungen werden zur Beschleunigung der Systemsimulation durch Einsatz von Transaction-Level Modeling (TLM-2.0) Techniken realisiert. TLM ist ein High-Level-Ansatz zur abstrakten Modellierung der Kommunikation zwischen virtuellen Geräten.

Geräte-Modellierung und -Verbindung

Um das zeitliche und funktionelle Verhalten der Hardware zu simulieren, ist es nötig, verschiedene Elemente, die entweder Hard- oder Softwarekomponenten darstellen, zu integrieren. Die Softwarekomponenten sind der gekapselte MHP Protokoll-Stack, die Callback-Funktionen und die Applikation. Hardwarekomponenten sind beispielsweise das NetInterface, das den INIC (Intelligent Network Interface Controller) repräsentiert, oder das Zeitgebermodul, welches dem Protokoll-Stack die Zeitfunktionalität bereitstellt. Um das Testen verschiedener Protokollversionen oder Anwendungen zu unterstützen, können die Komponenten des virtuellen Geräts ausgetauscht werden. Dazu wird eine Bibliothek eingeführt, die leicht mit neuen Hard- oder Softwarekomponenten erweitert werden kann. Diese Elemente werden vor Simulationsstart durch die Plattformkonfiguration ausgewählt. Zur Kommunikation mit anderen Geräten enthält jedes Gerät einen TLM 2.0-Port. Der Datenaustausch über den TLM-Port ist abstrahiert, das heißt es wird nicht jedes Bit eines Frames simuliert, sondern es werden komplette MHP-Nachrichten zwischen den verschiedenen Geräten übertragen. Die Technik, die die Ports der Geräte verbindet, bezeichnet man als Many-to-Many-Binding. Beide Abstraktionen führen zu wachsender Simulationsperformanz und haben einen minimalen Effekt auf das Zeitverhalten während der Simulation.

Plattformkonfiguration

Das Simulationsmodell wird durch XML-Dateien konfiguriert, die vor Simulationsstart geladen werden. Die Konfigurationsdatei umfasst die Netzwerk- und Gerätekonfiguration. Die Transaktionen für die transaktionsbasierte Protokollverifikation werden durch das angeschlossene TTWorkbench Testwerkzeug definiert. Die Netzwerkkonfiguration definiert die Simulationszeit, den Testhost und bis zu 64 MOST Geräte. Die Gerätekonfiguration selektiert Elemente wie etwa die Applikation oder die Version des Protokoll-Stack aus der Bibliothek und konfiguriert das Element selbst.

Überwachung und Kontrolle

Verschiedene Elemente der virtuellen Prototypen umfassen Monitore zur Überwachung von beispielsweise Statuswechseln, Paketverlusten und Nachrichten, die während der Simulation über den Kommunikationskanal ausgetauscht werden. Diese Daten werden zur späteren Analyse zusammen mit Zeitstempeln in Dateien gespeichert. Dazu werden verschiedene Dateiformate unterstützt wie etwa ein Textformat und ein Format, das von der SMSC OptoLyzer Suite oder dem MOST System Radar verarbeitet werden kann. Dies stellt sicher, dass die Simulationsergebnisse des virtuellen Prototypen mit den Ergebnissen bei Einsatz der realen Hardware mithilfe der gleichen Werkzeuge untersucht werden können. Die Kontrolle und die Überprüfung der Transaktionssequenzen sowie des Zeitverhaltens während der Simulation erfolgt durch die TTWorkbench. Die Anbindung mit der virtuellen oder der realen Umgebung ist über den Testhost realisiert. Das erlaubt der TTWorkbench, MHP-Nachrichten anzustoßen und zu empfangen. Mit dem Host können gleichzeitig mehrere Quellen und Senken simuliert werden, der virtuelle Host erlaubt zusätzlich das Steuern der Applikationen über die TTWorkbench. Die Testspezifikation und Testausführung innerhalb der TTWorkbench erfolgt mittels der Testing and Test Control Notation Version 3 (TTCN-3). Diese unterstützt verschiedene Varianten von Black-Box-Tests und ist für kommunikationsbasierte Systeme besonders geeignet. Die Testspezifikation kann mit Hilfe von Sequenzdiagrammen oder durch textuelle Beschreibung, die einer modularen Programmiersprache ähnelt, erfolgen. Neben verschiedenen Datentypen und weiteren, typischen Programmiersprachen-Elementen sind spezielle Elemente beispielsweise für Zeitdefinitionen verfügbar.

Anbindung der TTWorkbench an den virtuellen Prototypen

Die Anbindung der virtuellen Plattform an die TTWorkbench erfolgt über eine Softwareschnittstelle im virtuellen Testhost. Dieser stellt eine Verbindung mit den virtuellen Prototypen her, was wiederum der TTWorkbench erlaubt, das Netzwerk zu stimulieren und empfangene Nachrichten zu überprüfen. Darüber hinaus wird die Zeit der virtuellen Plattform mit der Zeit der TTWorkbench über die angesprochene Softwareschnittstelle synchronisiert. Die Anbindung der TTCN-3 basierten Testspezifikation hin zum ‚System under Test‘ (SUT) erfolgt über den Codec und den Testadapter (TA) der TTWorkbench. Die Aufgabe des Codec ist die Übersetzung definierter TTCN-3-Nachrichten in Nachrichten, die durch den virtuellen Prototyp verarbeitet werden können. Der Testadapter ist für die Kommunikation mit dem SUT verantwortlich, wobei eine Anzahl verschiedener Sprachen unterstützt werden. Das garantiert volle Übertragbarkeit auf verschiedene Plattform-Implementierungen. Damit wird auch die Anbindung realer MOST Hardware an die TTWorkbench ermöglicht, ohne irgendwelche Änderungen am Codec oder der TTCN-3 basierten Testbeschreibung vornehmen zu müssen.

Testen in frühen Entwicklungsstadien

Die Verbindung zwischen virtuellem Prototypen und der TTWorkbench erlaubt das Testen bereits in frühen Entwicklungsstadien. Um die Kommunikationssequenzen auszuführen, stehen Sende-, Empfangs- und Wartefunktionen zur Verfügung, die den Testhost für reale und virtuelle Prototypen kontrollieren. Zusätzlich zur Transaktionsdefinition muss zum Test mit virtuellen Prototypen die Plattform definiert sein. Dieses Problem wird durch den Aufruf einer externen Konfigurationsdatei über die Softwareschnittstelle des Host gelöst. Dieser Ansatz der frühen Softwareverifikation verteilter, eingebetteter Systeme berücksichtigt das funktionale und zeitliche Verhalten der Hardware. Er ermöglicht die Wiederverwendung der spezifizierten Tests auf virtuellen Prototypen zum Test der Software auf realer Hardware ohne Modifikationen. Die Analyse der Testergebnisse kann mit gewohnten Werkzeugen für die Verifikation auf realer Hardware oder mit zusätzlichen Werkzeugen wie z.B. einem Software-Debugger (schrittweise Ausführung und Beobachtung) vorgenommen werden. Darüber hinaus zeigt die Forschung, dass aufgrund der großen Simulationseffizienz und der einfachen Testautomatisierung beim Einsatz virtueller Prototypen die Testabdeckung signifikant erhöht werden kann.