Wie NASA den fehlertoleranten Computer von Artemis II gebaut hat

 (cacm.acm.org)
7 Punkte von GN⁺ 19 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der Flugcomputer des Mond-Raumschiffs Orion ist deutlich widerstandsfähiger und stärker zur automatischen Steuerung befähigt als Systeme aus der Apollo-Ära und verwaltet alle Kernfunktionen wie Lebenserhaltung, Stromversorgung und Kommunikation
  • Damit er auch in 250.000 Meilen Entfernung im Mondorbit ohne Unterbrechung arbeitet, wurde er mit physischer und logischer Redundanz sowie mehreren Flugcomputern so ausgelegt, dass er Hardwarefehler und Strahlungseinflüsse übersteht
  • Jedes Flight Control Module (FCM) besteht aus einem Paar selbstprüfender Prozessoren, sodass insgesamt 8 CPUs parallel laufen; Fail-Silent-Design und ein prioritätsbasierter Algorithmus zur Ausgabewahl isolieren Fehler
  • Das System hält mit zeitgetriggertem Ethernet und einer deterministischen Architektur einen vollständig synchronisierten Zustand aufrecht und korrigiert mit dreifach redundanten Netzwerken und Speicher sogar einzelne Bitfehler automatisch
  • Falls alle Hauptsysteme ausfallen, übernimmt eine Backup Flight Software auf Basis unabhängiger Hardware und eines eigenen Betriebssystems die Kontrolle; diese Struktur gilt als Modell für die Always-on-Resilienz autonomer Systeme

