Funktionale Sicherheit
Der Standard für funktionale Sicherheit, die IEC61508 empfiehlt, die Programmiersprache C nur für den niedrigsten Safety Integrity Level SIL1. Für SIL3 und SIL4 ist C nur mit geeigneten Codierungs-Standards und Analysetools verwendbar. Eine wichtige Komponente hierfür ist der Programmierstandard MISRA-C. MISRA-C 2004 umfasst etwa 140 Regeln, die in 21 Gruppen unterteilt sind, darunter Initialisierung, Datentypen, Strukturen oder Präprozessor. Ziel von MISRA-C ist es, die erwähnten Schwachstellen des C-Standards zu überwinden und potentielle Risiken bei der Programmierung weitgehend zu verhindern. Statische Code Analyse Tools wie PC-lint haben bereits Support für MISRA-C und, integriert in die ToolChain, helfen die Herausforderungen der Programmiersprache C für sicherheitsrelevante Applikationen zu meistern. Das effektive Management von Software Artefakten, insbesondere Quellcode wird durch solch einen Version Control Server übernommen. Weitere Begrifflichkeiten sind SC(C)M-Source Code (Configuration) Management, RCS – Revision Control System, VCS – Version Control System. Solche Systeme sind seit über 40 Jahren auf unterschiedlichen Plattformen am Markt. Eines der bekanntesten Systeme aus dem Windows Umfeld ist sicherlich Microsoft SourceSafe, aus dem open source Umfeld ist CVS ein heute häufig verwendetes Werkzeug, eine Ableitung davon ist Apache Subversion (SVN) welches als Alternative zu CVS entwickelt wurde um einige Nachteile von CVS zu eliminieren. Eine völlig andersartige Variante ist Git welches aus dem Umfeld von Linus Torvalds und Linux entwickelt wurde. Der sicherlich größte Vorteil von Git ist die Geschwindigkeit bei verteilten Standorten mit niedrigen Netzwerkbandbreiten zwischen den Standorten. Allerdings ist die Lernkurve für Entwickler aus dem „klassischen“ CVS Umfeld deutlich größer und der Support für Windows Server ist ziemlich limitiert. Ein Derivat davon ist Mercurial welches einen besseren Windows Server Support bietet. Auch hier gibt es keinen Königsweg und es ist abhängig von den Entwicklern, den Administratoren und Projektleitern, die die Systeme benutzen werden.
Continuous Integration Server
Der Continous Integration Server stellt das zentrale Werkzeug, in der die Software Integriert, compiliert und dem Build- und Test-Server komplette Versionen zur Verfügung gestellt wird. Häufig werden auf Basis des Integrations Servers statistische Quellcode Analyse Werkzeuge eingesetzt, um die Qualität der Software in einem sehr frühen Stadium beeinflussen zu können. Prominete Vertreter dieser Gattung sind Jenkins und Phyton, beide Werkzeuge haben die Möglichkeit der Integration in die oben genannten Versionskontrollsysteme. Aufgrund der Plug-in-Philosophie sind die Möglichkeiten dieser Werkzeuge sehr mächtig. Angefangen von simplen Untersuchungen, ob alle verwendeten variablen Objekte initialisiert sind bis hin zu statistischen Aussagen über Code-Coverage gibt es fast alles, was das Software-Entwicklerherz höher schlagen lässt. Der Build- und Test-Server hingegen versorgt das Validierungs- und Verifikationsteam mit den aktuell freigegebenen Testversionen und synchronisiert die Versionen für Hardware in the loop (HIL)“-Tests und „Device under Test (DUL)“-Tests.
Fazit
Die Nachvollziehbarkeit von der Anforderung bis zum durchgeführten Test und die überprüfbaren statistischen Aussagen ergeben sich durch die Integration der beschriebenen Werkzeuge. Die nachfolgende Graphik soll dies veranschaulichen. Die Toolchain ist eine Kombination der Prozesse mit den Werkzeugen. Allein die Prozesse können den Nachweis und Rückverfolgbarkeit nur schwerlich und mit erheblichem Aufwand generieren. Die Werkzeuge – die Toolchain – ohne Integration und definierten Prozessen kann dies auch nicht leisten. Eine intelligente Integration der einzelnen Werkzeuge kombiniert mit intelligenten Prozessen, die jeweils auf den benötigten Safety Integrity Level (von Standard Entwicklung ohne SIL Anforderung bis zur SIL3 Anforderung) adaptiert werden, ist das Mittel der Wahl. Der Aufbau der Prozesswelt und der Toolchain kann nicht in einem Big Bang erfolgen, sondern bedarf einer Zielvision und dem kontinuierlichen Umsetzen einzelner Schritte bis nach mehreren Iterationsstufen, die in Summe Jahre dauern können, das Ziel einer integrierten Prozess- und Werkzeugwelt erreicht ist.