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

Zitat von: Reihnold am 21. Dezember 2019, 18:30:16

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.

In der Pressekonferenz mit NASA und Boeing heute Abend (20 Uhr MEZ) wurde es so erklärt daß sich die Programmlogik von Starliner eine Zeitreferenz von der Atlas holt. Anscheinend hat diese Logik danebengegriffen und nicht die richtige Zeitreferenz geholt. Es wurde explizit gesagt daß es ein Fehler von Starliner ist und nicht der Atlas. Aber man versteht noch nicht warum das passiert ist. Die Zeitreferenz ist nun korrigiert, damit sollten dadurch keine weiteren Probleme auftreten.

Kommt mir kompliziert vor. Man könnte die Messung der Beschleunigung in Längsrichtung verwenden und damit eine Zeitreferenz bestimmen, z.B. wenn die Beschleunigung eine hohen Wert erreicht der stationär nicht durch Wind usw. erreicht werden kann. Wann das auftritt ist für den Atlas Aufstieg wohl ausreichend genau vorhersagbar, zumindest für eine Plausibilitätsprüfung einer anderweitig beschafften Zeitreferenz.

Kommt mir kompliziert vor. Man könnte die Messung der Beschleunigung in Längsrichtung verwenden und damit eine Zeitreferenz bestimmen, z.B. wenn die Beschleunigung eine hohen Wert erreicht der stationär nicht durch Wind usw. erreicht werden kann. Wann das auftritt ist für den Atlas Aufstieg wohl ausreichend genau vorhersagbar, zumindest für eine Plausibilitätsprüfung einer anderweitig beschafften Zeitreferenz.

Obwohl es der Erstflug einer Atlas V mit einer Dual Engine Centaur war und die Rakete ein neuartiges Flugprofil flog, kennt man den Träger inzwischen sehr genau. Außerdem hat die Centaur ein eigenes, sehr genaues Navigationssystem. Sich auf die Atlas zu verlassen und sich von dort ein Zeitsignal zu holen ist eigentlich keine schlechte Idee. Wenn es funktioniert, dann ist das einfach und zuverlässig. Wir wissen über den genauen Startverlauf der Starliner-Avionik zu wenig, aber so kurz nach der Abtrennung ist das Navigationssystem der Centaur vermutlich zuverlässiger. Starliner hat zwar ebenfalls ein INS-System, aber die primäre Navigation erfolgt sicher über ein Sternennavigationssystem. So kurz nach der Abtrennung der Kapsel liefert das noch keine präzisen Daten. Da macht es durchaus Sinn, die Triebwerke mittels eines Zeitsignals auf Basis der Centaur zu starten, wenn das INS des Starliner bestätigt, das die Kapsel richtig ausgerichtet ist.

Alle Eventualitäten kann man eh nicht abfangen. Beispiel SpaceX, der Fehlstart 2015. Die Dragon hat das Versagen der Falcon 9 überlebt, wurde dann aber beim Aufprall auf den Atlantik zerstört, weil die Fallschirme nicht ausgelöst wurden. Klar, wer rechnet schon damit, beim Start einer unbemannten Kapsel die Fallschirme zu brauchen. Oder der Fehlstart der ersten Ariane 5, als ein Speicherüberlauf nicht abgefangen wurde. Oder das Problem mit Huygens, als der Empfänger an Bord von Cassini den Dopplereffekt des Signals nicht verarbeiten konnte.

In der Pressekonferenz mit NASA und Boeing heute Abend (20 Uhr MEZ) wurde es so erklärt daß sich die Programmlogik von Starliner eine Zeitreferenz von der Atlas holt. Anscheinend hat diese Logik danebengegriffen und nicht die richtige Zeitreferenz geholt.

Dadurch erklärt sich für mich auch, warum der Insertburn nicht zu einem anderen Zeitpunkt stattgefunden hat, sondern gar nicht. Der Starliner hat sich eine Referenz geholt, bei der die Zündung schon statt gefunden hatte. Dadurch war die Mission Elapsed Time im Starliner nie an der Stelle, an der die Zündung ausgelöst hätte werden müssen.

Klingt erstmal einfach zu beheben.

Da stimme ich zu, so etwas lässt sich sehr einfach beheben.

Damit wird aber die Frage noch viel wichtiger: "Warum hat das die Simulation nicht gezeigt?" ...

