Spektakuläre Fehlschläge in der Raumfahrt – Teil 2

Es folgt nun der zweite Teil von spektakulären Fehlschlägen bzw. krassen Versäumnissen in der Raumfahrt, eventuell gibt es auch noch einen dritten Teil, ich denke gerade darüber nach was ich da noch aufnehmen könnte.

Block L: Mangelnde Telemetrie

Kennzeichnend für russische Raketen in der frühen Phase, teilweise bis heute ist, das die Konstrukteure Problemstellungen umgehen. Die meisten russischen Raketen werden „heiß“ gezündet, das heißt. Eine Stufe zündet, während die untere noch läuft. So vermeidet man, dass man die Stufe in Schwerelosigkeit zünden muss und sich der Treibstoff vielleicht von den Öffnungen der Tankleitungen entfernt. Das galt auch für die R-7. Als man aber eine Rakete für Planetenmissionen benötigte und auch für eine neue Serie von Nachrichtensatelliten gab es die Forderung, dass die letzte Stufe erst zündet, wenn sie in einem Erdorbit angekommen ist. Mindestens 20 Minuten lang ist sie in der Schwerelosigkeit. Diese neue Oberstufe war Block L, der zuerst für Raumsonden eingesetzt wurde, dann für die Serie von Molnija Satelliten. Die Sojus-Rakete mit dieser Oberstufe wurde später dann auch als „Molnja“ bezeichnet.

Die russische Lösung war das eine „normale „Stufe um ein Hilfssystem erweitert wurde, genannt BOZ. Es stabilisierte die Stufe während ihrer Freiflugphase und sammelte den Treibstoff in den Tanks, bevor die Stufe selbst zündete und wurde dann abgeworfen. Doch die Zuverlässigkeit der neuen Stufe Block L war sehr schlecht. Von den ersten 27 Starts scheiterten 15. Das war selbst damals ein miserabler Wert. Lange Zeit bekam Russland nicht heraus, woran es lag. Der eigentliche Grund ist ein Designfehler. Vor Zündung des eigentlichen Block L sollte die Steuerung von BOZ auf das Steuersystem 70S von Block L übergehen. Das erfolgte nicht. So war die Stufe anfangs nicht steuerbar, bis BOZ kurz nach der Zündung abgeworfen wurde. Geriet die Stufe nun bei der Zündung (oder schon vorher) in eine Fehlausrichtung so konnten die Gyroskope blockieren, was eine automatische Abschaltung nach sich zog. Unzählige Raumsonden strandeten so im Erdorbit und wurden als „Kosmos-Satellit“ ausgewiesen um den Fehlschlag zu verbergen.

Doch warum fiel dies fast vier Jahre über 27 Missionen lang nicht auf? Russland hatte keine Bahnverfolgungsschiffe an den Punkten, wo die Zündung stattfand. Daneben übermittelte Block L die Telemetriedaten automatisch in festen Abständen in Form eines Datenpakets. Da Russland nicht die ganze Bahn mit Bodenstationen abdecken konnte, bekam es lange Zeit nicht das Datenpaket, das die Daten enthielt, anhand derer man die Ursache finden konnte.

Erstaunlich aus heutiger Sicht ist, das man obwohl es ja über vier Jahre keine Verbesserung gab, trotzdem laufend Raumsonden mit der Molnija startete.

ESA: Softwarefehler

Scheiterten früher Raumfahrtmissionen an ausgefallener Hardware, so hat sich inzwischen die Software einen Spitzenplatz erobert. Softwarefehler gab es schon immer. Den ersten dokumentierten Softwarefehler gibt es schon beim Start von Mariner 1. Normal war, das die Atlas vom Boden aus gesteuert wurde und erst mit der Agena Oberstufe eine aktive Steuerung einsetzte. Vorher war der Autopilot nur als Backup aktiv. Doch bei dem Start verlor die Richtantenne der Atlas mehrfach den Kontakt und so schwenkte die Elektronik auf den Autopiloten um, bei dem ein fehlerhaftes FORTAN Programm dann aber zu einer Kursabweichung führte und die Rakete gesprengt werden musste.

