Softwaretest

Vorgehen und Werkzeuge für den Softwaretest im Bereich von Embedded Systemen haben in der Regel stark abweichende Anforderungen im Vergleich zum Test von so genannter Anwendungssoftware.

Was sind die wesentlichen Unterschiede?
Einer der größten ist sicherlich, dass die zu testende Software nicht auf derselben Hardware läuft, auf der auch die Entwicklung stattfindet. Wir unterscheiden in diesem Sinn zwischen der Hostplatform, auf der die eigentliche Entwicklung der Software stattfindet und der Target Platform, auf der die entwickelte Software letztendlich läuft.

Diese hat im Allgemeinen eingeschränkte Ressourcen an Speicher und Rechenleistung. In der Regel wird z.B. für automatisch ablaufende Tests, die Software des so genannten SUT (System Under Test) instrumentiert. Dieses führt zu zusätzlichem Speicherbedarf für den instrumentierten Code, der auf dem Target System nicht vorhanden ist. Natürlich beeinflusst die Instrumentierung auch das Zeitverhalten, was wiederum dazu führen kann, dass bei laufzeitorientierten Systemen ein großer Teil der Aussagekraft der Testergebnisse verloren geht.  

Letztendlich würde auch ein Test auf Basis des instrumentiertem Code im Rahmen von sicherheitsrelevanten Systemen einer Zertifizierung nicht standhalten.

Es gibt noch einen weiteren Unterschied: Interfaces, die auf der Target Platform verfügbar sind, fehlen auf der Host Platform. Würde der Test z.B. in Form einer Simulation auf der Host Platform ausgeführt werden, müssten alle Interfaces durch Stubs ersetzt werden, was in manchen Fällen sehr aufwändig sein kann.

Aus diesen und anderen Gründen müssen aussagekräftige Tests von Embedded Software auf der Target Platform stattfinden und das Umfeld (die so genannte Strecke) mit abbilden, wie es beispielsweise in HIL (Hardware In The Loop)-Testsumgebungen geschieht. Dieses stellt an das Testequipment besondere Herausforderungen, weshalb spezielle Methoden und Werkzeuge angewendet werden.

Hier finden Sie Informationen zu folgenden Themen:
Test Management
Dynamisches Testen
Statisches Testen

Softwareentwicklung in C für Mikroprozessoren und Mikrocontroller

Jörg Wiegelmann
*
Softwareentwicklung in C für
Mikroprozessoren und Mikrocontroller
*
6. überarbeitete Auflage 2011 - VDE Verlag GmbH
*
319 Seiten, 39,90 Euro
*
ISBN 978-3-8007-3261-6 

Bei einer 6. Auflage des Buches „Softwareentwicklung in C für Mikroprozessoren und Mikrocontroller“ könnte man denken: Ist C denn überhaupt noch zeitgerecht? Objekt-orientierte Programmierung mit C++, Java oder Modellierung mit UML sind doch derzeit in aller Munde. Ich meine, dieses Buch macht trotzdem Sinn. Vielleicht hätte der Name anders gewählt werden können, denn es ist nicht unbedingt ein Buch, um die Hochsprache C zu lernen.

