Falcon 9 / Dragon *COTS-C2+*

Man hat ja schon den Eindruck, dass die ganze Sache ein wenig mit der heißen Nadel gestrickt ist. Ich wundere mich, dass die sonst in Sicherheitsdingen so paranoide NASA da mitmacht und nicht verlangt, dass erst alles ordentlich entwickelt und getestet ist, bevor ein Flug zur ISS mit Andockoption erlaubt wird. Wenn das mal gut geht...

Man hat ja schon den Eindruck, dass die ganze Sache ein wenig mit der heißen Nadel gestrickt ist. Ich wundere mich, dass die sonst in Sicherheitsdingen so paranoide NASA da mitmacht und nicht verlangt, dass erst alles ordentlich entwickelt und getestet ist, bevor ein Flug zur ISS mit Andockoption erlaubt wird. Wenn das mal gut geht...

Nuja - da ist aber nach wie vor der Canadarm2-Roboarm außen vor - es sind ja "lediglich" zwei Näherungsmanöver an die ISS geplant und letztendlich soll die Dragon ja mit dem Canadarm abgegriffen werden.

Trotzdem müssen natürlich die Kopplungsbolzen zum richtigen Zeitpunkt aktiviert werden. Meint man das mit Docking-Software oder ist eher die für das Rendezvouz bzw. das Station-Halten gemeint. Ich vermute letzteres.

Wegen dem Startdelay wird auch der Triebwerkstest verschoben. Grund ist das Personal welches in Meetings und Besprechungen sitzt welches für den Triebwerkstest gebraucht wird.

Gruß Ian

Hi,

so fasse ich mal die Situation so zusammen wie ich sie verstanden habe. Basierend auf diesem Artikel: http://www.nasaspaceflight.com/2012/04/spacexnasa-new-falcon-9-launch-date-slip/

Also SpaceX braucht mehr Zeit für das so genannte "hardware-in-the-loop testing" dies ist ein Test bei dem die Software und die Hardware in Kombination getestet wird. Hier gibt es scheinbar weiterhin Problem, dass die Software einen Abbruch kommandiert obwohl dieser gar nicht notwendig ist. Hier interpretiert die Software die Hardware falsch.

Nun soll verschoben werden! Den 3. Mai kann man nicht schaffen weil wegen der Verschiebung man wahrscheinlich den Hotfire Test am 27.4. nicht machen kann weil das dazu benötigte Personal in einem FRR Meeting benötigt wird. Nun scheint der 7.5. wohl im Raum zu stehen. Allerdings gibt es hier ein weiteres Problem:

Am 15.5. soll die nächste ISS Crew mit der Sojus starten und die Nasa will nicht, dass 2 Vehicle sich irgendwo in einem Orbit "nahe" der ISS aufhalten. (Das ist glaub ich eine Flight Rule das dies verboten ist)

Deshalb kann es sein, dass die Nasa darauf bestehen könnte, dass man den Start auf den 19.5. verlegt und somit abwartet bis die neue Crew auf der ISS angekommen ist.

Wenn man am 19.5. allerdings startet wird dies ein Nachtstart. Ob dies ein weiteres Problem sein könnte weiß ich nicht, immerhin ist die Falcon 9 noch nie bei Nacht gestartet. Allerdings weiß ich, dass man bei SpaceX darauf besteht, dass die Landung bei Tag stattfindet. Ob der Startzeitpunkt darauf einen Einfluss hat wann man landen muss weiß ich nicht.

Ich halte es auf jedenfall für sehr unwahrscheinlich, dass Roscosmos den Sojus Start verschieben wird nur weil sich die Dragon beim ankommen/andocken an die ISS verspätet aus was auch immer für Gründen. Wenn man also am 7. Mai starten will MUSS man bis zum 14.5. erfolgreich an die ISS angedockt sein oder muss unverrichter Dinge wieder abziehen. Will man das? Sicher genug Zeit für die für das ankommen benörtigen Tage so wie es derzeit geplant ist hat man. Aber wer weiß schon ob alles problemlos funktioniert? Wenn nicht hat man nur 2 Tage Spielraum um mögliche Probleme zu lösen.

Soweit die Situation wie ich sie verstanden habe.

Gruß Ian

Via NSF kommt die Anekdote, dass der Dragon Programmcode offenbar in C++ geschrieben ist. Leider war das nicht die Programmiersprache, in der das NASA Reviewteam am besten geübt war, was wohl für einige Hürden gesorgt haben soll.

Hallo,

Mal die Startverschiebungstimeline 

 ...6.Juni , 8.Oct. , 30.Nov. , 19.Dec. in 2011 und weiter gehts.. 7.Jan. , 7.Feb. , 20.März , und 30.April .  und jetzt auf den 7. Mai 2012 wir kommen in den Bereich von 11 Monaten.
