Fehlerverträglichkeit im Weltraum: NASAs Architektur für Orion

# Fehlertolerante Architektur: Wie NASA die Zuverlässigkeit der Bord-Systeme von Orion für die Artemis-2-Mission sicherstellt

Um die Sicherheit der Besatzung im tiefen Weltraum zu gewährleisten, hat NASA ein mehrstufiges fehlertolerantes System an Bord des Orion-Raumschiffs entwickelt. Im Gegensatz zu den vereinfachten Lösungen aus der Apollo-Ära verbindet die moderne Architektur Hardware-Redundanz, deterministische Algorithmen und Backup-Software, die Strahlungsstörungen und vollständige Prozessor-Ausfälle überstehen kann. Kritische Funktionen – von der Lebenserhaltung bis zur Navigation – werden durch ein System gesteuert, in dem jedes Bauteil mindestens drei Schutzschichten aufweist.

Achtkanal-Redundanz: Das "Fail-Silent"-Prinzip

Das Herzstück des Systems bilden zwei Bordcomputer, die jeweils zwei Flugverwaltungsmodule (FMMs) enthalten. In jedem FMM arbeiten gepaarte Prozessoren, die die Berechnungen des anderen in Echtzeit gegenseitig überprüfen. Das resultierende Setup integriert acht Prozessoren, die denselben Code parallel ausführen. Wird eine Abweichung in den Berechnungen festgestellt (z. B. durch Strahlung), wird der fehlerhafte Prozessor sofort in einen "fail-silent"-Zustand versetzt, sodass fehlerhafte Daten das Steuerungssystem nicht erreichen.

Dieser Ansatz unterscheidet sich grundlegend von traditionellen dreifach-redundanten Systemen, die auf Abstimmung setzen, um das korrekte Ergebnis zu ermitteln. Orion setzt auf priorisierte Quellenauswahl: Das System prüft die verfügbaren FMMs der Reihe nach, beginnend mit der höchsten Priorität. Selbst wenn drei von vier Modulen ausfallen, kann das Raumschiff die Mission sicher abschließen. Eine Schlüsselinnovation ist die dynamische Rekonfiguration – Module im fail-silent-Modus starten automatisch neu, synchronisieren sich mit den aktiven Einheiten und kehren ohne Besatzungseingriff in den Dienst zurück.

Wichtige Schutzkomponenten:

• Gepaarte Prozessoren mit Hardware-Ergebnisvergleich
• Dreifach-modulare Redundanz-Speicher (TMR) zur Korrektur von Single-Bit-Fehlern
• Duplizierte Netzwerkschnittstellen mit kontinuierlicher Datenüberprüfung
• Priorisierte Quellenauswahl anstelle von Abstimmung
• Dynamische Rekonfiguration im Flug

Deterministische Synchronisation: Asynchronität überwinden

Der synchrone Betrieb von acht Prozessoren erfordert die Beseitigung von Timing-Abweichungen, die selbst durch geringfügige Uhrenfrequenzschwankungen entstehen können. NASA setzt auf eine zeitgesteuerte Architektur (TTEthernet), bei der alle Operationen über eine zentrale Zeitebene synchronisiert werden. Die Flugsoftware arbeitet in einem strengen zeitlichen Rahmen:

• Große Frames (1 Sekunde) sind in kleine Frames (Millisekunden-Intervalle) unterteilt
• Ein Scheduler gemäß ARINC 653-Standard verteilt Aufgaben mit garantierten Timing-Zwängen
• Jeder FMM erhält identische Eingabedaten zu genau definierten Zeitpunkten

Dieses Modell gewährleistet räumliche und zeitliche Isolation der Prozesse, sodass ein Bauteil das andere nicht beeinflussen kann. Kritische Anwendungen, die ihren zugewiesenen Zeitraum überschreiten, werden automatisch deaktiviert und neu gestartet. Zur Aufrechterhaltung der Synchronisation korrigiert das System jede Sekunde die lokalen Uhren der FMMs anhand der "wahren" Netzwerkzeit und misst Abweichungen mit Nanosekunden-Genauigkeit.

Michael Riley von der Carnegie Mellon University betont, dass eine solche Deterministik in der modernen Entwicklung selten ist: „Agile Methoden opfern oft architektonische Disziplin für Iterationsgeschwindigkeit, was zu technischem Schuldenberg führt. In missionskritischen Systemen ist das inakzeptabel – jede Codezeile muss strenge Timing- und Funktionsspezifikationen erfüllen.“

