Schiaparelli, Ariane 5 und die Software

Die ESA hat nun bekannt gegeben, warum Schiaparelli, (die ESA wird sicher inzwischen wieder die technische Bezeichnung Entry-Decend-Landing Demo bevorzugen) scheiterte.

Ursache war eine „Sättigung“ der IMU, der Inertial Measurement Unit. Das ist ein System, das die Ausrichtung des Landers im Raum anzeigt. Es gibt an, ob er geneigt ist, oder rotiert etc. Aufgrund dessen hat die Software angenommen, das der Lander schon auf der Oberfläche war bzw. nach der Darstellung sogar darunter. Dabei befand er sich noch in 1,2 km Höhe und die Triebwerke sind gerade einmal einige Sekunden gelaufen. Die Folge: Die Triebwerke wurden abgeschaltet und die Raumsonde fiel ungebremst auf den Mars und schlug mit etwa 300 km/h auf. Der Lander tat so als wäre nichts gewesen, so wurden sogar einige Experimente aktiviert, wie dies nach der Landung vorgesehen war.

Dies ist das zweite Mal, das eine Marssonde bei der Landung durch Softwarefehler verloren ging. Dasselbe passierte schon vor 18 Jahren beim Mars Polar Lander. Damals wurden kurz vor der Landung die Landebeine ausgefahren. Während dieses Prozesses geben die Fühler am Ende der Beine, die Bodenkontakt signalisieren, ein Signal ab, das die Software als Bodenkontaktsignal interpretierte und die Triebwerke abschaltete. Auch hier fiel der Mars Polar Lander auf die Oberfläche und zerschellte. Diesen Fehler fand man, erst als man eine baugleiche Raumsonde überprüfte (beim Mars Polar Lander aufgrund Konzeption und finanzieller Ausstattung des Projektes unterlassen) und man auf den Fakt aufmerksam wurde. Ein Softwareupdate hätte die Mission retten können, hätte man das vorher gewusst. Die ESA hat nach dem Verlust von Beagle gelernt und konnte von Schiaparelli die wichtigste Telemetrie über den Trace Gas Orbiter empfangen und war so fähig den Unfall zu rekonstruieren.

Ariane 5 lässt grüßen

Mich erinnert das stark an den Fehlschlag des Jungfernflugs von Ariane 5. Dort gab es einen Überlauf in einem Programm, weil die Rakete schneller beschleunigte, als Ariane 4, von der man das Programm übernommen hatte. Die entsprechenden Module schalteten sich ab und die Statusinformationen, die sie an den Bordcomputer übergaben wurden, als echte Daten interpretiert, die auf eine enorme Abweichung vom Kurs hinwiesen. Durch das abrupte Schwenken der Rakete, in der noch dichten Atmosphäre, brach die Nutzlastspitze ab und das Selbstzerstörungsprogramm wurde ausgelöst.

Es gibt eine Reihe von Parallelen. So, das beide Fehlschläge durch die Software ausgelöst wurde, die unangemessen reagierte.

So scheint in beiden Fällen die Software nicht so etwas wie ein „Gedächtnis“ zu haben. Sprich: Wenn ich zum Zeitpunkt x Sekunden in 1200 m Höhe bin, kann ich bei x+1 Sekunden nicht auf oder unter der Oberfläche sein. Analog kann ich nicht die Richtung der Rakete innerhalb eines Sekundenbruchteils enorm stark ändern.

Das Zweite sind fehlende Plausbibilitätsprüfungen. Im einen Fall war ein Messwert gesättigt, hätte also verworfen werden müssen. Im zweiten Fall wurden Statusinformationen als echte Daten interpretiert. Eine Software, die einfach nichts gemacht hätte und die Triebwerke in der alten Einstellung weiter betrieben hätte, hätte nach diesem kurzfristigen Ausfall (die ESA spricht von 1 Sekunde) wieder korrekte Navigationsdaten bekommen.

Bei Schiaparelli, wo es anders als bei Ariane 5 nicht durch den Softwarefehler sofort vorbei gewesen wäre, kommt dann noch ein starres Programm hinzu. Man ist gelandet, also aktiviert man die Experimente. Dabei hätte man durch andere Sensoren (Beschleunigungsmesser, Bodenkontaktsensoren) die Information bekommen, das man noch fällt und die Triebwerke erneut anschalten können.

Man sollte innerhalb der ESA den Abschlussbericht des Ariane 5 Jungfernflugs an das Softwareteam von Schiaparelli bzw. des nächsten Rovers, der ja 2020 starten soll, weiterleiten. Dort stehen einige Empfehlungen drin, die eigentlich Stand der Technik sein sollten. Sodass man Werte auf Plausibilität prüft und wenn das nicht geht, einfach mal mit den Daten weiter macht die vorher noch als korrekt befunden wurden. Es gibt ja noch andere Daten welche Informationen über die Sonde liefern so die Beschleunigungssensoren und das Radargerät. Sie hätten wahrscheinlich ausgereicht, um die Sonde erfolgreich zu landen.

