Ariane 5

Allgemeines

Die Ariane 5 ist das jüngste Modell der Trägerrakete Ariane der europäischen Weltraumorganisation ESA. Mit 4 CLUSTER-Satelliten beladen, sollte die Ariane 501 am 4. Juni 1996 ihren Jungfernflug starten. Dieser endete ca. 40 Sekunden nach dem Start mit einer Explosion der Trägerrakete (avi-Film der Explosion 3.9 MB). Glücklicherweise war der Flug unbemannt, allerdings belaufen sich die Herstellungskosten für die Rakete und die Satelliten auf insgesamt ca. 500 Millionen Dollar. Da keine kommerzielle Fracht an Bord war, sondern Forschungssatelliten, war der Flug nicht versichert worden. Die Entwicklung der Rakete alleine hat 10 Jahre und 7 Milliarden Dollar beansprucht.

Am 19. Juli 1996 lieferte ein eingesetzter Untersuchungsausschuß seinen Bericht über die Ursachen des Fehlschlages ab. Dieser Untersuchungsbericht diente als Hauptinformationsquelle für den Ariane-Teil dieser Website.

Ablauf des Fluges

T -3
Sek.

Der Onboard Computer gibt den Befehl das Haupttriebwerk VULCAIN zu zünden, das bis T 0 Sek. 100% Schubleistung aufbaut.

T 0
Sek.		 Nun wird an die beiden Booster der Zündbefehl erteilt. Der Aufbau des Schubs dauert 7,5 Sekunden.
T +7,5
Sek.		 Die Haltebolzen werden gesprengt und ARIANE 501 hebt in den wolkenverhangenen Himmel über Französisch Guyana ab.
T +37
Sek.		 Die Rakete befindet sich in einer Höhe von 3500 m und hat eine Geschwindigkeit von 0,7 Mach (857 km/h).
T +37 bis 39 Sek. Nun erteilt der Onboard Computer an die Servomotoren den Befehl, beide Boosterdüsen und das VULCAIN Triebwerk bis zum Anschlag zu lenken. Infolge dessen beginnt die Rakete nach vorne zu "kippen". Die nun auf die Flugeinheit einwirkenden Kräfte werden größer und haben die Folge, daß diese auseinander zu brechen beginnt. Einer der ersten Teile die "wegbrechen", ist die Nutzlastverkleidung mitsamt den vier CLUSTER-Satelliten (Anmerkung: Da beide Booster 92% der Schubleistung aufbringen, wäre ein Gegenlenken des Haupttriebwerks sinnlos).

T +41
Sek.

Der automatische Selbstzerstörungsmechanismus wird von beiden Onboard Computern ausgelöst und zerstört die Rakete.

Ariane 5 ExplosionRückläufige Ereignisabfolge

Der Untersuchungsausschuß beschreibt in seinem Bericht folgendes Ereignisszenario, das die Ereignisse von der Explosion an rückwärts auflistet:

Fehlersuche und Verifikation

Zur Fehlersuche lagen dem Untersuchungsausschuß Informationen an Hand des Flugschreibers, den Flugbahndaten der Radar Station, Filmaufnahmen und Trümmerteilen vor. Besonders viele Erkenntnisse konnten durch die Bergung des aktiven SRI gewonnen werden, da in seinem Speicher die letzten Daten gesichert waren, die nicht mehr zur Bodenstation übertragen werden konnten. Die Fehlerquelle konnte schnell auf das Flugsteuerungssystem und vor allem auf die beiden SRIs eingegrenzt werden, da sie offensichtlich fast gleichzeitig, kurz vor der Flugbahnabweichung, aufhörten zu arbeiten. Nachdem der Fehler durch Simulationen reproduziert werden konnte, ist die Fehlerquelle und der Ereignisablauf über jeden Zweifel erhaben.

Fehlerursachen

Im Folgenden sollen alle Fehlerquellen aufgezeigt werden, die zum Absturz geführt haben. Da alles mit de SRI zusammenhängt, soll dessen Funktionsweise kurz dargestellt werden. Das SRI, als Teil des Flugkontrollsystems, mißt die Fluglage und berechnet die Bewegungen der Rakete und überträgt dies über einen Datenbus an den OBC, der das Flugprogramm ausführt und die Düsen steuert. Um das System redundant zu halten, gab es von vielen Geräten ein Ersatzgerät mit identischer Hard- und Software. Dazu gehörten auch das SRI und der OBC. Der OBC sollte zu dem Backup-SRI wechseln, sobald der aktive SRI dem OBC eine Fehlfunktion anzeigt. Das Design der SRIs wurde von Ariane 4 übernommen.

 

1. Fehler

