Luft- und Raumfahrt Entwicklung DO-178C-konformer Software für Luftfahrtsysteme

Sichere Software spielt nicht nur in der Automobilindustrie eine wichtige Rolle, sondern auch in der Luftfahrt. Als Nachweis dafür dient die DO-178C, die wesentliche Änderungen im Vergleich zur Vorgängerversion DO-178B beinhaltet.

Investitionen in die Entwicklung von Software für Luftfahrtsysteme verlangen die strikte Einhaltung von Industriestandards wie DO-178C. 2013 haben die Federal Aviation Regulations (FAA) DO-178C als anerkanntes Mittel zum Nachweis der Lufttüchtigkeit festgelegt. Die FAA benutzt DO-178C, offiziell „Software Considerations in Airborne Systems and Equipment Certification" genannt, als Leitfaden zur Bestimmung der Software-Sicherheit. Sie betrachtet also eine Software-Komponente als lufttüchtig, wenn diese in Übereinstimmung mit DO-178C entwickelt wurde. Es gibt einige wesentliche Änderungen gegenüber dem vorherigen Standard DO-178B – darum ist es wichtig, die Unterschiede zu verstehen.

Im Vergleich: DO-178B und DO-178C

In den meisten Punkten sind DO-178B und DO-178C identisch. Der Großteil des Wortlauts wurde übernommen. Einige der übergeordneten Ziele, Prozesse und Definitionen wurden in DO-178C näher erläutert. So fügt DO-178C beispielsweise in Kapitel 6.1, das den Zweck des Software-Verifizierungsprozesses definiert, den folgenden Zweck in Bezug auf den ausführbaren Objektcode hinzu: „Der ausführbare Objektcode ist robust gegenüber Software-Anforderungen, so dass er auf anormale Eingaben und Bedingungen korrekt reagiert.“ Das gilt zusätzlich zu der Aussage in DO-178B, die festlegt, wie der ausführbare Objektcode zu verifizieren ist. „Der ausführbare Objekt-Code erfüllt die Software-Anforderungen, also die beabsichtigte Funktion, und bietet Sicherheit, dass es keine unbeabsichtigten Funktionen gibt."

Die zusätzliche Anforderung erklärt im Detail, wie der ausführbare Objektcode dafür sorgen soll, dass das System sicher funktioniert. Bisher war der Mindestumfang des Verifizierungsprozesses zu riskant, so dass es zu Systemausfällen kam. In vielen Fällen versucht die Sprache in DO-178C Konzepte, Funktionen und Prozesse detaillierter zu definieren. Allerdings gibt es eine wichtige erwähnenswerte Aktualisierung. Beide Versionen zeigen zwar, wie man den Prozess der Software-Entwicklung nachvollziehen kann, aber nur DO-178C kann das auch in beide Richtungen (bidirektionale Traceability).

Für Unternehmen, die DO-178C einhalten müssen, bedeutet die neue Anforderung, dass sie ein System brauchen, das Richtlinien durchsetzt und flexibel genug ist, um eine bidirektionale Traceability zu gewährleisten. Zum Zeitpunkt der Erstellung dieses Dokuments erklärt die FAA-Verordnung 8110.49A, „Software Approval Guidelines“ (Richtlinien für die Software-Zulassung), wie die Mitarbeiter der FAA-Flugzeugzertifizierungsstelle RTCA/DO-178B und RTCA/DO-178C bei Zertifizierungsprojekten verwenden und anwenden können. Die Richtlinien gelten für die Zertifizierung von Bordsystemen und -ausrüstung sowie für Software-Aspekte dieser Systeme.

DO-178B/C ist ein detaillierter Rahmen für die Integration einer Richtlinien-basierenden Software-Entwicklungsstrategie. Er bildet auch die Definition von Aufgaben, die zur Risikominderung durchgeführt werden müssen. Der Schlüssel zur Eindämmung von Risiken liegt in der Ausrichtung der Softwareentwicklungsaktivitäten an den Geschäftszielen des eigenen Unternehmens. Das wird durch eine „richtliniengesteuerte (Policy-Driven) Entwicklung“ sicherstellt.