Ganz anders war die Sache beim Jungfernflug der Ariane 501. Die Rakete stieg normal auf, um plötzlich, 37 s nach dem Start zu explodieren. Wer damals die Live-Übertragung im Fernsehen ansah erinnert sich noch an die geschickten Gesichter der Kontrolleure. Die Ursache stand jedoch noch mal selben Tag fest, bzw. es zeigte sich, dass es eine ganze Versagenskette war. Primäre Ursache war ein Überlauf einer Ganzzahlvariablen in einem Modul des Inertialsystems der Ariane 5, das man von der Ariane 4 übernommen hatte. Gegen Überläufe hatte man einige Variablen abgesichert, in dem Sinne, das sie eine Ausnahme warfen, die behandelt wurde, andere nicht, weil ein Überlauf entweder physikalisch nicht vorkommen konnte oder ausgeschlossen werden konnte. Das System schaltete sich ab und der Bordcomputer auf das Reservesystem um, das jedoch kurz danach ausfiel. Nun nahm der Bordcomputer die Fehlercodes, die als letzte Daten am Bus anlagen als reale Navigationsdaten. Da diese Daten auf eine starke Kursabweichung hindeuteten, schwenkte er die Triebwerke auf Anschlag wodurch die Ariane 5 zu diesem Zeitpunkt noch in der dichten Atmosphäre, auseinander brach und das Selbstzerstörungssystem auslöste. Das war durch die Bergung der Trümmer der Rakete und die EEPROMS mit den genauen Daten, aber auch einer Simulation des Aufstiegs an einem in drei Achsen dreh- und schwenkbaren Tischs der die Bewegung der Rakete nachahmte lückenlos nachvollziehbar.

Entsprechend sparte der offizielle Untersuchungsbericht auch nicht mit Kritik. Warum hatte man ein Modul von Ariane 4 ohne Tests einfach übernommen? Warum ging man zwar von Hardwarefehlern aus, aber nicht Softwarefehlern? Warum hielt der Bordcomputer die Ariane 5 nicht wenigstens danach auf Kurs – was ein Eingreifen der Bodenkontrolle ermöglicht hätte. Das Sahnehäubchen war aber das Softwaremodul. Warum hatte es nie bei der Ariane 4 Probleme gemacht? Nun diese hatte keine Feststoffbooster und beschleunigte nicht so stark. Bei ihr konnte ein Beschleunigungswert, der war es der überlief, niemals die Grenze erreichen, bei der dieser Überlauf stattfand. Das aber die
Ariane 5 schneller beschleunigt war eigentlich klar. Niemand hatte das überprüft. Das allerbeste: das Modul hätte zu dem Zeitpunkt gar nicht mehr aktiv sein müssen. Es hatte bei Ariane 4 einen einzigen Zweck – Daten für den Bordcomputer bereitzustellen für den Fall eines Startabbruchs in letzter Sekunde. Die eigentlichen Daten für den Bordcomputer stammten nicht von den Sensoren des Moduls, sondern der Inertialplattform. Wurde ein Ariane 4 Start nach Start der Inertialplattform, kurz vor Zünden der Triebwerke abgebrochen, so wäre ohne dieses Modul an dem Tage kein Start mehr möglich gewesen. Es lieferte solange Daten, von Beschleunigungssensoren an den Bordcomputer bis die Missionskontrolle die Inertialplattform wieder in Kontrolle hatte, so war eine Neuaufnahme des Starts ab Beginn der Synchronized Sequence möglich. Das Szenario kam auch einmal vor, nämlich bei V33 im Jahre 1989. Nach dem Abheben lieferten aber alle Navigationsdaten die Trägheitsplattform und das Modul war völlig unnötig, liefere aber 50 s lang noch Daten, die Zeit die vorgesehen war für die Übernahme der Kontrolle durch die Missionskontrolle.

