Ariane V88

Die Entwicklung eines neuen Schwerlastträgers als Nachfolger der erfolgreichen Ariane 4 wurde auf der ESA-Ministerkonferenz 1987 endgültig beschlossen. Die höhere Leistung der Ariane 5 sollte zum einen der steigenden Masse von kommerziellen Telekommunikationssatelliten gerecht werden und zum anderen den Start der Hermes-Raumfähre ermöglichen. Obwohl das Hermes-Programm 1992 abgebrochen wurde, wurde Ariane 5 im Hinblick auf eine mögliche bemannte Nutzung weiterentwickelt.[1] Für die qualifizierte Ariane-5-Rakete wurde je nach Oberstufe eine Zuverlässigkeit von 98–99 % angestrebt, entsprechend höchstens einem Fehlschlag je 50 bis 100 Starts.[2] Außerdem sollten die Startkosten der Ariane 5 gegenüber der Vorgängerrakete verringert werden. Da diese Anforderungen nicht durch eine Weiterentwicklung der Ariane 4 erfüllt werden konnten, musste die Ariane 5 größtenteils von Grund auf neu entwickelt werden.

Die Entwicklung der Ariane 5 fand im Auftrag der Europäischen Weltraumorganisation ESA statt, welche die technische und finanzielle Leitung der französischen Raumfahrtagentur CNES übergab. Den größten Beitrag zum Programm leistete Frankreich mit einer Beteiligung von 46 %.[3] Ursprünglich sollte der Qualifizierungsflug der Ariane 501 im Oktober 1995 stattfinden[4], wurde jedoch wegen Verzögerungen in der Entwicklung auf Juni des folgenden Jahres verschoben.

Ein Cluster-Satellit bei Tests

Die Nutzlast der Ariane 501 bestand aus vier Forschungssatelliten der Cluster-Mission mit einer Gesamtmasse von 4681 kg.[5] Das Cluster-Programm wurde während einer Ausschreibung der ESA für die nächste Reihe wissenschaftlicher Missionen 1982 vorgeschlagen und unter Beteiligung der NASA entwickelt. Das Ziel der Mission bestand darin, kleine räumliche und zeitliche Veränderungen der Erdmagnetosphäre und des erdnahen Sonnenwind-Plasmas dreidimensional zu untersuchen. Die vier Satelliten sollten von der Rakete in zwei Paaren in einer geostationären Transferbahn ausgesetzt werden und schließlich eine hochelliptische (HEO-) Bahn erreichen.[6]

Der Countdown verlief normal bis sieben Minuten vor Startbeginn (H₀–7 min), als er wegen nicht erfüllter Sichtbarkeitsbedingungen gestoppt wurde. Nach einer knappen Stunde wurde der Countdown wieder aufgenommen, und der Start fand um 9:34 Ortszeit (12:34 UTC) statt. Bis H₀+36 s, als sich die Rakete in einer Höhe von etwa 3700 m befand, verlief der Flug normal. In den folgenden Sekunden wich die Rakete von ihrem normalen Kurs ab, begann auseinanderzubrechen und sprengte sich selbst.

In den Tagen nach dem Start setzten der ESA-Generaldirektor Jean-Marie Luton und der Präsident der CNES, Alain Bensoussan, eine neunköpfige Untersuchungskommission unter der Leitung von Jacques-Louis Lions, Präsident der französischen Académie des sciences, ein. Das unabhängige Team sollte die Unfallursache feststellen, die Angemessenheit der Validierungsmethoden beurteilen, und Korrekturmaßnahmen aufzeigen. Die Kommission begann ihre Arbeit am 13. Juni 1996 und lieferte ihren Bericht am 19. Juli ab. Der veröffentlichten Zusammenfassung des Berichts zufolge kam es ab H₀+36 s zu folgender Kette von Ereignissen:[7]

Der Fehler hatte seine Ursache in einem Softwaremodul beider Inertialen Navigationssysteme (INS) der Steuerungseinheit, das für die Lageberechnung der Strapdown-Inertialplattform zuständig war. Bei der Umwandlung einer 64-Bit-Gleitkomma-Variablen in eine vorzeichenbehaftete 16-Bit-Ganzzahl kam es zu einem arithmetischen Überlauf. Diese Variable, E_BH (bias horizontal, „horizontale Ausrichtung“), gab die Ausrichtungspräzision der Inertialplattform an und hing mit der horizontalen Geschwindigkeit der Rakete zusammen. Die Codezeile, die zum Fehler führte, lautete wie folgt:

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S
                                   ((1.0/C_M_LSB_BH) *
                                   G_M_INFO_DERIVE(T_ALG.E_BH)))

