Was lief schief bei Schiaparelli?

So, da offensichtlich nur mich die Mängel im Raumsondenbau interessieren, schiebe ich mal ein Thema ein, zu dem jeder zumindest eine Meinung hat: Dem Verlust von Schiaparelli. Der Teil 3 kommt dann noch. Mal ne Rückfrage: Sind die Blogs zu technisch? Sie entstehen eben, wenn ich wie jetzt über Raumsonden schreibe, praktisch als Abfallprodukt beim Recherchieren und Nachdenken.

Ich habe bei der Gelegenheit auch den Artikel über die Mission der 2016-er Exomars aktualisiert. Da wurde schon im Mai der Bericht der Kommission veröffentlicht. Ich habe ihn erst mal ignoriert, schlussendlich waren schon genug Details vorher bekannt gewesen, die ich aufgenommen und verarbeitet habe.

So ganz bin ich beim Durchlesen des offiziellen Textes auch nicht schlau geworden. Aber damit wir mal alle auf dem selben Stand sind, hier meine Zusammenfassung aus dem Artikel:

Am 17.5.2017 wurde der Bericht der Untersuchungskommission veröffentlicht. Hier eine Tabelle der wesentlichen Ereignisse:

Ereignis Zeitpunkt [UTC]
Abtrennung vom Trace Gas Orbiter 16.10.2016 14:42:00
Erwachen 19.10.2016 13:19:48
Erste Verzögerung durch Atmosphäre registriert ~ 125 km Höhe 14:42:22
Fallschirm geöffnet 14:45:23
Hitzeschutzschild abgetrennt 14:46:03
Radarhöhenmesser aktiviert 14:46:19
Fallschirm mit Backshell abgetrennt 14:46:49
Start der Triebwerke 14:46:51
Brennschluss der Triebwerke 14:46:54
Aufschlag auf der Oberfläche 14:47:28
Geschätzte Landezeit, wenn alles normal gelaufen wäre 14:48:05

Der Ablauf war mit der über den Trace Gas Orbiter übertragenen Daten rekonstruierbar. Die schon kurz nach dem Unglück aufgekommene Vermutung wurde bestätigt.

Als sich der Fallschirm öffnete, das war noch bei hoher Geschwindigkeit, über Mach 2, kam es zu starken Bewegungen von Schiaparelli, er bewegte sich sowohl in der Vertikalen und rotierte um die eigene Achse. Schiaparelli hat eine IMU, eine Inertialeinheit an Bord. Sie stellt die räumliche Lage fest. Das ist wichtig, weil der Lander horizontal landen soll und nicht schräg. Durch diese abrupten Bewegungen kam es zu einer kurzzeitigen Sättigung der IMU. Sie setzte deswegen ein Flag, das dies signalisierte. Dieses Flag, so nahmen die Ingenieure der ESA an, würde maximal 15 ms lang gesetzt sein. Kommuniziert mit dem Hersteller der Inertialeinheit wurde das aber nicht. In der Praxis wurde es viel länger gesetzt. Solange es gesetzt war, gab die IMU nicht die reale Lage wieder, sondern maximal möglichen Höchstwert, selbst als die Schwankungen sich nach einigen Sekunden legten.

Mit diesem Wert berechnete der Bordcomputer nach Öffnung des Fallschirms die Ausrichtung der Sonde und berechnete einen Korrekturfaktor für die Radardaten. In der Endphase wird mit diesem Korrekturfaktor die Distanz verrechnet. Schaut das Radar schräg, so ist die Höhe viel kleiner als die aus der Laufzeit bestimmte Distanz. Dazu wird der Cosinus berechnet, entsprechend einem rechtwinkeligen Dreieck, bei der Berechnung der Ankathete, wenn die Hypotenuse bekannt ist. Nun ist der Cosinus bei Winkeln über 90 Grad negativ und der übermittelte Winkel war 165 Grad.

