Suchen

Softwareentwicklung

DO-178C – verbesserte Zertifizierung für preisgünstige Systeme in der Luftfahrt

Seite: 2/2

Firmen zum Thema

Die Neuauflage: DO-178C

DO-178C verfügt über die Strenge der DO-178B. Doch erstellt er, wo nötig, ein Update, um für den Bedarf der Entwickler einzuräumen, zum Anfang des Prozesses zu testen oder zu verifizieren. Aber das Wichtigste des DO-178C ist die Hinzufügung drei technologisch-spezifischer Abschnitte innerhalb des Kerndokuments, das vom DO-78B geerbt wurde (siehe Abb. 2):

  • Formale Methoden
  • Modellbasierte Entwicklung
  • Objektorientierte und verwandte Technologien

Struktur des Standards DO-178C: Das Kerndokument wird durch Ergänzungen zu formalen Methoden, modellbasierter Entwicklung, objektorientierte Technologien und Tools komplettiert.
Struktur des Standards DO-178C: Das Kerndokument wird durch Ergänzungen zu formalen Methoden, modellbasierter Entwicklung, objektorientierte Technologien und Tools komplettiert.
(Quelle: LDRA)

Jeder Abschnitt ergänzt das technologie-blinde Kerndokument. Eine Ergänzung definiert die Stufen (Aktivitäten) mit Bezug auf den Einsatz von Technologie und alle einmaligen "Objektive" oder Kriterien für die Annahme der produzierten Software.

Mit primär von Tools Dritter ermöglichten zwei oder drei Technologien, wird eine vierte Ergänzung zu „Tools“ besonders wichtig, da sie mit Tool-Qualifizierung assoziierte Aspekte anspricht.

Formale Methoden

Die Ergänzung „Formale Methoden“ räumt den Gebrauch mathematischer Beweise als eine zusätzliche Methode der Verifikation ein. Um dies noch zu erweitern, wurde der Abschnitt 6 des DO-178C mitd em Titel „Softwareverifikationsprozess“ geschrieben. Darin wird der Begriff „Verifizieren“ anstelle von „Testen“ benutzt, der die funktionale Verifikation von Software gestattet, um ein anderes Mittel anstelle von Tests oder in Ergänzung zum Testen einzusetzen.

Obgleich Theoretiker derzeit die mathematische Verifikation für ausreichend halten, befürwortet der DO-178C weiterhin gezielte Tests, um sicherzustellen, dass der Code korrekt dem Ziel angepasst ist und um False Positives in der formalen Methode zu vermeiden. Im Wesentlichen unterscheidet sich der DO-178C vom Vorgänger durch Festlegen mathematischer Beweise als ein anderes brauchbares Mittel der Verifikation.

Modellbasierte Entwicklung

Modellbasierte Entwicklung (MBE) wurde als Mittel der Bewältigung des enormen Wachstums von Software befürwortet. Die Forschung weist darauf hin, dass Prototyping von Softwareanforderungen in frühen Stadien mit einem ausführbaren Modell effektiv „Fehler“ auf Anforderungs- und Designstufen ausschaltet: Eine riesige Ersparnis, wenn man bedenkt, dass es neunhundert mal teuerer ist, einen Fehler, der erst nach der Zertifizierung erkannt wird, zu beheben. Mit MBE ist es auch möglich, automatisch Quellecode vom ausführbaren Modell zu erzeugen.

Der Schlüssel zur Softwareverifikation in DO-178B und DO-178C, ist die Rückverfolgbarkeit von Anforderungen bis zu ihrem Design und ihrer Implementation. MBE führt hierzu drei wichtige Aufgaben vor Augen:

  • Wie kann die Rückverfolgbarkeit von auf hoher Ebene geschriebenen Anforderungen bis zu modellbasierten Anforderungen eingerichtet und beibehalten werden?
  • Wie können Anforderungen auf hoher Ebene zu ihrem automatisch generierten Code zurückverfolgt werden?
  • Wie können die Anforderungen auf hoher Stufe zu den manuell geschriebenen Codes zurückverfolgt werden, die für die Funktion des automatisch generierten Codes in einem Zielsystem erforderlich sind?