Zusätzlich wird man natürlich noch untersuchen müssen, warum die IMU gesättigt war, denn das dürfte nicht passieren.

Software = Badware

Es zeigt aber auch ein Problem auf, das immer häufiger auftritt: Softwareprobleme bei Raumsonden. Juno hat derzeit einige Probleme mit ihren Bordcomputern. Man hat schon die Anpassung des Orbits auf den endgültigen Beobachtungsorbit zweimal verschoben. Auch bei anderen Raumsonden gab es Ausfälle, die bei den meisten Raumsonden und Satelliten dazu führen, dass diese in den Safe Mode gehen, d.h. Sie brechen die Experimente ab und richten sich so aus, das sie Strom von der Sonne bekommen und kontaktieren die Erde. Prominent erwischte das New Horizons wenige Tage vor dem Vorbeiflug an Pluto. Das scheint ein weiter verbreitertes Problem zu sein, als man denkt. Meiner Ansicht nach ist eine Ursache darin, dass die Software sich zwar enorm weiter entwickelt hat, aber nicht die Konzepte der Steuerung. Die ersten Raumsonden wurden durch Kommandos in Echtzeit gesteuert, die Experimente aktivierten, die Sonde drehten etc. Mit dem Auftauchen der Bordcomputer hat man das Konzept beibehalten. Nur werden nun ganze Listen von Kommandos zu Beobachtungsprogrammen zusammengefasst. Wenn es aber ein Problem gibt, dann gibt es keine Kommandos und die Raumsonde wartet oder im Falle von Schiaparelli: Geht einfach zum nächsten Programm über, dem für Inbetriebnahme der Experimente. „Eigenintelligenz“ im Sinne von selbstständigen Entscheidungen gibt es keine.

Fehlende Selbstständigkeit

Das zeigt sich auch bei den Rovern. Für die werden maximale Fahrstrecken pro Tag angegeben. Erreicht werden sie kaum. Der Grund: Die Rover könnten autonom fahren. Dürfen es aber in der Regel nicht. Stattdessen erarbeitet man bei der Missionsleitung einen Plan für die Fahrt zu einem neuen Zielpunkt und spielt den zur Sonde hoch. Der Zielpunkt ist meist nicht weit entfernt, die Route muss ja gut planbar sein. Dort stoppt der Rover, die Umgebung wird untersucht, und selbst wenn man dort nichts tun möchte, muss man nun erst einen neuen Plan für den nächsten Wegpunkt erarbeiten und das dauert. So fährt man immer nur kleine Strecken.

Opportunity ist der einzige Rover der wirklich viel Strecke zurückgelegt hat. Dies geschah erst nach Jahren, als man ihm mehr zutraute und auch weil die Mittel für die Missionsleitung nach mehrfacher Verlängerung der Mission gekürzt wurden. Das ging aber auch nur weil das Gelände wo Opportunity ist, praktisch eine Ebene voller Sand ohne Geröll ist. Opportunity ist übrigens 54 km von Schiaparellis Landeort entfernt. Bei rund 100 m pro Tag könnte er ihn in eineinhalb Jahren erreichen. Nominell kann Curiosity mehr Strecke pro Tag zurücklegen. Doch diese Sonde darf es nicht, weil das Geländer nicht so eben ist. Auf der Erde haben wir inzwischen selbsthaftende Autos, auf dem Mars, ohne Gegenverkehr und Fußgänger ist man davon noch weit entfernt.

Früher war alles besser

Die Frage, die sich mir stellt, ist die, ob man vielleicht wenn man keine sichere Software schreiben kann nicht wieder die alte Methode anwendet. Viking, aber auch Surveyor landeten völlig ohne Bordcomputer. Viking hatte einen an Bord, doch der wurde erst nach der Landung aktiviert. Das geht eigentlich relativ einfach durch analoge Systeme. Ein Beschleunigungsmesser liefert die Geschwindigkeit. Unterschreitet sie eine bestimmte Mindestgeschwindigkeit, so trennt man den hinteren Schild ab und entfalteten den Fallschirm. Unterschreitet sie dann später einen zweiten Punkt, so wirft man den Fallschirm und vorderen Schild ab. Gleichzeitig schaltet man die Triebwerke ein, deren Schub man an die Geschwindigkeit oder Höhe koppelt. Dazu hatte Viking ein einfaches Radargerät an Bord. Das liefert direkt Höheninformationen, über Integration auch Geschwindigkeitsinformationen.

