Ein Kommafehler und das Schicksal eines Titan-IV-Starts

Kein Stück besser verlief der Start einer Titan-4-Rakete am 30. April 1999. Auch sie verwendete eine Centaur-Oberstufe, in diesem Fall mit zwei RL-10-Triebwerken. Sie sollte einen Militärsatelliten direkt in einen geostationären Orbit bringen. Der kam dort nie an. Die Centaur feuerte im Flug unkontrolliert die Lagekontrolltriebwerke, während die Haupttriebwerke liefen. Ohne kontrollierte Lage kommt die Stufe so aber auf keinen Fall in irgendeinen geplanten Orbit.

Die unmittelbare Ursache war laut Untersuchungsbericht eine falsch eingetippte Variable.

Aber Tippfehler passieren. Es ist Aufgabe der Qualitätssicherung, solche Fehler zu finden. Die Variablen gehören zu einem System von Variablen, die Trägheitseffekte im Bezugssystem wie zum Beispiel die Erdrotation ausgleichen sollen. Diese eminent wichtigen Daten wurden aber nicht erneut kontrolliert. Tatsächlich lieferte das System schon vor dem Start, auf der stehenden Startrampe, fehlerhafte Werte. Es fand sich aber niemand, der den Fehler ernst genug nahm, um den Start abzubrechen.

Am Mars gescheitert

Die größte Aufmerksamkeit durch Softwarefehler bekamen zwei gescheiterte Marsmissionen. Der Absturz des Mars Climate Orbiters am 23. September 1999 ist legendär. Die Bodenkontrolle sendete Daten in Poundforce, aber die Software des Orbiters interpretierte sie als Angaben in SI-Einheiten, also in Newton. Entsprechend falsch war die Flugbahn und der Mars Climate Orbiter stürzte auf den Planeten.

Den Schlusspunkt dieser Serie von Fehlern setzte der Mars Polar Lander am 3. Dezember 1999. Die Bremsdüsen der Sonde mussten abschalten, sobald der Lander die Oberfläche berührte. Dazu gab es druckempfindliche Sensoren in den Landebeinen. Diese Sensoren lieferten aber auch schon ein Signal, als die Beine ausgefahren wurden. Das war bekannt und Warnungen vor diesem Problem fanden sich in der Dokumentation der Landerhardware. Jedoch kamen diese Warnungen nicht bei den Programmierern an, weshalb die Software keine Routine enthielt, die dieses falsche Signal herausfilterte.

Zu viel Rechenleistung brachte zu viel Komplexität

Diese Fehler waren ein Phänomen, das in den neunziger Jahren plötzlich auftrat. Über Jahrzehnte funktionierte die von den Programmierern abgelieferte Software weitgehend zuverlässig. Es gab Probleme, aber nicht in dieser Zahl, nicht mit diesen Auswirkungen und nicht über alle möglichen Raumfahrtprogramme verteilt. Eine solche Reihe von Fehlern, noch dazu primitive Fehler, war praktisch undenkbar. Am berühmten Y2K Bug konnte es noch nicht liegen. Die Raketen liefen übrigens nicht mit Windows 95, das zur gleichen Zeit für seine Abstürze bekannt war. Die Fehler mussten untersucht werden (PDF).

Wie zu erwarten war, zeigten die Untersuchungen eine Reihe von Nachlässigkeiten in allen Bereichen. Das fing beim Management an, der Verteilung der Verantwortung und ging mit fehlender Kommunikation im Unternehmen und schlechter Spezifikation der Anforderungen an die Software weiter. Systemtests wurden nicht mehr mit der vollständigen Hardware durchgeführt, womit sie praktisch wertlos waren. Beim Zusammenspiel von Komponenten stecken die Bugs im Detail - und diese Details fehlen, wenn ein Testsystem nur simuliert und nicht die finale Hardware benutzt wird. Hinter diesen Nachlässigkeiten wurden verschiedene Gründe vermutet. Sparzwänge standen ganz oben auf der Liste, ebenso wie übertriebenes Selbstvertrauen. Beide hatten sicherlich einen Anteil.

Das erklärt aber nicht, warum die gleiche Art von Problemen parallel in der Nasa, der Esa, US-Militärmissionen und kommerziellen Missionen auftauchten. In allen Fällen spielte die wachsende Komplexität der Software eine wichtige Rolle. Der Ausfall der Ariane 5 ist exemplarisch. Die Ursache war eine Variable, die aus Performance-Gründen nicht auf Bereichsüberschreitung kontrolliert wurde. Die Variable befand sich aber in einem ganzen Programmteil, der nicht mehr benötigt wurde und trotzdem ständig lief. Anstatt neue Software zu entwickeln, wurde alte Software erweitert.