Policy-Driven Development umfasst folgende Aufgaben:

• Klare Definition der Erwartungen und Dokumentation in verständlichen Richtlinien.

• Schulung der Entwickler über die Geschäftsziele, die hinter diesen Richtlinien stehen.

• Automatisierte und diskrete Durchsetzung der Richtlinien.

Eine Richtlinien-basierende Strategie hilft Unternehmen, die Produktivität und Qualität der Anwendungen genau und objektiv zu messen. Das senkt die Entwicklungskosten und reduziert die Risiken. Es ist wichtig, dass sich Software-Entwicklungsteams und Mitarbeiter in traditionellen Managementpositionen auf Richtlinien einigen und die Strategie in den Software-Entwicklungszyklus integrieren.

Entwicklungstests für DO-178B/C

In den meisten Unternehmen ist es nicht möglich, Richtlinien während des gesamten Entwicklungsprozesses manuell durchzusetzen. ALM-Tools werden häufig mit Codeanalysetools und Test-Frameworks kombiniert, um eine Ad-hoc-Lösung für Entwicklungstests zu schaffen, die einen Einblick in die Software-Entwicklungsaktivitäten bietet. In einem hart umkämpften Markt ist es jedoch von großem Vorteil, als erster mit qualitativ hochwertiger Software auf den Markt zu kommen. Ad-hoc-Entwicklungstestinfrastrukturen können zwar große Datenmengen liefern. Sie bieten jedoch selten die notwendigen Analysen, die es den Entwicklungsteams ermöglichen, zu erkennen, wo sie ihre Ressourcen einsetzen müssen, um ihre Ziele effizient zu erreichen.

Mit DTP für C- und C++-Anwendungen bietet Parasoft eine integrierte Lösung für die Automatisierung von Software-Verifizierungs- und Validierungsprozessen sowie von Software-Qualitätsaufgaben gemäß DO-178B/C, wie:

• Statische Analyse

• Statische Datenflussanalyse

• Metrik-Analyse

• Requirements Traceability

• Peer Code Review

• Unit-Tests

• Laufzeitfehler-Erkennung

• Konfigurierbare Berichte

Parasoft priorisiert mögliche Fehler anhand konfigurierbarer Schweregrade und weist sie automatisch dem verantwortlichen Entwickler zu. Direkte Links und eine Beschreibung der Fehlerbehebung werden an die IDE des Entwicklers übergeben. DTP für C und C++ ist für die Entwicklung in hostbasierten und zielbasierten Codeanalysen und Testabläufen einsetzbar.

Konformität mit DO178B/C mit Parasoft

Die folgenden Tabellen zeigen die wichtigsten Prinzipien aus DO-178B/C und wie sie mit Parasoft DTP für C/C++ zusammenpassen. Sie sind Beispiele für die Funktionen von Parasoft und erheben keinen Anspruch auf Vollständigkeit.

Aktivitäten im Programmierprozess

Hier kommt folgende Methode zum Einsatz:

• Der Quellcode sollte die grundlegenden Anforderungen erfüllen und mit der Softwarearchitektur übereinstimmen.

• Der Quellcode sollte den Standards für Softwarecode entsprechen.

• Der Quellcode sollte bis zur Designbeschreibung rückverfolgbar sein.

• Unzureichende oder fehlerhafte Eingaben, die während des Programmierprozesses entdeckt werden, sollten an den Softwareanforderungsprozess und das Softwaredesign weitergeleitet werden.

Der Parasoft Ansatz integriert Regeln, die den Best Practices der Branche entsprechen. Die Benutzer können ganze Bibliotheken von Industriestandards und benutzerdefinierten Regeln auswählen oder benutzerdefinierte Regeln auf der Grundlage von Unternehmensrichtlinien erstellen.

Parasoft DTP ermöglicht in Verbindung mit einer Reihe von Testwerkzeugen, wie Parasoft C/C++test, eine bidirektionale Traceability vom Code bis zur Anforderung. Dadurch wird sichergestellt, dass der Quellcode korrekt implementiert ist.