Benutzt wurde der Korrekturfaktor erst, als der Fallschirm abgelöst wurde und die Triebwerke aktiviert werden sollten. Dann wurde die vom Radar gelieferte Höhe mit dem Korrekturfaktor multipliziert, und da dieser negativ war, nahm der Bordrechner an, Schiaparelli wäre gelandet und stellte die Triebwerke ab. So zerschellte der Lander auf der Oberfläche.

Nach dem Board ist daher die primäre Ursache Sättigungsflag und es kommt zum Schluss, dass wenn es wie von der ESA-Seite angenommen nur 15 ms lang gesetzt gewesen wäre, es nicht zu dem Fehlverhalten gekommen wäre. Nur war diese Annahme nicht zum Hersteller kommuniziert worden und es gab auch keine Tests. Das so extreme Schwingungen auftreten konnten, war zwar nicht bei den Simulationen vorhergesehen worden, doch sie war nicht so außergewöhnlich. Ähnliche Erfahrungen machte schon die NASA bei ihren Landungen.

Das Ganze ist aber nur ein Teilaspekt. Die GNC (Guidance-Navigation-Control) Software hat mit diesem Wert ja gerechnet, ohne ihn zu hinterfragen. Es ist nun mal physikalisch unmöglich, das Schiaparelli 165 Grad zum Boden geneigt am Fallschirm hängt – dann müsste der Fallschirm Richtung Oberfläche zeigen. Ebenso erfolgte keine Prüfung, ob der Korrekturfaktor negativ ist, auch das ist physikalisch unmöglich und zuletzt hinterfragte die Software die Daten nicht, wie plötzlich die Sonde in einem Sekundenbruchteil von 3,7 km Höhe über dem Boden auf 2,5 km unterhalb des Bodens ankam.

In der Software Welt war die Software nicht „robust“ genug. Vieles erinnert an den Fehlstart der ersten Ariane 5, als durch eine zu hohe horizontale Beschleunigung in einem von der Ariane 4 übernommenen Programm, es bei der Konvertierung einer Zahl einen Überlauf kam und der Bordcomputer diesen Überlauf als reale Position nahm und die Rakete abrupt schwenkte, wodurch sie auseinanderbrach.

Diskussion

Soweit der Text aus der Webseite.

Ich verstehe selbst nach Lesen des Berichtes einiges nicht. So wurde der Korrekturfaktor für die Ausrichtung berechnet, als der Fallschirm geöffnet wurde. Warum? Verwendet wurde dieser Wert erheblich später, nämlich erst als die untere Abdeckung abgeworfen wurde und der Radarhöhenmesser aktiv wurde, denn dessen Daten sollten ja korrigiert werden. Das istfast eine Minute später. Der Sinn erschließt sich mir nicht. Schlussendlich muss die Ausrichtung bei Auslösung des Fallschirms ja nicht die gleiche sein wie beim Abwerfen der Abdeckung. Vor allem hätten sich da ja alle Schwingungen abgebaut.

Der einzige Grund, den ich kenne, für eine solche Vorgehensweise wäre, dass die Berechnung eines Korrekturfaktors sehr lange dauert, sodass man ihn sehr frühzeitig berechnen muss. Doch nach der Lektüre des Berichts scheint es eine einfache Cosinus-Berechnung zu sein. Das kann es also nicht sein.

Das nächste ist, dass dem Bordcomputer über ein „Sättigungsflag“ signalisiert wurde, dass die IMU gesättigt ist. Der Tatbestand weicht hier von dem Ariane 501 Versagen ab, wo man den Fehlercode als Messwert interpretierte. Der Bordcomputer wurde über das Flag informiert, das die IMU keinen korrekten Wert liefert. Warum benutzt er dann die Ausrichtung welche die IMU liefert? Bevor ich falsche Daten nehme, nehme ich lieber gar keine Daten. (Nein liebe FDP, diesen Sachverhalt, kann man nicht aufs Regieren übertragen). Dann gibt es eben keine Korrektur einer Schräglage und Schiaparelli kommt schräg auf. Vielleicht scheitert dann die Landung, aber dann zu einem späteren Zeitpunkt, wo man noch mehr Teile der Landung erprobt hat. Die ESA wurde ja nicht müde zu betonen, man habe die Daten, die man für die Landung 2020 braucht, gewonnen und das wäre der eigentliche Sinn der Mission.

