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
