Qualitäts-Check für Safety-Software

Prüfgrenzen individuell anpassen

Für jede der genannte Einzelmetriken kann der Anwender des Prüftools die Grenzen für deren Gültigkeit individuell festlegen. Die vorgegebenen Standardwerte sind im ersten Ansatz der Literatur entnommen. In der Weiterentwicklung haben sie sich aus der inzwischen 20-jährigen Praxis des BGIA mit sicherheitsrelevanter Software sozusagen als „Best Practice“ aus realen Anwendungen ergeben. Zusätzlich zur Bestimmung der Software- Qualität erlaubt das Werkzeug eine grafische Aufbereitung der untersuchten Software. In einem HTML-Dokument wird die Aufrufstruktur der Software über Hyperlinks sichtbar. Für jedes Modul gibt es eine grafische Darstellung des Kontrollflusses. Damit lässt sich die Komplexität eines Moduls sofort grafisch darstellen. Ein so genannter Kiviatgraph zeigt auf einen Blick, welche Metriken außerhalb der Normwerte liegen. Auf diese Weise bietet das Werkzeug neben der Analyse der Qualität eine Unterstützung in punkto Dokumentation des Quelltextes.

Grundsätzlich lassen sich mit dem Programm namens JMetrikaAWL, welches über das Internet kostenlos zur Verfügung steht, Quelltexte analysieren, die der Norm IEC 61131-3 entsprechen oder in der Siemens-Sprache Step7 implementiert sind. Alle anderen Quelltexte sind geringfügig anzupassen. Dies bedingt eine Darstellung der Programm-Organisationseinheiten in der entsprechenden normkonformen Weise. Möglicherweise sind die Sprung-, Aussprung- und Call-Befehle ebenfalls auf die normkonformen Befehle hin zu ändern. Eine weitere Anpassung betrifft die Variablen-Deklarationen für Timer, die ebenfalls normkonform sein müssen. Die im Internet herunterladbare Benutzerinformation zum Werkzeug beschreibt die notwendigen Anpassungen anhand zahlreicher Beispiele.

Neben dem Analysewerkzeug für Anweisungsliste sind über das Internet weitere Analysetools verfügbar. Damit ist es möglich, die Qualität sicherheitsrelevanter Software in C, in C++ und in Zukunft auch in Java zu analysieren. In Planung befindet sich zudem ein Analysewerkzeug für Assemblerprogramme. Da jedes der Werkzeuge auf einem als Freeware verfügbaren Parser aufsetzt, ist es an jede andere Hochsprache anpassbar. Hinweise, die zur Verbesserung der Werkzeuge führen, nehmen die Projektbeteiligten gerne entgegen.

Die grafisch orientieren Sprachen zur SPS-Programmierung werden zurzeit in einer PLCopen-Arbeitsgruppe standardisiert, mit dem Ziel, ein einheitliches XML-Datenformat für alle diese Sprachen zu schaffen. Gelingt das, so können Qualitätssicherungswerkzeuge der Zukunft auf diesem Format aufsetzen und es lassen sich vergleichbare Werkzeuge wie oben beschrieben erstellen. gh

Nähere Informationen:

www.dguv.de/bgia (Webcode2386566)

www.inf.fh-bonn-rhein-sieg.de/reinert.html

Im Rahmen des Kongresses der Nürnberger Fachmesse SPS/IPC/Drives wird das Werkzeug JMetrikaAWL in der Session „Sicherheit und Software – ein Widerspruch?“ im Detail vorgestellt, und zwar am 28. November um 15 Uhr.

Thomas Breuer

studiert an der FH Bonn-Rhein-Sieg den Masterstudiengang „Autonomous Systems“.

Prof. Dr. Norbert Jung

lehrt und forscht an der Fachhochschule Bonn-Rhein-Sieg im Arbeitsgebiet „Angewandte Informatik insbesondere eingebettete Systeme“.

Prof. Dr. Dietmar Reinert

ist Leiter des Zentralbereichs „Fachübergreifende Aufgaben“ am BGIA – Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung.  

Kriterium Selbstbeschreibung

Die gute Selbstbeschreibung ist eine besondere Anforderung an Software mit Sicherheitsaufgaben, da diese während der Verifizierung und der Zertifizierung von mehreren Personen gelesen und nachvollzogen werden muss. Maßnahmen, welche die Nachvollziehbarkeit unterstützen, sind: viele aussagekräftige Kommentare, selbsterklärende Variablen-Namen, ein klar strukturierter und überschaubarer Kontrollflussgraph sowie eine liche Länge aller Variablen-Namen und die Länge des Namens einer Programm- Organisationseinheit. Liegen alle drei Metriken im Bereich ihrer Grenzen, ist das Kriterium Selbstbeschreibung akzeptiert. Befindet sich die Länge der Namen außerhalb der Grenzen, erscheint der Hinweis „TO IMPROVE NAMING“; das heißt, die Namen müssen aussagefähiger gemacht werden. Liegt die Kommentierung außerhalb der Grenzen, folgt der Hinweis „TO DOCUMENT“, sprich, der Quellcode ist besser zu dokumentieren.