NASAs fehlertolerantes Computerdesign für Artemis II

  • Der Flugcomputer von Artemis II ist deutlich widerstandsfähiger und stärker zur automatischen Steuerung befähigt als der Navigationscomputer der Apollo-Ära
    • Apollo-Computer nutzten einen 1-MHz-Prozessor und etwa 4 KB Speicher, während wesentliche Steuerfunktionen überwiegend auf manuellen Schaltern oder Relais basierten
    • In der Orion-Kapsel von Artemis II verwaltet der Computer alle Kernfunktionen wie Lebenserhaltung, Stromversorgung und Kommunikation direkt
  • Da ein Missionsfehler in 250.000 Meilen Entfernung im Mondorbit nicht wieder gutzumachen wäre, muss das System auch bei Weltraumstrahlung, Bit-Flips und Hardwaredefekten ohne Unterbrechung weiterarbeiten
    • NASA setzt dafür auf physisch redundante Verkabelung, logisch redundante Netzwerkebenen und mehrere Flugcomputer als Schutz vor Hardwarefehlern

  • The Power of Eight

    • Orion verwendet eine Architektur, die über die klassische dreifache Redundanz (triple redundancy) hinausgeht
      • Zwei Vehicle Management Computer (VMC) tragen jeweils zwei Flight Control Modules (FCM), insgesamt also 4 FCMs
      • Jedes FCM besteht aus einem selbstprüfenden (self-checking) Prozessorpaar, sodass insgesamt 8 CPUs die Flugsoftware parallel ausführen
    • Das System basiert auf einem Fail-Silent-Design: Tritt ein Fehler auf, sendet die betroffene CPU keine fehlerhafte Ausgabe, sondern wechselt sofort in einen stillen Zustand
    • Statt Mehrheitsentscheidungen per Voting wird ein prioritätsbasierter Algorithmus zur Quellenauswahl verwendet, um die Ausgabe eines intakten Kanals zu wählen
    • NASA rechnet beim Durchflug durch die Van-Allen-Strahlungsgürtel mit vorübergehenden Fehlern; selbst beim Ausfall von bis zu 3 FCMs über maximal 22 Sekunden kann die Mission mit dem letzten verbleibenden FCM fortgesetzt werden
    • Ein stillgeschaltetes FCM kann nach einem Reset erneut mit den anderen Modulen synchronisiert und während des Flugs wieder eingebunden werden

  • Aufrechterhaltung deterministischen Verhaltens

    • Um mehrere unabhängige Computer in vollständiger Synchronisation (Lockstep) zu halten, kommt eine deterministische Architektur (deterministic architecture) zum Einsatz
    • Orion nutzt ein zeitgetriggertes Ethernet (time-triggered Ethernet), um Zeitinformationen im gesamten System zu verteilen
      • Die Flugsoftware läuft in einem Major Frame und Minor Frame, die von einem ARINC653-Scheduler verwaltet werden
      • Durch Zeit- und Raumaufteilung wird sichergestellt, dass Ein- und Ausgaben perfekt mit dem Netzwerkzeitplan abgestimmt sind
    • Jedes FCM erhält dieselben Eingaben, führt denselben Code aus und erzeugt dieselben Ausgaben
    • Jede Sekunde wird die Taktabweichung der FCMs gemessen und auf die Referenzzeit des Netzwerks nachkalibriert
    • Anwendungen, die ihre Deadline nicht einhalten, werden automatisch in einen stillen Zustand versetzt und anschließend neu synchronisiert
    • Die Hardware nutzt dreifach modulare redundante Speicher (TMR), um einzelne Bitfehler automatisch zu korrigieren; auch die Netzwerkschnittstellenkarten vergleichen zwei Traffic-Pfade und wechseln bei Fehlern in den Fail-Silent-Zustand
    • Das Netzwerk ist über drei unabhängige Ebenen dreifach redundant ausgelegt, und alle Switches verfügen über Selbstprüfungsfunktionen

  • Das letzte Backup-System

    • NASA berücksichtigt auch Common-Mode-Failures, die alle Hauptkanäle gleichzeitig betreffen könnten
    • Dafür ist zusätzlich ein separates Backup Flight Software (BFS)-System an Bord
      • BFS besteht aus anderer Hardware, einem anderen Betriebssystem und unabhängig entwickelter, vereinfachter Flugsoftware
      • Fällt das Hauptsystem aus, übernimmt BFS automatisch die Kontrolle und kann die dynamischen Phasen der Mission abschließen
      • Anschließend kann die Crew versuchen, die primären FCMs wiederherzustellen
    • Fail-Silent-Logik ist essenziell, muss jedoch durch Watchdog-Timer und mehrschichtiges Monitoring ergänzt werden, damit Fehler nicht unentdeckt bleiben
    • Das System ist auch auf das vollständige Versagen der Stromversorgung ("dead bus") hin ausgelegt
      • Nach Wiederherstellung der Stromversorgung wechselt es automatisch in den Safe Mode
      • Dabei werden die Solarpaneele zur Sonne ausgerichtet, um die Energieversorgung wiederherzustellen; anschließend wird das Fahrzeug zur thermischen Stabilisierung mit dem Heck zur Sonne gedreht
      • Danach versucht das System, die Kommunikation mit der Erde wiederherzustellen; falls nötig, kann die Crew die Lebenserhaltung manuell anpassen

  • Die Zukunft der Zuverlässigkeit

    • Der Wandel von Apollo zu Artemis bedeutet einen sprunghaften Anstieg der Softwarekomplexität
      • Bei Apollo gab es noch mechanische Backups, während bei Artemis die Software die gesamte Steuerung übernimmt
    • NASA verwendet einen modernen Verifikations-Workflow mit Simulationen über sämtliche Umgebungen hinweg, Monte-Carlo-Stresstests und umfangreicher Fault Injection
      • Mit Supercomputern wird der gesamte Flugzeitplan simuliert, um zu prüfen, ob sich die Software auch bei Hardwarefehlern per Fail-Silent-Verhalten erholen kann
    • Die Zero-Tolerance-Architektur von Orion gilt als Modell für Always-on-Resilienz, die künftig auch in autonomen Fahrzeugen und industriellen Steuerungsnetzen Anwendung finden könnte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 19 일 전
