Der Fehlschlag der Ariane 501 (Ariane 5 Jungfernflug)

Da das Thema in den Kommentaren zum Blog auftauchte und als seltsame Parallelität ich auch eine Anfrage eines Journalisten zum missglückten Jungfernflug bekam, für alle die es schon wieder vergessen haben oder noch gar nicht wissen (Fluch der späten Geburt) hier nochmal die Geschichte des Ariane 5 Fehlschlags.

Ariane 5 hob nach einigen Verzögerungen problemlos zum Jungfernflug am 4.6.1996. Bis 37 Sekunden nach dem Start funktionierte alles einwandfrei, dann schwenkte die Rakete abrupt. Sie war in etwa 4000 m Höhe und dieser Schwenk führte dazu, dass nach 39 s die Nutzlastspitze abriss, als die Rakete sich um 20 Grad gegen die Flugrichtung neigte, was von den Sicherheitsschaltungen registriert wurde, diese lösten dann das Selbstzerstörungsprogramm aus und sprengten die Rakete. Wie konnte es zu diesem katastrophalen Schwenk kommen, denn Ariane 5 wies bis zu diesem Zeitpunkt keinerlei Abweichung von der nominalen Bahn auf?

Sehr bald konzentrierten sich die Ermittlungen auf das Inertialsystem der Rakete, welche dem Bordcomputer sagt wo die Rakete gerade ist und in welche Richtung sie mit welcher Geschwindigkeit fliegt. Das SRI genannte System (Systemè Reference Interialè) besteht aus einer Inertialplattform aus Ringlasergyros, Beschleunigungsmesser und einem eigenen Computer. Es war redundant vorhanden und übergibt seine Daten dem eigentlichen Bordcomputer (OBC: OnBoard Computer). Eine Plattform SRI 1 ist aktiv, die andere steht im Hot-Standby, arbeitet also vom Start an und absolviert dasselbe Programm. Das erlaubt es dem Bordcomputer beim Verzagen von SRI 1 auf SRI 2 umzuschalten. Analog ist auch der OBC redundant vorhanden.

Das SRI ist im Prinzip das gleiche wie das von Ariane 4. Es wurde weitgehend unverändert übernommen, das galt auch für die Software. Das Inquiry Board konnte nun durch Untersuchung der Telemetrie, aber auch weil man die beiden Plattformen SRI1 und SRI2 aus dem Dschungel bergen konnte, den Vorfall rekonstruieren.

Ursache war ein Softwaremodul, das man von der Ariane 4 übernahm. Es hatte dort eine wichtige Operation. Die Rakete muss beim Start einen Punkt im All erreichen. Dieser Punkt verschiebt sich wegen der Rotation der Erde laufend. Die Ausrichtung der Trägheitsplattform ist ein komplizierter Vorgang der 45 Minuten dauert. Sie werden daher als letztes freigegeben, bei einem Ariane 4 Start erst 9 Sekunden vor der Zündung der Triebwerke. Wenn nun der Countdown in den letzten Sekunden abgebrochen wird man aber noch einen Startversuch unternehmen könnte, dann würde das scheitern weil die Neuausrichtung der Trägheitsplattform zu lange dauert und die Startfenster meist nur eine stunde lang dauern. Dafür lief eine Software „Alignment“ nach dem Freigeben, das den Bordcomputer mit Statusinfomationen über die Bahn unterrichtete, basierend auf der momentanen Ausrichtung der Plattform und den Einflüssen (der Erdrotation). Sie lief 50 Sekunden lang, das war die Zeit die die Missionskontrolle brauchte um nach einem Startabbruch wieder die Kontrolle über die Rakete zu übernehmen. Hob Ariane 4 ab, so war die Ausgabe nutzlos, wurde aber nach wie vor zum OBC übermittelt. Die Software bewährte sich: es kam einmal vor das ein Ariane 4 Start in letzter Sekunde abgebrochen wurde, das war V33 im Jahr 1989. Er konnte wiederaufgenommen werden und die Rakete nutzte das Startfenster aus.