Jörg Wiegelmann startet zwar mit dem Kapitel „Kurze Einführung in die Sprache C“, und mit rund  30 Seiten werden kurz und knapp die wesentlichen Notationselemente abgehandelt. Wer keine C-Kenntnisse hat, sollte sich jedoch noch ein Buch über ANSI-C dazu nehmen, in dem das eine oder andere noch einmal ausführlicher nachzulesen ist. Die Hauptqualitäten des Buches wird man jedoch nicht unbedingt in diesem Kapitel finden, eher in dem dargebotenen Know-how zur allgemeinen Embedded-spezifischen Programmierung und in Hinweisen zur Anwendung von Werkzeugen. Erfreulich ist, dass der Bereich über Pointer und deren Vor- und Nachteile ausführlicher behandelt wird. Spätestens hier merkt man, dass es weniger ein Grundlagenbuch über die Anwendung von C ist, sondern viel mehr die Stolperfallen in der Anwendung von C thematisiert. Ebenso erfreulich ist die ausführliche Behandlung der #INCLUDE Präprozessoranweisungen in Verbindung mit Header-Files; bilden sie doch die Grundlage für einen modularen Aufbau von Programmen, dem am Anfang der Programmierung häufig zu wenig Bedeutung beigemessen wird. Auch hier wieder reichlich praktische Erfahrungen, was schief gehen kann und wie es verhindert wird - für Einsteiger sicher sehr hilfreich. Und so geht es weiter: Im Kapitel über Compiler werden die verschiedenen Speichermodelle erläutert, die Aufgaben des Linkers, Make und immer wieder werden Stolpersteine behandelt, zum Beispiel wie sich die Compiler-Optimierungen auswirken und beim Debuggen für reichlich Verwirrung sorgen können; oder wann Variablen, die nur extern beschrieben werden vom Compiler weg optimiert werden. Nicht selten haben Entwickler Tage mit Effekten zugebracht, die durch Optimierungen des Compiler verursacht werden.

In Kapitel 9 „C-Programmierung für Embedded Systeme“ geht es ins Eingemachte: Hier wird erläutert, wie Mikrocontroller spezifische Hardware-Komponenten mit Hochsprache angesprochen werden können. Es werden die wichtigsten sogenannten NON ANSI-Erweiterungen der Compiler besprochen, die hierfür notwendig sind, zum Beispiel der Umgang mit Bits anstelle von Bytes, oder der Einsatz von Interrupts. Verständlicherweise geht Jörg Wiegelmann hier nicht in die Tiefe, da dieser Bereich sehr CPU- und Compilerspezifisch ist. Aber die Grundlagen werden angesprochen, so dass die Handbücher der Compiler auf dieser Basis sicher gut verstanden werden. Erfreulich: Auch hier wieder praktische Elemente; zum Beispiel werden nicht - wie häufig üblich - nur die Programmierung von Interrupt-Service-Routinen angesprochen, sondern auch die Kommunikation derselbigen zur Systemebene unter anderem mit der Problematik bei preemptivem Verhalten. Und wieder werden nicht nur die Probleme aufgezeigt, sondern auch probate Mittel, dem zu begegnen, etwa durch die Verwendung von Semaphoren. Leider wird nicht auf asynchrone Kommunikation als eine der elegantesten Möglichkeit eingegangen.

Weiter geht es mit Kapitel 9.7 „Betriebssystem“. Hier werden die Basis-Scheduling-Pattern beschrieben, angefangen bei der einfachen main() Loop bis hin zu preemptivem Multitasking und den damit verbundenen Pattern zur Kommunikation, für den Einstieg sicher gut zu wissen. Alles wird angesprochen, Speicherverwaltung, Anwendung von Interrupt-Routinen in Kombination mit dem Betriebssystem, Hardware Treiber ...

Ein kleiner Wermutstropfen auch an dieser Stelle: Ich vermisse Hinweise auf die sinnvolle Kombination von Scheduling- und Kommunikations-Pattern, beziehungsweise die Problematiken, die bei ungünstigen Kombinationen entstehen, zum Beispiel bei preemptivem Scheduling und synchroner Kommunikation auf Basis von Signalen, was heute sehr häufig anzutreffen ist. Auch interessant für den Einsteiger, das Kapitel 9.11 „Steuerungssoftware“: Hier beschreibt Jörg Wiegelmann eine simple Laufzeit-Architektur auf Basis eines Dispatchers in Verbindung mit Zustandsautomaten. Mit dieser Architektur lassen sich Embedded Systems sehr strukturiert programmieren, wenn sich die Komplexität in Grenzen hält.

Es geht weiter mit dem Kapitel 10 „Quellcode“, in dem auf Struktur, Übersicht und Qualität von Code eingegangen wird. Immer wieder wird der Einsteiger den einen oder anderen Tipp finden, der ihm das Leben erleichtert. Bevor der praktische Teil anfängt, gibt es noch das Kapitel 11 „Tools und Entwicklungsumgebung“. Hier werden außer den Basis-Werkzeugen zum Beispiel auch statische Analyser (Lint) und Sourcecodeverwaltung (RCS, CVS) angesprochen, also auch erste Schritte zur Absicherung von Qualität in Bezug auf Sourcecode an sich und Sourcecode-Management. Ich hoffe, die Leser schenken diesen Kapiteln die notwendige Achtung.

