Exomars: Sensorfehler führte zum Absturz von Schiaparelli

[i_make_it]

Ich vergleiche ein erfolgreich getestetes System von "Surface sensing Probes" mit einem System das versagt hat und einen entsprechend teuren Verlust verursacht hat, weil es das einzige System war und somit der Computer nicht feststellen konnte das ein Fehler vorliegt.

Ich weis was mich ein Flug zum Fallschirmspringen kostet, deshalb lass ich aber nicht meinen Reserverschirm mit integriertem barrometrichem Ausloser weg weil ich ja schon einen Höhenmesser am Handgelenk habe.

Die Sonde wäre mit redundanten Systemen etwas teurer geworden, der Start und der Flug wären auch etwas teuerer geworden, ja.
Aber jetzt stehen dem ein hoher dreistelliger Millionenbetrag für gar nichts gegenüber.

# # #

Was ich als Designfehler in der Software betrachte, ist das sie an massiver Alzheimer leidet.
Aktuelle Messwerte werden verarbeitet und für entscheidungen Herangezogen.
Es gibt aber kein Gedächtniss, das eine gewisse Spanne von Werten z.B. in einem Ringpuffer hält und so neue Messwerte auf Plausibilität gegen die alten Werte prüfen kann.
Wenn die Sinkrate vorher ausgerechnet wurde, und die Sampling Rate der Sensoren bekannt ist, dann weis man auch um wieviel sich ein Sensorwert maximal zwichen zwei Messungen verändern kann.
Das ein positiver Höhenwert plötzlich in einen negativen Wert umspringt und der Lander somit schlagartig von plus 3,7km auf minus 2km seine Position verändern soll, wäre so aufgefallen.
Der Computer hätte bei entsprechender Programmierung und Daten über die Dichte der Atmosphäre, sogar versuchen können die Sinkrate zu schätzen (interpolieren) und so eventuell die Landung blind auszuführen.
Das wäre ein Fallback gewesen, das gar kein Zusatzgewicht verursacht hätte und die Überlebenschance des Landers zumindest auf ein realistischs Maß erhöht hätte.
Wenn der Schirm ein Rundkappen Schirm ist, also sowieso nicht steuerbar, dann hätte man auch den Schirm an einer längeren Leine befestigen können und dort einen simplen Kraftsensor anbringen können.
als Fallback wäre der Schirm dann solange am Lander geblieben bis die Zugkraft durch die Landung nachlässt und dann getrennt worden.
Bei geringem Wind besteht dann zwar das Risiko das der Schirm zu nahe oder auf dem Lander runterkommt, aber damit wären nur ein paar Experimente ausgefallen und nicht das komplette System.

Wenn man sich den Auffand ansieht, mit dem bei den Raketen die Systeme, wo es nur geht dreifach ausgelegt werden um eine Erfolgschance zu maximieren, dann finde ich es halt Verschwendung von Steuergeldern wann bei dem letzten Missionsabschnitt keinerlei Ersatzsysteme vorhanden sind.
Um das Argument mit den Kosten pro Kilo "Übergepäck" aufzugreifen:
Der selbe Kostensatz der für jedes Kilo Übergepäck gilt, gilt logischerweise auch für jedes andere Kilo das befördert wird.
Es gibt kein Kilo Grundlast das zum Preis X fliegt und kein Kilo Übergepäck das zum Preis Y fliegt.
Wenn man also Die Kosten sieht die anfallen um alles erstmal bis an diesen Pukt im All zu befördern, dann macht das Sparen mit dem entstehenden potentiellen Ausfallsrisiko und den dadurch fehlenden Geldern an anderer Stelle, gar keinen Sinn.

[Ceos]

auch diese MAschiene wurde nur von einem MEnschen programmiert ... schlimmer sogar, von mehreren Menschen!

