Autor: Daniel Penning<\/p>\n
Eine testgetriebene Entwicklung kann die Softwarequalit\u00e4t ma\u00dfgeblich steigern.\u00a0 F\u00fcr ein Embedded-System sind automatisierte Tests oft nur mit Einsatz spezieller Testhardware m\u00f6glich. Durch einen softwaregest\u00fctzten Dual-Target-Ansatz k\u00f6nnen Tests ohne zus\u00e4tzliche Hardware ausgef\u00fchrt werden. Dieser Artikel argumentiert, dass dabei die ausschlie\u00dfliche Verwendung klassischer Unittests nicht ausreichend ist. Es wird aufgezeigt, wie eine umfassendere Testumgebung aufgebaut werden kann.<\/strong><\/p>\n Agile Verfahren haben zu erstaunlichen Fortschritten in der Softwareentwicklung gef\u00fchrt. Trotz erwiesener Vorteile setzen sich SCRUM und \u00e4hnliche Verfahren zur Entwicklung eingebetteter Systeme allerdings nur langsam durch. Ein wesentlicher Grund sind spezielle „embedded“-Probleme, wie Hardwareabh\u00e4ngigkeiten und die Ausf\u00fchrungsumgebung der Software.<\/p>\n Der Kern agiler Vorgehen liegt darin, \u00c4nderungen in den Anforderungen im Projektverlauf zu begr\u00fc\u00dfen (embrace change<\/em>). Ver\u00e4nderungen an einer Codebasis k\u00f6nnen aber nur dann schnell erfolgen, wenn sichergestellt ist, dass die Anpassung keine bestehende Funktionalit\u00e4t beeintr\u00e4chtigt. Daher wird ein besonderer Fokus auf den automatischen Test der Software gelegt. Ein schnelles und belastbares Feedback f\u00fchrt dazu, dass Entwickler die Auswirkungen von gr\u00f6\u00dferen Ver\u00e4nderungen schnell absch\u00e4tzen k\u00f6nnen. Die Realisierung dieses Feedback-Elements stellt die zentrale H\u00fcrde in der erfolgreichen Umsetzung agiler Methoden f\u00fcr die Entwicklung eingebetteter Systeme dar. Fehlt dieses Element oder ist nur eine unzureichende Testabdeckung realisiert, kann das Potential derartiger Ans\u00e4tze nicht voll ausgesch\u00f6pft werden.<\/p>\n Abbildung 1 (siehe\u00a0PDF<\/a>) zeigt das im Folgenden betrachtete System zur Regelung von Leistungselektronik. Es besteht aus einer Kombination von DSP und FPGA. Auf dem DSP laufen ein Echtzeitbetriebssystem (RTOS) und die in C++ entwickelte Anwendung. Das FPGA erm\u00f6glicht die zeitlich exakte Messung von Signalwerten und das Stellen von Schaltern \u00fcber eine PWM mit genau definiertem Zeitverhalten. F\u00fcr die Untersuchung wird als Leistungselektronik ein Tiefsetzsteller betrachtet.<\/p>\n F\u00fcr dieses exemplarische System soll hier im Sinne der agilen Entwicklung ein testgetriebener Entwicklungsansatz vorgestellt werden. Wie eingangs beschrieben, erfordert dies die Bereitstellung eines schnellen und qualitativ hochwertigen Feedbacks. Dieses Feedback sollte zuverl\u00e4ssig Aufschluss \u00fcber die Stabilit\u00e4t des aktuellen Softwarestandes liefern und damit beispielsweise folgende Fragen beantworten:<\/p>\n (1) und (2) sind das klassische Einsatzgebiet von Unittests. Methoden werden unabh\u00e4ngig voneinander auf bestimmte Erwartungswerte gepr\u00fcft. F\u00fcr das Isolieren von Abh\u00e4ngigkeiten werden Stubs und Mocks eingesetzt. Diese Tests werden bereits zunehmend in der Embedded-Praxis eingesetzt. Da alle Hardware- und Systemabh\u00e4ngigkeiten isoliert sind, kann der zu \u00fcberpr\u00fcfende Code inklusive der Tests bereits f\u00fcr die Architektur des Entwicklungsrechners (PC) kompiliert und auch dort ausgef\u00fchrt und somit \u00fcberpr\u00fcft werden. Ausgezeichnete Literatur [1, 2] besch\u00e4ftigt sich mit der praktischen Umsetzung, insbesondere der f\u00fcr Unittests n\u00f6tigen Softwarearchitektur. Testframeworks wie googletest [3] unterst\u00fctzen den Entwickler bei der Formulierung aussagekr\u00e4ftiger Unittests in C++.<\/p>\n (3) zielt auf das Zusammenspiel der Software mit dem RTOS ab. Die Taskpriorit\u00e4t, das eingesetzte Scheduling-Verfahren und die zeitliche Verf\u00fcgbarkeit von Betriebsmitteln (Mutex, Queue, etc.) bestimmen ma\u00dfgeblich die Ausf\u00fchrreihenfolge der Tasks. Fehler bei der Auslegung der Software auf eine Multitasking-Umgebung f\u00fchren leicht zu Deadlocks, bei denen die komplette Ausf\u00fchrung unterbrochen wird. Die Abh\u00e4ngigkeit zum Betriebssystem und die zeitliche Dimension grenzen diese Integrationstests klar von klassischen Unittests ab. N\u00f6tige Testkonfigurationen m\u00fcssen f\u00fcr das Zielsystem \u00fcbersetzt und dort ausgef\u00fchrt werden. Das Ergebnis muss zudem auslesbar sein. Daher lassen sich solche Tests \u00fcblicherweise nur schwer realisieren.<\/p>\n (4) und (5) beziehen die externe Umgebung in die Tests ein. F\u00fcr bestimmte Ausgangssignale der externen Leistungselektronik wird erwartet, dass die Software mit definierten Stellsignalen reagiert. In der Praxis wird dieser Beweis \u00fcblicherweise mit Systemtests erbracht. Dazu wird entweder ein Hardwaresimulator oder – wenn m\u00f6glich – die reale externe Hardware an das System angeschlossen und der Ablauf \u00fcberwacht.<\/p>\n Das Konzept der klassischen Unittests l\u00e4sst sich direkt auf eingebettete Systeme \u00fcbertragen. Per definitionem k\u00f6nnen und sollen diese allerdings nicht die komplexe zeitliche Interaktion mit RTOS und externer Hardware pr\u00fcfen. In der klassischen Softwareentwicklung spielen diese Abh\u00e4ngigkeiten h\u00e4ufig nur eine untergeordnete Rolle. Das Ziel von eingebetteten Systemen ist allerdings gerade die Interaktion mit dieser\u00a0einbettenden<\/em>\u00a0Umgebung. Ein optimales Feedback l\u00e4sst sich hier nur realisieren, wenn auch die Integrationstests (3, 4, 5) einbezogen werden.<\/p>\n Praktisch ist eine manuelle Testausf\u00fchrung auf dem Zielsystem mit hohem Zeit- und Kostenaufwand verbunden und kann daher nicht in der gew\u00fcnschten Frequenz und kurzen Zeitspanne erfolgen. Daher muss eine M\u00f6glichkeit zur Automatisierung gefunden werden.<\/p>\n Unittests lassen sich leicht realisieren, da sie auf dem PC ausgef\u00fchrt werden k\u00f6nnen. Dazu wird ein sogenannter Dual-Target-Ansatz verwendet. Der eigentlich f\u00fcr das Zielsystem (hier der DSP) bestimmte Quellcode wird dabei zus\u00e4tzlich f\u00fcr die Architektur des PC (bspw. x86) kompiliert. F\u00fcr Integrationstests l\u00e4sst sich dieser Ansatz nicht direkt \u00fcbernehmen, da der Code Abh\u00e4ngigkeiten aufweist, die auf dem PC nicht vorhanden sind. Abbildung 2 (siehe\u00a0PDF<\/a>) zeigt diese Abh\u00e4ngigkeiten f\u00fcr das Beispielsystem.<\/p>\n Nahezu jedes gr\u00f6\u00dfere Embedded-System verwendet bereits die hier mit HAL (Hardware Abstraction Layer) bezeichnete Abstraktion von der eigentlichen Hardware. Wird dieser HAL in einer ausreichenden Form auch f\u00fcr den PC zur Verf\u00fcgung gestellt, so kann der gesamte Code bereits f\u00fcr den Entwicklungsrechner kompiliert und dort ausgef\u00fchrt werden. Die nicht l\u00e4nger vorhandene Hardwareabh\u00e4ngigkeit beschleunigt den Entwicklungsprozess und erm\u00f6glicht ein optimales Feedback durch jetzt leicht automatisierbare Integrationstests.<\/p>\n Das verwendete RTOS muss zun\u00e4chst f\u00fcr eine Ausf\u00fchrung auf dem PC \u00a0(bspw. unter Microsoft Windows\u00ae) simuliert werden. Dazu k\u00f6nnen die Tasks mit den nativen Threads, die auf jedem Desktop-Betriebssystem bereitstehen, nachgebildet werden. Ein besonderes Augenmerk muss dabei auf die Realisierung des Schedulers gelegt werden. Das RTOS verwendet ein pr\u00e4emptives Multitasking, kann also laufende Tasks jederzeit unterbrechen. Dieses Verhalten kann unter Windows simuliert werden, wenn der Scheduler in einem eigenen hochpriorisierten Task arbeitet. Alle eigentlichen Programm-Tasks werden in niedrigpriorisierten Threads gekapselt. Ein weiterer hochpriorisierter Task kann die Generierung von Interrupts simulieren. Diese Nachbildung kann sich je nach Betriebssystem als komplex und zeitaufwendig erweisen. F\u00fcr das popul\u00e4re FreeRTOS\u2122<\/strong>\u00a0existiert bereits eine offizielle Portierung f\u00fcr Windows [4].<\/p>\n Zus\u00e4tzlich m\u00fcssen n\u00f6tige Treiber f\u00fcr die Peripherie mit sinnvollen Implementierungen bereitgestellt werden.<\/p>\n Das Beispielsystem interagiert mit der zu beeinflussenden Leistungselektronik ausschlie\u00dflich \u00fcber das FPGA. Integrationstests sollen das Verhalten\u00a0 einer Regelung \u00fcberpr\u00fcfen k\u00f6nnen. Daher muss neben der reinen Nachbildung der FPGA-Bl\u00f6cke auch eine Simulierung der angeschlossenen Leistungselektronik erfolgen.<\/p>\n Abbildung 3 (siehe\u00a0PDF<\/a>) zeigt das Verhalten des PWM-Blocks. Die Nachbildung muss den zeitlich deterministischen Charakter erhalten. Dazu wird die in Abbildung 4 (siehe\u00a0PDF<\/a>) gezeigte Struktur verwendet. Mit einer zeitdiskreten simulierten Systemzeit wird ein Environment Controller (EC) implementiert. Der EC steuert das Ausl\u00f6sen von zeitabh\u00e4ngigen Events, bspw. des On-Events (Setzen des Ausgangs auf einen High-Pegel). Der PWM-Block selbst wird gleichzeitig mit einem Modell des angeschlossenen Systems verbunden.<\/p>\n Aus der bereits durchgef\u00fchrten Auslegung des Reglers stehen PLECS\u00ae-Modelle [5] f\u00fcr die Leistungselektronik \u2013 hier der Tiefsetzsteller – bereit. PLECS erm\u00f6glicht den Export dieser Modelle in einem ANSI-C kompatiblen Format. Die generierten zeitdiskreten Modelle k\u00f6nnen so leicht an den nachgebildeten PWM-Block angebunden werden. Das von der Anwendung benutzte FPGA-Interface kann nun auf ein realistisches Modell zugreifen. Stelleingriffe \u00fcber die Beeinflussung des PWM-Tastgrades f\u00fchren zu einer dynamischen Reaktion im Modell. Systemgr\u00f6\u00dfen k\u00f6nnen \u00fcber einen weiteren Analog-Digital-Block aus dem Code heraus ausgelesen werden.<\/p>\n Damit sind die Grundvoraussetzungen f\u00fcr Integrationstests geschaffen. F\u00fcr die automatisierte Ausf\u00fchrung m\u00fcssen die Signalverl\u00e4ufe von interessanten Kenngr\u00f6\u00dfen aufgezeichnet und mit vorgegebenen Referenzsignalen abgeglichen werden. Dazu wurde ein hier nicht n\u00e4her besprochenes Signalframework entwickelt, das die n\u00f6tigen Informationen aus XML-Dateien ausliest, Signale w\u00e4hrend der Testlaufzeit aufnimmt und eine automatische Beurteilung vornimmt.<\/p>\n Abbildung 5 (siehe\u00a0PDF<\/a>) zeigt einen Test zur Pr\u00fcfung der Abschaltlogik. Dabei wird zum Zeitpunkt t=4ms per Software das anliegende Modell so beeinflusst, dass es einen Lastkurzschluss simuliert. Die Abschaltlogik ist als Teil der Anwendung innerhalb des DSP in einem Regelungs-Task realisiert. An der Ausf\u00fchrung dieses Tests sind somit alle nachgebildeten Komponenten beteiligt. Weiterhin wird ein grafischer Export generiert, der in Abbildung 6 (siehe\u00a0PDF<\/a>) dargestellt ist. Aus diesem l\u00e4sst sich der Erfolg\/Nichterfolg des Tests verst\u00e4ndlich nachvollziehen.<\/p>\n Der entwickelte Ansatz zeigt, dass eine agile und testgetriebene Methodik f\u00fcr komplexe Systeme mit Hardwareabh\u00e4ngigkeiten m\u00f6glich ist. Dabei muss sichergestellt sein, dass der Entwickler zu jedem Zeitpunkt ein optimales Feedback f\u00fcr den Programmstand erh\u00e4lt. Ein komplett softwarebasierter Testansatz ist automatisierbar, minimiert die Feedbackzeit und senkt Kosten. Durch die Unabh\u00e4ngigkeit von realer Hardware l\u00e4sst sich bereits fr\u00fch entwickeln und die Time-to-Market senken.<\/p>\n Hardwarespezifische Details k\u00f6nnen so allerdings nur aufwendig, zeitabh\u00e4ngige Vorg\u00e4nge innerhalb des DSP \u00fcberhaupt nicht abgebildet werden. Systeme mit einem hohen Logikanteil werden dagegen von einer erh\u00f6hten Testabdeckung profitieren. Die Komplexit\u00e4t und der Umfang von Programmen f\u00fcr eingebettete Systeme steigen stetig. Gleichzeitig erlaubt die zunehmende Rechenleistung eine h\u00f6here Abstraktion auf Softwareebene. Daher ist anzunehmen, dass in Zukunft vermehrt Einsatzgebiete entstehen, die von der Anwendung einer solchen testgetriebenen Methodik profitieren.<\/p>\n [1]\u00a0 Martin, Robert C.: Agile software development: principles, patterns, and \u00a0\u00a0\u00a0practises. Prentice Hall PTR, 2003.<\/p>\n [2]\u00a0 Grenning, James W.: Test-driven development for embedded C. Pragmatic Bookshelf, 2011<\/p>\n [3]\u00a0https:\/\/github.com\/google\/googletest<\/a><\/p>\n [4]\u00a0\u00a0https:\/\/www.freertos.org\/FreeRTOS-Windows-Simulator-Emulator-for-Visual-Studio-and-Eclipse-MingW.html<\/a><\/p>\n [5]\u00a0https:\/\/www.plexim.com\/de\/plecs<\/a><\/p>\n Beitrag als PDF downloaden\u00a0<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinleitung<\/h2>\n
Problemstellung und Analyse<\/h2>\n
\n
L\u00f6sung<\/h2>\n
Beispiel<\/h2>\n
Zusammenfassung<\/h2>\n
Verweise<\/h2>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug – Fachwissen<\/h2>\n