Überprüfungen und Analysen der Software-Architektur

Die gängige Methode ist:

• Kompatibel mit hohen Anforderungen: Die Software-Architektur soll nicht mit den hohen Anforderungen kollidieren, insbesondere mit Funktionen, die die Systemintegrität sicherstellen, wie Partitionierungsschemata.

• Konsistenz: Das Ziel ist, dass die Komponenten der Software-Architektur richtig zusammenpassen. Das wird durch Data Flow und Control Flow sichergestellt.

• Kompatibilität mit dem Zielrechner: Es soll keine Probleme, insbesondere bei der Initialisierung, im asynchronen Betrieb, bei der Synchronisation und bei Interrupts, zwischen der Software-Architektur und den Hardware-/ Software-Funktionen des Zielrechners geben.

• Verifizierbarkeit: Das Ziel ist, dass die Software-Architektur verifiziert werden kann, beispielsweise, dass es keine unbegrenzten rekursiven Algorithmen gibt.

• Konformität mit Standards: Während des Software-Designprozesses sollen die Standards eingehalten und Abweichungen von den Standards begründet werden, insbesondere Komplexitätsbeschränkungen und Design-Konstrukte, die nicht mit den Systemsicherheitszielen übereinstimmen würden.

• Trennungsintegrität: Das Ziel ist, sicherzustellen, dass Teilungsfehler verhindert oder isoliert werden.

Es ist möglich, Parasoft-Regeln so zu konfigurieren, dass alle möglichen Richtlinien durchgesetzt werden, zum Beispiel zur Software-Architektur oder basierend auf den Spezifikationen der Zielcomputer. Das Unternehmen verfügt über Tools zum Testen der Software-Entwicklung, beispielsweise zur statischen Analyse, Unit-Tests, Code-Abdeckungsanalyse, Peer-Review-Analyse und Laufzeitfehlererkennung. Regeln zur Durchsetzung von Best Practices sind bereits integriert. Man kann Bibliotheken auf Industriestandards oder einzelne Regeln auswählen oder eigene Regeln auf Unternehmensrichtlinien erstellen.

Überprüfungen und Analysen des Quellcodes

Wichtig ist es, den Quellcode zu überprüfen und zu analysieren. Er muss:

• Low-Level-Anforderungen erfüllen,

• zur Software-Architektur passen,

• verifiziert werden können,

• sich an Standards halten.

• auf die Low-Level-Anforderungen rückverfolgbar und

• genau und konsistent sein

Mit automatisch generierten Testfällen stellt Parasoft sicher, dass der Code die Low-Level-Anforderungen erfüllt. Regeln können definiert werden, um Richtlinien durchzusetzen.Das Unternehmen verfügt über Software-Entwicklungstools, um zu überprüfen, ob der Code wie erwartet funktioniert. In denTests sind Regeln integriert, die Best Practices der Industrie durchsetzen. Die Benutzer können auf Industriestandards basierende Bibliotheken oder einzelne Regeln auswählen oder benutzerdefinierte Regeln erstellen.

Die musterbasierte Datenflussanalyse überprüft Pfade, simuliert die Ausführung von Testfällen und erkennt Fehler über mehrere Units, Komponenten und Dateien hinweg. Anforderungen können mit Tasks, Code und anderen Anforderungen korreliert werden.

Testumgebung

Um die Ziele des Software-Tests zu erreichen, kann mehr als eine Testumgebung erforderlich sein. Eine hervorragende Testumgebung umfasst die Software, die auf den Zielcomputer geladen und in einer getreuen Simulation der Zielcomputerumgebung getestet wird.

In vielen Fällen kann die erforderliche Coverage und strukturelle Abdeckung nur durch eine genauere Kontrolle und Überwachung der Testeingaben und der Codeausführung erreicht werden, als das normalerweise in einer vollständig integrierten Umgebung möglich ist. Solche Tests müssen möglicherweise an einer kleinen Software-Komponente durchgeführt werden, die funktional von anderen Software-Komponenten isoliert ist.

