Fünf praktische Tipps zum Erlangen der MISRA-Konformität

Coding-Standards wie MISRA:C sollen bereits bei der Entwicklung von Software gewährleisten, dass das Endergebnis auch stabil und sicher ist.Damit Sie über alle Handlungsempfehlungen den Überblick behalten folgen hier fünf Tipps, wie Sie ziemlich sicher einen MISRA-konformen Code erhalten.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Es gibt Dutzende von Tools, die Sie darüber informieren, ob Ihr C- oder C++-Code die MISRA-Regeln verletzt. Das Identifizieren und Behandeln der von einem solchen Analyse-Tool gemeldeten Regelverletzungen kann für den einzelnen Entwickler durchaus eine Herausforderung darstellen, aber für das Entwicklungs-Team insgesamt ist es dennoch nur ein kleiner Teil des Compliance-Prozesses. Für Viele dürfte es eine Überraschung darstellen, dass das MISRA-C:2012-Dokument nicht weniger als sechs Kapitel mit Handlungsempfehlungen enthält, bevor die Richtlinien selbst definiert werden.

Lässt die detaillierte Analyse der Regelverletzungen einmal außen vor und betrachtet alles aus einer höheren Warte, so treten die größeren Fragen über den Prozess insgesamt deutlicher hervor. Auch wenn das MISRA-Dokument „MISRA Compliance:2016“ wesentlich weniger Aufmerksamkeit erregt als die eigentlichen Sprach-Teilmengen, ist es von unschätzbarem Wert für das Verständnis, wie die von Ihrem statischen Analyse-Tool markierten Informationen in den größeren Kontext einer MISRA-konformen Applikation einzuordnen sind.

Bildergalerie

Nur allzu leicht könnte man das Wesen der MISRA-Konformität missverstehen und annehmen, eine minimierte Anzahl an Regelverletzungen biete die Gewähr dafür, dass die Applikation in Sachen Safety und Security optimiert ist. Um aber wirksam zu sein, müssen die MISRA-Richtlinien innerhalb eines Gerüsts angewandt werden, das die Vorteile des konformen Codes nutzt und mit jeglichen notwendigen Abweichungen umgeht, denn nur so kann das Konzept der Konformität glaubwürdig sein.

Das Dokument „MISRA Compliance:2016“ umfasst insgesamt 33 Seiten. Ein kurzer Artikel wie dieser kann deshalb unmöglich auf alle darin behandelten Themen eingehen. Allerdings kann ein solcher Beitrag durchaus Einblicke darin geben, wie ein konformes Projekt aussehen könnte. Die darin enthaltenen Tipps sind von Prinzipien abgeleitet, die im MISRA-Compliance-Dokument skizziert werden, und dementsprechend enthalten sie ein gewisses Maß an technischer „Weisheit“ sowie eine Menge gesunden Menschenverstand.

1. Die MISRA-Konformität verlangt nach einem dokumentierten Softwareentwicklungs-Prozess

Die MISRA-Richtlinien sind für die Verwendung in einem formalen Softwareentwicklungs-Prozess vorgesehen. Ein solcher Prozess bietet die Gewähr für vollständige, unzweideutige und korrekte Softwareanforderungen sowie dafür, dass sich alle diese Anforderungen (und nur diese) in den Artefakten widerspiegeln, die in den verschiedenen Phasen des Softwareentwicklungs-Lebenszyklus generiert werden (vgl. Bild 1).

Wenn Ihr Code keine Regelverletzungen enthält, aber dennoch seine gewünschte Funktion nicht erfüllt, bleibt er einfach unzureichend.

2. Nicht alle MISRA-Richtlinien lassen sich durch Analyse-Tools prüfen

Ds macht sich vor allem an den folgenden drei Punkten bemerkbar:

• Die MISRA-C:2012-Richtlinien führten ein System ein, innerhalb dessen jede Richtlinie (guideline) entweder als Regel (rule) oder als Direktive (directive) klassifiziert wird. Üblicherweise sind Regeln hinreichend gut definiert, um durch ein automatisiertes Tool geprüft zu werden, während Direktiven etwas subjektiverer Natur sind. Ein Beispiel ist die Direktive 1.1 in MISRA C:2012. Sie verlangt, dass „jedes von der Implementierung definierte Verhalten, von dem der Ausgang des Programms abhängt, zu dokumentieren und zu verstehen ist“.

• In MISRA C:2012 werden einige Regeln als „unentscheidbar“ bezeichnet. Das bedeutet, dass es grundsätzlich keine Methode geben kann, die allgemein sicher aussagen kann, ob eine Regelverletzung vorliegt oder nicht. Ein Tool kann also vor einem potenziellen Problem warnen oder nicht. In beiden Fällen ist ein gewisses Maß an manueller Intervention erforderlich.

