Starliner CST-100 Orbital Flight Test auf Atlas V N22 in CC-LC41

Zitat von: Kelvin am 20. Dezember 2019, 23:44:38

Eine desorientierte Steuerungssoftware, die nicht einmal ihre Desorientierung erkennt

Also wenn eine desorientierte Steuerungssoftware dazu führt, dass Sie Ihre Lage im Raum besonders präzise halten möchte, dann ist das doch nicht gefährlich.

Eine Steuerungssoftware, die von total falschen Voraussetzungen ausgeht, ist schon gefährlich. Unberechenbar.

Die Software hatte doch angeblich die geplante Beschleunigung auf Orbitalgeschwindigkeit mit gleichzeitiger Anpassung der Bahn an die ISS einfach übersprungen. (Wenn ich das richtig mitbekommen habe.) Das bedeutet für mich, daß sie die beiden grundlegend unterschiedlichen Flugzustände auf Grund der Eingangsdaten nicht auseinanderhalten konnte. Daß z.B. die Laufzeit des Antriebes nicht gemessen und überprüft wurde. Daß die verstrichene Zeit seit der Trennung von der 2.Stufe nicht gemessen oder überwacht wurde. Daß keine Rückkopplung zwischen Befehl und Ergebnis bestand oder funktioniert hat. Sonst könnte die Steuerung doch unmöglich die nicht erfolgte Bahnanhebung ignorieren!

Ich bin sehr gespannt, was dabei rauskommt. Und weil mir dieses Verhalten so absurd vorkommt, tippe ich darauf, daß da irgendwelche für den Testbetrieb vorgesehenen Schalter nicht zurückgesetzt wurden. Das praktisch von Anfang an nur der spätere Annäherungsmodus aktiv war und nicht die komplette Startsequenz.

Eine andere Möglichkeit ist vielleicht noch, daß das Programm bei der Auslösung der Bahnanhebung steckengeblieben ist, weil eben aus irgendwelchen Gründen keine Anhebung erfolgte. Und daß also die Meldungen, daß die Anhebungssequenz "übersprungen" wurde, so nicht stimmen.

Schönen Gruß, Kelvin

Das ist aber kein Erkenntnisgewinn. Es schlummern in komplexer Software immer unerkannte Fehler, egal ob nun einer auftritt oder nicht. Deine Schlussfolgerung wegen eines erkannten Fehlers die Kiste wegen möglicher anderer Fehler nicht in die Nähe der ISS zu lassen, zumindest hattest Du genau das geschrieben, teile ich nicht.

Informatiker wissen: Es gibt keine fehlerfreie Software. Wenn man danach geht, sollten man bei Eseln und Pferden bleiben.

Wir wissen noch nicht genau, was falsch gelaufen ist. Eigentlich sind Timer sehr zuverlässig. Bei der Galileo-Atmosphärensonde und auch bei Huygens wurden die Sonden vor der Landung von Timern aufgeweckt. Der Timer der Galileo-Kapsel lief fast 5 Monate.

Informatiker wissen: Es gibt keine fehlerfreie Software. Wenn man danach geht, sollten man bei Eseln und Pferden bleiben.

Natürlich gibt es fehlerfreie Software, erst recht in definierten Szenarios. Und das mit dem Timer kann man nicht wortwörtlich nehmen das ist natürlich Marketing Gewäsch.

Verstehe auch die Diskussion nur bedingt. Es gab ein Problem und die Mission wurde nicht komplett durchgeführt.

Im Grunde kein Beinbruch dafür sind Tests ja da. Logisch wäre es man behebt das Problem und macht einen weiteren Test. Das man da offiziell auf die Crew verweist ist arg skurril denn deren eingreifen ist ja maximal ein Backup.

Wenn der Autopilot eines Fahrzeug aussetzt würde man den ja auch nicht mit den Hinweis releasen, das der Fahrer ja selbst hätte fahren können.