Für Tests, die mit einem Emulator des Zielcomputers oder einem Simulator des Hostcomputers durchgeführt werden, können Zertifizierungspunkte vergeben werden. Zu den Richtlinien für die Testumgebung gehört die Vorgabe, dass ausgewählte Tests in der integrierten Zielrechnerumgebung durchzuführen sind, da einige Fehler nur in dieser Umgebung erkannt werden können.

Parasoft bietet hier umfassende Funktionen für Testumgebungen. Es kann durch Kreuzkompilierung der generierten Testsysteme und Code-Instrumentierung für eine gewünschte Ziel-Laufzeitumgebung mit vielen embedded Echtzeit-Betriebssystemen und -Architekturen verwendet werden. Eine vollständige Anpassung der Testausführungssequenz wird ebenfalls unterstützt. Zusätzlich zur Nutzung der integrierten Testautomatisierung können Anwender benutzerdefinierte Testskripte und Shell-Befehle integrieren, um das Werkzeug an ihre spezifische Build- und Testumgebung anzupassen.

Testmethoden, die auf Anforderungen basieren

Zu den Testmethoden, die auf Anforderungen basieren, zählen Anforderungs-basierende Hardware/Software-Integrationstests, der Anforderungs-basierende Software-Integrationstests und Anforderungs-basierendes Low-Level-Testen.

Zu den typischen Fehlern, die sich durch Anforderungs-basierende Hardware/Software-Integrationstests aufdecken lassen, gehören u.a. falsche Interruptbehandlung, Nichteinhaltung von Anforderungen an die Ausführungszeit, falsche Software-Reaktion auf Hardware-Transienten oder Hardware-Fehler, zum Beispiel Startsequenzen, transiente Eingangslasten und Eingangsstromtransienten, Datenbus- und andere Ressourcenkonflikte, wie Speicherzuweisung oder die Unfähigkeit des integrierten Tests, Fehler zu erkennen. Des Weiteren lassen sich Fehler in Hardware-/Software-Schnittstellen, ein fehlerhaftes Verhalten von Feedback Loops, die falsche Steuerung von Hardware zur Speicherverwaltung oder anderer Software-gesteuerter Hardware, Speicherüberlauf, Fehlfunktionen von Mechanismen zur Überprüfung der Korrektheit und Kompatibilität von vor Ort ladbarer Software sowie Verstöße gegen die Software-Partitionierung finden.

Anforderungs-basierende Software-Integrationstests decken typische Fehler wie fehlerhafte Initialisierung von Variablen und Konstanten, Fehler bei der Parameterübergabe, Datenkorruption, unzureichende End-to-End numerische Auflösung sowie die falsche Reihenfolge von Ereignissen und Operationen auf.

Wenn ein Algorithmus eine Software-Anforderung nicht erfüllt, dann lässt sich das mit Anforderungs-basierendem Low-Level-Testen feststellen, genauso wie falsche Schleifenoperationen, falsche logische Entscheidungen, falsche Reaktionen auf fehlende oder beschädigte Eingabedaten, falsche Behandlung von Ausnahmen, wie Rechenfehler oder Überschreiten von Array-Grenzen, inkorrekte Ausführungsreihenfolge oder eine unzureichende Genauigkeit, Präzision oder Leistung des Algorithmus. Auch das zuverlässige Kombinationen von Eingabebedingungen nicht korrekt verarbeitet werden, lässt sich mit dieser Testmethode feststellen.

Die grafische Benutzeroberfläche von Parasoft ermöglicht die Parametrisierung von Testfällen und Stubs für einen größeren Testumfang und eine bessere Testabdeckung. Die „Stub View" analysiert und generiert Stubs. Der Benutzer kann Stubs für Funktionen erstellen oder bestehende Stubs modifizieren.

C/C++test kann Hardware-Integration überprüfen, Tests auf Ziel- und Testumgebung ausführen, Komponententests anpassen und Regressionstests durchführen. Funktionen zur Erkennung von Laufzeitfehlern decken Integrations- und andere Anwendungsfehler auf.

Das Modul für die erweiterte prozedurübergreifende statische Analyse simuliert mögliche Ausführungspfade und stellt Laufzeitfehler fest. Zu den erkannten Fehlern gehören:

