Ariane 5 lässt grüßen<\/h3>\n![\"Schiapareli](\"http:\/\/www.esa.int\/var\/esa\/storage\/images\/esa_multimedia\/images\/2016\/11\/schiaparelli_in_colour\/16475178-1-eng-GB\/Schiaparelli_in_colour_node_full_image_2.png\")
<\/a>Schiaparelli Aufschlagsstelle (c) des Fotos NASA\/ESA<\/figcaption><\/figure>\nMich erinnert das stark an den Fehlschlag des Jungfernflugs<\/a> 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.<\/p>\nEs gibt eine Reihe von Parallelen. So, das beide Fehlschläge durch die Software ausgelöst wurde, die unangemessen reagierte.<\/p>\n
So scheint in beiden Fällen die Software nicht so etwas wie ein \u201eGedächtnis\u201c 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Zusätzlich wird man natürlich noch untersuchen müssen, warum die IMU gesättigt war, denn das dürfte nicht passieren.<\/p>\n
Software = Badware<\/h3>\n
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. \u201eEigenintelligenz\u201c im Sinne von selbstständigen Entscheidungen gibt es keine.<\/p>\n
Fehlende Selbstständigkeit<\/h3>\n
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.<\/p>\n
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.<\/p>\n
Früher war alles besser<\/h3>\n
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.<\/p>\n
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.<\/p>\n
Veraltete Hardware<\/h3>\n
<\/a>Mich erinnert das stark an den Fehlschlag des Jungfernflugs<\/a> 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.<\/p>\n Es gibt eine Reihe von Parallelen. So, das beide Fehlschläge durch die Software ausgelöst wurde, die unangemessen reagierte.<\/p>\n So scheint in beiden Fällen die Software nicht so etwas wie ein \u201eGedächtnis\u201c 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Zusätzlich wird man natürlich noch untersuchen müssen, warum die IMU gesättigt war, denn das dürfte nicht passieren.<\/p>\n 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. \u201eEigenintelligenz\u201c im Sinne von selbstständigen Entscheidungen gibt es keine.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\nSoftware = Badware<\/h3>\n
Fehlende Selbstständigkeit<\/h3>\n
Früher war alles besser<\/h3>\n
Veraltete Hardware<\/h3>\n