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

 

Hier gehts ja gerade ganz schön durcheinander. Ich glaub ich komm dann morgen wieder, wenn sich die Wogen geglättet haben..

Liebe Raumfahrtfreunde.
Ich möchte mich bei allen bedanken. War sehr interessant, Euch hier seit dem Nachmittag (Start) zu lesen und Kommentar seitig dabei zu sein.
Keine Missverständnisse: Das meine ich ehrlich. 

Ich finde, es wird jetzt auf einem anderen Themengebiet interessant. Nachdem die Amerikaner ja bei den Russen schon die Sitze gekündigt hatten, ist man wieder einmal offensichtlich auf die olle Sojus angewiesen.
http://www.gerhardkowalski.com/?p=18956
Damit werden Besatzungen und Flugpläne neu gemischt... . Bis hin zu solchen Projekten wie "Die Astronautin".

Unsere (Raumfahrt-)Praxis entwickelt sich so rasant, dass mancher theoretisch gar nicht mehr mit kommt... .   

... ist aber ein anderer Themenbereich.

Folgend der Orbit von ca. 20 Uhr MEZ (Rohdaten von 16 Uhr MEZ) grafisch:

Die Bahn deckt sich mit der ISS-Bahn, die Rakete ist also in die richtige Richtung geflogen.



Zahlen von 16 Uhr MEZ:
Epoche:                   20.12.2019 14:52:50 UTC (20.12.2019 15:52:50 MEZ)
Inklination:              51,59°
Umlaufzeit:               5311,36s
Apogäum:                  220,78km
Perigäum:                 182,04km

Von der Seite betrachtet sieht man den Unterschied der Bahnhöhen:

Nachdem die Amerikaner ja bei den Russen schon die Sitze gekündigt hatten, ist man wieder einmal offensichtlich auf die olle Sojus angewiesen.

Redundanz auch auf Internationaler Ebene ist doch toll. So kann man in Ruhe die Probleme beheben. Und ob man nun nochmal 2-3 Plätze einkauft oder nicht finde ich kaum erwähnenswert. Klingt in Deinem Statement ja fast schon als wäre es eine Blamage für die Amis auf die Zitat "olle Sojus" angewiesen zu sein. Das finde ich nicht.

Viele Grüße,

Klaus

Bei SpaceX hat das problemlos geklappt.

Und bei Boeing hat die Druckbeaufschlagung der Tanks funktioniert. Die mussten dabei nicht die ganze Kapsel sprengen.

Auf was ich dabei eigentlich hinaus wollte: Bei Boeing hat das nicht funktioniert und bei SpaceX etwas anderes. Das ist nun mal Technik im Grenzbereich. Da geht immer mal wieder etwas schief. Erst vor ein paar Jahren sind auch die seit fast 50 Jahren eingesetzten Sojus-Kapseln bei der Landung knapp an einer Katastrophe vorbeigeschrammt. Um solche Probleme zu finden, macht man die Testflüge. Die ersten Unbemannten Flüge von Dragon 2 und Starliner sollten am Anfang tatsächlich nicht zur ISS gehen, das hat man erst später auf Wunsch der Unternehmen geändert, damit sie einen Testflug sparen können.

Zumindest hätte die Crew das Problem heute überlebt. Mit einem Piloten an Bord hätte man den Fehler vielleicht sogar korrigieren können, bevor zu viel Treibstoff verbraucht wird.

Startfoto von John Kraus: 


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

Ich hatte heute leider keine Möglichkeit, den Start zu verfolgen.
Klar, das Ergebnis ist bisher teilweise enttäuschend. Aber man sollte sich auch vor Augen halten: Es war erst mal ein Test.
Die ersten Flüge des Sojus-Raumschiffes (unbemannt und bemannt) waren eine einzige Pannenserie.
Neue Technik muss in der Praxis getestet werden, um Fehler aufzudecken.
Es wird in Ruhe analysiert werden und beim nächsten Flug treten hoffentlich weniger oder keine Fehler mehr auf.
Ob jetzt der bemannte Flug folgt, möchte ich bezweifeln.
Ich würde für das Projekt trotzdem nicht zu schwarz sehen.