• Verwendung von nicht initialisiertem oder ungültigem Speicher

• Dereferenzierung von Null-Zeigern

• Array- und Pufferüberläufe

• Division durch Null

• Speicher- und Ressourcenlecks

• Toter Code

Parasoft C/C++test ermöglicht die Anpassung der Regeln für die statische Analyse, um Code zu analysieren. Dateien und Codezeilen lassen sich nach verschiedenen Kriterien testen. Software-Entwickler können den Umfang der Komponententests anpassen und Regressionstests durchführen. Es gibt Funktionen zur Erkennung von Laufzeitfehlern und anderen Fehlern während der Ausführung der Anwendung.

Bei Low-Level-Tests werden einzelne Funktionen mit vorgegebenen Eingaben getestet. Benutzer können Unit-Testfälle automatisch für Funktionen generieren. Tests können gespeichert und als Regressionstests ausgeführt werden, um die korrekte Integration der Software sicherzustellen.

Strukturelle Coverage Analyse

Bei der strukturellen Coverage-Analyse wird festgestellt, welche Code-Strukturen durch die Anforderungs-basierenden Tests nicht abgedeckt wurden. Möglicherweise haben die Anforderungs-basierenden Testfälle nicht alle Code-Strukturen abgedeckt, daher erfolgen eine strukturelle Coverage Analyse und zusätzliche Überprüfungen.

Hier sind einige Hinweise:

• Die Analyse sollte den Grad der strukturellen Abdeckung bestätigen.

• Die strukturelle Coverage Analyse kann am Quellcode durchgeführt werden, es sei denn, der Software-Level ist A und der Compiler erzeugt Objektcode, der sich nicht direkt auf Quellcode-Anweisungen zurückführen lässt. In diesem Fall sollte eine zusätzliche Verifizierung am Objektcode stattfinden. Ein Beispiel für Objektcode, der nicht direkt auf den Quellcode zurückgeführt werden kann, ist ein vom Compiler erzeugter Array-Bound-Check im Objektcode.

• Die Analyse sollte die Datenverknüpfung und die Kontrollverknüpfung zwischen den Codekomponenten bestätigen.

Ein Analyse-Tool für die Testabdeckung mit mehreren Metriken hilft den Anwendern, die Effizienz und Vollständigkeit von Tests zu messen und die Einhaltung von Test- und Validierungsanforderungen nachzuweisen. Durch die Rückverfolgung von Abdeckungselementen zu den entsprechenden Testfällen können Anwender Testergebnisse analysieren und die Testfälle effizienter erweitern, um eine bessere Abdeckung zu erreichen.

Alle Testergebnisse können für Konformitätszwecke exportiert werden. Das Object Coverage Modul (auch Assembler Coverage genannt) hilft dem Anwender festzustellen, ob der Compiler Objektcode erzeugt hat, der nicht zum Quellcode zurückverfolgt werden kann, und stellt sicher, dass dieser während der Testprozeduren überprüft wurde.

Auflösung der strukturellen Abdeckungsanalyse

Die strukturelle Abdeckungsanalyse kann Code-Strukturen aufdecken, die während des Testens nicht ausgeführt wurden. Um diese aufzulösen, sind zusätzliche Software-Verifizierungsprozesse erforderlich. Die nicht ausgeführten Code-Strukturen können folgende Ursachen haben:

• Mängel in den anforderungsbasierten Testfällen oder Testprozeduren. Die Testfälle sollten ergänzt oder die Testprodeduren geändert werden, um die fehlende Abdeckung zu gewährleisten. Gegebenenfalls müssen die Methoden zur Durchführung der anforderungsbasierten Überdeckungsanalyse überprüft werden.

• Lücken in den Softwareanforderungen. Die Softwareanforderungen sollten geändert, zusätzliche Testfälle entwickelt und Testverfahren durchgeführt werden.

• Toter Code. Der Code sollte entfernt und eine Analyse durchgeführt werden, um die Auswirkungen und die Notwendigkeit einer erneuten Verifizierung zu bewerten.