Hacker-News-Kommentare

  • Von 1989 bis 1995 bei Stratus an VOS- und Datenbank-Performance gearbeitet
    Stratus war ein Unternehmen für hardwarebasierte fehlertolerante (fault-tolerant) Systeme, während der Konkurrent Tandem einen softwarebasierten Ansatz verfolgte
    Die Architektur von Stratus war „pair and spare“: Alle Boards waren doppelt vorhanden, und jeder Pin-Ausgang wurde bei jedem Takt verglichen
    Beim Wechsel von Motorola 68K zu Intel hatte das Hardware-Team große Schwierigkeiten, weil bei einigen Instruktionen ungenutzte Pins flottierten

  • Die Formulierung eines CMU-Forschers, dass „Agile und DevOps die architektonische Disziplin geschwächt haben“, blieb hängen
    Es wirkt, als hätten wir verlernt, wie man deterministische Systeme baut
    Das strenge Frame-Scheduling von Time-triggered Ethernet fühlt sich wie eine völlig andere Welt an als heutige Softwareentwicklung

    • Es gibt immer noch Leute, die Embedded-Systeme mit Anforderungen an Echtzeitgarantien entwickeln
      Einige moderne Entwicklungspraktiken wie Unit-Tests und CI haben auch in solchen Umgebungen positive Effekte
    • In der Apollo-Zeit war deterministisches Rechnen auf Basis von WCET (Worst-Case Execution Time) dank verteidigungsgetriebener Forschungsförderung Mainstream
      Heute hat sich der Fokus auf den kommerziellen Markt verlagert und die Investitionen sind gesunken, aber es gibt weiterhin viele interessante Algorithmen
      Die Forschung von Frank Mueller oder Johann Blieberger ist sehenswert
    • Time-triggered Ethernet ist Teil eines Datenbusses für die Flugzeugzertifizierung, und INRIA und Airbus haben dazu geforscht
      In Umgebungen mit begrenzten Ein- und Ausgaben wie in Flugzeugen passt ein deterministisches Design perfekt
      Tatsächlich ist es eher ein dedizierter Hardware-Bus als Ethernet im üblichen Sinn
    • Soweit ich gehört habe, nutzt auch der Tesla Cybertruck diesen Ansatz auf Ethernet
    • Wahrscheinlich war gemeint: SpaceWire

  • Beim Lesen der „radiation hardening“-Challenge von Code Golf
    fragte ich mich, ob so ein Ansatz in der Praxis wirklich nützlich wäre
    Realistisch betrachtet sind zu viele Probleme auf verschiedenen Ebenen miteinander verflochten, aber die Idee ist trotzdem interessant

  • Das im Artikel beschriebene „fail-silent“-Design war interessant
    Ich habe mich aber gefragt, wie man erkennt, wenn beide CPUs gleichzeitig falsch rechnen und dabei dasselbe Ergebnis liefern

    • Die Wahrscheinlichkeit, dass durch Strahlung gleichzeitig derselbe Bitfehler in beiden CPUs entsteht, ist extrem gering
    • Solche CPUs arbeiten in einer Lockstep-Architektur, führen also dieselben Operationen gleichzeitig aus und vergleichen die Ergebnisse
      Die Wahrscheinlichkeit, dass beide CPUs denselben Fehler gleichzeitig machen, ist deutlich geringer als der FIT-Wert einer einzelnen CPU
    • Die Chance, dass in beiden CPUs gleichzeitig dasselbe Bit kippt, ist eher geringer als die Wahrscheinlichkeit eines Asteroideneinschlags
      Im All gilt allerdings Murphys Gesetz, also sicher sein kann man nie
    • Tatsächlich tritt dasselbe Problem auch bei einer dreifachen Mehrheitsarchitektur auf, wenn zwei CPUs denselben Fehler machen
    • Wenn System 1 und 2 gleichzeitig falsch liegen und die übrigen 6 korrekt sind,
      könnte bei einer „25%-Mehrheit“ trotzdem das falsche Ergebnis ausgewählt werden

  • Mich interessieren konkrete Details zu CPU, RAM, OS und Sprache dieses Systems
    Ich würde auch gern wissen, wie oft das FCM tatsächlich „fail-silent“ geworden ist

    • NASA cFS ist in C geschrieben und auf GitHub veröffentlicht
      Es läuft gewöhnlich auf FreeRTOS oder RTEMS
      Ich persönlich fand die Projektstruktur so komplex, dass sie schwer handhabbar war
    • BFS verwendet cFS und ist auch in diesem YouTube-Video zu sehen
      Der Großteil des NASA-Kerncodes ist nicht öffentlich, aber cFS ist gutes Material, um klassisches Flight-Software-Design zu lernen

  • Im Artikel fehlen Details zum eigentlichen RTOS und zur Architektur
    Die primäre Flugsteuerung von Orion basiert auf einer vierfach redundanten Struktur mit Green Hills INTEGRITY RTOS und BAE RAD750-Prozessoren
    BFS läuft auf völlig anderer LEON3 + VxWorks-Hardware und nutzt das cFS-Framework von NASA
    Das ist eine modulare, wiederverwendbare Architektur, die auch beim James-Webb-Teleskop und beim Mars Rover eingesetzt wurde
    Diese Struktur ist kein simples „Hauptsystem + Backup“, sondern das Konzept der dissimilar redundancy
    Mehr dazu in NASA Technical Document 1, Dokument 2

    • Aber selbst wenn die Teams völlig getrennt arbeiten, können identische Fehler entstehen, wenn sie auf dieselben Lehrbücher oder Algorithmusquellen zurückgreifen

  • Die tatsächliche Umsetzung lag bei Lockheed Martin und den Subunternehmern
    Wenn Medien es so darstellen, als habe NASA das direkt selbst gebaut, führt das zu Missverständnissen

    • Ich glaube nicht, dass Lockheed ohne Anfrage der NASA einfach so ein teures vierfach redundantes PowerPC-System gebaut hätte
    • BFS wurde überwiegend intern bei NASA entwickelt (laut einem Freund, der daran beteiligt war)
    • Tatsächlich dürfte es eine enge Zusammenarbeit zwischen NASA und Lockheed gegeben haben
    • Es fiel auch der scherzhafte Hinweis: „Denk an einen Megakonzern“

  • Als ich vor 25 Jahren als Webentwickler gearbeitet habe, fragte ich einen Freund mit NASA-Hintergrund, wie sie mit Bugs umgingen
    Er lachte und sagte: „Es gab keine Bugs“
    Die Entwickler von heute sind an Umgebungen gewöhnt, in denen bei einem Fehler keine Menschenleben auf dem Spiel stehen

    • Jede Branche hat ihren eigenen Maßstab dafür, was „gut genug“ ist
      Bei Webservices geht es um Umsatzverluste, bei Raumfahrzeugen um Menschenleben

  • Ich habe früher einmal an einem strahlungsharten Computer gearbeitet
    Dabei nutzten wir zusätzlich zur einfachen Redundanz auch nicht-redundante Fehlererkennungsverfahren
    Schade, dass man in diesem System so einen Ansatz nicht sieht

    • In der Shuttle-Ära wurden fünf Computer an unterschiedlichen Orten und in verschiedenen Ausrichtungen eingebaut,
      um durch physische Härtung den Strahlungs-Stoßquerschnitt zu verteilen

  • Die verschiedenen Redundanzstrukturen sind beeindruckend, aber ich frage mich, ob manuelle Steuerung (Manual Override) weiterhin möglich ist
    Ob man also wie bei Apollo 11 und 13 bei Bedarf direkt eingreifen kann
    Da weiterhin Astronauten mit Testpilotenhintergrund fliegen, scheint das wohl möglich zu sein