Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
14 Elektronik 25 2021 EmbEddEd TEchnology ausführ lichen Fehlerbeschreibungen angezeigt Gute Werkzeuge für die statische Analyse bieten im Vergleich zu einfachen Analysewerkzeugen einen weitaus größeren Komfort indem sie Fehlermeldungen nach Kritikalität sortieren Das Entwicklerteam kann sich somit zunächst der Behebung der schwerwiegenden Fehler widmen und weniger kritische Meldungen dann bearbeiten wenn hierzu noch Zeit bleibt Warnungen die vom Team als nicht relevant angesehen werden können sogar ganz unterdrückt werden Der Einsatz von »Advanced Static Analysis Tools« führt daher bei Entwicklern und Managern zu höherer Akzeptanz Die etwas höheren Kosten für die Anschaffung des Tools werden in der Regel schnell wieder hereingeholt Dynamische Tests ergänzen die statische Codeanalyse Sobald die Software im fortgeschrittenen Projektstadium ablauffähig ist sollte die statische Analyse durch dynamische Tests ergänzt werden Sie dienen vor allem dazu die funktio - nale Korrektheit eines Systems nachzuweisen Üblicherweise werden dynamische Tests ausgeführt sobald erste Bestandteile des Codes lauffähig sind und begleiten dann die Entwicklung bis zum fertigen Produkt Ein wichtiger Bestandteil dieser Tests ist die Code-Coverage-Analyse Hiermit wird sicher gestellt dass jeglicher Code einer Anwendung auch durchlaufen – d h getestet – wurde Programmteile die offensichtlich für einen gewissen Zweck entwickelt wurden und damit auch eine Funktion haben sollten die aber nie aufgerufen werden lassen vermuten dass ein Programmieroder Verfahrensfehler vorliegt Im einfachsten Fall ist es Code den niemand gelöscht hat nachdem er nicht mehr gebraucht wurde und der »nur« Speicherplatz belegt Im schlimmsten Fall sind es Initialisierungsoder andere Funktionen die selten zum Einsatz kommen im Bedarfsfall aber wichtige Aufgaben haben Code Coverage Analyser wie Testwell CTC++ von Verifysoft ergänzen zur Messung der Testabdeckung die Programme durch passende Zähler die an allen relevanten Stellen im Source-Code platziert werden – Instrumentierung des Codes – und analysieren ob der entsprechende Codeteil durchlaufen wurde Wichtig bei solchen Tools ist dass die Instrumentierung möglichst wenig Speicherplatz belegt da in Embedded-Systemen häufig nur limitierter Hauptspeicher zur Verfügung steht Außerdem dürfen solche Tools die Leistungsfähigkeit nur minimal beeinflussen um in zeitkritischen Regelungssystemen keine Fehlfunktionen zu generieren die sonst nicht auftreten würden In der Regel sind Coverage-Tools in die Entwicklungsumgebungen integriert sodass kein manuelles Platzieren von Testcode nötig ist Nach den Testläufen erzeugt der Coverage-Analyser Berichte über die Entwickler sich bis ins Detail anschauen können welche Funktionen ausgeführt wurden und welche nicht Ein nützlicher Nebeneffekt der Code-Coverage-Analyse ist die Angabe wie häufig einzelnen Codeteile aufgerufen wurden Bei sicherheitskritischer Software sind dynamische Testverfahren und der Nachweis der Code-Coverage aus gutem Grund verpflichtend So fordern die DO-178C in der Luftfahrt die ISO 26262 im Automobilbereich die EN 50128 im Schienenverkehr sowie die allgemeine Norm IEC 61508 für Software mit hoher Kritikalität hohe Code-Coverage-Stufen wie die Modified Condition Decision Coverage MC DC um den Test aller Bedingungen bzw Entscheidungen in einer Software nachzuweisen Dies ist beispielsweise für If-Then-Abfragen mit mehreren logischen Undoder Oder-Verknüpfungen wichtig So wird bei einer Abfrage wie if sensorActivity TRUE || sensorB > grenzwert … { … } die Funktion » grenzwert « im zweiten Teil der Abfrage hinter dem logischen Oder » || « nicht ausgeführt wenn sensorActivity den Wert True hat Das ist auch sinnvoll weil unabhängig vom Ergebnis des zweiten Vergleichs der Gesamtausdruck True sein wird wenn sensorActivity schon True ist Ist die Funktion » grenzwert « auch für die Initialisierung von globalen Variablen oder I O-Registern verantwortlich Listing 1 Beispiel Waschmaschinen-Software Funktion zur Berechnung der Waschdauer des Hauptwaschgangs Quelle Verifysoft Listing 2 Die im Test als problematisch erkannte Programmzeile in der Funktion zur Berechnung der Waschdauer des Hauptwaschgangs Quelle Verifysoft size t durationMainWashCycle size t prog size t load size t staining { if prog 3 || prog 5 || prog 7 load < 5 { return staining * 5 } else if prog 4 || prog 6 load < 5 { return staining * 8 } else if prog 4 || prog 6 load < 3 { return staining * 7 } else { return staining * 9 } } else if prog 4 || prog 6 load < 3 { return staining * 7