Testen oder Nichttesten, das ist hier nicht die Frage…

Softwareentwicklung von Embedded-Systemen stellt insbesondere den KMU vor eine Herausforderung. Dort muss der Umfang an Kompetenzen auf wenige Köpfe verteilt werden. Die frühzeitige Erkennung von Fehlern während der Entwicklung ist hierfür eine Lösungsmöglichkeit. Aber der Erfolg von Softwaretests und die Testtiefe sind ebenso von der eingesetzten Hardware – genauer, des Mikrocontrollers – abhängig.

(Bild: iSystem AG)

Zeit in eine entsprechende Methodik zu investieren, lohnt sich übrigens für alle Firmengrößen. Allerdings werden sowohl die Einführung einer Testmethodik als auch die entsprechende Werkzeugausstattung als sehr aufwendig und teuer angesehen. Zusätzliche Ressourcen sind notwendig, um den Test sinnvoll umzusetzen und von der eigentlichen Softwareentwicklung zu trennen. Letztendlich ist der Erfolg des Softwaretests auf Embedded-Systemen sowie die zu erreichende Testtiefe auch abhängig vom Zugang zur Hardware bzw. des eingesetzten Mikrocontrollers. Die hierzu notwendigen Schnittstellen, auch Debug-Interface genannt, sind sehr unterschiedlich in ihrer Realisierung in Bezug auf Funktionalität und Einblick in den jeweiligen Mikrocontroller. Dies trifft insbesondere für 8- und 16Bit-Prozessoren zu. Mit der ’32Bit-Lösung für alle‘-Strategie hat ARM die Halbleiterwelt verändert. Alle Hersteller wählen heute ARM als CPU für ihre Mikrocontroller anstatt auf proprietäre Systemarchitekturen zu setzten. Diese Art von Standardisierung erleichtert dann auch das Testen. Zumindest dahingehend, dass z.B. ein CoreSight Debug und Trace-Modul quasi umsonst mitgeliefert wird. Unabhängig von der Bezugsquelle des Mikrocontrollers profitiert man besonders von den größtenteils genormten Modulen, die neue Einsatzmöglichkeiten und Unterstützung für Embedded-Entwickler und -Tester bieten.

Was man bei der Auswahl eines Mikrocontrollers richtigmachen kann

CoreSight ist eine Sammlung von obligatorischen und optionalen Intellectual-Property (IP)-Blöcken, die ein Halbleiterhersteller eines ARM-basierten Mikrocontrollers (z.B. Cortex-M) einbeziehen kann. Diese IP-Blöcke liefern unter anderem die Debugging-Schnittstelle selbst sowie Unterstützung für Haltepunkte und Zugang zu den Speicherbereichen um den Flash des Mikrocontrollers zu programmieren und die CPU zu debuggen. Weitere Module ermöglichen die Aufzeichnung des Programmablaufs und Datenspeicherzugriffe zur Laufzeit einer Anwendung. Wichtige Einblicke und Informationen zur Untersuchung von Embedded-Systemen, die asynchrone Datenverbindungen implementieren oder solche, die Codeabdeckung für die Dokumentation und Zertifizierung benötigen. Aufgrund der Vielzahl von obligatorischen und optionalen Modulen der CoreSight-Architektur lohnt es sich, Datenblatt und Dokumentation eines zur Auswahl stehenden Mikrocontrollers im Vorfeld einer Entwicklung genauer unter die Lupe zu nehmen. CoreSight in Kombination mit geeigneten Entwicklungswerkzeugen öffnet eine Vielzahl an Möglichkeiten, Testing schon vor Projektstart systematisch mit einzuplanen. Das erleichtert die Entwicklung von sicherem Code sowie der Erhöhung der Zuverlässigkeit einer Anwendung. Ist der Test fester Bestandteil des Entwicklungsprozesses, können Tests kontinuierlich während des Entwicklungszyklus aufgerufen werden, um die mögliche Auswirkung gewünschter (und unerwünschter) Änderungen des Codes rechtzeitig zu prüfen. Solch eine Vorgehensweise liefert ein erhöhtes Vertrauen in die Software sowie damit auch in das endgültige Produkt. Ein solches Entwicklungswerkzeug stellt die iSystem in Form der integrierten Entwicklungsumgebung winIDEA und dem dazugehörigen Hardware-Debugger iTAG.2K zur Verfügung. Dieser Einstiegsdebugger eignet sich für eine große Anzahl an MCUs von Herstellern wie Infineon, ST, Atmel (mittlerweile Microchip), NXP und Cypress. Hierdurch ist die Investition in die Werkzeuge projektübergreifend gesichert.

