Softwarefehler in der Raumfahrt: In den Neunzigern stürzte alles ab
Die neunziger Jahre waren die finanziell verlustreichsten in der Raumfahrt. Eine Mission nach der anderen scheiterte. Es wurden neue Raketen eingeführt, und sie explodierten oder gerieten außer Kontrolle – und die Nutzlast war gestrandet. Raumsonden flogen zum Mars und wurden nie mehr gehört oder gesehen. Die Ursache waren Softwarefehler durch Bereichsüberschreitungen von Variablen und Kommafehler beim Abtippen von Konstanten. Das war ein schmerzhafter Lernprozess für die Raumfahrtorganisationen, wie unsere Liste der verlorenen Missionen zeigt.
Der erste Flug der Ariane 5
1996 startete die Esa ihre neue Ariane-5-Rakete zum ersten Mal. Anders als ursprünglich geplant, war die Ariane 5 keine verbesserte Ariane 4, sondern eine völlig neue Rakete. Kein Teil war mehr gleich. Jeder der beiden Feststoffbooster hatte allein schon mehr Schub als die größte Variante der Ariane 4. Bei 66 Prozent mehr Startmasse hatte die Ariane 5 einen um 140 Prozent größeren Schub. Sie hob viel schneller ab und es wirkten im Flug 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 hatte und die Neuentwicklung viel teurer gewesen wäre. Die Ariane 5 sollte trotzdem von Anfang an so zuverlässig sein wie die Ariane 4. Schon beim ersten Flug sollte sie vier Cluster-Satelliten(öffnet im neuen Fenster) im Wert von 370 Millionen US-Dollar tragen.
37 Sekunden bis zur Selbstzerstörung
Nur 37 Sekunden nach dem Start musste die Rakete aber gesprengt werden. Die viel größeren Querbeschleunigungen wurden ihr zum Verhängnis. Der Messwert der Beschleunigung wurde als (signed) 16-bit Integer weitergegeben. Als die den magischen Wert von 32768 übersprang und zur -32767 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 und die Rakete drehte sich quer zur Flugrichtung.
Die Variable wurde aus Performancegründen aus der Kontrolle auf Wertbereichsüberschreitung herausgenommen. 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 Prinzip "Test as you fly, fly as you test" wohl erkannt worden. Anstatt mit Daten aus dem echten Trägheitsnavigationssystem der Rakete war das Steuersystem aber nur mit Werten aus einer Simulation getestet worden. Und selbst diese Simulationen folgten nicht der eigentlichen Flugbahn der neuen Ariane-5-Missionen. So rutschte dieser Fehler durch und verursachte das Desaster. Die heute vergessenen Peinlichkeiten der Ariane 5 endeten nach 14 Flügen, von denen nur zehn erfolgreich waren. Den Report der Esa zum Absturz der ersten Ariane 5 gibt es hier(öffnet im neuen Fenster).
Das beschwingte Ende der Delta III
Noch schlechter erging es der Delta-3-Rakete zwei Jahre später im Jahr 1998. Sie war als Nachfolger der Delta 2 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 sechziger Jahren in verschiedenen Raketen benutzt werden. Die erste Stufe nutzte das gleiche Triebwerk wie die Delta 2. 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 Prozent mehr Schub lieferten.
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 2 übernommen, schließlich funktionierte sie zuverlässig. Die neue Rakete wurde mit großem Selbstvertrauen und einem kommerziellen Nachrichtensatelliten, Galaxy 10(öffnet im neuen Fenster), gestartet.
Der Flug war zunächst erfolgreich, aber 75 Sekunden nach dem Start geriet die Rakete in Schräglage zur Flugrichtung und musste wie die Ariane 5 gesprengt werden(öffnet im neuen Fenster).
Die hydraulischen Steuersysteme der Booster-Raketen 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 stehenblieben.
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 2. Wegen der Ähnlichkeit der beiden Raketen wurden aber keine eigenen Simulationen mit der Delta 3 durchgeführt. So groß war die Ähnlichkeit dann aber doch nicht, wie Computersimulationen erst nach dem Unfall zeigten. Die Lösung war letztlich ganz einfach. Die 4 Hz wurden zu den Frequenzen in Rollrichtung hinzugefügt, die das System bei den Korrekturmanövern ignorieren sollte.
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-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(öffnet im neuen Fenster).
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(öffnet im neuen Fenster) 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(öffnet im neuen Fenster) 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(öffnet im neuen Fenster) (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.
Weniger ist manchmal zuverlässiger
Mit der beschränkten Rechenleistung früherer Jahre hätte es dieses Problem nie gegeben. Die exponentiell wachsende Rechenleistung der Hardware ermöglichte erst den Luxus, solche unnötigen Programmteile auszuführen. Es war also keine schlechtere Qualitätskontrolle nötig, um diese Fehler herbeizuführen. Die Qualitätskontrolle musste sich um immer mehr Funktionen in der Software kümmern, womit Fehler leichter durchkamen. Inzwischen hat sich in der Programmierung eine gewisse Askese durchgesetzt und die Testverfahren wurden verbessert. Dazu gehören Verfahren wie die systemtheoretische Prozessanalyse(öffnet im neuen Fenster) (STPA).
In der Praxis lief das alles auf eine engere Integration der Softwareentwickler in den Rest der Entwicklung hinaus. Bis dahin wurde die Softwareentwicklung als alleinstehender Teil der Entwicklung betrachtet. Das ging so weit, dass Software nur als ein einziger Punkt in der Fehleranalyse auftauchte. Die Anforderungen an die Software wurden klarer formuliert und strukturiert. Damit wurden sie für die Softwareentwickler besser zugänglich und konnten auch besser getestet werden.
Inzwischen stehen wieder die Probleme der mechanischen Hardware im Mittelpunkt. Wegen der hohen Kosten waren Vereinfachungen in den konservativen Verfahren der Fehlerkontrolle dort notwendig. Diese Vereinfachungen führten ihrerseits wieder zu neuen Fehlern, wie zuletzt bei Orbital Sciences und SpaceX.
- Anzeige Hier geht es zu Die Geschichte der Raumfahrt bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.