Schwerpunkte

Entwicklungs- und Tooling-Ansätze

MISRA und AUTOSAR Coding Compliance in der Praxis

06. April 2021, 10:00 Uhr   |  Autoren: Dr. Dennis Kengo Oka und Dr. Ralf Huuck; Redaktion: Irina Hübner

MISRA und AUTOSAR Coding Compliance in der Praxis
© Gorodenkoff | Shutterstock.com

Die Automotive-Industrie vollzieht den Shift Left. Sicherheitskriterien werden nun zu einem früheren Zeitpunkt in den Entwicklungsprozess eingeführt. Wie der Shift Left auch für MISRA und AUTOSAR Code Compliance im Rahmen der ISO 26262 und der ISO/SAE 21434 möglich ist, lesen Sie in diesem Beitrag.

Moderne Automotive-Software stellt zunehmend strengere Anforderungen an eine sichere Entwicklung mit Bezug auf Safety und Security. Neben der Entwicklung von Steuergeräten in klassischen Bereichen wie Antriebsstrang, Fahrwerk und Karosserieelektronik werden fortschrittlichere neue Systeme wie digitale Cockpits, Infotainmentsysteme, autonome Fahrsysteme und Connectivity Units entwickelt.

Normen wie die ISO 26262 [1] und ISO/SAE 21434 [2] geben Unternehmen in der Automotive-Branche Leitlinien für die Sicherheit und Schutzmaßnahmen an die Hand. Diese Leitlinien geben Empfehlungen für die Codierung, die Quellcode-Qualität sowie spezifische Codier-Richtlinien wie MISRA [3,4] und AUTOSAR [5].

MISRA und AUTOSAR im Überblick

Die Motor Industry Software Reliability Association (MISRA) definiert eine Reihe von Richtlinien und Direktiven für die C/C++-Softwareentwicklung, die hauptsächlich für sicherheitskritische Systeme in Bereichen wie Automotive, Verteidigung und Avionik gelten. MISRA-C:2012 [3] einschließlich ihrer Addendums [6,7] definiert etwa 175 Entwicklungsrichtlinien, die in 158 Regeln und 17 Direktiven unterteilt sind, und kategorisiert jede Regel weiter in obligatorisch (mandatory), erforderlich (required) und beratend (advisory). Um Unternehmen bei der Umsetzung der Richtlinien zu leiten, wird jede Richtlinie außerdem als entscheidbar oder unentscheidbar definiert.

Entscheidbare Richtlinien lassen sich mit einem Tool zur statischen Analyse validieren. Für die unentscheidbaren Richtlinien erzeugt die statische Analyse jedoch nur ein unvollständiges Bild, das potenziell false positive / negative Ergebnisse liefert.
Darüber hinaus definiert AUTomotive Open System ARchitecture (AUTOSAR) eine Reihe von Richtlinien, die man zusammenfassend als AUTOSAR Coding Guidelines C++ bezeichnet [5]. Diese gelten als Aktualisierung des MISRA-C++:2008-Standards [4] und werden derzeit vom MISRA C++-Ausschuss überarbeitet.

MISRA veröffentlichte 2016 das Dokument MISRA Compliance [8], welches Unternehmen als Anleitung dient, MISRA-konform zu werden. Das Dokument wurde 2020 aktualisiert [9] und beschreibt eine formale Anleitung für den Compliance-Prozess. Es definiert Dokumente und Anforderungen für die Compliance, wie zum Beispiel einen Guideline Enforcement Plan (Plan zur Durchsetzung der Richtlinien), einen Guideline Reclassification Plan (Plan zur Re-Klassifizierung der Richtlinien) und eine Compliance Summary (Compliance-Zusammenfassung).

Diese Anforderungen werden durch optionale Deviation Records (Aufzeichnung von Abweichungen) und Deviation Permits (Abweichungsgenehmigungen) unterstützt. Insbesondere ist es erwähnenswert, dass Regeln, die als beratend kategorisiert sind, im Guideline Reclassification Plan zum Beispiel als vernachlässigbar eingestuft werden können. Das wiederum bedeutet, dass man diese Regeln auf das spezifische Projekt nicht anwenden muss. Darüber hinaus definiert das MISRA-Compliance-Dokument Richtlinien und Einschränkungen dazu, was Compliance bedeutet, unter welchen Einschränkungen Richtlinien umklassifiziert werden können und unter welchen Umständen Abweichungen von den Richtlinien zulässig sind. Zusätzlich sind Anleitungen zum Umgang mit so genanntem Adopted Code (übernommenem Code) wie Binärdateien von Dritten oder Open-Source-Software enthalten.