In der Pressekonferenz mit NASA und Boeing heute Abend (20 Uhr MEZ) wurde es so erklärt daß sich die Programmlogik von Starliner eine Zeitreferenz von der Atlas holt. Anscheinend hat diese Logik danebengegriffen und nicht die richtige Zeitreferenz geholt. ...

Danke für die Infos, proton01!  Das ich das jetzt verstehen würde, kann ich ich aber trotzdem nicht sagen.
Ich versuche laut nachzudenken - welche Zeit holt sich der Starliner von der Atlas?

 - UTC wird es nicht sein, die ist schon vor dem Start bekannt und braucht nicht übergeben werden.

 - die Startzeit? Zu dem Zeitpunkt ist doch noch alle bodenmäßig verdrahtet bzw. werden die Leitungen gerade getrennt, genug Möglichkeiten einen eigenen Timer zu starten.

 - verstrichene Zeit ab der Trennung von der Atlas? Die kann der Starliner auch ohne übergabe haben, meine ich. Falls er die Trennung selber auslöst, hat er sie automatisch, wenn nicht, reicht ein Mikroswitch an der Trenn- / Kopplungsvorrichtung. (Der dann einen Timer startet.)

Aus diesen drei Elementen läßt sich zeitmäßig alles ermitteln, wenn ich nicht irre. Und die ISS Parameter sind auch bekannt.  Der vorgeschlagene Beschleunigungssensor wüerde wohl auch funktionieren. Man macht doch die Dinge möglichst autonom, wenn man nicht zum Gegenteil gezwungen ist. Keine unnötigen Komplikationen, Kommunikation hat immer auch etwas von der Stillen Post.

Und wenn von Anfang an klar ist, daß die Trennung bei einer leicht suborbitalen Geschwindigkeit erfolgt, ist auch klar, daß die erste Aktion eine Bahnanhebung sein muß. Nachdem alles übeprüft wurde, geht es doch softwaremäßig an die Ausrichtung und wenn die auch ok ist, wird gestartet. Ein Timer ist dafür doch  eigentlich unnötig, vielleicht noch um die Dinge ins Logbuch zu schreiben

Sinnvoll wäre jedoch die Übergabe der Positionsdaten bei der Trennung, wie MR schon schreibt. Mit der Zeit dann im "Paket", weil es ja irgendwie sinnvoll zusammengehört. Dann kann man die Brennzeit bei der Anhebung sicher genauer bestimmen. Aber auch Fehler produzieren.

So ein bisschen komme ich mir vor wie bei der Fußball WM. Ganz Deutschland besteht aus Trainern
und weiß wie man es besser macht.
Ich bin nunmehr seit >38 Jahren Informatiker (besonders im Bereich embedded und Steuerungen) aber
ein Urteil darüber was "DIE" bei einem so komplexen Thema falsch gemacht haben nehme ich mir nicht heraus.

Das Ganze ist ein Tripel aus Position, Geschwindigkeit und Zeit. Daraus ergibt sich ein Zustand.
Aus diesem Zustand heraus wird der Bordcomputer handeln.

Bahnmechanik ist nu wirklich nicht trivial, da ist ruckzuck ein Fehler drin (den man eventuell nicht am
Boden entdecken konnte).

Ulli

Danke für die Infos, proton01!  Das ich das jetzt verstehen würde, kann ich ich aber trotzdem nicht sagen.

Geht mir eigentlich genauso. Ich habe nur versucht wiederzugeben, was gesagt wurde.

Da kann man jetzt herrlich spekulieren, aber wir wissen viel zu wenig über das System, um begründete Aussagen machen zu können. Früher gab es bei NASA detaillierte System News Reference Bücher für Apollo (ca. 350 + 270 Seiten für CSM und LM), Skylab , Space Shuttle (über 1000 Seiten). Damit könnte man es eventuell besser verstehen. Für CST-100 ist die Dokumentation äußerst dürftig, noch nicht mal ein brauchbarer Press Kit ist verfügbar.

Da stimme ich zu, so etwas lässt sich sehr einfach beheben.

Ein kurzer Bezug würde sie Sache verständlicher machen

Damit wird aber die Frage noch viel wichtiger: "Warum hat das die Simulation nicht gezeigt?" ...

