Schiaparelli-Landung: Fehlschlag auf der Zielgeraden

BLOG: Go for Launch

Raumfahrt aus der Froschperspektive
Go for Launch

Die letzte Woche war turbulent. Sie enthielt reichlich Höhen und Tiefen. Am Sonntag setzte das Orbitermodul “TGO” der ESA-Marsmission ExoMars 2016 den Landedemonstrator Schiaparelli aus. Am Mittwoch dann die Ankunft am Mars mit Mars-Bahneinschuss des TGO und Schiaparelli-Landung. Für den TGO ist ein Erfolg zu verbuchen, für Schiaparelli leider nicht, wobei die Haben-Seite auch da deutlich besser aussieht, als es auf den ersten Anblick erscheinen mag.

Hier das Komposit aus beiden Raumsonden als hochwertiges Tischmodell mit Schiaparelli oben drauf. Im Foto darunter das 1:1-Modell von Schiaparelli ohne aerodynamische Umhüllung, d.h. (mehr oder weniger) so, wie er auf der Marsoberfläche hätte landen sollen.

Modell im Maßstab 1:50 vom TGO und Schiaparelli (leider nicht meins)
Credit: Michael Khan, Darmstadt / Modell im Maßstab 1:50 vom TGO und Schiaparelli (leider nicht meins)
1:1 Modell des Landemoduls Schiaparelli in der Konfiguration nach dem Aufsetzen
Credit: Michael Khan, Darmstadt / 1:1 Modell des Landemoduls Schiaparelli in der Konfiguration nach dem Aufsetzen

Beim TGO war die Situation von vorneherein eher entspannt. Die NASA-Bodenstation in Canberra empfing das Signal von der X-Band-Rundstrahlantenne vor und während des Manöverbeginns, danach übernahm die NASA-Bodenstation in Madrid. Die Dopplerverschiebung zeigte den Beginn und den Fortschritt des fast 140 Minuten langen Manövers. Der TGO verschwand für etwa 70 Minuten hinter dem Mars. Pünktlich um 18:33 MESZ war das Signal wieder da, und die Datenübertragung zur Erde konnte beginnen. Es war schnell klar, dass die Raumsonde wohlauf und fast exakt im Zielorbit angekommen war.

Dort ist also alles im grünen Bereich.

Bei Schiaparelli lief es leider etwas holpriger.

Bereits 75 Minuten vor dem Erreichen der Atmosphäre weckte ein Timer Schiaparelli aus dem Stromsparmodus während seiner dreitägigen Freiflugphase und der UHF-Sender schaltete sich ein. Im Kontrollraum konnte man Diagramme mit dem Zeitverlauf der Signalstärke und der Dopplerverschiebung des Signals sehen, so wie es ab 15:38 MESZ vom GMRT-Radioteleskoparray in Pune (Indien) empfangen wurde. Pune empfing wohlgemerkt nur das Signal, nicht die Telemetrie – also keine Daten von Schiaparelli. Die messbare Dopplerverschiebung und auch die Signalstärke stellen allerdings auch Daten dar – man kann daraus etwas berechnen und ableiten. Dieser Umstand kam in der Öffentlichkeit einfach nicht an. Egal, wie oft man es erklärte – irgendwann gab ich es auf.

Für das Kontrollteam war der Empfang des Signals eine große Erleichterung. Zum einen wusste man schon, dass das Aufwecken stattgefunden hatte. Zum anderen konnte man in Echtzeit (abgesehen von den 9.7 Minuten Signallaufzeit aufgrund der Entfernung von 175 Millionen km vom Mars zur Erde zu diesem Zeitpunkt) verfolgen, ob die Sonde noch am Leben war. Auch der zu frühe Signalabbruch war so live mitzuverfolgen.

Nach der Zeit des Eintritts (Signalempfangszeit ca. 16:52 MESZ) änderte sich erst einmal gar nichts. Langsam machte sich eine Dopplerverschiebung wegen der zunehmenden Abbremsung bemerkbar. Schiaparelli bewegte sich aufgrund der Geometrie zwischen Erde und Mars beim Eintritt von der Erde weg. Bei einsetzender atmosphärischer Abbremsung verringerte sich die Relativgeschwindigkeit, sodass die Frequenz des empfangenen Signals anstieg. Die Rotverschiebung des Signals wurde weniger. Das war genau so erwartet worden.

Dann riss das Signal vorübergehend ab. Auch das war so erwartet worden. Während der Phase des starken atmosphärischen Abbremsens ist die Eintrittskapsel von heißem Plasma umhüllt. Diese verschluckt das UHF-Signal. Trotzdem war das Warten extrem aufreibend. Nach fast zwei Minuten kam das Signal wieder, was mit großem Jubel quittiert wurde. Einige erhebliche Oszillationen danach müssen auf das Ausfahren des Fallschirms bei knapp zweifacher Schallgeschwindigkeit zurückzuführen sein, etwa 40 Sekunden danach auf den Abwurf des vorderen Teils des Hitzeschilds. Dieser wurde schon nicht mehr gebraucht, bevor der Fallschirm ausfuhr, aber mit dem Absprengen wurde gewartet, damit sich die Ausrichtung der Sonde stabilisieren konnte. Eine große Sorge beim Abwurf von Komponenten ist immer, dass sie mit dem Rest der Sonde kollidieren könnten.

Eigentlich hätte Schiaparelli noch 15 Minuten nach der Landung (Signalempfangszeit ca. 16:59 MESZ) weiter senden müssen. Bereits deutlich vor der wahrscheinlichen Landezeit war jedoch plötzlich Schluss. Zwar konnte zu diesem Zeitpunkt noch niemand wissen, was vorgefallen war. Der Verlust des Signals war jedoch kein gutes Zeichen. Alle von Schiaparelli gesendeten Daten sollten zwar vom TGO empfangen worden sein. Zu dieser Zeit war der jedoch noch hinter dem Mars. Wir wussten nicht, ob die Übertragung geklappt hatte. Die Telemetrie von Schiaparelli sollte erst Stunden später in Darmstadt eintreffen.

