MISRA C++ im eigenen Projekt einführen

Anbieter zum Thema

ET System electronic GmbH

MES Electronic Connect GmbH & Co. KG

IBR Leiterplatten GmbH & Co. KG

iSYSTEM AG

Dokumentation von kontrollierten Regelverletzungen

Zur Demonstration des Nachweises, dass der untersuchte Code MISRA C++ genügt, werden zusätzlich zur normalen Dokumentation über den Lebenszyklus des Projektes weitere Dokumente benötigt. Zunächst muss eine Regelbefolgungsmatrix erzeugt werden, die aufzeigt wie Verletzungen der Regeln entdeckt werden. Für jede Regel sollte ein Eintrag vorhanden sein, der zeigt welches Werkzeug oder Werkzeuge und/oder welche Überprüfungsprozesse verwendet werden um Verletzungen der Regeln aufzufinden.

Zweitens, da MISRA C++ erlaubt, dass Regeln absichtlich in kontrollierter Weise verletzt werden (im Gegensatz zu Subsets wie z.B. SPARC ADA), sollte eine Abweichungsprozedur definiert sowie ein zugehöriges Abweichungsprotokoll laufend aktualisiert werden. Die Abweichungsprozedur legt die aktuell gültigen Kontrollen fest und sollte darüber hinaus auch die Prozesse festlegen, die notwendig sind um irgendwelche Abweichungen aufzuzeichnen, zuzulassen und zu überprüfen. Einträge im Abweichungsprotokoll müssen für jede absichtliche Regelverletzung und Instanz einer Regelverletzung getätigt werden. Jeder Eintrag sollte die Einzelheiten der verletzten Regel enthalten, eine Rechtfertigung, sowie die möglichen Konsequenzen, die im Ergebnis auftreten können, zusammen mit einer Demonstration wie die Sicherheit garantiert werden kann. Wird eine Abweichung über das ganze Projekt hinweg angewendet, sollten die Umstände die dazu führen aufgelistet werden.

Der Beweis, dass Code einem Subset genügt, lässt sich mit verschiedenen Methoden von manuell bis automatisch bringen. Während manuelle Codeüberprüfung für kleine Untermengen, die auf einfache Projekte mit nur wenigen Codezeilen angewendet werden, akzeptabel ist, wird dies in der Mehrzahl der Fälle nicht machbar sein. Für große Untermengen wie MISRA C++ ist der automatische Test mittels Werkzeugen, die statische und dynamische Analyse durchführen, eine schlichte Notwendigkeit. Insgesamt ist der Nachweis der Konformität nicht einfach. Muss z.B. einer Zertifizierungsbehörde ein Beweis geliefert werden, dass der Code einer Untermenge genügt, ist wahrscheinlichein dokumentierter Nachweis erforderlich. Dann ist die Verwendung eines Werkzeuges die Voraussetzung um die Arbeitsbelastung im Projekt zu minimieren.

Ein Beispiel ist die LDRA-Werkzeugreihe mit der Quellcode (einzelne Dateien oder vollständige Projekte) analysiert werden können. Es werden diverse Berichte wie der Code Review Report (Codeüberprüfungsreport) erzeugt. Dieser beschreibt die Zustandsinformationen über alle Codierstandards die in der Werkzeugreihe implementiert sind und zeigt auf, welche von ihnen im untersuchten Code verletzt sind. Ein Programmierstandardmodell, ein Filter, der aus einem Satz von Standards besteht, kann auf die Ergebnisse angewendet werden um aufzuzeigen, wie sie sich bezüglich einer bestimmten Untermenge verhalten. Z.B. zeigt Bild 2 wie TBvision verwendet wird um den Codeüberprüfungsreport für eine Datei zu zeigen. Dabei werden die vorhandenen Verletzungen hervorgehoben. Die Ausgabeberichte werden dahingehend überprüft, dass keine unerwarteten Regelverletzungen vorhanden sind.

Zusätzlich erlauben einige Werkzeuge Anmerkungen (speziell formatierte C++-Kommentare im Fall von LDRA), die Meldungen für erwartete Verletzungen unterdrücken. Wenn Anmerkungen verwendet werden, müssen sie im Überprüfungsprozess eingeschlossen sein um sicherzustellen, dass sie von der Dokumentation erfasst werden. Jede unerwartete Verletzung im Quellcode muss durch Änderung des Quellcodes entfernt werden. Schließlich und endlich müssen alle diese Prozesse in das Qualitätssicherungssystem integriert werden.

*Chris Tapp ist Anwendungsingenieur bei LDRA und Leiter der MISRA C++ Arbeitsgruppe

(ID:277121)