Qualitäts-Check für Safety-Software

Kriterium Testbarkeit

Auch nach einer Code-Inspektion lassen sich – insbesondere was die Echtzeit-Anforderungen betrifft – nur begrenzt Aussagen über das korrekte Verhalten des Gesamtsystems im Betrieb machen. Aus diesen Gründen ist es notwendig, Testfälle während allen Entwicklungsphasen des Systems durchzuführen. Diese Testfälle gestalten sich meist sehr umfangreich, da möglichst alle wichtigen Pfade der Software durchlaufen werden sollen. Eine starke Modularisierung und wenig verschachtelte Programme vereinfachen das Testen. In diesem Zusammenhang spielen folgende Metriken eine Rolle: die Komplexität des Moduls (zyklomatische Zahl), die Anzahl der Rücksprünge, die Komplexität des Moduls in Abhängigkeit von sei-  überschaubare Modullänge. Konkret fließen in dieses Kriterium folgende Metriken ein: die Kommentar-Rate in Abhängigkeit von der Komplexität und dem Umfang eines Moduls, die durchschnittnem Umfang, und die Häufigkeit der Abfrage von Timern. Das Modul ist hinsichtlich des Kriteriums Testbarkeit „TO INSPECT“, wenn zu häufig Timer eingesetzt wurden, „TO STRUCTURE“, wenn es zu viele Rücksprünge oder eine zu hohe Komplexität gibt, und „TO CUT“, wenn das Modul zu lang ist.

Kriterium Einfachheit

Eines der Hauptargumente für den Einsatz von softwarebasierten Lösungen ist die Flexibilität, Anpassungen an ihr vornehmen zu können. Für eine leichte und sichere Einarbeitung ist es wichtig, dass das System so einfach wie möglich aufgebaut ist. Die Schnittstellen der einzelnen Module sollten klar definiert und abgegrenzt sein. Der Programmcode der einzelnen Module sollte überschaubar und leicht verständlich sein. Das Kriterium der Einfachheit lässt sich durch folgende Metriken bewerten: die Verschachtelung des Moduls ohne Fehleraussprünge auf ein einziges Modul, die Komplexität des Moduls in Abhängigkeit von seinem Umfang, das Verhältnis der Eingangangs-/Ausgangsvariablen zu anderen Variablen, die Anzahl der Timer sowie durch das Verhältnis der Timer-Anzahl zu deren Abfragehäufigkeit. Fehlerroutinen sind in der Sicherheitstechnik elementar, da sie über eine zentrale Fehleraussprungroutine beim Erkennen eines Fehlers durch die Software „angesprungen“ werden. Ist keine der genannten Metriken erfüllt, so muss das Modul neu geschrieben werden (TO REWRITE). Ist die Komplexität in Abhängigkeit vom Umfang zu groß, lautet das Ergebnis „TO CUT“. Liegt außer der Komplexität in Abhängigkeit vom Umfang eine der anderen Metriken außerhalb der Grenzen, ist die Software „TO INSPECT“. Das bedeutet, dass die Software in diesem Fall manuell zu inspizieren ist, zum Beispiel durch eine Fagan-Inspektion oder einen Walkthrough.

Kriterium Lesbarkeit

Software mit sicherheitsrelevanten Aufgaben muss nicht nur in der Lage sein, auf externe Einflüsse (Sensoren) zu reagieren, sondern auch interne Fehler zu erkennen. Für derartige Fehler muss eine einfache und einheitliche Fehlerroutine existieren. Dies erfordert die Nutzung von üblichen Sprachkonstrukten wie Case-Strukturen und Fehleraussprüngen. Schleifen erschweren die Lesbarkeit und sind daher sparsam zu verwenden. Ein langer, linearer Programmtext ist ähnlich schwer zu verstehen, wie ein kurzer, aber verschachtelter Code. Nicht zuletzt sollten Operatoren nicht zu oft verändert werden. Dies führt zum Kriterium der Lesbarkeit. Metriken, die die Lesbarkeit bestimmen, sind: Verschachtelung eines Moduls ohne Auswahlstrukturen und Fehleraussprünge, die Anzahl der Rücksprünge, die Komplexität in Abhängigkeit vom Umfang des Moduls und die durchschnittliche Häufigkeit der Veränderung von Variablen. Die Lesbarkeit ist „ACCEPTED“, wenn alle Metriken erfüllt sind, „TO INSPECT“, wenn Verschachtelung und Komplexität zu groß sind, und „TO STRUCTURE“, wenn die Anzahl der Rücksprünge und die durchschnittliche Häufigkeit der Veränderung der Variablen außerhalb der Grenzen liegen.