Jemand hat einen Treiber programmiert, der Messwerte für den Rotationssensor ausgiebt und hat 95% seiner möglichen Ausgabewerte Dokumentiert und der arme TRottel der die Auswertung programmiert hat hat auch diese 95% zu erwartenden Werte berücksichtigt. Jetzt kommt aber genau diese 5% Situation zustande und die Auswertung erkennt nicht dass es ein FEhlerwert sein soll und rechnet es folgenschwer in die Formel ein die pöötzlich einen negativen Messwert ergibt.

Klar hätte man da Fallback und Vergleichsmessung hinzuziehen können, aber die Erfahrung macht man meistens erst NACH dem Fehler.

Es ist wie im realen Leben (und ich arbeite als Entwickler für eine Sensorfirma ich habe also schon entsprechenden Humbug erlebt) da hat man ein Gerät mit den Spezifikationen und dem Datenblatt und der Hersteller ist halt der Meinung er muss sich eigene Fehlerwerte ausdenken und dokumentiert sie nicht.

In der Fertigung gibt es ständig Fehlermeldungen die dann bei mir auf dem Tisch landen und ich darf mich dann erstmal mit dem Hersteller auseinandersetzen was genau der Fehler bedeute um dann heraus zu finden was wir falschen machen dass seine Komponente diesen Fehler hervorbringt.

Blöderweise ist man selber immer blind, man testet Dinge auf dem Labortisch nicht wirklich unter realen Bedingungen und reale Bedingungen zu simulieren kostet Zeit und Geld ... alles Dinge die man meist nicht hat in der freien Wirtschaft, also gibt es immer wieder mal unerwartete Bedingungen.

Ich denke mal dass derjenige, der an der Auswertung gearbeitet hat, den Sensor schon mit üblen Schlägen und Stürzen maltretiert hat und dabei niemals diesen einen Fehlerwert bekommen hat.

[i_make_it]

Und genau deshalb kann (und sollte) plausibilitätsprüfungen machen. (ungeachtet dessen ,das die Menschheit allgemein und die ESA im Besonderen, nicht zum ersten mal Sonden baut die auf fremden Hoimmelskörpern landen).
Da ich dei werte nicht habe, neheme ich einfach mal an Sinkrate 300m/s. jetzt nehmee ich alle Sekunde einen Mittelwert über 4 Messungen und schiebe den in einen Ringpuffer. Nehme immer die Differenz zwichen 2 Werten und komme auf die 300m/s.
Plötzlich spinnt der Sensor und gibt die fehlerhaften Werte aus. in ein paar Millisekunden springt meine errechnete Höhe um 5,7km ins Minus. Wenn also plötzlich eine Sinkrate von 5700m/s auftaucht kann was nicht stimmen.
Es wird ein Fehlerflag gesetzt und ausgerechnet wie lange der Abstieg anhand der letzten zueinander stimmigen Werte noch dauert.
Passiert das unterhalb eines bestimmten Schwellwertes (maximale Brenndauer des Triebwerks) wird die Landung eingeleitet und man hofft das alles glatt geht.
ist der Wert der restlichen Abstiegszeit groß genug wird blind nach diesen Daten gearbeitet. Stimmen die Sensorwerte wieder überein, (was ja nach ca. einer Sekunde der Fall war. Nur war da der Schirm bereits abgetrennt) macht man mit der geschätzten Höhe und der gemessenen Sinkrate einfach weiter und verlegt den Start der Radarmessung für die Abstandsermittlung etwas nach vorne.
Das kostet mehr Energie und die Batterien reichen dann nicht mehr die geplanten 8 Tage, aber mit der jetzigen Situation hat man keine 7 oder 7,5 tage sondern einen neuen Krater im Mars.
Wie man sowas macht hatte die NASA ja schon vorgemacht, also weder Erstleistung noch glanzvoll.
Die Entwicklung eines nicht komerziellen Raumfahrzeugs für Forschungszwecke sollte nicht den zwängen einer gewinnorientierten Produktentwicklung unter Konkurenzdruck unterliegen.

