Nachweisbare Tests für funktionale Sicherheit auf Serienhardware durchführen

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Parasoft® Deutschland GmbH

PLS Programmierbare Logik & Systeme GmbH

Auf Herz und Nieren prüfen: Die Rolle des Debuggers

Der Debugger bildet im gesamten Ecosystem, das für die Entwicklung von eingebetteter Software zur Verfügung steht, die eigentliche Schnittstelle zum Zielsystem. Das eignet ihn besonders gut zum Test auf echter Hardware und unter realen Bedingungen. Ein typischer Debugger wie die Universal Debug Engine (UDE) von PLS, der sich vorrangig verfügbare Debug-Schnittstellen wie z.B. das bekannte JTAG zu Nutze macht, besteht meist aus zwei Elementen: einem Zugangsgerät wie dem Universal Access Device 2next (UAD2next), das die Adaption der Debug-Signale des Zielsystems übernimmt, und der eigentlichen Debugger-Software auf dem PC. Zugangsgerät und PC kommunizieren über die für das PC-Umfeld typischen Schnittstellen wie USB oder Ethernet.

Bildergalerie

Der direkte Zugang zum Mikrocontroller über eine dedizierte Schnittstelle erlaubt dem Debugger neben der Ermittlung des aktuellen Target-Zustandes auch dessen Beeinflussung. Dies alles geschieht mittels gezielter Lese- und Schreibzugriffe auf Register und Speicher über die Debug-Infrastruktur des jeweiligen Controllers und – ganz wichtig – ohne nennenswerten Einfluss auf die Zielapplikation. Damit ist die Hauptanforderung für das Testen auf realer Hardware erfüllt. Aber der Debugger bietet noch mehr. So lassen sich beispielsweise neben globalen Variablen der Applikation, auch lokale Variablen von Funktionen und sogar einzelne Bits im Speicher oder in Registern auslesen oder ändern. Damit kann nicht nur die funkti¬onale Korrektheit des zu testenden Systems nachgewiesen bzw. wider¬legt werden. Der Entwickler kann so auch gleich nachvollziehen, warum sich das System möglicherweise nicht wie erwartet verhält.

Aber der Debugger bietet noch mehr. So lassen sich beispielsweise neben globalen Variablen der Applikation, auch lokale Variablen von Funktionen und sogar einzelne Bits im Speicher oder in Registern auslesen oder ändern. Damit kann nicht nur die funktionale Korrektheit des zu testenden Systems nachgewiesen bzw. widerlegt werden. Der Entwickler kann so auch gleich nachvollziehen, warum sich das System möglicherweise nicht wie erwartet verhält.

Zudem bieten Debugger die Möglichkeit, durch Breakpoints bei Erreichen bestimmter Positionen im Code die Programmausführung zu unterbrechen und auch wieder fortzusetzen. Im Testszenario lässt sich diese Basisfunktion ideal nutzen, um die funktionale Korrektheit sogenannter Freischnitte, also bestimmter Code-Sequenzen oder ausgewählter Funktionen, nachzuweisen.

Nun sind der Test und dessen Dokumentation alleine für die Sicherstellung einer hohen Softwarequalität noch nicht ausreichend. Auch die Testgüte spielt hier eine große Rolle. Als Maß dafür wird in vielen Fällen Code Coverage herangezogen, das sich unter bestimmten Voraussetzungen auch mit Hilfe des Debuggers ermitteln lässt. Code Coverage trifft eine Aussage darüber, wie hoch der Anteil am Code ist, die der jeweilige Test gestresst hat, gegenüber dem Anteil, der durch eine ungünstige Wahl von Testfällen gar nicht gestresst werden konnte.

Neben dem traditionellen Run-Mode-Debugging mit Breakpoints, Speichermanipulationen oder Single-Step-Betrieb bieten moderne Debugger wie die UDE zusätzlich auch Trace-basierte Analysefunktionen. Mit deren Unterstützung lassen sich Programmausführung inklusive aller Verzweigungen ohne vorherige Instrumentierung des Codes und ohne Beeinflussung der Laufzeit beobachten, Voraussetzung dafür ist lediglich die Verfügbarkeit von Trace-Hardware auf dem jeweiligen Mikrocontroller, was aber heutzutage schon fast selbstverständlich ist. Trace eignet sich hervorragend, das Code Coverage während der Testläufe zu bestimmen und damit gleich den Nachweis für eine ausreichende Testgüte zu erbringen.

Entscheidend ist die einfache Testkopplung

In der Praxis nutzt wenig, wenn der Debugger zwar für den Test auf realer Hardware geeignete Funktionen besitzt, er aber für das Testsystem nur bedingt erreich- und nutzbar ist. Damit kommt ein weiterer wichtiger Aspekt ins Spiel: die Tool-Kopplung. Sie hat das Ziel, Testwerkzeugen wie ECU TEST oder TPT die Debugger-Funktionen zum Steuern des Zielsystems sowie zum Manipulieren und Auslesen der Target-Zustände bereitzustellen. Bei einer Kopplung mit der UDE von PLS wird dafür eine von der UDE dafür bereitgestellte Automatisierungsschnittstelle (UDE-Objektmodell) benutzt. Diese basiert auf dem Microsoft® Common Object Model (COM), das sich längst als De-facto-Standard in der Windows-Welt etabliert hat. Auch Microsoft selbst bietet einen großen Teil seiner neu hinzukommenden Windows-Funktionen über COM-Schnittstellen an. Über das UDE-Objektmodell stehen externen Tools nahezu alle Funktionen des Debugger wie Flash-Programmierung, Ablaufsteuerung, Lesen und Schreiben von Target-Speicher in symbolischer und numerischer Form, Trace-Daten-Erfassung, deren Analyse und vieles mehr zur Verfügung (Bild 3).

Im Falle der Kopplung von TPT an die UDE realisiert eine in C++ geschriebene DLL die Schnittstelle zwischen beiden Werkzeugen. Die Tests werden zunächst im Testsystem grafisch modelliert und dann wie bereits oben beschrieben die Automaten für den Test generiert. Dank beliebig vieler alternativer Signaldefinitionen bzw. Übergangsbedingungen lassen sich unterschiedlichste Varianten von Testfällen realisieren. Der eigentliche Test besteht aus der Abarbeitung des jeweiligen Automaten unter Berücksichtigung seiner jeweiligen Varianten. Dabei ist es zunächst egal, ob die Zielapplikation beispielsweise durch Matlab/Simulink als Modell simuliert wird oder ob es sich um ein reales eingebettetes System handelt, das den Code auch tatsächlich ausführt.

Im letzteren Fall werden für jeden Abarbeitungsschritt die vorher festgelegten Aktionen für die Manipulation des Zielsystems ausgeführt bzw. die Daten abgeholt (Bild 4). Durch die Kapselung der dafür benutzten UDE-Objektmodell-Funktionen in der DLL kommt der Testingenieur mit den eigentlichen Debugger-Funktionen der UDE nicht in Berührung, es ist also keine spezielle umfangreiche Einarbeitung erforderlich.

Testautomatisierung spart Zeit, Kosten und Nerven

Anforderungsmanagement und Qualitätssicherung

Testbarkeit und Testautomatisierung

PLS - Programmierbare Logik und Systeme präsentiert seine Tools und Lösungen auch vom 27. Februar bis 1. März 2018 auf der Embedded World in Nürnberg in Halle 4, Stand 4-310.

* Jens Braunes ist Product Marketing Manager bei der PLS Programmierbare Logik & Systeme.

(ID:45087348)