Blog

5 Fallen, in die ein Software-Ingenieur in einem DO-178C-Projekt nicht tappen sollte

5 verbreitete Fallen können Ihrem DO-178C-Projekt ernsthaft schaden, wenn sie zu spät erkannt werden

Die Vorschrift DO-178C «Software Considerations in Airborne Systems and Equipment Certification» (deutsch etwa: Richtlinien zur Zertifizierung von Avionik-Software), ist ein von der RTCA (Radio Technical Commission for Aeronautics) entwickelter Standard zur Softwareentwicklung im sicherheitskritischen Bereich der Luft- und Raumfahrtindustrie. Das Dokument enthält jedoch kein praktisches Rezept, wie die Problemfragen in einem bestimmten Projekt gelöst werden können. Jedes einzelne Projktteam hat seine eigene Art und Weise, die Ziele und Einschränkungen der DO-178C zu interpretieren. Nachfolgend sind fünf Fälle aufgeführt, die nach meiner Erfahrung die meisten Diskussionen und Missverständnisse verursacht haben. Ich bezeichne diese Aspekte als „Falle“, weil ein falscher Weg zu ihrer Umsetzung spürbare negative Auswirkungen auf Ihr Projekt haben wird.

№ 1. Falle des Wasserfallmodells im Projekt-Lebenszyklus

Die Auffassung, dass die DO-178C einen schwergewichtigen, wasserfallartigen Lebenszyklus vorschreibt, ist falsch. Jede Methode wäre angemessen, sogar eine agile, wenn sie den Übergangskriterien folgt und die Zielerreichung nicht behindert. Wählen Sie aus, was am besten zu Ihrem Projekt und Ihrer Unternehmenskultur passt, und ergänzen Sie es um die erforderlichen Maßnahmen zur Erreichung der Konformität. Sie sollten nicht auf eine Aktivität verzichten, die Ihrem Produkt einen Mehrwert verleiht, nur weil ihre Normkonformität in Frage steht. Berichten Sie einfach nicht über solche Errungenschaften. Im Gegensatz dazu sollten Sie sich nicht scheuen, zusätzliche Aufgaben hinzuzufügen, um die Einhaltung der formalen Anforderungen zu gewährleisten. Oft wird durch eine Woche für bestimmte formale Aufgaben ein Monat ineffizienter und nutzloser Arbeit an künstlichen Stufen im Lebenszyklus vermieden.

№ 2. Falle der Vernachlässigung der Robustheit

Die Beständigkeit wird oft in den letzten Verifikationsstufen in Erinnerung gerufen. Es geschieht ungefähr so: "Oh, wir müssten ja noch einige Beständigkeitstests hinzufügen, um das Audit der Einschaltungsphasen (stage of involvement, SOI) zu bestehen". Die so entwickelte Software ist nichts anderes als ein Koloss auf tönernen Füßen. Die Robustheit sollte von Anfang an bewertet und während des gesamten Projektlebenszyklus in greifbare Ergebnisse umgewandelt werden. Es ist daher wichtig, abnormale Situationen und Maßnahmen zu deren Eindämmung in die Anforderungen einzubeziehen, die entsprechenden Funktionen in das Projekt zu integrieren und nicht zuzulassen, dass ein unauffindbarer defensiver Code in Ihren Implementierungsprozess einfließt. Wenn Sie alles richtig machen kann die Robustheitsprüfung nur eines der Elemente der normgerechten anforderungsbasierten Prüfung sein.

№ 3. Falle mit strukturellen Tests