Ich entwickle auch grade ein Messgerät auf Basis von Beschleunigungssensoren.
Mein Produktmanager ist Dr. der Informatik und der zuständige Geschäftsführer seit Jahren in der entwicklung tätig.
Nachdem ich einen minmal Prototypen abgeliefert habe und damit eine Machbarkeitsstudie erstellt habe (mit Schwerpunkt was alles nicht so einfach oder gar nicht geht und was nur geht bei richtiger Handhabung) habe ich die Lister der notwendigen Hardware für einen vollwertigen Prototypen abgegeben und dazu die Rhos, EMV und Messgeräte Verordnung mit dem Hinweis, das vom Prototypen bis zur Serienreife locker 15k€ für Prüfungen rauf gehen können, sowie den Hinweis, das die Patentlage zu einem solchen Meßsystem erst mal zu prüfen ist bevor da weitere Entwicklungskosten anfallen.
Bei der Frage nach dem Zielmarkt kamen wir auf initial rund 400 Geräte und daß sie bei einem konkreten Kunden ein Einsparpotential von 10k€ pro Einsatz bringen.
Also ist ein Preis von 2000€ vertretbar.

Allerdings erwarte ich eigentlich, das nicht ich der eigentlich für die IT zuständig ist, a) die Entwicklung macht und b) das recherschieren solcher Themen anstoßen muß.
Allerdings stelle ich fest das ich mit einer der ältesten im Unternehmen bin und einer der wenigen der all diese Bereiche schon mal gelernt bzw. selbst abgedeckt hat.
Das selbst Denken und vor allem das weitsichtige Denken wird heute allem anschein nicht mehr gelehrt und noch weniger angewand.
Es wird zunehmen in kleinen Schubladen gedacht und "das nicht sein kann, was nicht sein darf".

[Unregistriert]

ich glaube ehrlich gesagt nicht, dass hier irgendwer im Forum allgemein und in diesem Thread speziell das Wissen und die Hintergrund-Informationen aus erster Hand besitzt, um hier wirklich fundiert zu den tatsächlichen Ursachen des Crashs Stellung nehmen zu können, und schon gar nicht aus einer schulmeisterhaften Position heraus nach dem Motto "jeder weiß doch..." oder "eigentlich hätte die NASA wissen müssen" gespickt mit dem eigenen eigenen Erfahrungsschatz des eigenen Berufslebens....
Sollte hier wirklich grob fahrlässiges Verschulden oder Vernachlässigung der Sorgfaltspflicht die Ursache gewesen sein, wird die NASA sicherlich schon wissen wie sie mit den Verantwortlichen umzugehen hat. Blutigen Anfängern wird man die Sensorik und die Programmierung ja nun wohl sicherlich nicht blind und unkontrolliert übertragen haben.
Oder denkt hier jemand, man sollte doch mal der NASA einen Wink geben, damit sie künftig weiß, wer hier im Forum der richtige Ansprechpartner ist, um sie bei ihren Projekten endlich mal fundiert unterstützen kann, damit nicht wieder ständig solche peinlichen und nun wirklich vorhersehbaren Anfängefehler bei ihren Missione passieren ?

[Ceos]

ich sag ja nur dass man nicht alles vorhersehen kann und vor allem den technischen Gegebenheiten und der Dokumentation ausgeliefert ist. Was die Verantwortung angeht, da wird sicher eine Untersuchung laufen wie es dazu gekommen ist um Zukünftig mehr Sorgfalt walten zu lassen. Ich behaupt ja auch nicht dass ich es besser gekonnt hätte aber meine Erfahrung zeigt auch dass man mit mehr Zeit besser Entwickeln kann! Aber mehr Zeit kostet auch erheblich mehr Geld.

Man versucht immer einen Break-Even zu finden und erreicht eben nur endliche Sicherheit. Dass es nun genau zu dem Corner-Case gekommen ist ist einfach tragisch und ärgerlich ... bei der NASA stehen jetzt bestimmt auch ein paar Leute mit verkniffenem Gesicht und denken sich "das hätte ich/man besser machen können"

