Startseite > Embedded > Entwicklungstools > Modellbasiert auf Serien-Hardware testen

Automatisch testen und debuggen

Modellbasiert auf Serien-Hardware testen

26. Februar 2016, 13:04 Uhr | Von Heiko Rießland und Dirk Tetzlaff

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Schrittweiser Datenaustausch

Mit den passenden externen Tools ist die Schnittstelle auch mit unterschiedlichen Programmiersprachen wie C, C++, C# und .NET nutzbar. So bildet eine in C++ geschriebene DLL die Verbindung zwischen TPT und der Universal Debug Engine. Damit können in jedem Simulationsschritt beliebige Debugger-Funktionen aufgerufen und beispielsweise vollautomatisch Haltepunkte gesetzt werden. An jedem dieser Haltepunkte lässt sich vom Anwender genau definieren, welche Größen des zu testenden Systems mit vorgegebenen Daten belegt oder ausgelesen werden. Darüber hinaus kann die Ausführung an beliebiger Stelle durch Umsetzen des Befehlszeigers fortgesetzt werden. Dieser Ansatz bietet gegenüber anderen Kopplungen, die über die Schnittstelle zum Zielsystem nur Größen ändern und ermitteln können, den großen Vorteil, dass sich zusätzlich auch noch beliebige Speicherbereiche und Register der Ziel-Hardware, einzelne Bitpositionen und sogar lokale Variablen von Funktionen setzen und auslesen lassen. So ist es nun erstmals möglich, nicht nur die funktionale Korrektheit des zu testenden Systems nachzuweisen bzw. zu widerlegen, sondern darüber hinaus auch gleich mit aufzuzeigen, warum sich das System nicht wie erwartet verhält. Da in jedem Simulationsschritt mehrere Aktionen des UDE-Debugger auf der Ziel-Hardware ausgeführt werden können, ist außerdem der Test der funktionalen Korrektheit von Freischnitten des zu testenden Systems vollautomatisch durchführbar.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Bild 3 zeigt die Konfiguration der UDE-Kopplung mit dem TPT-Verfahren. In der oberen Tabelle werden Breakpoints auf der Ziel-Hardware, in der mittleren auszuführende Aktionen des UDE-Debugger pro Simulationsschritt und in der unteren zu setzende und/oder auszulesende Größen der Ziel-Hardware und des zu testenden Systems festgelegt. Die Haltepunkte können vom Anwender dabei wahlweise an eine absolute hexadezimale Adresse, an den über deren Namen spezifizierten Beginn einer Funktion, an das Ende einer Funktion oder an eine bestimmte Zeile in einer Quellcode-Datei gesetzt werden. Für die Beschreibung der einzelnen Aktionen, die pro Simulationsschritt durch die UDE auszuführen sind, wird eine Zustandsmaschine genutzt, wobei die Haltepunkte die Zustände sind und Zustandsübergänge durch Fortsetzen der Ausführung bis zum Ziel-Haltepunkt (Schlüsselwort: run) oder durch Umsetzen des Befehlszeigers (Schlüsselwort: setNextStatement) beschrieben werden.

Da die Steuerungsschritte für die UDE aus der mittleren Tabelle ‚Program‘ (Bild 3) nicht zeilenweise abgearbeitet werden, lassen sich einmalig durchzuführende Aktionen wie z.B. die Speicher-Initialisierung von der eigentlichen Testdurchführung separieren. In dem beschriebenen Beispiel werden nach dem Programm-Start die ersten drei Zeilen einmalig ausgeführt und dann mit den nächsten beiden Zeilen die Ausführung von function_start über function_middle nach function_end fortgesetzt. Durch die Programmausführung als Zustandsmaschine stehen die darauf folgenden Schritte in der letzten Zeile, gefolgt von der vorletzten, und die Testdurchführung iteriert ab diesem Punkt bei function_start.

Einbindung in den modellorientierten Workflow

Der Test komplexer Embedded Software verlangt zunehmend nach ganzheitlichen Ansätzen auf Systemebene und modellbasierten Methoden. Welche Rolle Hardware-nahe Debugger bei diesem sich seit geraumer Zeit abzeichnenden Paradigmenwechsel künftig einnehmen werden, hängt nicht zuletzt vor allem davon ab, wie einfach und zuverlässig sich ihre Funktionen von anderen Programmen innerhalb der Werkzeugkette nutzen lässt. Wie am Beispiel des engen Zusammenwirkens von TPT und UDE deutlich wird, sind hier im Idealfall komplett neue Workflows denkbar, die Entwicklern vor allem im Hinblick auf automatisierte Testverfahren für Serien-Hardware völlig neue Möglichkeiten erschließen.

Die Autoren

Dr.-Ing. Dirk Tetzlaff
hat an der TU Berlin studiert, mit Abschluss als Diplom-Informatiker im Jahr 2007. Danach war er bis 2013 wissenschaftlicher Mitarbeiter am Lehrstuhl Programmierung eingebetteter Systeme unter der Leitung von Prof. Dr. Sabine Glesner. Bei ihr hat er 2014 promoviert und arbeitet seitdem bei der Firma PikeTec GmbH als Software Engineer und Consultant.

Dipl.-Ing. Heiko Rießland
hat an der Technischen Universität Dresden Informationstechnik studiert. Seine berufliche Laufbahn begann der Diplomingenieur 1992 als Software-Entwickler bei der Firma PLS. Nach einigen Jahren wechselte er in den Vertrieb von Entwicklungswerkzeugen für 16- und 32-bit-Mikrocontroller. Seit acht Jahren leitet er das Produktmarketing von PLS.

Heiko.Riessland@pls-mc.com