Die Kirche auf dem Sahnehäubchen: Bei Ariane 5 wurden Startabbrüche in letzter Sekunde anders gehandhabt, das gesamte Softwaremodul war überflüssig. Mehr dazu auf meiner Seite über Ariane v 5 Fehlstarts.

Als hätte man sich so nicht schon blamiert, wiederholte man einen Softwarefehler zwanzig Jahre später nochmals.

Was passierte:

Als Schiaparelli, der Lander von Exomars 2016, am 16.10.2016 abstieg, warf er nach einer ballistischen Phase, in der er durch die Reibung der Atmosphäre abgebremst wurde die Backshell ab. Danach wurde der Fallschirm herausgeschossen, der ihn nun über einige Kilometer weiter abbremsen sollte. Das Entfalten des Fallschirms erzeugt Kräfte bei der der Lander 2,5 Sekunden lang stark schwankt und um die Seile rotiert. Das Schwanken und Rotieren um die Achse erzeugte in der Inertialplattform (IMU) eine kurzzeitige Sättigung, das heißt die Grenzen die erlaubt waren, wurden überschritten. Die IMU setzte ein Sättigungsflag um dies zu signalisieren. In etwa zur gleichen Zeit ermittelte die GNC Software (Guidance-Navigation-Control) aufgrund der Daten der IMU, das Schiaparelli eine räumliche Ausrichtung in der Z-Ache um -165 Grad zur Normalen hatte, also quasi kopfüber fliegt. Danach schloss sich etwas später die Abtrennung des unteren Teils der Aeroshell an und es begann die Phase, in der die Triebwerke den Lander weiter abbremsten. Die Software berechnete nun die Höhe und Geschwindigkeit. Nun wurde die (angebliche) Ausrichtung um -165 Grad relevant, denn der Cosinus von -165 ist negativ und so wurde eine negative Höhe errechnet, in diesem Falle -2500 m/s. Da die Software sich nun schon unterhalb der Oberfläche wähnte, schaltete sie die Triebwerke nach wenigen Sekunden wieder ab und Schiaparelli stürzte ungebremst auf die Oberfläche zu, wo er nach 34 Sekunden mit 150 m/s (540 km/h) aufschlug.

Auch hier attestierte der offizielle Untersuchungsbericht etliche Versäumnisse. Die IMU wurde tatsächlich durch die starken Bewegungen temporär gesättigt, aber sie war funktionstüchtig. Sie lieferte danach korrekte Daten. Verhängnisvoll war, dass das Sättigungsflag zu lange stand. Man ging innerhalb der Auslegung des Systems von einer Dauer von 15 ms aus, kommunizierte dies aber nicht mit allen Zulieferern so stand es länger als 15 ms und dies führte dann zur Fehlberechnung der Ausrichtung als nach 200 ms diese erfolgte. Wäre es nur 15 ms aktiv gewesen, die Mission wäre (zumindest was dieses Vorkommnis angeht) erfolgreich gewesen. Fatal wurde die Fehlberechnung, als die Software welche die Triebwerke betreiben sollte, die Werte nahm und nicht hinterfragte, denn wie sollte es denn sein, das man 2,5 km unter der Oberfläche befindet? Auch hier die Parallele zum Ariane 5 Fehlstart, bei dem eine enorme Abweichung vom Kurs innerhalb eines Computerzykluses (20 ms) nicht hinterfragt wurde.

Zuma: Keine Zusammenarbeit