Das ist schon ganz großes Space Shuttle Niveau...zumindest bei den Verzögerungen 

gruß jok

naja, bei STS-1 wurde aus Anfang 79 April 81, da hätte Space X also noch ein Jährchen.....

@vostei,
der Vergleich zu STS 1 hinkt m. E. auch etwas. Das Space Shuttle ist nicht mit einer Kapsel zu vergleichen!

Sicherlich auch bei Apollo 7 gab es, wenn man Apollo 1 berücksichtigt, eine vergleichbare Verzögerung. Vielleicht hätte man doch beide Flüge getrennt durchführen sollen?
Gruß Ingo

Edit Holi: Threadtitel repariert, Gruß Holger

Nee man sollte es mit einem vergleichbaren Transporter vergleichen, z.B. dem ATV und wenn man da mal hier klickt:
http://www.spacedaily.com/news/rlv-03b.html

sieht man, dass 2003 die Rede von September 2004 als Startdatum beim ATV war. Der erste Start war März 2008, man war also mindestens 3 1/2 Jahre hinterher. Und wenn man jetzt den ursprünglichen SpaceX-COTS Vertrag anschaut sieht man dort ein Datum von Ende 2009 für COTS-3. Damit ist man zur Zeit 2 1/2 Jahre hinterher und man hat noch ein Jahr Zeit mit dem ATV gleichzuziehen.

SpaceX PAO:

Update on SpaceX COTS 2 Launch

NASA and the Cape Canaveral Air Force Station have approved SpaceX’s request to set May 7th as the target launch date for the upcoming COTS 2 mission.

We will send out updated information on launch activities in the coming days.

7. Mai ist das neue Datum. Nur um wieviel Uhr ist da der Start?

Und wenn man jetzt den ursprünglichen SpaceX-COTS Vertrag anschaut sieht man dort ein Datum von Ende 2009 für COTS-3. Damit ist man zur Zeit 2 1/2 Jahre hinterher ...

So ist es! Und der Vertrag wurde im Sep. 2006 vereinbart als SAA. Bei einer Verdoppelung der Entwicklungzeit redet man wohl noch nicht von "hinterm-Plan" und "Budgetüberschreitung".

So gesehen ist die Entwicklungszeit des Shuttles geradezu sensationell verlaufen, zumal der Start ja dann auch erfolgte und wir auf das Erreichen von COTS 3 noch warten.

Der Vergleich mit Europa hinkt aber so was von total, auch wenn es da um ein vollautomatisches Docking ging.

7. Mai ist das neue Datum. Nur um wieviel Uhr ist da der Start?

NASA Kennedy twittert dazu,...um 15:38 Uhr unserer Zeit. 

Gruß
Holi

Moin,

Nee man sollte es mit einem vergleichbaren Transporter vergleichen, z.B. dem ATV .... sieht man, dass 2003 die Rede von September 2004 als Startdatum beim ATV war. Der erste Start war März 2008, man war also mindestens 3 1/2 Jahre hinterher.

Ja, ATV und Dragon haben in dieser Beziehung viel Ähnlichkeit. Auch bei ATV waren es die S/W-Entwicklung und jede Menge H/W-Test, die von der ESA gefordert wurden, die zu der Verzögerung führte. Hinzu kamen viel zusätzliche Dokumente, die plötzlich gefordert wurden. Ich drücke SpaceX alle Daumen, das hinzukriegen.

Übrigens, auch bei ATV ist die S/W fast komplett in C++ geschrieben....

Gruß
roger50

Übrigens, auch bei ATV ist die S/W fast komplett in C++ geschrieben....

Prinzipiell ist es fast völlig egal, welche Programmiersprache man nun nimmt. Wichtig ist der Softwareentwicklungsprozess, kompetente Mitarbeiter, ständige Tests und ein gutes Qualitätsmanagement. Damit bekommt man die Software auch von Anfang an gut hin, so lange eben nicht ständig Anforderungen hinzukommen. Sowas macht eine Software dann plötzlich unglaublich kompliziert, wenn man keine agilen Modelle verfolgt. Und ATV Software ist bestimmt mit V-Modell 97 entwickelt. Falls es V-Modell XT ist, wäre zu prüfen, welche Module dort verwendet worden sind.

Welches Modell SpaceX verwendet hat bekommt man sicher nicht raus oder? Zu SpaceX würde ja Extreme Programming passen, aber das lässt die NASA sicher nicht mit sich machen. Als Zwischenschritt wäre auch RUP möglich.

Gruß, Klaus

Hallo Klaus,

