Strukturelle Abdeckung des Objektcodes für DO-178​C

Die Einhaltung der DO-178C-Vorschriften für Software in Avioniksystemen stellt besondere Herausforderungen dar, insbesondere wenn es darum geht, eine umfassende strukturelle Abdeckung auf Objektcodeebene sicherzustellen. Diese Präsentation untersucht praktische Methoden zur Optimierung dieses Prozesses und konzentriert sich dabei auf die Reduzierung des Testaufwands und die Beschleunigung der Markteinführung.

Lernen Sie Methoden kennen, um Tests zu fokussieren und redundanten Aufwand beim Testen der strukturellen Maschinencodeabdeckung zu reduzieren, wie in DO-178C 6.4.4.2 beschrieben. Hochentwickelte Quellsprachen wie C++ entwickeln sich ständig weiter. Je einfacher es für einen Entwickler ist, sich über eine höhere Quellsprache auszudrücken, desto schwieriger ist es, den entsprechenden, vom Compiler generierten Maschinencode zu verfolgen.

Anhand von Beispielen verfolgt diese Präsentation einen iterativen Ansatz für den Prozess der Erstellung einer vollständigen strukturellen Abdeckung von Maschinencode und zeigt Best Practices in der Praxis, um die Markteinführungszeit zu verkürzen.

Key Take Away

• Einfache Kategorisierungen für strukturelle Mängel bei der Maschinencodeabdeckung.
• Beispiellösungen für gängige Kategorien von ungetestetem Maschinencode.
• Strategien zur Minimierung des Aufwands beim Debuggen von Maschinensprache.

Die Herausforderungen von DO-178C verstehen

DO-178C-Konformität umfasst mehrere wichtige Ziele, die durch den Design Assurance Level (DAL) Ihrer Software beeinflusst werden können. Dazu gehören:

• Bidirektionale Rückverfolgbarkeit der Anforderungen: Sicherstellen einer klaren Verknüpfung von Anforderungen zu Testfällen, Code und Überprüfungen.
• Erfüllung der Compliance-Ziele: Identifizieren und Abgrenzen notwendiger Ziele.
• Zielhardwarevalidierung: Testen auf dem tatsächlichen System, das zertifiziert werden soll.
• Einhaltung des Codierstandards: Einhaltung von Standards wie MISRA, AUTOSAR C++14 oder benutzerdefinierten Regeln.
• Daten- und Steuerungskopplungsanalyse: Führen Sie diese Analyse durch und dokumentieren Sie sie, falls dies von Ihrem DAL verlangt wird.
• Strukturelle Codeabdeckung: Überprüfen, ob alle Anforderungen getestet wurden.
• Assembly-Code-Abdeckung: Erfüllen der Abdeckungsanforderungen auf Montageebene, falls vorgeschrieben.
• Werkzeugqualifikation: Verwenden Sie Tools, die mit einem Tool-Qualifizierungspaket für Ihr Entwicklungsökosystem geliefert werden.
• Compliance-Management-Plan: Einen klaren Plan und fachkundige Anleitung für den Zertifizierungsprozess haben.

Parasoft bietet Lösungen zur Bewältigung dieser Herausforderungen, darunter Integrationen mit ALM-Tools zur Rückverfolgbarkeit, Unterstützung verschiedener Codierungsstandards und Funktionen zur gezielten Hardwareüberprüfung.

Entdecken Sie, wie DO-178C den Software-Compliance-Prozess strukturiert in unserem ausführlichen Ratgeber.

Objektcode-Verifizierung: Ein tieferer Einblick

Korrektheit auf Objektcodeebene zu erreichen, ist eine anspruchsvolle Aufgabe. Die Strategie besteht darin, sich auf kleine, isolierte Lückenbereiche mit mangelhafter struktureller Abdeckung zu konzentrieren. Dazu werden die Ergebnisse von Testverfahren auf Quellcodeebene mithilfe von Objektinstrumentierung ausgewertet.

Durch Instrumentierung auf Quellcodeebene für Anforderungen, MCDC (Modified Condition/Decision Coverage) und On-Target-Tests erreichen Sie eine nahezu vollständige strukturelle Abdeckung auf Objektebene, ohne den Objektcode zunächst direkt untersuchen zu müssen. Kumulative Berichte können dann Ergebnisse verschiedener Testmethoden mit Instrumentierung auf Objektebene kombinieren.

Der Unterschied in der MCDC-Messbarkeit: Quelle vs. Montage

Betrachten Sie eine einfache A OR B Ausdruck. Um eine 100%ige MCDC-Abdeckung auf Quellebene zu erreichen, sind drei Testläufe erforderlich, um A und B. Wenn dieser C-Code kompiliert wird, kann die resultierende Assembly unterschiedliche Verzweigungsstrukturen aufweisen.

