Software-Prüfung nach DIN EN 61508
Statische Tests automatisieren
Fortsetzung des Artikels von Teil 1
Programmierrichtlinien: unsichere Sprachmerkmale ausschließen
Viele Stellen der DIN EN 61508 zielen darauf ab, dass die Software verständlich ist (dazu gehört auch die obige Softwarekomplexitätsbegrenzung) und keine unsicheren Sprachmerkmale verwendet werden. Beiden Zielen wird mit Programmierrichtlinien Rechnung getragen. In Tabelle A.4 (im normativen Anhang A des Teils 3 der DIN EN 61508) werden Entwurfs- und Programmierrichtlinien als „besonders empfohlen“ für SIL 2 bis SIL 4 angegeben. In Tabelle B.1 (im informativen Anhang B des Teils 3 der DIN EN 61508) wird in Punkt 1 die Verwendung von Programmierrichtlinien für alle SIL „besonders empfohlen“. Die am verbreitetsten verwendeten Programmierrichtlinien für die Sprachen C bzw. C++ sind die MISRA-Regeln. Diese Regeln sorgen u.a. dafür, dass unspezifiziertes, undefiniertes und Compiler-abhängiges Verhalten vermieden wird.
Ein Beispiel für unspezifiziertes Verhalten ist die Reihenfolge der Evaluierung von Ausdrücken, die nicht vom Sprachstandard vorgeschrieben ist, und was durch die Einhaltung der Regel 13.2 aus MISRA-C:2012 vermieden werden soll. Ein Beispiel für undefiniertes Verhalten ist, wenn eine non-void-Funktion keinen return-Wert zurückgibt. Das ist eigentlich ein Programmierfehler und soll durch die Einhaltung von Regel 17.4 aus MISRA-C:2012 verhindert werden.
Jobangebote+ passend zum Thema
| EN 61508 |
|---|
| Die Norm DIN EN 61508 [1] beschreibt Maßnahmen bzw. Verfahren, die bei der Entwicklung von sicherheitskritischen Systemen angewendet werden können. Die Maßnahmen werden mehr oder weniger stark empfohlen bzw. es wird von ihrer Verwendung abgeraten. Dies hängt meist vom Sicherheits-Integritätslevel (SIL) ab. Der SIL hat Werte von 1 bis 4. Bei SIL 4 müssen wirkungsvollere Maßnahmen durchgeführt werden als auf SIL 1, um das Risiko auf ein akzeptables Maß zu reduzieren. Die höchste Empfehlungsstufe ist „besonders empfohlen“, darunter gibt es noch „empfohlen“, „keine Empfehlung für oder gegen Verwendung“ und „ausdrücklich nicht empfohlen“. |
Ein Beispiel für compiler-abhängiges Verhalten ist das Lesen einer „union“ unter bestimmten Bedingungen: Hier ist der Compiler frei, zu verfahren wie er möchte, er muss dies aber immer auf die gleiche Weise tun. Es ist jedoch möglich, dass ein anderer Compiler sich anders verhält; weshalb der Code möglicherweise nicht portabel ist. Regel 19.2 aus MISRA-C:2012 verbietet das Schlüsselwort „union“, womit das Problem aus der Welt ist. Ein Beispiel für Verständlichkeit ist die Regel 7.1 aus MISRA-C:2012: Oktale Konstanten dürfen nicht verwendet werden. Das ist einerseits eine kleine Einschränkung des Sprachumfangs, so dass nur eine Sprachteilmenge verwendet wird, was nach Tabelle A.3 Punkt 3 für SIL 3 und SIL 4 „besonders empfohlen“ ist – und gleichzeitig auch ein Beitrag zur Verständlichkeit/Wartbarkeit, denn es könnte sein, dass es beim Schreiben bzw. Lesen der Software zu Missverständnissen kommt, was den Wert einer oktalen Konstante betrifft. Wenn Sie denken, dass nach „int zehn = 010;“ in der Variablen zehn der Wert 10 steht, sind Sie diesem Irrtum aufgesessen. Andere MISRA-Regeln versuchen, Missverständnisse mit Seiteneffekten zu vermeiden. Beispielsweise fordert Regel 13.6. aus MISRA-C:2012, dass keine Ausdrücke als Operand des sizeof-Operators verwendet werden, weil diese Ausdrücke zur Laufzeit normalerweise nicht evaluiert werden, was man aber leicht annehmen könnte.
Die Maßnahme, nur einen Eingang und nur einen Ausgang für Unterprogramme und Funktionen zu haben (enthalten in Tabelle B.9, Punkt 5), „besonders empfohlen“ für SIL 1 bis SIL 4, kann man durch Einhalten der Regel 15.5 aus MISRA-C:2012 durchführen. Diese Regel besagt, dass eine Funktion nur eine return-Anweisung haben darf, und zwar am Ende. Da in C eine Funktion nur am Anfang beginnen kann, ist durch Einhalten der MISRA-Regel die Maßnahme der DIN EN 61508 erfüllt, genaugenommen sogar übererfüllt, denn die DIN EN 61508 verlangt nicht explizit, dass der Ausgang (und damit die return-Anweisung) am Ende der Funktion steht.
Die meisten statischen Analysewerkzeuge unterstützen die Prüfung der MISRA-Regeln. Allerdings ist die Anzahl der Regeln, die geprüft werden können, von Werkzeug zu Werkzeug unterschiedlich (und ändert sich auch von Werkzeugversion zu Werkzeugversion). Außerdem gibt es auch Unterschiede in der Güte des Findens von Regelverletzungen, denn nicht alle Regelverletzungen sind so leicht zu ermitteln wie die Verwendung von oktalen Konstanten.
Regeln für die Namensgebung
Ein Vorschlag zu Programmierrichtlinien der DIN EN 61508, Vereinbarungen zu bedeutungsvollen Namen zu treffen (Teil 7, C.2.6.2), ist von den MISRA-Regeln aber nicht abgedeckt. Da sehr oft jede Firma (und manchmal sogar jedes Projekt innerhalb einer Firma) eigene Regeln zur (bedeutungsvollen) Namensgebung erfunden hat, ist es für statische Analysetools „von der Stange“ i.A. nicht möglich, mit vorgefertigten Regeln Namensgebungen zu prüfen. Abhilfe schafft die Möglichkeit, spezifische Regeln nachträglich dem Regelsatz hinzuzufügen. Eine solche Möglichkeit bieten allerdings nicht alle statischen Analysewerkzeuge.
Beispielsweise könnte eine Programmierrichtlinie fordern, dass alle globalen Variablen in einem Programm mit dem Präfix „glb_“ beginnen. Das ist hochgradig spezifisch und kaum ein statisches Analysewerkzeug wird eine vorgefertigte Lösung bieten. In Klocwork könnte man jedoch eine solche Anforderung durch eine spezifische Prüfung implementieren (Bild 2).
- 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