Der unbehandelte Operandenfehler (Operand Error) im Ada-Programm führte zum Ausfall (Übergang in den „degraded mode“) des Reserve-INS und kurz danach des Haupt-INS, und damit zum vollständigen Verlust von Lenk- und Lageinformationen. Von diesem Zeitpunkt an lieferten die INS an den Flugcomputer keine eigentlichen Flugdaten mehr, sondern im Wesentlichen nur noch Diagnoseinformationen.

Der Bordcomputer interpretierte die INS-Diagnoseinformationen als normale Flugdaten und stellte fälschlicherweise eine große Abweichung von der Flugbahn fest. Daraufhin sendete der Computer an die Düsen der beiden Feststoff-Booster und kurz darauf an das Vulcain-Triebwerk der Hauptstufe das Signal zur Schwenkung, um die vermeintliche Abweichung zu korrigieren. Durch die Schwenkung der Düsen wich die Rakete mit über 30 Grad pro Sekunde von ihrem Kurs ab.[8] Da sich die Rakete noch in den dichteren Schichten der Erdatmosphäre befand, war sie dem großen Angriffswinkel der Luftströmung nicht gewachsen und begann angesichts der hohen aerodynamischen Kräfte auseinanderzubrechen. Nachdem die Verbindungen zwischen den Feststoffboostern und der Hauptstufe abrissen, leitete die Rakete – wie in diesem Fall vorgesehen – die automatische Selbstzerstörung ein und explodierte. Anschließend aktivierte zusätzlich die Bodenkontrolle den Befehl zur Sprengung, wenngleich die Rakete zu diesem Zeitpunkt bereits zerstört war.

Zeitstrahl mit wichtigen Flugereignissen

Zum Zeitpunkt der Explosion befand sich die Rakete in 4000 m Höhe, etwa einen Kilometer östlich der Startrampe. Die Trümmer der explodierten Trägerrakete verteilten sich über eine Fläche von 5 km × 2,5 km; die durch die Explosion entstandene Wolke und die Abgase trieben in Richtung des Ozeans, wo sie sich allmählich auflösten.[9] Einige Bruchstücke fielen nahe dem Startplatz ELA-3 herunter, dieser selbst blieb unversehrt.[3] Menschen kamen bei dem Unfall nicht zu Schaden.

Trotz des sumpfigen Geländes konnten einige Systeme geborgen werden. Dazu zählten die beiden INS, die Daten enthielten, welche nicht per Telemetrie empfangen worden waren. Bruchstücke der vier Cluster-Satelliten wurden ebenfalls geborgen, waren aber nicht mehr verwendbar.[9]

Geborgenes Bruchstück des Satelliten-Tragwerks der Ariane 501

Das Design des bei Ariane 5 verwendeten INS wurde fast unverändert von Ariane 4 übernommen.[10]

Der Überlauf der Variablen E_BH hing damit zusammen, dass die horizontale Geschwindigkeit der Inertialplattform aufgrund des größeren Nick-Winkels zu Beginn des Flugs fünfmal höher als bei Ariane 4 war. Die Software selbst wurde zwar vor dem Flug getestet, allerdings mit einer Parameterauswahl, welche die Fehlerbedingungen nicht erfasste.[11] Die Untersuchungskommission kritisierte, dass die Systemspezifikation des INS die aus der Software resultierenden Einschränkungen der Betriebsbedingungen nicht dokumentierte.

Das Softwaremodul, das den Fehler verursachte, lieferte sowohl bei Ariane 5 als auch bei der Vorgängerrakete nur vor dem Start sinnvolle Daten und erfüllte danach keinen Zweck mehr. Dennoch lief das Modul noch in den ersten 40 Sekunden des Flugs weiter, was auf eine Anforderung von Ariane 4 zurückging. Das Weiterlaufen der Prozedur diente dazu, die Plattform im Falle eines kurz vor dem Start angehaltenen Countdowns schnell wieder neu auszurichten. Auf Ariane 5 treffen diese Erwägungen nicht zu, da der Träger eine andere Vorbereitungssequenz hat.

