Exomars: Sensorfehler führte zum Absturz von Schiaparelli

Bild hier   Falsche Daten, falsche Höhenberechnung: Weil das Navigationssystem von Schiaparelli glaubte, der Lander sei bereits auf dem Boden, wurde der Fallschirm zu früh abgetrennt, und der Exomars-Lander schlug mit hoher Geschwindigkeit auf dem Mars auf. (Exomars, ESA) Bild hier  

Weiterlesen...

Sag deine Meinung zu der Meldung und diskutiere im Roboternetz.

News Quelle: Golem
Diese Nachricht wurde automatisiert vom Roboternetz-Bot gepostet. Verantwortlich für den Inhalt ist daher allein der Herausgeber, nicht das Roboternetz.de oder deren Verantwortliche.


Anzeige

Aua, aua, aua.
Seit den Mondlandungen weis die Nasa, das ein paar simple Stabsensoren von 1,7 Meter Länge zuverlässig funktionieren.
Da wurde mal wieder ein teuere Schnick schnack gebaut der wenn er funktioniert ja schön ist, aber kein redundantes System (Jedes Verkehrsflugzeug muß seine Sensoren dreifach haben)
und kein 2$ teuren Federstahlstab der einen 1$ Schalter auslöst und das auch nur wenn da wirklich Boden ist.

Ahh, ein ganz Schlauer. Hättest den Marslander bestimmt allein in deiner Garage gebaut. Und vergleichst Äpfel mit Birnen. Bei der Mondlandung waren übrigens Piloten mit an Bord, und Flugzeuge haben zusätzlich noch etliche Passagiere. Dein Übergepäck beim Fliegen kostet auch nicht etliche Millionen €€€ pro Kilo, denn sonst würdest du selbst die Unterwäsche zu Hause lassen.

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.

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.

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

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 ?

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

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.

Zitat:

---

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

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.

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

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

Zitat:

---

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

Zitat:

---

Zitat von Michael

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.

Hallo Michael,

Zitat:

---

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

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 ;)

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

Zitat:

---

Zitat von White_Fox

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.

Zitat:

---

Zitat von White_Fox

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

Zitat:

---

Zitat von Unregistriert

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!

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

Zitat:

---

Zitat von Unregistriert

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

---

Ich würde mich auch als Gast verstecken, wenn ich keine Ahnung hätte:

Java: git es seit 1995
Python: 1991
OSEK: 1994
Linux: 1992

Bring mal etwas, was wenigsten aus den 70er Jahren stammt, darf auch Ende der 70er sein!

Noch ein Tipp: Ich bin älter als BASIC.

Nächstes Mal sollten die einfach die Entwicklung der Software hier ins Forum auslagern. Die Schlauberger hier werden natürlich 100% fehlerfreie Software abliefern und den Amateuren mal so richtig zeigen wie programmiert wird.

jup, und zwar in Assembler oder Algol oder Fortran, wenn sie da schon geboren waren :D

Das ist das schöne daran, man muß nicht damals geboren worden sein, man kann es auch später noch lernen.
ich habe auch erst 1991 das erste mal in COBOL programmiert und 1992 in APL2.
Beides stammt von vor meiner Geburt.
Man muß es halt lernen, verstehen und beherschen, dann kann man damit auch fehlerarme bis fehlerfreie Progamme schreiben.
Wobei es hier ja gar nicht um fehlerfreie Programme geht sondern wie man durch Beachtung grundlegender Softwaredesign Regeln eben Fehler soweit minimiert und kapselt, das sie keine negativen Auswirkungen haben.

Bei meinem Messgeräte Projekt, habe ich einen Dr. der Informatik als Produktmanager, muß aber erst mal erklären, warum ich viele Rechnungen so aufteile, das möglichst viel mit Division durch 2 hoch n läuft.
Heute wird in den Unnis halt von PCs mit Multicore GHz CPUs ausgegangen, Das man insgesammt nur 2K für Variablen hat und ein Singlecore mit 16MHz möglichst stromsparend in so einem mobilen Messgerät mit Datenlogger werkeln soll, da bekomme ich ständig gesagt "so tief stecke ich da nicht drin".
Ich muß dann erst mal erklären, das vier Aditionen und zwei einfache Shift right sowie dann noch zweimal je eine Adition plus Shift Right halt schneller ist als 6 Werte zu adieren und anschließend eine Division durch 6 auszuführen.