• Es sind nicht alle Tools gleich. Einigen wird bescheinigt, sie böten eine umfangreichere Regelüberdeckung als andere, und einige versagen bei etwas subtileren Regelverletzungen. Gibt ein Tool die Meldung aus, dass „keine Regelverletzungen“ vorliegen, kann dies in Wirklich bedeuten: „keine Regelverletzungen bis auf jene, die ich nicht bemerkt habe“.

Eine der Definitionen für das Wort „Tool“ (Werkzeug) im Oxford Dictionary lautet: „Ein Ding, das bei der Ausführung einer Aufgabe hilft“. Sehr treffend: Werkzeuge helfen, aber sie nehmen Ihnen das Erledigen der Aufgabe nicht ab.

3. Richtlinien sind nur dann hilfreich, wenn ein Plan für ihre Durchsetzung existiert

Bei den meisten Richtlinien besteht die zuverlässigste und kosteneffektivste Möglichkeit zu ihrer Durchsetzung darin, ein statisches Analysetool, den Compiler oder eine Kombination aus beiden anzuwenden (siehe Bild 2).

Bei diesen Richtlinien ist unbedingt sicherzustellen, dass das bzw. die zu verwendende(n) Werkzeug(e) erwiesenermaßen geeignet sind und dass ihr Typ und ihre Version spezifiziert und festgelegt sind.

Außerdem muss es Durchsetzungspläne für jene Richtlinien geben, die ein gewisses Maß an manueller Verifikation benötigen.

4. „Abweichung“ ist kein Unwort

Mit großer Wahrscheinlichkeit gibt es in jeder realen Embedded-Applikation einige unvermeidbare Regelverletzungen. Der Umgang mit diesen Regelverletzungen muss durch einen klar definierten Prozess autorisiert und durch eine geeignete „Abweichungs-Aufzeichnung“ unterstützt werden, damit eine Konformitätsbehauptung für die resultierende Applikation glaubwürdig sein kann.

Diese Abweichungs-Aufzeichnungen müssen die verletzte(n) Richtlinie(n), die Rechtfertigungen für diese Regelverletzung(en), die Umstände, unter denen die jeweilige Abweichung zum Tragen kommt, sowie die betreffende Codebasis enthalten.

5. Übernommener Code darf nicht ignoriert werden

Ein Großteil der Dokumentation und viele der Standards, die sich auf funktional sichere und geschützte Embedded-Software beziehen, gehen von der Annahme aus, dass jedes Projekt von Grund auf neu geschrieben wird. Die Praxis sieht jedoch oft anders aus: Häufig müssen die Entwickler auf vorhandenem, entweder im eigenen Haus oder von Dritten entwickeltem Code (z. B. Gerätetreiber sowie Mathematik- oder Grafik-Bibliotheken) aufbauen.

Auch wenn es eindeutig nicht praktikabel ist, die MISRA-Richtlinien rückwirkend auf solchen Code anzuwenden, kommt es im Interesse der MISRA-Konformität darauf an sicherzustellen, dass dieser „übernommene Code“ die Security und Safety des Systems insgesamt nicht kompromittieren kann.

Fazit: Zuverlässige Funktion nicht nur für kritische Systeme gewährleisten

Es ist kein Zufall, dass viele funktional sichere Systeme, die in Übereinstimmung mit Standards wie ISO 26262, IEC 61508 oder DO-178C entwickelt wurden, auf die MISRA-Sprach-Teilmengen zurückgreifen. Dies wiederum kann zu der Annahme verleiten, dass die MISRA-Konformität nur für diese Umgebungen relevant ist.

Dies wäre jedoch ein Trugschluss. Ebenso trifft nämlich zu, dass – neben den Richtlinien in der Sprach-Teilmenge selbst – viele der zugrundeliegenden Anforderungen, die erfüllt sein müssen, damit die MISRA-Konformität zu Recht behauptet werden kann, im Grunde auf dem gesunden Menschenverstand und der Entschlossenheit basieren, es richtig zu machen. Dies aber darf nicht allein den kritischen Systemen vorbehalten bleiben, denn ein System muss nicht unbedingt kritisch sein, um die Motivation dafür zu rechtfertigen, es zuverlässig funktionieren zu lassen.

CERT vs. MISRA vs. ISO/IEC 17961

Der richtige Coding-Standard für sichere Embedded Software

Coding-Guidelines: Sind Programmierrichtlinien Fluch oder Segen?

Der Autor

* Mark Pitchford erwarb seinen Abschluss als Bachelor of Science an der Trent University, Nottingham, und ist seit mehr als 20 Jahren Diplomingenieur. Von 2007 bis 2014 arbeitete er als FAE bei LDRA. Im Anschluss wechselte er als Technical Manager für den Bereich EMEA zu Lynx Software Technologies, bevor er im Februar 2017 zu LDRA zurückkehrte. Dort ist er als Technical Specialist tätig.

(ID:45880266)