Der Wert der zu konvertierenden Variablen war zu groß, wodurch es zu dem Speicherüberlauf kam. Man ging davon aus, daß die Variable trotz Sicherheitsbereich keinen so großen physikalischen Wert annehmen kann. Dies läßt sich darauf zurückführen, daß das Design der SRIs von der Ariane 4 übernommen wurde, die eine andere Flugbahn beschreibt und deshalb diese Werte nicht erreicht.

2. Fehler

Die Exception die durch die Umwandlung geworfen wurde, wurde nicht abgefangen. Erstaunlicherweise fand man in dem kritischen Teil der Software von insgesamt 7 Variablen noch 2 weitere, die auch nicht abgesichert waren. Dazu gab es keine Kommentare direkt im Quellcode. Dem Untersuchungsausschuß wurde allerdings mitgeteilt, daß der SRI-Computer nur auf eine Arbeitslast von 80% eingestellt werden sollte, um performanter zu sein. Die 3 ungeschützten Variablen wurden auf Fehlermöglichkeiten, speziell auf Speicherüberläufe bei Konvertierungen, überprüft (allerdings nur für Ariane 4, siehe oben).

3. Fehler

Das Programm, das den Fehler verursachte, war zu diesem Zeitpunkt überflüßig und hätte bereits gestoppt werden müssen. Es war eigentlich dafür zuständig im Falle einer Unterbrechung der Countdowns kurz vor dem Lift-Off (T0) diesen möglichst schnell wiederaufnehmen zu können. Entsprechend der Spezifikation von Ariane 4 ließ man das Programm für genau 40 Sekunden nach dem Start weiterlaufen. Hier vertraute man auf dem Grundsatz, daß ein bisher funktionsfähiges System nicht geändert werden sollte.

4. Fehler

Die beiden SRIs schalteten sich ab, nachdem sie eine Exception erkannt hatten. Vorher speicherten sie den Kontext im EEPROM und lieferten einmalig Diagnosedaten an den OBC, der diese als Flugbahndaten auswertete. Dei Entscheidung das System abzuschalten beruht in dem Vertrauen auf ein redundantes System. Allerdings können damit nur Hardwarefehler abgefangen werden. in diesem Fall lag ein Softwarefehler vor und da bei beiden SRIs die gleiche Software eingesetzt wurde, führte dies auch zu Ausfall beider Systeme.

5. Fehler

Eine weitere wichtige Bedingung für das Auftreten des Fehlers waren die Tests im Vorfeld des Starts. Das SRI und das Restsystem wurden getrennt von einander getestet. Innerhalb eines Tests wurden die jeweiligen anderen Komponenten nur simuliert. Grund hierfür war unter anderem, daß man annahm das SRI würde korrekt arbeiten, da er ja schon in Ariane 4 keine Fehlfunktionen gezeigt hatte.

6. Fehler

Die Spezifikation für die SRIs war unzureichend. Sie umfaßte nicht das Miteinbeziehen der Flugbahndaten. Damit hätte der Hersteller der SRIs den Fehler bei seinen Tests erkennen müssen.

Der Untersuchungsausschuß weißt in seinem Bericht ausdrücklich darauf hin, daß das komplette Software-System der Ariane 5 das Ergebnis einer qualitativ sehr hochwertigen Ingenieursarbeit ist. Man sieht den Fehler im Design der Software, da solange angenommen wird das die Software korrekt arbeitet, bis sie sich als fehlerhaft herausstellt. Der Ausschuß vertrat den gegensätzlichen Standpunkt, daß Software als fehlerhaft angesehen werden sollte, bis die zur Zeit beste Praxismethoden zeigt, daß die Software korrekt ist. Das bedeutet, daß kritische Software - deren Ausfall die Mission in Gefahr bringt - auf einem sehr detailliertem Level gekennzeichnet werden muß, daß Exception Verhalten begrenzt werden muß, und daß eine angemessene Backup-Politik Software-Ausfälle in Betracht geziehen muß.

Fazit

Ursache des Fehlers war eindeutig ein fehlerhaftes Design aufgrund einer fehlerhaften Spezifikation. Der Fehler hätte jedoch in entsprechenden Tests erkannt werden können. Die Empfehlungen des Untersuchungsausschusses ergeben sich aus den festgestellten Fehlern.

Empfehlungen des Ausschußes

