Der Compiler ist DAS zentrales „Tool“, welches man in jeden Software Produktentwicklung benötigt. Er bildet das Bindeglied zwischen der vom Menschen gut lesbaren Hochsprache (z.B. C und C++) und dem für den Hardwareprozessor interpretierbaren Maschinencode. Für die Entwicklung sicherheitsrelevanter Software nach entsprechenden Funktionalen Sicherheitsstandards wie ISO26262 (Auto), EN50128 (Bahn), IEC61508 (Automatisierung, Allgemein) oder DO178C (Luftfahrt) gelten für die während der Entwicklung verwendete Tools besondere Anforderungen (siehe Blogbeiträge zur Toolqualifikation aus 2016: Blog 1; Blog 2). Der Compiler spielt hier eine Sonderrolle. Einerseits ist er das zentrale Tool jeder Entwicklung, andererseits sind die in den Normen vorgeschlagenen Maßnahmen in der Praxis für Ihn nur bedingt anwendbar. Der Blog zeigt einen Prozess aus der Luftfahrt für die Compilerverifikation/-validation auf, der auch für andere Industrien sehr zu empfehlen ist.

Branchenübergreifende, gängige Methoden einer Toolqualifikation:

1. Daten aus dem historischen Einsatz des Compilers
2. Assessment des Entwicklungsprozesses des Compilers
3. Test der Funktionalität des Compilers
4. Vollständige Entwicklung des Compilers nach einem Standard der Funktionalen Sicherheit

Die aus Sicherheitsgründen mächtigste Methode Nr. 4 scheidet für den Compiler praktisch aus, da Compiler von kommerziellen Herstellern gebaut werden. Die Kosten für einen Compiler der nach Sicherheitsstandards entwickelt würde, wären so hoch, dass ein gewinnbringender Vertrieb dafür auf dem relativen kleinen Markt der Sicherheitstechnik kaum möglich ist.

Methode Nr. 3 scheidet insofern aus, als dass ein vollständiger Test der Funktionalität eines Compilers aus Gründen der Komplexität nicht möglich ist. Es bleiben entweder zu viele Aspekte ungetestet, oder die Testerstellung ist unwirtschaftlich.

Methode Nr. 2 hat sich bisher am Markt nicht durchgesetzt. Vermutlich auch deswegen, da diese Methode insbesondere auch für Compiler qualitativ nicht hinreichend gute Ergebnisse liefern kann.
Damit verbleibt nur Methode 1. Diese kommt auch zur Anwendung. Mir ist kein sicherheitsrelevantes Projekt bekannt, beim dem ein Compiler zum Einsatz kommt, der ganz neu auf dem Markt ist. In so gut wie allem Funktionalen Sicherheitsprojekten werden hingegen Compiler verwendet, die langjährig auf dem Markt sind und schon mehrfach in vergleichbaren Projekten verwendet wurden.
Da aber historische Daten an sich keine allzugroße Sicherheit bieten für einzelnes konkretes Projekt hat die Luftfahrt einen Prozess entwickelt der die Sicherheit einen Compilerfehler zu entdecken deutlich erhöht.

Minimierung des Risikos von unentdeckten Compilerfehler in der Luftfahrt:

Der Prozess in der Luftfahrt besteht aus zwei Elementen:

1. Für jeden Test verwendet man die genau gleichen Compilereinstellungen, die auch für den operativen Code zum Einsatz kommen.
2. Für besonders sicherheits relvante Projekte (DAL A und B) wird eine Traceability vom Objectcode zum Hochsprachencode (C und C++) gefordert.

Die Erfahrung der letzten 20 – 30 Jahren in der Luftfahrt zeigen deutlich, dass die Anwendung dieser beiden Methoden sehr effektiv sind. In Kombination mit dem Einsatz bekannter Compiler senkt man so das Risiko unentedeckter Compilerfehler auf ein absolutes Minimum. In den Luftfahrtprojekten die mir aus den letzten 15 Jahren bekannt sind, hat man keine Fehler, auch nach langjährigem Feldeinsatz, festgestellt, die auf den Compiler zurückzuführen sind.

Für andere Branchen ist daher auf jeden Fall zu empfehlen, zumindest alle Tests immer mit dem operativen Compiler und den entsprechenden Einstellungen zu verwenden. Mit einer guten Teststrategie und durchdachtenTestumgebung auf jeder Ebene (Unittest, Integrationstest und Systemebene) ist dies meist auch mit kaum einem Mehraufwand verbunden.
Wie die Erfahrung aus der Luftfahrt zeigt, sinkt andererseits das Risiko unentdeckter Compilerfehler dramatisch, wenn bei Tests die sowohl eine strukturelle Coverage sowie eine Requirements Coverage von 95% und mehr nachweisen, kein Compilerfehler entdeckt wurde.

Fazit: Compiler in sicherheits relevanten Projekten

Der Nachweis einer vollständigen Funkionalität scheitert beim Compiler an der Komplexität (siehe Ausführungen zu Methode 3 oben). Für ein einzelnes Projekt ist die verwendete Compilerfunktionalität begrenzt und daher eher vollständig testbar. Genau das erreicht man mit dem Vorgehen in der Luftfahrt erreicht.

Ihre individuellen Fragen zur Funktionalen Sicherheit beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).