Scheint so das auf vielen Unis keine Grundlagen mehr vermittelt werden.
So Absolventen kommen dann halt auch zu ESA Forschungsprojekten und sollen da natürlich möglichst frisch von der Uni sein damit sie auf dem neusten Stand sind.
Wenn das Basiswissen aber nicht vermittelt wurde und keinerlei Erfahrung vorhanden ist, kostet das halt richtig Kohle wenn mit dem Crash eines Marslanders rauskommt "so klappt es nicht".
Das dann das Testing genauso wie das Qualitätsmanagement versagt, schließt das ganze dann ab.

Eigentlich kenne ich diese Form von Trollerei und pseudointelligente Sprüche wie von Man in the moon und dem Unregistrierten (wenn das sogar mal nicht diesselben sind) nur aus einem einzigen Forum...ist nix los im mikrocontroller.net?

Wird Zeit das morgen wieder die Arbeit anfängt...

Edit:

Zitat:

---

Zitat von i_make_it

Wobei es hier ja gar nicht um fehlerfreie Programme geht sondern wie man durch Beachtung grundlegender Softwaredesign Regeln eben Fehler soweit minimiert und kapselt, das sie keine negativen Auswirkungen haben.

---

Verlang nicht zu viel von diesen Leuten. Jemand der so redet hat noch nie den Vorteil einer strukturierten Arbeitsweise verstanden. Diesselben Leute würden auch eine Platine routen ohne sich vorher einen Schaltplan zu machen, fangen an wild draufloszuprogrammieren ohne vorher wenigstens ein grundlegenes Struktogramm zu entwerfen und evt. Schwachstellen schon vorher zu finden (Code kommentieren dauert nur unnötig und ist langweilig, und wozu zum Geier soll man denn noch eine Klasse selber programmieren?) und sehen einen Test ls erfolgreich an, wenn das Gerät beim Einschalten eine Power-On-LED leuchten läßt.

Kurz: Der Unterschied zwischen Ingenieurskunst und Bastelei.

Ätzend finde ich solche Menschen nur, wenn ich mit ihnen arbeiten muß. Ich arbeite gern mit einer fachlich vollkommen inkompetenten Person zusammen, wenn nur Lernwille und die Fähigkeit zum selbständigen Denken vorhanden sind. Die kann man wenigstens mit Erklärungen und Wissenweitergabe geradeziehen und hat irgendwann mal möglicherweise einen fähigen Kollegen. Gegen fachliche Naivität, gepaart mit Dummheit und Ignoranz, ist mir leider kein Kraut bekannt.

Vieleicht hat es ja auch was positives.
Zum Trollen werden die Posts ja gelesen.
Wenn die statistischen 10% der Informationen beim Lesen hängen bleiben, werden die Trolle durchs lesen hier ja schlauer.

Wenn die statistischen 10% stets hängen bleiben würden, wäre in den letzten Posts schon vorher mehr als nur die Aufzählung von ein paar Programmiersprachen herumgekommen.

Und was das Lesen von Threads, gepaart mit Dummheit und Ignoranz, macht, konnte wir erst kürzlich im Langlebige-Elkos-Thread sehen.

Zitat:

---

Zitat von White_Fox

Gegen fachliche Naivität, gepaart mit Dummheit und Ignoranz, ist mir leider kein Kraut bekannt.

---

Bei uns in der Firma heist das Kraut Kündigung.
Ich bin jetzt knapp 8 Monate da und etwa ein Drittel der Neuzugänge schafft die Probezeit nicht.
Erst kommt, eine Woche Selbststudium für einen Kunden oder ein Projekt, dann 2-3 Monate Einsatz im Team und dann die erste Einzelaufgabe. Da entscheidet es sich dann.