Ariane Flug V88

"Cluster (Raumschiff)" leitet hier weiter. In diesem Artikel geht es um den fehlgeschlagenen Cluster -Start. Für die erfolgreiche Weltraummission siehe Cluster II (Raumschiff).
Cluster
Missionstyp Magnetosphärisch
Operator ESA
Cospar ID Edit this at Wikidata
Raumfahrzeuge Eigenschaften
Startmasse 1.200 Kilogramm (2.600 lb)
Missionsstart
Erscheinungsdatum 12:34:06, 4. Juni 1996 (UTC)
Rakete Ariane 5g
Startplatz Kourou ELA-3
Ende der Mission
Verfügung Startversagen
Zerstört 4. Juni 1996
Cluster mission insignia
ESA Viereckelale Mission Insignia für Cluster
←Soho
Huygens→
 

Ariane Flug V88[1] war der gescheiterte Maiden -Flug der Arianespace Ariane 5 Rakete, Fahrzeug Nr. 501, am 4. Juni 1996. Es trug das Cluster Raumschiff, eine Konstellation von vier Europäische Weltraumagentur Forschung Satelliten.

Der Start endete mit dem Fehler aufgrund mehrerer Fehler im Softwaredesign: Dead Codenur für Ariane 4mit unzureichender Schutz vor Ganzzahlüberlauf führte zu an Ausnahme behandelt unangemessen - das Ganze haut Trägheitsnavigationssystem Das wäre sonst nicht betroffen gewesen. Dies führte dazu, dass die Rakete 37 Sekunden nach dem Start von ihrem Flugweg abweist, sich unter hohen aerodynamischen Kräften auflösten und schließlich über seine automatisierten selbst zerstört Flugabschlusssystem. Das Versagen ist als einer der berüchtigtsten und teuersten bekannt geworden Software -Fehler in der Geschichte.[2] Das Scheitern führte zu einem Verlust von mehr als 370 Millionen US -Dollar.[3]

Startversagen

Diagramm der Ariane 501 mit den vier Cluster -Satelliten
Fragment -Fallout -Zone des gescheiterten Ariane 501 -Starts
Wiederherstellte Unterstützung der Satellitenstruktur

Der Ariane 5 den Code wiederverwendet von dem Trägheitsreferenzplattform von dem Ariane 4Aber der frühe Teil des Flugwegs des Ariane 5 unterschieden sich von der Ariane 4 in höheren horizontalen Geschwindigkeitswerten. Dies führte zu einem internen Wert BH (horizontale Vorspannung), der in der Ausrichtungsfunktion berechnet wurde, um unerwartet hoch zu sein. Die Ausrichtungsfunktion war ungefähr 40 Sekunden lang Flugbetriebe betrieben, was auf einer Anforderung von Ariane 4 beruhte.[4] Die größeren Werte von BH verursachten eine Datenumwandlung von a 64-Bit schwimmender Punkt Nummer zu a 16-Bit unterzeichnet ganze Zahl Wert zu Überlauf und Ursache a Hardware -Ausnahme.[5] Die Programmierer hatten nur vier von sieben kritischen Variablen gegen Überlauf aufgrund von Bedenken hinsichtlich der rechnerischen Einschränkungen des Bordcomputer Ariane 5, Flugbahn.[6] Die Ausnahme hielt beide Trägheitsreferenzsystemmodule an, obwohl sie zu sehen waren überflüssig. Das aktive Modul stellte dem On-Bord-Computer ein diagnostisches Bitmuster vor, das als Flugdaten interpretiert wurde, was insbesondere bei vollständigen Düsenablenkungen der soliden Booster und der Vulcain -Hauptmotor. Dies führte zu einem Antragswinkel von mehr als 20 Grad, was zu einer Trennung der Booster von der Hauptbühne, zur Auslösen des Selbstzerstörungssystems des Launchers und zur Zerstörung des Fluges führte.[4]

