Software-Prüfung nach DIN EN 61508 Statische Tests automatisieren

Normen sorgen für Einhaltung und überprüfen den Arbeitsprozess.
Normen sorgen für Einhaltung und überprüfen den Arbeitsprozess.

Um die Norm DIN EN 61508 zu erfüllen, muss der Quellcode mit statischen Methoden verifiziert werden – beispielsweise um zu prüfen, ob die geforderten Programmierrichtlinien eingehalten werden. Was ist bei der automatisierten Prüfung zu beachten?

Statische Analyse wird auch bei der Softwareverifikation nach SIL 2 bis SIL 4 „besonders empfohlen“ (siehe Kasten DIN EN 51508). Damit ist die Prüfung von Hardware (z.B. Montageabstände) und Software (z.B. Datenflussanalyse) gemein. Im Folgenden soll es jedoch nur um die statische Analyse von Software gehen.

Statische Analyse kann prinzipiell durch Menschen (manuell) oder werkzeuggestützt (automatisiert) durchgeführt werden. Bei statischer Analyse von Software durch Menschen mittels Reviews, Inspektionen oder Walk-throughs kann prinzipiell jede Anforderung geprüft werden, insbesondere die Funk¬tionalität gegen die Spezifikation der Software, was automatisiert im Allgemeinen nicht möglich ist. Allerdings ist diese manuelle Prüfung sehr aufwendig. Deshalb werden üblicherweise im Vorfeld der manuellen Prüfung statische Analysewerkzeuge eingesetzt, um zur Entlastung des Menschen automatisiert zu prüfen, was automatisiert zu prüfen ist. Aber welche Anforderungen aus der DIN EN 61508 lassen sich automatisiert testen und welche Eigenschaften muss ein dazu benutztes Werkzeug aufweisen?

Softwarekomplexität begrenzen

Etliche Anforderungen der DIN EN 61508 kann man unter dem Oberbegriff „Softwarekomplexitätskontrolle“ subsummieren. Die Anforderung Softwarekomplexitätskontrolle ist auch explizit als Maßnahme genannt, und zwar in Tabelle B.9 (Modularer Ansatz), Punkt 2, im (informativen) Anhang B in Teil 3 der DIN EN 61508. Wie kann man nun die Komplexität messen und somit kontrollieren? Eine Metrik, die „Komplexität“ bereits im Namen trägt, ist die zyklomatische Komplexität nach McCabe [2]. Dieser Wert wächst linear mit der Anzahl der binären Entscheidungen in einem Programm; allerdings berücksichtigt sie beispielsweise Berechnungen nicht. Eine umfangreiche Funktion mit vielen Berechnungen, aber ohne Verzweigungen, kann also eine geringere zyklomatische Komplexität haben (und zwar 1) als eine kleine Funktion mit lediglich einer if-Anweisung (nämlich 2). Ungeachtet dessen ist die Messung der zyklomatischen Komplexität sehr gebräuchlich und sehr viele statische Analysewerkzeuge sind in der Lage, sie zu messen.

Als eine weitere Metrik zur Messung der Komplexität könnte man Halstead [2] heranziehen. Diese Metrik berechnet das „Volumen“ einer Software aufgrund der Anzahl der unterschiedlichen Operatoren (n1), der Anzahl der unterschiedlichen Operanden (n2), der Gesamtzahl der Operatoren (N1) und der Gesamtzahl der Operanden (N2). Das Volumen V ist dann V = (N1+N2) log2(n1+n2) und man könnte es ebenfalls als Maß für die Komplexität heranziehen. Wie bei der zyklomatischen Komplexität sind viele statische Analysewerkzeuge in der Lage, das Volumen nach Halstead zu messen. Halstead hat übrigens noch weitere Formeln aufgestellt, beispielsweise für den Aufwand oder für die Schwierigkeit. Jedoch sollte man diese Formeln und die daraus abgeleiteten Aussagen nicht ohne nähere Beschäftigung damit verwenden: Halsteads Formeln werden mitunter kontrovers diskutiert.

Die DIN EN 61508 nennt in der Tabelle B.9 von Teil 3 noch zwei weitere Verfahren/Maßnahmen, die dem Ziel Komplexitätskontrolle zuarbeiten – obwohl die Tabelle B.9 eigentlich Maßnahmen/Verfahren zur Modularität der Software auflistet. Bei der ersten Maßnahme handelt es sich um die Begrenzung der Softwaremodulgröße (Tabelle B.9 Punkt 1). Die Norm schlägt in Abschnitt C.2.9. (in Teil 7) die Begrenzung auf zwei bis vier Bildschirmseiten vor. Mit einer fachkundigen Annahme, welche Bildschirme die Autoren der DIN EN 61508 im Sinn hatten, kann man eine Anzahl von Zeilen festlegen, die ein Modul nicht überschreiten darf oder soll. Die dafür geeignete Metrik Lines-of-Code (LoC) ist eine leicht durch Zählen zu ermittelnde Metrik. Bei der zweiten Maßnahme handelt es sich um die Begrenzung der Anzahl von Parametern von Unterprogrammen (Tabelle B.9, Punkt 4). Auch das ist eine einfach zu ermittelnde Metrik.

Das statische Analysewerkzeug Klocwork (Bild 1) kann z.B. die Anzahl der Parameter einer Funktion prüfen und beim Überschreiten von Grenzwerten eine Warnung oder einen Fehler erzeugen. Durch die Regel mit dem Namen „Fuenf Parameter“ im oberen Teil von Bild 1 wird festgelegt, dass die Metrik „Anzahl der Parameter“ (NOPARMS) durch Klocwork ermittelt werden soll, und zwar für Funktionen (FUNCTIONS) bzw. Methoden (CLASS-METHOD). Die Werte 5 und 4 sind frei ausgewählte Schwellenwerte, bei deren Überschreitung ein Fehler bzw. eine Warnung ausgegeben wird. Die Funktion f2() in Bild 1 hat fünf Parameter, damit wird zwar der Schwellenwert für die Warnung, aber nicht der Schwellenwert für einen Fehler überschritten. Deshalb gibt es für f2() bzw. für Zeile 42 eine Warnung. Die Funktion f3() in Bild 1 hat sechs Parameter, damit wird der Schwellenwert für einen Fehler überschritten. Deshalb gibt es für f3() bzw. Zeile 64 eine Fehlermeldung.

Bilder: 5

Die Bilder des Artikels im Überblick, Bilder 1-5

Statische Tests automatisieren