Welcher Art waren die bekannten Fehler in der Space-Shuttle-Software?

Obwohl die Flugsoftware des Space Shuttles von hervorragender Qualität war, ist es völlig falsch zu glauben, dass es nur einen Fehler gab. Es gab viele bekannte Fehler in der Flugsoftware (FSW). Hier sind drei, die mir spontan einfallen, die Missionen beeinflusst haben.

1. Die Flugkampagne des Shuttle-Programms begann mit einem peinlichen Softwarefehler! Der allererste Startversuch wurde geschrubbt, als der Computer der Backup Flight Software (BFS) sich weigerte, sich mit den vier Computern des Primary Avionics Software System (PASS) zu synchronisieren. Details in "The Bug Heard Round the World" hier .

2. Der Erstflug der Raumfähre Endeavour (STS-49) war aus vielen Gründen voller Action. Zum einen wurde ein Fehler in der Lambert-Targeting-Software gefunden, die zur Berechnung der Rendezvous-Parameter verwendet wird. Die Berechnung konnte nicht konvergieren

   aufgrund einer Nichtübereinstimmung zwischen der Genauigkeit der Zustandsvektorvariablen, die die Position und Geschwindigkeit des Shuttles beschreiben, und den Grenzen, die zum Begrenzen der Berechnung verwendet werden

   ( Quelle ) (Dieses Papier spricht über zusätzliche Shuttle-FSW-Fehler)

   Zusätzliche Einzelheiten zu den Missionsauswirkungen des Lambert-Softwareproblems und Diskussion anderer FSW-Fehler, die sich auf Rendezvous-Missionen auswirken, finden Sie hier

3. Noch als STS-126 im Jahr 2008 tauchte ein neuer Fehler in der OI-33-Softwareversion auf. Nach dem Abschalten des Haupttriebwerks taten dies zwei Kommunikationssysteme, die automatisch von ihrer Start- in die Umlaufbahnkonfiguration wechseln sollten, aufgrund eines Codierungsfehlers nicht.

   Die primäre Kommunikation verwendete weiterhin S-Band-Frequenzen, nachdem sie auf das leistungsstärkere Ku-Band hätte wechseln sollen. Die Verbindung zwischen dem Shuttle und seiner Nutzlast – der Payload Signal Processor (PSP) – blieb für eine Funkverbindung konfiguriert, anstatt automatisch auf die festverdrahtete Nabelverbindung umzuschalten.

   Alle Einzelheiten zu diesem Problem, die Sie sich wünschen, finden Sie hier .

Mehrere andere Fehler tauchten im Shuttle Mission Simulator Training auf. Sie wurden dort aufgrund der extremen Natur der Trainingsszenarien im Vergleich zum tatsächlichen Flug oder den FSW-Verifizierungseinrichtungen aufgedeckt. Sie haben nie Missionen beeinflusst, aber sie waren Käfer, die flogen. Es gibt hier eine Präsentation über diese Fehler (die schwerwiegend genug waren, um das Fahrzeug zum Absturz zu bringen) . Hier ist ein lustiges Bild aus dieser Präsentation – der PASS hängt vollständig an einer Transoceanic Abort Landing (TAL). Die Besatzung musste das BFS angreifen.

Mit freundlicher Genehmigung von Tristan , hier ist eine Folie aus einer anderen Präsentation von James Orr, die ~425 geflogene FSW-Bugs (aufgeführt als DRs – Discrepancy Reports) auf dem Höhepunkt um 1983 zeigt.

Quelle

TL;DR: Wenn Ihnen jemand sagt, dass das Space Shuttle nur einen FSW-Bug hatte, kaufen Sie keine Immobilien von ihm.

Als Autor von einem der Beiträge, auf die Sie sich bezüglich der Anzahl der gefundenen Fehler beziehen, haben Sie die Worte missverstanden. Bitte lesen Sie sie erneut.