Entsprechend William KahanDer Verlust des Fluges 501 wäre vermieden worden, wenn der Verzug IEEE 754 Ausnahmebehandlungspolitik ("Presubstitution") war verwendet worden, weil sie die Berechnung nicht abgebrochen hätte.[7] Der offizielle Bericht über den Absturz (durchgeführt von einem Untersuchungsausschuss unter der Leitung Jacques-Louis Lions) stellte fest, dass "ein zugrunde liegendes Thema in der Entwicklung von Ariane 5 die Tendenz in Richtung der ist Minderung des zufälligen Versagens. Der Lieferant des Trägheitsnavigationssystem (SRI) folgte nur der ihm angegebenen Spezifikation, was feststellte, dass im Falle einer erkannten Ausnahme der Prozessor gestoppt werden sollte. Die Ausnahme, die auftrat, war nicht auf zufällige Ausfälle, sondern auf einen Entwurfsfehler zurückzuführen. Die Ausnahme wurde erkannt, jedoch unangemessen behandelt, da die Ansicht genommen worden war, dass Software als korrekt angesehen werden sollte, bis sich gezeigt hat, dass sie schuld ist. [...] Obwohl der Fehler auf einen systematischen Software -Designfehler zurückzuführen war, können Mechanismen eingeführt werden, um diese Art von Problem zu mildern. Zum Beispiel hätten die Computer innerhalb des SRI Attitüde Information. Es besteht Grund zu Anliegen, dass eine Software-Ausnahme zugelassen oder sogar erforderlich ist, um einen Prozessor zu veranlassen, während missionskritischer Geräte umgehen. In der Tat ist der Verlust einer ordnungsgemäßen Softwarefunktion gefährlich, da dieselbe Software in beiden SRI -Einheiten ausgeführt wird. Im Fall von Ariane 501 führte dies zum Ausschalten von zwei noch gesunden kritischen Geräten. "[4]

Andere im Bericht identifizierte Themen konzentrierten sich auf Tests:[4]

  • Der Zweck des Überprüfungsprozesses, an dem alle wichtigen Partner im Ariane 5 -Programm beteiligt sind, besteht darin, Entwurfsentscheidungen zu validieren und Flugqualifikation zu erhalten. In diesem Prozess wurden die Einschränkungen der Ausrichtungssoftware nicht vollständig analysiert, und die möglichen Auswirkungen, dass sie während des Fluges weiter funktionieren konnte, wurden nicht realisiert.
  • Die Spezifikation des Trägheitsreferenzsystems und der auf Geräteebene durchgeführten Tests umfasste nicht speziell die Ariane 5 -Flugbahndaten. Folglich wurde die Neuausrichtungsfunktion unter simulierten Ariane 5 -Flugbedingungen nicht getestet, und der Entwurfsfehler wurde nicht entdeckt.
  • Es wäre technisch machbar gewesen, fast das gesamte Trägheitsreferenzsystem in die durchgeführten Gesamtsystemsimulationen aufzunehmen. Aus einer Reihe von Gründen wurde beschlossen, die simulierte Ausgabe des Trägheitsreferenzsystems, nicht das reale System oder seine detaillierte Simulation zu verwenden. Wäre das System aufgenommen worden, hätte der Fehler festgestellt werden können. Auf einem Computer mit Software des Trägheitsreferenzsystems und einer simulierten Umgebung, einschließlich der tatsächlichen Flugbahndaten aus dem Ariane 501-Flug, wurden Simulationen nach dem Flug nach dem Flug durchgeführt. Diese Simulationen haben die Kette der Ereignisse, die zum Versagen der Trägheitsreferenzsysteme führen, treu reproduziert.

Eine andere Perspektive des Scheiterns basierend auf Systemtechnik, konzentriert sich auf Anforderungen:[8]

  • Die Bereiche von Variablen wie horizontaler Geschwindigkeit und der daraus berechneten Menge, die aus sie berechnet wurde, sollten explizit quantifiziert werden. Stattdessen wurde ein 16-Bit-Bereich angenommen.
  • Die Ausrichtungsaufgabe hätte in einem angemessenen Zeitpunkt deaktiviert werden müssen. Stattdessen lief die Ausrichtungsaufgabe nach dem Abheben.
  • Ein Fehlermodell der Trägheitsreferenzplattformen hätte analysiert werden müssen, um sicherzustellen, dass der Service während des gesamten Fluges kontinuierlich erbracht wird, anstatt davon auszugehen, dass höchstens ein Modul fehlschlagen würde. Stattdessen scheiterten beide Module, und anstatt den Flug ordnungsgemäß zu töten, geben Sie diagnostische Nachrichten aus, die als Flugdaten interpretiert wurden.