Redundanz durch Heterogenität

Schon bei Achtkanal-Redundanz besteht das Risiko systemweiter Ausfälle – etwa durch Fehler in der primären Flugsoftware. Um das zu mindern, ist Orion mit einem unabhängigen redundanten Flugsoftwaresystem (RFS) ausgestattet, das:

• Auf einem separaten Hardware-Stack läuft
• Ein alternatives Betriebssystem nutzt
• Einen vereinfachten Steuerungsalgorithmus verwendet
• Parallel zum primären System arbeitet

Das RFS wurde bewusst so unähnlich wie möglich zum Hauptsystem gestaltet, um korrelierte Fehler auszuschließen. Bei totalem Ausfall des Primärkanals übernimmt das Backup-System automatisch die Kontrolle und versetzt das Raumschiff in den sicheren Modus. Seine Algorithmen können alle kritischen Operationen zur Stabilisierung des Fahrzeugs durchführen, einschließlich Ausrichtung der Solarpaneele und thermischer Regelung.

Besondere Beachtung finden Szenarien mit Totalstromausfall („dead bus“). Nach Stromwiederherstellung durchläuft Orion sequentiell:

• Stabilisierung der Lage im All
• Ausrichtung der Solarpaneele zur Energiequelle
• Sicherstellung der thermischen Stabilität
• Einleitung von Kommunikationswiederherstellungsversuchen

Die Besatzung kann zudem manuell eingreifen, indem sie Notfallprotokolle über mechanische Schnittstellen aktiviert.

Wichtige Erkenntnisse

• Achtkanal-Redundanz mit fail-silent-Mechanismen erhält die Betriebsfähigkeit auch nach Verlust von 75 % der Rechenmodule.
• Deterministische Architektur auf Basis von TTEthernet und ARINC 653 gewährleistet betriebliche Synchronität mit Nanosekunden-Genauigkeit.
• Heterogene Redundanz über RFS schließt Fehlerkorrelation zwischen Primär- und Backup-System aus.
• Monte-Carlo-Stresstests simulieren katastrophale Szenarien zur Überprüfung der Wiederherstellungsalgorithmen.
• Strahlungshärtete Hardware umfasst TMR-Speicher und duplizierte Netzwerkschnittstellen mit kontinuierlicher Datenintegritätsprüfung.

Verifizierung unter weltraumähnlichen Bedingungen

Zur Validierung der Architektur-Zuverlässigkeit setzt NASA eine mehrstufige Teststrategie ein. In der Entwicklungsphase rekonstruieren Simulatoren die Strahlungsumgebung der Van-Allen-Gürtel. Die Kernmethode besteht im Einspritzen künstlicher Fehler über Supercomputer-Modelle, darunter:

• Synchrone Ausfälle über mehrere FMMs
• Asynchrone Timing-Abweichungen
• Netzwerkpaketverluste
• Hardware-Ausfälle in festgelegten Intervallen

Besonderer Fokus liegt auf Moduswechsel-Tests. Bei Simulation des Verlusts von drei FMMs innerhalb von 22 Sekunden muss das System nahtlos auf das verbleibende Modul umschalten, während die Lageregulierung aufrechterhalten wird. Alle Tests überschreiten die erwarteten Missionslasten mit einem Sicherheitszuschlag von mindestens 30 %.

Diese Verfahren haben versteckte Schwachstellen aufgedeckt und behoben, wie z. B. Timing-Fenster während der Systemrekonfiguration nach Modul-Neustart. Wie Nate Wittenbrock vom Johnson Space Center betont: „Unser Ziel ist nicht nur, einen Ausfall zu erkennen, sondern sicherzustellen, dass das System ohne menschliches Eingreifen zur vollen Funktionalität zurückkehrt.“

Der Übergang von Apollo zu Artemis zeigt die Evolution der Zuverlässigkeitsansätze: In den 1960er-Jahren kompensierten mechanische Backups die begrenzte Bordrechenleistung; heute ist Software die letzte Verteidigungslinie. Orions Architektur setzt Maßstäbe für zukünftige Systeme – von autonomen Fahrzeugen bis zu kritischer Infrastruktur, wo ein einzelner Bit-Flip zur Katastrophe führen kann.

— Editorial Team