Wie oft, wenn überhaupt, wurde die "Software" im Shuttle-Orbiter aktualisiert?

„Rigorose Tests“ beschreiben nicht annähernd den Prozess, der verwendet wird, um sicherzustellen, dass die Shuttle-Software keine Fehler enthält. Dieser umfangreiche Artikel beschreibt, wie der Prozess funktioniert .
Ein paar markante Punkte:

• Die Shuttle-Software besteht aus ca. 420.000 Zeilen. Die Gesamtzahl der Fehler bewegt sich um 1 herum. An einem Punkt um 1996 herum bauten sie 11 Versionen des Codes mit insgesamt 17 Fehlern. Kommerzielle Programme ähnlicher Komplexität hätten Tausende von Fehlern.
• Der Prozess des Schreibens der Software ist mehr als akribisch. Sie brauchten ein Update der GPS-Software (6300 Codezeilen). Bevor am Code gearbeitet wurde, schrieben sie eine 2.500-seitige Spezifikation, in der die erforderlichen Änderungen detailliert beschrieben wurden.
• Jede Änderung am Code wird dokumentiert.

... die Geschichte des Codes selbst – mit jeder Zeile kommentiert, zeigt jedes Mal, wenn sie geändert wurde, warum sie geändert wurde, wann sie geändert wurde, was der Zweck der Änderung war, welche Spezifikationen die Änderung detailliert dokumentieren. Alles, was mit dem Programm passiert, wird in seiner Master-Historie aufgezeichnet. Die Genealogie jeder Codezeile – der Grund, warum es so ist, wie es ist – ist sofort für jeden verfügbar.

• Jeder Fehler wird ausführlich analysiert:

Für jeden dieser Fehler zeichnet die Datenbank auf, wann der Fehler entdeckt wurde; Welcher Satz von Befehlen hat den Fehler aufgedeckt; wer hat es entdeckt; welche Aktivität vor sich ging, als es entdeckt wurde – Tests, Training oder Flug. Es verfolgt, wie der Fehler in das Programm eingeführt wurde; wie es dem Fehler gelang, an den Filtern vorbeizuschlüpfen, die in jeder Phase eingerichtet wurden, um Fehler zu erkennen – warum wurde er nicht während des Entwurfs erkannt? bei Entwicklungsprüfungen? während der Überprüfung? Schließlich zeichnet die Datenbank auf, wie der Fehler behoben wurde und ob möglicherweise ähnliche Fehler durch dieselben Löcher geschlüpft sind.

• Alles, was der Softwarekonzern tut, ist in Prozesse strukturiert, und jeder Fehler ist ein Anlass, diese Prozesse zu überprüfen und zu verbessern:

Wie schreiben sie die richtigen Sachen?

Die Antwort ist, es ist der Prozess. Die wichtigste Kreation der Gruppe ist nicht die perfekte Software, die sie schreiben – es ist der Prozess, den sie erfunden haben, der die perfekte Software schreibt.
...
Beheben Sie nicht nur die Fehler – beheben Sie, was den Fehler überhaupt erst zugelassen hat. Der Prozess ist so allgegenwärtig, dass er für jeden Fehler verantwortlich gemacht wird – wenn es einen Fehler in der Software gibt, muss etwas mit der Art und Weise, wie sie geschrieben wurde, falsch sein, etwas, das korrigiert werden kann. Jeder Fehler, der in der Planungsphase nicht gefunden wurde, ist zumindest einigen Kontrollen entgangen. Wieso den? Stimmt etwas mit dem Inspektionsprozess nicht? Muss eine Frage zu einer Checkliste hinzugefügt werden?

Daher wird die Shuttle-Software nach den höchsten Standards der Welt geschrieben. Und das ist nur eine Ebene des Systems, das die NASA entwickelt hat, um zu verhindern, dass die Steuercomputer Probleme verursachen.

Das Shuttle wird von 5 AP-101 Allzweckcomputern gesteuert . Nach einem Upgrade im Jahr 1991 hatten sie 1 MB Speicher und liefen mit 1,4 MIPS. Aber sie sind wie ein Panzer gebaut: Jeder wiegt 64 Pfund. Es wurde entwickelt, um jahrelang ohne Abstürze zu laufen. Seine Speicherschaltkreise können durch Strahlung beschädigte Speicherzellen erkennen und verhindern, dass die beschädigten Daten verwendet werden.