DO-178C spricht die Herausforderungen bei der Implementation dieser Technologie an. Die Einrichtung und Beibehaltung der Rückverfolgung von Anforderungen auf hoher Ebene zu modellbasierten Anforderungen wird von der DO-178C mit Leichtigkeit erfüllt. Sie erkennt ganz einfach die Modelle als die Anforderungen an, und somit wird die Rückverfolgung offensichtlich.

Die Herausforderungen automatisch generierten und manuell eingegebenen Codes unter Einsatz von MBE sind jedoch erheblich. Doch MBE-Tools können Codes eingeben, die sich nur im Zusammenhang mit der Implementation des Modells rationalisieren lassen, nicht mit den funktionalen Anforderungen. Die Antwort auf diese Fragen hängt von den Charakteristiken der Modellierungssprache und den Mechanismen ab, die von dem den Code automatisch generierenden MBE-Tool unterstützt werden.

Da DO-178C das Direct Mapping zwischen Anforderungen und Quellcode erfordert, muss nicht zugeordneter Code vom Applikanten ausgewiesen werden, möglicherweise durch Definieren abgeleiteter Anforderungen, um den nicht zugeordneten Code zu rechtfertigen, mit dem Resultat zweier verschiedener Rückverfolgungsmethoden.

Objektorientierung und verwandte Technologien

Die Ergänzung des DO-178C zum Thema „Objektorientierte und verwandte Technologien“ (OOT) konzentriert sich auf die aktuellen OO-Sprachen, wie C++, Java und Ada 2005. Im Besonderen spricht sie das Thema der Subtyp-Verifikation an, die zuerst im FAA-Handbuch „Objektorientierte Technologie in der Aviation“ (OOTiA) 2004 erwähnt wurde.

Die Untertypisierung ist die Fähigkeit, neue Typen oder Subtypen in einer OO-Sprache zu erzeugen. Obgleich dieses Feature sehr leistungsstark ist, führt es das Problem der Beibehaltung von Typenkonsistenz und Subtyp-Verifikation vor Augen. Die OOTiA-Empfehlung war, eine gründliche Flattened Class-Methode anzuwenden, die den OOT-Verifikationsaufwand sprunghaft erhöht.

DO-178C empfiehlt einen viel praktischeren Vorgang: Design-Verifikationstests (DVT), die auf Klassenebene vorgenommen werden, beweisen, dass alle Member-Funktionen den Klassenvertrag mit Hinsicht auf Vor- und Nachbedingungen sowie Objektvarianten des Klassenzustands erfüllen. Als eine Alternative zu DVT können Entwickler formale Methoden im Einklang mit der Ergänzung „Formale Methoden“ benutzen.

Zusätzlich zu den neuen Ergänzungen verstärkt DO-178C den Bedarf für traditionelle Tools, um mit Anforderungen, Rückverfolgung, Einhaltung der Codiernormen, Abdeckungsanalyse, sowie der Daten- und Steuerungskopplung umgehen zu können.

Schlussfolgerung

Die Komplexität moderner Avioniksysteme resultiert nicht nur aus ihrem sicherheitskritischen Charakter, sondern auch von den vielen Optionskombinationen, die von Avionikanbietern vorgestellt werden. In seinem Artikel: „Bridging The Embedded Software Development Gap", fand Roy C. Wildeman von Forrester nicht nur, dass diese „Systeme aller Systeme“ zusätzliche Software und längere Lieferzeiten erfordern, sondern dass diese Art softwareintensiver Projekte derzeitig das Budget und den Zeitplan zu verdoppeln scheinen, während sie nur sechzig Prozent der erwarteten Funktionalität erbringen.

Wird DO178C den Avionik-Anbietern Tools und Richtlinien zur Verfügung stellen, die eine preisgünstigere Zertifizierung der immer komplizierter werdenden modernen Avionik-Systeme erreichen können? Zur Zeit der Veröffentlichung dieses Artikels lautet die Antwort kurz und bündig Ja – indem die notwendigen Richtlinien erstellt werden, um die Annahme moderner Entwicklungs- und Verifikationstechnologien und -methoden zu unterstützen.

//FG

* * Bill St. Clair ... ist Direktor der US Operations für LDRA Technology in San Bruno, Kalifornien, und verfügt über mehr als 25 Jahre Erfahrung in Entwicklung und Management von Embedded-Software. .

(ID:33978220)