Das Softwaremodul wurde nun auf die Ariane 5 übernommen. Das Problem war, das die Computer des SRI nicht die leistungsfähigsten waren. Man konnte nicht den gesamten Code absichern, es war „unprotected“ Code. Nun gibt es Programmiersprachen, die produzieren nur unprotected Code, aber ADA, in der der Softwareteil zum größten Teil geschrieben war erlaubte es Fehler, „Exceptions“ abzufangen. Eine Exception die möglich war, war der Überlauf wenn eine 64 Bit Fließkommazahl in eine 16 Bit Ganzzahl umgewandelt werden sollte. Sieben Variablen waren in dem Softwaremodul betroffen. Da die Belastung des SRI-Rechners unter 80% liegen sollte, waren nur vier der sieben Variablen geschützt, drei waren es nicht, weil ihr Wert entweder physikalisch begrenzt war oder weil sie bei der Ariane 4 eine Obergrenze nicht überschreiten würden, die noch in eine Ganzzahl passte. Diese Entscheidung wurde gemeinschaftlich von den Kontraktoren des Systems gefällt.

Ein wert davon war der Horizontale Bias (Variable BH) die mit der horizontalen Beschleunigung zusammenhing. Die Ariane 5 startete aber mit höherer Beschleunigung und so passierte 36,672 s nach dem Start das fatale, es gab eine Exception weil die 64 Bit Fließkommavariable nicht mehr in eine 16 Bit Ganzzahl hereinpasst, in der Fachsprache der Softwaretechnik: Es gab einen Überlauf. Das alleine löste aber nicht das Versagen aus, es war die Grundphilosophie des Designs. Dieses war ausgelegt zufällige Fehler, die vor allem durch Hardwareausfälle entstehen konnten, abzufangen. Die Vorgehensweise war die, das die betroffene Einheit sich abschaltete, den ein Restart hätte die gesamten Navigationsdaten neu berechnen müssen, wofür es nicht die Zeit gab. Das Modul legte die Fehlerdaten in einem EEPROM ab und übermittelte Diagnosedaten an den OBC. Wogegen dieses Konzept sich nicht absicherte, waren systematische Fehler, wie sie in der Software vorlagen. Nun trat ein was für Hardwareausfälle vorgesehen war: nachdem SRI1 sich abschaltete, sprang SRI2 in die Bresche. Doch da auf ihm das gleiche Programm lief, passierte einen Zyklus (72 ms) das gleiche, auch SRI2 schaltete sich ab. Der Bordcomputer erhielt nun keine Navigationsdaten mehr sondern nur noch das Diagnosemuster. Er nahm dieses Diagnosemuster aber für die wahre Position und da plötzlich die Rakete von einem Augenblick zum anderen völlig vom Kurs abgekommen war, befall er die Düsen der Booster und des Vulcains auf Vollaufschlag, wodurch die Rakete sich drehte und auseinanderbrach.

Das Inquiry Board sparte daher nicht an Kritik, denn es gab eine Reihe von Fehlern bei der Entwicklung die alle nicht erkannt wurden:

Man hat, gemäß dem Spruch von Softwerken „Never touch a running System“ ein funktionierendes System der Ariane 4 auf die Ariane 5 übertrage,n ohne sich zu fragen ob nicht Anpassungen nötig seien. So handelte man Startabbrüche bei der Ariane 5 anders, das Modul war eigentlich gar nicht nötig. Selbst bei der Ariane 4 war seine Ausgabe nach dem Start nicht mehr nötig. So unterblieb natürlich auch ein Review ob es bei der Ariane 5 nicht zu Überschreitungen des BH Wertes kommen konnte.

Im ganzen Arianeprogramm gab es die Devise, das man bei Fehlern abschaltete und auf die Redundanz baute. Es gab keine Absicherung gegen systematische Softwarefehler. Ein Softwarefehler dürfte überhaupt nicht zum Abschalten führen, stattdessen sollten die SRI Schätzungen der Höhe und Position bei einem solchen Fehler übermitteln („best effort“)

Nun werden Raketen, darunter auch die Computersteuerung getestet, bevor man sie einsetzt. Warum fiel dies dort nicht auf? Die SRI wurden in Einzelteilen getestet, nicht jedoch die Gesamtheit unter realen Flugbedingungen. Das war technisch sehr aufwendig. Die Inertialplattform muss auf einem 3D Tisch so gedreht und geneigt werden wie die Rakete wenn sie fliegen würde. Die Werte der Beschleunigungsmesser sind nur als Simulation (anlgeen der Spannungen an die A/D Wandler die entstehen würden) übermittelbar. Daher hat man ganz darauf verzichtet.

