MISRA Compliance:2020 — MISRA-Regeln und -Richtlinien
MISRA Compliance:2020 konsolidiert und klärt vieles aus den Leitlinien, die sich bisher auf die MISRA C und C++ Coding-Richtliniendokumente verteilt haben.
Hierdurch sollen sowohl Software-Erwerber als auch -Lieferanten zu einem klareren Verständnis der MISRA-Compliance zu Beginn eines Projektes gelangen
Im zweiten Teil von MISRA Compliance:2020 führt das Dokument die besten Praktiken zur Durchsetzung der MISRA-Regeln und -Richtlinien auf und erörtert, wie mit MISRA-Abweichungen umzugehen ist.
Durchsetzung von MISRA-Regeln und -Direktiven
Ein perfektes statisches Analysetool identifiziert jeden Verstoß gegen MISRA-Regeln und generiert keine Falschmeldungen. Leider hat jeder MISRA-Checker seine Grenzen. Das liegt daran, dass zwar die meisten MISRA-Regeln entscheidbar, manche jedoch unentscheidbar. sind
Abschnitt 3 des Compliance-Dokumentes enthält eine hilfreiche Erklärung des Konzeptes der Entscheidbarkeit.
MISRA-Regeln und -Direktiven
Die MISRA C:2012-Richtlinien klassifizieren jede Richtlinie entweder als Regel oder Direktive.
Die Einhaltung einer Direktive kann nicht allein anhand der Prüfung des Quellcodes festgestellt werden, sondern es sind auch Prozessüberprüfungen, Dokumentationen und Funktionsanforderungen erforderlich, um die vollständige Konformität mit Direktiven festzustellen.
Die Einhaltung einer Regel wiederum kann allein anhand der Prüfung des Quellcodes festgestellt werden, so dass statische Quellcode-Analysetools eingesetzt werden können, um die Konformität mit Regeln festzustellen.
Leider gibt es einige Regeln, bei denen kein Tool eine hundertprozentige endgültige Antwort auf die Frage „Erfüllt der Code diese Regel?“ liefern kann. In manchen Situationen ist Compliance ungewiss.
Laut MISRA Compliance:2020 ist die Fähigkeit zur Diagnose einer Nichteinhaltung mit unentscheidbaren Regeln je nach den verschiedenen Tools sehr unterschiedlich.
Zudem wird darin betont, wie wichtig die Verwendung eines Tools ist, das ein hohes Maß an Erfolg bei der Meldung und Erkennung definitiver Verstöße sowie möglicher Verstöße bietet, um falsch positive und falsch negative Ergebnisse zu vermeiden.
Analysetools, die zuverlässig mögliche Verstöße erkennen, können durch die Einführung von Best-Practice-Kodierverfahren helfen, Unklarheiten zu beseitigen.
Beispiel für eine unentscheidbare Regel
In Regel 12.2 heißt es: „Der rechte Operand eines Shiftoperators liegt im Bereich null bis eins unter der Bitbreite des essentiellen Typs des linken Operanden.“
Diese Regel verhindert undefiniertes Verhalten, das sich aus der Links- oder Rechtsverschiebung eines Wertes mit einer ungültigen Anzahl von Bits ergeben würde.
Beim unten stehenden Code, bei dem der rechte Operand ein konstanter Wert ist, ist es für ein Tool einfach, den Regelverstoß zu erkennen:
Abbildung 1
extern unsigned long ula;
extern void foo(void)
{
ula = ula << -2; /* 2790 */
ula = ula << 40; /* 2790 2921 */
}
Helix QAC generiert die Meldung 2790: „Konstant: Rechter Operand des Schiebeoperators ist negativ oder zu groß.“
(Helix QAC generiert außerdem die Meldung 2921: „Definit: Linksverschiebungsoperation auf Ausdruck von vorzeichenlosem Typ resultiert in Verlust höherwertiger Bits“, weil erkannt wird, dass es in diesem Kontext immer einen Verlust höherwertiger Bits geben wird.)
Betrachten Sie nun aber das folgende Beispiel:
Abbildung 2
void foo(unsigned long ul, int si)
{
if (si > 40)
{
}
ul = ul << si; /* 2792 */
}
In diesem Fall kann der Wert des rechten Operanden (etwa die Anzahl der zu verschiebenden Bits) manchmal außerhalb des zulässigen Bereichs liegen (unter der Annahme, dass die Größe eines Long 32 Bit beträgt).
Sofern die if -Anweisung nicht redundant ist, impliziert der Code, dass der Wert von si erwartungsgemäß manchmal 40 übersteigt, und falls ja, das Verhalten der darauf folgenden Verschiebungsoperation undefiniert sein wird.
In diesem Fall generiert Helix QAC die Meldung 2792: „Offensichtlich: Rechter Operand des Schiebeoperators ist negativ oder zu groß.“
Die hochentwickelte Datenflussanalyse von Helix QAC bietet einen systemweiten Überblick über alle Übersetzungseinheiten in Ihrem Programm, um zu bestimmen, ob Probleme definitiv oder möglich sind.
Das ist nur einer der Gründe, warum jeder der weltweiten Top-10-Automobilzulieferer für MISRA-Compliance auf Helix QAC zurückgreift.
Back to topDurchsetzung der MISRA-Richtlinien
Zwar werden Kodierungsstil-Aspekte durch die MISRA-Kodierrichtlinien explizit ausgeschlossen, aber MISRA Compliance:2020 erkennt die Bedeutung eines konsistenten Kodierungsstils an, um es den Programmierern zu erleichtern, den von anderen geschriebenen Code zu verstehen.
In Abschnitt 2.4 des Compliance-Dokumentes wird empfohlen, dass alle Organisationen einen „Hausstil“ definieren, der Aspekte wie Code-Layout und Einrückungen, Layout von Klammern und Blockstrukturen, Namenskonventionen und Kommentare umfasst.
Darüber hinaus wird in MISRA Compliance:2020 spezifisch auf C Style: Standards and Guidelines von David Straker Bezug genommen.
Helix QAC beinhaltet die Komponente „Namecheck“, die helfen kann, die Einhaltung Ihrer hauseigenen Namenskonventionen zu gewährleisten. Sie können QAC so konfigurieren, dass Namecheck immer gemeinsam mit Ihrer MISRA C oder C++-Analyse läuft.
Wenn Sie den MISRA-Regel-Checker von Helix QAC gemeinsam mit einem konfigurierten Namecheck laufen lassen, können Sie vor dem Testen und der manuellen Codeprüfung so viele Kodierungsprobleme wie möglich erfassen.
Back to topManagement von MISRA-Metriken
Die Erfassung von Metriken ist zur Messung und Verbesserung Ihrer Codequalität unerlässlich.
In Abschnitt 2.5 des Compliance-Dokumentes wird dringend die Nutzung eines Tools zur Erfassung von Quellcodemetriken empfohlen, um Codebereiche zu erkennen, die konzentriertere Prüfungen und Tests erfordern.
Metriken können außerdem helfen, die Erstellung von Code zu verhindern, der schwierig zu testen und zu pflegen ist.
Das Dokument schreibt nicht genau vor, welche Metriken bei einem MISRA-konformen Projekt verwendet werden sollten, da dies basierend auf der Art des Projektes festgelegt werden sollte.
Üblicherweise wird die gesamte Codequalität in eine Reihe von Zielen wie „Zuverlässigkeit“, „Testbarkeit“, „Pflegbarkeit“ u. a. aufgegliedert.
Metriken in Bezug auf diese Qualitätsziele werden eingesetzt, um zu messen, inwieweit diese Ziele erreicht wurden, und um Codequalitäts-Trends im Laufe der Zeit zu überwachen.
So werden sich beispielsweise eine Erhöhung der Codekomplexität und/oder eine steigende Anzahl von Fehlern wahrscheinlich negativ auf die Zuverlässigkeitsziele auswirken.
Eine steigende Codekomplexität wird zudem die Pflegbarkeit reduzieren, neben weiteren Faktoren wie einer erhöhten Codegröße und einer engeren Kopplung zwischen Modulen.
Helix QAC produziert metrische Daten, während es gleichzeitig Ihren Code auf MISRA-Compliance überprüft. Es produziert datei- und funktionsbasierte Metriken für C Code und fügt klassenbasierte Metriken für C++ Code hinzu.
Es kann Warnmeldungen generieren, wann immer eine Metrik Ihren gewählten Schwellenwert überschreitet. Das bedeutet, dass Überschreitungen von Metrikschwellenwerten direkt von den Entwicklern angegangen werden können, noch bevor Code festgelegt wird
Back to topManagement von MISRA-Abweichungen
Die meisten Projekte müssen zwangsläufig gegen eine oder mehr MISRA-Regeln verstoßen.
Laut Abschnitt 4 des Compliance-Dokumentes sind Regelverstöße manchmal nicht zu vermeiden.
Ein Regelverstoß bedeutet nicht, dass Ihr Code nicht MISRA-konform sein kann. Wichtig ist, dass Regelverstöße ordnungsgemäß als „Abweichungseintrag“ geprüft, autorisiert und formell dokumentiert wurden.
Eine Abweichung kann für einen einzelnen Regelverstoß oder für einen Anwendungsfall gelten, der an mehreren Stellen im gesamten Code auftritt.
Es ist wichtig, jeden Verstoß im Zusammenhang mit einem Abweichungseintrag identifizieren zu können, um einen zuverlässigen Prüfungsprozess zu unterstützen.
Im Dokument wird anerkannt, dass es häufig Anwendungsfälle gibt, die Abweichungen erfordern. Um Projektaufwand zu vermeiden, können „Abweichungsgenehmigungen“ für solche Abweichungen verwendet werden.
Zwischen dem Lieferanten und dem Erwerber könnte zu Beginn eines Projektes ein Repository für Abweichungsgenehmigungen vereinbart werden, um Zeit zu sparen, sobald das Projekt angelaufen ist.
Die gemeinsame Nutzung von Helix QAC mit dem Helix QAC Dashboard ermöglicht ein einfaches Management Ihrer MISRA-Abweichungen.
Mithilfe des Feature „Diagnoseausblendung“ von Helix QAC können Sie Diagnosen, bei denen es legitime Gründe für eine Abweichung von der vollständigen Einhaltung der Kodierungsnormen gibt, vor Usern verbergen. Diese Ausblendungen können mit Abweichungseinträgen verlinkt werden, die alle in der Datenbank des Dashboards gespeichert sind.
Das System pflegt also Ihr Repository mit Abweichungseinträgen zusammen mit der Liste aller damit verbundenen Verstöße. Dies kann mithilfe der Berichtskomponente „Ausblendungs- und Abweichungsliste“ als Teil Ihres Compliance-Berichtes ausgegeben werden.
Es können projektbasierte Genehmigungseinstellungen verwendet werden, um einzuschränken, welche User Ausblendungen und Abweichungen hinzufügen und entfernen dürfen. Auf diese Weise können nur User mit ausreichender Befugnis Diagnosen ausblenden und Abweichungen erstellen.
Diese native Unterstützung eines MISRA-konformen Abweichungsprozesses ist ein weiterer Grund, warum Helix QAC von hunderten Organisationen weltweit eingesetzt wird, die missionskritische Systeme entwickeln.
Back to topNutzen Sie Helix QAC zur Durchsetzung der MISRA-Regeln und -Richtlinien
Helix QAC findet und meldet Verstöße gegen MISRA-Regeln, -Richtlinien und -Abweichungen in C und C++. Er ist der beste statische Codeanalysator für MISRA C und C++, weil er
- über eine vollständig dokumentierte Regeldurchsetzung und Meldungsinterpretation verfügt
- eine vollständig konfigurierbare Regelverarbeitung bietet
- unabhängig zertifiziert für den Einsatz in der Entwicklung sicherheitskritischer Software ist
- mit umfangreichem Beispielcode geliefert wird
MISRA-Compliance leicht gemacht
Back to top