Nur das Kapitel 12.5 „CASE-Tools“ kann nicht recht überzeugen. Hier kritisiert Jörg Wiegelmann den Einsatz von CASE-Tools, weil es „... ist sehr aufwändig, eine wirkliche komplexe Software vollständig in einem CASE-Tool zu entwickeln. Die einzelnen Softwareteile müssen mit ihren Schnittstellen genau spezifiziert werden. ...“ Das ist aber nicht die Problematik, die entsteht, wenn ein CASE-Tool eingesetzt wird. Das ergibt sich grundsätzlich, egal auf Basis welcher Notationen, Methoden oder Werkzeugen programmiert wird. Im Gegenteil, ein gutes CASE-Tool macht die Definition von Schnittstellen vergleichsweise einfach, zum Beispiel in Form einer „Usage“-Beziehung zwischen zwei Modulen. Die im ersten Teil des Buches aufgeführten Probleme mit Include- und Header-Dateien werden vom CASE-Tool erledigt. Der praktische Nutzen von CASE-Tools ist es gerade, die bei steigender Komplexität anwachsenden Beziehungen zu entflechten und deren Umgang gegenüber der Programmierung in einer Hochsprache zu vereinfachen. Weitere angesprochene mögliche Nachteile von CASE-Tools sind bei guten Werkzeugen nicht relevant. Diese Einstellung scheint Jörg Wiegelmann nicht zu teilen - schade.

Im Kapitel 13 „Fallstudie“ geht es dann um die reale Durchführung eines Beispielprojektes auf Basis des „AVR ATmega88“. Auf einer dem Buch beiliegenden CD-ROM sind Werkzeuge und Quellcode enthalten, um dieses Beispiel selber nachzuvollziehen. Dieser Teil des Buches wurde aus Zeitgründen nicht rezensiert, obwohl er sicher für den Einsteiger noch einmal einen sehr wichtigen und hilfreichen, wenn nicht sogar den wichtigsten Teil darstellt. Streng nach dem Motto: Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie. Abschließend beurteile ich das Buch für Einsteiger in die Programmierung von Embedded-Applikationen als sehr hilfreich. Abgesehen von ganz wenigen Aussagen ist das Buch reich an praxisrelevanten und kompetenten Tipps und Hinweisen, die einem Einsteiger das Leben erleichtern können.

Manche Stellen musste ich zwei mal lesen um zu begreifen, was Jörg Wiegelmann meint. So könnte man kritisieren, dass das eine oder andere eleganter hätte formuliert werden können. Letztendlich ist der Inhalt kompetent und praxisnah, und das ist der Hauptgrund, warum ich das Buch grundsätzlich jedem Entwickler empfehlen kann, der in die Programmierung von Embedded Systems einsteigen möchte und dort auch mit hardwarenaher Programmierung konfrontiert wird, egal, ob er das in der Notation C, C++ oder auf Modellierungsebene, etwa mit UML tun möchte. Viele in dem Buch beschriebene grundlegende Dinge sind hilfreich zu wissen und beugen langem Suchen nach unerklärlichen Effekten vor. Auch erfahrenen Programmierern, die in das Embedded-SW-Engineering einsteigen möchten. kann das Buch empfohlen werden. Nicht zu empfehlen ist es für Entwickler, die den Einstieg in die Welt der Embedded Systems auf Basis von Betriebssystemen wie Linux, VxWorks oder Windows in Verbindung mit sogenannten BSP‘s (Board Support Packages) machen möchten.

Andreas Willert - www.willert.de

Ansehen

Bereitgestellt von:

zurück


Newsletter abonnieren



Empfehlung an diese E-Mail-Adresse senden:


 

 

 

Ihre eigenen Angaben:

 

 

 

 

Diese Seite empfehlen Sie weiter: