Definition
SAE-Richtlinie für den systemtechnischen Entwicklungsprozess von Flugzeugen und ihren Systemen. Definiert die Top-Down-Prozesskette von Aircraft-Level-Anforderungen über System-Anforderungen bis zu Subsystem- und Komponentenebene. Verbindet Safety Assessment (ARP 4761), Software (DO-178C) und Hardware (DO-254) zu einem konsistenten Entwicklungsprozess. Pflichtgrundlage für jede zivile Luftfahrtzulassung.
In der Praxis
ARP 4754A scheitert in der Praxis fast nie am Prozessverständnis, sondern an der Anforderungsverfolgung: Die Kette von den Flugzeug-Level-Anforderungen über System- und Subsystem-Ebene bis zur Komponente reißt — und in der Zulassung kann dann niemand mehr zeigen, welche Systemanforderung welches Risiko auf Flugzeugebene abdeckt. Das ist kein Dokumentationsproblem, sondern ein Architekturproblem: Anforderungen werden in Excel-Inseln gepflegt, Änderungen laufen am Konfigurationsmanagement vorbei, und die Zuordnung der Development Assurance Levels zur Architektur ist nicht nachvollziehbar. Zweiter Stolperstein: Die Verbindung zur Safety Assessment nach ARP 4761 wird als lästige Querschnittsaufgabe behandelt statt als Treiber des Entwicklungsprozesses — dabei liefert sie die DALs, ohne die jede Entwicklungsstrenge willkürlich ist. Mein Rat: Investieren Sie in ein durchgängiges Anforderungsmanagement mit bidirektionaler Traceability und führen Sie die Design Reviews je Ebene diszipliniert durch. Die Rückverfolgbarkeit ist in der Zulassung die Währung, mit der Sie bezahlen — alles andere ist Beiwerk.
Häufige Fragen zu ARP 4754A
Was ist der Unterschied zwischen ARP 4754A und ARP 4761?
Die beiden Richtlinien sind Zwillinge mit klarer Rollenteilung. ARP 4754A beschreibt den Entwicklungsprozess für Flugzeuge und Systeme: wie Anforderungen von der Flugzeugebene hierarchisch auf Systeme und Komponenten heruntergebrochen, allokiert und verifiziert werden. ARP 4761 beschreibt die Safety-Assessment-Methodik: Functional Hazard Assessment, vorläufige und finale System-Sicherheitsbewertung — also die Analysen, aus denen die Kritikalität der Funktionen hervorgeht. Die 4761 liefert damit die Eingangsgrößen für die 4754A: Ohne Safety Assessment keine belastbare DAL-Zuordnung, ohne DAL keine festgelegte Entwicklungsstrenge. In der Praxis laufen beide Prozesse iterativ verzahnt, nicht nacheinander. Wer nur eine der beiden Richtlinien ernst nimmt, hat das Konzept der zivilen Luftfahrtentwicklung nicht verstanden.
Ist ARP 4754A für die Entwicklung ziviler Luftfahrtsysteme verbindlich vorgeschrieben?
ARP 4754A ist eine SAE-Richtlinie, kein Gesetz — aber sie ist das von EASA und FAA anerkannte Mittel, um den systemtechnischen Entwicklungsprozess für hochintegrierte und komplexe Flugzeugsysteme darzustellen. Im Zulassungskontext von EASA Part 21 wird die Richtlinie über die Zulassungsbasis und die Zertifizierungsvereinbarung faktisch zur Verpflichtung: Wer einen anderen Entwicklungsprozess vorschlägt, muss dessen Gleichwertigkeit gegenüber der Behörde begründen. Für Zulieferer kommt die Anforderung zusätzlich über den Vertrag: Die Flugzeughersteller fordern die Anwendung entlang der Lieferkette ein, weil sie die Systemintegration und die Nachweise an der Spitze sonst nicht zusammenbekommen. Praktisch gilt deshalb: Ohne ARP-4754A-konformen Prozess keine Rolle in der zivilen Großluftfahrt-Entwicklung.
Wie bekommen wir die durchgängige Anforderungsverfolgung vom Flugzeug bis zur Komponente hin?
Drei Dinge müssen zusammenkommen. Erstens ein Anforderungsmanagement-Werkzeug, das bidirektionale Verknüpfungen beherrscht — jede Systemanforderung zeigt nach oben ihre Herleitung und nach unten ihre Allokation; Excel scheidet bei diesem Umfang aus. Zweitens eine disziplinierte Review-Kette: Auf jeder Ebene wird geprüft, ob die abgeleiteten Anforderungen die übergeordneten vollständig und korrekt abdecken — diese Reviews sind die eigentliche Qualitätssicherung der Zerlegung. Drittens ein Konfigurationsmanagement, das Anforderungsänderungen über alle Ebenen propagiert und bewertet; eine Änderung auf Flugzeugebene muss sichtbar machen, welche Systemanforderungen betroffen sind. Ergänzend empfiehlt sich die Verknüpfung mit den Verifikationsnachweisen, damit am Ende jede Anforderung nicht nur allokiert, sondern auch verifiziert ist. Genau diese Kette ist es, die Behörden und Kunden in Audits sehen wollen.