Definition
SAE-Richtlinie für die Safety-Assessment-Methodik in der zivilen Luftfahrt. Definiert drei aufeinander aufbauende Analysen: Functional Hazard Assessment (FHA, Funktionen-Sicherheit), Preliminary System Safety Assessment (PSSA, vorläufige Bewertung) und System Safety Assessment (SSA, finale Bewertung). Liefert die Risiko-Klassifikation, die ARP 4754A für die DAL-Zuordnung benötigt.
In der Praxis
Der häufigste Fehler im Safety-Prozess ist die Verwechslung der drei Analysestufen: FHA, PSSA und SSA werden durcheinandergeworfen — oder die PSSA wird komplett übersprungen, weil „wir ja am Ende die SSA machen". Dann fehlt genau der Schritt, in dem die Architektur gegen die Sicherheitsanforderungen geprüft und die DALs hergeleitet werden, und die gesamte Entwicklungsstrenge steht auf Sand. Zweiter Dauerbrenner: Die Analysen laufen als nachträgliche Dokumentation statt als Entwicklungsbegleitung — eine FHA, die nach dem Design entsteht, findet keine Gefährdungen mehr, sondern rechtfertigt nur noch. Drittens wird die Methodenwahl unterschätzt: Fehlerbaumanalyse, FMEA und Zonenanalysen haben unterschiedliche Stärken, und die ARP 4761 erwartet ihre situationsgerechte Kombination, nicht das eine Lieblingswerkzeug. Mein Rat: Binden Sie das Safety-Team ab der Konzeptphase ein und halten Sie die Analysen als lebende Dokumente — jede Architekturänderung gehört gegen die PSSA geprüft. Wer Safety als Parallelprozess führt statt als Feigenblatt, hat in der Zulassung die leichtesten Gespräche.
Häufige Fragen zu ARP 4761
Was unterscheidet FHA, PSSA und SSA — und brauchen wir wirklich alle drei?
Ja, die drei Analysen bauen aufeinander auf und beantworten unterschiedliche Fragen. Die Functional Hazard Assessment betrachtet die Funktionen des Flugzeugs oder Systems und klassifiziert die Auswirkungen ihres Versagens — noch ohne jede Architektur; sie legt die Sicherheitsziele fest. Die Preliminary System Safety Assessment prüft dann die geplante Systemarchitektur: Kann diese Architektur die Sicherheitsziele überhaupt erreichen, und welche Anforderungen — einschließlich der DAL-Zuordnung für Software und Hardware — ergeben sich daraus für die untergeordneten Elemente? Die System Safety Assessment schließlich ist der finale Nachweis an der realisierten Umsetzung: Zeigt die gebaute Lösung, dass die Sicherheitsanforderungen erfüllt sind? Wer die PSSA überspringt, entwickelt ohne geprüfte Architekturvorgaben — und merkt das erst in der SSA, wenn Änderungen am teuersten sind.
Woher kommt eigentlich die DAL-Zuordnung für unsere Software — wer legt die fest?
Die DAL-Zuordnung ist ein Ergebnis des Safety-Assessment-Prozesses, keine Entscheidung des Software-Teams. Aus der Functional Hazard Assessment ergibt sich die Klassifikation der Ausfallbedingungen — katastrophal, gefährlich, groß und so weiter — und aus der Systemarchitektur-Betrachtung der PSSA folgt, welches Element welchen Beitrag zur Beherrschung dieser Ausfallbedingungen leistet. Daraus wird der Development Assurance Level für Software und komplexe Hardware abgeleitet. Die quantitative Logik dahinter kennen Sie aus AC 25.1309-1: Katastrophale Ausfallbedingungen müssen als äußerst unwahrscheinlich gelten, das heißt kleiner als 10 hoch minus 9 pro Flugstunde. Wichtig: Der DAL wird niemals aus Aufwand oder Budget abgeleitet — eine solche Begründung ist im Zulassungsgespräch sofort entlarvt.
Welche Analysemethoden setzen wir im Safety-Prozess sinnvoll ein?
Die ARP 4761 nennt einen Werkzeugkasten, aus dem Sie je nach Fragestellung wählen. Die Fehlerbaumanalyse eignet sich, um deduktiv von einer unerwünschten Ausfallbedingung auf die beitragenden Ursachenkombinationen zu schließen — sie ist das Standardwerkzeug, um Redundanzen und Unabhängigkeiten zu bewerten. Die FMEA arbeitet induktiv vom Einzelteilausfall zur Systemwirkung und deckt auf, welche Einzelfehler überhaupt kritisch werden können; sie ergänzt den Fehlerbaum, ersetzt ihn aber nicht. Zonen- und Particular-Risks-Analysen adressieren räumliche und externe Einflüsse, die keine Funktionsausfälle sind — etwa Brände, platzende Rotoren oder gemeinsame Ursachen in einem Einbaubereich. Entscheidend ist die dokumentierte Methodenwahl: Warum diese Methode für diese Fragestellung? Und halten Sie die Ergebnisse konsistent — eine FMEA, die andere kritische Pfade zeigt als der Fehlerbaum, ist ein Prüfpunkt, keine Kleinigkeit.