DO-178C schreibt anforderungsbasierte Tests vor. In Gesprächen zwischen Ingenieuren kommt jedoch häufig ein Ausdruck wie "MC/DC-Tests“ vor. Also, vergessen Sie nun diese Wendung. Tests sollten die Software auf ihre Anforderungskonformität prüfen. Die Modified Condition and Alternative Coverage Method (MC/DC) ist nur ein Maß, das die allgemeine gegenseitige Konsistenz und Vollständigkeit zwischen Anforderungen, Code und Tests aufzeigt. Eine Deckungslücke bedeutet nicht unbedingt, dass das Testergebnis mangelhaft ist. Die Anforderungen mögen oft unangemessen sein und es könnte an Details mangeln, oder das Problem kann durch einen unauffindbaren Zusatzcode verursacht werden. Der schlimmste Fehler, den Sie machen können, ist die Einfügung eines synthetischen Testbeispiels, nur um bestimmte Kombinationen von Programmvariablen zu üben.

№ 4. Falle der übereifrigen Toolsqualifikationstests

DO-178C legt ein zusätzliches Augenmerk auf die Qualifikation der Softwaretools. Dieser Aspekt wird durch die Sonderergänzung zum DO-330-Standard geregelt. Die Qualifizierung jedes einzelnen Software-Tools ist jedoch nicht erforderlich. Zudem ist die Qualifizierung eines Software-Tools ein kostspieliger Prozess, und eine vernünftig gewählte Qualifizierungsstrategie wird helfen, Ihre Bemühungen zu optimieren. Daher ist es wichtig, die Kriterien für die Qualifizierung von Werkzeugen zu verstehen und die Kosten für jede Qualifizierungsstufe einzuschätzen. Manchmal ist es besser, zusätzliche Schritte, z.B. Verifizierung oder Analyse, einzuführen, anstatt das Werkzeug zu qualifizieren. Ein weiterer Fehler ist das übermäßige Vertrauen in das vom Werkzeuganbieter gelieferte Unterstützungspaket zur Werkzeugqualifizierung. Nur selten kann ein solches Paket in seinem Urzustand einen Nachweis für eine erfolgreiche Qualifikation darstellen. Anpassung an die Projektumgebung, Qualifikationstestläufe und Ergebnisanalyse können erhebliche Zeit in Anspruch nehmen. Dieser Arbeitsaufwand sollte bei der Entwicklung einer Qualifizierungsstrategie für Softwaretools in Betracht gezogen werden.

№ 5. Falle bei rücksichtslosem Einsatz von externen Komponenten

Die Einführung einer von einem Drittanbieter entwickelten Komponente oder einer Open-Source-Komponente in Ihre eigene Software scheint oft eine verlockende Idee zu sein. Jeder einzelne Teil des Codes muss jedoch mit der DO-178-Norm konform sein. Das bedeutet zum Beispiel, dass Sie die Bibliothek nicht ohne zusätzliche Maßnahmen zur Bestätigung ihrer Konformität mit dem Projekt linken können. Versicherungen, dass "die Programmierer-Community diese Bibliothek schon seit langer Zeit nutzt", sind kein starkes Argument für eine förmliche Genehmigung. Sie benötigen einen soliden Plan zur Anpassung solcher Komponenten an Ihr Projekt. Sie können das Supportpaket für die Toll-Zertifizierung verwenden oder einen Reengineering-Zyklus durchlaufen, um Daten zu den Anforderungen der Codebibliothek zu sammeln und die erforderliche Verifizierung durchzuführen. Berücksichtigen Sie diesen zusätzlichen Aufwand, wenn Sie über eine externe Komponente nachdenken. Manchmal ist die Entwicklung einer eigenen dedizierten Bibliothek eine effizientere Lösung als die Nachbearbeitung einer Standardkomponente von einem Drittanbieter.

Die obige Liste ist nicht abschließend. Es gibt viele weitere Fallen in Technologie, Design und Prozess, in die ein Unternehmen tappen kann. Der Unterschied ist nur, dass diese fünf Fehler Ihnen besonders viel kosten, wenn sie in späten Projektphasen erkannt werden. Mein Rat ist, diese Aspekte von Anfang an im Auge zu behalten und nicht zu vergessen, den von Ihnen gewählten Ansatz mit dem Designierten Beauftragten für Technik (Designated Engineering Representative, DER) zu besprechen, der die Einhaltung der Vorschriften überwacht.