Zitat von: F-D-R am 20. Dezember 2019, 19:36:33

Nachdem die Amerikaner ja bei den Russen schon die Sitze gekündigt hatten, ist man wieder einmal offensichtlich auf die olle Sojus angewiesen.

Redundanz auch auf Internationaler Ebene ist doch toll. So kann man in Ruhe die Probleme beheben. Und ob man nun nochmal 2-3 Plätze einkauft oder nicht finde ich kaum erwähnenswert. Klingt in Deinem Statement ja fast schon als wäre es eine Blamage für die Amis auf die Zitat "olle Sojus" angewiesen zu sein. Das finde ich nicht.

Viele Grüße,

Klaus

Ne Klaus.  Schadenfreude ist mir sehr fern hier. Raumfahrt ist, wie wir beide wissen, ein sehr komplziertes Ding... .
Mich macht es blos etwas traurig, das die Amerikaner, wenn sie einen technischen Stand erreicht haben, dann das Ing.-Wissen verbrennen (nach Apollo, nach Shuttle) und dann das "Fahrrad" mit viel Mühe noch einmal erfinden müssen.

Eine Nation, wie die USA hätte eigentlich seit 1961 einen permanenten Zugang zum All haben sollen. Die Kraft und das Wissen hatten sie ja dazu.

Natürlich freue ich mich, wenn die Amerikaner jetzt wieder mit den Russen zusammen (mit-)fliegen werden (müssen). Aber mir wäre es lieber, wenn es kein Zwangsgemeinschaft wäre sondern eine - wie sage ich es am besten? - Zusammenarbeit auf Augenhöhe.

Ja, ja..... Wunschvorstellung von mir. Ich weis. 

"Wie der NASA-Chef Jim Bridenstine inzwischen mitteilte, hatte die Raumkapsel ein Problem mit der Zeitmessung. Deswegen sei eine geplante Triebswerkszündung zum falschen Zeitpunkt durchgeführt worden."

Wenn ich das so lese, dann kommt mir folgendes Möglichkeit in den Sinn:

Die Annäherung an die ISS dürfte vermutlich die komplizierteste Angelegenheit sein, die auch am ausführlichsten getestet werden muß. Also hat man dort, um die Testzeiten zu verkürzen, auch einen "Schnelldurchlauf" mit simulierten Daten. Also einen kleinen Softwareschalter, der die Uhr beschleunigt oder ein "ok" nicht abwartet.  Und wenn man dann bei den letzten Tests nicht aufpasst, weil man das schon tausendmal gemacht hat, und immer im Schnelldurchlauf, dann kann schon mal dieses eine Bit im Echtbetrieb umgelegt bleiben. (Wenn man das nicht z.B. hardwaremäßig absichert.)

Die Entscheidung über einen frühzeitigen Abbruch der Mission mit Landung am Sonntag in White Sands scheint gefallen zu sein, wie Jim Bridenstine vor kurzem twitterte.

https://twitter.com/jimbridenstine/status/1208103439009538055

Gruß
roger50

…
Mich macht es blos etwas traurig, das die Amerikaner, wenn sie einen technischen Stand erreicht haben, dann das Ing.-Wissen verbrennen (nach Apollo, nach Shuttle) und dann das "Fahrrad" mit viel Mühe noch einmal erfinden müssen.
…

@F-D-R
Ich verstehe dich, auch wenn ich deine Meinung aus fachlichen Gründen nicht teile.

Mit dem Verlust der digitalen Unterlagen zur Saturn V usw. wurde ein erheblicher Fortschritt auf dem Gebiet der Speicherung digitaler Unterlagen in Archiven initiiert. Sicherlich ist da noch nicht alles Gold, was glänzt, aber so eine Pleite soll es in den Archiven der Industriestaaten nicht noch einmal geben.