Eine Softwareänderung durchläuft normalerweise etwa neun Monate interne Simulatortests und dann weitere sechs Monate Tests in einem einzigartigen NASA-Labor, bevor sie für den Flug zugelassen wird. Die Ergebnisse des anstrengenden Testprogramms? Nun, es ist 24 Jahre her, seit ein Softwareproblem das letzte Mal während einer Mission im Orbit behoben werden musste. In den letzten 12 Jahren sind während eines Fluges nur drei Softwarefehler aufgetreten. Aber die vielleicht aussagekräftigste Statistik ist, dass ein Softwarefehler noch nie die Crew, das Shuttle oder den Erfolg einer Mission gefährdet hat.

Jeder der 5 GPCs kann das Shuttle bei Bedarf alleine steuern .

Fünf IBM-Computer – von denen vier in einer redundanten Konfiguration angeordnet waren, wobei ein fünfter Computer als Backup-Einheit fungierte – ermöglichten es, frühe Shuttle-Missionen fortzusetzen, selbst wenn mehrere Ausfälle aufgetreten waren. Die Computer überprüften sich gegenseitig mehr als 500 Mal pro Sekunde.

Auf den 4 redundanten Computern läuft das PASS (Primary Avionics Software System). Auf dem fünften Computer läuft ein völlig separates Programm, das BFS (Backup Flight Control System). Es hat die gleichen Funktionen wie der PASS, wird aber von einer anderen Gruppe geschrieben und gepflegt. Dies fügt eine weitere Sicherheitsebene hinzu: Ein Fehler kann nicht alle 5 Computer gleichzeitig betreffen.

Auf dem Shuttle würden vier identische AP-101B während kritischer Missionsphasen wie Aufstieg und Wiedereintritt gleichzeitig als vierfach redundanter Satz fungieren und dieselben Informationen, die von vollständig getrennten Datenbussen stammen, in präziser Synchronisation verarbeiten. Wenn zwischen den vier primären Computern ein Konflikt auftauchte, entschied die Mehrheit und wählte die konfliktbehaftete Einheit aus der Schleife. Keiner der Computer, einzeln oder massenhaft, konnte einen anderen ausschalten – dieser Schritt blieb der Crew überlassen.

Um sicherzustellen, dass das BFS so unabhängig wie möglich war, beauftragte die NASA Rockwell damit, es zu schreiben, und es wurden sogar verschiedene Entwicklungsumgebungen und Konfigurationsverwaltungssysteme spezifiziert.

Die Software ist in der HAL/S-Sprache geschrieben , die speziell für die Verwendung in der Luft- und Raumfahrt entwickelt wurde.

Die drei Schlüsselprinzipien bei der Gestaltung der Sprache waren Zuverlässigkeit, Effizienz und Maschinenunabhängigkeit. Die Sprache ist so konzipiert, dass Aufgaben im Zusammenhang mit der Luft- und Raumfahrt (wie Vektor-/Matrix-Arithmetik) auf eine Weise ausgeführt werden können, die von Personen leicht verständlich ist, die über Raumfahrtkenntnisse verfügen, aber möglicherweise nicht unbedingt über Kenntnisse in der Computerprogrammierung verfügen.

HAL/S wurde so konzipiert, dass einige Konstrukte, von denen angenommen wird, dass sie die Ursache von Fehlern sind, nicht enthalten sind. Beispielsweise gibt es keine Unterstützung für die dynamische Speicherzuweisung. Die Sprache bietet spezielle Unterstützung für Echtzeit-Ausführungsumgebungen.

Das ist natürlich nicht billig :

In einer Branche, in der die durchschnittliche Codezeile die Regierung (zum Zeitpunkt des Berichts) ungefähr 50 US-Dollar (geschrieben, dokumentiert und getestet) kostete, kostete die Primary Avionics System Software der NASA etwas mehr als 1.000 US- Dollar pro Zeile. Insgesamt wurden 500 Millionen US- Dollar für die anfängliche Entwicklung und den Support von PASS an IBM gezahlt.

Wenn Sie mehr wissen wollen:

• An Assessment of Space Shuttle Flight Software Development Processes (kostenloses PDF-Download nach Registrierung).
• Das Erbe der Space-Shuttle-Flugsoftware (PDF) . Dieses Dokument listet 31 Operational Increment (OI) Releases (dh größere Softwareänderungen) auf (Seite 22).