Wenn Sie MCDC-Tests von Grund auf auf Assemblyebene durchführen, verpassen Sie möglicherweise die Abdeckung von Verzweigungsanweisungen, wenn Sie einen erforderlichen Testlauf auslassen. Wenn Sie jedoch bereits MCDC-Tests auf Quellcodeebene durchgeführt haben, ist dieser dritte Testlauf wahrscheinlich bereits enthalten, sodass Sie ohne zusätzlichen Aufwand eine vollständige Abdeckung auf Assemblyebene erhalten.

Mangelhafte strukturelle Objektcodeabdeckung für bedingte Verzweigungen

Compiler führen häufig implizite Prüfungen, Grenzwertprüfungen oder Optimierungen ein, die im Quellcode auf höherer Ebene nicht direkt erkennbar sind. Dies kann zu einer unzureichenden Abdeckung allein auf Quellcodeebene führen.

Beispielsweise kann beim Testen einer C-Funktion eine MCDC-Abdeckung von 100 % auf Quellcodeebene erreicht werden. Bei der Untersuchung der Assembly-Ausgabe kann jedoch eine Verzweigungsabdeckung von 97 % mit einer bestimmten Sprunganweisung (z. B. jump if above to L51) nicht ausgeübt wird.

Dieser Mangel könnte auf eine vom Compiler eingeführte Prüfung des Enumerationswerts außerhalb des zulässigen Bereichs zurückzuführen sein. Um dies zu beheben, können Sie einen spezifischen Testfall mit einem Parameter erstellen, der den Enumerationswert außerhalb des erwarteten Bereichs zwingt. Indem Sie diesen isolierten Test ausführen und seine Abdeckungsergebnisse mit Ihrer vorhandenen MCDC-Abdeckung zusammenführen, können Sie die Lücke schließen und die Gesamtabdeckung des Zweigs erhöhen.

Strukturelle Abdeckung für Anweisungen ohne Quellcode-Darstellung

Einige vom Compiler generierte Konstrukte, wie Dateiformatierung, funktionale Schnittstellen oder Systemprüfungen (z. B. Stack-Smashing-Schutz), sind möglicherweise nicht direkt im Quellcode abgebildet. Um diese abzudecken, müssen Sie die Produktions-Ausführbare selbst instrumentieren.

Wenn beispielsweise eine Funktion mit einem Stack-Check-Fail-Aufruf endet und dieser Pfad nicht durch Ihre Unit-Tests abgedeckt ist, instrumentieren Sie die Produktions-Ausführbare. Indem Sie diese instrumentierte Ausführbare ausführen und ihren Zustand manipulieren (z. B. einen Registerwert wie RCX um einen Sprung zum Scheitern zu bringen), können Sie den mangelhaften Pfad ausführen. Die Abdeckungsdaten aus dieser Ausführung können dann mit Ihren vorhandenen Abdeckungsberichten zusammengeführt werden, wodurch eine Anweisungsabdeckung von 100 % für diesen Abschnitt erreicht wird.

Strategien für den Erfolg

• Priorisieren Sie Tests auf Quellcodeebene: Bemühen Sie sich, die Testziele im Quellcode auf hoher Ebene, im MCDC-Testmodus und im Funktions-/Produktionstestmodus zu erreichen. Dadurch wird die Anzahl der Lücken, die Sie auf Assemblyebene schließen müssen, erheblich reduziert.
• Fokus auf Lückenanalyse: Durch die Konzentration auf bestimmte Mängel können Sie die erforderlichen Ausführungspfade leichter finden und dokumentieren.
• Nutzen Sie die kollaborative Berichterstattung: Indem Sie die Abdeckung um kleine, einzigartige Teile für bestimmte Testzwecke ergänzen, fördern Sie eine stärkere Zusammenarbeit, bei der einzelne Personen einen Teil der Abdeckung beitragen können, ohne dass sich die Arbeit an gemeinsam genutztem Code überschneidet.
• Automatisieren Sie die Instrumentierung: Verwenden Sie Toolchains, die die ursprüngliche Toolchain erweitern können, um Assembly-Anweisungen zum Aufzeichnen von Ausführungspfaden einzufügen. Dies kann in Build-Prozesse wie Makefiles oder CMake integriert werden.
• Abdeckungsdaten zusammenführen: Abdeckungsdaten aus verschiedenen Quellen (Unit-Tests, Produktions-Executables) können zusammengeführt werden, indem die Abdeckungsaufzeichnungen auf eine gemeinsame AST-Darstellung (Abstract Syntax Tree) des Assemblercodes angewendet werden. Dies ermöglicht kumulative Abdeckungsberichte und kann sogar verwendet werden, um die Gleichwertigkeit von Assemblercode, der durch Unit-Tests erzeugt wurde, mit Produktions-Builds zu bestätigen.