Wie der Report auch schreibt, gab es „consistency checks“. Der Bordcomputer überprüft Höhe und Geschwindigkeit. Irgendwie komisch. Er überprüft also, ob er in der richtigen Höhe ist, aber erst nachdem er diese durch den Korrekturfaktor verändert hat. Sollte er nicht die Rohdaten aus Plausibilität prüfen?.

Natürlich muss eine Software „robust“ sein, also mit Ausfällen zurecht kommen. In diesem Falle geht das weiter sie muss auch physikalisch korrekte Inhalte überprüfen. Es ist nun mal nicht möglich das man sich plötzlich weit unterhalb der Oberfläche befindet oder verkehrt herum am Fallschirm hängt. Etwas schwerer ist es, mit den Folgen fertig zu werden. Hier war ja die Ursache, dass man den Wert abgefragt hatte, als er ungültig war. Aber was wäre passiert, wenn es wirklich einen Ausfall der IMU gegeben hätte? Man könnte mit dem letzten Wert arbeiten. Da das Landeradar die Daten über Höhe und Geschwindigkeit liefert, wäre noch eine Landung möglich, aber sie war riskanter. Man weiß nicht, wie Schiaparelli orientiert ist, also senkrecht unter dem Fallschirm hängt oder leicht schräg. Das birgt nicht nur die Gefahr, das Schiaparelli beim Aufsetzen umkippt. Die Höhendaten stimmen auch nicht. Denn wenn das Radar dann auch leicht schräg zur Seite schaut, so ist die Distanz zum Boden kleiner, als die gemessene. In der Folge würde Schiaparelli mit höherer als geplanter Geschwindigkeit aufsetzen. Wobei die Endphase ja ein Sinken mit konstanter Geschwindigkeit ist, daher wären die Auswirkungen nicht so hoch.

Es gibt für mich auch andere offene Punkte. Der Report listet, dass man um 14:47:22 den Funkkontakt verloren hat. Das war aber schon 6 Sekunden vor der Landung. Was ist da passiert?

Vor allem, wie kommt die ESA auf die Überzeugung, die Mission wäre erfolgreich? Nach meiner Überzeugung ist ab der Fallschirmablösung alles schief gegangen. Die Backshell wurde verfrüht abgeworfen, die gesamte Endphase der Landung, also das Abbremsen auf langsame Geschwindigkeit in 4 m Höhe wurde nicht erprobt.

Peinlich finde ich dann auch die Ausreden, die fielen. Zusammengefasst liefen die so: „Es ist unsere erste Mission zum Mars, deswegen haben wie die Landung ja auch vor dem Rover der 2020 abgesetzt wird erprobt. Wegen der dünnen Luftschicht ist das riskant und es sind ja schon so viele Missionen verloren gegangen“.

Na ja. Natürlich ist es schwieriger als auf der Erde und dem Mond. Auf der Erde reicht fast eine alleinige Fallschirmlandung aus, auf dem Mond muss man mit Triebwerken landen. Die Problematik ist, dass es anders als beim Mond mehr Störeinflüsse gibt. Verschiedene Temperaturen, verschiedene Druckwerte und Seitenwind, je nach Landegebiet und aktuellen Wetter. Doch das Grundprinzip das alle Landungen einsetzen berücksichtigt das.