Schauen wir uns de atmosphärische Trajektorie von Schiaparelli an. Hier zeige ich einige Diagramme, die auf dem nominalen Zustand basieren. Es handelt sich nicht um Auswertungen der tatsächlichen Telemetrie. In blau die Bahnhöhe, abzulesen an der linken Skala. In rot die Geschwindigkeit relativ zur rotierenden Atmosphäre, also etwas weniger als die inertiale Geschwindigkeit. Der Zeitpunkt 0 ist definiert als die Zeit, bei der der “Entry Interface Point” (EIP) durchquert wird. Dieser EIP ist willkürlich bei einem Bahnradius von 3516.0 km festgelegt. Der Eintritt erfolgt mit fast 5800 m/s. Man sieht:

  • Die Geschwindigkeit nimmt zunächst noch zu. Erst etwa eine Minute nach EIP macht sich die Abbremsung bemerkbar. Da ist die Bahnhöhe nur noch 60 km.
  • Danach geht die Geschwindigkeit rasant nach unten. Das ist die “Hypervelocity Phase”, während der der Hitzeschild gefordert ist. Hier wird die Phase des größten Wärmestroms (“max q”) erreicht.
  • Mehr als 150 Sekunden nach EIP werden 1000 m/s unterschritten, schon in deutlich weniger als 20 km Höhe.
  • Etwa 200 Sekunden nach EIP in nur 11 km Höhe und bei knapp unter 500 m/s (rund Mach 1.9) kommt der Fallschirm heraus. Es gab bei Schiaparelli keinen kleinen “drogue chute”, der den Hauptschirm herauszieht. Typischerweise entfaltet sich ein Überschallfallschirm in weniger als einer Sekunde. Die Kräfte auf die Sonde erreichen hier eine zweite Spitze, nach der ersten in der Hyperschallphase.
  • Schon 20 Sekunden später ist die Gleichgewichtsgeschwindigkeit erreicht. Diese liegt bei etwa 80 m/s und nimmt beim weiteren Abstieg auf etwa 60 m/s ab, im selben Maße, wie die atmosphärische Dichte zunimmt.
  • Der vordere Teil des Hitzeschilds wird in 7 km Höhe abgeworfen. Dann wird das Bodenradar aktiv.
  • In etwa 1.3 km Höhe wird, gesteuert durch den geschlossenen Regelkreis des Steuerungssystems an Bord, der hintere Teil des Hitzeschilds abgeworfen, an dem noch der Fallschirm hängt. Danach ist das von der Landesonde übrig, was man oben im zweiten Bild sieht. Der Abstieg bis auf eine Höhe von 2 Metern erfolgt allein durch die Bremswirkung der neun Hydrazintriebwerke an Bord. Diese Triebwerke können im Pulsbetrieb geregelt werden, ebenfalls durch das Steuerungssystem an Bord unter Nutzung der Trägheitsplattform und der Radarmessungen. In 2 m Höhe soll die Geschwindigkeit idealerweise komplett abgebaut sein. Der Rest des Abstiegs erfolgt im freien Fall, wobei eine kleine Knautschzone die Energie aufnimmt.
Vorausberechnetes Zeitprofil von Höhe über Grund und Geschwindigkeit relativ zur rotierenden Atmosphäre für einen Fall ähnlich dem atmosphärischen Flug von Schiaparelli am 19.10.2016
Credit: Michael Khan, Darmstadt / Vorausberechnetes Zeitprofil von Höhe über Grund und Geschwindigkeit relativ zur rotierenden Atmosphäre für einen Fall ähnlich dem atmosphärischen Flug von Schiaparelli am 19.10.2016

Hier noch die Darstellung nur des letzten Teils des Abstieges, unterhalb einer Höhe von 12 km und einer Geschwindigkeit von 600 m/s. Die ersten 180 Sekunden nach EIP werden dabei weggelassen. Viel Neues bringt diese Grafik nicht, aber man sieht nochmals etwas deutlicher den Geschwindigkeitsverlauf in der Endphase. Beide Diagramme enden dort, wo der Fallschirm abgetrennt wird. Ab dann spielen aerodynamische Kräfte nur noch eine untergeordnete Rolle; der weitere Abstieg ist ein regelungstechnisches Problem, im geschlossenen Regelkreis mit Trägheitsnavigationssystem, Radar und Triebwerken.

Vorausberechnetes Zeitprofil von Höhe über Grund und Geschwindigkeit relativ zur rotierenden Atmosphäre für einen Fall ähnlich dem atmosphärischen Flug von Schiaparelli am 19.10.2016, Beginn ab 12 km Höhe
Credit: Michael Khan, Darmstadt / Vorausberechnetes Zeitprofil von Höhe über Grund und Geschwindigkeit relativ zur rotierenden Atmosphäre für einen Fall ähnlich dem atmosphärischen Flug von Schiaparelli am 19.10.2016, Beginn 180 s nach EIP

Hier das Ganze als hübschere Infografik:

Grafische Darstellung der Hauptergeignisse während des geplanten Abstiegs von Schiaparelli, Quelle: ESA/ATG medialab
Grafische Darstellung der Hauptergeignisse während des geplanten Abstiegs von Schiaparelli, Quelle: ESA/ATG medialab

Was man bis jetzt über die letzten Minuten von Schiaparelli weiß:

  • Es ist keine Anomalie in der Navigation während des Anflugs aufgetreten. Das belegt sowohl der punktgenaue Bahneinschuss des TGO sowie die Tatsache, dass der tatsächliche Landeort nahe dem Mittelpunkt der vorausberechneten Unsicherheitsellipse liegt.
  • Der Hitzeschild hat gehalten; die Sonde funktionierte auch nach der heißen Phase weiter.
  • Der Fallschirm wurde genau wie geplant entfaltet und zeigte die nominale Bremswirkung.
  • Der vordere Teil des Hitzeschilds konnte abgeworfen werden (sonst hätte das Radar nicht funktioniert und die Triebwerke hätten nicht aktiviert werden können).
  • Auch der Abwurf des hinteren Teils des Hitzeschilds mit dem daran befestigten Fallschirm war erfolgreich. Dies geschah allerdings zu früh- nicht in 1.3 km Höhe, sondern deutlich höher, vielleicht bis zu 4 km über der Oberfläche.
  • Die Triebwerke wurden gestartet und liefen eine kurze Zeit, bis sie wieder abgeschaltet wurden. Es wurde noch eine kurze Zeit danach Telemetrie gesendet.
  • Sämtliche gesendete Telemetrie wurde vom TGO empfangen und ist nun den Ingenieuren verfügbar. Es wurde eine technische Kommission  einberufen, die untersucht, was geschehen ist, und wenn sie es heraus gefunden haben wird, belastbare Untersuchungsergebnisse veröffentlichen wird.

