Software-Prüfung nach DIN EN 61508
Statische Tests automatisieren
Fortsetzung des Artikels von Teil 2
Kontrollflussanalyse
In DIN EN 61508, Teil 3, Tabelle B.8 wird Kontrollflussanalyse als Verfahren/Maßnahme der statischen Analyse genannt (Punkt 3). Die Kontrollflussanalyse ist „besonders empfohlen“ für SIL 2 bis SIL 4. Eine typische Kontrollflussanomalie ist das Vorhandensein von nicht erreichbarem Code. Dies wird auch in DIN EN 61508, Teil 7, C.5.9 aufgeführt. Dies muss nicht unmittelbar zu einer fehlerhaften Programmausführung führen, aber es legt die Vermutung nahe, dass an dieser Stelle vielleicht etwas programmiert wurde, was so nicht beabsichtigt war. In jedem Fall ist eine solche Anomalie eine Überprüfung wert.
Jobangebote+ passend zum Thema
In Bild 3 ist eine Situation mit unerreichbarem Code dargestellt. Die return-Anweisung in Zeile 7 wird niemals ausgeführt, weil die Funktion func() schon zuvor entweder durch die return-Anweisung in Zeile 4 oder die return-Anweisung in Zeile 6 verlassen wird. Im vorliegenden Fall mag das offensichtlich sein, aber im Allgemeinen erfordert die Aufdeckung von unerreichbarem Code fortgeschrittene Analysefähigkeiten.
Auch einige MISRA-Regeln haben Kontrollfluss zum Thema. Im Beispiel in Bild 3 ist beispielsweise die bereits bekannte MISRA-Regel 15.5 aus MISRA-C:2012 verletzt. Denn es gibt mehr als eine return-Anweisung in der Funktion func().
Eine weitere Beziehung in Bezug auf Kontrollfluss zwischen der DIN EN 61508 und den MISRA-Regeln gibt es bei der Rekursion. In Tabelle B.1 in Teil 3 der DIN EN 61508 ist die Maßnahme „Eingeschränkte Verwendung von Rekursion“ „besonders empfohlen“ für SIL 3 und SIL 4. Laut Abschnitt C.2.6.7 in Teil 7 soll die Tiefe der Rekursion voraussagbar sein. Dazu passt die Regel 17.2 von MISRA-C:2012, die verlangt, dass sich Funktionen nicht selbst aufrufen. Der Hintergrund in beiden Fällen ist die Befürchtung, dass durch eine zu hohe Zahl von rekursiven Funktionsaufrufen der Stack-Speicher aufgebraucht würde, wodurch es voraussichtlich zu Fehlfunktionen kommen wird.
Strukturierte Programmierung
Man kann weitere MISRA-Regeln zur genaueren Spezifikation von Verfahren/Maßnahmen heranziehen, die in DIN EN 61508 genannt sind. Beispielsweise ist „strukturierte Programmierung“ laut Tabelle A.4, Punkt 6 in DIN EN 61508 Teil 3 „besonders empfohlen“ für alle SIL. Was die DIN EN 61508 unter strukturierter Programmierung genauer versteht, ist in Punkt C.2.7 erläutert, u.a. „Vermeidung … unbedingter Sprünge (GOTO).“ Mit unbedingten Sprüngen beschäftigen sich die MISRA-Regeln 15.1 bis 15.4 aus MISRA-C:2012. Regel 15.1 schlägt vor, die Verwendung der goto-Anweisung gänzlich zu unterlassen. Weil das aber nicht immer sinnvoll ist, fordert Regel 15.2, wenn schon eine goto-Anweisung verwendet wird, diese nur zu einer Marke (Label) später in der gleichen Funktion springen darf (also nur vorwärts und nicht zurück). Wegen Regel 15.3 dürfen Sprünge nur zum selben Block oder zu weiter außen liegenden Böcken erfolgen. Regel 15.4. sagt aus, dass nicht mehrere break- bzw. goto-Anweisungen verwendet werden sollen, um Schleifen zu verlassen. Alle diese Regeln dienen dem Ziel „strukturierte Programmierung“ der DIN EN 61508.
Datenflussanalyse
In DIN EN 61508, Teil 3, Tabelle B.8 wird Datenflussanalyse als Verfahren/Maßnahme der statischen Analyse genannt (Punkt 4). Die Kontrollflussanalyse ist „besonders empfohlen“ für SIL 2 bis SIL 4. In Teil 7 werden in C.5.10 die üblichen drei Datenflussanomalien beschrieben:
- Eine nicht initialisierte Variable wird verwendet (gelesen).
- Eine Variable wird mehrfach beschrieben, ohne dazwischen verwendet (gelesen) zu werden.
- Eine Variable wird beschrieben, aber nie verwendet.
Es ist offensichtlich, dass es durch die Verwendung von nicht initialisierten Variablen zu unvorhersehbarem Programmverhalten kommen kann, und, dass dies vermieden werden muss. In den anderen beiden Fällen muss es nicht unbedingt zu fehlerhaftem Programmverhalten kommen, jedoch liegt die Vermutung nahe, dass der Code nicht ganz in Ordnung ist.
Datenflussanalyse in DIN EN 61508 gibt es eine MISRA-Regel, die dies für die Sprache C enger fasst. Regel 9.1 fordert, dass keine automatische Variable gelesen wird, bevor sie initialisiert ist.
Im Beispiel in Bild 4 sind alle drei Datenflussanomalien vorhanden und sie werden auch alle von Klocwork erkannt. Dabei stuft Klocwork die Verwendung der nicht initialisierten Variablen mit der Gewichtung „critical“ in die höchste Stufe ein, denn dies kann zu beliebigem Programmverhalten führen. Die beiden anderen Anomalien bekommen die Gewichtung „review“ (niedrigste Stufe) zugewiesen, denn hier reicht es aus, sie bei Gelegenheit einmal anzuschauen.
- Statische Tests automatisieren
- Programmierrichtlinien: unsichere Sprachmerkmale ausschließen
- Kontrollflussanalyse
- Vermeiden von Laufzeitfehlern
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Software-Test
Wie robust ist mein Code?
Software-Entwicklung
Testeron: Testen auf Gegenseitigkeit
Microsoft
Künstliche Intelligenz für Arduino und Raspberry Pi
Matlab-Expo
Auf dem Weg zur Autonomie
Unternehmensführung
Jörg Stender ist neuer Geschäftsführer bei Hitex