Bei der Zusammenarbeit mit dem OBC war ursprünglich vorgesehen, dass alle Teile und ihre Zusammenarbeit getestet wurden. Die Methode für das Einbinden der SRI wäre entweder die komplexe mit dem 3D-Tisch gewesen oder man hätte die SRI Computer auch nur mit den Daten füttern können wie, sie vorkommen, also Inertialplattform und Beschleunigungssensoren nicht testen und nur den Computer der SRI und seine Zusammenarbeit mit dem OBC. Beide Methoden hätten den Fehler finden können, doch 1992 entschloss man sich aus mehreren Gründen nur eine Softwaresimulation der SRI durchzuführen:

  • Man sah die beiden SRI als qualifiziert an, sie waren schließlich seit 4 Jahren bei Ariane 4 im Einsatz.
  • Die Präzision der Navigationssoftware hängt entscheidend von den genauen Berechnungen der SRI Software ab. Diese konnte mit elektronisch eingespeisten Signalen nicht erreicht werden.
  • Wichtig war vor allem auch die Simulation von Fehlermodi. Dies war mit realer SRI Hardware nicht möglich.
  • Die SRI hatten eine Berechnungszykluszeit der Beschleunigungswerte von 1 ms, während die simulierten elektronischen Signale als Ersatz für IMU und Beschleunigungsmesser alle 6 ms eingespielt wurden. Das brachte eine Fehlerursache in das System und reduzierte weiter die Genauigkeit.

Was die OBC bei der Qualfikation bekamen waren nun nicht Navigationsdaten von den SRI, sondern von einer Software berechnete Werte welche eine SRI liefern würde – wenn sie denn funktionieren würde…. Das Inquiry Board befand denn auch das dies unzureichend war, schließlich wäre eine Qualifikation auf Systemlevel nur möglich wenn die Systeme denn auch alle vorhanden sind. Man hat also auf mindestens zwei verschiedenen Ebenen versäumt den Fehler im Vorfeld zu finden. Als man ihn kannte und einen SRI mit den simulierten Beschleunigungsdaten eines Ariane 5 Starts fütterte, fiel er  zu genau demselben Zeitpunkt aus. So konnte als Nebeneffekt  die Missinterpretation des Diagnosemusters als Navigationsdaten auch nicht bei der OBC Qualifikation erkennt waren, denn natürlich gab es niemals bei der Softwaresimulation das Diagnosemuster auf dem Datenbus ….