steck deine Vorgehensmodelle wieder ein, ein NASA-Audit hatte doch im Okt. 2011 festgestellt, dass SpaceX kein CMMI-Modell verfolgt. Die dürften also weder ein klassisches noch ein agiles Vorgehensmodell haben. Wahrscheinlich kann man das eher Hero/Praktikanten-Modell nennen (wobei ich dafür sogar eine gewisse Symphatie hätte).

Die NASA würde sicher gerne Vorgaben machen, kann sie aber nicht, weil nach SAA die Umsetzungsverantwortung bei SpaceX liegt.

Aktuell interessant ist, dass Musk von Hardware-in-the-loop-Tests spricht, das sind Integrationstests, bei denen das zu testende System mit seinen Ein- und Ausgängen in einem Simulator getestet wird. Wie schon erwähnt, sind die Ergebnisse wohl noch nicht so, wie sich das SpaceX erhofft.
http://de.wikipedia.org/wiki/Hardware_in_the_Loop

viele Grüße
tomtom

Guten Morgen,

nach allem, was ich hier so lese, rechne ich mit weiteren Verzögerungen, oder - wenn der Druck zu stark wird - für einen zu frühen Start mit einem unerwünschten Missionsausgang.

Und würde mich natürlich freuen wie ein Schnitzel, wenn obiges beides nicht eintritt. Jetzt fragt mich nicht, wie ein Schnitzel sich freut ...

Gruß   Pirx

Jetzt fragt mich nicht, wie ein Schnitzel sich freut ...
Gruß   Pirx

Als Tierfreund, ich habe sie zum fressen gerne, freue ich mich wie die Sau (am Stück) wenn's klappt.... ^^

Hi,

so Jungs, nach euren Blödeleien hier mal nen paar konstruktive Updates:
Die Nasa hat mitlerweile offiziell den 7. Mai als Starttermin freigegeben! Das wundert mich zwar aber na gut.

Der Hotfire Test ist nun auf den 30.4. Angesetzt. Um 15:38 MESZ solls nun feuern!

Des weiteren hat die Nasa ihre Nasa TV Übertragungszeiten für die Mission angepasst die ich hier im folgenden zitieren werde mit angepassten MESZ Zeiten:

May 6, Sunday

    19:00 MESZ – SpaceX/Falcon 9 Dragon Pre-Launch Briefing – KSC (All Channels)


May 7, Monday

    14:00 MESZ – SpaceX/Falcon 9 Dragon Launch Coverage Begins (Launch scheduled at 15:38 MESZ) – KSC (All Channels)
    17:00 MESZ – SpaceX/Falcon 9 Dragon Post-Launch News Conference – KSC (All Channels)


May 8, Tuesday

    17:00 MESZ  – ISS Update – JSC (All Channels)


May 9, Wednesday

    14:30 MESZ – SpaceX/Dragon Fly-Under of the ISS Coverage – JSC (All Channels)
    16:00 MESZ – SpaceX/Dragon Mission Status Briefing – JSC (All Channels)
    17:00 MESZ – ISS Update – JSC (All Channels)


May 10, Thursday

    14:00 MESZ – SpaceX/Dragon Grapple and Berthing Coverage – JSC (All Channels)
    19:00 MESZ – SpaceX/Dragon Mission Status Briefing – JSC (All Channels)


May 11, Friday

    13:30 MESZ – SpaceX/Dragon Hatch Opening Coverage – JSC (All Channels)
    TBD  – ISS Expedition 31 In-Flight Event – JSC (All Channels)
    TBD – ISS Update – JSC (All Channels)

Wie ihr an diesen Zeiten erkennen könnt hat man auch das Missionsprofil angepasst und strebt nun ein Berthing am FD4 an.
Zu guter letzt etwas nettes für alle die des englischen mächtig sind was ich im NSF Forum gefunden hab: http://forum.nasaspaceflight.com/index.php?topic=28734.msg889836#msg889836
In dem Sinne scheint ja SpaceX alles klasse zu machen.^^
Glück Auf und euch alle noch einen schönen Tag,

Gruß Ian

Zitat von: roger50 am 25. April 2012, 02:42:11

Übrigens, auch bei ATV ist die S/W fast komplett in C++ geschrieben....

Prinzipiell ist es fast völlig egal, welche Programmiersprache man nun nimmt.

So weit würde ich nicht gehen - wenn die Nasa in bestimmte Bereiche Einsicht nimmt oder nehmen läßt, ist es schon relevant, daß derjenige, der eine Software oder ein Teil davon auf Quellcodeebene gegenprüft, auch ein mehr als rudimentäres Verständnis von der verwendeten Programmiersprache hat und von ihren spefizischen Eigenheiten. Daß allerdings die Nasa da nun gerade mit C++ solche "Probleme" haben soll, verwundert mich jetzt ein bisschen - in der Prozess- und Steuerungstechnik ist die Sprache jetzt nicht so selten, bzw. war zumindest zu Zeiten meines Studiums üblich bis Standard.
Was zu der Frage führt: womit arbeitet denn die Nasa selbst in diesem Bereich?