Es ist seit Viking eigentlich unverändert: Der Fallschirm bremst die Sonde soweit ab, bis man eine Referenzhöhe erreicht bei der die Triebwerke arbeiten, die ein Programm haben, das die Sonde nahe der Oberfläche auf niedrige Geschwindigkeit abbremst. Gesteuert wird das durch einen Radarhöhenmesser der Distanz und Geschwindigkeit misst. Die Treibstoffvorräte sind groß genug ausgelegt um auch Abweichungen vom Soll abzufangen und der Fallschirm so groß dimensioniert, dass man eine Geschwindigkeit beim Start der Triebwerke hat, die man sicher abfangen kann. Die Referenzhöhe ist so hoch, dass es genügend Zeit zum Abbremsen gibt. Bei Schiaparelli z. B. wurde der Fallschirm in 7 km Höhe entfaltet und schon in 1,2 km Höhe begann der Triebwerksstart. Das lässt genügend Zeit, um die Restgeschwindigkeit abzubauen.

Dazu braucht man keine ausgeklügelte Software. Viking landete 1975 mit einer Feedback-Steuerung, überwacht durch den Bordcomputer mit der Leistung eines C64. Die größten Risiken, die es damals gab, lagen nicht bei der Landung, sondern dem Landegebiet. Vergleicht man die ersten Aufnahmen nach dem Aufsetzen von Viking, Pathfinder einerseits und den beiden MER, Phoenix und Curiosity so fällt auf das die Letzteren in weitestgehend „leerem“ Gebiet, also fast ohne Steine niedergingen. Das ist das Ergebnis, das man bei den ersten beiden Sonden Bilder mit maximal 40 m Auflösung des Landegebietes hatte und bei den folgenden dann von 2 m und später 0,3 m Auflösung. Auf den grob auflösenden Aufnahmen konnte man keine Felsen ausmachen, die in einer Größe sind, wo ein Lander umkippen kann, wenn er auf ihnen aufkommt oder zumindest in der Funktion beeinträchtigt ist. Viking Lander 1 kam wenige Meter neben einem 1,5 m hohen Felsbrocken „Big Joe“ auf. 7 m weiter und er wäre auf ihm gelandet und umgekippt. Ebenso landete Pathfinder nur wenige Meter neben einem 1 m großen Felsbrocken „Yogi“. Eine Landung auf ihm wäre auch das aus der Mission gewesen.