Wein keine Simulation die Wirklichkeit genau nachbilden kann. Weil jede Simulation mit Annahmen und sonstigen Krücken arbeitet. Weil es immer auch eine Kostenfrage ist, wie nah an der Wirklichkeit man die Simulation baut. Weil man vielleicht nicht einmal die Elektronik der Oberstufe mit dem Starliner hat direkt kommunizieren lassen. Sondern sich auf irgendwelche vielleicht überholte Standards verlassen hat. Oder, oder..

Ich gebe zu, daß ich inzwischen echt überrascht bin, wenn eine Simulation zufällig dem späteren Ergebnis entspricht. Man darf nicht alles glauben, nur weil das Ergebnis mit 10 Stellen hinter dem Komma genau berechnet wurde.

Ich bin nunmehr seit >38 Jahren Informatiker (besonders im Bereich embedded und Steuerungen) aber
ein Urteil darüber was "DIE" bei einem so komplexen Thema falsch gemacht haben nehme ich mir nicht heraus.

Ich auch nicht, auch weil ich mich nur ca 20 Jahre der Programmiererei gewidmet habe, und noch dazu als einer dieser furchtbaren Autodidakten   Was ich mir herausgenommen habe war nur daran zu zweifeln, daß es an der Zeitübergabe lag, wie von der NASA behauptet wurde. Denn eine Zeitübergabe war nicht nötig, wie ich versucht habe zu begründen.


Position + Zeit + Geschwindigkeit ist etwas anderes, und ja, sicher nicht trivial.

Was immer in dem Zusammenhang als "Zeitübergabe" bezeichnet wird.
Da gibt es durchaus (in jedem Projekt) interne Nomenklaturen die dem Außenstehenden nicht unmittlebar
einleuchten.

Ulli

Ich kann mir sehr gut vorstellen, daß hier der "übliche" Timer inklusive Flugphase übergeben wird. Das sieht man ja bei einigen Raketenstarts. Speziell die Flugphase wird gelegentlich mit angezeigt.

Wenn man jetzt die aktuelle Flugphase von der Rakete an das Raumschiff übergibt, damit das Raumschiff sauber arbeitet, dann hat man alles in einem Rutsch erschlagen.

Beispiel:
- Phase 12 ist der Flug der 2. Stufe bis zum Ende der sicheren Parabel.
- Phase 13 ist der Flug vom Ende der sicheren Parabel in den sicheren Orbit
- Phase 14 ist der Flug vom sicheren Orbit in den ISS-Orbit.


Übergibt die Rakete "Zeit: 12 Minuten - Phase 13", dann weiß, das Raumschiff, daß es Phase 13 durchführen soll.
Übergibt die Rakete "Zeit: 12 Minuten - Phase 14", dann weiß, das Raumschiff, daß die Rakete Phase 13 bereits durchgeführt hat.

Immerhin ist die Entscheidung, daß die Rakete keinen Orbit erreicht, ja nicht in Stein gemeißelt, man könnte es nächstes Jahr ändern, wenn man möchte. Somit muss das Raumschiff wissen, wie weit die Rakete bereits geflogen ist.

Wenn in der Rakete das Triebwerk der 2. Stufe versagen sollte, würde die Rakete "Zeit: 11 Minuten- Phase 12" übergeben. Dann würde das Raumschiff wissen, daß es ein großes Problem gibt. Und wenn "Zeit: 0 Minuten - Phase 0" übergeben wird, dann weiß das Raumschiff, daß die Rakete noch am Boden steht bei der Trennung. Es wäre also Zeit zum Auslösen der Rettungsraketen.

Das war das was ich mit "Status" oder neudeutsch mit "State" meinte.
(Stichwort StateMaschine).

Ulli

NASA-Übertragung der Landung beginnt um 12:45 MEZ. De-Orbit-Burn geplant für 13:23 MEZ, mit Landung um 13:57 MEZ.

Das bedeutet: Landung um 5:57 Uhr lokal in White Sands, dann ist's da leider noch stockfinster....

Man gönnt uns bei dieser Mission einfach keine guten Bilder.....

https://blogs.nasa.gov/commercialcrew/2019/12/21/boeing-starliner-to-land-sunday-morning/

Gruß
roger50

Neue Daten:
Apogäum: 260,86 km
Perigäum: 246,03 km

Es gibt ein Video von den Trennung zwischen Rakete und Starliner:

https://starlinerupdates.com/starliner-centaur-separation/

