Die 100%ige strukturelle Source Code Überdeckung wird ja inzwischen von fast allen Normen (IEC61508, ISO26262, DO 178C etc.) der Funktionalen Sicherheit eindeutig gefordert. Unterschieden wird in den einzelnen SIL/ASIL Leveln nur noch die Art der Source Code Coverage.

Strukturelle Source Code Überdeckung:

Im Wesentlichen werden die Statement Coverage (niedrige SIL/ASIL Level), die Branch Coverage und die MC/DC Coverage (hohe SIL/ASIL Level) gefordert. Aus guten Gründen wird aber z.B. keine Pfad Coverage gefordert. Diese würden bedeuten, dass man alle Kombinationen von Pfaden die in einer Software möglich sind überprüfen würde. Das wäre ein extrem hohes Vielfaches von Testfällen im Vergleich zu einer MC/DC Coverage.
Im nachfolgenden Blog möchte ich nun die Frage thematisieren, welche Vor- bzw. Nachteile sich ergeben, wenn man die Coverage auf der finalen Hardware ermittelt im Gegensatz zu einer Coverage Ermittlung auf einem vom Compilerhersteller zur Verfügung gestellten Simulator der auf dem PC ausgeführt wird.
Spontan wird man sicher zu der Meinung kommen, dass eine Coverage Messung auf der finalen Hardware die aus Sicherheitsgründen beste Methode ist. Einige immer wieder vorgetragene Argumente sind: Toter Code würde unter realen Bedingungen gefunden. Die Coverage würde nachgwiesen unter Berücksichtigung der realen HW/SW Schnittstellen. Mancher bisheriger, formaler Unittest könnte gespart werden.
Für eine aussagekräftige Antwort, muss noch geklärt werden ob mit Hardware „nur“ der Mikrocontroller und dessen Periferie gemeint ist, oder ob die gesamte Hardware inklusive I/Os, FPGAs etc. verwendet wird.

Die Messung von Code Coverage unter Aussführung des Source Codes auf dem Mikrocontrollers ist in der Luftfahrt seit Jahrzehnten schon gängige Praxis. Aus dieser langjährigen Erfahrung geht eindeutig hervor, dass es so gut wie keine Fehler gibt, die man hier zusätzlich findet. Ein Test auf einem Simulator zeigt in den allermeisten Fällen genau die gleichen Fehler auf. Hier gibt es keinen erkennbaren Vorteil des Tests auf dem Target. Es sei hier noch angemerkt, dass bei diesem Verfahren praktisch nie die gesamte Software auf einmal instrumentiert wird, sondern immer nur relativ kleine Teile. Aufgrund entsprechend vorhandener Tools auf dem Markt ist es aber kein großer Aufwand am Ende die vollständige Coverage zu ermitteln.
Unter einem „echten“ Test auf der Hardware versteht man aber meist die vollständige Hardware (inklusive I/Os, FPGAs etc.). Mit den bisher üblichen Methoden der Coverage Messung ergibt sich nun aber das Problem, dass sich das Timing Verhalten der Software sowie der Speicherbedarf massiv verändern, wenn die Software instrumentiert ist. Die Instrumentierung ist wiederum notwendig um die Coverage überhaupt ermitteln zu können. Dies bedeutet, in der Praxis ganz oft, dass die Software gar nicht mehr oder nur sehr eingeschränkt lauffähig ist auf der echten Hardware. Um trotzdem Tests auf diese Art und Weise durchzuführen wird nun oft versucht auch hier nur Teile der Software zu instrumentieren, Tests entsprechend durchzuführen und die Gesamt Coverage dann auf zu addieren. Das Problem ist aber hier, dass dafür keine kommerzielle Toolunterstützung zur Verfügung steht. Damit ensteht ein in der Praxis völlig inakzepabler Aufwand zur Ermittlung der Gesamt Coverage. Bei sehr zeitkritischen Systemen kann jegliche Instrumentierung dazu führen, dass ein sinnvoller Test gar nicht mehr möglich ist.

Lösungsansätze:

Die offensichtliche Lösung des obigen Problems ist eine Technologie die es nicht mehr erfordert den Source Code zu verändern, die aber trotzdem die Code Coverage messen kann. Aktuell gibt es einige vielversprechende Entwicklungen von einigen Toolherstellern in diese Richtung. Für ausgewählte Hardware Architekturen sind einige Lösungen auch schon nahe an der Marktreife.
In der Luftfahrtbranche hat sich über die Jahre auch noch eine Vorgehensweise herausgebildet, welche die angestrebten Sicherheitsziele durch die Ermittlung der Source Code Coverage auch auf hervorragende Art und Weise erreicht:

1. Alle Tests (Unit-, Integrations- und Systemtests) werden mit den Compilereinstellungen übersetzt wie Sie auch im operationellen Code verwendet werden.
2. Die Tests werden zu 100% gegen Requirements erstellt. Die strukturelle Coverage wird nur im Hintergrund ermittelt und immer wenn eine Lücke auftritt wird analysiert wo die Lücke liegt. Es gibt prinzipiell nur 3 mögliche Lücken: unvollständige Requirements, unvollständige Testspezifikationen, nicht benötigter Source Code. Mit diesem Vorgehen wird am Ende ein 100% Source Code Coverage erreicht, die zur 100% durch Requirements basierte Tests abgedeckt ist.

Sind Sie bereit für einen FuSi Workshop um das Verbesserungspotential zu identifizieren? Dann senden Sie eine Mail an info[at]heicon-ulm.de oder vereinbaren Sie einen Telefontermin unter +49 (0) 7353 981 781.