Drei dieser Booster hatten steuerbare Düsen, um die Rakete trotz des höheren Schubs noch kontrollieren zu können. Trotz der Änderungen an der Rakete wurde die Steuersoftware aus der Delta II übernommen, schließlich funktionierte sie zuverlässig. Die neue Rakete wurde mit großem Selbstvertrauen und einem kommerziellen Nachrichtensatelliten (Galaxy 10) gestartet.

Der Flug war zunächst erfolgreich, aber 75 Sekunden nach dem Start geriet die Rakete in Schräglage zur Flugrichtung und musste gesprengt werden. Nein, das habe ich nicht bei der Ariane 5 abgeschrieben. Die hielt nur 37 Sekunden durch!

Die hydraulischen Steuersysteme der Boosterraketen versuchten eine 4-Hz Eigenschwingung in Rollrichtung auszugleichen. Diese Eigenschwingung wurde aber durch die Korrekturbewegungen nur noch verstärkt. Die ständigen Korrekturbewegungen führten schließlich dazu, dass dem System die Hydraulikflüssigkeit ausging und die Steuerdüsen in ihrer letzten Position stehen blieben. Die Schwingung in Rollrichtung hörte ohne die ständigen Korrekturbewegungen sofort auf. Aber die verbliebenen Steuerdüsen der ersten Stufe hatten keine Chance, gegen die Booster anzukommen. Denn zwei der Booster blieben im vollen Ausschlag stecken. (Die Raketen verwenden ein offenes Hydrauliksystem, in dem Flüssigkeit aus einem Tank bei jeder Bewegung verbraucht wird.)

Bekanntes Problem und trotzdem ignoriert

Die Problematik solcher Eigenschwingungsmoden war auch schon vor dem Flug bekannt. Es gab sie auch bei der Delta II. Wegen der Ähnlichkeit der beiden Raketen wurden aber keine eigenen Simulationen mit der Delta III durchgeführt. So groß war die Ähnlichkeit doch nicht, wie Computersimulationen erst nach dem Unfall zeigten. Die Lösung war letztlich ganz einfach. Die 4Hz wurden zu den Frequenzen in Rollrichtung hinzu gefügt, die das System bei den Korrekturmanövern ignorieren sollte.

Das funktionierte auch bei den nächsten Flügen. Allerdings versagte beim zweiten Flug das RL-10 Triebwerk der zweiten Stufe beim Wiederstart. Auch dabei ging ein kommerzieller Satellit verloren. Im dritten Flug kam endlich eine reine Testnutzlast zum Einsatz. Er war erfolgreich, aber auch der letzte Flug einer Delta III. Die Booster der Delta III wurden später noch mit der Delta II, als Delta II Heavy, benutzt. Die zweite Stufe der Delta III wurde zur zweiten Stufe der Delta IV und wird demnächst auch die zweite Stufe vom Block 1 der neuen Schwerlastrakete SLS sein.

Genau wie bei der Ariane 5 führte die Übernahme der Software von einer alten Rakete in ein neues System zum Verlust einer Mission. In beiden Fällen gab es die Überzeugung, dass die alte Software die Fehlerfreiheit garantieren würde. Aber tatsächlich wurde sie zur Ursache eines völlig neuen Problems.

Ein Kommafehler und das Schicksal eines Titan IV Starts

Kein Stück besser verlief der Start einer Titan IV 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 eine falsch eingetippte Variable. Wie es der Untersuchungsbericht sagt:

“That failed process did not detect and correct a human error in the manual entry of the I1(25) roll rate filter constant entered in the Inertial Measurement System flight software file. The value should have been entered as –1.992476, but was entered as –0.1992476.”

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 nochmals 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.

1 / 2 / 3 / 4

Kommentare (2)

  1. #1 Karl Mistelberger
    26. November 2015

    Die Raumfahrt steckte schon früher in einer Krise: Communication Aberration. Jedem Amateurastronomen wäre der Fehler von Perkin-Elmer aufgefallen.

    Mehr: https://www.google.de/search?q=perkin+elmer+null+corrector

  2. #2 Michael Khan
    Darmstadt
    7. Dezember 2016

    Hier wird eine ganze Menge als “Softwarefehler” subsumiert, selbst wenn das nicht zutrifft. Wenn Software, die gemäß korrekten Spezifikationen richtig codiert wurde und auf der Rakete, für deren Steuerung sie ursprünglich entwickelt worden war, problemlos funktionierte, nun plötzlich ohne hinreichende Tests auf einer ganz anderen Rakete installiert wird, für deren Steuerung sie nie entwickelt war udn wo sie auch gar nicht funktionieren kann – wieso sollte das ein Softwarefehler sein? Es ist mit ziemlicher Sicherheit ein Managementfehler, weil zu wenig Zeit und Resourcen für Systemtests verfügbar gemacht wurden.

    Die Beschreibung der vermeintlichen Problemursache beim Mars Climate Orbiter ist schlicht falsch: “Die Bodenkontrolle sendete Daten in Poundforce, aber die Software des Orbiters interpretierte sie als Angaben in SI-Einheiten, in Newton.”. Das ist Unsinn.

    Richtig ist, dass der Hersteller der Sonde in der Vielzahl der Daten, die dem Kontrollzentrum bei der NASA übermittelt worden waren, bei einem Parameter einen Fehler gemacht hatte. Es handelt sich um den Parameter, der angibt, wie viel Auswirkung auf die Bahn die kleinen Manöver haben, mit denen die Schwungráder desatutiert werde, Dieser nicht unmittelbar intuitiv verifizierbare Parameter wurde vom Hersteller in pound-force-seconds angegegeben. Die Bahnbestimmungs- und Navigationssoftware bei NASA/JPL verwendete und erwartete aber Daten in metrischen Einheiten, also Newton-seconds.

    Der falsche Wert führte zu einem sich langsam aufbauenden Fehler in der Bahnbestimmung, und zwar unglücklicherweise gerade in der Komponente, die mit den Funkmessdaten, aus denen die Bahn bestimmt wird, nicht gut beobachtet werden konnte.

    Die Leute beim JPL wussten, dass etwas nicht stimmt, weil die Residuen in der Bahnbestimmung zu groß waren. Sie konnten aber die Ursache nicht orten. Zum einen, weil sie Pech hatten und dr Fehler sich ausgerechnet in der einen Komponente auswirkte, die sie mit ihren Funkmessdaten weniger gut “sehen”konnten. Zum anderen, weil die eine Billigmission sein sollte und die Ressourcen entsprechend limitiert waren. Am Ende wich die berechnete von der tatsächlichen Position um 75 km ab. Noch einmal Pech – der Fehler war genau so, dass die Sonde statt, wie gezielt 150 km, nur 75 km über der Oberfläche vorbeiflog.

    Abgesehen von der generell nicht richtigen Darstellung im Blog-Artikel – auch das hier war kein Softwarefehler. Es war eine Kombination aus falschen Eingangsdaten, Pech, und unzureichenden Resourcen. Was auch immer schief lief – dass es hier irgendwo ein Problem mit fehlerhafter Software gegeben habe, sehe ich nicht.