Am 8.1.2018 startete die 47-te Falcon 9 Mission. Nutzlast war eine geheime Mission der NRO unter der offiziellen Bezeichnung „USA-280“ in Auftrag gegeben vom National Reconniassance Office (NRO) und gefertigt von Northrop-Grumman. Bekannter ist die Mission unter dem Namen „Zuma“. Weniger als eine Stunde nach dem Start meldete SpaceX einen erfolgreichen Start. Dumm nur, dass Beobachter keinen neuen Satelliten im Orbit registrierten. So kamen denn auch gleich Gerüchte auf, das etwas schiefgegangen sei. Aufgrund der geheimen Mission gab es keine Informationen seitens der NRO. Andere meinten, es wäre eine ganz besondere militärische Mission, die nach einem Umlauf sofort wieder landete, was zwar mal für das Space Shuttle, aber nie für eine Satellitenmission angedacht war. SpaceX betonte, ihre Rakete habe voll funktioniert. Northrop Grumman gab kein Statement ab. Was sich schon andeutete, wurde dann indirekt durch heraus gesickerte Informationen bestätigt. Nach dem Start findet als Nächstes das Abtrennen der Nutzlast statt. Diese ist mit der Oberstufe durch einen Adapter verbunden. Es gibt dafür Standard-Adapter, die der Hersteller der Rakete zur Verfügung stellt und die in genormten Befestigungsmöglichkeiten für den Satelliten enden. In diesem Falle war es anders. Northrop Grumman fertigte den Adapter. Die Abtrennung klappte nicht, was heute sehr, sehr selten geschieht. Danach deorbitierte sich die Oberstufe automatisch selbst, indem sie den Sauerstoff durch Überdruckventile gegen die Flugrichtung entließ, sodass das ausströmen Gas die Oberstufe samt Zuma abbremste und beide verglühten.

Das ist ein Beispiel für mangelnde Zusammenarbeit. Es ist ungewöhnlich, dass ein Satellitenhersteller nicht den Standardadapter des Raketenherstellers wählt, aber vielleicht wegen der ungewöhnlichen NRO-Nutzlast nicht so außergewöhnlich. Das er aber nicht funktioniert, ist doch sehr erwähnenswert, denn solche Adaptertrennungen sind relativ einfach aufgebaut, sie müssen auch hundertprozentig funktionieren. Üblicherweise werden zwei Teile die an Rakete und Satelliten stecken ineinander geschachtelt und ein straf gezogenes Metallband presst beide zusammen und verhindert, dass sich Stufe und Satellit sich trennen. Für die Trennung wird dieses Metallband durchtrennt z. B. durch ein pyrotechnisch betätigtes Messer oder Sprengsätze. Das ist ausgereift und erprobt. Dass es hier nicht klappte, kann viele Ursachen haben. Aber eine und die wichtigste ist wohl das Grumman die Konstruktion nie durch SpaceX testen lies oder sie so konstruiert wurde das sie nicht funktionierte. Vielleicht auch waren die Informationen seitens SpaceX nicht ausreichend. Denn das diese Firma sogar bei den Astronauten, die sie mit der Dragon befördert mit Informationen geizt, sodass diese sich schon beschwerten, sie seien nun keine Astronauten, sondern nur noch „Gäste“ ist bekannt. Warum sollte es anders sein wenn andere Firmen Informationen für den Adapter benötigen? Das ist eine mangelnde Zusammenarbeit von zwei Firmen. Ob die Mission noch zu retten gewesen wäre, ist schwer zu beurteilen. Vielleicht hätte man durch Manöver doch noch die Verbindung lösen können, notfalls hätte man den Treibstoff so entlassen können, das er die Stufe nicht abbremst und versuchen den Satelliten trotzdem in Betrieb zu nehmen. Vielleicht wäre es nicht gelungen, vielleicht die Lebensdauer durch das Zusatzgewicht stark reduziert. Aber es wäre eine Chance gewesen. Zumindest hätte man die Fehlfunktion besser untersuchbar gewesen. Aber indem die Rakete nach Schema F, ohne zu bemerken, dass es keine Veränderung des Trägheitsmoments durch verlorene Masse gab, sich deorbitiert ist auch kein Ruhmesblatt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

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