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 plötzlich vom Kurs abkam und sich kurz darauf selbst zerstörte. Vier Cluster-Forschungssatelliten zur Untersuchung des Erdmagnetfelds gingen dabei verloren.
Die Software, die zur Kursabweichung führte, war unverändert und ohne Systemtests von der Vorgängerrakete Ariane 4 übernommen worden, obwohl sie nicht für die geänderte Flugbahn der Ariane 5 geeignet war und nach dem Abheben der Rakete ohnehin keinen Zweck erfüllte. Die Steuereinheit war redundant, jedoch wurde auf beiden Systemen die gleiche fehlerhafte Software betrieben.
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 Ariane 4 ausgewichen wurde. Ein neuer Satz von Cluster-Satelliten wurde vier Jahre nach dem Unglück mit russischen Sojus-Raketen gestartet.
Startvorbereitungen und Flug
Vorgeschichte
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.
Nutzlast
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]
Verlauf
Der Countdown verlief normal bis sieben Minuten vor Startbeginn (H0–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 H0+36 s, als sich die Rakete in einer Höhe von etwa 3700 m befand, verlief der Flug nominal. 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 Unglücksursache 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 H0+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.
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 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 worden waren. Bruchstücke der vier Cluster-Satelliten wurden ebenfalls geborgen, waren aber nicht mehr verwendbar.[9]
Fehlerursachen
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 Druckes beider Aktoren des Vulcain-Triebwerks, die in der Folge untersucht wurden. Auf den Fehlstart der Ariane 501 hatte diese Anomalie keinen Einfluss. Es wurden laut der öffentlichen Zusammenfassung des Berichts keine weiteren Schwächen oder externen Faktoren gefunden, die für den Fehlstart verantwortlich gewesen sein könnten.
INS-Software und Ausnahmebehandlung
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.
Simulationen und Tests
| An den betroffenen Systemen beteiligte Organisationen und Unternehmen[12] | |
|---|---|
| ESA | Auftraggeber |
| CNES | Technische Leitung |
| Aérospatiale zu EADS fusioniert |
Hauptauftragnehmer |
| Matra Marconi Space zu EADS Astrium fusioniert |
Steuerungseinheit |
| Sextant Avionique heute Thales Avionics |
Inertiale Navigationssysteme |
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.
Einordnung des Fehlers
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.[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. 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.[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 Unglücks als Programmfehler angezweifelt wurde, ist der Fehlstart der Ariane 5 ein oft zitiertes Beispiel für teure Softwarefehler. So etwa wurde das Unglück vom Technologiemagazin Wired zu den zehn „schlimmsten Bugs der Geschichte“ gezählt.[19]
Reaktionen und Folgen
Korrekturmaßnahmen
Die Untersuchungskommission nannte in der Zusammenfassung ihres Berichts mehrere Empfehlungen, um ein ähnliches Unglück 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.
Nachwirkungen
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.
Literatur
- 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)
- Jean-Jacques Lévy: Un petit bogue, un grand boum ! (Präsentation mit Ausschnitten aus dem unveröffentlichten Untersuchungsbericht und Teilen des Original-Quellcodes. PDF, 15,3 MB)
- 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 (Zusammenfassung des Untersuchungsberichts. PDF, 2,1 MB)
- Bashar Nuseibeh: Ariane 5: Who Dunnit? IEEE Software 14, 3 (May-June 1997): 15–16, ISSN 0740-7459 Ariane 5: Who Dunnit? (Memento vom 2. März 2012 im Internet Archive)
Weblinks
- V88 ARIANE 501 (Capcom Espace) (franz.) – Bericht über die Startkampagne, mit Video des Starts
Einzelnachweise
- 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
- P. Jorant: Ariane 5 Family, S. 5. AIAA 93-4131. AIAA Space Programs and Technologies Conference and Exhibit, Huntsville, AL, September 21–23, 1993
- Jean-Paul Dufour, Jean-François Augereau: Le programme Ariane-5 n’est pas remis en cause par la destruction du lanceur. Le Monde, 6 juin 1996
- Orye: Ariane 5: A Launcher for the 21st Century, S. 5
- William Huon: Ariane, une épopée européenne, S. 200. ETAI 2007, ISBN 978-2-7268-8709-7.
- C.P. Escoubet u. a. (Hrsg.): The Cluster and Phoenix Missions. Kluwer, Dordrecht 1997, ISBN 0-7923-4411-1.
- Lions u. a.: Ariane 5 Flight 501 Failure – Report by the Enquiry Board. Paris 1996
- 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
- De Dalmau, Gigou: Ariane-5: Learning from Flight 501 and Preparing for 502.
- Lions u. a.: Ariane 5 Flight 501 Failure – Report by the Enquiry Board, S. 3
- ESA/CNES: Immediate Post-Accident Analysis, Folie 9
- Ariane 5 Report Details Software Design Errors. Aviation Week & Space Technology, 19 Sep. 1996, S. 79–81, ISSN 0005-2175
- Space News vom 24–30 Juni 1996, ISSN 1046-6940
- ESA/CNES: Immediate Post-Accident Analysis, Folie 10
- Bashar Nuseibeh: Ariane 5: Who Dunnit?
- Le Lann: The Ariane 5 Flight 501 Failure – A Case Study in System Engineering for Computing Systems.
- Dowson: The Ariane 5 Software Failure.
- Ariane 501 & the Reliability Factor. Space Insurance Report 86 (July 1996), ISSN 0957-0063
- Simson Garfinkel: History’s Worst Software Bugs. Wired, 11. August 2005
- Philippe Lacan u. a.: ARIANE 5 – The Software Reliability Verification Process. In DASIA 98 Proceedings, S. 201–205. ESA Publications Division, Noordwijk 1998, ISBN 92-9092-688-0 (Online)
- CDRH Software Forensics Lab: Applying Rocket Science To Device Analysis. (Memento vom 24. Mai 2008 im Internet Archive) The Gray Sheet, 15. Oktober 2007, ISSN 1530-1214
- ESA Space Science: Cluster Overview