Definition
Ergänzung zu DO-178C, die objektorientierte Programmiertechniken (Vererbung, Polymorphismus, dynamische Bindung, Templates) in sicherheitskritischer Avionik-Software adressiert. Definiert spezifische Anforderungen zur Beherrschbarkeit komplexer OO-Konstrukte. Ohne DO-332-Konformität sind moderne C++/Java-basierte Avioniksysteme nicht zertifizierbar.
In der Praxis
Objektorientierung in sicherheitskritischer Software ist kein Selbstzweck-Verbot, aber sie verschiebt das Risiko: Vererbung, Polymorphismus und dynamische Bindung machen aus statisch lesbarem Code ein Laufzeitverhalten, das sich dem klassischen Review entzieht. DO-332 existiert, weil die Frage „welcher Code läuft hier eigentlich?" bei dynamischem Dispatch nicht mehr aus dem Quelltext allein beantwortbar ist. In der Praxis sehe ich drei Fehler. Erstens wird C++ ohne verbindliche Teilmenge verwendet — Templates, Mehrfachvererbung und Ausnahmen nach Belieben, bis die Verifikation kollabiert. Zweitens wird die Abdeckungsanalyse auf Quelltextebene als ausreichend angesehen, obwohl das OO-Verhalten erst auf Objektebene sichtbar wird. Drittens wird DO-332 erst im Zulassungsreview entdeckt — dann ist die Architektur längst gegossen. Wer OO in der Avionik einsetzt, braucht einen dokumentierten Sprachumfang, statische Analyse und eine Verifikationsstrategie für die dynamischen Konstrukte — und das ab dem ersten Design-Review.
Häufige Fragen zu DO-332
Worin unterscheiden sich DO-331, DO-332 und DO-333?
Alle drei sind Supplements zur DO-178C — sie ergänzen deren Ziele für eine bestimmte Technologie, ersetzen die Grundnorm aber nie. DO-331 betrifft die modellbasierte Entwicklung und Verifikation: Modelle als Spezifikation, Modellabdeckung, Codegenerierung. DO-332 betrifft objektorientierte Technologien und verwandte Techniken: Es stellt Zusatzanforderungen an die Beherrschbarkeit von Vererbung, Polymorphismus und dynamischer Bindung. DO-333 betrifft formale Methoden: Es regelt, wann mathematische Beweise klassische Verifikationstätigkeiten ersetzen oder ergänzen dürfen. Die Supplements sind kombinierbar — ein Projekt kann gleichzeitig modellbasiert und objektorientiert arbeiten. Im Zulassungsplan deklarieren Sie, welche Supplements zur Anwendung kommen und wie ihre Ziele erfüllt werden; genau das prüft die Behörde.
Ist C++ in zertifizierbarer Avionik-Software überhaupt zulässig?
Ja — aber nur unter den Zusatzbedingungen von DO-332. Der Supplement zur DO-178C steht objektorientierten Techniken nicht ablehnend gegenüber, er verlangt deren Beherrschung: Die dynamischen Eigenschaften — etwa welche Methode bei polymorphen Aufrufen tatsächlich ausgeführt wird — müssen analysierbar und verifiziert sein, und die Typkonsistenz muss über die Vererbungshierarchien hinweg nachgewiesen werden. Praktisch heißt das: Sie definieren eine verbindliche Sprach-Teilmenge und einen Kodierstandard, setzen statische Analyse zur Durchsetzung ein und dokumentieren, wie Sie dynamische Bindungspunkte identifizieren und verifizieren. Ohne diese Disziplin ist ein modernes C++-Programm in einem zertifizierungspflichtigen System nicht darstellbar. Die Entscheidung für OO ist damit eine Verifikationsentscheidung, keine Stilfrage (RTCA DO-332, Supplement zu DO-178C).
Wie machen wir ein C++-Projekt für die Zulassung beherrschbar?
Beginnen Sie mit der Sprachdisziplin: Legen Sie eine dokumentierte C++-Teilmenge fest — in der Praxis orientieren sich Teams an etablierten Kodierstandards für sicherheitskritische Systeme — und setzen Sie sie mit statischer Analyse automatisiert durch. Zweitens: Inventarisieren Sie die OO-Konstrukte. Jede Stelle mit dynamischer Bindung ist ein Verifikationspunkt; dokumentieren Sie, welche konkreten Typen zur Laufzeit auftreten können und dass alle abgedeckt sind. Drittens: Verankern Sie die OO-Strategie in den Zulassungsdokumenten — der Plan muss zeigen, wie die DO-332-Zusatzziele erfüllt werden, bevor die Behörde fragt. Viertens: Schulen Sie das Team; OO-Fehler in sicherheitskritischer Software entstehen selten aus Böswilligkeit, sondern aus Gewohnheiten aus der Consumer-Entwicklung. Und fünftens: Führen Sie die Abdeckungsanalyse auf der Ebene durch, auf der das Verhalten entsteht — notfalls bis zur Objektcode-Ebene, je nach Design Assurance Level.