Ariane V88

V88 (V für franz. vol, „Flug“) war die Startnummer des Erstflugs der europäischen Schwerlast-Trägerrakete Ariane 5 am 4. Juni 1996. Die Rakete trug die Seriennummer 501. Der Flug endete etwa 40 Sekunden nach dem Start, als die Rakete nach einer Ausnahmesituation in der Software der Steuereinheit vom Kurs abkam und sich kurz darauf selbst zerstörte. Vier Cluster-Forschungssatelliten zur Untersuchung des Erdmagnetfelds gingen dabei verloren.

Der Fehlschlag mit einem Gesamtverlust von etwa 290 Millionen Euro führte zu einer einjährigen Verzögerung des Ariane-5-Programms, weshalb vorläufig auf die Vorgängerrakete Ariane 4 ausgewichen wurde. Die Cluster-Satelliten konnten erst vier Jahre nach dem Unglück gestartet werden.

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] Bei geringeren Startkosten wurde als Zuverlässigkeit je nach Oberstufe 98–99 % angestrebt, entsprechend höchstens einem Fehlschlag je 50 Starts.^[2] Da diese Eigenschaften nicht durch eine Weiterentwicklung der Ariane 4 erzielt werden konnten, handelte es sich bei der Ariane 5 im Wesentlichen um eine Neuentwicklung.

Die Entwicklung der Ariane 5 fand im Auftrag der Europäischen Weltraumorganisation ESA statt, die 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.

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 7 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 9h34 Ortszeit (12h34 UTC) statt. Bis H₀+36 s, als sich die Rakete einer Höhe von etwa 3700 m befand, verlief der Flug nominal. In den folgenden Sekunden wich die Rakete von ihrem normalen Kurs ab, brach auseinander und explodierte.

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 ein. Das unabhängige Team sollte die Unglücksursache feststellen, die Angemessenheit der Validierungsmethoden beurteilen, und Korrekturmaßnahmen aufzeigen. Die Kommission begann ihre Arbeit am 13. Juni 1996 und veröffentlichte ihren Bericht am 19. Juli. Dem Bericht 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 Ausrichtung der Strapdown-Inertialplattform zuständig war. Bei der Umwandlung einer 64-Bit-Gleitkomma-Variable in eine vorzeichenbehaftete 16-Bit-Ganzzahl kam es zu einem arithmetischen Überlauf. Diese Variable, BH (biais horizontal, „horizontale Ausrichtung“), gab die Ausrichtungspräzision der Inertialplattform an und hing mit der horizontalen Geschwindigkeit der Rakete zusammen.

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 kompletten Verlust von Lenk- und Lageinformationen. Von diesem Zeitpunkt an lieferten die INS an den Flugcomputer keine normalen Flugdaten mehr, sondern im Wesentlichen 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] Die Rakete war 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.

Zum Zeitpunkt der Explosion befand sich die Rakete in 4000 m Höhe, etwa 1 km östlich der Startrampe. Die Trümmer der explodierten Trägerrakete verteilten sich über eine Fläche von 5×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 des Startplatzes ELA-3 herunter, dieser selbst blieb unversehrt.^[3] Menschen kamen bei dem Unglück 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 wurden. Bruchstücke der vier Cluster-Satelliten wurden ebenfalls geborgen, waren aber nicht mehr flugtauglich.^[9]

Der Fehler konnte in einer Simulation, in der die Flugsoftware mit den tatsächlichen Flugdaten ausgeführt wurde, reproduziert werden. Die Kommission fand außerdem abnorme Schwankungen des hydraulischen Druck beider Aktuatoren des Vulcain-Triebwerks, die in der Folge untersucht wurden. Auf den Fehlstart der Ariane 501 hatte diese Anomalie keinen Einfluss. Es wurden keine weiteren Schwächen oder externen Faktoren gefunden, die für den Fehlstart verantwortlich gewesen sein könnten.

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

Der Überlauf der Variable 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, die 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.

Bei einer Analyse der Ausrichtungsprozedur wurden sieben Variablen identifiziert, die einen Operandenfehler riskierten. Vier der Variablen wurden durch eine Ausnahmebehandlung für Operandenfehler geschützt. Da die maximale Auslastung des INS-Computers auf 80 % beschränkt war, wurde von verschiedenen Projektpartnern einvernehmlich beschlossen, die restlichen drei Variablen inklusive 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 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 geliefert hätten 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 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. Die beiden INS sollten zunächst ebenfalls diese Simulation durchlaufen, die Entscheidung wurde jedoch später zurückgezogen, sodass lediglich die Schnittstellen zum Bordcomputer getestet wurden. Dies lag zum einen daran, dass die INS seit 1994 erfolgreich in 23 Ariane-4-Starts benutzt wurden^[13] und somit eine gesonderte Qualifikation als überflüssig betrachtet wurde. 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 das Unglück 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.^[14]

Laut Gérard Le Lann hätte die Kommission Softwaretechnik und Systems Engineering verwechselt.^[15] 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 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. Das Unglück 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.^[16]

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.^[17]

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

