Was war der historische Einfluss von Flug 501 von Ariane 5?

Der Zerfall der Ariane 5-Rakete 37 Sekunden nach dem Start auf ihrer Jungfernfahrt ( Flug 501 ) wird allgemein als einer der teuersten Softwarefehler in der Geschichte ^{1 bezeichnet} :

Die Europäische Weltraumorganisation brauchte 10 Jahre und 7 Milliarden US-Dollar, um Ariane 5 zu produzieren, eine Riesenrakete, die bei jedem Start ein Paar Drei-Tonnen-Satelliten in die Umlaufbahn schleudern kann und Europa eine überwältigende Vormachtstellung im kommerziellen Raumfahrtgeschäft verleihen soll.

Alles, was nötig war, um diese Rakete in weniger als einer Minute auf ihrer Jungfernfahrt im vergangenen Juni zu explodieren und feurige Trümmer über die Mangrovensümpfe in Französisch-Guayana zu verteilen, war ein kleines Computerprogramm, das versuchte, eine 64-Bit-Zahl in einen 16-Bit-Raum zu stopfen.

Ein Fehler, ein Absturz. Von allen nachlässigen Codezeilen, die in den Annalen der Informatik aufgezeichnet sind, ist diese möglicherweise die verheerend effizienteste. Aus Interviews mit Raketenexperten und einer für die Weltraumbehörde erstellten Analyse ergibt sich ein klarer Weg von einem Rechenfehler zur totalen Zerstörung.

Welche wesentlichen Änderungen haben der Ausfall des Flight 501 und die anschließenden Untersuchungen zur Erforschung sicherheitskritischer Systeme und Softwaretests angeregt?

Ich suche nicht nach einer Erklärung des Fehlers selbst, sondern nach einer Erklärung der historischen Auswirkungen des Fehlers in Bezug auf Untersuchungen, die von der Untersuchung (en) des Fehlers inspiriert wurden oder in direktem Zusammenhang damit standen. Zum Beispiel kommt dieses Papier zu dem Schluss:

Wir haben statische Analysen verwendet, um:

• Überprüfen Sie die Initialisierung von Variablen.
• Bereitstellung der vollständigen Liste potenzieller Datenzugriffskonflikte für gemeinsam genutzte Variablen;
• Führen Sie die potenziellen Laufzeitfehler aus der Ada-Semantik ausführlich auf.

Nach unserer Kenntnis ist dies das erste Mal, dass boolesche und nicht boolesche statische Analysetechniken zur Validierung industrieller Programme verwendet werden.

In diesem Artikel ^{(pdf) heißt es ebenfalls} :

Für die statische Analyse der eingebetteten ADA-Software des Ariane 5-Launchers und der ARD wurden abstrakte interpretationsbasierte statische Programmanalysen verwendet. Der statische Programmanalysator zielt auf die automatische Erkennung der Definitivität, Potentialität, Unmöglichkeit oder Unzugänglichkeit von Laufzeitfehlern wie Skalar- und Fließkommaüberläufen, Array-Indexfehlern, Division durch Null und verwandten arithmetischen Ausnahmen, nicht initialisierten Variablen und Datenrennen ab gemeinsame Datenstrukturen usw. Der Analysator konnte den Flugfehler Ariane 501 automatisch erkennen. Die statische Analyse eingebetteter sicherheitskritischer Software (z. B. Avionik-Software) ist sehr vielversprechend .

Ich würde gerne eine ausführliche Erklärung der Auswirkungen dieses einzelnen Ereignisses auf Softwaretestansätze und -tools erhalten.

_{¹ Die Zahl von 7 Milliarden US-Dollar bezieht sich möglicherweise auf die Gesamtkosten des Ariane-5-Projekts. Wikipedia berichtet, dass der Ausfall zu einem Verlust von mehr als 370 Millionen US-Dollar geführt hat. Immer noch ein ziemlich teurer Fehler, aber bei weitem nicht annähernd die 7-Milliarden-Dollar-Zahl.}

Technisch gesehen handelte es sich eher um " Software Rot ". Die Flugsteuerungssoftware wurde aus der früheren Ariane 4-Rakete recycelt. Dies ist angesichts der hohen Kosten für die Entwicklung von Software ein vernünftiger Schritt, insbesondere wenn es sich um unternehmenskritische Software handelt, die nach weitaus strengeren Standards getestet und verifiziert werden muss, als es die meisten kommerziellen Softwareprodukte erfordern.

Leider machte sich niemand die Mühe zu testen, welche Auswirkungen die Änderung der Betriebsumgebung haben würde, oder wenn dies der Fall wäre, würden sie diese Tests nicht nach einem ausreichend gründlichen Standard durchführen.

Die Software wurde entwickelt, um zu erwarten, dass bestimmte Parameter bestimmte Werte (Schub, Beschleunigung, Kraftstoffverbrauch, Vibrationspegel usw.) niemals überschreiten. Im normalen Flug mit einer Ariane 4 war dies kein Problem, da diese Parameter niemals ungültige Werte erreichen würden, ohne dass etwas bereits spektakulär falsch wäre. Die Ariane 5 ist jedoch viel leistungsstärker und Bereiche, die auf der 4 albern erscheinen, können auf der 5 recht leicht auftreten.