Aufgrund von seinen Analysen und Schlußfolgerungen bildet der Außschuß folgende Empfehlungen.

  1. Schalten Sie die Ausrichtungsfunktion des SRI sofort nach dem Lift-Off aus. Allgemeiner gesprochen, sollte keine Software-Funktion während des Fluges laufen, es sei denn sie ist erforderlich.
  2. Bereiten Sie eine Test-Umgebung vor, die so viele reale Ausrüstung wie technisch durchführbar beinhaltet, geben Sie realistische Eingangsdaten ein, und führen Sie komplettes, closed-loop System-Testing durch. Komplette Simulationen müssen vor jeder möglichen Mission stattfinden. Es muß eine hohe Testdeckung erreicht werden.
  3. Erlauben Sie keinem Sensor, wie dem SRI, damit aufzuhören die besten Schätz-Daten zu senden.
  4. Organisieren Sie, für jedes Ausrüstungseinzelteil der verbindenden Software, einen spezifischen Software-Qualifikations-Bericht. Der industrielle Architekt sollte an diesen Berichten teilnehmen und über die komplette Systemprüfung, die mit der Ausrüstung durchgeführt wurde, berichten. Alle Anwendungseinschränkungen der Ausrüstung sollten für den Review-Ausschuß klar und deutlich gemacht werden. Machen Sie aus jeder kritischen Software ein Konfigurationsgesteuertes Einzelteil (Configuration Controlled Item).
  5. Überprüfen Sie alle Flug-Software (einschließlich eingebetteter Software) und insbesondere:
    • Kennzeichnen Sie alle impliziten Annahmen, die durch den Code und seine Rechtfertigungs-Dokumente (Lastenheft) gemacht werden, auf die Quantitätswerte, die durch die Ausrüstung unterstützt werden. Überprüfen Sie diese Annahmen gegen die Anwendungseinschränkungen der Ausrüstung.
    • Überprüfen Sie den Wertebereich, der durch alle Internen- oder Kommunikations-Variablen in der Software in Anspruch genommen wird.
    • Das Projektteam sollte Lösungen zu den möglichen Problemen in der Bordcomputer-Software, wobei Bordcomputerumschltungen besonders beachtet werden sollen, vorgeschlagen und diese sollten von einer Gruppe externer Experten überprüft werden, die dem Bordcomputer-Qualifikations-Ausschuß berichten sollten.
  6. Wo immer technisch durchführbar, ziehen Sie die begrenzten Ausnahmefälle von Aufgaben- und Geräte- Backup-Möglichkeiten in Betracht.
  7. Stellen Sie mehr Daten zur Fernmessung im Falle eines Ausfalls irgendeiner Komponente zur Verfügung, damit die Ausrüstungsrückgewinnung weniger lebenswichtig ist.
  8. Überdenken Sie die Definition der kritischen Bestandteile und ziehen Sie Ausfälle durch Software-Ursprung in Betracht (insbesonders Einzelpunktausfälle).
  9. Schließen Sie externe Teilnehmer (des Projekts) mit ein, wenn Sie Spezifikationen, Code und Rechtfertigungs-Dokumente überprüfen. Stellen Sie sicher, daß diese Berichte die Substanz der Argumenten betrachten, anstatt zu prüfen, ob eine Verifikation durchgeführt worden sind.
  10. Fügen Sie Flugbahndaten in die Spezifikationen und in die Testanforderungen ein.
  11. Überprüfen Sie die Testdeckung der vorhandenen Ausrüstung und erweitern Sie sie, wo es notwendig zu sein scheint.
  12. Geben Sie den Rechtfertigungs-Dokumenten die gleiche Aufmerksamkeit wie dem Code. Verbessern Sie die Technik für das Konsistenthalten des Codes und seiner Rechtfertigungs-Dokumente.
  13. Stellen Sie eine Mannschaft auf, die das Verfahren vorbereitet für das Qualifizieren von Software , zwingende Richtlinien für die Bestätigung solcher Qualifikation vorschlägt und ermittelt, daß Spezifikation, Verifikation und das Testen der Software von einer durchweg hohen Qualität im Ariane 5 Programm ist. Es sollte in Betrachtet gezogen werden externen RAMAS Experten miteinzubeziehen.
  14. Eine transparentere Organisation der Zusammenarbeit unter den Partnern im Ariane 5 Programm muß in Betracht gezogen werden. Nahe Ingenieurszusammenarbeit, mit klaren Berechtigungs- und Verantwortlichkeits-Grenzen, ist erforderlich, um Systemkohärenz mit einfachen und klaren Schnittstellen zwischen Partnern zu erreichen.

Ada-Code

Zum Abschluß noch der mehrere Millionen schwere Ada-Code:

begin
sensor_get(vertical_veloc_sensor);
sensor_get(horizontal_veloc_sensor);
vertical_veloc_bias := integer(vertical_veloc_sensor);
horizontal_veloc_bias := integer(horizontal_veloc_sensor);
...
exception
when numeric_error => calculate_vertical_veloc();
when others => use_irs1();
end;

Top