Eine Analyse der Ausrichtungsprozedur identifizierte sieben Variablen, deren Berechnung unter Umständen einen Operandenfehler auslösen konnte. Vier der Variablen wurden durch eine Ausnahmebehandlung für Operandenfehler geschützt. Da die maximale Auslastung des INS-Computers laut den technischen Vorgaben 80 % nicht überschreiten durfte, wurde von verschiedenen Projektpartnern einvernehmlich beschlossen, die restlichen drei Variablen inklusive E_BH ungeschützt zu lassen. Im Quellcode fand sich kein Kommentar zu dieser Entscheidung. Analysen hatten ergeben, dass die drei restlichen Variablen entweder begrenzte physikalische Auswirkungen hatten oder ein großer Sicherheitsspielraum vorhanden war. Dies stellte sich im Falle von E_BH als falsch heraus, sodass gemäß Spezifikation ohne Ausnahmebehandlung der INS-Prozessor heruntergefahren wurde. Die Kommission war der Auffassung, dass die Auswirkungen von Softwareausnahmen begrenzt werden müssten und die INS jederzeit wenigstens Schätzwerte der Daten hätten liefern sollen.

Das Verhalten der ungeschützten Variablen wurde nicht anhand von geplanten Flugbahndaten der Ariane 5 simuliert. Wenn das INS mit Hilfe eines Bewegungssimulators und von Flugdaten simuliert worden wäre, hätte der Fehler entdeckt werden können. Tatsächlich wurden nach einvernehmlicher Entscheidung die Flugbahndaten der Ariane 5 nicht in die Anforderungen- und Spezifikationsdokumente des INS aufgenommen.

Der Hauptauftragnehmer des Ariane-5-Projekts, Aérospatiale, besaß eine Einrichtung zur Simulation von Flugkomponenten (installation de simulation fonctionnelle, ISF), mit der viele Systeme der Rakete in einer Closed-Loop-Simulation getestet wurden. Ein Antrag, die beiden INS einer solchen Simulation zu unterziehen, wurde von der CNES aus finanziellen Gründen abgelehnt.[13] Letztendlich wurden lediglich die Schnittstellen zum Bordcomputer getestet. Als Begründung wurde angegeben, dass die INS seit 1994 erfolgreich in 23 Ariane-4-Starts benutzt wurden[14] und somit eine gesonderte Qualifikation überflüssig sei. Zum anderen hätte die Leistung der ISF für eine präzise Simulation nicht ausgereicht. Die Untersuchungskommission stufte diese Entscheidung als riskant ein und stellte fest, dass selbst eine unpräzise Simulation sinnvoll gewesen wäre, um die Systemintegration zu testen.

Die Untersuchungskommission stellte zusammenfassend fest, dass der Unfall auf einen „systematischen Software-Designfehler“ zurückging. Diese Einschätzung wird von einigen Veröffentlichungen nicht geteilt, da sich das Computerprogramm des INS die ganze Zeit gemäß Spezifikation und Design verhielt. Tatsächlich lassen sich je nach Standpunkt verschiedene Fehlerursachen feststellen, deren Behebung den Fehlstart jeweils vermieden hätte.[15]

Laut Gérard Le Lann hätte die Kommission Softwaretechnik und Systems Engineering verwechselt.[16] Die unvollständige Spezifikation des INS sei als fehlerhaftes Systemdesign zu betrachten. Auch der zu geringe Speicherplatz, der für das Ganzzahl-Resultat der Umwandlung der Variable E_BH verwendet wurde, sei kein Softwarefehler, sondern ein Dimensionierungsproblem des Systems. Er weist darauf hin, dass es zum gleichen Fehler gekommen wäre, wenn alle Softwaremodule als Hardware implementiert worden wären.

Auch Mark Dowson sieht im Fehler zumindest ein Systems-Engineering-Problem, da das operative Umfeld der Software nicht ausreichend berücksichtigt wurde. Der Unfall sei ein Beispiel dafür, dass die „politischen“ Aspekte des Entwicklungszyklus nicht vernachlässigt werden sollten. Ein guter Entwicklungsprozess solle nicht nur regulieren, wie Systeme entworfen und entwickelt werden, sondern auch, wie Entscheidungen zum Design und Entwicklung auf höherer Ebene getroffen werden.[17]

Im Nachhinein kritisierte die britische Zeitschrift Space Insurance Report die wenig aussagekräftigen Zahlen zur geplanten Zuverlässigkeit der Rakete. Auch sei die Entscheidung, nicht versicherte Nutzlasten mit einer ungetesteten Trägerrakete zu starten, riskant gewesen.[18]