• Deaktivierter Code. Für inaktivierten Code, der in keiner in einem Flugzeug oder Triebwerk verwendeten Konfiguration ausgeführt werden kann, sollte durch eine Kombination aus Analyse und Tests nachgewiesen werden, dass die Mittel, die eine unbeabsichtigte Ausführung dieses Codes ermöglichen, verhindert, isoliert oder entfernt wurden. Für deaktivierten Code, der nur in bestimmten Konfigurationen der Ziel-Computerumgebung ausgeführt werden kann, sollten die Betriebskonfiguration, die für die normale Ausführung dieses Codes erforderlich ist, festgelegt und zusätzliche Testfälle und Testverfahren entwickelt werden, um die erforderlichen Abdeckungsziele zu erreichen.

Parasoft analysiert den Code automatisch und erzeugt Unit-Tests mit hoher Testabdeckung. Verbesserungen der Testabdeckung sind möglich:

• Einfache Testfall-Erweiterungen.

• Ein flexibler Stub.

• Datengetriebene Tests mit unterschiedlichen Datensätzen.

Ein Datenquellen-Assistent hilft bei der Parametrisierung von Testfällen und Stubs und ermöglicht so einen größeren Testumfang und eine höhere Testabdeckung mit minimalem Aufwand. Die Stub-Ansicht analysiert und generiert Stubs, indem sie alle im Code verwendeten Funktionen anzeigt.

Das Modul für die prozedurübergreifende statische Analyse simuliert mögliche Ausführungspfade der Anwendung und stellt fest, ob diese Pfade bestimmte Kategorien von Laufzeitfehlern auslösen können. Zu den erkannten Fehlern zählen:

• Verwendung von nicht initialisiertem oder ungültigem Speicher

• Dereferenzierung von Null-Zeigern

• Array- und Pufferüberläufe

• Division durch Null

• Speicher- und Ressourcenlecks

• Toter Code

Tool-Qualifizierung

Die Qualifizierung eines Tools ist erforderlich, wenn Prozesse dieses Dokuments durch den Einsatz eines Software-Tools eliminiert, reduziert oder automatisiert werden, ohne dass dessen Output gemäß Abschnitt 6 überprüft wird. Der Einsatz von Software-Werkzeugen zur Automatisierung von Aktivitäten der Software-Life-Cycle-Prozesse kann zur Erreichung der Systemsicherheitsziele beitragen, sofern sie in der Lage sind, die Einhaltung von Software-Entwicklungsstandards durchzusetzen und automatische Prüfungen zu verwenden.

Nur deterministische Tools, d.h. Tools, die bei gleichen Eingabedaten in der gleichen Umgebung die gleiche Ausgabe liefern, können qualifiziert werden. Der Tool-Qualifizierungsprozess kann entweder auf ein einzelnes Tool oder auf eine Tool-Suite angewendet werden.

Die Ziele des Verifizierungsprozesses für Software-Entwicklungstools sind in Abschnitt 12.2.1 beschrieben (weitere Informationen stehen im RTCA-Dokument DO-330). Man darf ein Tool nur dann für die Verwendung in einem bestimmten System qualifizieren, wenn die Absicht, dieses zu verwenden, im Plan für die Softwareaspekte der Zertifizierung angeführt ist. Die Verwendung des Tools für andere Systeme kann eine weitere Qualifizierung erfordern.

Um die Qualitätstools durch Parasoft zu qualifizieren, werden statische Analysen, Flow-Analysen, Unit-Tests und alle anderen Testaktivitäten, die im Entwicklungsprozess zum Einsatz kommen, an einer Reihe von Testfällen mit bekannten und klar definierten Ergebnissen, die Parasoft bereitstellt, durchgeführt. Parasoft meldet Fehler einheitlich, genau und objektiv, wodurch die korrekte Funktion des Tools sichergestellt wird. (se)

Bauelemente

Mouser, Analog Devices und Amphenol untersuchen Zukunft der Luftfahrt

Safety und Security

Entwicklung sicherheitskritischer Software: AbsInt und ISIT schließen Vertriebsvereinbarung

(ID:50431838)