Exomars: Sensorfehler führte zum Absturz von Schiaparelli

[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.