Nutzlast

Cluster bestand aus vier 1.200 Kilogramm (2.600 lb) zylindrisch, Spin-stabilisiert Raumschiff, angetrieben von 224 Watt Solarzellen. Das Raumschiff sollte in a geflogen sein Tetraedrisch Bildung und sollten die Erforschung der Erde durchführen Magnetosphäre. Die Satelliten wären in hoch elliptische Umlaufbahnen untergebracht worden; 17.200 x 120.600 Kilometer (10.700 x 74.900 mi), geneigt bei 90 Grad zum Äquator.[9]

Nachwirkungen

Nach dem Fehler vier Ersatz Cluster II Satelliten wurden gebaut. Diese wurden paarweise an Bord gestartet Soyuz-u/Fregat Raketen im Jahr 2000.

Der Startversagen brachte die hohen Risiken, die mit komplexen Computersystemen verbunden sind Führungskräfte, was zu einer erhöhten Unterstützung für die Forschung zur Gewährleistung der Zuverlässigkeit von führt Sicherheitskritische Systeme. Die anschließende automatisierte Analyse des Ariane Code (geschrieben in Ada) war das erste Beispiel für groß an Statische Codeanalyse durch Abstrakte Interpretation.[10]

Das Scheitern schadete auch den hervorragenden Erfolg der Raketenfamilie der Europäischen Weltraumagentur, die durch die hohe Erfolgsrate des Ariane 4 -Modells festgelegt wurde. Erst 2007 wurden Ariane 5 Starts als so zuverlässig anerkannt wie die des Vorgängermodells.[11]

Siehe auch

Verweise

  1. ^ "V88 Ariane 501". www.capcomespace.net. Abgerufen 25. Dezember 2021.
  2. ^ Gleick, James (1. Dezember 1996). "Ein Fehler und ein Absturz". New York Times Magazine. Abgerufen 7. April 2012.
  3. ^ Dowson, Mark (März 1997). "Der Ariane 5 -Softwarefehler". ACM Sigsoft Software Engineering Notizen. 22 (2): 84. doi:10.1145/251880.251992. S2CID 43439273.
  4. ^ a b c d "Ariane 5 Misserfolg - Voller Bericht". Archiviert Aus dem Original am 26. April 2014. Abgerufen 16. Juli 2014.
  5. ^ NuSeibeh, Bashar (Mai 1997). "Ariane 5: Wer nicht?" (PDF). IEEE -Software. 14 (3): 15–16. doi:10.1109/ms.1997.589224. S2CID 206482665.
  6. ^ "Die Lektionen von Ariane". www.irisa.fr. Archiviert Aus dem Original am 4. Juni 2016. Abgerufen 5. Mai 2018.
  7. ^ W.Kahan (5. Juli 2005). "Eine Demonstration der Vorsteuerung für ∞/∞" (PDF). Archiviert (PDF) Aus dem Original am 10. März 2012.
  8. ^ Le Lann, Gérard (März 1997). "Eine Analyse des Ariane 5 Flug 501 -Fehlers - eine Systemtechnik Perspektive". Proceedings der Internationalen Konferenz von 1997 über technische Systeme computergestützter Systeme (ECBS'97). IEEE Computer Society. S. 339–346. doi:10.1109/ecbs.1997.581900. ISBN 0-8186-7889-5.
  9. ^ Krebs, Gunter. "Cluster 1, 2, 3, 4, 5, 6, 7, 8". Gunters -Space -Seite. Abgerufen 29. November 2011.
  10. ^ Faure, Christèle. "Polyspace Technologies History". Abgerufen 3. Oktober 2010.
  11. ^ Todd, David (März 2007). "Space Intelligence News aufsteigen" (PDF). Archiviert von das Original (PDF) am 14. Februar 2007.

Weitere Lektüre

  • Thomas, L.D. (2007) Ausgewählte Systemtechnik -Prozessmängeln und deren Konsequenzen. Acta Astronautica, 61, 406–415.

Externe Links