Vor allem scheint es mir der sonstigen Vorgehensweise der NASA zu widersprechen, vor bemannten Missionen wesentlich mehr Perfektion zu verlangen als minimal nötig.

Verstehe auch die Diskussion nur bedingt. Es gab ein Problem und die Mission wurde nicht komplett durchgeführt.

Im Grunde kein Beinbruch dafür sind Tests ja da. Logisch wäre es man behebt das Problem und macht einen weiteren Test. Das man da offiziell auf die Crew verweist ist arg skurril denn deren eingreifen ist ja maximal ein Backup.

...................

Vor allem scheint es mir der sonstigen Vorgehensweise der NASA zu widersprechen, vor bemannten Missionen wesentlich mehr Perfektion zu verlangen als minimal nötig.

Dem stimme ich vollständig zu. Der Fehler an sich ist nicht dramatisch. So etwas darf eigentlich nicht passieren, es passiert aber.

Aber ich lege mich mal fest. Boeing wird einen schönen Bericht schreiben, daß sie den Fehler eingegrenzt haben und daß es nie wieder passieren kann, die NASA wird ihn abstempeln und schon sind sie bereit, die bemannte Mission zu fliegen. Verzögerung 2 Monate vielleicht.

Neben politischem Druck wird da die Überlegung eine Rolle spielen, daß eine Wiederholung des Tests das Boeing Programm um ca. ein Jahr verzögern wird. Sie haben weder die Hardware für eine neue Kapsel noch eine Atlas mit dual RL-10, wenn sie die für Crew vorgesehene Kapsel für einen unbemannten zweiten Test verwenden.

Wenn der Autopilot eines Fahrzeug aussetzt würde man den ja auch nicht mit den Hinweis releasen, das der Fahrer ja selbst hätte fahren können.

Da muß ich allerdings widersprechen. Genauso läuft es mit der Tesla Autopilot Software. Die ist noch längst nicht soweit, daß man sie alleine fahren lassen könnte. Aber die Kombination Fahrer plus Autopilot ist statistisch wesentlich sicherer als Fahrer alleine.

Startfoto von John Kraus: 


https://twitter.com/johnkrausphotos/status/1208064468405624840

Man sieht sehr schön das RD-180 Triebwerk der Russen

Zitat von: Duncan Idaho am 20. Dezember 2019, 19:55:51

Startfoto von John Kraus: 


https://twitter.com/johnkrausphotos/status/1208064468405624840

Man sieht sehr schön das RD-180 Triebwerk der Russen

Dazu habe ich mal eine dumme Frage: Kauft die ULA diese Antriebe für jeden Start direkt bei den Russen - und ist so von ihnen immer noch abhängig - oder haben sie eine Gebühr/Lizenz bezahlt und bauen dieses Triebwerk selbst nach, wenn sie dies brauchen? Oder beziehen sie diese gar von der Ukraine?

Habe dazu nichts aussagekräftiges gefunden...

Aus dem Video von Scott Manley höre ich heraus, dass wohl auf der PK es so erklärt wurde, dass Starliner nach dem Timing/Timer-Fehler glaubte habe bereits im Insertion-Burn zu sein und deshalb versuchte mit den kleinen RCS-Düsen die Ausrichtung möglichst exakt zu halten.
Im Video sieht man auch noch einmal eine kleine Sequenz der Animation im Control Center, bei der die Düsen wirklich sehr wild feuern.
Auch wenn es nur die kleinen RCS-Düsen waren und nicht die größeren, die eigentlich für den Insertion Burn gedacht sind, wurde dabei angeblich 25% des Treibstoffvorrats verbraucht.
Dadurch seien (zumindest bei diesem Testflug) die Reserven für einen Anflug zur ISS zu gering.

Letztlich bestätigt das aber eine meiner größten Bedenken, Starliner hat selbst nicht erkannt, dass etwas nicht stimmt.
Ich finde trotz allem (es ist ein Testflug) es ist kein gutes Zeichen, wenn offensichtlich nicht genug Kontrollfunktionen vorhanden sind, um eine gravierende Abweichung vom Flugplan zu erkennen.