Schon am Freitag erhielt die ESA von den Kollegen bei der NASA zwei Aufnahmen der CTX-Kontextkamera auf dem Orbiter MRO. Dort ist eine Stelle innerhalb der Landeellipse zu sehen, einmal vor, einmal nach der Landung. Das Bild ist eindeutig. Man sieht einen hellen Fleck – mit hoher Wahrscheinlichkeit der Fallschirm, an dem auch noch der hintere Teil des Hitzeschilds hängen muss, der allerdings bei dieser Auflösung nicht zu sehen ist.

Etwa 1 km nördlich vom weißen Fleck ist eine zuvor nicht sichtbare geschwärzte Fläche von etwa 15 x 40 m Ausdehnung zu sehen. Dabei handelt es sich ziemlich sicher um die Aufschlagstelle von Schiaparelli.

Aufnahmen der Schiaparelli-Aufschlagsstelle, Quelle: Main image: NASA/JPL-Caltech/MSSS, Arizona State University; inserts: NASA/JPL-Caltech/MSSS
Aufnahmen der Schiaparelli-Aufschlagsstelle, Quelle: Main image: NASA/JPL-Caltech/MSSS, Arizona State University; inserts: NASA/JPL-Caltech/MSSS

Spekulation ist weder hilfreich noch notwendig, die Experten haben alle verfügbaren Daten zur Hand und werden herausfinden, was geschehen ist.

Es ist allerdings keine Spekulation, wenn man berechnet, wie schnell die Sonde beim Aufschlag gewesen sein mag. Die Geschwindigkeit nahe am Boden setzt sich aus drei Teilen zusammen:

  1. Die Anfangsgeschwindigkeit bei Zünden der Bremstriebwerke
  2. Die zusätzlich gewonnene Geschwindigkeit durch die Anziehungskraft des Mars
  3. Die Abbremsung durch die Triebwerke

Die Endgeschwindigkeit berechnet sich aus (1) + (2) – (3). Im Nominalfall kommt ein Wert nahe Null heraus. Den kleinen Effekt der aerodynamischen Abbremsung vernachlässige ich zunächst mal in meiner Überschlagsrechnung.

Wenn nun aber Fallschirm und hinterer Teil des Hitzeschilds deutlich zu früh abgeworfen wurden, steigt (1) etwas (siehe Grafiken 3 und 4 oben) und (2) deutlich an. Im gegebenen Fall wurden offenbar die Triebwerke schon sehr bald nach dem Zünden wieder abgeschaltet, sodass (3) nahezu Null wird.

Wenn ich (3) auf Null setze und für die Anfangshöhe 4000 m annehme, kommt eine Fallzeit von 31 Sekunden und eine Aufprallgeschwindigkeit von 186 m/s heraus, also rund 670 km/h. Das allerdings dürfte deutlich über der Gleichgewichtsgeschwindigkeit selbst für ein kompaktes Objekt liegen. Ich schätze diese auf zwischen 300 und 400 km/h. Der freie Fall dauert also etwas länger als 31 Sekunden. Egal – ob nun 300, 400 oder 700 km/h, das kann keine Hardware überstehen.

Selbst aus 2 km Höhe mit 60 m/s Anfangsgeschwindigkeit komme ich auf fast 500 km/h theoretische Aufschlaggeschwindigkeit. Das liegt immer noch über der Gleichgewichtsgeschwindigkeit.

Fazit: Der Aufprall erfolgte mit “terminal velocity”. Wie hoch die genau war, werden die Aerodynamiker sagen können. Für Schiaparelli ist es egal, denn für ihn war die Geschwindigkeit auf jeden Fall zu hoch.

Wenn wir uns aber jetzt mal nicht auf das konzentrieren, was schief ging, sondern lieber auf das, was funktionierte, sieht es gar nicht so schlecht aus:

  • Offenbar haben, soweit mir bis jetzt bekannt, die wesentlichen Hardwarekomponenten funktioniert.
  • Die Daten, die zur Charakterisierung des Systems benötigt werden, liegen vor.
  • Gerade die Abschnitte der Eintrittsphase, die auf der Erde nicht leicht simuliert werden können, haben funktioniert. Also alles, was sich bei hohen Geschwindigkeiten und niedrigen Gasdichten in der Kohlendioxidatmosphäre des Mars abgespielt hat.
  • Zweifelsohne ist noch Requalifikationsbedarf vorhanden – diese Tests jedoch können auch auf der Erde stattfinden, beispielsweise mithilfe von Höhenballons.

Aus meiner Sicht ist also Schiaparelli eher ein Erfolg als ein Misserfolg.

Michael Khan

Ich bin Luft- und Raumfahrtingenieur und arbeite bei einer Raumfahrtagentur als Missionsanalytiker. Alle in meinen Artikeln geäußerten sind aber meine eigenen und geben nicht notwendigerweise die Sichtweise meines Arbeitgebers wieder.

