- fchao-Sinus-Wechselrichter AliExpress         
Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 28

Thema: Exomars: Sensorfehler führte zum Absturz von Schiaparelli

  1. #1
    Elektronik & Technik Infos Robotik Visionär Avatar von Roboternetz-News
    Registriert seit
    28.02.2011
    Ort
    Roboternetz Server 3
    Beiträge
    8.991

    Beitrag Exomars: Sensorfehler führte zum Absturz von Schiaparelli

    Anzeige

    LiFePo4 Akku selber bauen - Video
    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

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von i_make_it
    Registriert seit
    29.07.2008
    Ort
    Raum DA
    Alter
    56
    Beiträge
    2.814
    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.

  3. #3
    Man in the moon
    Gast
    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.

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von i_make_it
    Registriert seit
    29.07.2008
    Ort
    Raum DA
    Alter
    56
    Beiträge
    2.814
    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.
    Geändert von i_make_it (25.11.2016 um 08:26 Uhr)

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    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.
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von i_make_it
    Registriert seit
    29.07.2008
    Ort
    Raum DA
    Alter
    56
    Beiträge
    2.814
    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".
    Geändert von i_make_it (25.11.2016 um 11:03 Uhr)

  7. #7
    Unregistriert
    Gast
    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 ?

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    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
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von i_make_it
    Registriert seit
    29.07.2008
    Ort
    Raum DA
    Alter
    56
    Beiträge
    2.814
    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.
    Geändert von i_make_it (25.11.2016 um 15:18 Uhr)

  10. #10
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.688
    .. 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.
    Ciao sagt der JoeamBerg

Seite 1 von 3 123 LetzteLetzte

Ähnliche Themen

  1. Absturz bei seriellem Empfang
    Von TobiasBlome im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 24
    Letzter Beitrag: 27.10.2010, 18:09
  2. RS-232 verursacht absturz...
    Von Silence07 im Forum C - Programmierung (GCC u.a.)
    Antworten: 3
    Letzter Beitrag: 24.09.2007, 10:37
  3. mutmaßlicher absturz nach _delay_ms
    Von Stein im Forum C - Programmierung (GCC u.a.)
    Antworten: 5
    Letzter Beitrag: 26.05.2007, 11:54
  4. PIC absturz
    Von *Mario* im Forum PIC Controller
    Antworten: 11
    Letzter Beitrag: 28.03.2006, 23:49
  5. RESET bzw. Absturz bei Tastendruck ???
    Von dl1akp im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 4
    Letzter Beitrag: 31.03.2005, 09:54

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test