Lander Beresheet und Nusantara Satu

Zitat aus einem Raumfahrer.net-Artikel (zu einem Projekt, das auf Beresheet basiert):

[Beresheet] wurde in eine Mondumlaufbahn gebracht; allerdings kam es aufgrund eines fehlerhaften Kommandos (dessen Ursache konnte inzwischen vollständig geklärt werden) während des kontrollierten Abstiegs zur Mondoberfläche zu einem Reset des Bordcomputers und einem harten Aufprall.

https://www.raumfahrer.net/news/raumfahrt/28092019090634.shtml

Aha, das mit der vollständigen Aufklärung wusste ich noch gar nicht. Ich habe gerade mal danach gesucht, finde aber nur Vermutungen von kurz nach dem Crash, dass ein manuelles Kommando die Absturzursache gewesen sein soll (https://www.space.com/israel-beresheet-moon-crash-manual-command.html).

Hat hier jemand neuere, bessere Informationen zu der vollständigen Klärung und mag sie mit uns teilen?

Es gibt einen interessanten Bericht zu den Ursachen des Absturzes von Beresheet:

https://spacenews.com/new-details-emerge-about-failed-lunar-landings/?fbclid=IwAR1UlsRV_plLrjxT6ivwa_m6iL5LTVLjotOnhfIr7W_LkFh-v3r6w_H39Rw

Eine der beiden Trägheitsplattformen (IMU) des Landers ist beim Abstieg ausgefallen und wurde vom Computer abgeschaltet.
Das Kontrollzentrum hat draufhin Befehle hochgeladen, um die Plattform wieder zum Laufen zu bekommen.
Dieses Hochladen hat eine Kette von Reset-Befehlen im Steuersystem des Landers ausgelöst, die schließlich zur Abschaltung des Triebwerkes führten.
Gleichzeitig war es dadurch nicht mehr möglich, das Triebwerk wieder rechtzeitig in Betrieb zu nehmen.
Es war offenbar keine gute Idee, die ausgefallene IMU während des Abstiegs wieder in Betrieb zu nehmen.
Das führte nämlich zu einer Datenblockade zwischen beiden IMU und dem Zentralrechner, wodurch der Antrieb abgeschaltet und ein erneutes Hochfahren des Rechners ausgelöst wurde. Die hochgeladenen Software-Updates gingen beim Hochfahren verloren, weil sie in einem SRAM gespeichert waren.
Ohne die entsprechenden Updates konnte der Computer nicht selbstständig wieder korrekt hochfahren und das Antriebssystem blieb abgeschaltet.

Zu den Empfehlungen für künftige Landeprozeduren gehört daher, daß es möglich sein soll, die Software während des Fluges zu ändern und die Befehle
nicht so zu speichern, daß sie beim Hochfahren verloren gehen können.

Der Bericht enthält eine weitere wichtige Neuigkeit (für mich jedenfalls):

While SpaceIL has abandoned plans for a second Beresheet mission, IAI signed an agreement with Firefly Aerospace to use the Beresheet lander design as the basis for a lander called Genesis that Firefly is offering as part of its NASA Commercial Lunar Payload Services (CLPS) contract.

Während SpaceIL die Pläne für eine zweite Beresheet-Mission aufgegeben hat, hat das IAI eine Vereinbarung mit Firefly Aerospace unterzeichnet, die das Beresheet-Landerdesign als Grundlage für einen Lander namens Genesis verwendet, den Firefly im Rahmen seines NASA Commercial Lunar Payload Services (CLPS)-Vertrags anbietet.

Übersetzt mit deepl

Dann hoffen wir mal, dass aus den CLPS Verträgen etwas reales herauskommt.

Die Fehleranalyse von Beresheet möchte ich es mal etwas anders formulieren: Es war nicht der Computerglitch, der den Absturz verursacht hat, sondern der Mensch. Ja, das Hochladen hätte vielleicht glatter laufen können, aber ich erinnere mich an die Live-Übertragung. Das wurde doch wirklich in den letzten Minuten vorm Landemanöver gemacht. Und solches Updaten ist immer ein Risiko. Ich habe es so verstanden, dass eine der zwei redundanten IMUs ausgefallen ist. Dies hat der Boardcomputer erkannt und wäre auch gut mit der verbliebenen zurechtgekommen. Vermutlich wäre Beresheet also ohne das Eingreifen des kontrollzentrums sicher gelandet.

Es war nicht der Computerglitch, der den Absturz verursacht hat, sondern der Mensch. Ja, das Hochladen hätte vielleicht glatter laufen können, aber ich erinnere mich an die Live-Übertragung. Das wurde doch wirklich in den letzten Minuten vorm Landemanöver gemacht. Und solches Updaten ist immer ein Risiko. Ich habe es so verstanden, dass eine der zwei redundanten IMUs ausgefallen ist. Dies hat der Boardcomputer erkannt und wäre auch gut mit der verbliebenen zurechtgekommen. Vermutlich wäre Beresheet also ohne das Eingreifen des kontrollzentrums sicher gelandet.

Volle Zustimmung. Während eines Landemanövers hat man eigentlich Besseres zu tun, als Software-Updates zu fahren. Es sei denn, das Update wäre im Nachhinein notwendig geworden, um die Landung überhaupt noch zu Ende zu bringen, aber das wäre dann a) in dem Absturzbericht ja sicher erwähnt worden und b) ein Zeichen für schlechte Planung, also ebenfalls menschliches Versagen.