Viele Grüße
Rücksturz

@Klaus: RD-180 Triebwerke kommen direkt von Energomash aus Russland.

Neue Daten:

Apogäum: 265,25 km
Perigäum: 241,41 km

Auch wenn bereits die Ankündigung kam, daß man abbricht: In diesem Orbit könnte Starliner auch länger bleiben.

Start der Atlas V mit CST-100 Starliner
Orbital Flight Test - unbemannt zur ISS
Beim Start traten mehrere kleine Fehler auf,
weshalb die Raumstation nicht erreicht werden konnte.

Richard Angle hat den Start vom Dach des VAB gesehen:
Credit: Teslarati - Richard Angle
https://www.teslarati.com/boeing-astronaut-capsule-flies-off-course-launch-debut/ 

Im Bild sind von links nach rechts die Startrampen LC-39B, LC-39A, SLC-41 und SLC-40 zu sehen.

@Klaus: RD-180 Triebwerke kommen direkt von Energomash aus Russland.

Fast.
Den Vertrag mit Energomash hat Pratt&Whitney, die heute zu Aerospace-Rocketdyne gehören. Sie liefern die Triebwerke an ULA.
Der Vertrag läuft über 100 Triebwerke für insgesamt 1 Mrd Dollar, also 10 Mio pro Triebwerk. Inzwischen wird Energomash dafür stark in Russland kritisiert, da die Triebwerke zu billig verkauft würden.

Es sind schon 116 Triebwerke RD-180 in die USA geliefert.

Nabelschnüre und alles was man sonst noch so braucht.
Tom McCool, hochaufgelöst, drauf klicken!:
https://twitter.com/Cygnusx112/status/1207753184262922241







Aerodynamisch is ja das ganze nicht wirklich ein Highlight aber bei Raketen drück ich da mal ein zu.

Das mit den falsch gehenden Timer könnte man so erklären:
Eins dieser zahlreichen Kabel dient als Auslöser für den Timer. Und dummerweise wurde dieses Kabel zu früh vom Träger oder der Nutzlast getrennt und damit begann der Timer zu laufen.

Als Beispiel das dies schon mal vorgekommen ist:
Im Dezember 1965 versuchte die NASA Gemini 6 zu starten, die Triebwerk wurden gezündet, ein schlecht befestigtes Kabel löste sich vom Träger und der Timer begann zu laufen, bereits vor den Abheben. Der Start wurde damals abgebrochen.   https://de.wikipedia.org/wiki/Gemini_6

Glaubst du wirklich das heute noch so primitiv arbeiten ?

Ulli

Es kommt auch heute noch durch Kleinigkeiten zu Fehlern, über die man im Nachhinein nur den Kopf schütteln kann. Siehe das Problem beim Ariane 5 Start im Januar 2018, als die Nutzlasten ihre Umlaufbahn verfehlten, weil jemand einen Fehler bei der Flugbahn-Programmierung des Trägers gemacht hat. Auch damals hat man das Problem zu spät erkannt, weswegen das FTS nicht ausgelöst wurde. Der Träger war nicht auf Kurs und passierte die Stadt Kourou viel zu nah. Aber als man das erkannte, war es zum Sprengen des Trägers bereits zu spät. Die Trümmer der abstürzenden Rakete waren ein viel größeres Risiko als eine Fortsetzung des Fluges.

Vermutlich hat auch beim Starliner irgendjemand einen Fehler gemacht, durch den der Timer nicht mehr stimmte.

Guten Tag