20 Kommentare

  1. Für mich als Laien stellen sich die folgende Fragen:
    1) Warum wurde die Kombination Fallschirm/Hitzeschild zu früh abgeworfen und
    2) warum waren die Bremstriebwerke nur so kurz aktiv.

    zu 1) Welches Ereignis löst den Abwurf des Fallschirms und des Hitzeschilds aus? Basiert es auf der Messung der Höhe über Grund mittels Radar, ist das über einen fixen Zeitpunkt festgelegt oder sind es die von Schiaparelli gemessenen Flugzeiten und Beschleunigungen, die dieses Ereignis auslösen

    zu 2) Ist der Treibstoff in den Bremstriebwerken so knapp bemessen, dass sie nur ganz kurz aktiv sein können oder schalten sich die Triebwerke ab, wenn Schiaparelli eine nur noch kleine Distanz zum Boden misst?

    • Zu Ihre Fragen 1.) und 2.): Eben das ist ja die große Frage, die die Expertenkommission klären will.

      Das Abtrennen der Back Shell und des Fallschirms sollte bei einer Höhe von 1.3 km stattfinden. Dieser Punkt sollte durch den geschlossenen Regelkreis bestimmt werden, unter Nutzung des Trágheitsnavigationssystems und der Radardaten. Offenbar hat das nicht funktioniert. Jetzt ist zu klären, woran das lag. Gleiches gilt auch für die Steuerung der Triebwerke, deren effektive Schubkraft (als Mittel über Schub- und Leerzeit) geregelt werden kann, indem man sie gepulst betreibt.

  2. Soweit noch zu erfahren war, riss der Funkträger erst 19 Sekunden nach der Abschaltung der Triebwerke ab: Würde das im beschriebenen Szenario eines freien Falles in der Atmosphäre dem Zeitpunkt des Aufpralls entsprechen? (Danach kann es ja schwerlich gewesen sein, wohl aber theoretisch davor.) Wissen Sie, ob in jenen 19 Sekunden noch brauchbare Telemetrie übertragen wurde, aus der die “Befindlichkeit” Schiaparellis hervorgeht, d.h. ob der Bordrechner ‘glaubte’, die Landung habe bereits stattgefunden (so wie 1999 der des ebenfalls wegen verfrühter Triebwerksabschaltung abgestürzte Mars Polar Lander)? Und noch eine Frage, auf die ich gestern bei erneuter Lektüre bzgl. der vorgesehenen Experimente des EDM am Boden kam: Kann man sich vorstellen, dass INRRI oder zumindest einzelne der Corner-Reflektoren den Crash überstanden haben und so Schiaparelli doch noch eines Tages für einen Orbiter als Laser-Target dienen könnte?

    • Ist das mit den 19 Sekunden inzwischen konsolidiert und bestätigt?

      Wie auch immer, wenn man die sehr einfache Überschlagsrechnung der minimal erforderlichen Absturzdauer, kommt man selbst bei einem Fallschirmabwurf in 2 km Höhe mit 19 Sekunden nur hin, wenn man den Luftwiderpstand und die geringer Abbremsung durch die Triebwerke komplett vernachlässigt.

      Sollte der Fehler bereits früher eingetreten sein, also bei einer größeren Höhe, können 19 Sekunden selbst unter diesen unrealistischen Annahmen unmöglich sein.

      Aufgrund der Beobachtung des in Pune empfangenen Signals bzw. der Dauer des Signalempfangs würde ich aber sagen, diese Signalempfang war eher kurz als lang, d.h., die Höhe, bei der das Ungemach seinen Lauf nahm, war eher hoch als niedrig.

      Ich lehne mich mal mit einer Spekulation aus dem Fenster … allerdings nicht sehr weit:

      Das heißt, vom Moment des Abtrennens der Back Shell bis zum Impakt muss eine längere Zeit verstrichen sein.

      Ich lehne mich noch mal ein bisschen aus dem Fenster:

      Ohne die stabilisierende Wirkung des Fallschirms und ohne Triebwerksschub war Schiaparelli bald in einem Betriebsmodus, für den er nicht ausgelegt war. Mit so hoher Geschwindigkeit durch die Atmosphäre?

      Es erscheint mir kaum denkbar, dass er dabei brav seine Lage mit der platten Seite nach unten und der huckeligen Seite mit der helikoidalen UHF-Antenne nach oben beibehalten haben wird.

      Wenn er aber wild ins Taumeln geraten ist, dann zeigt die Antenne irgendwo hin, mal hier, mal da. Da es sich aber nicht um eine omnidirektionale Antenne handelt, sondern eine mit einer gewissen Richtcharakteristik, und da der Korpus des Landers das Signal selbst die Nebenkeulen abgeschattet haben kann, wenn die Antenne nicht mehr richtig ausgerichtet ist, gehe ich davon aus, dass von einem undefiniert taumelnden Lander entweder gar kein Signal mehr empfangen wird, selbst wenn er noch funkt, oder aber bestenfalls irgendwelche unvollständigen Datenframes, die vielleicht empfängerseitig zurückgewiesen werden oder gar nicht als Signal erkannt werden, sodass auch kein Lock mehr möglich ist.

      Das aber ist nur eine Privatmeinung von mir. Mir ist nicht bekannt, on es diesbezügliche Hinweise gibt.

  3. Zur “Erfolg/Mißerfolg”-Bewertung des Demonstrators: Ich denke, zu einer Bewertung ist es noch zu früh. Wenn die gewonnenen Daten dazu führen, dass konkrete Fehler oder Konstruktionsmängel erkannt werden können und somit die künftig anstehende Landemöglichkeit des Rovers entscheidend qualitativ verbessert wird, dann hätte der Demonstrator seinen Zweck genau erfüllt. Wenn die Daten “nichts” hergeben, dann hat der Demonstrator das Gewünschte nicht erbracht. Natürlich wird man dann trotzdem aufgrund des Absturzes gezwungen sein, alle Komponenten konzeptionell und im Detail neu zu bewerten, was aufgrund der Mühe, der Kosten, des Zeitaufwandes etc. sicherlich einen erheblichen Einfluss auf die kommende Mission hätte.

    • Selbstverständlich ist es zu einer abschließenden Bewertung noch zu früh. Die Feststellung, dass eine Reihe für den Eintritt wesentlichen Hardwarekomponenten und ihre Auslösung offenbar wie erwartet funktioniert haben, erscheint mir jedoch auch nach aktuellem Kenntnisstand durchaus zulässig und gerechtfertigt.

  4. Wie sieht es mit den Erkenntnissen und deren konkreten Anwendungen aus? Der Abstieg verlief ja weitestgehend wie geplant; werden diese Vorgehensweisen nach dem Motto “never touch a running system” 1:1 auf Exo Mars 2020 übertragen, oder gibt es noch Spielraum für Optimierungen (die, wenn vorhanden, dann auch umgesetzt werden)?

    • Naja, ob der Abstieg nun “weitestgehend wie geplant” lief oder nicht, dazu wird sich der Bericht der Untersuchungskommission nächste Woche äußern.

      Selbst wenn alles geklappt hätte und Schiaparelli nun funktionierend auf der Oberfläche des Mars stünde, wäre das bestenfalls nur ein Schritt hin zum Entry, descent and Landung-System der Rovermission 2020, denn das ist viel größer und schwerer, braucht einen viel größeren mehrstufigen Fallschirm und soll weich auf der Oberfläche aufsetzen.

  5. Laut Ulrich Walter, 62, Professor für Raumfahrttechnik an der TU München war ein Softwarefehler für den Schiaparelli-Crash verantwortlich.

    Walter: Nach Abwurf des Hitzeschilds zündeten planmäßig die Bremsraketen; aber sie feuerten nur für wenige Sekunden. Dann fiel der Flugkörper aus rund drei Kilometer Höhe wie ein Stein vom Marshimmel. Das Navigationssystem an Bord hatte dummerweise angenommen, dass “Schiaparelli” bereits am Boden angekommen sei – und schaltete zu früh die Bremsraketen ab.

    Ulrich Walter gibt ungenügendem Testen bei der Esa die Schuld für den übersehenen Softwarefehler.

  6. Jetzt hat die ESA den Schiaparelli-Crash wegen vorzeitigem Abbruch der Landesequenz (Schiapi glaubte schon gelandet zu sein) im Bericht SCHIAPARELLI LANDING INVESTIGATION MAKES PROGRESS festgehalten. Kurzgefasst: Eine von der Software nicht vorausgesehene starke und lange Rotation von Schiaparelli führte zu einer Art Software-Überlauf und das bewirkte in der weiteren Berechnung, dass Schiaparelli einen negativen Wert für den Abstand zum Boden erhielt und somit meinte schon gelandet zu sein. Hier die entscheidenden Sätze:

    As Schiaparelli descended under its parachute, its radar Doppler altimeter functioned correctly and the measurements were included in the guidance, navigation and control system. However, saturation – maximum measurement – of the Inertial Measurement Unit (IMU) had occurred shortly after the parachute deployment. The IMU measures the rotation rates of the vehicle. Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected. When merged into the navigation system, the erroneous information generated an estimated altitude that was negative – that is, below ground level. This in turn successively triggered a premature release of the parachute and the backshell, a brief firing of the braking thrusters and finally activation of the on-ground systems as if Schiaparelli had already landed. In reality, the vehicle was still at an altitude of around 3.7 km. This behaviour has been clearly reproduced in computer simulations of the control system’s response to the erroneous information.

    • Nach der Behauptung von vor einigen Wochen, dass das “Radar nicht richtig mit der Steuerungssoftware kommuniziert” hätte, kommt nun offenbar die Mär von einem “Software-Überlauf” (Wie bitte?), in etwa so: “Sonde hat zu stark gewackelt – in der Software gab es einen Überlauf – das hätte man mit einem ‘End-to-End-Test’ herausgekriegt – die ESA wollte den Test nicht machen.”

      Glaubt denn wirklich einer, das sei so simpel? OK, es bedarf keiner Antwort, das glaubt wahrscheinlich mal wieder jeder.

      Dabei steht doch in der ESA-PM von heute (24.11.2016) unmissverständlich:

      As Schiaparelli descended under its parachute, its radar Doppler altimeter functioned correctly and the measurements were included in the guidance, navigation and control system.

      Also, noch einmal zum Mitmeißeln: Das Radar hat spezifikationsgemäß funktioniert. Seine Daten wurden im GNC (Guidance, Navigation and Control)-System (=die Steuerungssoftware im Bordcomputer, die die Lage und Position der Raumsonde aus Sensordaten und aus Propagation, ausgehend von einem bekannten Anfangsstatus weiter propagiert) aufgenommen und verarbeitet.

      However, saturation – maximum measurement – of the Inertial Measurement Unit (IMU) had occurred shortly after the parachute deployment. The IMU measures the rotation rates of the vehicle. Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected

      Klipp und klar: IMU saturation. Die Trägheitsplattform besteht aus Längsbeschleunigungssensoren (accelerometer) und Gyroskopen (Sensoren für Winkeländerungen), davon jeweils einer für jeder der drei Achsen. Jeder solche Sensor ist für einen gewissen Beschleunigungs- bzw. Winkelgeschwindigkeitsbereich ausgelegt.

      Überschreitet die Beschleunigung bzw. in Winkelgeschwindigkeit in bzw. um eine der drei Achsen diesen Auslegungswerk, dann ist der betreffende Sensor gesättigt (saturiert), er gibt nur noch den maximal möglichen Wert aus, nicht die tatsächliche Beschleunigung oder Winkelgeschwindigkeit.

      Also in etwa wie ein Tacho, der am Anschlag ist, auch wenn das Auto nochmals viel schneller fährt, oder wie eine Digitalkamera, die bei kompletter Überbelichtung ein vollkommen weißes Bild liefert, in dem sich nichts mehr erkennen lässt.

      Eine Sättigung sollte man vermeiden, indem man die im schlimmsten Fall mögliche Spitze der Beschleunigung oder Winkelgeschwindigkeit bestimmt, üblicherweise in einer großen Zahl numerischer Simulationen, dann zur Sicherheit noch einen erheblichen Sicherheitsfaktor draufschlägt und die Sensoren so wählt, dass sie mit selbst mit den Worst-Case-Spitzen * Sicherheitsfaktor fertig werden.

      Entweder wurde bei dem verantwortlichen Industrieunternehmen der Worst-Case-Wert zu niedrig angesetzt, oder aber er wurde richtig berechnet, aber die Sensoren wurden nicht korrekt ausgewählt, oder aber, er wurde richtig ausgewählt und die Sensoren auch richtig ausgewählt, aber einer zeigte aufgrund eines Problems fälschlich eine Sättigung an. Was nun der Fall war, genau dies wird die in der PM erwähnte unabhängige Untersuchungskommission heraus finden.

      So. Wir haben hier keinen “Software-Überlauf”, sondern ein eindeutiges Hardwareproblem. Steht in der PM klipp und klar drin.

      Aber offenbar war die Software im GNC-System nicht so ausgelegt, dass sie sicher mit einer kurzfristigen Sättigung (im gegebenen Fall nur etwa eine Sekunde) eines Sensors in der Trägheitsplattform umgeht. Denn in der PM steht weiter:

      When merged into the navigation system, the erroneous information generated an estimated altitude that was negative – that is, below ground level.

      Das bedeutet – bis zur IMU-Sättigung ist alles OK. Dann aber, im Lauf einer Sekunde und infolge der IMU-Sättigung, berechnet die GNC-Software einen Sprung in der Höhe um mehrere Kilometer, was unmöglich sein kann. Nur wenige Sekunden nach Ausfahren des Fallschirms ist die Geschwindigkeit auf 200, dann bald auf 100 m/s gefallen. Es ist also vollkommen ausgeschlossen – IMU-Werte hin oder her – dass die Höhe in ganz kurzer Zeit um viele Kilometer abnimmt. Zumal ja auch noch nach wie vor der korrekte Input des Radars vorliegt, aus dem sich klar die Höhe über Grund ergibt.

      Also ich kleiner Ingenieur hätte an dieser Stelle erwartet, dass die Software, die ja erkennt, dass der Sensor gesättigt ist (ein gesättigter Sensor gibt einen HEX-Code von “FFFFFF” o.ä. zurück), den unbrauchbaren Input überbrückt und auf eine Notfallroutine zurückgreift. In etwa so:

      Für die Höhe: Radardaten benutzen. Für die Positionsdaten in den zwei anderen Koordinaten, die eh nicht so wichtig sind – es interessiert vorwiegend die Höhe – einfach die Daten von vor der Sättigung weiter verwenden.

      Für die Ausrichtung: Einfach 10 Sekunden gar nichts machen und nur abwarten, denn dann ist die Sonde unter dem Fallschirm in guter Näherung im senkrechten Flug nach unten mit vertigalter Ausrichtung und man kann einfach die Lagedaten neu initialisieren. Wichtig ist doch nur, dass man immer weiß, wo oben ist, damit die Triebwerke richtig gesteuert werden können.

      Höhe und vertikale Ausrichtung, das braucht man für die weiche Landung. Alles andere ist primär, wie der große deutsche Denker Hans Krankl dereinst sagte.

      So würde ich das System auslegen.

      Also. Wir haben ein Hardwareproblem, und anscheinend hat die Software, die aus dieser Hardware Input bezieht, auf dieses Hardwareproblem nicht richtig reagiert. das Verhalten der Software ist ja reproduzierbar, wie in der PM steht.

      Was ist nun mit dem angeblich nicht stattgefunden habenden End-to-End-Test: Wenn das ganze wirklich durch ein unerwartet starkes Geschaukel unter den Fallschirm ausgelöst wurde, mit Winkelgeschwindigkeiten, die das der vielfachen numerischen Simulationen im Vorfeld überstiegen, dann ist mir nicht klar, wie nun in einem Test der Erdatmosphäre (wo sonst?) sichergestellt werden soll, dass tatsächlich so starke Oszillationen auftreten, wie sie nun offenbar aufgetreten sind.

      Wenn es aber keinen belastbaren Grund zur Annahme gibt, dass diese dynamischen Verhältnisse im Test auftreten können, die vorher offenbar für die echte Trajektorie für extrem unwahrscheinlich erachtet wurden, dann ist die Behauptung, das Problem hätte mit noch einem Test gefunden werden können, nicht nachvollziehbar.

      Vielleicht kann mir einer der Experten, von denen es in Medien und Blogwelt ja nur so wimmelt, dies mal erklären.

      Ich erwarte eine solche Erklärung mit Spannung. Ansonsten könnte ich ja glatt auf die Idee kommen, das Problem lag ursächlich in der ungeeigneten Implementation der Wiederherstellungsroutine nach Auftreten einer IMU-Sättigung.

      Dass man so etwas in einem Realtest findet, ist unwahrscheinlich. Dafür gibt es die Monte Carlo-Analyse, bei der Abertausende von numerischen Simulationen durchlaufen werden, wobei alle Eingangsparameter unter Verwendung von Zufallsvariablen innerhalb der erwarteten Schwankungsbreite variieren dürfen, sodass jeder einzelne Lauf etwas anders ist als die anderen. Eine solche Analyse hat meines Wissens stattgefunden.

      Aber auch dazu wird mit Sicherheit die unabhängige Untersuchungskommission etwas sagen.

      • Für mich liest sich das

        Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.

        hier so als wenn für Sekundenbruchteile eine kurze Sättigung der IMU erwartet worden wäre. Versteh ich das falsch? Klingt für mich nicht völlig unplausibel, dass man nicht alle kurzfristigen Beschleunigungsspitzen messen können will. Aber wenn schon damit gerechnet wird, dass die Sonde einen Moment zu stark taumelt, dann sollte natürlich abgefangen werden, wenn der Moment länger dauert als erwartet.

        Mich wundert, dass keine Plausibilitätskontrolle die negative Höhe abgefangen und dann den Wert verworfen hat. Die negative Höhe ist sowieso eine Sache, die mich irritiert. Hört sich fast so an als wenn unsigned Int für die Variable verwendet wurde und die Variable übergelaufen wäre. Typischer Fehler in C. Aber wird in Luft- und Raumfahrt nicht Aada benutzt?

        Gibt es (sinnvolle) Radardaten wenn die Sonde zu stark taumelt?

        • [….] als wenn für Sekundenbruchteile eine kurze Sättigung der IMU erwartet worden wäre. Versteh ich das falsch?

          Ja, das verstehen Sie falsch. Die Sättigung der Beschleunigungs und Winkelgeschwindigkeitssensoren sollte explizit vermieden werden. Allerdings gab es auch einen Rückfallmechanismus, falls e doch dazu kam. in welchem Umfang dieser Algorithmus getestet wurde, entzieht sich meiner Kenntnis.

          Das gelang schon einmal nicht, hätte aber meines Erachtens auch nicht die Konsequenzen haben dürfen, die dann auftraten. Übrigens war nicht die IMU komplett gesättigt, es ging nur um eines der Gyroskope. Die Beschleunigungen konnten nach wie vor gemessen werden – das Problem betraf die Winkelgeschwindigkeitsmessung um eine Achse. Warum diese Größe überhaupt einen so einschneidenden Einfluss auf die Berechnung der Position haben soll, entzieht sich ebenfalls meiner Kenntnis.

          Mich wundert, dass keine Plausibilitätskontrolle die negative Höhe abgefangen und dann den Wert verworfen hat.

          Sehr richtig. Es ist physikalisch vollkommen ausgeschlossen, dass ein solch großer Höhenunterschied in so kurzer Zeit auftritt. Das hätte also die Software unbedingt merken und damit der eigenen Positionsberechnung keinen Glauben mehr schenken dürfen. Warum dies nicht geschah, wird die unabhängige Untersuchungskommission herausfinden müssen.

          Gibt es (sinnvolle) Radardaten wenn die Sonde zu stark taumelt?

          Die Radardaten waren korrekt. Die PM der ESA sagt das auch. Mir ist auch nie Gegenteiliges zu Ohren gekommen. Es git vier Radarsensoren, deren Strahl eine spitze Pyramide aufspannt. Die Höheninformation wird aus den vier Messwerten berechnet. Klar, bei zu starker Pendelbewegung (Taumeln ist etwas anderes) können da Ausfälle auftreten. Aber das Pendeln trat kurzfristig und schon viel früher auf, nämlich nach dem Ruck beim Ausfahren. Der Fallschirm wirkt stark stabilisierend und eine Schwingung wird schnell ausgedämpft. Und noch einmal: Die Radardaten waren OK.

          Wie die GNC-Software in einem Sprung von einem richtigen zu einem völlig falschen Positionsvektor gelangte, ist eine Sache. Vielleicht ein Programmierfehler, vielleicht ein Overflow. Aber das halte ich nicht für den zentralen Punkt. Egal wie die dahin kam; Es kann doch nicht angehen, dass nach dem erkannten Ereignis einer Sensorsättigung die Rückfallroutine ihre eigenen Ergebnisse nicht checkt.

          • Danke für die Erklärung des Radars. Die Frage war falsch gestellt, denn das es funktioniert hat war mir bewusst. Der Bericht der Untersuchungskommission wird sicher eine spannende Lektüre, die hoffentlich mein Verständnis nicht übersteigt.

          • Ich habe vorher die Frage in den Raum gestellt, wieso denn die Kenntnis der inertialen Lage (=Ausrichtung) eine so einschneidende Bedeutung für die Berechnung der Position, insbesondere der Bahnhöhe haben kann.

            Ich stelle hier nun mal meine Theorie in den Raum, wie diese Größen zusammenhängen.

            Nehmen wir an, wir haben eine Landesonde, die unter einem Fallschirm hängt. Die Landesonde kann um die vertikale Lage ausgelenkt sein. Der Winkel zwischen der vertikalen Lage und der tatsächlichen Auslenkung sei “alpha”.

            Das Radar sitzt unten an der Raumsonde und misst in Sichtrichtung den Abstand zum Boden. Wenn die Raumsonde genau so ausgerichtet ist, dass ihre Unterseite nach unten zeigt, was der Fall list, wenn der Winkel alpha genau Null beträgt, dann ist der gemessene Abstand vom Boden genau gleich der Flughöhe.

            Wenn die Sonde aber nicht genau in radialer Richtung ausgerichtet ist, dann ist die aktuelle Flughöhe gleich dem gemessenen Abstand vom Boden * Cosinus (alpha). Das funktioniert natürlich nur, wenn alpha kleiner als 90 Grad ist. Aber auch nur dann kann das Radar Sichtbarkeit zum Boden haben.

            Wenn nun aber aufgrund der Sättigung eines Gyroskops die Berechnung der inertialen Ausrichtung komplett falsch ist, dann könnte es sein, dass die GNC-Software fälschlich einen Winkel Alpha größer als 90 Grad heraus bekommt, schlimmstenfalls 180 Grad, obwohl die wirkliche Auslenkung der Sonde nur klein oder sogar Null ist. Das heißt: Der wirkliche Winkel Alpha und der berechnete Winkel Alpha haben nichts mehr miteinander zu tun.

            Dann kommen nach wie vor Radardaten herein. Ist das System schlau, bzw. hat der Mensch, der es programmiert hat, auch Plausibilitätschecks eingebaut, dann müsste es erkennen, dass das Vorhandensein von Radardaten nicht zu einem berechneten Winkel alpha größer 90 Grad passt. Weil das System aber auch wissen müsste, dass zuvor eine Sättigung eines Sensors aufgetreten ist, sollte es diesem berechneten Winkel alpha keinen Glauben schenken, sondern sich allein auf die Radardaten verlassen. Zumindest eine Zeit lang. Messen ist immer besser als vorausberechnen. Allemal, wenn man annehmen muss, dass in der Berechnung der Wurm stecken kann.

            Wenn aber das System nicht mit den notwendigen Plausibilitätschecks ausgestattet ist, dann nimmt es einfach den vom Radar gemessenen Abstand zum Boden, berechnet den Cosinus des berechneten Winkels alpha. Wenn der Wert des Winkels gerade irgendwo zwischen 90 und180 Grad liegt, dann ist der Cosinus dieses Winkels ein negativer Wert.

            Multipliziert man nun den gemessenen Abstand vom Boden mit einem (aufgrund eines grob falsch berechneten Winkels alpha) negativen Wert, dann kommt schlagartig eine negative Höhe heraus.

            Dann müsste es natürlich eine zweite Plausibilitätsprüfung geben, denn binnen ganz kurzer Zeit kann die Bahnhöhe ja nicht von einem komfortablen Wert etliche Kilometer über der Oberfläche zu einem Wert deutlich unter der Oberfläche gesprungen sein. Das ist physikalisch vollkommen unmöglich. Das wäre ein weiterer, deutlicher Hinweis darauf, dass es ein Problem mit der Umrechnung der Bahnhöhe gibt und man sich lieber nur auf die Radardaten verlassen sollte.

            Ich kann ja nur hoffen, dass die hier dargelegte Theorie nicht zutrifft, denn dann wäre das System wirklich ein “failure looking for a place to happen”. Es kann doch wohl hoffentlich nicht sein, dass dem Absturz tatsächlich eine so unglaubliche Fehlleistung zugrunde liegt.

      • Danke für die ausführliche Antwort. Es war also die Kombination eines Gyroskop-Fehlers – welches Daten lieferte, die nicht mehr aussagekräftig waren – und einer fehlenden Plausibilitätsprüfung der Daten. Wenn es tatsächlich stimmt, dass die korrekt gemessene Radardistanz zum Boden mit einer negativen Zahl multipliziert wurde, weil der Kosinus eines Winkels einen negativen Wert ergab, dann wurde eine physikalisch nicht mögliche Situation nicht erkannt.
        Immerhin: Zusätzliche Plausibilitätsprüfungen dürften das System robuster machen – und das ohne damit neue Fehlerquellen einzuführen.

        Erstaunlich finde ich, wieviel man rekonstruieren konnte. Habe immer gemeint die während des Abstiegs zur Erde übertragenen Daten wären zu wenig detailliert dazu.

        • Wir werden ja sehen, was der endgültige Untersuchungsbericht sagt. Irgendwann einmal.

          Vielleicht liege ich ganz falsch. Allerdings ist die Tatsache, dass an Bord auf einmal eine negative Flughöhe im System auftauchte, unbestritten und steht auch so im zitierten Zwischenbericht der ESA. Die Fragen ist nun, wie das passieren konnte, und natürlich, warum das nicht geprüft wurde. Immerhin gab es ja begründeten Anlass, am Rechenergebnis der GNC-Software zu zweifeln.

          Schiaparelli übermittelte übrigens seine Daten nicht zur Erde, sondern zum TGO. Nur 8 kbit/s, aber das reicht für die technisch relevanten Systemdaten.

          Und nein, es lag kein Gyroskopfehler vor. Das Gyroskop, das gesättigt war, verhielt sich zu jeder Zeit auslegungskonform. Es machte genau, wofür es konstruiert war. Seine Ausgabedaten waren auch aussagekräftig. Sie sagten aus, dass kurzfristig eine höhere Winkelgeschwindigkeit um die eine Achse aufgetreten war als der spezifizierte Maximalwert, den dieser Sensor messen konnte. Ich sehe da keinen Fehler bei dieser Hardwarekomponente.

          • Dass die Erde die Messdaten indirekt, nämlich über den TGO erhielt, davon bin ich auch ausgegangen, denn für eine direkte Kommunikation hätte entweder der Schiaparelli-Sender sehr stark oder die empfangende Antenne auf der Erde sehr gross sein müssen. Oder gibt es Marssonden, die während des Abstiegs Daten erfolgreich direkt zur Erde zurückgefunkt haben?
            Betreffend Gyroskop habe ich schon die richtige Annahme gemacht: Das Gyroskop war gesättigt und lieferte den Sättigungswert (0xFFFFFF oder ähnliches) korrekt. Doch aus ihren Ausführungen habe ich entnommen, dass das Gyroskop und seine Sensoren so ausgelegt hätten sein müssen, dass keine Sättigung eintritt:

            Eine Sättigung sollte man vermeiden, indem man die im schlimmsten Fall mögliche Spitze der Beschleunigung oder Winkelgeschwindigkeit bestimmt, üblicherweise in einer großen Zahl numerischer Simulationen, dann zur Sicherheit noch einen erheblichen Sicherheitsfaktor draufschlägt und die Sensoren so wählt, dass sie mit selbst mit den Worst-Case-Spitzen * Sicherheitsfaktor fertig werden.

            Sie schreiben einen Absatz weiter unten sogar:

            So. Wir haben hier keinen „Software-Überlauf“, sondern ein eindeutiges Hardwareproblem. Steht in der PM klipp und klar drin.

            Wobei das Hardwareproblem betrifft wohl die Auslegung des Gyroskops. Es hätte so ausgelegt werden sollen,

            dass sie [das Gyroskop und seine Sensoren] selbst mit den Worst-Case-Spitzen * Sicherheitsfaktor fertig werden

            Besten Dank noch einmal für die Ausführungen. Eine Fehlerinterpretation allein aus dem Bericht ist schwierig, wenn man über die Instrumente an Bord der Schiaparelli zuwenig weiss.

  7. Der offizielle ESA-Untersuchungsbericht ExoMars 2016 – Schiaparelli Anomaly Inquiry ist nun öffentlich zugänglich. Im SPON wird darüber unter dem Titel Computer war schuld an “Schiaparelli”-Crash berichtet. Kurz zusammengefasst: die IMU lieferte gesättigte Werte worauf der Bordcomputer durch diese Werte 1 Sekunde lang blockiert war um dann schliesslich eine falsche Höhe über Grund zu berechnen, nämliche eine negative Höhe. Schiaparelli verhielt sich dann auch so, als sei es bereits auf Grund. Die Antriebsaggregate wurden abgestellt obwohl Schiaparelli noch weit vom Boden entfernt war.

    • Bei SPON steht wie üblich eine Menge Falsches.

      Dadurch wiederum wurde aus den Bewegungsdaten eine falsche Höhenangabe berechnet.

      Was soll das denn wohl heißen und wer soll das verstehen?

      Diese [Bremstiebwerke] sollten eigentlich erst wenige Meter über dem Boden zum Einsatz kommen.

      Unsinn. Die Bremstriebwerke sollen von etwa einem Kiometer Höhe an feuern und die Sonde mit dann abgetrenntem Fallschirm bis auf 2 Meter Höhe und Geschwindigkeit Null briggen. In “wenigen Metern Höhe”, nämlich genau dann, sollten die Triebwerke ausgeschaltet werden und nicht etwa feuern. Diese wenigen Meter wären in freiem Fall zurück gelegt worden.

      Na, und “der Computer war Schuld” ist wohl auch eine beliebig vage Aussage. Eigentlich falsch. Der Computer hat genau das getan, was ihm einprogrammiert war.

Schreibe einen Kommentar