Moderne Software und Radargeräte können mehr. Bei Curiosity und Schiaparelli liefern mehrere Radarkeulen Daten über den Drift, also ob man sich zur Seite bewegt, im unteren Bereich auch über Unebenheiten des Bodens. Doch richtig intelligent ist die Software nicht. Das zeigt nicht nur der Verlauf der Landung, sondern auch die Auswahl des Landegebiets und die Angaben über die Software. Wie Opportunity landete Schiaparelli in einer Ebene ohne Steine. Genauer gesagt: Alle Raumsonden nach 1997 landeten in Gebieten, wo praktisch kein Krater oder auch nur größere Steine vorhanden sind. Vorher gab es nur Aufnahmen von Viking Orbiter mit maximal 8 m Auflösung, danach konnte der MGS Aufnahmen mit 1 m Auflösung und ab 2005 MRO mit 0,35 m Auflösung anfertigen. Die Sicherheitsaspekte sind so wichtig, dass sich dem andere Aspekte unterordnen, obwohl man inzwischen die Größe der Landeellipsen deutlich verkleinern konnte, also ein kleineres Gebiet aussuchen kann, wo die Bedingungen zutreffen. Nur: Wenn ich auf einer Ebene lande, ist es egal ob ich einen seitlichen Drift habe oder nicht. Dass die Raumsonden Bilder auswerten, wie es heute schon Autos tun, ist auch noch Zukunftsmusik. Zwar machen die Sonden Bilder beim Abstieg, doch ausgewertet werden die nicht, stattdessen nach der Landung übertragen um in der Missionskontrolle die Flugbahn und den Landeort genauer zu bestimmen. Wenn die Sonden wirklich intelligent wären, würden sie die Bilder auswerten. Zwischen zwei Bildern kann man den Drift erkennen und man kann hochrechnen, wo man bei gleicher Geschwindigkeit landet. Dann könnte die Software die Sonde so umlenken, dass man in einem glatten Gebiet niedergeht. Es vergehen 3 Minuten von der Inbetriebnahme der Steuerdüsen bis zur Landung bei nur 2 m/s seitlicher Geschwindigkeit kann man so den Landepunkt um 360 m verschieben.

Veraltete Hardware

Sicher mit den Bordrechnern von Exomars ist das nicht möglich. Die SPARC V8 Architektur auf der die Rechner basieren wurde von 1992 bis 1995 bei Sun eingesetzt, die Rechner entsprechen also 20 Jahre alter Technik oder in etwa der technischen Leistung eines Pentiums. Doch es gibt ja zum einen gerade für die Bildverarbeitung die Möglichkeit die Algorithmen in Hardware zu gießen und als logikprogrammiertes Array mitzuführen, entweder unveränderbar oder über Software neu beschreibbar. Alternativ kann man auch einen normalen PC-Prozessor nehmen. Wenn er nur wenige Minuten arbeiten soll, würde auch nicht strahlungsgehärtete Hardware ausreichen. Durch Redundanz könnte man sich gegen den Fall eines Ausfalls oder kosmischen Teilchens, das Bits kippen lässt, absichern.

Wenn man wirklich die Software aktiv eine Landung steuern lässt (im obigen Sinne das sie aktiv den Kurs nach Betrieb der Triebwerke steuert), dann sehe ich große Potenziale. Man kann dann viel mehr Gebiete erreichen. Die Landeellipse von Schiaparelli hat z.B. einen Durchmesser von 100 km in Ost-West Richtung und 15 km in Nord-Süd. Innerhalb dieser Ellipse muss das Gelände weitestgehend risikolos sein. Wenn der Lander aktiv eine Zone ansteuern kann, dann kann man die Ellipse deutlich verkleinern. Dann kommen auch viele interessante Gebiete in Frage, die heute einfach nicht diese großen Zonen aufweisen. Eine Landung am Boden von Valles Marineris würde sicher einen atemberaubenden Umblick liefern, dazu noch Gestein aus der Tiefe. Man könnte in einem der vielen Flusstäler oder chaotischem Gelände landen. Dazu gehören natürlich auch andere Maßnahmen. So erlaubte eine bessere Navigation und kurz angesetzte Kurskorrekturmanöver die Reduktion der Landellipse bei Curiosity auf 20 x 6 km, also eine 13-mal kleinere Fläche als bei Schiaparelli. Allerdings tritt bei dieser Mission der Bus mit in die Atmosphäre ein, das erlaubt noch Kurskorrekturen in kürzerer Zeit und man muss nicht auf den Bus Rücksicht nehmen. Bei Schiaparelli war die Hauptnutzlast aber der Orbiter und Schiaparelli nur eine Demo.

In jedem Falle hat die ESA noch einige Arbeit vor sich. Ich bin mal gespannt, ob man einen Untersuchungsbericht, wie bei dem Versagen von Ariane 5 veröffentlicht.