Für den häufigsten Engpass (geringer RAM-Speicher) lohnt eine kritische Betrachtung des Datentyps der Zähler. In den meisten Fällen ist ein nicht-vorzeichenbehafteter 32-bit-Datentyp (unsigned int long) überdimensioniert. Bei kleineren Datentypen (16 bit und 8 bit) ergibt sich eine merkliche Einsparung an RAM, jedoch erhöht sich die Wahrscheinlichkeit eines Speicherüberlaufs, was letztendlich zu einer Fehlinterpretation der Ergebnisse führen kann. Zumindest von der Verwendung von 8-bit-Zählern ist abzuraten.
Kann auf die Information, wie oft man eine bestimmte Stelle durchlaufen hat, verzichtet werden, so bietet es sich an, die Instrumentierung mittels Bit Coverage durchzuführen. Hierbei wird für jeden zu zählenden Entscheidungspunkt nur ein Bit verwendet. Im Gegensatz zur Standardinstrumentierung lässt sich damit der RAM-Bedarf um den Faktor 32 verringern. Beim erstmaligen Erreichen eines Entscheidungspunkts wird dieses Bit gesetzt. Ein erneutes Durchlaufen ändert dann das gesetzte Bit nicht. Auf den meisten Plattformen ist das Setzen eines Bits mit drei Assemblerbefehlen (Lies Zähler in Register, Setze Bit, Schreibe Zähler in Speicher) realisierbar. Einige wenige Mikrocontrollerfamilien wie PICs unterstützen direktes Setzen einzelner Bits im RAM ohne Verwendung von Registern.
ROM-Bedarf |
|
Ohne Instrumentierung | 60 Bytes |
Coverage-Stufe Funktionsüberdeckung | 67 Bytes |
Coverage-Stufe Zweigüberdeckung | 118 Bytes |
Coverage-Stufe Bedingungsüberdeckung | 285 Bytes |
Zusätzlicher RAM-Bedarf ohne Bit-Coverage (32-Bit-Zähler) |
|
Coverage-Stufe Funktionsüberdeckung |
4 Bytes |
Coverage-Stufe Zweigüberdeckung |
16 Bytes |
Coverage-Stufe Bedingungsüberdeckung |
28 Bytes |
Zusätzlicher RAM-Bedarf mit Bit-Coverage |
|
Coverage-Stufe Funktionsüberdeckung |
1 bit |
Coverage-Stufe Zweigüberdeckung |
4 bit |
Coverage-Stufe Bedingungsüberdeckung |
7 bit |
In Tabelle 5 ist exemplarisch anhand des Codes aus Listing 2 der Overhead aufgezeigt. Dabei kam der sdcc-Compiler für einen Z80 und Testwell CTC++ 7.0.2 zur Anwendung. Anhand des gewählten Beispiels ergibt sich ein recht hoher Instrumentierungs-Overhead. In der Praxis ist allerdings mit einem Overhead von nur dreißig Prozent im Mittel zu rechnen.
int goo( int a, int b, int c) { int x; if (((a>0) || (b>0)) && (c>0)) { x = 1; } else { x = 0; } return x; } |
Listing 2. Programmcode der Funktion goo
Das richtige Tool auswählen
Getrieben durch die Normen, müssen mittlerweile neben den Herstellern von Embedded Systems auch deren Zulieferer den Nachweis einer Code Coverage erbringen. Neben dem notwendigen Know-how, welches durch Schulungsmaßnahmen nachhaltig aufgebaut werden kann, ist die Auswahl eines geeigneten Coverage Tools der Schlüssel zum Erfolg. Am konkreten Projekt sollten einige Coverage Tools evaluiert werden. Gerade bei der Unterstützung kleiner Targets unterscheiden sich diese meist im Detail. jk
Literatur & Autoren
[1] Liggesmeyer, P.: Software-Qualität: Testen, Analysieren und Verifizieren von Software. 2. Auflage, Spektrum Verlag, 2009.
[2] DIN/VDE (Hrsg.): Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme – Teil 3: Anforderungen an Software, Februar 2011.
[3] ISO: International Standard ISO/FDIS 26262 – Road vehicles – Functional safety – Part 6: Product development at the software level, 2011.
[4] Lindenberg, U.: Vergleich IEC EN 61508 SIL mit ISO CD 26262 ASIL, http://www.uwe-lindenberg.de/files/sil_asil-tabelle.pdf, Stand 31.05.2012.
[5] Radio Technical Commission for Aeronautics: DO-178C – Software Considerations in Airborne Systems and Equipment Certification, RTCA, Inc., 2011.
[6] Hilderman, V.; Baghai, T.: Avionics Certification – A Complete Guide to DO-178 (Software) DO-254 (Hardware); Avionics Communication Inc., 2008.
[7] International Electrotechnical Commission: International Standard IEC 62304: Medical Device Software – Software Lifecycle Processes, 2006.
Roland Bär |
---|
leitet die Entwicklung und den Support bei Verifysoft Technology. Schwerpunkte seiner Tätigkeit sind die statische Codeanalyse sowie die Weiterentwicklung und Erweiterung des Coverage Tools Testwell CTC++ speziell für kleine Targets. Compiler-spezifische Anpassungen der Werkzeuge gehören ebenso zu seinem Aufgabenspektrum. |
baer@verifysoft.com
Prof. Dr. Daniel Fischer |
---|
ist seit 2001 Professor für Informationstechnologie an der Hochschule Offenburg. Er leitet dort als Studiendekan die Studiengänge Angewandte Informatik und Wirtschaftsinformatik plus. In Zusammenarbeit mit der Firma Verifysoft Technology bietet er seit geraumer Zeit die Seminare „Testen von Embedded Systems“ und „Effizientes Testmanagement“ an. |
daniel.fischer@fh-offenburg.de