(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.
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.
Am Mars gescheitert
Das größte Echo in der Öffentlichkeit bekam diese Softwareseuche aber durch zwei gescheiterte Marsmissionen. Der Absturz des Mars Climate Orbiters am 23. September 1999 ist inzwischen legendär. Die Bodenkontrolle sendete Daten in Poundforce, aber die Software des Orbiters interpretierte sie als Angaben in SI-Einheiten, in Newton. Entsprechend falsch war die Flugbahn und der Mars Climate Orbiter stürzte auf den Planeten.
Den Schlusspunkt dieser peinlichen Serie von Fehlern setzte dann der Mars Polar Lander am 3. Dezember 1999. Die Bremsdüsen der Sonde mussten abschalten, sobald der Lander die Oberfläche berührt. 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 auch in der Dokumentation der Landerhardware. Aber diese Warnungen kamen nicht bei den Programmierern an, weshalb die Software keine Routine enthielt, die dieses falsche Signal ausfiltert.
Zu viel Rechenleistung brachte zu viel Komplexität
Diese Fehler waren ein Phänomen, das in den 90er Jahren plötzlich auftauchte. Über Jahrzehnte funktionierte die Software weitgehend zuverlässig, die von Programmierern abgeliefert wurde. 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 legendär war. Die Fehler mussten untersucht werden.
Wie zu erwarten war, zeigten die Untersuchungen (zweiter Link) eine Reihe von Nachlässigkeiten in allen Bereichen. Es fängt mit Kritik am Management und der Verteilung von Verantwortung an. Es geht 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. Aber beim Zusammenspiel von Komponenten stecken die Bugs im Detail. Gerade diese Details fehlen aber, wenn ein Testsystem nur simuliert wird, anstatt die finale Hardware zu benutzen. Hinter diesen Nachlässigkeiten wurden verschieden Gründe vermutet. Sparzwänge standen ganz oben auf der Liste, genauso wie übertriebenes Selbstvertrauen. Beide hatten sicherlich einen Anteil.
Das erklärt aber nicht, warum die selbe Art von Problemen parallel in der NASA, der ESA, US-Militärmissionen und kommerziellen Missionen auftauchen. 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 Performancegrü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 entwickelt, wurde alte Software erweitert.
Weniger ist zuverlässiger
Mit der beschränkten Rechenleistung früherer Jahre, hätte es dieses Problem nie gegeben. Die exponentiell wachsende Rechenleistung der Hardware erlaubte erst den Luxus, solche unnötigen Programmteile auszuführen. Es war also keine schlechtere Qualitätskontrolle nötig, um diese Fehler zu erlauben. Die Qualitätskontrolle musste sich um immer mehr Funktionen in der Software kümmern, womit Fehler leichter durch kamen. Inzwischen hat sich in der Programmierung eine gewisse Askese durchgesetzt und die Testverfahren wurden verbessert. Dazu gehören Verfahren wie die die systemtheoretische Prozessanalyse (STPA).
In der Praxis lief das alles auf eine engere Integration der Softwareentwickler in den Rest der Entwicklung der Hardwareentwicklung hinaus. Bis dahin wurde die Softwareentwicklung als alleinstehender Teil der Entwicklung betrachtet. Das ging soweit, dass in der Fehleranalyse der Punkt “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.
Schmerzhafte Lektionen
Unter Schmerzen entstand ein neuer Respekt für die Probleme von Softwareentwicklung. Danach wurde sie in der Fehleranalyse zum ersten mal komplex dargestellt und nicht mehr als ein einziger möglicher Fehler betrachtet. Es gab eine bessere Strukturierung der Softwareentwicklung, mit besserer Übersicht und eigenem Management. Die Kommunikation wurde verbessert den Softwareingenieuren eine höhere Priorität bei der Meldung von Problemen vor dem Start eingeräumt. Erprobte Software in einem neuen System wurde nicht mehr automatisch als zuverlässig angesehen, sondern als anfällig für Probleme im Kontext eines neuen Systems.
Zumindest führten die schmerzenhaften Verluste dazu, dass die einfachen Softwarefehler der späten 90er seit dem nicht wieder auftraten. 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 sorgen ihrerseits wieder für neue Fehler, wie zuletzt bei Orbital Sciences und SpaceX. Möglicherweise ist das auch ein Blick in die weitere Entwicklung bei der Software. Dann käme nach einem Exzess akribischer Kontrolle, konservativer Systeme und explodierender Kosten wieder eine Phase der Einsparungen, in der alte Fehler zurück kommen. Wir werden es in einigen Jahren oder Jahrzehnten sehen.
Kommentare (2)