Das hilft natürlich der NASA aktuell nicht weiter, dämpft aber hoffentlich deinen Frust.

Zitat von: Dublone am 20. Dezember 2019, 17:54:46

Ich halte es für einen Schweren Fehler wenn man die Funkverbindung verliert.

Wirfst du dein Handy weg, wenn du mal im Funkloch steckst?

Das ist ein Totschlagargument. Weil z.B. eine Reise von Berlin nach Leipzig nicht im Atlantik endet, wenn man im Funkloch steckt. Und weil die Bewegung irgendwann rausführt. Das weiß man und schleppt daher kein zweites Handy mit.
Eine verlorene Funkverbindung sollte es in der Raumfahrt nur da geben, wo man mit ihr rechnen kann. (Plasma, Sat-übergabe etc) Oder in stabilen Phasen. Hier aber wäre es sicher möglich gewesen, für die Testdauer Redundanz zu schaffen, um Lücken zu überbrücken. Kann man ja später wieder zurückfahren.
Aber jetzt kann man sich nun nicht herausreden. Das hätte organisiert werden können.

Vor allem ist der Flugweg wenn man zur ISS möchte, immer ähnlich. Man könnte somit Bodenstationen bauen. Im Wasser sicher etwas schwieriger, aber eine überdimensionale Funkboje solle vielleicht auch möglich sein.
Speziell jetzt, wo man wieder bemannt fliegt, ist eine durchgängige Funkverbindung sicherlich von Vorteil.

Wir wissen noch nicht, warum die Funkverbindung ausgefallen ist. Lag es am TDRS-Netz oder vielleicht auch am Skyliner? Vielleicht sind die Antennen am Skyliner durch die ungeplanten Manöver so positioniert wurden, das sie die Signale nicht empfangen konnten? Mal sehen, was wir die kommenden Tage noch erfahren. Vermutlich gilt das Prinzip "Kleine Ursache, große Wirkung!"

Nachdem jetzt offenbar ein schnelles Ende des Fluges am Sonntag beschlossen wurde, sinken die Chancen für einen bemannten nächsten Flug. Hier wird man nicht umhin kommen, einen weiteren unbemannten Testflug durchzuführen. Da im nächsten Jahr einige Atlas-5-Nutzlasten mit engen Startfenstern im Kalender stehen, wird ein weiterer Flug nicht einfach. Ob der Starliner 2020 schon bemannt fliegt? Wenn man das Problem schnell lösen kann und einen passenden Starttermin bekommt, vielleicht. Durch den Block-by müssten eigentlich einige Atlas 5 verfügbar sein. Vielleicht kann man eine weniger wichtige Nutzlast etwas nach hinten schieben? Aber die Chancen stehen nicht gut. Schade, ich hätte es Boeing so sehr gewünscht...

 


https://twitter.com/EdPiotrowski/status/1208022045520531462

Hier wird man nicht umhin kommen, einen weiteren unbemannten Testflug durchzuführen.

Abwarten. In der Pressekonferenz hieß es, dass die sicherheitskritischen Meilensteine (Start & Landung) erfolgreich getestet werden können. Das Docking ist vermutlich sogar manuell durchführbar falls die Automatik zickt und das manuelle Verfahren kann ein unbemannter Test sowieso nicht abdecken. Beim Docken wäre also das Risiko für die Astronauten überschaubar wenn die Automatik versagt durch ungenügende Praxistests. Mal abwarten wie die restlichen Daten aussehen, wie die Landung läuft und vor allem, was die eigentliche Ursache des Problems war.

Viele Grüße,

Klaus

Es ist zwar schon (fast) alles gesagt, aber noch nicht von mir... 
Ich fasse nochmal das (für mich) wichtigste zusammen (alles vorläufig und keine endgültigen Weisheiten, wir müssen für eine endgültige Wertung erst die Untersuchungsergebnisse abwarten):

