Wenn beim Absenkmanöver etwas schiefgeht …
Meist beginnt eine Mondlandung mit einem niedrigen, nahezu kreisförmigen Mondorbit. Von dort aus wird ein Absenkmanöver ausgeführt. Dieses macht aus der kreisförmigen Bahn von beispielsweise um 100 km Höhe eine leicht exzentrische, deren Periselenium bei etwa15 km liegt. Wenn die Landesonde sich dem Periselenium nähert, beginnt das große Bremsmanöver. Dieses endet beim Aufsetzen auf der Oberfläche mit einer Geschwindigkeit nahe Null.
Das Absenkmanöver ist zu klein
Das Absenkmanöver könnte geringer ausfallen als geplant. Das ist nur dann gefährlich, wenn man es nicht mitkriegt. Dann würde man zulassen, dass das große Bremsmanöver startet, obwohl das Periselenium noch zu hoch ist. Dieser Fall wurde im April dieses Jahres eindrucksvoll von der japanischen Firma ispace mit der Landesonde Hakuto R demonstriert. Die Abhilfe besteht darin, das Absenkmanöver bereits einige Umläufe vor der eigentlichen Landung zu absolvieren. Dann hat man ausreichend Zeit, um die Bahn zu bestimmen und, falls nötig, noch ein Korrekturmanöver nachzuschieben.
Die russische Raumfahrtagentur Roskosmos hat es mit Luna 25 genau so versucht. Die Landung hätte gestern, Montag, 21.8. stattfinden sollen. Das Absenkmanöver wurde bereits am Samstag, 19.8. ausgeführt. Da hätte man noch genügend Zeit gehabt, um Sachen glattzuziehen und die Sonde auf die Landung vorzubereiten.
Das Absenkmanöver ist zu groß
Bei Luna 25 fiel allerdings das Manöver deutlich zu groß aus. Das ist viel schlimmer als bei Hakuto R, denn ein zu großes Absenkmanöver führt zu einer zu niedrigen oder sogar negativen Periseleniumshöhe. Die Umlaufperiode einer niedrigen Bahn um den Mond liegt bei knapp zwei Stunden. Das heißt, man hat deutlich weniger als ein Stunde, um das Ruder noch herumzureißen und mit einem Rettungsmanöver die Bahn erst einmal so weit anzuheben, dass sie wenigstens nicht mehr die Mondoberfläche schneidet.
Danach kann man sie in Ruhe weiter stabilisieren, herausfinden, wo das Problem lag und es später noch einmal probieren. Bei dem ersten Rettungsmanöver drängt aber die Zeit. Man weiß: In weniger als einer Stunde wird es krachen und die Mission ist vorbei. Jetzt muss man eine Sequenz von Telekommandos hochschicken, die das große Bremsmanöver unterbinden, die Sonde umkonfigurieren, die inertiale Lage anpassen und rechtzeitig das Rettungsmanöver ausführen. Also viele, teilweise komplizierte Aktionen in sehr begrenzter Zeit.
Rettung: FDIR-Prozeduren
Wenn es also schon dazu gekommen ist, dass die Sonde ungewollt in eine solche Kamikaze-Bahn eingetreten ist, dann wird ein das Rettungsmanöver zwingend notwendig. Sonst ist Schicht im Schacht. Man hat keine Zeit und es dürfen keine Fehler mehr auftreten. Man sollte lieber gar nicht erst zulassen, dass es zu einer solchen Situation kommt. Erstens muss man überhaupt erst mal mitkriegen, dass etwas schiefgelaufen ist. Zweckmäßigerweise hat man im Steuerungssystem so genannte FDIR-Prozeduren definiert. FDIR steht für “Failure (bzw. Fault) Detection, Isolation and Recovery”. In diesen Prozeduren wird festgelegt, wie die Sonde auf unterschiedliche Fehlfunktionen zu reagieren hat.
Zuallermindest wird eine Fehlfunktion zeitnah festgestellt. Im gegebenen Fall könnte das so implementiert werden, dass Grenzwerte für die Manöverdauer, das Schubniveau oder das verabreichte delta-v festgelegt werden. Wird der untere oder obere Grenzwert verletzt, treten automatische Prozeduren in Kraft, um das Problem zu isolieren und der Bedienermannschaft die Möglichkeit zur Behebung zu geben.
Safe Mode und Abwarten
Wird festgestellt, dass das Absenkmanöver zu gering ist, dann ist die Landesonde erst einmal nicht in höchster Gefahr. Es muss jedoch verhindert werden, dass das große Bremsmanöver gestartet wird, denn sonst hätte man den Fall Hakuto. Es könnte angebracht sein, die Sonde in den “Safe Mode” zu versetzen – das Raumfahrzeug nimmt eine inertiale Lage ein, bei der die Solargeneratoren Sonnenlicht einfangen und nichts zu heiß oder zu kalt wird, und wartet dann ab, bis die Bedienermannschaft aktiv wird und den Safe Mode beendet.
Lag das Absenkmanöver jedoch über dem oberen Grenzwert, dann ist es schon kritischer. Idealerweise ist der obere Grenzwert so definiert, dass immer noch keine Absturzgefahr besteht, Das Absenkmanöver wird bei Erreichen des oberen Grenzwerts automatisch beendet. Auch hier muss das große Bremsmanöver unterbunden werden. Man weiß ja, dass etwas schief gelaufen ist und korrigiert werden sollte, bevor die Landung angegangen werden kann. Ein Safe Mode wäre auch hier empfehlenswert, denn es besteht die Möglichkeit einer missionskritischen Fehlfunktion. Hier sollte das Team im Kontrollzentrum erst einmal aktiv werden.
Kurz gesagt, Mondlandemissionen verlieren etwas von ihrem Schrecken, wenn man elementare Vorsichtsmaßnahmen ergreift. Am Ende steht zwar immer noch das große Bremsmanöver, bei dem es viele Dinge gibt, für die kein Plan B möglich ist. Deswegen ist eine Mondlandung bis auf Weiteres nichts ganz Alltägliches. Aber auf dem Weg dahin sollte man schon ausschließen können, dass relativ kleine Fehler die ganze Mission scheitern lassen.
Ich kann mich nur auf die Pressemitteilungen beziehen, die die Aussagen von Roskosmos zitieren. Ein Satz zu dem Absturz lässt mich annehmen, das Roskosmos die Sonde eher durch eine Fernsteuerung landen wollte und dass es wohl keine automatischen “On-board”-Notfallprozeduren gab.
Einzelne Manöver (wie das Absenkmanöver mit seiner Größe von knapp 20 m/s) werden immer per Telekommandos ausgelöst, also, wenn man will, ferngesteuert. Zuvor werden, falls vorhanden, FDIR-Prozeduren “scharf gestellt” (enable) und die jeweils aktuellen Grenzwerte (deadbands) werden gesetzt, ebenfalls per Telekommandos.
Für manche Manöver werden FDIR-Prozeduren sogar ausdrücklich “abgestellt” (disable). Das ist bei missionskritischen Manövern wie dem Lunar Orbit Insertion üblich. Man will ausschließen, dass beispielsweise irgendein Instrument, dem es gerade etwas zu warm oder kalt wird, das Bahneinschussmanöver unterbricht, wodurch die ganze Mission scheitern könnte. Bei einem nicht-missionskritischen Manöver würde man so eine FDIR-Prozedur dagegen eingeschaltet lassen, da hätte der Schutz des Instruments Priorität vor dem Manöver, das man genauso gut auch später nachholen kann.
Das große Bremsmanöver, das zum Aufsetzen auf der Oberfläche führt, kann jedoch nicht ferngesteuert oder im voraus vorgegeben werden, es muss im geschlossenen Regelkreislauf von Sensoren wie Trägheitsplattform, Radar, Sonnensensor, Gyroskopen etc. ich Echtzeit geregelt werden. Dabei müssen inder Regel die FDIR-Prozeduren abgestellt sein, denn die Landung hat Vorrang vor allem anderen.
Bei Luna 25 hätte eine richtige Implementierung von FDIR-Prozeduren dieses eigentlich unglaubliche Fehlerszenario, das da offenbar eingetreten ist, zuverlässig ausschließen müssen. Auch bei Hakuto-R wäre der eingetretene Fehlerfall nicht passiert, wenn die Sequenz fehlertolerant gestaltet und durch FDIR-Prozeduren abgesichert worden wäre.
heute (ca 14:30) folgt ja noch Indiens *Chandrayaan-3*
… da dürfen wir schon mal die daumen halten
es gibt einen Live-straem:
https://www.youtube.com/watch?v=DLA_64yz8Ss
grüssle
Tja Leute, die vierte Raumfahrtnation, der die weiche Landung auf dem Mond geglückt ist, ist Indien und nicht etwa Europa.
Na und? Europa baut Ultrapräzisions-Maschine wie Gaia und dabei nur die Astronomie für immer revolutioniert, oder schickt Sonden zum Merkur und Jupiter die in extremsten Umgebungen funktionieren, oder können sie sich vielleicht noch an Rosetta erinnern …?
Europa liegt in der Raumfahrttechnik zunehmend weit zurück. Dies gilt zwar nicht für alle Bereiche – in der Erdbeobachtung mit Umweltsatelliten nimmt Europa sogar eine führende Rolle ein. Im Großen und Ganzen hinken wir jedoch hinterher, was in zu geringen Investitionen in der Hochtechnologie liegt. Besonders daramatisch ist die Situation in der Raketentechnik, wo die Wettbewerbsfähigkeit nicht mehr gewährleistet ist und Europa zudem über keine Schwerlastfähigkeit verfügt.
Sehr geehrter Herr Khan,
Ihre beiden Texte lesen sich für mich so, als ob sowohl die russische als auch die japanische Mission Selbstverständlichkeiten unterlassen hätte.
Nun kann ich mir bei der russischen Mission sehr wohl vorstellen, dass nun aber wirklich ein Prestigeobjekt gebraucht und dafür alle warnenden Hinweise der Ingenieure hinweggewischt wurden. Sowas soll zu Sowjetzeiten ja auch schon mal vorgekommen sein.
Das gilt für die Japaner aber meines Erachtens nicht.
Was könnte dann aus Ihrer Sicht der Grund für das Nicht-Vorsehen der von Ihnen für selbstverständlich gehaltenen Prozeduren gewesen sein?
Was für “die Japaner” gilt oder nicht gilt, darüber maße ich mir kein Urteil an.
Im Falle von ispace ist es meines Erachtens so, dass ein kleines Start-up-Unternehmen (in diesem Fall ein japanisches) in der Planung eines schwierigen Unterfangens nicht alle Möglichkeiten zur Maximierung der operationallen Sicherheit ausgeschöpft hat. Das hat sich dann gerächt.
Hätte, hätte Fahradkette 🙂
Luna25 hatte nach Beginn des Absenkmanövers 47 min bis zum Crash Zeit, die überschüssige Bremsung rückgängig zu machen. Das hätte aber unmittelbar erfolgen müssen, als Reaktion ziemlich illusorisch.
Hier hat ein Plan B für den Notfall gefehlt. Als man gemerkt hat, daß die Bahn zu tief liegt – Not-aus-Knopf.
In einer Höhe über Grund von 18 km hätte die Landesequenz eingeleitet werden müssen, dann wäre die Sonde automatisch eben bei ca 55° südlicher Breite, und nicht bei 73° gelandet, also nur iwie 20° vorher.
Die wissenschaftliche Mission hätte dort mit vergleichbaren Ergebnissen durchgeführt werden können.
Vielleicht sollte man solche Ausweichszenarien zu Rettung zukünftig in die Flugware integrieren.
Die Notrettung hätte darin bestanden, ein Manöver durchzuführen, das die Bahn bei einer niedrigeren Höhe zirkularisiert. Dafür hätte man jedoch keineswegs noch 47 Minuten Zeit gehabt. Zudem hätte das Manöver nochmals delta-v gekostet, und zwar Minute für Minute, die man es später durchführt, mehr delta-v. Aber man muss erst einmal merken, dass man ein Problem hat. Dann muss man verstehen, was genau das Problem ist. Dann muss man berechnen, was man für ein Manöver braucht. Dann muss man die Sequenz von Telekommandos erstellen und hochsenden … und wahrscheinlich ist es dann zu spät
Das Landen in einer komplett unvorhergesehenen Region kann nicht wirklich ein Auswechszenario sein. Es gibt viele Gründe, das nicht zu tun, und obendrein müsste man wieder auf die Schnelle Telekommandos erstellen, denn das Abstiegsszenario ist dann ja ein anderes.
Weder das Rettungsmanöver ist der Weg, den man gehen sollte, noch die Einleitung des Notabstiegs irgendwo anders. Das muss man ja auch nicht, wenn man mit der Festlegung durchdachter FDIR-Prozeduren einen zuverlässigen Weg hat, um das Problem ganz zu vermeiden.
Man muss das mal festhalten: Wir hatten allein dieses Jahr zwei Abstürze von Mondsonden, die auf leicht vermeidbare Nachlässigkeiten beim Durchführen eines kleinen Absenkmanövers zurückzuführen sind.
Klar, an den beiden Fehlschlägen lässt sich im nachhinein nichts mehr ändern. Ich wollte eigentlich auch nur ein paar Denknanstöße geben, was man machen könnte, damit zumindest der eine oder andere an und für sich eher kleine Fehler gleich einen Missionsverlust nach sich zieht. Das ist allemal besser, als alles fatalistisch hinzunehmen.
Vielen Dank für die Anregungen. Schade, dass keine weiteren Details zu der fehlerhaften Ausführung des Luna 25-Absenkmanövers bekannt sind. Mich hätte durchaus interessiert (neben der offenbar unzureichenden Implementierung von FDIR-Prozeduren), warum das Bremsmanöver 127 Sekunden lang (anstelle von angeblich geplanten 84 Sekunden !?) ausgeführt wurde und wann tatsächlich dieser Fehler bei der Roskosmos-Missionskontrolle bemerkt worden ist.
Es wäre in der Tat interessant, das zu erfahren. Das werden wir aber nur, wenn Roskosmos etwas publik macht. Es ist mir nicht bekannt, ob das geschehen wird, und falls ja, wann.
Ich selbst habe auch nur Zugang zu öffentlich einsehbaren Quellen (beispielsweise hier) und kann deren Zuverlässigkeit manchmal nur schwer beurteilen. Natan Eismont halte ich (wie auch viele meiner Kollegen) für eine sehr zuverlässige Quelle, aber mir fehlt der genaue Wortlaut seiner Aussage zu diesem Thema. Bei Anatoly Zaks Aussagen bin ich dagegen lieber etwas vorsichtig.
Es ist auch nicht bekannt ob die ESA den Untersuchungsbericht (falls überhaupt einer existiert) zum Huygens-Datenverlust jemals (zu unseren Lebzeiten) publik macht. SO?!
Wovon reden Sie? Es ist schon seit kurz nach der Huygenslandung bekannt, und auch publik, wie es zu dem Datenverlust kam. –> Siehe hier
Die Veröffentlichung der Untersuchung, die meiner Erinnerung zufolge in diesem Artikel (der mittlerweile hinter einer Paywall verschwunden ist) angekündigt wurde ist nie passiert.
Aber wenn sie alle genauen Umstände kennen, wie es zum Datenverlust kommen konnte – vielleicht eine gute Idee für einen Blogartikel. Ich wäre sehr dankbar.
Entschuldigung, das mit der Paywall hatte ich nicht gesehen. Da steht nicht mehr drin als das, was damals bereits der Persse mitgeteilt wurde. Das Kommando zum Einschalten des Empfängers für den S-Band-Kanal A auf Cassini war nicht im Telekommando-Stapel enthalten, weil jemand einen Fehler gemacht hatte. Andere hätten das überprüfen sollen, haben’s aber nicht gemerkt. Sowas passiert halt mal. Sollte es natürlich nicht, kommt aber trotzdem vor.
Ich weiß jetzt nicht, was eine großmächtige Untersuchung weiter hätte herauskriegen können als “Einer hat Mist gemacht und ein anderer hat’s nicht gemerkt”.
Ich war an der Sache übrigens nicht beteiligt. Mir wäre so ein Fehler zwar sehr wohl zuzutrauen, aber das weiß auch jeder. Deswegen lässt man einen wie mich an Telekommandogenerierung gar nicht erst ran. Insofern funktionieren also die Vorkehrungen zur Qualitätssicherung durchaus.
Vielen Dank für diesen informativen Beitrag über bekannte Fehlerbehandlungsprozeduren bei Mondmissionen (wohl auch Marsmission etc.).
So wie sie es beschreiben, gibt es also bei Mondlandungen so etwas wie einen Standard der Fehlerbehandlung. Wobei das Wesentliche wohl gerade ist, dass man Fehler nicht ausschliesst und Routinen implementiert, die Fehler begrenzen.
Die von ihnen beschriebenen FDIR-Routinen werden von der NASA etwa in Operations erwähnt.
Wenn jetzt Startups bei ihren Mondlandungsversuchen diese Routinen nicht implementieren oder wenn nach Jahrzehnten der Flugpausen eine neue Mondmission ebenfalls FDIR nicht richtig implementiert, dann muss man sich meiner Meinung nach fragen, ob die Professionalität im Raumflugbereich genügend hoch ist. Denn bei anderen reifen Disziplinen – etwa Brückenbau – werden Standardprozedere bereits in den Lehrbüchern detailliert beschrieben und es gibt inzwischen Software, die einem vieles abnimmt. Ich würde erwarten, dass auch in der Raumfahrt etwa FDIR-Verfahren detailliert in Lehrbüchern beschrieben werden und es sogar so etwas wie Open-Source Implementationen gibt, mit denen der Interessierte herumspielen kann. Das scheint aber (noch) nicht der Fall zu sein.
Es kann natürlich sein, dass FDIR-Prozeduren sauber implementiert waren. Man kann jetzt spekulieren, dass der Fehler, der zu dem exzessiven Absenkmanöver führte, eine FDIR-Prozedur auslöste, die das Manöver beenden sollte. Aber eine zweite Störung verhinderte, dass die zwangsweise Beendigung stattfand. Das kann natürlich so gewesen sein. Ich weiß es nicht, aber es kommt mir nicht wahrscheinlich vor.
Hätte offenbar alles mit geeigneten FDIR-Prozeduren vermieden werden können:
https://t.me/frnved/1644 (Russisch)
automatisch übersetzt liest sich das so:
Erfahren Sie mehr über die Gründe, die zum Absturz von Luna 25 führten. Jetzt, nach der offiziellen Stellungnahme von Roskosmos, können wir alles im Detail klären.
RK-Wortlaut:
„Es wurde festgestellt, dass die wahrscheinlichste Ursache des Luna-25-Unfalls die abnormale Funktion des Bordkontrollkomplexes war, die mit dem Versäumnis verbunden war, die Beschleunigungsmessereinheit im BIUS-L-Gerät (Winkelgeschwindigkeitsmessung) einzuschalten Einheit) aufgrund der möglichen Einbeziehung von Befehlen mit unterschiedlichen Prioritäten für deren Umsetzung …“
Lassen Sie uns nun aus der Sprache der Ingenieure ins normale Russisch übersetzen.
Der Ausfall ereignete sich in einer komplexen Kombination mehrerer auf Luna-25 installierter Computer. Der erste und wichtigste von ihnen, der Onboard Control Complex (BCU), stellte die Funktionsfähigkeit des gesamten Raumfahrzeugs und seiner verschiedenen Systeme sicher. Zu seinen Aufgaben gehörte die Interaktion mit BIUS-L (er zeichnete Geschwindigkeitsänderungen von Luna-25 auf und informierte die BKU darüber).
Doch das Zusammenspiel ließ uns irgendwann im Stich: Der Bordcomputer sendete plötzlich mehrere Befehle gleichzeitig an den BIUS-L und der BIUS erlebte einen „Systemausfall“. Dadurch verpasste er den wichtigen Befehl „Schalten Sie die Beschleunigungsmesser des Geräts ein“ an seinen metallenen „Ohren“ vorbei. Und er musste endlich den Zeitpunkt bestimmen und dem Motor rechtzeitig ein Signal zum Abstellen geben. Wie MK bereits berichtete,
Leider war das BKU-Programm so geschrieben, dass es die Antwort des BIUS „nicht hörte“ – ob es den Befehl des Bordkontrollkomplexes verstand. Und das war das Problem: Er verstand den Befehl nicht. Infolgedessen geschah Folgendes: Die Motoren des Geräts arbeiteten hart, um langsamer zu werden, und der BIUS sendete, ohne den Prozess zu steuern, denselben Befehl an den Bordcomputer: „Es gibt keine Verlangsamung durch den Motorbetrieb.“ Der auffälligste Vergleich lässt sich mit einem Flugzeug machen, das im Nebel landet. In diesem Fall fliegt der Pilot nur gemäß den Messwerten der Instrumente, und während einer normalen Landung „sagt“ einer von ihnen – der Höhenmesser: 15 Meter – 10 Meter – 5 Meter usw. Und ein nicht funktionierender Höhenmesser würde wiederholen: 15 Meter – 15 Meter – 15 Meter. Und der Pilot, der dem Höhenmesser vertraute, hätte den Flug fortgesetzt und gedacht, dass seine Höhe immer noch 15 m betrug, obwohl es in Wirklichkeit völlig anders war … Wenn an Bord der Luna-25 eine Person gewesen wäre, hätte er es getan Aus dem objektiven Bild von außen wurde klar, dass die Technologie nicht die Wahrheit sagt, aber an Bord der Luna-25 befand sich kein Mensch …
Infolgedessen entstand eine gravierende Diskrepanz: Nachdem die BKU die erforderliche Geschwindigkeit und Höhe erreicht hatte und auf die gewünschte 18-Kilometer-Umlaufbahn abgesunken war, musste sie den Motor abstellen. Da jedoch kein Signal vom BIUS kam, verpasste er den Moment des Abstellens des Motors. Dadurch funktionierte es beim Abstieg zu lange und das Gerät blieb regelrecht in der Oberfläche stecken.
Das Enttäuschendste ist, dass es nicht das schwierigste Manöver war. Einige Tage zuvor schloss Luna-25 eine viel komplexere Aufgabe erfolgreich ab, bei der auch der Bremsmotor eingeschaltet wurde und sich das Gerät vorsichtig von der interplanetaren Flugbahn in eine kreisförmige Mondumlaufbahn bewegte. Wer hat das Programm für die BKU geschrieben? Programmierer der nach ihr benannten NPO. Lawotschkina. Wir hatten keine Zeit, das Programm in Zusammenarbeit mit dem BIUS gründlich zu überprüfen. Warum hattest du keine Zeit? Ist das eine Frage. Vielleicht war es eine Fehleinschätzung der Organisatoren, vielleicht hat es viel Zeit gekostet, das Programm zu schreiben. Nicht der Punkt. Es ist wichtig, dass die Jungs weiterarbeiten, denn sie wissen jetzt viel mehr über das Mondlandesystem als zuvor. Weitere Details im heutigen Material „MK“ (https://www.mk.ru/science/2023/10/03/stali-izvestny-detali-konflikta-kompyuterov-na-lune25-privedshie-k-katastrofe.html)
http://www.mk.ru (https://www.mk.ru/science/2023/10/03/stali-izvestny-detali-konflikta-kompyuterov-na-lune25-privedshie-k-katastrofe.html)
Details zum Computerkonflikt auf Luna-25, der zur Katastrophe führte, sind bekannt geworden
Am 4. Oktober feiert unser Land den 66. Jahrestag des Beginns des Weltraumzeitalters, also des Starts des ersten künstlichen Erdsatelliten durch die Sowjetunion. Zufällig veröffentlichte Roscosmos kurz vor dem Feiertag vorläufige Ergebnisse der Arbeiten zur Ermittlung der Ursachen des Absturzes von Luna 25. Was können Sie tun, Sie können nicht vor der Realität davonlaufen. Es ist gut, dass den Spezialisten jetzt alles klar ist und sie aufgrund dieser Erfahrung beim nächsten Start von Luna-26 mit Sicherheit keine früheren Fehler wiederholen werden. Der MK.s-Kolumnist hat auch die Einzelheiten der erfolglosen Landung des Geräts herausgefunden.