Also ganz ehrlich.
Ich verstehe die Sache mit den Timern überhaupt nicht.
Timer braucht man nur für die Zeiten in denen keine anderen Ereignisse auftreten.
Aber außerhalb dieser Zeiten werden, insbesondere dann, wenn es sich um sequentiell abzuarbeitende Prozesse handelt, diese wohl über den Abschluß der vorhergehenden Sequenz gestartet. Da dazwischen kann sich dann von mir aus eine Zeitphase befinden die nur abgewartet werden muß, in der sich sonst nichts tut. Und selbst in der könnte, über mögliche Eingangsdaten, ermittelt werden, "wo" man sich befindet, und ob dies alles plausibel ist. Timer stellen eine Zeitbasis zur Verfügung oder wecken z.B. aus einer langen Ruhephase auf; dies ist hier nichtgegeben; hier, bei einem Start mit vielen sich änderndern Paramentern kann und muß die Steuerung/Regelung permanent aktiv sein.
Für mich ist dies ein ganz grober Schnitzer der Steuerungssoftware. Man muß nicht alles beschönigen.

Schönen Abend, James

Das wird das "Landeprofil" für White Sands.

https://twitter.com/Marco_Langbroek/status/1208400988828307457

Die Kapsel scheint den Orbit stabilisiert zu haben. (265 x 241 km)

@James, ich hätte es nicht besser beschreiben können.

PS: Danke für die Verlinkung vom Scott Manleys Video.
Einen Punkt muss ich da noch mal hervorheben.
Minute 2:00.
Bei solch einem Start nur die Kontroller hinter den Monitoren zu zeigen finde ich eine Frechheit.

Jim Bridenstine
‏Verifizierter Account @JimBridenstine
20. Dez.

Update: #Starliner had a Mission Elapsed Time (MET) anomaly causing the spacecraft to believe that it was in an orbital insertion burn, when it was not. More information at 9am ET:

https://twitter.com/JimBridenstine

Die NASA hat für ihre Raumfahrtprojekte eine einige Zeitform: Mission Elapsed Time (MET)
Die Flugpläne, wenn sie nicht von anderen Parameter abhängig sind, werden für MET geschrieben und ausgeführt. Diese Zeitangabe beginnt mit den Start bei Null.
https://de.wikipedia.org/wiki/Mission_Elapsed_Time

Ein Problem mit dem Timer muss nicht bedeute, daß eine Uhr falsch oder zu früh los ging. Es kann auch sein, daß einfach nur eine Mission-Phase gedacht hat, sie wäre fertig und jetzt war die Mission-Phase falsch.

Guten Tag

Also ganz ehrlich.
Ich verstehe die Sache mit den Timern überhaupt nicht.
Timer braucht man nur für die Zeiten in denen keine anderen Ereignisse auftreten.
Aber außerhalb dieser Zeiten werden, insbesondere dann, wenn es sich um sequentiell abzuarbeitende Prozesse handelt, diese wohl über den Abschluß der vorhergehenden Sequenz gestartet. Da dazwischen kann sich dann von mir aus eine Zeitphase befinden die nur abgewartet werden muß, in der sich sonst nichts tut. Und selbst in der könnte, über mögliche Eingangsdaten, ermittelt werden, "wo" man sich befindet, und ob dies alles plausibel ist. Timer stellen eine Zeitbasis zur Verfügung oder wecken z.B. aus einer langen Ruhephase auf; dies ist hier nichtgegeben; hier, bei einem Start mit vielen sich änderndern Paramentern kann und muß die Steuerung/Regelung permanent aktiv sein.
Für mich ist dies ein ganz grober Schnitzer der Steuerungssoftware. Man muß nicht alles beschönigen.

Schönen Abend, James

Timer kann auch mit "Zeitgeber" übersetzt werden, der die Missionszeit vorhält. Ich gehe auch nicht davon aus, dass die mit Timern arbeiten, die nach dem Start einer Aktion gestartet werden und dann die nächste Aktion auslösen, sondern vermute dass es eine zentrale Uhr (plus Redundanz) gibt, welche entweder die Zeit an alle Komponenten weiterverteilt (die Komponenten hätten dann eigene Uhren, die für die eigentliche Ereignissauslösung zuständig sind) oder das die zentrale Uhr auch schon die Kommandos in den Komponenten auslöst. Komponenten müssen dabei nicht Hardwarekomponenten sein, sondern können wiederrum auch eigene Softwarekomponenten sein. Zumindest würde ich als Informatiker eine der beiden Lösungen nehmen - haben beide Vor- und Nachteile.

