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.