ich bleib dabei Irren ist Menschlich und Maschinen sind von Menschen gebaut ...

Aber mal OT ich finde es schon etwas witzig mit anzusehen wie die mäkeligen Kommentare mit den ganzen Spitzfindigkeiten vor allem mal wieder als unregistriert abgegeben werden.

Mach dir mal n Account damit ich dich besser wiedererkennen kann wenn du selber mal vom Stapel ziehst oder Blödsinn redest oder dich aus dem Fenster lehnst. Diese Anonymität finde ich zumindest persönlich gesehen unhöflich

aber hey, no hard feelings


ich vermisse den Daumen Hoch smiley

[i_make_it]

Bei der NASA interessiert das wohl nur wenige etwas am Rande.
Die grinsen wohl höchstens hinter vorgehaltener Hand das Sie nicht die einzigen sind die wegen Softwarefehlern eine Sonde in den Mars gecrasht haben.
Schiaparelli ist eine ESA Sonde und wurde gebaut von Thales Alenia Space.

Da ein (mittlerweile ehemaliger) Arbeitskollege von mir jahrelang direkt in der ESOC die IT betreut hat und meine ehemalige Rollenspielleiterin bis Ende 2014 (Missionsende) dort tätig war, habe ich da aus Sicht der Wissenschaftler und aus Sicht der IT einen gewissen Einblick.
Und mit dem Wissen will man manchmal gar nicht noch mehr wissen.
Eines der Probleme ist Eurokratie. (Bürokratie mit vielen nationalen Chefs die alle was zu sagen haben wollen)
Z.B. findet man alle Äußerungen von "Andrea Accomazzo" zu dem Vorfall in wunderbaren italienisch.
Warum auch sollte sich der "head of solar and planetary missions" an die ESA (und EU) Verkehrssprachen Englich, Französisch oder Deutsch halten.
Und da fangen die Probleme halt schon an.
Ob die Software am Ende von einem ESA Programmierer oder gar von einem Inder (als Outsourcingwunder) für Thales programmiert wurde ist eigentlich egal.

Ich habe nur Systemsoftware für CNC Maschinen geschrieben, aber da bin ich schon vor 20 Jahren nach dem Schema vorgegangen.
Die Plausibilitätsprüfung ist einfach eine Sicherheit dafür, das alle in den Testszenarien vergessenen Fehlerquellen nicht ungehindert durchschlagen.
Man will halt nicht das eine 9000kg CNC Achse mal mit 30m/s² beschleunigt wenn in der Maschine jemand mit JOG-Pannel steht und bei der Betriebsarten wahl was unmögliches eingestellt hat und dann die Tastenkombination erwicht, die mit dem gebrückten Sicherheitsschalter und der Zugeklebten Fotozelle die Datnekombination ergibt die Sagt jetzt mal Volldampf vorraus.

Wenn Die ESA selbst angibt, dass sie das Fehlverhalten problemlos 1:1 in kürzester Zeit im Simulator nachstellen konnte, dann wurde geschlampt.
Wenn die Wochen oder gar Monate brauchen würden um den selben Fehler nachzustellen, weil die Kombi so außergewöhnlich ist das man da nicht draufkommt und es auch nicht erwartet, dann "shit happens" aber auch das könnte man mit dem beschriebenen Verfahren abfangen.

[oberallgeier]

.. dass man .. technischen Gegebenheiten und der Dokumentation ausgeliefert ist. .. mehr Zeit kostet auch erheblich mehr Geld .. "das hätte ich/man besser machen können" ..

Das mit Zeit/Geld ist einer der Knackpunkte in dessen Wirbelschleppe immer wieder ahnungs- oder verantwortungslose Vorsitzende, Vorgesetzte manchmal auch Kollegen herumschlackern und Druck machen, wider besseres Wissen Freigaben erteilen oder erzwingen etc. Nicht nur die Challengerkatastrophe zeigt das überdeutlich. Und all die unausgewogenen Mondmännlein wissen ja hinterher immer alles besser.