Kann mir jemand bitte genau sagen die Maße der Atlas V Rakete sowie vom Starliner? ( Länge,Höhe, Durchmesser usw) .vielen Dank!

Landung von Starliner am morgigen Sonntag während des 33.Erdumlaufs.

https://twitter.com/NASASpaceflight/status/1208468578632163329

Zündung der Bremsraketen soll um 6:23 CT (13:23 MEZ) erfolgen, Landung dann rund 20-30 min später. NASA-TV überträgt live

Hoffentlich nicht nur wieder mit Bildern aus dem Kontrollzentrum.....

Gruß
roger50

sondern vermute dass es eine zentrale Uhr (plus Redundanz) gibt, welche entweder die Zeit an alle Komponenten weiterverteilt (die Komponenten hätten dann eigene Uhren, die für die eigentliche Ereignissauslösung zuständig sind) oder das die zentrale Uhr auch schon die Kommandos in den Komponenten auslöst. Komponenten müssen dabei nicht Hardwarekomponenten sein, sondern können wiederrum auch eigene Softwarekomponenten sein.

Völlig einverstanden. Nur muß es natürlich auch eine (wie auch immer realisierte) Rückkopplung geben. Es kann ja Unterprozesse geben, bei denen die korrekte Erledigung der vorangegangenen Aufgabe wichtiger ist, als ein vorausberechneter Zeitpunkt. Entweder muß die "Hauptinstanz" (die mit der "Hauptuhr") die Prüfungen erledigen, oder es müssen die jeweiligen Unterprozesse machen und die Hauptinstanz informieren. (Kombinationen sind sicher auch denkbar.)

Es gibt ja gerade für diesen Vorgang eine Menge messbarer und am Ort verfügbaren "Merkmale", die alle zur Rückkopplung verwendet werden können. (Zeit zwischen Start und Stop, Beschleunigung, Durchflußsensoren, Füllstandssensoren... Sogar Temperaturensensoren an den Triebwerken könnten Auskunft geben.) Und diese Rückkopplung ist einfach nicht erfolgt. (Wenn denn "übersprungen" gilt.)

Noch zu der diskutierten Fehleranfälligkeit. Fehleranfällig sind insbesondere Prozesse, die direkt mit irgend einer Hardware kommunizieren. Leitungen können sich lösen, Wackelkontakte können entstehen, Sensoren können den eigenen Messbereich verlassen, falsch eingebaut oder angeschlossen sein - alles für die Software sehr unangenehme weil unendlich vielfältige Ereignisse. Viel kritischer als reine Softwarefehler. Das bestimmende "Hauptprogramm" sollte daher aus meiner Sicht keinen direkten Außenkontakt zu solcher Hardware haben. Es muß unter allen Umständen "kühlen Kopf" behalten und sich nicht blockieren lassen. Um bei Bedarf Notfallprozeduren zu starten oder sogar die eigene Ausführung zu stoppen. Und genau diese "kühle Kopf" war vielleicht nicht vorhanden.

Daher ist es aus meiner Sicht nicht einfach nur ein immer möglicher kleiner Fehler in einer untergeordneten Prozedur.  Boeing und Software scheint neuerdings nicht ganz zusammnzupassen.

Kann mir jemand bitte genau sagen die Maße der Atlas V Rakete sowie vom Starliner? ( Länge,Höhe, Durchmesser usw) .vielen Dank!

Atlas V 58,3 Meter Höhe, 3,81 Meter Durchmesser

Starliner 5,03 Meter Höhe, 4,56 Meter Durchmesser