Obwohl das MISRA-Compliance-Dokument eine recht überschaubare Anleitung bereitstellt, haben viele Unternehmen Schwierigkeiten mit der Umsetzung. Das liegt oft daran, dass sie MISRA- oder AUTOSAR-Analysetools blind anwenden und sich der Compliance-Definitionen und damit auch der Freiheiten innerhalb des Compliance-Prozesses nicht bewusst sind. Dieses sind sowohl Prozessherausforderungen als auch Tool- und Anwendungsprobleme.

Herausforderungen

Auf den ersten Blick erscheint es vergleichsweise einfach, eine Compliance mit den Anforderungen zu erreichen. Zumal, wenn man während der Entwicklung die Codier-Richtlinien befolgt. In der Praxis treten allerdings eine Reihe von Problemen auf. Erstens basiert die Software in neueren Systemen wie digitalen Cockpits, Infotainment-Systemen oder autonomen Fahrsystemen häufig auf Code, der aus verschiedenen Quellen stammt.

Das kann sowohl eigenentwickelter Code sein, Code von Drittanbietern, automatisch generierter Code oder Open-Source-Software. Wenn man für die gesamte Codebasis die Compliance erzielen will, ist das eine relativ große Herausforderung. Einige Teile der Software wurden möglicherweise nicht auf der Grundlage der MISRA- oder AUTOSAR-Codier-Richtlinien entwickelt. Das Scannen der gesamten Codebasis auf MISRA oder AUTOSAR wird dann generell eine hohe Anzahl von Codierungsverstößen zu Tage fördern, die im Unternehmen nicht realistisch bearbeitet werden kann.

Darüber hinaus kann es sein, dass viele dieser Funde aufgrund des spezifischen Richtlinientyps oder der Art der Softwarekomponente, möglicherweise nur eine niedrige Priorität haben und für Security und Safety von nachrangiger Bedeutung sind. Die immense Zahl von Ergebnissen erschwert es, Probleme mit der höchsten Priorität zu identifizieren. Das Ganze wird noch durch die Tatsache verschärft, dass die aktiven Codebasen oft schnell wachsen, und man immer weiter hinter der Entwicklung hinterherhinkt.  Daher brauch man eine Strategie, wie man Tools anwendet und Fehler abarbeitet.

Bild 1. Beispiel für Codesegmentierung, bei der die Codebasis in verschiedene Softwarekomponenten unterteilt ist.
© Synopsys

Bild 1. Beispiel für Codesegmentierung, bei der die Codebasis in verschiedene Softwarekomponenten unterteilt ist.

Ein Lösungsansatz

Unternehmen brauchen als erstes ein klares Verständnis davon, welche Teile der Codebasis und welche Codier-Richtlinien die höchste Priorität haben, um Verstöße effizient anzugehen. Wie bereits erwähnt, ist der Ansatz, die gesamte Codebasis mit einem statischen Code-Analyse-Tool zu scannen, naiv.  Wenn alle Checker für Codier-Richtlinien aktiviert sind, führt das zwangsläufig zu einer hohen Zahl von Befunden. Deshalb soll eine Lösung beschrieben werden, die auf einem zweistufigen Prozess basiert:

Im ersten Schritt sollten Unternehmen relevante Codier-Richtlinien für relevante Teile in der Codebasis identifizieren und eine entsprechende Konfiguration für die Software des Zielsystems erstellen. Diese Regeln müssen vorweg mit dem Abnehmer abgesprochen werden. Möglicherweise lassen sich Ergebnisse aus einer Hazard Analysis and Risk Assessment (HARA) oder einer Threat Analysis and Risk Assessment (TARA) anwenden, um sicherheits- und schutzrelevante Softwarekomponenten in der Codebasis präziser zu identifizieren.

Die Codebasis kann dann in verschiedene Komponenten unterteilt werden, zum Beispiel eigenentwickelte, sicherheitskritische Komponente, automatisch generierte, nicht sicherheitskritische Komponente, fremdentwickelte, sicherheitskritische Komponente, nicht sicherheitskritische Open-Source-Softwarekomponente, kommerzielle, nicht sicherheitskritische Komponente usw. Ein vereinfachtes Beispiel ist in Bild 1 dargestellt. Darüber hinaus kann das Unternehmen kommunizieren, welche Codier-Richtlinien sich für welche Teile der Codebasis eignen. Beispielsweise eignen sich bestimmte Regeln eher für sicherheitskritische Komponenten und weniger für nicht-sicherheitskritische Komponenten.

