Exomars: Sensorfehler führte zum Absturz von Schiaparelli

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

[Peter(TOO)]

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.

Etwas irritierend ist, dass mehrere unabhängige Systeme versagt haben:
1. Das Landegestell selbst sollte durch Dämpfer schon so abfedern, dass wieder hoch hüpfen verhindert wird.
2. In jedem der drei Landebeine gab eine Bohrschraube, welche sich rein durch die mechanische Energie beim Aufsetzen ins Eis bohren sollten.
3. Ein Triebwerk oben auf Philae sollte den Roboter beim Aufsetzen an den Boden anpressen. Dieses Kaltgas-Triebwerk besteht eigentlich nur aus einem Druckluftbehälter und einem Ventil und soll in anderen Missionen immer zuverlässig gearbeitet haben.
2. Der Roboter sollte mit zwei Harpunen im Boden verankert werden, auch hier hat keine ausgelöst.

1. und 2. waren rein mechanische Systeme.

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

Grundsätzlich geht es mir gleich, ich bin jetzt auch schon seit 1976 in der Entwicklung von µC-System tätig.

Was sich seit damals grundlegend geändert hat ist, dass heute noch mehr zwischen Soft- und Hardware getrennt wird und die meisten Programmierer keine Ahnung von Hardware und Assembler haben.
OK, das gab es damals schon bei den Grossrechnern, da wurde zwischen System- und Anwendungsprogrammierern unterschieden. Für Anwendungsprogrammierer bestand die unterste Ebene aus dem API des Betriebssystems. Bei kleineren System bestand das API aus BASIC mit ein paar zusätzlichen Befehlen um Terminal, Drucker und Plattenlaufwerk anzusteuern.
Die Systemprogrammierer waren dann hauptsächlich in Assembler unterwegs, mussten Driver für die Hardware schreiben und anpassen und waren damit beschäftigt das System zu optimieren.

Ein anderer Punkt ist, dass die damalige Hardware grundsätzlich etwas weniger zuverlässig war. Schon die Lesefehler-Raten, vor allem von dynamischem RAM, waren wesentlich höher. Mit der Technik aus den 70er Jahren wäre schon rein deshalb ein Speicher mit 1GB nicht realisierbar gewesen, da hätte man im Betrieb etwa jede Sekunde mit einem Lesefehler rechnen müssen.

Auch hatte man die Halbleiterfertigung noch nicht so im Griff wie heute, in den 70er Jahren lag die Strukturgrösse noch um 1µm.

Wir hatten 1976 eine Lieferung von 6502-CPUs aus einer der ersten Produktions-Chargen. Von 100 Geräten funktionierten eigentlich alle. Wenn beim Kunden die Raumtemperatur aber unter 20°C lag, führte die CPU intern den Reset nicht richtig aus. Eine thermische Nachbehandlung der CPUs (Backen der Chips bei etwa 130°C über 10h, die maximale Lagertemperatur lag, laut Datenblatt, bei 175°C) löste dann das Problem. Von den 100 CPUs waren dann 2 defekt und der Rest funktionierte perfekt. Aus Kostengründen wurde ein abgleichbarer RC-Oszillator verwendet und kein Quarz. Nach dem Backen standen dann alle Trimm-Kondensatoren in der selben Stellung (Damals war ein guter Trimm-Kondensator billiger als ein Quarz, heute ist das umgekehrt!).
Später hat uns dann MOS bestätigt, dass die ersten Chargen ungetestet ausgeliefert wurden und das nachbacken empfohlen ...

Auch machte das BIOs des IMP-PCs nach einem Reset eine Menge Selbsttests. Unter anderem gab es auch eine Reihe Tests, welche z.B. die internen Register des 8088 getestet haben, man hat damals immer damit gerechnet, dass auch die CPU selbst einen Fehler haben kann!

MfG Peter(TOO)

- - - Aktualisiert - - -

also echt, dass die bei der ESA 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...

Heute können doch schon die Kids ihre Legos programmieren, was braucht es da Fachwissen ??

Ein erfahrener Programmierer will doch nur mehr Lohn!