Zitat von: klausd am 25. April 2012, 03:08:11

Zitat von: roger50 am 25. April 2012, 02:42:11

Übrigens, auch bei ATV ist die S/W fast komplett in C++ geschrieben....

Prinzipiell ist es fast völlig egal, welche Programmiersprache man nun nimmt.

So weit würde ich nicht gehen - wenn die Nasa in bestimmte Bereiche Einsicht nimmt oder nehmen läßt, ist es schon relevant, daß derjenige, der eine Software oder ein Teil davon auf Quellcodeebene gegenprüft, auch ein mehr als rudimentäres Verständnis von der verwendeten Programmiersprache hat und von ihren spefizischen Eigenheiten. Daß allerdings die Nasa da nun gerade mit C++ solche "Probleme" haben soll, verwundert mich jetzt ein bisschen - in der Prozess- und Steuerungstechnik ist die Sprache jetzt nicht so selten, bzw. war zumindest zu Zeiten meines Studiums üblich bis Standard.
Was zu der Frage führt: womit arbeitet denn die Nasa selbst in diesem Bereich?

Dies hier gerüchteweise: http://de.wikipedia.org/wiki/HAL/S

steck deine Vorgehensmodelle wieder ein, ein NASA-Audit hatte doch im Okt. 2011 festgestellt, dass SpaceX kein CMMI-Modell verfolgt.

Das ist aber unabhängig davon, welches Modell SpaceX bei der Softwareentwicklung einsetzt. Die verschiedenen Reifegrade von CMMI (0-5) sind nämlich noch eine Ebene höher angesiedelt und sollen nur dabei helfen, vorhandene Prozesse zu optimieren und einzuschätzen, wie weit man ist. Kurz: Ohne Prozess kein CMMI, aber ohne CMMI trotzdem ein Prozess möglich.

Die dürften also weder ein klassisches noch ein agiles Vorgehensmodell haben. Wahrscheinlich kann man das eher Hero/Praktikanten-Modell nennen (wobei ich dafür sogar eine gewisse Symphatie hätte).

Das kann ich mir daher unmöglich vorstellen. Ohne Entwicklungsmodell befinden wir uns nämlich in den Zeiten, wo 95% aller Softwareprojekte in den Sand gesetzt wurden.

So weit würde ich nicht gehen - wenn die Nasa in bestimmte Bereiche Einsicht nimmt oder nehmen läßt, ist es schon relevant, daß derjenige, der eine Software oder ein Teil davon auf Quellcodeebene gegenprüft, auch ein mehr als rudimentäres Verständnis von der verwendeten Programmiersprache hat und von ihren spefizischen Eigenheiten.

Das meinte ich damit nicht. Mir war wichtig zu sagen, dass man mit fast jeder Programmiersprache sein Ziel erreichen kann. Wenn die NASA Abteilung zu dämlich ist, simples C++ zu verstehen, dann ist das wieder was anderes. Da stellt sich mir doch glatt die Frage was ein Komitee verbessern will, dass sich erst neu in C++ einarbeiten muss.

Gruß, Klaus

Hallo Zusammen,
diese beiden Aussagen passen in der Logik nicht zusammen:

Via NSF kommt die Anekdote, dass der Dragon Programmcode offenbar in C++ geschrieben ist. Leider war das nicht die Programmiersprache, in der das NASA Reviewteam am besten geübt war, was wohl für einige Hürden gesorgt haben soll.

Moin,...........................................................
Übrigens, auch bei ATV ist die S/W fast komplett in C++ geschrieben....
Gruß
roger50

... was ist jetzt der wirklich Verzögerungsgrund.?
Habe ich etwas übersehen?
mit den besten Grüßen
Gertrud

... was ist jetzt der wirklich Verzögerungsgrund.?

Fehler ausmerzen bei der Software.

Gruß, Klaus

Hallo Klaus,
ich stimme Dir vollständig zu,

Fehler ausmerzen bei der Software. ...

Doch da sehe ich auch Gertruds Bedenken bestätigt,

... was ist jetzt der wirklich Verzögerungsgrund.?

denn dummerweise steckt in der Aussage, dass der eine den anderen Prüfer/Tester nicht versteht, ein hoher populister Faktor. Sind die Verantwortlichen wirklich so blöd und stecken Software-Legasteniker als Qualitätssicherer zusammen - nach dem Motto: Was der eine nicht versteht, begreift dafür der andere nicht... 
Gruß aus dem HausD