Ich bin mir nicht sicher, welcher Parameter außerhalb des Bereichs lag (es könnte eine Beschleunigung gewesen sein, die ich überprüfen muss), aber als dies der Fall war, war die Software nicht in der Lage, einen arithmetischen Überlauf zu bewältigen, für den es ihn gegeben hatte unzureichende Fehlerprüfung und Wiederherstellungscode implementiert. Der Leitcomputer begann, Müll an die Kardandüsen zu senden, was wiederum dazu führte, dass die Motordüse ziemlich zufällig ausgerichtet wurde. Die Rakete begann zu stürzen und zu zerbrechen, und das automatische Selbstzerstörungssystem erkannte, dass sich die Rakete jetzt in einer unsicheren, nicht wiederherstellbaren Position befand, und beendete den Job.

Um ehrlich zu sein, hat dieser Vorfall wahrscheinlich keine neuen Lektionen gelehrt, da die Art von Problemen zuvor in allen Arten von Systemen aufgedeckt wurde und es bereits Strategien gibt, um Fehler zu finden und zu beheben. Der Vorfall hat gezeigt, dass die Nachlässigkeit bei der Befolgung dieser Strategien enorme Konsequenzen haben kann, in diesem Fall Millionen Dollar an zerstörter Hardware, einige extrem verärgerte Kunden und eine hässliche Beeinträchtigung des Ansehens von Arianespace.

Dieser besondere Fall war besonders auffällig, weil eine Abkürzung zum Sparen von Geld eine enorme Menge kostete, sowohl in Bezug auf Geld als auch in Bezug auf den Rufverlust. Wenn die Software in einer simulierten Ariane 5-Umgebung genauso robust getestet worden wäre wie bei der ursprünglichen Entwicklung für Ariane 4, wäre der Fehler sicherlich schon lange vor der Installation der Software auf der Starthardware und der Beauftragung von aufgetreten ein tatsächlicher Flug. Wenn ein Softwareentwickler absichtlich eine unsinnige Eingabe in die Software geworfen hätte, wäre der Fehler möglicherweise sogar in der Ariane 4-Ära aufgetreten, da dies die Tatsache hervorgehoben hätte, dass die vorhandene Fehlerbehebung unzureichend war.

Kurz gesagt, es lehrte nicht wirklich neue Lektionen, aber es rammte die Gefahren nach Hause, sich nicht an alte zu erinnern. Es wurde auch gezeigt, dass die Umgebung, in der ein Softwaresystem arbeitet, genauso wichtig ist wie die Software selbst. Nur weil die Software nachweislich für die Umgebung X korrekt ist, bedeutet dies nicht, dass sie für den Zweck in einer ähnlichen, aber unterschiedlichen Umgebung Y geeignet ist. Schließlich wurde hervorgehoben, wie wichtig es ist, dass unternehmenskritische Software robust genug ist, um mit Umständen umzugehen, die nicht gegeben sein sollten passierte.

Kontrastflug 501 mit Apollo 11 und seinen Computerproblemen. Während die LGC-Software während der Landung unter einem schwerwiegenden Fehler litt, war sie äußerst robust und konnte trotz der ausgelösten Softwarealarme in einem betriebsbereiten Zustand bleiben, ohne dass Astronauten in Gefahr waren und dies dennoch konnten Schließe seine Mission ab.

Es handelte sich hauptsächlich um ein Wiederverwendungs- und Verwaltungsproblem und nicht um ein Codierungsproblem. Aus meinen Erinnerungen (ich verstehe wahrscheinlich einige Dinge falsch) an den Bericht.

• Ein Subsystem war für Ariane IV konzipiert worden. Trajektorien von Ariane IV konnten nicht zum Überlauf führen, und es wurde absichtlich entschieden, dass es sich im Falle eines Hardwareproblems um ein Hardwareproblem handelte. Das Herunterfahren des Subsystems und das Wechseln zum Ersatzteil war das Richtige.

• Für Ariane V wurde beschlossen, dieses Subsystem wiederzuverwenden und die Annahmen und den Code nicht zu überprüfen, sondern sich auf Tests zu verlassen.

• Ferner wurde beschlossen, die vollständigen Tests einzustellen.

Verschiedene Flugparameter von Ariane V haben den Überlauf verursacht. Fahren Sie die Primärdatenbank herunter. Schalten Sie das Ersatzteil aus. Autodestruction.

Zusätzliche Dinge, an die ich mich erinnere:

• Das Subsystem zum Zeitpunkt des Überlaufs war nicht mehr nützlich. Man könnte argumentieren, dass sein Versagen die automatische Zerstörung nicht hätte auslösen sollen. (Andererseits könnte die zusätzliche Komplexität selbst eine Quelle von Problemen sein).

• Es wurden Debug-Daten an einen Bus gesendet, wenn dies nicht der Fall sein sollte. Ich erinnere mich nicht an das Spezifische.

Wie andere bereits erwähnt haben, hat dies die Branche im Allgemeinen veranlasst, das Konzept der Wiederverwendung erneut zu prüfen und es in einen größeren Bezugsrahmen zu stellen, wobei Komponenten nicht isoliert, sondern im Kontext des gesamten Systems bewertet werden. Dies verringert die Attraktivität der Wiederverwendung erheblich, da selbst wenn eine Komponente ohne Änderungen wiederverwendet werden kann, sie dennoch mit neuen Annahmen analysiert werden muss. Eine weitere Konsequenz ist, dass Backup-Hardware, auf der dieselbe Software ausgeführt wird, bei weitem nicht so attraktiv ist, da die meisten modernen Hardwarekomponenten um Größenordnungen zuverlässiger sind als moderne Software. Ich habe gehört, dass einige Verteidigungsverträge zwei separate Softwaresysteme erfordern, die von verschiedenen Teams unter Verwendung unterschiedlicher Technologien entwickelt wurden, die nach derselben Spezifikation arbeiten, um die ordnungsgemäße Implementierung zu überprüfen.