Die Untersuchungskommission nannte in ihrem Bericht mehrere Empfehlungen, um ein ähnliches Unglück 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 stets konsistent gehalten werden.

Die Kommission empfahl außerdem die Einberufung von Experten, um eine Prozedur zur Qualifikation von Software ausarbeiten. 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 wurden im Nachhinein umgesetzt; so etwa fand eine Komplettüberprüfung der Software statt.^[19]

Der Gesamtverlust von Rakete und Nutzlast betrug etwa 1,9 Milliarden Francs (290 Millionen Euro).^[15] 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-Fragat-Rakete vom russischen Weltraumbahnhof Baikonur aus gestartet.^[20]

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 ab 2004 das für die Vermarktung zuständige Unternehmen Arianespace Zuschüsse durch die ESA erhalten musste.^[21] Seit dem letzten Fehlschlag im Dezember 2002 fanden über 20 erfolgreiche Ariane-5-Raketenstarts in Folge statt (Stand: 2009).

• J. de Dalmau, J. Gigou: Ariane-5: Learning from Flight 501 and Preparing for 502. ESA Bulletin 89 (Feb. 1997), ISSN 0376-4265 (Online)
• Mark Dowson: The Ariane 5 Software Failure. ACM SIGSOFT Software Engineering Notes 22, 2 (March 1997): 84, ISSN 0163-5948
• Gérard Le Lann: The Ariane 5 Flight 501 Failure – A Case Study in System Engineering for Computing Systems. INRIA Research Report RR-3079 (1996) (PDF, 140 KB)
• Jacques-Louis Lions u. a.: Ariane 5 Flight 501 Failure – Report by the Enquiry Board. Paris, 19 July 1996; ESA Directorate of Launchers, CNES: Flight A501: Immediate Post-Accident Analysis (PDF, 2,1 MB)
• Bashar Nuseibeh: Ariane 5: Who Dunnit? IEEE Software 14, 3 (May-June 1997): 15–16, ISSN 0740-7459 (PDF, 440 KB)

• V88 ARIANE 501 (Capcom Espace) (franz.) – Bericht über die Startkampagne, mit Video des Starts

1. ↑ R. Orye: Ariane 5: A Launcher for the 21st Century, S. 2. AIAA 94-4653. AIAA Space Programs and Technologies Conference, Huntsville, AL, September 27–29, 1994
2. ↑ P. Jorant: Ariane 5 Family, S. 5. AIAA 93-4131. AIAA Space Programs and Technologies Conference and Exhibit, Huntsville, AL, September 21–23, 1993
3. ↑ ^{a b c} Jean-Paul Dufour, Jean-Franois Augereau: Le programme Ariane-5 n’est pas remis en cause par la destruction du lanceur. Le Monde, 6 juin 1996
4. ↑ Orye: Ariane 5: A Launcher for the 21st Century, S. 5
5. ↑ William Huon: Ariane, une épopée européenne, S. 200. ETAI 2007, ISBN 978-2-7268-8709-7
6. ↑ C.P. Escoubet u. a. (Hrsg.): The Cluster and Phoenix Missions. Kluwer, Dordrecht 1997, ISBN 0-7923-4411-1
7. ↑ Lions u. a.: Ariane 5 Flight 501 Failure – Report by the Enquiry Board.
8. ↑ I-Shih Chang: European Space Launch Failures, S. 10. AIAA 2000-3574. 36th AIAA/ASME/SAE/ASEE Joint Propulsion Conference and Exhibit, Huntsville, AL, July 16–19, 2000
9. ↑ ^{a b} De Dalmau, Gigou: Ariane-5: Learning from Flight 501 and Preparing for 502.
10. ↑ Lions u. a.: Ariane 5 Flight 501 Failure – Report by the Enquiry Board, S. 3
11. ↑ ESA/CNES: Immediate Post-Accident Analysis, Folie 9
12. ↑ Ariane 5 Report Details Software Design Errors. Aviation Week & Space Technology, 19 Sep. 1996, S. 79–81, ISSN 0005-2175
13. ↑ ESA/CNES: Immediate Post-Accident Analysis, Folie 10
14. ↑ Bashar Nuseibeh: Ariane 5: Who Dunnit?
15. ↑ ^{a b} Le Lann: The Ariane 5 Flight 501 Failure – A Case Study in System Engineering for Computing Systems.
16. ↑ Dowson: The Ariane 5 Software Failure.
17. ↑ Ariane 501 & the Reliability Factor. Space Insurance Report 86 (July 1996), ISSN 0957-0063
18. ↑ Simson Garfinkel: History’s Worst Software Bugs. Wired, 11. 08. 2005
19. ↑ L. Jourdainne: Ariane Launch System: 20 Years of Operational Revolution, S. 9. IAF-00-V.5.01. 51st International Astronautical Congress, Rio de Janeiro, Brazil, October 2–6, 2000
20. ↑ ESA Space Science: Cluster Overview
21. ↑ ESA Information Note 10-2003: Access to space today and tomorrow: what does Europe need?

Dieser Artikel nimmt am Schreibwettbewerb teil. Bitte hilf mit, ihn zu verbessern!