1. Nach allem was ich mitbekommen habe hat die Atlas 5 in dieser modifizierten Version einschließlich Dual-RL-10-Centaur einwandfrei funktioniert. Wenn sich das auch nach Auswertung aller Telemetrie so bestätigt, kann man das definitiv als Erfolg werten (für ULA).
2. Starliner hat sich nicht sofort oder komplett zerlegt, ist imho grundsätzlich flugfähig, wenn auch noch fehlerbehaftet.
3. Es gab ein Timer oder Timingproblem, so dass Starliner "glaubte" den Insertion-Burn bereits gemacht zu haben.
Das ist ein gravierender Fehler und muss auf jeden Fall gründlich untersucht und behoben werden, bevor wieder ein Starliner abhebt (egal ob mit oder ohne Crew).
4. Da Starliner "glaubte" bereits in einer späteren Flugphase zu sein, haben (so scheint es zumindest) die RCS wild gefeuert, um einen bestimmten Zustand zu erreichen oder mit höherer Präzision zu halten.
Dadurch wurde (zu) viel Treibstoff verbraucht. Ein Anflug zur ISS ist möglicherweise schon wegen des fehlenden Treibstoffs nicht mehr möglich.
5. Der Timer/Timingfehler ist bei Bodentests und allen Simulationen nicht aufgetreten bzw. wurde er nicht erkannt.
Insoweit muss die gesamte Testphilosophie hinterfragt und überarbeitet werden, um möglicherweise sicherzustellen, dass Fehler dieser Art zukünftig bereits bei Tests/Simulationen am Boden erkannt werden.
Offensichtlich gab es bei den Test/Simulationen einen "blinden Fleck", den man beseitigen sollte.
Theoretisch ist es nicht auszuschließen, dass es weitere unbekannte Fehler gibt, die sich hinter dem gleichen "blinden Fleck" verbergen.
6. Starliner hat wegen des Timingfehlers "gedacht" bereits in einer ganz anderen Flugphase zu sein.
Offensichtlich gibt es keine Fehlerkontrolle die z.B. über GPS oder eine andere Technik die eigene Position und Lage im Raum erfasst bzw. mit der Timline des Flugs vergleicht.
Andere Raumfahrzeuge, die eine erhebliche Lage- oder Ortsabweichung feststellen, die außerhalb vorgegebener Parameter liegt, gehen in einen Safemode, also einen sicheren Zustand.
Das wäre zwar auch nicht automatisch eine Lösung für die hier aufgetretene Situation, aber dass einfach mit dem Programm an einer unpassenden Stelle weitergemacht wird, kann fatal enden (Wie war das mit Schiapparelli?).
Ein einfaches Abspulen eines fest vorgegebenen Programms ohne Rücksicht auf das was drum herum passiert, konnte man sich noch bei den einfachen Ranger-Sonden erlauben, für das 21ste Jahrhundert eher ein Armutszeugnis.
Man stelle sich vor, Starliner befindet sich im Docking-Anflug auf die ISS und ist noch 5 m entfernt und kommt dank eines Softwarefehlers zu dem Schluss, dass der Insertion-Burn noch nicht stattgefunden hätte und feuert alle Triebwerke mit maximalem Schub...
7. Als Backup für die (fehlerhafte) automatische Steuerung waren anscheinend Kommandos vom Boden aus vorgesehen.
Diese sind wegen fehlender TDRS-Abdeckung bzw. unterbrochener Funkverbindung anscheinend nicht angekommen.
Wenn das wirklich das einzige (automatische) Backup-System sein sollte, dann ist das ziemlich untauglich.
Auch zukünftig zu fordern, für die wichtigsten Flugphasen muss halt immer eine Funkverbindung her, greift m.M. zu kurz.
Selbst wenn die Befehle der Kontroller ankämen, wer garantiert, dass diese in einer heiklen Situation, wenn es um Sekunden geht, immer auf den richtigen Knopf drücken, im Stress den richtigen Klick machen oder sich in der Hektik an die richtigen Codes erinnern?
Natürlich könnte man am Boden ein tatsächlich redundantes (d.h. andere Hardware, andere Software) System mitlaufen lassen, das dann automatisch die richtigen Codes sendet.
Aber eigentlich würde ich so ein redundanten System an Bord des Raumschiffs erwarten.
8. Es wird gesagt, bei einem Flug mit Crew hätte diese die Steuerung übernehmen können.
Das mag sogar stimmen, aber eigentlich erwarte ich ein System, das zumindest mit einem Fehler nicht automatisch in eine gefährliche Situation kommt.
9. Da nicht klar ist, ob dieser Fehler der einzige ist, der bei den vorherigen Tests und Simulationen unerkannt blieb, würde ich es keinesfalls zulassen den Starliner in die Nähe der ISS zu lassen.
Momentan kennt man nur die Auswirkungen des Fehlers, die genaue Ursache und den ganzen Hergang vollständig zu verstehen wird Monate dauern.
Daher sollte man jetzt versuchen die Kapsel geordnet landen zu lassen.
Damit kann man das Landessystem testen und die Kapsel am Boden untersuchen.
10. Sollten alle Fehler gefunden und behoben werden, kann ich mir den nächsten Start mit Crew schon vorstellen, ob allerdings gleich eine längere ISS-Mission eingeplant werden sollte, halte ich zumindest für gewagt.