Ein Tool zur statischen Code-Analyse wird dann entsprechend konfiguriert, um die Codebasis regelmäßig zu scannen. Dabei sucht es nur nach bestimmten Codier-Richtlinien, die für die spezifischen Softwarekomponenten relevant sind. Das macht den Scan-Prozess deutlich effizienter. Firmen sollten dazu ein Tool verwenden, das eine breite Abdeckung von Checkern für Codier-Richtlinien aufweist, um bessere Ergebnisse zu erzielen [10,11].

Bild 2. Beispiele für MISRA-Fundstellen, die von einem Tool zur statischen Code-Analyse entdeckt wurden.
© Synopsys

Bild 2. Beispiele für MISRA-Fundstellen, die von einem Tool zur statischen Code-Analyse entdeckt wurden.

Beispiele für MISRA-Funde mit Coverity [12], einem Tool zur statischen Code-Analyse, sind in Bild 2 visualisiert. Dieses Tool zur statischen Code-Analyse generiert Ergebnisse, die dann in einem zweiten Schritt von einem Tool zur Datenanalyse verarbeitet werden. Ziel ist es, die Ergebnismenge von potenziell Tausenden, wenn nicht Hunderttausenden von Funden zu untersuchen und eine Burndown-Strategie für den Kunden zu erstellen. Das Logilica-Insights-Tool [13] bietet Analysefunktionen wie man sie aus der Business Intelligence kennt und kombiniert diese mit unterschiedlichen visuellen Darstellungen.

Mit Hilfe dieses Werkzeugs können Unternehmen die Befunde analysieren, klassifizieren, visualisieren und leichter einen Einblick in die relevante MISRA-Compliance-Strategie für die Codebasis gewinnen. Neben gängigen Diagramm- und Visualisierungstechniken setzt Logilica auf sogenannte CodeCities [14], die 3D-Karten von Software-Repositorien darstellen.

Bild 3. 3D-Karte zur Visualisierung der Fehlerdichte in der Codebasis.
© Logilica

Bild 3. 3D-Karte zur Visualisierung der Fehlerdichte in der Codebasis.

Jede Datei wird dabei als ein Gebäude dargestellt, Ebenen bilden Ordern ab. Die Höhe, Weite und Farbe der Gebäude wird dann von überlagerten Metriken bestimmt. Bild 3 zeigt ein Beispiel für MISRA-Funde, generiert mit einem Tool zur statischen Code-Analyse und mit dieser Logilica-Technik dargestellt. Die Höhe des Gebäudes spiegelt dabei die Größe der Datei wider und die Farbe des Gebäudes steht für die MISRA-Fehlerdichte (Funde pro Codegröße).

Das rote Gebäude in der Abbildung weist beispielsweise eine hohe Fehlerdichte auf. Solche Dateien und Bereiche geben Anhaltspunkte, was ein Unternehmen vorrangig und mit höherer Priorität betrachten sollte. Darüber hinaus trägt diese Form der visuellen Darstellung dazu bei, Hotspots zu identifizieren, das heißt bestimmte Codebereiche, die eine große Anzahl von Verstößen enthalten, und deren Ursache man auf den Grund gehen sollte. Gleichzeitig lassen sich andere Informationen, wie zum Beispiel Open-Source-Zugehörigkeit, überlagern oder Funde in diesen Bereichen ausblenden.

Multi-Tool Vorteile

Der Vorteil von Lösungen wie hier beschrieben besteht darin, Unternehmen dabei zu unterstützen, die wichtigsten Regelverstöße besser zu identifizieren, ein Verständnis dafür zu schaffen, wo diese Verstöße liegen, das heißt in welchen Komponenten und welchen Dateien, und eine Compliance-Strategie zu definieren. Im ersten Schritt ist es zwingend erforderlich, die Tools und Prozesse richtig zu justieren. Dazu wird das Tool für die statische Analyse anhand der spezifischen Konfiguration der relevanten Codier-Richtlinien für die Zielsoftware konfiguriert, um ein effizienteres Scannen zu erlauben.

Das heißt auch, regelmäßige Scans eventuell täglich durchzuführen.
Im zweiten Schritt bekommen Entwickler und das Engineering-Management mit dem Datenanalysetool einen klaren Einblick in den aktuellen Projektstatus. So kann ein Unternehmen beispielsweise problemlos erkennen, ob die Fehler mehrheitlich in übernommenem Code, zum Beispiel einer Open-Source-Softwarekomponente, entdeckt werden, oder ob es bestimmte Regeln sind, die eine signifikante Anzahl von hohen Fundstellen erzeugen. Auf dieser Basis lässt sich eine geeignete Compliance-Strategie festlegen, zum Beispiel den Burndown in eigenentwickeltem Code zu starten oder die beratenden Regeln erstmal auszuschließen.