Integriertes Testwerkzeug als fester Bestandteil einer Entwicklungsumgebung

iSystem hat das Original-Binary-Code (OBC)-Testwerkzeug test-IDEA in seine Entwicklungsumgebung eingebettet. Damit ist es schon während der Entwicklung von Softwaremodulen möglich, deren Funktionalität gegen die Anforderung zu prüfen. Solche Tests werden zusammen mit dem Quelltext gespeichert und sind somit in der Regression verwendbar. Es wird damit sichergestellt, dass sich keine Fehler anhand von Änderungen eingeschlichen haben. Falls sich die Anforderungen ändern, kann der Test ebenfalls auf den neusten Stand gebracht werden. Der Quereinstieg eines Entwicklers in ein Projektteam ist somit leichter möglich, die Produktivität des Teams erhöht sich. Zur Ausführung der Tests benötigt man einen gültigen winIDEA Workspace zusammen mit einer ausführbaren, übersetzten Binary-Datei und den Zugang zum Zielsystem über die Debug-Schnittstelle des Mikrocontrollers.

Codeabdeckung, das Maß aller Dinge

Ohne alle Entscheidungszweige im Code vollständig zu durchlaufen (Codeabdeckungsanalyse), sind nicht alle möglichen Codefehler aufzufinden. CoreSight Micro Trace Buffer (MTB, implementiert auf Cortex-M0+) und die Embedded Trace Macrocell (ETM, implementiert auf Cortex M3, M4 und M7) liefern testIDEA sogenannte Trace-Daten zur Messung der Codeabdeckung. Mit dieser Metrik wird zudem sichergestellt, dass die definierten Tests auch tatsächliche alle Zweige und Entscheidungsbefehle ausführen und damit kein ‚toter‘ Code mit dem Produkt ausgeliefert wird. Codeabdeckung ist also auch ein Maß der Güte von Testfällen. ETM ist eine vollständige Programm-Trace-Lösung, die digitale I/O-Pins der MCUs für diesen Zweck benötigen (typischerweise fünf). Auf dem Cortex M7 kann dieses Modul auch für die Ausgabe von Data-Trace verwendet werden. Wenn diese Fähigkeit zusammen mit OBC Unit Testing in testIDEA genutzt wird, bekommt man den gesamten Codeabdeckungsgrad für die Tests. Damit ist gesichert, dass der Test auch die verborgenen Winkel des Codes untersucht hat. Der MTB liefert ebenfalls Programm-Trace, ist aber in seinem Umfang etwas begrenzt gegenüber ETM. Das liegt daran, dass die Trace-Daten in einem reservierten Bereich des SRAMs untergebracht werden und so die Länge der Aufzeichnung und die Größe des zur Verfügung stehenden SRAM für die Anwendung reduziert wird. Zum anderen werden aufgrund der Technologie des MTB die Trace-Daten nicht in Echtzeit von einem Debug-Tool ausgelesen. Trotzdem kann der MTB zur Messung von Codeabdeckung einzelner Funktionen eingesetzt werden. Da testIDEA auf das Testen von einzelnen Funktionen ausgerichtet ist, beschränkt sich der Bedarf an SRAM auf Stack und Heap während der Testausführung. Für den Schnelleinstieg ins Original Binary Code Testing bietet sich ein Arduino M0 Pro oder Arduino/Genuino Zero Board an, welche mit einem SAM D21 MCU ausgestattet sind. Diese Boards haben eine integrierte CMSIS-DAP-Debugschnittstelle und werden direkt von winIDEA Open (eine kostenlose Entwicklungsumgebung von iSystem) aus programmiert. Das unter 1) aufgeführte Projekt implementiert einen einfachen Regler für einen Ofen. Dieses enthält auch ein Beispiel für testIDEA, womit ein relativ einfacher Codefehler in dem Softwareregler aufgedeckt werden kann, bevor der Kunde den Fehler während der Inbetriebnahme findet. Mehr hierzu unter Link 2). Falls Sie gerade bei der Auswahl einer neuen MCU-Plattform sind, vergessen Sie nicht, dass Cortex-M nicht immer gleich Cortex-M ist. Die Technology von ARM bietet umfassende und leistungsfähige Debug- und Trace-Funktionen, aber nur solange die MCU-Hersteller diese auf dem jeweiligen Silizium auch umgesetzt haben. Treffen Sie rechtzeitig die richtige Produktentscheidung, damit Sie auch in aussichtlosen Situationen einen Plan-B zur Verfügung haben.