Viele Grüße
Rücksturz

aber eigentlich erwarte ich ein System, das zumindest mit einem Fehler nicht automatisch in eine gefährliche Situation kommt.

Zu welchem Zeitpunkt war es denn "gefährlich"? Die Atlas V fliegt die Kapsel absichtlich in keinen stabilen Orbit, damit es unmittelbar zur Landung kommt wenn Triebwerke versagen. Ein erhöhter Treibstoffverbrauch durch den Versuch die Raumlage besonders stabil zu halten kann man nicht als "gefährlich" einstufen. Auch ein Nichterreichen der ISS ist nicht gefährlich.

Viele Grüße,

Klaus

@F-D-R und Voyager_VI:

Zum Thema "Ing.-Wissen verbrennen" hätte ich noch einiges beizusteuern, aber nicht hier, da falscher Thread. Bloß wo?

Gruß
roger50

9. Da nicht klar ist, ob dieser Fehler der einzige ist, der bei den vorherigen Tests und Simulationen unerkannt blieb, würde ich es keinesfalls zulassen den Starliner in die Nähe der ISS zu lassen.

Dieser Argumentationskette folge ich nicht. Du sagst damit: Wenn ein Fehler auftritt, sind automatisch alle Systeme potentiell nicht mehr sicher. Diesen Grad der Perfektion einer wirklich 100%tigen Testabdeckung alle nur denkbaren Szenarien ist unrealistisch. Also nur weil ein Bug durchgerutscht ist, ist nicht gleich das ganze Testkonzept für die Tonne.

Viele Grüße,

Klaus

Zu welchem Zeitpunkt war es denn "gefährlich"? Die Atlas V fliegt die Kapsel absichtlich in keinen stabilen Orbit, damit es unmittelbar zur Landung kommt wenn Triebwerke versagen. Ein erhöhter Treibstoffverbrauch durch den Versuch die Raumlage besonders stabil zu halten kann man nicht als "gefährlich" einstufen. Auch ein Nichterreichen der ISS ist nicht gefährlich.

Viele Grüße,

Klaus

Vielleicht hätte ich schreiben sollen "potentiell gefährlich".
Natürlich ist es ein Testflug, um genau solche Fehler und Probleme aufzudecken, bevor es gefährlich wird.
Aber es ist doch ganz klar, dass so ein hochkomplexes System, für den Fall dass Menschen mitfliegen, nicht plötzlich an einer völlig falschen Stelle im Programm weitermachen darf, wenn ein gravierender Fehler auftritt.
Und gravierend ist es auf jeden Fall, wenn die Software davon ausgeht einen wichtigen Missionsabschnitt schon durchlaufen zu haben, das aber gar nicht der Fall ist.
Ich erwarte nicht, dass das System so redundant ist, dass der Fehler automatisch behoben wird, aber ich erwarte schon dass zumindest automatisch erkannt wird, dass etwas nicht stimmt.
Und dann eben nicht irgendwo im Programm weitergemacht wird.
Das ist doch eigentlich eine Selbstverständlichkeit.
Deshalb mein Beispiel mit dem automatischen Andocken an die ISS, in dieser Situation darf das Raumschiff nicht einfach Prozeduren auslassen oder an einer anderen Stelle weitermachen.