Bild 4. Die am häufigsten beanstandeten MISRA-Regeln aus einem Beispielprojekt.
© Logilica

Bild 4. Die am häufigsten beanstandeten MISRA-Regeln aus einem Beispielprojekt.

Wie in Bild 4 visualisiert, gehört zu den am häufigsten beanstandeten Regeln für ein Beispielprojekt die Regel 15.5 mit 13.820 Funden. Diese Regel ist als beratend kategorisiert und könnte für dieses Projekt möglicherweise als nicht anwendbar eingestuft werden. Das wiederum würde bedeuten, dass man die 13.820 Funde ignorieren kann. Solche Strategien helfen Unternehmen, Prioritäten zu setzen, und gestatten es Softwareentwicklern, sich auf die Arbeit an den richtigen Bereichen zu konzentrieren.

Automotive-Systeme entwickeln sich ständig weiter und enthalten immer komplexere Software, einschließlich von Software aus verschiedenen Quellen. Das macht die Software Compliance natürlich zu einer größeren und andauernden Herausforderung. Um diesen Herausforderungen in der Praxis zu begegnen, sollten Unternehmen in der Automotive-Branche die Coding Compliance mit geeigneten Workflows früh in den Prozess miteinbeziehen und entsprechende technische Lösungen anwenden [15].
 


Literatur

[1] ISO, »ISO 26262 - Straßenfahrzeuge - Funktionale Sicherheit«, 2018.
[2] ISO/SAE International, »ISO/SAE DIS 21434 - Straßenfahrzeuge - Cybersecurity engineering«, 2020.
[3] MISRA, »MISRA C:2012 Guidelines for the use of the C language in critical systems«, 2013.
[4] MISRA, »MISRA C++:2008 Guidelines for the Use of the C++ Language in Critical Systems«, 2008.
[5] AUTOSAR, »Guidelines for the use of the C++14 language in critical and safety-related systems«, 2019.
[6] MISRA, »MISRA C:2012 Amendment 1 - Additional security guidelines for MISRA C:2012«, 2016.
[7] MISRA, »MISRA C:2012 Amendment 2 - Updates for ISO/IEC 9899:2011 Core functionality«, 2020.
[8] MISRA, »MISRA Compliance:2016 - Achieving compliance with MISRA Coding Guidelines«, 2016.
[9] MISRA, »MISRA Compliance:2020 - Achieving compliance with MISRA Coding Guidelines«, 2020.
[10] Synopsys, »Coverity Support for MISRA Coding Standards«, 2020.
[11] Synopsys, »Coverity Support for AUTOSAR Coding Standards«, 2020.
[12] Synopsys, »Coverity Static Application Security Testing«, https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html.
[13] Logilica Insights. https://logilica.com.
[14] R. Wettel, and M. Lanza, »CodeCity: 3D visualization of large-scale software«, Proceedings – International Conference on Software Engineering. 2008. 921-922. 10.1145/1370175.1370188.
[15] D. K. Oka, and R. Huuck, »How to Put MISRA and AUTOSAR Coding Compliance into Practice«, Embedded World 2021.

 

Die Autoren

Dr. Dennis Kengo Oka, Synopsys
© Synopsys

Dr. Dennis Kengo Oka, Synopsys

Dr. Dennis Kengo Oka

ist Automotive-Cybersecurity-Experte bei Synopsys – mit über 15 Jahren Erfahrung in der Automotive-Branche weltweit. Er hält einen Ph.D. in Automotive Security mit Schwerpunkt auf Lösungen für das vernetzte Auto. Dennis Oka hat über 60 Arbeiten veröffentlicht, darunter Konferenzbeiträge, Zeitschriftenartikel und Bücher. Er ist ein gefragter Redner auf internationalen Konferenzen und Veranstaltungen im Bereich Automotive und Cybersicherheit.

Dr. Ralf Huuck, Logilica.
© Logilica

Dr. Ralf Huuck, Logilica.

Dr. Ralf Huuck

ist CEO & Gründer von Logilica, Australien, einem führenden Anbieter von Analyselösungen für den Softwarelebenszyklus. Huuck ist seit über 20 Jahren in den Bereichen Anwendungssicherheit und Softwaremanagment tätig. Er hatte zuvor leitende Positionen bei Synopsys, Red Lizard Software und der Forschungseinrichtung NICTA inne. Huuck ist außerordentlicher Professor für Softwaretechnologie an der UNSW in Australien und kann auf über 50 »peer-reviewed« Veröffentlichungen zurückblicken.  

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

Synopsys