Obwohl die Charakterisierung des Unfalls als Programmfehler angezweifelt wurde, ist der Fehlstart der Ariane 5 ein oft zitiertes Beispiel für teure Softwarefehler. So etwa wurde der Unfall vom Technologiemagazin Wired zu den zehn „schlimmsten Bugs der Geschichte“ gezählt.[19]

Die Untersuchungskommission nannte in der Zusammenfassung ihres Berichts mehrere Empfehlungen, um einen ähnlichen Unfall künftig zu vermeiden. So sollten während des Flugs nicht benötigte Softwarefunktionen direkt nach dem Start deaktiviert werden und Systeme eine vollständige Closed-Loop-Simulation durchlaufen, idealerweise unter Einbeziehung von Flugbahndaten. Außerdem sollten die Auswirkungen von Ausnahmen begrenzt und gegebenenfalls auf Ersatzlösungen ausgewichen werden, sodass kein Sensor aufhört, wenigstens Schätzwerte zu liefern. Begründungsakten (Justification Files) sollte gleich viel Aufmerksamkeit zukommen wie Code, und beide sollten stets konsistent gehalten werden.

Die Kommission empfahl außerdem die Einberufung von Experten, um eine Prozedur zur Qualifikation von Software auszuarbeiten. Für jedes Gerät, das Software enthält, sollte ein gesondertes Software-Qualifikationsreview stattfinden, und projektexterne Personen systematisch die Stichhaltigkeit der bei Reviews hervorgebrachten Argumente überprüfen. Schließlich wurde empfohlen, die Zusammenarbeit der Projektbeteiligten transparenter, mit klaren Befugnissen und Verantwortungen, zu organisieren.

Einige der Empfehlungen der Untersuchungskommission wurden im Nachhinein umgesetzt. So etwa führte Aérospatiale eine Komplettüberprüfung der INS- und Flugsoftware durch. Dabei fand unter anderem eine statische Code-Analyse mittels abstrakter Interpretation von insgesamt 90.000 Zeilen Ada-Code statt.[20] Diese Tests zählten zu den ersten größeren statischen Analysen eines industriellen Computerprogramms und trugen zu einer weiteren Verbreitung statischer Analyseverfahren bei.[21] In der Flugsoftware wurde der ursächliche Fehler korrigiert, indem E_BH als 32-Bit-Ganzzahl deklariert wurde.

Startplatz ELA-3 der Ariane 5 im Centre Spatial Guyanais

Der Gesamtverlust von Rakete und Nutzlast betrug etwa 1,9 Milliarden Francs (290 Millionen Euro).[16] Für die Cluster-Mission zog der Fehlstart von V88 lange Verzögerungen nach sich. Zunächst erwog die ESA, aus Ersatzteilen einen einzigen Satelliten, „Phoenix“ genannt, zu bauen. Nachdem sich jedoch die Erkenntnis durchsetzte, dass mit nur einem Satelliten die wissenschaftlichen Ziele der Mission nicht erfüllt werden konnten, wurden weitere drei Satelliten neu gebaut. Die Satelliten wurden paarweise im Juli und August 2000 von einer Sojus-Fregat-Rakete vom russischen Weltraumbahnhof Baikonur aus gestartet.[22]

Nach dem Fehlstart bekräftigte Frankreichs delegierter Minister für Postwesen, Telekommunikation und Raumfahrt, François Fillon, sein Vertrauen in das Ariane-Programm.[3] Vorläufig ließen sich die Verspätungen im Ariane-5-Programm durch die Vorgängerrakete ausgleichen; bereits elf Tage nach V88 fand ein erfolgreicher Start einer Ariane 4 statt.

Der zweite Qualifizierungsflug einer Ariane-5-Rakete fand im Oktober 1997 statt, wobei nur Satellitenattrappen sowie der Studentensatellit YES transportiert wurden. Der Flug war nur ein Teilerfolg, da durch vorzeitige Abschaltung der Triebwerke die Nutzlasten in einem zu niedrigen Orbit ausgesetzt wurden. Dieser Fehler konnte im Anschluss an den Flug erklärt und behoben werden. Dennoch litt das Vertrauen der Kunden in den neuen Träger, sodass die Ariane 4 noch bis 2003 gestartet wurde.