Viele Grüße
Rücksturz

Zitat von: Rücksturz am 20. Dezember 2019, 23:13:10

9. Da nicht klar ist, ob dieser Fehler der einzige ist, der bei den vorherigen Tests und Simulationen unerkannt blieb, würde ich es keinesfalls zulassen den Starliner in die Nähe der ISS zu lassen.

Dieser Argumentationskette folge ich nicht. Du sagst damit: Wenn ein Fehler auftritt, sind automatisch alle Systeme potentiell nicht mehr sicher. Diesen Grad der Perfektion einer wirklich 100%tigen Testabdeckung alle nur denkbaren Szenarien ist unrealistisch. Also nur weil ein Bug durchgerutscht ist, ist nicht gleich das ganze Testkonzept für die Tonne.

Viele Grüße,

Klaus

Nein, das sage ich so nicht.
Ich behaupte, wenn ein Fehler bei vorherigen Tests nicht erkannt wurde ist bewiesen, dass mit den bisherigen Simulationen und Tests (am Boden) nicht alle Fehler erkannt wurden, zumindest einer wurde nicht erkannt.
Insoweit ist weder bewiesen dass es weitere Fehler gibt noch dass es keine weiteren Fehler gibt (letzteres lässt sich imho nicht beweisen).
Daher fordere ich, dass die Testphilosophie überdacht wird.
Möglicherweise lernt man nicht nur aus dem Fehler sondern auch daraus, dass er nicht erkannt wurde und kann sogar bei verbesserten Tests und Simulationen Fehler erkennen, die man bisher nicht erkennen konnte.
Ich habe es vielleicht negativ formuliert aber eigentlich positiv gemeint.

Viele Grüße
Rücksturz

Zu welchem Zeitpunkt war es denn "gefährlich"?

Eine desorientierte Steuerungssoftware, die nicht einmal ihre Desorientierung erkennt und einfach weitermacht, ist meiner Meinung nach sehr gefährlich. Im freien Raum, weil sie eine mögliche Rückkehr verbaut und in der Nähe der ISS, weil sie jederzeit einen Zusammenstoß fabrizieren kann. Aus falschen Annahmen werden zwingen falsche, nicht vorhersagbare Reaktionen fabriziert.

wenn ein Fehler bei vorherigen Tests nicht erkannt wurde ist bewiesen, dass mit den bisherigen Simulationen und Tests (am Boden) nicht alle Fehler erkannt wurden

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.

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. Der Treibstoffverbrauch ist aber natürlich ein Punkt, wäre interessant, ob es da eine Barriere gegeben hätte wenn ein kritischer Bereich erreicht worden wäre der eine sichere Rückkehr gefährdet. Zumindest waren noch 75% Treibstoff nach dieser Desorientierung an Bord gemäß Pressekonferenz.

Viele Grüße,

Klaus

@Rücksturz: Ich stimme Dir zu 100% zu. Speziell im Bereich "blinder Fleck". Man muss rausfinden, warum man diesen Fehler nicht in der Simulation hatte und prüfen ob es weitere blinde Flecken gibt und dann neuere und bessere Simulationen fahren.

Mit Glück stellt sich heraus, daß man bei der Simulation nur eine Variable fixiert hatte.
Mit Pech stellt sich heraus, daß man die Simulation aus Kostengründen nicht auf Flughardware laufen lässt, sondern im Emulator Simuliert.