Insider präsentiert Mission Beresheet
BLOG: Go for Launch
Die spendenfinanzierte israelische Mondlandemission Beresheet, durchgeführt von der Non-Profit-Organisation SpaceIL wurde am 22. Februar 2019 gestartet und zerschellte 7 Wochen später, am 11. April 2019 beim Versuch, weich im Mare Serenitatis zu landen.
Heute stellte der israelische Ingenieur Yoav Landsman die Mission bei einem etwa einstündigen Vortrag am ESOC in Darmstadt vor. Landsman war 6 Jahre lang leitender Systemingenieur und auch stellvertretender Missionsleiter bei Beresheet.
Ich gebe im folgenden das wieder, was ich heute von Yoav Landsman gehört habe. In Wikipedia und anderen Quellen steht zu einigen Details etwas anderes. Nichts von dem, was hier steht, ist wirklich neu. Immerhin geschah alles schon vor vier Monaten und wurde weithin berichtet. Trotzdem bin ich froh, diesen Bericht aus erster Hand gehört zu haben.
Beresheet – Entstanden aus dem Google Lunar X-Prize
Die Organisation SpaceIL war mit ihrer Mission eine der 33 am Google Lunar X-Prize (GLXP) teilnehmenden Gruppen. Beim GLXP ging es darum, vor einem festgelegten Datum mit einer robotischen Raumsonde auf dem Mond zu landen und sich mindestens 500 Meter vom Landeort weg zu bewegen. Der Erfolg musste durch zur Erde gefunkte HD-Videos dokumentiert werden. Das Datum wurde mehrfach nach hinten verschoben – zuletzt auf den 31.3.2018.
Keines der Teams hielt die Deadline ein. SpaceIL war mit der Entwicklung von Beresheet im April 2018 jedoch schon so weit, dass man beschloss, auch ohne Aussicht auf die 20 Millionen Dollar Preisgeld weiterzumachen, die dem Gewinner des GLXP gewunken hätten. Die GXLP-Anforderung der Mobilität nach der Landung wurde fallen gelassen – man ging zu Recht davon aus, dass bereits die weiche Landung schon eine genügend hohe Herausforderung darstellte.
Auf der Oberfläche sollte Beresheet nur begrenzte Zeit weiter funktionieren. Die thermische Regelung im Orbit ist eine Sache, die auf der sonnenbeschienenen Mondoberfläche eine ganz andere. Es war klar, das Beresheet nach der Landung überhitzen und ausfallen würde. Aber dazu kam es ohnehin nicht mehr.
Beresheet – eine Low-Cost-Mission
Landsman nannte für die gesamten Missionskosten, also Entwicklung und Bau der Raumsonde, Start, Operationen und Bodensegment inklusive Nutzung eines Netzwerks von Bodenstationen eine Zahl von 100 Millionen Dollar. Die Entwicklungszeit betrug 4.5 Jahre.
(Anmerkung MK: Bevor jetzt gleich wieder das große Lamento losgeht, wie immer, wenn eine Zahl genannt wird: 100 M$ ist für ein technisches Projekt, …
- bei dem viel Entwicklungsarbeit geleistet wird und an dem deswegen viele hochqualifizierte Leute mitarbeiten müssen
- bei dem man nicht alle Technik einfach von der Stange kaufen kann
- das sich über mehrere Jahre hinzieht
… nicht besonders viel. Für das Geld kriegt man gerade mal ein modernes Kampfflugzeug. Wenn man Glück hat oder bereit ist Abstriche hinzunehmen. Man kann beim Düsenjäger aber durchaus auch mehr loswerden. Deutlich mehr. )
Beresheet war eine kleine Raumsonde. Sie sah aus wie eine Tonne auf Beinen. Etwa anderthalb Meter hoch und mit anderthalb Metern Durchmesser. Die Leermasse(“dry mass”) betrug rund 150 kg, die Masse vollgetankt (“wet mass”) weniger als 600 kg.
Beresheet war keine wissenschaftliche Mission. Deswegen war auch die wissenschaftliche Ausstattung limitiert. Neben einem Magnetometer und einem Laserreflektor-Array war natürlich die Kamera an Bord, mit der die erfolgreiche Landung dokumentiert werden sollte.
Beresheet-Hersteller: IAI
SpaceIL ging für die Entwicklung und den Bau der Raumsonde und die Beschaffung der Komponenten eine Partnerschaft mit dem staatlichen israelischen Luft- und Raumfahrtunternehmen IAI (Israel Aerospace Industries) ein. Verständlicherweise, denn es ist kaum vorstellbar, dass eine kleine Startup sich das Know-How, über das ein großes Unternehmen verfügt, in kurzer Zeit selbst aufbauen kann.
Beresheet-Landeort: Mare Serenitatis
In Zusammenarbeit mit dem Weizmann Institute of Science wurde der Landeort im Norden des Mare Serenitatis festgelegt. Dort ist eine magnetische Anomalie bekannt. Dieses Institut lieferte auch das Magnetometer für Beresheet. Als Landeungenauigkeit wurde 15 km genannt – ich weiß allerdings nicht mehr, ob es sich bei diesem Wert um den Durchmesser oder den Radius der vorgesehenden Landezone handelt.
Der Aufschlag von Beresheet erfolgte laut Landsman 13.4 km vom Zielpunkt entfernt, was auch zu erwarten ist. In der letzten Phase des Abstiegs fliegt eine Landesonde recht steil nach unten. Die Triebwerke sind zu dieser Zeit fast ausschließlich damit beschäftigt, die Vertikalgeschwindigkeit zu reduzieren, sodass idealerweise bei knapp über 0 Meter Flughöhe 0 m/s an Geschwindigkeit erzielt werden.
Auch wenn die weiche Landung nicht gelingt, kommt die Sonde zwangsläufig ziemlich nahe am anvisierten Ort runter. So auch hier.
Bodenstationen
SpaceIL war zunächst davon ausgegangen, gegen Entgelt Unterstützung von der Swedish Space Corporation SSC mit ihren Bodenstationen in Kiruna (Schweden), Haartebeesthoek (Südafrika), Dongara (Asutralien), Santiago (Chile), Hawaii und Weilheim (Deutschland) zu bekommen.
Nach dem LOI am 4.4. erhielt SpaceIL jedoch auch unvorhergesehen kostenlose Unterstützung durch das NASA DSN in Goldstone, Madrid und Canberra mit zeitweise vier Antennen, darunter zwei der 70-Meter-Schüsseln.
Beresheet-Start mit der Falcon 9
Der Start wurde als Dienstleistung beim Unternehmen Spaceflight eingekauft. Spaceflight kauft überschüssige Nutzlastkapazität ein ud verkauft sie an Betreiber kleiner Satelliten weiter.
Angenommen, Sie haben einen Satelliten. Der soll ins geostationäre Transferorbit. Seine Startmasse liegt bei 4000 kg. Die vorgesehene Rakete würde in das vorgesehene Startorbit aber 5000 kg schaffen. Dann wenden Sie sich an ein Unternehmen wie Spaceflight. Das setzt sich mit dem Raketenbetrieber ins Einvernehmen und bietet die Dienstleistung seinen Kunden an.
Die Firma Spaceflight bietet einen zusätzlichen Nutzlastadapter, der auf dem Hauptpassagier montiert wird und in diesem Fall zwei weitere Raumfahrzeuge trug, Beresheet und einen US-Satelliten.
Im Fall des Starts von Beresheet war der Hauptpassagier der Falcon 9-Rakete von SpaceX ein indonesischer Nachrichtensatellit. Das Zielorbit des Starts war ein Super-GTO mit Peri- und Apogäumshöhen von 500 und 70,000 km.
Transfer zum Mond und Probleme
Von dieser Bahn aus ist es noch ein weiter Weg zum Mond. Beresheet absolvierte zuächst eine Serie von Manövern am Perigäum seiner Bahn, die das Apogäum anhoben, bis es die Mondbahn erreichte.
Dabei hatten das Team im Kontrollzentrum von vorneherein mit Problemen zu kämpfen. Eine der Ursachen war die Belastung durch geladene Teilchen (vorwiegend Elektronen udn Protonen) beim Durchgang durch die Van-Allen-Gürtel. Da das Startorbit eine Perigäumshöhe von nur 500 km hatte, durchquerte Beresheet auf jedem Umlauf zwei Mal die Zonen hoher Teilchenflussdichten.
Das führte zu jeder Menge Probleme. Zum einen versagte der Sternsensor. Die Ursache ist laut Yoav Landsman immer noch nicht bekannt. Vermutet wird entweder ein Effekt der Teilchenstrahlung oder Kontamination (Anmerkung MK: Leider habe ich vergessen zu fragen, ob eine Kontamination des Sensors oder der Vergütung der Optik gemeint ist).
Hinzu kam ein häufiges Reset des Bordcomputers (bis zu 1x pro Minute). Der konnte zwar immer wieder gestartet werden. Aber viele Parameter der Onboardsoftware mussten durch Patches nachgeladen werden. Diese Änderungen waren immer wieder gelöscht, wenn der Computer neu startete, denn der bezog seine Referenz aus der im EEPROM abgelegten Urversion. Dies hatte ernste Konsequenzen, wie weiter unten beschrieben.
Einer dieser Resets führte zum Abbruch eines vorgesehenen Triebwerksmanövers. Das Steuerungsteam von SpaceIL veränderte daraufhin die Zugriffsrechte der Steuerungssoftware auf laufende Manöver so, wie es für wirklich kritische Manöver wie den Einschuss in die Mondbahn vorgesehen war. Das erhöhte zwar das Risiko, dass eine wirkliche Fehlfunktion nicht abgefangen werden konnte, verringerte aber das Risiko durch unbegründete Computerfehler.
Ein anderes Problem betraf die Bahnbestimmung, die sich laut Yoav Landsman als unglaublich kompliziert und aufwändig darstellte. (Anmerkung MK: Den Grund konnte ich leider nicht in Erfahrung bringen, obwohl es mich brennend interessierte)
Der Absturz
Als Beresheet am 11. April 2019 zur Landung ansetzte, war die Raumsonde bis kurz vor Beginn des letzten Bremsmanövers noch hinter dem Mond und damit im Funkschatten des Mondes, und wie ich vermute, auch im Mondschatten und damit unter Stromversorgung der Batterien (Anmerkung MK: Ich vermute, es muss im Funkschatten bereits das erste Manöver zum Absenken des Periseleniums über dem Mare Serenitatis gegeben haben).
Man hatte an dem Tag einige Unregelmäßigkeiten mit der Lageregelung festgestellt. Eine Ursache dafür könnte Schwappen des Treibstoffs gewesen sein (Anmerkung MK: engl.: “fuel sloshing”. Mir ist aber nicht klar, wie das mit der von Yoav Landsman beschriebenen “attitude drift” zusammenhängen kann).
Das eigentliche lange Landemanöver, das inklusive Gravitationsverluste mehr als 1850 m/s umfassen muss, also wirklich groß ist, begann erst nominal. Als Beresheet sich jedoch der Mondoberfläche näherte, gab es wieder Störungen unbekannter Ursache, die laut Yoav Landsman mit den Umgebungsbedingungen zusammenhängen kännen, beispielsweise starken elektrostatischen Feldern.
Durch Software wurde eine der IMUs (Inertial Measurement Unit, die inertiale Plattform, die aus Beschleunigungssensoren und Gyroskopen die Position, Geschwindigkeit und inertiale Ausrichtung bestimmt) abgeschaltet.
Die Kontrollmanschaft war der Ansicht, dass mit der IMU alles in Ordnung sei, und sandte das Kommando, sie wieder hochzufahren. Aus unbekannten Gründen führte dies jedoch zu einer Kaskade von Ereignissen, in deren Folge es zum Reset des Bordcomputers und zum Löschen aller Parameter kam, die in Vorbereitung der Landung geändert worden waren. Dies stoppte das Bremstriebwerk zu einer Zeit, in der man es gar nicht gebrauchen kann.
Yoah Landsman antwortete auf die Frage “What would you have done differently, given the chance?” spontan: “I wouldn’t have tried to restart that IMU”. Danach ging alles den bach runter und selbst wenn das Triebwerk wieder gestartet werden konnte, wie in der Presse zu lesen ist, reichte die Zeit offenbar nicht mehr, um die verbleibende Orbitalgeschwindigkeit plus der Zunahme der Fallgeschwindigkeit während des Triebwerksausfalls noch herauszunehmen. Zudem ist nicht klar, ob die inertiale Ausrichtung nach Stoppen und Neustart des Triebwerks noch stimmte. Falls nicht, wäre die Landung ohnehin aussichtlos.
Was ich aus dem Vortrag mitnahm
Natürlich war mir die Geschichte von Beresheet nicht neu, aber der Vortrag von Yoav Landsman hat mir dennoch gefallen, schon wegen der vielen kleinen Ingenieursdetails.
Ich bin allerdings der Meinung, ob die Steuerung einer Landung funktioniert, sieht man erst auf den letzten Metern. Während der ersten 95% brenht das Triebwerk vor sich hin und die Lage ändert sich langsam von horizontal zu vertikal. Das aber stellt noch keine große Herausforderung für ein rechnergesteuertes System dar.
Kurz vor dem Aussetzen kommt aber alles zusammen. Das Triebwerk muss Schub zurücknehmen und genau im richtigen Moment aussetzen. Dann muss, dicht über der Oberfläche, aber nicht zu dicht, die vertikale und die horizonate Geschwindigkeit gleich Null sein. Das alles ist nicht einfach und auch nicht allein von der IMU zu steuern, sondern es müssen Daten vom Radar oder Lidar die Steuerung übernehmen.
Selbst wenn es vorher klappt, heißt das noch lange nicht, dass es auf den letzten Metern klappt. Das gilt hier, aber es gilt ebenso für Schiaparelli auf dem Mars.
Und andersherum: Wenn es schon in der relativ problemlosen Phase ein ernstes Problem gibt, dann kann man nicht davon ausgehen, das Steuerungssystem habe sich bewährt. Man hat schlicht keine Information darüber, wie es in der wirklich ernsten Phase zugegangen wäre.
Mein Eindruck ist, dass die Mission auch mit 100 M$ noch unterfinanziert war. Die Sache mit dem zu kleinen EEPROM, die Probleme mit Computer und Hardware, die Schwierigkeiten mit der Bahnmechanik … all das riecht nach Sparzwang und unzureichender Vorbereitung, vielleicht auch zuwenig Personal. Es fehlte vielleicht nicht mehr sehr viel, aber es fehlte etwas – obwohl das Projekt ja auch noch unerwartete Geschenke bekommen hatte wie die kostenlose Versorgung mit NASA-DSN-Bodenstationen während der einwöchigen Mondumkreisungsphase.
Erstaunlich wie komplex so eine private Mondlandung auch heute noch ist. Und was für einen Überwachungs- und Bugfix-Aufwand es beim Anflug und der Landung bedeuten kann. Es braucht also nicht nur Designer, Konstrukteure und Zuflieferer, sondern auch kompetente Tester und eine ständige Überwachung durch das Bodenpersonal, welches die Instrumente und ihre Sollwerte genau kennen und die sich zu helfen wissen, wenn etwas nicht so läuft wie vorgesehen.
100 Millionen Gesamtaufwand für die Beresheet Mondmission sind dann auch 5 Mal mehr als die 20 Millionen Lunar X-Preisgeld. Die Idee hinter einem Preisgeld von 20 Millionen war ja wohl, dass diese Summe gerade die Unkosten denkt. Doch weit gefehlt. Es kostete 5 Mal mehr und war erst noch ein Misserfolg.
Nach der Mondlandung hätte die NASA das Ziel setzen können, jedes Jahr eine je 100 Millionen US-Dollar (in 1970er Dollars) teure unbemannte Mission zum Mond (jedesmal eine andere Destination) zu schicken.
Mit den Langfristzielen:
1) eine standardisierte, möglichst kostengünstige Mondrakete und zugehörigen Mondlander zu entwickeln und zu optimieren
2) Die Teleoperationen Mond/Erde zu perfektionieren und teilautonome kleine Mondfahrzeuge zu entwickeln
Solch ein Langfrist-Programm hätte sowohl der Raumfahrt als auch der Technologie allgemein viel gebracht. Vielleicht wären dann selbstfahrende Fahrzeuge 10 Jahre früher gekommen und Lidar wäre vielleicht schon längst ein Billigartikel.
Schade um die 100 M$. Vielleicht hätte man Hard- und Software etwas gründlicher entwickeln sollen. Wo ist denn da die Erfahrung von 50 Jahren Raumfahrt?
Die indische Mars-Orbiter-Mission (MOM ,Mangalayaan) soll 73 Millionen US-Dollar gekostet haben – und alle 3 Punkte, die gemäss Michael Khan eine Mission teuer machen treffen auch auf diese Mars-Mission zu, also folgendes
– bei dem viel Entwicklungsarbeit geleistet wird und an dem deswegen viele hochqualifizierte Leute mitarbeiten müssen
– bei dem man nicht alle Technik einfach von der Stange kaufen kann
– das sich über mehrere Jahre hinzieht
In der Wikipedia zur Mangalayaan-Mission liest man folgende Begründung für die tiefen Kosten (übersetzt von google translate):
Die geringen Kosten der Mission wurden von K. Radhakrishnan, dem Vorsitzenden der ISRO, auf verschiedene Faktoren zurückgeführt, darunter ein “modularer Ansatz”, wenige Bodentests und lange Arbeitstage (18 bis 20 Stunden) für Wissenschaftler. [41] Jonathan Amos von der BBC erwähnte niedrigere Arbeitskosten, einheimische Technologien, ein einfacheres Design und eine deutlich weniger komplizierte Nutzlast als MAVEN von der NASA.
Nun, einige Punkte davon sind generell zu beherzigen, nämlich: ein “modularer Ansatz”, ein einfaches Design und eine wenig komplizierte Nutzlast.
Bei Lunar-X-Price war die vorgegebene Nutzlast wenig kompliziert, denn der Mond-Lander musste lediglich ein Gefährt mitführen, das mindestens 500 Meter weit kam und es galt ein paar Videos zur Erde zurückzuschicken.
Ob das Design des Beresheet-Landers einfach war, kann ich nicht beurteilen. Es scheint aber, dass dieses Design wiederverwendet wird wie man im Artikel Israel’s failed lunar lander will live on in the design of Firefly Aerospace’s new Moon spacecraft liest:
Das US-Unternehmen Firefly Aerospace gab bekannt, dass es mit der Israel Aerospace Industries (IAI) eine Partnerschaft eingeht, um ein neues Mondfahrzeug zu entwickeln, das auf den Entwürfen der verunglückten Raumfahrzeuge basiert. Firefly sagt, dass dieser Lander auf den “Erfahrungen” aus dem Unfall aufbauen wird, um sicherzustellen, dass der neue Lander nicht das gleiche Schicksal trifft.
Designs sollten meiner Ansicht nach wenn immer möglich wiederverwendet werden – vor allem Designs, die sich bewährt haben (was man bei Beresheet allerdings nicht sagen kann).
Ein Beispiel für eine erfolgreiche Wiederverwendung eines Designs ist wohl die RD-180, ein russischer Raketenmotor, der schliesslich von United Launch Alliance (ULA) für die Booster der ersten Stufe verwendet wurde.
Die 100 Millionen wurden ja nicht zum Mond geschossen, sondern sie stecken in etlichen Personenjahren gewonnener Erfahrung bei den beteiligten Industrieunternehmen.
Wenn man eben nicht das Geld hat, das man brauchen würde, um ein zuverlässiges Design hinzulegen, muss man das Risiko akzeptieren, das mit einem weniger guten Design und weniger gründlichen Tests einhergeht.
So ist das Leben. Sparen kann manchmal richtig teuer werden.
MOM war ein Orbiter, nicht ein Lander. Ein Orbiter, selbst wenn er um einen anderen Himmelskörper als die Erde fliegen soll, unterscheidet sich nicht fundamental von einem Erdsatelliten. Eine andere Avionik, größere Tanks, größere Antennen … das sind alles nur Deltas. Man kann schon sehr viel von der Stange nehmen. Gerade da, wo das Testen sehr aufwändig wird, nämlich bei der Onboardsoftware, ist das ein wesentlicher Sparfaktor.
Bei einem Lander ist das eine ganz andere Sache. Know-How und vorhandene Hardware von Satelliten ist da nur bedingt hilfreich. Und auch die Tatsache, dass jemand das schon vor 50 Jahren geschafft hat, hilft erst einmal nicht weiter.
Die Anforderungen beim GLXP (Prize, nicht Price) sind nicht ganz ohne. Erstens die weiche Landung. Dann die Mobilität auf der Oberfläche. Entweder kann das gelandete Fahrzeug wieder abheben und ein Stück entfernt landen, oder es führt einen Rover mit. Der Rover muss aber auch entwickelt, gebaut und getestet werden. Das ist dann noch einmal eine ganz andere Aufgabe als der Bau des Landers.
Da stellt sich die Frage: Wie testet man einen Mondlander? Etwa gleich wie die ESA ihren Marslander (ExoMars) getestet haben? Test durch reales Landen (oder crashen) also.
Eine weiche Mondlandung ist in mancher Hinsicht technisch einfacher, in anderer Hinsicht schwieriger zu bewerkstelligen als der eines Marslanders. Das ergibt sich aus der Tatsache, dass es am Mars eine Atmosphäre gibt.
Der Marslander braucht also einen Hitzeschild. Der muss der thermischen und mechanischen Belastung standhalten und er muss zuverlässig abgesprengt werden, ohne dass seine Komponenten danach noch einmal mit dem Rest der Landesonde in Kontakt kommen. Die thermische und strukturelle Festigkeit kann man durch Rechnen hinreichend genau nachweisen. Das Risiko des Rekontakts kann durch die Auslegung minimiert werden.
Dann braucht der Marslander einen Fallschirm. Der muss innerhalb eines engen Geschwindigkeits- und Höhenfensters ausgefahren werden. Die Dynamik kurz nach dem Ausfahren ist extrem komplex. Schon kurze Zeit später sind jedoch die Schwingungen abgeklungen. Dann, aber erst dann, ist der Fallschirm dynamisch gesehen ziemlich zahm.
Das Ausfahren des Fallschirms kann man schon in der Erdatmosphäre testen, indem man eine Versuchskapsel mit Fallschrim von einem Höhenballon abwerfen lässt. Aber solche Tests verifizieren nur die allgemeine Festigkeit und die aerodynamischen Grundeigenschaften. Die komplexe Dynamik, also die Oszillationen kurz nach dem Entfalten, wird jedes Mal anders sein.
Bloß weil das System bei einem Test innerhalb der angenommenen Bandbreiten geblieben ist, bedeutet das noch lange nicht, dass dies beim nächsten Rest oder im realen Einsatz auch so sein muss.
Diese zwei wesentlichen Komponenten hat eine Mondsonde nicht. Da gibt es nur ein Triebwerk, das zunächst einmal das Gros der Orbitalgeschwindigkeit aufzehrt, um dann im geschlossenen Regelkreis, unter Nutzung von Radar oder Lidar oder, wenn es ganz ausgefeilt ist, unter Verwendung von Bildmaterial einer Bordkamera zwecks Feinnavigation oder Gefahrenerkennung bei Höhe von etwas über Null Metern eine Vertikal- und Horizontalgeschwindigkeit von jeweils etwa 0 Metern pro Sekunde zu erreichen.
Hier kann die Verifikation mittels einer großen Menge von Computersimulationen schon helfen, wobei man aber immer gewissen Annehmen bezüglich des Verhaltens aller beteiligten Komponenten machen muss. Ob diese Komponenten sich unter Realbedingungen auch so verhalten, wie man es erwartet, ist eine andere Frage.
Wo immer möglich, sollte das Steuerungssystem fehlertolerant ausgelegt werden. Genau hieran haperte es aber bei Schiaparelli. Der Fehlertoleranz sind allerdings dann auch noch praktische Grenzen auferlegt. Im Endanflug kann hat das System einfach keine Zeit mehr zum Überlegen. Da muss das einfach funktionieren, basta.
Praxistests auf der Erde sind wegen des Vorhandenseins einer Atmosphäre, wegen der höheren Scwherkraft und wegen zahlreicher anderer Unterschiede zum Mond zwar möglich (und auch teuer), aber nicht abschließend aussagekräftig.
Im gegebenen Fall könnte es ein Problem mit starken elektrostatischen Feldern in Oberflächennähe gegeben haben.
@Michael Khan: Besten Dank für die Ausführungen.
Selber habe ich nichts zur Ursache des Beresheet-Crashes gehört. Wenn sie schreiben: “Im gegebenen Fall könnte es ein Problem mit starken elektrostatischen Feldern in Oberflächennähe gegeben haben.” meinen sie also, dass der Beresheet-Lander – oder besser gesagt seine Sensoren – kurz vor dem Aufsetzen durch elektrostatische Felder gestört wurde.
Dass die Ursachen von Unfällen mit Raumfahrzeugen oft schwierig zu eruieren sind, scheint mir ein grosses Problem zu sein. Denn dann besteht die Gefahr, dass man beim nächsten Mal das gleiche passiert. Zum Glück und zum Vorteil weiterer ESA-Marsmissionen konnte der Schiaparelli-Crash vollkommen aufgeklärt werden.
Wenn der Bereesheet Lander tatsächlich durch elektrostatische Felder gestört wurde, dann wundere ich mich etwas, denn von den Apollo-Missionen ist mir zwar bekannt, dass es dieses Phänomen gibt und die Astronauten damit zu kämpfen hatten, doch die Landesphären dazumal scheinen diese Felder nicht gestört zu haben.
Was Yoav Landsman zum Absturzhergang gesagt hat, steht in meinem Blog-Artikel. Ich werde das nicht wiederholen. Ob ganz am Anfang eine Störung durch ein elektrostatisches Feld stand, ist Spekulation, wie er selbst sagt. So wird er auch von mir zitiert. Es kann auch ein anderes Problem gegeben haben, möglicherweise eine defekte Komponente, möglicherweise ein Programmierfehler, möglicherweise ein Single Event Upset. Oder auch etwas anderes. Vielleicht werden wir es nie erfahren.
Das ist auch gar nicht so wichtig. Es gibt immer die Möglichkeit, dass etwas schief geht. Fehlerquellen gibt es zuhauf. Deswegen muss das System dagegen robust sein. Deren Bordcomputer war es offensichtlich nicht. Wenn es zu einer hohen Resetfrequenz kommt und dann immer die aktuelle Konfiguration geöscht wird und zeitraubend nachgeladen werden muss, dann ist das das System nicht robust.
Die Bauart der heute verwendeten Sensoren einer Trägheitsplattform unterscheidet sich von der zu Apollo-Zeiten. Damals waren elektromechanische Komponenten verbreitet. Zudem war damals immer auch der Mensch mit in der Schleife. Wenn der sehen würde, dass es eine unkommandierte Rollbewegung gibt, dann steuert er einfach manuell gegen.
@Michael Khan: Wie bei der Schiaparelli-Mission betrachten Sie die fehlende Robustheit der Landersoftware als Kardinalfehler.
Bei der Schiaparelli-Mission gab es in meinen (und soviel ich erinnern kann auch in ihren) Augen 2 Fehler:
1) die Dynamik beim Marsatmosphäreneintritt wurde unterschätzt.
2a ) die Landersoftware rechnete nicht mit Fehlern, nicht einmal mit einfach erkennbaren Fehlern wie einer Sättigung des Drehwinkel-Registers.
2b) Ein Restart von Subsystemen (wie dem Drehsensorsystem) war nicht vorgesehen
Bei der Beresheet-Mission gab es in Bezug auf die Hardware/Software wohl ebenfalls 2 schwerwiegende Fehler:
1) die hohe Resetfrequenz (ein Hardwarefehler?)
2) die fehlende Berücksichtigung von (häufigen) Resets in der Software
Robuste Software wäre also in beiden Fällen das Gebot der Mission gewesen. Doch robuste Software zu schreiben ist gar nicht einfach, denn bei der Fehlerbehandlung können ja selbst wieder Fehler entstehen. Soviel ich weiss wurde bei der Schiaparelli-Mission sogar bewusst auf eine solche robuste Software verzichtet, weil der Aufwand dafür als zu hoch eingeschätzt wurde.
Ich möchte darum bitten, mir nicht Aussagen zu unterstellen, die ich nicht gemacht habe. Meine Meinung zu Schiaparelli steht in den Artikeln in meinem Blog, die ich zu diesem Tjema gescrieben habe. Dem habe ich nichts hinzuzufügen. Von einer “überschätzten Dynamik beim Atmosphäreneintritt” habe ich bestimmt nichts geschrieben.
Zur Beurteilung etwaiger Fehler bei beresheet fehlt mir der Einblick in Details der Mission. Ob es sich um Software-Resets oder Hardware-Resets handelte, macht einen Unterschied. Wodurch diese ausgelöst wurden, ist meines Wissens unbekannt. Mir ist auch nicht bekannt, ob bei Beresheet “robuste Software” das Problem gelöst hätte, wobei robute Software ja erst einman nicht mehr als ein Schlagwort ist, das immer genau das bedeutet, das der, der es benutzt, gerade meint.
Die Quelle für Ihre Aussage zu Designentscheidungen bezüglich der Software auf Schiaparelli ist mir unbekannt. Vielleicht haben Sie Zugang zu Informationen, die mir nicht verfügbar sind.
@Michael Khan
(Zitat 1) Von einer “überschätzten Dynamik beim Atmosphäreneintritt” habe ich bestimmt nichts geschrieben.
Zitat 2) Die Quelle für Ihre Aussage zu Designentscheidungen bezüglich der Software auf Schiaparelli ist mir unbekannt. Vielleicht haben Sie Zugang zu Informationen, die mir nicht verfügbar sind.
zu 1) Ich habe geschrieben: die Dynamik beim Marsatmosphäreneintritt wurde unterschätzt. Mit anderen Worten: Die Dynamik war grösser als erwartet. Das gleiche liest man auch in der esa-Präsentation Would any dependability technique have prevented Schiaparelli to land on Mars at 150 m/s?
Zur Dynamik bei Eintritt in die Marsatmosphäre
Dort steht nämlich zur Fallschirm-/Atmosphären-Dynamik:
1) Insufficient conservative modelling of the parachute dynamics which led to expect much lower dynamics than observed in flight
2) as no such parachute dynamic was expected, there was no consideration of saturation as feared event.
Zur geplanten Robustheit des Schiaparelli-Landers
Bezüglich geplanter Robustheit der Lander-Software liest man:
1) initial statement: no redundancy, not Fail-Ops, not Fail-Safe.
2) could have been just fail-degraded? yes but, anyhow both IMU and Radar are essential to the landing.
3) stress: Strong delivery-oriented teamMust-launch in 2016
Diese drei Aussagen habe ich so interpretiert:
zu 1) initial statement == Initiale Festlegung (meine Interpretation von initial statement): keine Redundanz, kein Fail-Ops, kein Fail-Safe
zu 2) ohne IMU und Radar geht sowieso nichts, also keine Fehlerbehandlung für etwas was man gar nicht behandeln kann.
zu 3) Überlastung war mit ein Grund warum man auf Redundanz, Fail-Ops/Fail-Safe verzichtet hat
“überschätzt” war ein Tippfehler von mir, das sollte natürlich “unterschätzt” heißen. Woran ich mich störte ist, dass Sie vom “Atmosphäreneintritt” sprachen. Darunter verstehe ich aber die Hochgeschwindigkeitsphase, also alles, was bis hinunter zum Ausfahren des Fallschirms passiert. Die Dynamik in dieser Phase wurde nicht unterschätzt. Ich denke auch nicht, dass es auf Basis des heutigen Wissens denkbar gewesen wäre, den Entwurf des Hitzeschilds zu verbocken. Insofern distanziere ich mich deutlich von Ihrer Äußerung.
Zur Auslegung von Schiaparelli: Die Auslegung des Systems als Single String, also ohne multiple Redundanz, ist eine hardwareseitige Entscheidung. Das hat mit der Robustheit der Software nichts zu tun. Die Software war in der Tat nicht robust ausgelegt, aber ich denke nicht, dass das bewusst so angelegt war, als Folge eine vorsichtigen und überlegten Abwägung aller Möglichkeiten.
Ich bin auch nicht der Meinung, dss eine robustere Softwareauslegung komplexer gewesen sein müsste. Ich habe zuvor auf eine Möglichkeit hingewiesen, wie das Problem mit den Schwingungen beim Ausfahren des Fallschirms sehr einfach durch bloßes Abwarten hätte gelöst werden können.
Auf dem Mond gibt es jetzt Lebenwesen:
Quelle:
https://www.welt.de/kmpkt/article198173461/Baertierchen-koennten-nach-Raumfahrt-Unfall-auf-Mond-leben.html
nein, den Mond haben schon die US-Survoyers mit Mikroben besiedelt …
“Besiedelt” ist vielleicht etwas übertrieben ausgedrückt, aber es sieht schon so aus, als seien damals Mikroben eingeschleppt worden, dem zwischenzeitlichen Dementi aus dem Jahr 2011 zum Trotz.
Die Sache mit den Bärtierchen auf Beresheet stellt offenbar keinen Verstoß gegen geltende Bestimmungen dar. Übrigens haben die Apollo-Astronauten schon eine Menge ganz sicher noch nicht einmal annähernd steriles Zeug auf dem Mond zurückgelassen, darunter Beutel mit Fäkalien. Nach ein paar Mondtagen auf dem bis zu 150 Grad C heißen Regolith dürften diese aber wohl steril sein. Hinzu kommt noch die kosmische Strahlung. Also, kein großes Problem von der Seite. Sollte mal eine bemannte Mission zu einem der Apollo-Orte fliegen, müssen die Leute halt aufpassen, wo sie hintreten.