Ja fein, aber ein paar Sekunden mehr hätten sie uns gönnen können.

Hatte man in der Kapsel eigentlich wichtige Fracht für die ISS dabei, oder nur "Geschenke"?
Einen Trunk für zusätzliche Fracht wie bei der CrewDragon gibt es ja beim Starliner nicht, wenn ich das richtig gesehen habe.

Es gibt ein Video von den Trennung zwischen Rakete und Starliner:

https://starlinerupdates.com/starliner-centaur-separation/

Danke.
Aber schon hier sieht man, daß Starliner unmittelbar nach der Trennung mit allen möglichen Lagekontrolltriebwerken feuert. Normalerwese sollte er wohl (so erwarte ich es ohne es zu wissen) nur einen Impuls in Längsrichtung durchführen um sich sauber von der Centaur  zu trennen.

@roger50:   wie war das bei ATV ?

Dieses direkte Feuern find ich auch ungewöhnlich. Wenn man Nutzlasten aussetzt versuchen die Körper eigentlich erstmal kräftefrei zu driften.

Es bestätigt zumindest, dass Starliner praktisch ab der Trennung sich schon in einer falschen Fluphase befand bzw. mind. die Phase des Insertion-Burns übersprungen hatte.

Um mich möglicherweise zu wiederholen, die fehlerhafte Zeit/Phasen/Status-Übergabe ist eigentlich ein kleiner Fehler.
War das der ursprüngliche Fehler (und nicht die Folge einer weiteren Kette von Fehlern oder gar Designfehlentscheidungen), dann könnte das möglicherweise relativ leicht zu beheben sein.
Allerdings hat man für zukünftige Simulationen eine neue potentielle Fehlerquelle, "Was passiert, wenn Starliner ein falsches Zeit- oder Status-Signal bekommt?".
Hier alle möglichen Fehlerbäume durchzutesten wird wahrscheinlich länger dauern als den eigentlichen Fehler zu beheben.
Außerdem sollte man sich noch einmal Gedanken darüber machen, wie Starliner selbst überprüfen kann, ob die aktuelle Ausrichtung, Lage, Beschleunigung, Triebwerkstemperaturen, Füllstände etc. zur aktuellen oder vermeintlichen Flugphase passen. Und was passieren soll, wenn es abweicht.

Einen schönen 4. Advent wünscht
Rücksturz

Außerdem sollte man sich noch einmal Gedanken darüber machen, wie Starliner selbst überprüfen kann, ob die aktuelle Ausrichtung, Lage, Beschleunigung, Triebwerkstemperaturen, Füllstände etc. zur aktuellen oder vermeintlichen Flugphase passen. Und was passieren soll, wenn es abweicht.

Genau! Jede primitive Webseite führt bei "Fremddateneingabe" eine Plausibilitätsprüfung durch. In diesem Fall hätte es offenbar ausgereicht, die übergebenen Daten mit einem eigenem, beim Start gesetzten Timer zu vergleichen. Dann wäre klar, daß man sich nicht "hinter" der Flugbahnanhebung befinden kann.

Ich bin zwar nur ein blöder Feld-, Wald- und Wiesenprogrammierer, aber ohne Plausibilitätsprüfungen wird auch in unseren Kreisen kein einziger Datensatz in einer eher unwichtigen Datenbank gespeichert. Mein Verständnis dafür hält sich daher echt in Grenzen.

Unabhängig davon wünsche ich aber allen hier versammelten ebenfalls einen schönen 4. Advent 


EDIT / PS: Als Problem sehe ich daher nicht diesen einen Fehler, ich zweifle langsam an der Qualität der Software als Ganzes und an der Fähigkeit der direkt Beteiligten die Dinge gegenüber der Öffentlichkeit angemessen zu vertreten.

Nun mich wundert das ganze nicht wenn man mal schaut wie Boeing bei der Softwareentwicklung der 737Max gearbeitet hat. Das zeigt mit eines, das ganze Geschwafel von wegen "wir liefern bessere Leistung und die kostet dann halt mehr..." ist nur dummes Geschwätz. Ich habe meine Zweifel ob das Ding auch nur annähernd sicher sein wird.

Man bereitet sich für die Landung vor.

Deorbit Burn sieht gut aus.

… und abgeschlossen.

Nächster Hauptpunkt: Abtrennen Service Module....

Auch schon erledigt !

Gruß
roger50