was mich aber noch mehr schockiert ist, daß das "Hauptsystem" unbeeindruckt weiter mit den zuletzt gemeldeten Werten des offensichtlich funktionslosen Untersystems rechnet und diese vermutlich noch falsch extrapoliert.
Hm. Das mit dem "Weiterrechnen" und "Extrapolieren" war ja in der Schnittstelle zwischen den beiden Systemen offensichtlich so verabredet und berücksichtigt.
Ferner war offensichtlich verabredet, dass das "Sättigungsflag" für maximal 15 ms anliegen sollte. An diese Verabredung hat sich die IMU aber wie gesagt nicht gehalten und das war laut Bericht die Hauptursache des Absturzes. Ich habe mittlerweile in einem älteren Link die Information gefunden, dass die IMU mit einer "persistence time" von 1 Sekunde, also 1000 ms operierte:
http://www.asi.it/en/news/schiaparelli-imu-saturation .
Für mich ist die interessante Frage, warum sich selbst nach dieser langen Sekunde das GNC-System nicht einfach wieder "berappeln" kann, wenn die IMU doch nun wieder nominale Daten liefern müsste, zumal die heftigen Pendelbewegungen nun abgeklungen sein sollen
. Aber das zu beurteilen, dafür fehlen uns wohl Informationen über die Systeme und die Funktionsweise einer IMU bzw. GNC allgemein.
Anderswo habe ich gelesen, dass Systeme auf IMU-Basis Lageinformationen ermitteln, indem sie aus Daten von Beschleunigungssensoren auf die bewegte Strecke rückschließen (vereinfacht: "Ich erfahre gerade eine Beschleunigung a, also werde ich in der Zeit delta t um den Weg delta s bewegt") und diese Deltas fortlaufend aufaddieren. Das geht so lange gut, wie die auftretenden Beschleunigungen unter dem Grenzwert des Sensors liegen. Nach einer zu großen Beschleunigung müssten aber von da an die Lagedaten mit einer gewissen Unsicherheit behaftet sein, da ja das "delta a" über dem Grenzwert von nun an in der Kalkulation fehlt.
Die Frage ist dann, ob es ein rein relatives System ist oder ob es sich zumindest ab und zu mal an einem Absolutwert neu ausrichten kann...
Wenn es keinen Absolutwert gibt, kommt vielleicht jetzt die "persistence time" ins Spiel. 15 Millisekunden ist ja nicht so viel, und
wenn nach den 15 ms wieder nominale Beschleunigungsverhältnisse herrschen, ist die Lageabweichung der IMU vielleicht nicht so groß. Lass' es auch mehrmals 15 ms sein, ist bestimmt immer noch beherrschbar. 1000 Millisekunden sind aber schon ein ganz anderes Kaliber... immer vorausgesetzt, es gibt keinen Absolutwert, an dem man sich resetten kann.
Und anschleißend ein neu hinzukommendes anderes, unabhängiges Untersystem (Bodenradar) "für fehlerhaft erklärt" und abschaltet, weil seine Daten nicht in die "fantasierte Weltsicht" des Hauptsystems (negative Höhe über Grund) passt.
Jep, das wird auch in dem Bericht erwähnt: Das GNC-System war offensichtlich so programmiert, dass es eher mit einem Radar-Versagen als mit einem IMU-Versagen gerechnet hat. Deswegen wurde wegen der Inkonsistenz zwischen IMU und Radar ausgerechnet das korrekt funktionierende System ignoriert.
Die Annahmen des Hauptsystems konnten nicht richtig sein. Ich sehe dort das Hauptproblem.
Beim GNC identifiziert der Bericht eine Fehlerursache insofern, als es keine Plausibilitätskontrolle wegen der negativen Höhe enthielt. Wäre das nicht gewesen, hätte vielleicht noch das Radar die IMU überstimmen können... naja, man weiß es nicht.
Es werden auch noch weitere Fehlerquellen identifiziert, so etwa, dass man sich die Entfaltung des Fallschirms bei der ESA aerodynamisch zu einfach vorgestellt hat, während die NASA da schon mehr Erfahrung hat (Rob Manning von der MER- und MSL-Mission war Mitglied des SIB
), sowie zuwenig Fehlertoleranz in der Software. Aber als Grundursache
in diesem konkreten Fall wird eben diese "persistence time" benannt.