Ich finde insgesamt, das das Exomarsprogramm kein Ruhmesblatt für die ESA ist. Siehe dazu auch der letzte Blog. Die Frage, die ich mir stelle ist, wofür man 1,5 Milliarden Euro ausgibt. Ein Orbiter, der nur wenige Instrumente trägt und bei der Software für die eh schon kastrierte Mission (warum hat man nicht wenigstens die Oberfläche mit Solarzellen bedeckt, um eine längere Betriebszeit zu ermöglichen. Per se ist es aber ein Witz einen Lander abzusetzen der nur einige Tage arbeitet. Wenn man für 2020 eine Landeplattform baut, die dauerhaft arbeitet, warum setzt man die nicht 2016 ein. Das wäre dann auch eine realistische Generalprobe. Den komplexen Rover kann man dann 2020 hinzunehmen. Ich war stolz darauf, dass die ESA es mit Venus- und Marsexpress hinbekam, preiswerte Missionen zu designen, die trotzdem wissenschaftlich wertvoll sind. Derzeit läuft es darauf hinaus, dass man nur teure Missionen designt, die wissenschaftlich nicht so wertvoll sind. Klar, auch bei den USA ist die Zeit der preiswerten Missionen vorbei. Insight ist im Prinzip von der Sonde her ein Nachbau des Mars Polar Landers. Der kostete 234 Millionen Dollar (inflationskorrigiert) Insight 838 Millionen Dollar. Aber dort sind es wenigstens nicht Sonden, die einige Tage lang wenige Messwerte liefern. Es setzt sich ja fort: 2020 gibt es trotz eines Proton-Starts (Nutzlast zum Mars rund 5,2 t) nur eine Cruise Stage. Ich glaube nicht das die Landeplattform so schwer ist, als das man da nicht noch einen Orbiter mitnehmen könnte. Vielleicht nicht so ein Monster wie der TGO, aber einen in der Größe von Mars Express in jedem Fall. Auch hier: gespart aber am falschen Ende.

Mein Resümee: Das war kein Ruhmesblatt.

[Edit]

Nachdem ich mir die Diskussion bei Michael Khan angesehen habe und auch hier jeder einen anderen Gesichtspunkt hat, will ich meinen Standpunkt noch mal erläutern. Ich würde mich nicht auf die Sättigung der IMU fokussieren. Die zeigte (mit Einschränkungen) ein „normales“ Verhalten – wenn ein Messwert aus dem zulässigen Messbereich kommt, dann gibt es den Maximalwert des Messbereichs und eine Fehlanzeige an das System zurück. Das würde ich in der Programmierung, wo ich ja auch firm bin, als korrekte Behandlung einer Exception ansehen.

Die IMU reicht die Verantwortung weiter an die nächste Schicht, in dem Fall den Bordcomputer. Hier liegt das Versagen. Er erkennt die Exception nicht, beachtet also gar nicht das Flag. Er müsste nun den Wert ignorieren, die IMU erneut abfragen. Das ist der erste Fehler.

Ich habe ja mal eine Wetterstation programmiert (inzwischen leider durch Sensorausfall nicht mehr aktiv). Da gab es nachts auch ab und an Helligkeitswerte über 5 Lux, wahrscheinlich durch Fenster bei den Nachbarn, die angingen und auf den Sensor reflektiert wurden. Da ich den Sonnenaufgang detektiere, wenn es heller als 5 Lux wird, musste man diese einzelnen Ausreiser ignorieren. Dazu muss die Software nur schauen, wie die Werte verlaufen. Wenn es Tag wird, dann wird es langsam heller und nicht plötzlich hell und dann wieder dunkel. Auch dies findet man in der Software von Schiaparelli nicht. Sie hat kein „Gedächtnis“, was frappierend an Verlust der Ariane 501 zwanzig Jahre früher erinnert. Auch hier hat der Bordcomputer nicht hinterfragt, dass die Rakete urplötzlich von einem Zyklus (0,04 s) auf den nächsten ihre Ausrichtung massiv geändert hat. Ebenso wie die Software des Bordcomputers von Schiaparelli den Wert nicht hinterfragte.

Noch schlimmer: Sie hat mit dem Wert 5 Sekunden lang „contingency Checks“ gemacht, die natürlich alle negativ waren, ohne sich jemals in den 5 Sekunden den aktuellen Wert der IMU zu holen.

Dazu kommt, wie schon erwähnte, das ich es den Zeitpunkt für Blödsinn halte den Wert so früh zu nehmen. Er wird ja erst gebraucht, wenn der Radarhöhenmesser aktiv ist. Dann ist aber:

  • Schiaparelli von Mach 1700 auf 320 km/h abgebremst
  • 5 km tiefer in dichterer Atmosphäre
  • Um 80 kg (den Hitzeschutzschild) leichter.

Für mich sieht das alles Grund genug den Wert neu berechnen. Vor allem werden die Triebwerke ja die Schiaparelli, selbst wenn sie schräg orientiert ist, in die richtige Lage drehen, man will ja Schiaparelli nicht schräg landen. Alleine deswegen müsste die IMU dauernd abgefragt werden.

Wenn man sich die Versäumnisse anschaut (es sind ja nicht wenige). Dann stellt sich mir die Frage, welcher Programmier- und Qualitätssicherungsstandard bei der ESA herrscht.

Michael Khan moniert ja auch die fehlende Redundanz. Die hilft aber nur etwas, wenn man zwei Systeme hat, die voneinander unabhängig erstellt wurden, also unabhängig programmiert wurden. Ansonsten passiert das Gleiche wie bei Ariane 501, da fiel ja aufgrund desselben Programmfehlers in zwei unabhängigen, redundanten Modulen das zweite Modul einen Zyklus später aus.

Das würde implizieren das die ESA neben einem Stümper-Programmierteam auch eines hat das programmieren kann. Doch wenn dem so wäre, dann hätte das sicher die Fehler des ersten bemerkt.

8 thoughts on “Was lief schief bei Schiaparelli?

  1. Danke für den Link, erklärt aber in meinen Augen nicht warum man einen Korrekturwert, den man erst braucht um die Radardaten zu korrigieren (das Aktivieren des Radarhöhenmessers geschieht bei 14:46:19) schon beim Öffnen des Fallschirms gewinnt (14:45:23). Ich muss doch einen Korrekturwert zeitnah gewinnen. In den 56 Sekunden wird die Sonde langsamer, gerät in ein anderes Druckniveau, die Form und der Schwerpunkt ändern sich auch durch Abwurf des Hitzeschutzschildes. Die Gewinnung des Korrekturfaktors so früh macht für mich weder programmtechnisch, noch technisch noch physikalisch einen Sinn.

  2. Ich vermute mal in der Trägheitsplattform der IMU ist durch das rotieren um die eigene Achse ein Gimbal Lock aufgetreten.
    Und die Frage ist: war das rotieren um die eigene Achse geplant gewesen?

  3. Nach dem Bericht war die Fallschirmauslösung heftig, das bedeutet das die Sonde kurzzeitig durchgeschüttelt wurde. Es war kein Gimbal Lock, denn der bedeutet meist den endgültigen Ausfall. Das war nicht der Fall, nachdem die Bewegungen sich legte, lieferte die IMU korrekte Daten. Daher auch ein Schluss des Berichtes, dass wenn das Flag nur 0,015 s wie vereinbart anstatt der 1 s gesetzt war. die Mission geglückt wäre.

  4. Offensichtlich war man bei der Planung des Abstiegs zum Schluss gekommen, dass die Sonde eine konstante, im Voraus nicht bestimmbare Schräglage einnehmen kann. Wenn man von dieser Grundannahme ausgeht ergibt es absolut Sinn, den Korrekturfaktor für die Schräglage so früh wie möglich; und insbesondere vor dem Zünden der Triebwerke zu bestimmen. Da weder Druck noch Geschwindigkeit einen Einfluss auf diesen offensichtlich geometrischen Faktor haben, ergibt es umgekehrt überhaupt gar keinen Sinn, länger als nötig zu warten. Im Gegenteil, es ist doch völliger Unsinn 56s Abstieg mit unkorrigierten Höhendaten zu fliegen, wenn man ohne Nachteile (so die Annahme) korrigierte Daten haben kann.

  5. Dieser Punkt fehlt in der Zeitschiene:
    »Between EIP and Parachute Deployment triggering, an unexpected evolution in the spin rate of the EDM was noticed.«
    Und an diesen Punkt war die Sache bereits beendet!

    Ein Gimbal Lock bedeutet nicht ein Totalausfall, sondern es kann in einer Richtung nicht mehr gemessen werden, d.h. einer von drei Kreisel hat seine Funktion verloren.

  6. @Ariane42L
    „Based on the analyses performed, the SIB consider that there is no link between the unexpected spin rate behaviour and the unexpected transverse angular rates that saturated the IMU.“
    @Karle: Welchen Sinn soll es machen eine konstante Schrägneigung völlig unabhängig von aktueller Masse, Schwerpunktslage und Form, Geschwindigkeit, Wind und Druck anzunehmen und zu korrigieren. Das ist physikalisch unmöglich. Jeder der obigen Faktoren wirkt ein und würde eine konstante Schräglage in eine variable überführen.

  7. Hallo Bernd,
    daß Deine Blogs zu technisch sind finde ich nicht.
    Manches kann ich mit meinem (un-)gesunden Viertel- oder Halbwissen nicht verstehen, dann kann man nachschlagen (nicht nur Goockeln sonderna auch in einem Buch!) oder einfach nachfragen.
    Wenn ich eine Bemerkung zum Blog habe mache ich sie (manchmal auch lustig gemeint!)

    Ansonsten genieße ich Deine Blogs ruhig und interessiert!

    Gutes Neues Jahr wünscht
    Ralf mit Z

Schreibe einen Kommentar zu Ralf mit Z Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

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