Was bleibt ist die Unmöglichkeit die Abwesenheit von Fehlern zu beweisen. Vorher - und oft nachher.

[Man in the moon]

Wie heißt so schön? "Talk is cheap". Es war schon immer einfach hinterher daher zu kommen und zu herum zu labern was die anderen alles falsch gemacht und wie man es es denn besser macht, ohne auch irgendeinen Einblick in die Funktionen solcher Teile zu haben.

[Ceos]

NASA ESA ja sorry gedankendreher

haha oh ja @oberallgeier das mit den Vorsitzenden schimpft sich bei uns Produktmanagement

keinen rechten Plan von der internen Materie, haben die Kundenwünsche im Hinterkopf, hören sich die "Möglichkeiten" an, reden die "Umstände" runter, legen einen Zeitplan fest und machen dann Pflichtenhefte damit und wir dürfen sehen wie wir das dann in der geplanten Zeit entwickeln dürfen!
Hirarchie ist eine große Bremse in der Entwicklung ... zumindest wenn man von der Entscheidungsgewalt mal ausgeht.
Wenn mir das Management einfach die Wünsche erklärt kann ich sagen ob oder ob nicht und wenn, dann wie lang ich dafür brauche. Aber wenn man mal kreativität vom Management verlangt fantasieren die immer an der Realität vorbei ...

[i_make_it]

Also die Funktion der Northrop Grumman LN-200 IMU ist bekannt und dokumentiert.
Auch die Hardware der anderen von Thales verbauten Systeme ist bekannt
Auch die CTPU an der die IMU per RS 485 hängt ist bekannt und das die CTPU einen 32 Bit LEON Kern enthällt.
Da LEON für die ESA entwickelt wurde, und LEON2 in Hardware ein Amtel AT697 ist, ist also auch die Architektur verfügbar.
Der Einblick in den Aufbau und in die Funktionen ist durchaus gegeben. Aber halt nicht in den Code (also die Implementierung der Funktionen).
Die Hardware Komponenten sind alle im größeren Umfang bereits in der Luft- und Raumfahrt zum Einsatz gekommen und getestet.
Da nach dem ESA eigenen Test auch von einem "Glitch" gesprochen wurde, ist es also die Software.
Ändert nichts daran, das man dort beim Softwaredesign einiges hätte tun können um das Versagen zu vermeiden.
Wenn man sich ansieht, wo die LN-200 IMU überall erfolgreich in der Raumfahrt eingesetzt wurde und wird,
kann man allerdings daran zweifeln ob wirklich der Sensor eine Sekunde ausgesetzt hat oder ob da nicht auch in der Software was daneben ging.
Da wird man wohl den detailierten Bericht abwarten müssen.

Nachtrag:

Noch mehr AUA.

Ich habe mir grade das offizielle ESA Statement von vorgestern durchgelesen.
Das Dopplerradar war bereits im Betrieb und die fehlerhaften Daten nach dem öffnen des Schirms wurden erwartet.
Nur das es eine Sekunde dauert war, war länger als erwartet.
Wenn man Moltkes Zitat "kein Plan überlebt die erste Feindberührung" mal verallgemeinert auf "Du kannst planen was Du willst es passiert doch was unerwartetes", Dann ist seit weit über 100 Jahren bekannt das man sich nicht darauf verlassen soll was man erwartet.
Es gibt als Höhendaten und Sinkrate von einem Dopplerradar und Höhendaten sowie Lagedaten einer IMU. Und es ist bekannt das die IMU nach dem öffnen des Schirms falsche Werte leifern wird.
Trotzdem hat man einfach ein Zeitfenster gesetzt wo man die IMU Daten ignoriert und danach sämtliche Entscheidungen nur auf die IMU gestützt und die anderen Systeme ignoriert.
Das war richtig geschlampt.


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.

http://www.esa.int/Our_Activities/Sp...makes_progress