Exomars: Sensorfehler führte zum Absturz von Schiaparelli

[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

[Michael]

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.

was hätte man den besser machen können/müssen?
Zeitfenster verlängern?
So eine Plausibilitätsprüfung kostet vielleicht auch wertvolle Zeit, und wenn das Ding mit 300m/s fällt, dann muss man ja irgendwann reagieren, bevor vielleicht noch schlimmeres passiert.
Ich kann mir vorstellen, dass bei so einem Teil jedes Gramm zählt, mehr Sensoren wären finanziell sicher kein Problem gewesen, mehr Gewicht dadurch aber schon.E
Ehrlich gesagt, fand ich den Vorschlag der 1,7m langen Stochersensoren aus Beitrag #2 nicht wirklich passend bei 300m/s. So schlau waren die ESA-Jungs und Mädels sicher. Das ist so wie bei unseren Robotern, mit Whisker-Sensorik kannst du eben keine hohe Geschwindigkeiten machen.

Gruß, Michael

[i_make_it]

So eine Plausibilitätsprüfung kostet vielleicht auch wertvolle Zeit, und wenn das Ding mit 300m/s fällt, dann muss man ja irgendwann reagieren, bevor vielleicht noch schlimmeres passiert.

Natürlich braucht das Zeit, nach CPU Masstäben.
Die LN-200 IMU hat eine Data Rate von 200-400Hz.
Die drei Glasfaser Gyroskope und die drei MEMS Accerometer liefern 6 Werte als WORD.
Und die RS485 schickt die Daten in 16 Bit also auch Word.
https://claraty.jpl.nasa.gov/main/ha...rol_Dr_B50.pdf

Wenn man die Daten in einen (6 Stück) Ringpuffer schreibt und den aktuellen Wert nur über den Pointer festlegt, dauert das pro Wert 3-5 Takte länger wie das normale Schreiben eines Wertes in eine Variable.
Der LEON 2/Amtel AT697 ist eine 32Bit SPARC CPU mit maximal 100MHz.

Ich handle in meinem Prototypen momentan 6 Accelerometer mit je 3 16Bit Werten (also 18 Werte) bei einer data rate von 400Hz und einer 16Bit CPU mit 16MHz.
Also gehen tut das problemlos.

Man nimmt dann die Differenzwerte zwichen den Datensätzen und vergleicht die.
Das frisst nicht viel Rechenzeit und bei einer data rate von 400Hz hat man dem entsprechend auch 400 Werte pro sekunde, wovon man eventuell 6 mal 4-8 Werte heranzieht.
Also können im ungünstigsten Fall alle 0,01 bis 0,02 Sekunden Entscheidungen getroffen werden. Wenn man mein Beispiel von 300m/s nimmt wären das alle 3-6 Meter.

Wenn das Bremstriebwerk z.B. für 15 Sekunden Treibstoff hat, und der Lander laut Vorgabe sein Triebwerk vor dem Bodenkontakt abstellt und den Aufschlag über eine plastisch verformbare Struktur absorbiert, dann kann man die kritischen Phase auch problemlos abdecken.
Da das Radar ja an war, stellt sich aber da gar nicht die Frage, da die vom Radar gelieferten Abstandswerte auch zu einer Sinkrate umgerechnet werden können. Die springt zwar, aber man kann die Mittlere Antenne als Fixpunkt nehmen dessen Wert nur durch das tatsächliche Pendeln schwankt.
Die werte der anderen drei Antennen kann man sogar umrechnen un die fehlerhafte Drehrate der IMU auszugleichen. denn jeder Minimumwert einer Antenne kommt ja einmal pro Umdrehung vor.
Somit hat man 3 Werteseätze die um 120° versetzt immer zeigen wann diese Antenne jeweils die kürzeste Entfernung zum boden zeigt.
Das Radar hat laut Altenia einen maximalen Höhernfehler von 0,7 Meter, von 0,5m/s bei der Geschwindigkeit und unter 5° bei der Abweichung der Lage von der Senkrechten.
es liefert also selbst schon fertige Werte die nicht mehr umgerechnet werden müssen.
Man hätte also nur die Entscheidung den oberen Hitzeschild mit dem Fallschirm abzuwerfen einfach nicht ausschließlich von den Werten der IMU abhängig machen müssen.

[Peter(TOO)]

Hallo Michael,

was hätte man den besser machen können/müssen?
Zeitfenster verlängern?
So eine Plausibilitätsprüfung kostet vielleicht auch wertvolle Zeit, und wenn das Ding mit 300m/s fällt, dann muss man ja irgendwann reagieren, bevor vielleicht noch schlimmeres passiert.
Ich kann mir vorstellen, dass bei so einem Teil jedes Gramm zählt, mehr Sensoren wären finanziell sicher kein Problem gewesen, mehr Gewicht dadurch aber schon.E

1. Man hat zwei unabhängige Systeme, welche die Höhe angeben. Wenn die Angaben um grob 6km auseinanderliegen, kann was nicht stimmen! Die Differenz der beiden Werte zu bilden und mit einen Grenzwert zu vergleichen ist wirklich kein Rechenaufwand. Der beginnt erst, wenn man den Fehler festgestellt hat.
2. Eine negative Höhenangabe von -2km ist irgendwie neben der Realität, da wundert man sich eher, wieso der Rechner noch funktioniert.

So viel zur Plausibilitätsprüfung!

Zudem war bekannt, dass die IMU falsche Werte liefern kann und das Bodenradar in diesem Zeitpunkt zuverlässiger arbeitet, also wäre es naheliegend gewesen mit den Radardaten zu rechnen.
Besser wäre es gewesen neben dem Zeitfenster eine Plausibilitätsprüfung zu machen und die falschen Daten wegzuwerfen.
Noch besser die Messwerte gegen eine Trendrechnung zu vergleichen.

So ein Problem hatte ich mal Mitte der 80er Jahre. Die Hardware war ein Hitachi 6301, also ein 6801 Derivat als SingleChip mit 1MHz Taktrate und 2 oder 4 KByte ROM. Also kein Vergleich mit der heutigen Rechenleistung.

Das Problem bestand aus einer 30kg Waage, auf welcher ein Trichter mit Motor und Förderschnecke montiert war. Gefördert wurde Kunststoffgranulat.
Das Problem war, dass wenn so ein Granulatkörnchen in der Schnecke verklemmte, dies Schläge auf die Waage übertrug. Die Störsignale lagen im Bereich von 10kg bis über 15 kg. Dosiert werden sollte in der Grössenordnung von kontinuierlich 100g/Min.

Gelöst habe ich das Problem auch mit einem Puffer, Trendrechnungen, Mittelwerten und Plausibilitätsrechnungen. Ausser beim Nachfüllen war es schon physikalisch nicht möglich, dass sich die Masse innerhalb von Sekundenbruchteilen um 10kg ändert, also eine Fehlmessung und weg damit. Auch die Drehzahlregelung hatte eine endliche Geschwindigkeit, sodass auch hiermit eingegrenzt werden konnte.

Man darf eben nicht nur stur rechnen, sondern muss auch die durch die Physik gegebenen Grenzen überwachen.

Für eine stabile Software sind grundsätzlich, zumindest einfache, Plausibilitätsprüfungen aller Sensoren angesagt. Wenn das Wasser im Wasserkocher 500°C hat, stimmt etwas nicht!
Gute Software macht aber auch innerhalb der Software, an Modulgrenzen, entsprechende Prüfungen.
Auch bei den Stellgrössen von Aktoren muss man entsprechend prüfen. Wenn der Aktor auf 110% gestellt werden soll, darf der ausgegeben Wert nicht nur 10% betragen, weil man einfach die 100er Stellen wegstreicht, sondern man muss halt 100% ausgeben und ggF noch eine Fehlermeldung absetzen.

MfG Peter(TOO)

P.S. SASSER war genau auch so ein Problem. Ethernet kann Datenblöcke bis zu 64KB übertragen. Für das MS-Subsystem waren aber Blöcke mit maximal 4KB definiert. Der Fehler war, dass man, ohne eine Prüfung, den Ethernet-Datenblock in einen 4kB Puffer kopiert hat.
Gerade in einem Netzwerk muss man immer damit rechnen, dass ein Datenpaket versehentlich an einen falschen Port gesendet wird...

[Unregistriert]

also echt, dass die bei der SA so was elementares noch nicht mal wissen - das müssen ja die absoluten Vollpfosten sein. Dass man sowas unkontrolliert auf die ganzen Steuergelder und die ganze Technik loslässt...

- - - Aktualisiert - - -

uups, ESA.
E verschluckt

[White_Fox]

Mir geht das Verständnis für dersrt dumme Fehler sowas von auf die...

Bei Philae waren es Umstände, die nicht vorhersehbar waren. Und dann kam noch eine gehörige Portion Pech hinzu. Die Rosetta-mission war dennoch eine meisterleistung, Fehlschlag hin oder her.

Wenn ich jedoch so lese was für Anfängerfehler bei Schiaparelli gemacht wurden frag ich mich echt, welchen Praktikanten man da unbeaufsichtigt rumfrickeln ließ. Es gibt Fehler, die kann man nicht vorraus ahnen-und es gibt Fehler, die aus Naivität, mangelndem Risikobewußtsein und letztlich Dummheit entstehen. Letztere sind vermeidbar und zumindest ich halte diese Fehlerkategorie für absolut inakzeptabel (vor allem wenn Menschen dabei sterben, war hier nicht der Fall, gab es dennoch).
Zudem sind wir nicht mehr in den 80er Jahren, man sollte meinen daß bereits genug Fehler gemacht und hinreichend dokumentiert sind um genügend Respekt vor solch komplexen Vorhaben aufzubauen. Zumal Prozessabläufe mit der heute verfügbaren Technik weitaus besser realisiert und kontrolliert werden können als noch vor 30 Jahren...

[Unregistriert]

Assembler? haha, eher schon Java. Oder ein RTOS wie OSEK. Oder Python mit Linux. Oder alles zusammen, dann wirds ganz schwierig.