Heute gilt der missglückte Jungfernflug der Ariane 5 als ein Beispiel welche Fehler man bei der Softwareentwicklung, vor allem dem Design und Test machen kann. Mich würde interessieren, ob der Verlust des Mars Climate Orbiters in US-Universitäten auch erwähnt wird, als Beispiel, warum man nicht in US-Einheiten rechnen sollte, sondern in SI-Einheiten. Seltsamerweise scheinen ähnliche Vorfälle immer noch vorzukommen. Ich denke nur an den Flug einer Proton die sich nach dem Start um 180 Grad drehte, weil Beschleunigungsmesser verkehrt herum eingebaut wurden. Auch hier müsste der Bordcomputer sofort nach dem Abheben doch feststellen, das die Richtung nicht stimmt. Bei der Ariane 5 wurde die Beschleunigung in 1 ms Intervallen gemessen und die Navigationsdaten in 5 ms Intervallen berechnet. Nach der kurzen Zeit wäre die Rakete noch nicht groß abgehoben und wäre wahrscheinlich beim Ausschalten wieder zur Ruhe gekommen (wie bei Mercury Redstone 1, wo es nach 22 bis 29 s erfolgte blieb die Rakete zumindest am Boden stehen. So wie der Start allerdings aussieht scheint man sie erst abgefragt zu haben als die Rakete schon den Startturm passiert hat, da sie erst dann anfängt sich zu drehen.

http://www.youtube.com/watch?v=7piHsxLs7Ss

5 thoughts on “Der Fehlschlag der Ariane 501 (Ariane 5 Jungfernflug)

  1. Bin mir jetzt nicht ganz sicher, aber zu dem Fehlstart der Proton meine ich gelesen zu haben, das der Bordcomputer durchaus bemerkt hat, dass die Richtung nicht stimmt und diese korrigieren wollte, weshalb die Rakete überhaupt erst den 180° Schwenk gemacht hat. Dieses Szenario geht so natürlich nur, wenn es nur einen einzigen Beschleunigungsmesser gibt. Wenn es allerdings mehrere Beschleunigungsmesser gab, wovon einige falsche Werte lieferten, weil falsch herum eingebaut, dann hätte die Software so beschaffen sein sollen, das sie das feststellen kann.
    Ob der Verlust des Mars Climate Orbiters an US-Universitäten auch erwähnt wird, wenn es um solche Fehler geht, würde mich auch mal interessieren. Das wird man aber wahrscheinlich nur schwer heraus finden können, weil es wohl auch von den Leuten abhängt, die dort unterrichten. Sofern die mit SI-Einheiten gross geworden sind, und sich erst mal an diverse Imperial-Units gewöhnen müssen, kann ich mir durchaus vorstellen, dass die eher geneigt sind, ihren Studenten auch SI-Einheiten beizubringen, als wenn sie im englisch sprachigen Raum gross geworden sind, wo SI-Einheiten im Alltag eher ungewöhnlich sind.
    Vielleicht hilft es auch, sich mal durch aktuelle Publikationen auf arXiv, etc. zu wühlen, um zu sehen, wie weit SI-Einheiten verbreitet sind. (Das durchwühlen könnte auch automatisiert passieren, vielleicht nicht von arXiv-Servern, sondern vom eigenen PC, was dann auch gleich den Vorteil hätte, dass man sich die Ergebnisse des DatenCrawlers sofort ansehen könnte.)

  2. Bei den USA ist es schon komisch. Die NASA arbeitet nur mit SI-Einheiten, weshalb auch der Fehler passieren konnte. Bei den Universitäten sollte es nominell auch so sein, spätestens wenn es ans Publizieren geht sind sie Pflicht. Ob das aber auch für die Studiengänge mit niedrigem Abschluss wie Bachelor gilt, darüber weis ich nichts und ich nehme es auch nicht an, denn sonst würden US-Unternehmen die ja dauernd neue Absolventen bekommen ihre Politik langsam ändern vor allem eben Luft und Raumfahrtkonzerne die ja nun nicht ihre Produkte an Endverbraucher verkaufen die keine anderen Einheiten kennen und noch dazu international verflochten sind.

  3. Hab wegen der SI-Einheiten jetzt mal ein bischen nachgeforscht; – zusammenfassend könnte man sagen, dass die USA bezüglich SI-Einheiten in zwei Lager gespalten sind: Jene die SI-Einheiten verwenden und jene, die bei imperialen Einheiten bleiben wollen. Der englische Wikipediaartikel über die SI-Einheiten ist dazu recht ausführlich. Dort ist u.a. nachzulesen, dass verschiedene US-Präsidenten schon mal versucht haben, SI-Einheiten auf breiteter Front einzuführen, was aber an einigen Lobbygruppen und teilen der Bevölkerung gescheitet ist. Einige Zeitungen haben dabei gleich masslos übertrieben, indem sie die Einführeung als diktatorische Politik geisselten.
    In einigen Bereichen wird deshalb doppelt gelabelt, da stehen dann sowohl imperiale als auch SI-Einheiten auf den Packungen. Also insgesamt wird wohl der Mensch vom US-Einheitenbüro recht behalten, den ich in einer Doku mal gesehen habe. Der meinte, dass sich dass SI-System nur langsam über mehrere Generationen hinweg durchsetzen wird. Die hatten dazu ein Beispiel gebracht, wo ein kleiner Vergnügungspark eine Achterbahn in Europa bestellt hatte und die Techniker, die sie aufbauen und später instand halten sollten, mit den Plänen erst mal nicht klar kamen, bzw. diese für falsch hielten, weil darin alle Masse in metrischen Einheiten angegeben waren, die in der Gegend unbekannt waren. Dann musste dieser Typ vom Einheitenbüro kommen und den lokalen Behörden und anderen beteiligten erklären, dass die metrischen Einheiten in Europa und auch anderswo in der Welt Standard sind und an den Plänen deshalb nichts falsch ist; – also kein Grund zur Reklamation vorliegt.

    Jetzt noch mal zum Beitrag selbst: Den finde ich sehr gut, wie da noch mal alles zusammen gefasst ist. 🙂

  4. Wir sollten eher auf passen, dass Imperiale Einheiten nicht bei uns vermehrt kommen, z.B. Inch bei Bildschirmen. Da könnte doch die EU nachhelfen, mit einem Gesetzt, dass andere Einheiten als SI verbietet. Von dort kommt ja häufiger grössere Quatsch.

    Und wenn man einem Ami zeigen will, wieso das Imperiale System minderwertig ist, dann fragt man, wieviele Inch eine Meile hat. Um das ganze zu toppen, wieviele Kubik Inch eine Kubik Meile hat. Mit mm und km ist das ganze eigentlich ein Kinderspiel.

  5. Um das zu toppen haben die ja auch noch Einheiten die wie unsere klingen. So gibt es bei ihnen „tons“. Das sind aber nicht 1000 kg, denn das wäre eine „metric ton“. In den USA sind das nur 907 kg. Sogar die wikipedia beginnt ihren Artikel dazu mit
    „Not to be confused with Tonnage or Tonne.“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.