Beim STS liegt ein „Bug“ vor, wenn die Software die Anforderungen nicht erfüllt. Es bedeutete nicht unbedingt, dass etwas Schlimmes passieren würde, nur dass der Code nicht den Anforderungen entsprach. Die Entwickler haben die Fehler nicht klassifiziert. Bei übermäßig komplexen Fehlern kann ein Entwickler um eine Analyse gebeten werden. Nichts wurde als „Feature“ bezeichnet, wenn es nicht in den Anforderungen enthalten war. Das wäre auch ein Bug.

Außerdem durften die Entwickler keine Fehler ohne formelle Genehmigung beheben. Wir durften keine Zeile in der Quelle ändern, die nicht in direktem Zusammenhang mit der Änderungsautorisierung stand, unter der wir arbeiteten. Wir durften den Einzug nicht ändern, um den Code besser lesbar zu machen, es sei denn, unsere Änderungen in der Nähe waren signifikant genug. Diese Einschränkungen sollten versehentliche Änderungen verhindern, die zu einer versehentlichen Einführung von Fehlern führen würden. Jede geänderte Leitung wurde mit einer bestimmten Person und CR/DR-Autorisierung gekennzeichnet.

Gerade bei Leitrechnungen konnten die Anforderungen aufgrund von Einschränkungen der Rechner manchmal nicht umgesetzt werden. Beim Echtzeit-Codieren ist eine verspätete Antwort genauso schlimm wie eine falsche Antwort. Mindestens einmal mussten die Anforderungen an den Code angepasst werden.

Niemand kennt zu irgendeinem Zeitpunkt die tatsächliche Anzahl von Fehlern in irgendeiner Software, aber Jim Orr hat buchstäblich das Buch über Probleme und Fehler in der Space-Shuttle-Software geschrieben. Ihm wurden alle Daten zu Anforderungsüberprüfungen, Designüberprüfungen, Testplanüberprüfungen, Codeüberprüfungen und Testergebnissen zur Verfügung gestellt, als ich dort für die GN&C FSW arbeitete

Es gab definitiv Hunderte von Fehlern im FSW, nur sehr wenige wurden als SEV-1 eingestuft. Keiner würde einen Computerabsturz oder andere typische Fehler verursachen, die Menschen heute in ihrem Leben in Kauf nehmen. Der GN&C-Code hatte keine Probleme wie typischer Desktop- oder Server-Code. Es gab keine dynamische Speicherzuweisung. Die Verwendung von Zeigern erforderte eine schriftliche, genehmigte Abweichung vom SW-Standards-Board. Der gesamte Code wurde formell von mindestens 6 Personen begutachtet. Komplizierterer Code würde von mehr als 20 Personen überprüft werden – im selben Raum. Im Laufe der Jahrzehnte wurde der Prozess zur Erstellung der Software immer besser. Der Prozess wurde so eingerichtet, dass er nicht auf Superprogrammierer angewiesen war , um relativ fehlerfreie Software zu erstellen. Es ging wirklich nur um den Prozess.

In meinen Jahrzehnten, in denen ich Software für viele verschiedene Unternehmen geschrieben habe, habe ich gesehen, dass überall sonst auf die Idee eines Superprogrammierers gesetzt/hofft wird, um bessere Ergebnisse zu erzielen. Das Problem dabei ist, dass Super Programmer nicht leicht reproduzierbar ist. Ich habe gesehen, dass es an einem Ort funktioniert, und zwar nur, weil jeder Programmierer jeden Fehler als persönlichen Fehler betrachtete. Überall sonst gibt es gute, durchschnittliche und schlechte Programmierer. Vor allem in größeren Organisationen scheint sich die Skala stärker als anderswo in Richtung schlecht zu verschieben. Es gibt immer Ausnahmen und selbst wenn ich beruflich direkt mit 3000 Programmierern zusammengearbeitet habe, sind das natürlich nicht alle Programmierer überall.

Hoffe das verdeutlicht und ist hilfreich.