(Dieser Artikel erschien, etwas gekürzt, auf Golem.de unter dem Titel “Softwarefehler in der Raumfahrt – In den Neunzigern stürzte alles ab“)

In den 90er Jahren grassierte eine Seuche in der Raumfahrt, der eine Mission nach der anderen zum Opfer fiel. Es wurden neue Raketen eingeführt und sie explodierten, oder sie gerieten außer Kontrolle und die Nutzlast war gestrandet. Raumsonden flogen zum Mars und wurden nie mehr gehört. Die Ursache waren Softwarefehler. Immer wieder schlichen sich einfache Fehler ein, die vor dem Flug nicht entdeckt wurden. Bereichsüberschreitungen von Variablen und Kommafehler beim Abtippen von Konstanten führten zu Verlusten von hunderten Millionen Dollar. Es war mit Sicherheit ein schmerzhafter Lernprozess. Wie schmerzhaft er genau war, zeigt die Liste der verlorenen Missionen.

Der erste Flug der Ariane 5

1996 hat die ESA ihre neue Ariane 5 Rakete zum ersten Mal gestartet. Anders als ursprünglich geplant, war die Ariane 5 keine verbesserte Ariane 4, sondern eine völlig neue Rakete. Kein Teil war mehr das Gleiche. Jeder der beiden Feststoffbooster hatte allein schon mehr Schub als die größte Variante der Ariane 4. Bei 66% mehr Startmasse hatte die Ariane 5 einen 140% größeren Schub. Sie hebt viel schneller ab und es wirken im Flug auch viel größere Kräfte.

Die Hardware war völlig neu. Nur die Software sollte von der alten Ariane übernommen werden, weil sie bisher zuverlässig funktioniert hat und die Neuentwicklung viel teurer wäre. Die Ariane 5 sollte trotzdem von Anfang an genauso zuverlässig sein, wie die Ariane 4. Schon beim ersten Flug sollte sie vier “Cluster” Satelliten im Wert von $370mio tragen.

37 Sekunden bis zur Selbstzerstörung

37 Sekunden nach dem Start musste die Rakete gesprengt werden. Die viel größeren Querbeschleunigungen der Rakete wurden ihr zum Verhängnis. Der Messwert der Beschleunigung wurde als (signed) 16-bit Integer weitergegeben. Als die den magischen Wert von 32767 übersprang und zur -32768 wurde, löste das eine Fehlermeldung aus, die in ADA standardmäßig zum Abbruch des Steuerprogramms führte. Daraufhin blieben die Steuerdüsen in ihrer Position stecken, die Rakete drehte sich quer zur Flugrichtung und wurde schließlich gesprengt.

(Man beachte auch den Ansager kurz vor der Explosion, als sich die Rakete schon zur Seite neigte. “Alle Werte sind normal.”)

Die Variable wurde aus Performancegründen aus der Kontrolle auf Wertbereichsüberschreitung ausgenommen. Der Programmteil in dem das alles passierte, wurde tatsächlich in der Ariane 5 auch nicht mehr gebraucht. Er wurde nur übernommen um die Unterschiede in den Softwareversionen der Raketen zu minimieren.

Der Fehler wäre mit dem das Prinizip “Test as you fly, fly as you test” wohl erkannt worden. Anstatt das Steuersystem mit Daten aus dem echten Trägheitsnavigationssystem der Rakete zu testen, wurde das nur mit Werten aus einer Simulation getan. Und selbst diese Simulationen folgten nicht der eigentlichen Flugbahn der neuen Ariane 5 Missionen. So rutschte dieser Fehler durch und wurde zu einem Disaster. Die heute vergessenen Peinlichkeiten der Ariane 5 endeten erst nach 14 Flügen, von denen nur 10 erfolgreich waren.

Den Report der ESA zum Absturz der ersten Ariane 5 gibt es hier.

Das beschwingte Ende der Delta III

Noch schlechter erging es der Delta III Rakete zwei Jahre später im Jahr 1998. Sie war als Nachfolger der Delta II geplant, mit doppelter Nutzlast. Dazu sollte eine effizientere “Centaur” Oberstufe zum Einsatz kommen. Die Centaur hatte sich längst bewährt. Ihr Triebwerk ist eine Variante der RL-10 Triebwerke, die schon seit den 60er Jahren in verschiedenen Raketen benutzt werden. Die erste Stufe benutzte das gleiche Triebwerke wie die Delta II. Es ist ein RS-27A Triebwerk, das in einer älteren Variante schon die Saturn 1 Raketen der Apollo Ära angetrieben hat. Neu waren nur die neun Feststoffbooster, die jeweils 50% mehr Schub lieferten.

1 / 2 / 3 / 4 / Auf einer Seite lesen

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.