SpaceX - Diskussion

Um einen Altkanzler zu zitieren: Wichtig ist, was hinten dabei rauskommt.

SpaceX hat bisher letztlich immer geliefert. Die FH wird genauso fliegen, wie Crew Dragon und anderes. Raumfahrt ist kompliziert und hart. Gemessen daran und wie viel SpaceX seit der Gründung schaffte ist es extrem hohes Niveau auf dem gejammert wird.

An MCT wird sicherlich fleißig entwickelt. Wie Musk erwähnte, möchte man es aber erst dann öffentlich vorstellen, wenn man sich sicher ist, dass nicht mehr allzu viel am Entwurf geändert wird. Klingt für mich vernünftig.

So, und jetzt zerreisst mich.

Nein

Ich denke hier ähnlich wie Du. Die Prognosen von SpaceX sind einfach viel zu optimistisch. Aber das sind Prognosen immer, denn anhand von der ersten Prognose wird entschieden, auch über Zuschüsse anderer Firmen. Jeder weiß zwar, daß die Prognosen nicht stimmen, aber wenn jemand eine echte Prognose abgeben würde, dann würde sein Projekt schon im Keim erstickt werden. Und das ist mit allen großen und kleinen Projekten auf der ganzen Welt das gleiche.

Die Zuverlässigkeit ist noch nicht die beste, aber das ist sie bei neuen Firmen nie. Und SpaceX ist neu. Ein Triebwerk ist mal ausgefallen und der Satellit ist verglüht, während die Dragon noch zur ISS kam. Und dann ist ein Zulieferteil mit Zertifikat Schuld gewesen an einem Totalverlust. Das mit den Zulieferern wird SpaceX jetzt sicher gelernt haben. Zertifikate sind schön, aber sie sind Ihr Papier nicht Wert. Der Zulieferer wird sicher zahlen müssen, aber der ist jetzt pleite (oder gut versichert).

Wenn man sich die aktuelle Startrate von SpaceX anschaut, dann sieht man eine stetige Verbesserung. Sie Starten im Schnitt immer schneller. Sie machen Fortschritte. Und das ist das einzig wichtige.

Sehen wir es doch mal so: Die Kapazitäten (auch einer Firma wie SpaceX) sind einfach begrenzt. Man kann da keine Wunderdinge erwarten. Ich erinnere mich noch lebhaft an die Diskussionen unmittelbar nach dem Fehlstart. Da wurde über ein RTF in zwei bis drei Monaten phantasiert. Mit viel Mühe hat man letztendlich kurz vor Jahresende noch einen einzigen Start hinbekommen, den allerdings mit Paukenschlag. Dennoch: Auch für SpaceX gelten bestimmte Limits und gelten bestimmte Normalitäten. Und wenn man diese Normalitäten ansetzt, dann:

-> liegt die gefühlte Wahrscheinlichkeit für einen FH-Erststart in diesem Jahr (wieder!) bei deutlich unter 50%
-> wird es vermutlich noch keinen orbitalen Start einer bereits gebrauchten Stufe geben
-> wird die weitere Optimierung der F9 hin zu einer technisch (nicht wirtschaftlich!) vernünftig funktionierenden Wiederverwendung der Erststufe vermutlich noch mindestens 2-3 Jahre in Anspruch nehmen
-> wird es möglicherweise ("hope to...") gegen Ende des Jahres erste konkrete Info zu einem größeren Träger geben (wobei es das 2015... äh... 2014... nein 2013 auch schon hieß...)
-> liegt die Wahrscheinlichkeit für ein fehlstartfreies Startjahr bei angenommenen 10 Starts bei nur etwa 60% (bei angenommener Zuverlässigkeit von 95%)

Und was die Folgen eines erneuten Fehlstarts wären, das denke ich muss man hier nicht weiter ausführen. Das ein FH-Start dieses Jahr in dem Fall genauso hinfällig wäre, wie irgendwelche Ankündigungen zur nächsten Trägergeneration ist wohl klar.

Um es ganz klar zu sagen: Ich möchte hier keinen Pessimismus verbreiten, und auch nichts miesmachen. Aber was ich hier im Forum feststellen muss, dass es irgendwie (fast) nur zwei Lager gibt:Die einen verbreiten Phantasie-Optimismus, dann gibt es selbsternannte Experten, die von vornherein alles mit "X" komplett in Frage stellen (noch sehr vornehm ausgedrückt). Warum kann man nicht einfach mal den gesunden Mittelweg gehen? Das erspart den beklagten Frust auf der einen, und Anfeindungen auf der anderen Seite. Sie werden schon liefern, irgendwann. Aber eben nicht morgen sondern meistens erst übermorgen. Und ich hoffe dass ich noch eine Menge davon erleben werde.

Ich glaub den Mittelweg gibt's viel öfter als man denkt. Er schafft sich aber (leider) einfach nicht so stark Gehör.

liegt die Wahrscheinlichkeit für ein fehlstartfreies Startjahr bei angenommenen 10 Starts bei nur etwa 60% (bei angenommener Zuverlässigkeit von 95%)

? Meine Mathekenntnisse sagen da 75% voraus.

--
Ich bin auch der Meinung,  dass das Problem häufig die zu hohem Erwartungen sind. Diese sind kaum zu erfüllen und jede 'fehler' von SpaceX wird dann zu einer Enttäuschung.
Zudem machen die ganzen Verschiebungen es schwer, die Firma voller Inbrunst zu verteidigen. Kritiker können dann sagen: guckt euch die ganzen Fehler bei den Landungen an. Schaut auch die ganzen Verschiebungen an.  SpX KANN es einfach nicht!


Warum die Heavy allerdings so lange braucht finde ich so langsam aber auch unverständlich. Ich hätte gedacht nach der V1.2 Implementierung könnte(und sollte) es direkt los gehen..  :/

Da ist mal wieder einer übers Testgelände in McGregor geflogen.
http://pictures.jtbuice.com/SpaceX-2/McGregor-Flyover-1-30-2016/

Zitat

liegt die Wahrscheinlichkeit für ein fehlstartfreies Startjahr bei angenommenen 10 Starts bei nur etwa 60% (bei angenommener Zuverlässigkeit von 95%)

? Meine Mathekenntnisse sagen da 75% voraus.

Ich komme auf 60%...

Meine Rechnung:  95% ^10 = 59,87%

Man kann aber nicht von 95% Zuverlässigkeit ausgehen, auch wenn diese Zahl jetzt quasi praktisch erwiesen ist, aber 21 Starts sind zu wenig für eine relevante Statistik. Es ist auch die Ursache des einen Fehlstarts bekannt und behoben und mit dem einhergehenden gründlichen Review (Der ist auch der Grund warum der RTF sich so lang hingezogen hat, das konkrete Problem mit den Streben was die Ursache war wurde deutlich schneller gefunden und abgestellt) der Falcon 9 und der Lernkurve die mit jedem Start steigt davon auszugehen dass in Zukunft ein Fehlstart deutlich unwahrscheinlicher wird.

Da ist mal wieder einer übers Testgelände in McGregor geflogen.
http://pictures.jtbuice.com/SpaceX-2/McGregor-Flyover-1-30-2016/

Das interessanteste ist das Bild vom Raptor-Prüfstand im Bau.

Also... Die Zahl ist natürlich weder praktisch bewiesen noch signifikant. Sie ist schlicht das was ich versuchte mit meinem vorigen Post auszudrücken: Normalität. Anzunehmen, die Zahl wäre höher ist aus meiner Sicht Optimismus. Ja, man hat ein Review gemacht. Und ja, es ist davon auszugehen, dass die Zuverlässigkeit mit der Zeit steigt. Aber die Realität sieht eben anders aus. Man kann auch durch ein Review nicht alle potenziellen Probleme beseitigen. Es ist vermutlich immerhin wahrscheinlicher, dass wir dieses Jahr keinen Fehlstart sehen, als dass es einen gibt. Und nächstes Jahr ist die Quote vermutlich noch besser. Also: Ich behaupte ja nicht dass die F9 total unzuverlässig ist. Aber die Wahrscheinlichkeit für Probleme irgendwelcher Art ist oft größer als viele annehmen. Dafür sind die aktuellen Verzögerungen das beste Beispiel.

Warum die Heavy allerdings so lange braucht finde ich so langsam aber auch unverständlich. Ich hätte gedacht nach der V1.2 Implementierung könnte(und sollte) es direkt los gehen..  :/

Blödes Beispiel, aber vielleicht is es ein ähnliches Problem wie bei Virgin, wo es Schwierigkeiten gab die bisherige Technik auf ein größeres Format zu übertragen.

Ich sage mit Absicht blödes Beispiel, weil im Falle Virgin es auf einen totalen Reinfall hinausgelaufen ist. Das glaube ich hier nicht.

Desweiteren ist die Heavy natürlich ein besonderes Prestigeprojekt, weil es der erste private Träger dieser Gewichtsklasse, für den es keinen staatlichen "Auftrag" gab. (Korrigiert mich hier bitte, wenn ich was falsches sage.)

Dementsprechend muß bei Erststart auch alles klappen. Tut es das nicht, ist es natürlich ein massiver PR-Schaden und es werden sicher vermehrt Stimmen laut werden, die meinen, dass sich SpaceX einfach überschätzt hat.

Und das werden sie sicher nicht riskieren wollen.

Das interessanteste ist das Bild vom Raptor-Prüfstand im Bau.

Weiß man den sicher, dass es der Raptor Teststand ist? Gut ich mein, was soll es sonst sein  . Aber ohne offizielle Aussage dazu kann man ja nicht 100% sicher sein.

Also: Ich behaupte ja nicht dass die F9 total unzuverlässig ist. Aber die Wahrscheinlichkeit für Probleme irgendwelcher Art ist oft größer als viele annehmen. Dafür sind die aktuellen Verzögerungen das beste Beispiel.

Full Ack. Selbst wenn die Hardware perfekt wäre, die Software kann auch spinnen. So wie bei der Ariane 5 damals. Es gibt also immer wieder etwas neues, wo man sagen kann "Hey, sowas darf doch nicht passieren". Aber es passiert halt doch.

Aber: 95% nach 20 Starts ist perfekt. Das haben andere nicht geschafft.

Selbst wenn die Hardware perfekt wäre, die Software kann auch spinnen. So wie bei der Ariane 5 damals. Es gibt also immer wieder etwas neues, wo man sagen kann "Hey, sowas darf doch nicht passieren". Aber es passiert halt doch.

Nur zur Klarstellung: 
Bei Ariane 5 Flug 501 hat die Software genau das gemacht was sie sollte. Als die primären Programmierung unverständliche Messdaten bekam wurden diese ignoriert und die sekundäre Programmierung weiter benutzt. Dies war so vorgesehen worden für en Fall daß ein Sensor ausfällt und unsinnige Messwerte liefert. Die primäre und die sekundäre Programmierung hatten ihre eigenen Sensoren. Bei beiden funktionierten die Sensoren einwandfrei und lieferten quasi zeitgleich die gleichen Werte.
Die Programme waren von der Ariane 4 übernommen worden, da sie dort sehr zuverlässig funktionierten. Was übersehen wurde war daß die Messungen waufgrund der deutlich steileren Flugbahn der Ariane 5 größere  Werte annehmen konnten als in der von Ariane 4 stammenden Software überhaupt darstellbar waren. Daher kam es zu einem Werte-Überlauf, der als unsinnige Werte interpretiert wurde, und zwar richtigerweise. Dieser Überlauf trat quasi zeitgleich bei beiden Steuerungsprogrammen auf, damit war die Redundnaz verloren gegangen.
Bei der Entwicklung ist dies nicht aufgefallen, da der dazu gehörige Tst der Sensoren mit der Software und mit vorhergesagten Flugbahndaten aus Kostengründen ausgelassen wurde.

Sprich, die Software hat keineswegs gesponnen. Und alle elektrischen Komponenten und Computer sind an Bord doppelt vorhanden um Redundanz zu haben. Das wird per Vorschrift so gefordert.

Siehe auch: http://www5.in.tum.de/~huckle/bugs.html
und http://www4.in.tum.de/lehre/seminare/ps/WS0203/desaster/Riedl-Arianne5-Ausarbeitung-27-11-02.pdf

Zitat von: GalacticTraveler am 31. Januar 2016, 22:47:23

Also: Ich behaupte ja nicht dass die F9 total unzuverlässig ist. Aber die Wahrscheinlichkeit für Probleme irgendwelcher Art ist oft größer als viele annehmen. Dafür sind die aktuellen Verzögerungen das beste Beispiel.

Full Ack. Selbst wenn die Hardware perfekt wäre, die Software kann auch spinnen. So wie bei der Ariane 5 damals. Es gibt also immer wieder etwas neues, wo man sagen kann "Hey, sowas darf doch nicht passieren". Aber es passiert halt doch.

Aber: 95% nach 20 Starts ist perfekt. Das haben andere nicht geschafft.

Ja, absolut! Das wollte ich auch nicht kritisieren.

Nur zur Klarstellung: 
Bei Ariane 5 Flug 501 hat die Software genau das gemacht was sie sollte. Als die primären Programmierung unverständliche Messdaten bekam wurden diese ignoriert und die sekundäre Programmierung weiter benutzt. Dies war so vorgesehen worden für en Fall daß ein Sensor ausfällt und unsinnige Messwerte liefert. Die primäre und die sekundäre Programmierung hatten ihre eigenen Sensoren. Bei beiden funktionierten die Sensoren einwandfrei und lieferten quasi zeitgleich die gleichen Werte.
Die Programme waren von der Ariane 4 übernommen worden, da sie dort sehr zuverlässig funktionierten. Was übersehen wurde war daß die Messungen waufgrund der deutlich steileren Flugbahn der Ariane 5 größere  Werte annehmen konnten als in der von Ariane 4 stammenden Software überhaupt darstellbar waren. Daher kam es zu einem Werte-Überlauf, der als unsinnige Werte interpretiert wurde, und zwar richtigerweise. Dieser Überlauf trat quasi zeitgleich bei beiden Steuerungsprogrammen auf, damit war die Redundnaz verloren gegangen.
Bei der Entwicklung ist dies nicht aufgefallen, da der dazu gehörige Tst der Sensoren mit der Software und mit vorhergesagten Flugbahndaten aus Kostengründen ausgelassen wurde.

Sprich, die Software hat keineswegs gesponnen. Und alle elektrischen Komponenten und Computer sind an Bord doppelt vorhanden um Redundanz zu haben. Das wird per Vorschrift so gefordert.

Hm, ich als Softwareentwickler sehe das durchaus als Softwarefehler. Wenn der Wertebereich einer Variable nicht ausreicht um das Gewünschte zu tun, dann hat der Entwickler falsch programmiert bzw. das Interface mit dem Sensor falsch implementiert und hinterher dann auch nicht ordentlich getestet. Und Grenzwerttests sind essentiell. Aber gut, dass ist ja schon über 20 Jahre her.

Zitat von: proton01 am 31. Januar 2016, 23:26:18

Nur zur Klarstellung: 
Bei Ariane 5 Flug 501 hat die Software genau das gemacht was sie sollte. [...]

Sprich, die Software hat keineswegs gesponnen. Und alle elektrischen Komponenten und Computer sind an Bord doppelt vorhanden um Redundanz zu haben. Das wird per Vorschrift so gefordert.

Hm, ich als Softwareentwickler sehe das durchaus als Softwarefehler. Wenn der Wertebereich einer Variable nicht ausreicht um das Gewünschte zu tun, dann hat der Entwickler falsch programmiert bzw. das Interface mit dem Sensor falsch implementiert und hinterher dann auch nicht ordentlich getestet. Und Grenzwerttests sind essentiell. Aber gut, dass ist ja schon über 20 Jahre her.

Sehe ich (ebenfalls SW-Entwickler) auch so. Man kann sich vielleicht noch streiten, was man unter "Software spinnt" genau versteht, also ob eine unzureichende Variable da mit drunter fällt oder ob es ein Fehler im Algorithmus sein muss... oder vielleicht ein Timingproblem in einem streng deterministischen Realtime-System... aber ein Softwarefehler ist das allemal.

Das System war richtig programmiert und hat perfekt funktioniert bei der Ariane 4.
Dämlich war nur den Softwareteil ungeprüft 1 zu 1 zu übernehmen.
Da aber die Ariane 5 Schneller startet kam es zum Overflow. So erinnere ich mich jedenfalls.

Also Programm spann wegen Faulheit der Programmierer der Ariane 5.

Zitat von: tralf am 01. Februar 2016, 09:29:48

Zitat von: proton01 am 31. Januar 2016, 23:26:18

Nur zur Klarstellung: 
Bei Ariane 5 Flug 501 hat die Software genau das gemacht was sie sollte. [...]

Sprich, die Software hat keineswegs gesponnen. Und alle elektrischen Komponenten und Computer sind an Bord doppelt vorhanden um Redundanz zu haben. Das wird per Vorschrift so gefordert.

Hm, ich als Softwareentwickler sehe das durchaus als Softwarefehler. Wenn der Wertebereich einer Variable nicht ausreicht um das Gewünschte zu tun, dann hat der Entwickler falsch programmiert bzw. das Interface mit dem Sensor falsch implementiert und hinterher dann auch nicht ordentlich getestet. Und Grenzwerttests sind essentiell. Aber gut, dass ist ja schon über 20 Jahre her.

Sehe ich (ebenfalls SW-Entwickler) auch so. Man kann sich vielleicht noch streiten, was man unter "Software spinnt" genau versteht, also ob eine unzureichende Variable da mit drunter fällt oder ob es ein Fehler im Algorithmus sein muss... oder vielleicht ein Timingproblem in einem streng deterministischen Realtime-System... aber ein Softwarefehler ist das allemal.

Die Software hat doch genau das gemacht wie sie programmiert war, nur hat sie in einer nicht vorhergesehenen Situation so reagiert, wie es nicht vorhergesehen war. Und dieser Fall war vorher nicht getestet worden. Sprich, die Software wurde außerhalb ihres Definitionsbereiches betrieben. Aber es war in dem Sinne kein Software bug. Das wäre gewesen wenn die Software auf richtigen Input falsch reagiert hätte. Die hat aber auf falschen Input richtig reagiert.
Ich stimme absolut zu das Grenzwerttests nötig sind, nut hat keiner den Grenzwert für die Tests richtig definiert.

Kleine Korrektur am Rande:  Die Flugbahn war nicht steiler sondern flacher als bei Ariane 4, also mit schnellerer Umlenkung in die Horizontale. Dadurch überschritt die Horizontalgeschwindigkeit den Wertebereich (und der wurde erst bei der Umwandlung der Real-Zahl in einen Integer überschritten)

Korrekt proton01:

die Software wurde außerhalb ihres Definitionsbereiches betrieben

Das ist kein Bug, jedoch hätte die Abteilung, welche für die Wartung des Codes zuständig ist auf die Barrikaden gehen müssen, als entschieden wurde Teile des Ariane 4 Codes für die Ariane 5 einzusetzen ohne umfangreich erneut zu testen.

Zumindest eine dicke Mail / Hauspost  muss sich im Laden finden lassen, wo vor den Risiken gewarnt wurde, sonst hat jemand seinen Job nicht gemacht.

Das die Risiken nachher vom Management wegdefiniert wurden ist eine andere Sache und sollte entsprechende Konsequenzen gehabt haben...

Viele Grüße,

Klaus

Wenn man dem Buschfunk auf reddit Glauben schenken mag, scheint auch das März-Datum eventuell nicht zu halten zu sein. Zudem kursiert wohl ein RTF-Datum, das erst deutlich später im Lauf des Jahre liegt. So langsam kommt doch irgendwie ein ungutes Gefühl auf. Zum einen natürlich auf Grund der Verzögerung an sich, zum anderen weil man von SpaceX offiziell so garnichts dazu hört. Noch nicht einmal SES als Kunden wurde ein Startdatum mitgeteilt.

Zunächst ist das eines der Probleme die sehr typisch für die Softwareentwicklung ist, man hat Software geschrieben die für eine Zielhardware optimiert war, z.B. 16Bit Code,
oder man hat Datentypen verwendet der z.B. mit 16 Bit locker bei der A4 auskam und nie daran gedacht das jemand nach der eigenen Pensionierung auf die (dumme) Idee kommt dies im Nachfolger wiederzuverwenden.
Ich kenne kaum einen alten Hasen (wie mich), dem sowas zumindest im eigenen Team schon passiert ist.
Das Problem ist hierbei aber ein anderes und das ist wirklich gravierend, man hat das Sensorinterface nicht sauber von der Weitervergabe getrennt.
Die Lösung wäre sowohl im Softwareinterface das diesen Wert verarbeitet, wie im nachfolgenden Application-Model möglich gewesen.
Eigentlich wurde geschlampt, vermutlich bei der Applikation und das war auch schon bei der A4 ein Fehler nur war der hier ohne Auswirkung.
Bei C# hat man dafür zurecht, getter und setter was es einfacher macht das sauber zu implementieren.
16Bit auf der Hardwareseite sollte heute auch Obsolet sein.

Leider ist die Software Entwicklung oft ein saumäßig HARTes Geschäft und das wird wohl kaum besser werden.

Zurück zu SpaceX, wir wissen zumindest von einem Softwarefehler der bei SpaceX zu einem Absturz geführt hat, der Ablauf der Stufentrennung bei der F1 war fehlerhaft.

OT, weil anderes Unternehmen, aber Lehrstück, das mit der 501:

Ereigniskette so wie ich das sehe:

SW-Teil, der nach dem Abheben nicht mehr benötigt wird, läuft noch nach dem Start, und liefert Werte.

Irgendwann halten beide Rechner des Inertial-Systems an, als bei der Variablen-Konvertierung eines Werts, der in Zusammenhang mit der Horizontalgeschwindigkeit stand, Ausnahmefehler auftreten.

Der Wert hatte beim Flug der A5 den bei der A4 flugmäßig möglichen Wertebereich verlassen.

Rechner 2 hört dabei rund 72 Millisekunden vor Rechner 1 auf, vom Bordrechner korrekt interpretierbare Flugdaten zu liefern.

Beide Rechner des Inertial-Systems liefern Diagnose-Daten.

Erst erfolgte Anhalten von Backup-Intertial-Rechner 2. Auf Inertial-Rechner 1, den der Bordcomputer in dem Moment aktiv nutzt, ist es die selbe Software, die den selben Fehler liefert. Gleiche Fehlerbehandlung: Anhalten des Rechners.

Bordcomputer schaltet wie vorgesehen auf Versorgung durch Daten von Inertial-Rechner 2. Der liefert aber keine für den Bordcomputer im Flug sinnvoll nutzbare Daten.

Umschaltung auf Inertial-Rechner 1 geht nicht, weil der steht. Bordcomputer schaut wieder auf den Bus und "sieht" Daten.

Bordcomputer "liest" Diagnose-Daten vom Rechner 2 des Inertial-Systems.

Ab Flugsekunde 30 keine gültigen Lenk- und Lagedaten.

Der Bordcomputer hält die Daten für Flugdaten und lenkt Düsen der Booster und des Vulcain entsprechend - und voll - aus.

Fairing- und Nutzlasttrennung werden sensormäßig erfasst.

Booster lösen sich, weil Raketen gemeinhin nicht um die Ecke fliegen können ... das Flugabbruchsystem wird aktiv.

Gruß  Pirx

... Das die Risiken nachher vom Management weg definiert wurden ist eine andere Sache und sollte entsprechende Konsequenzen gehabt haben...

Ja vermutlich hat man den Softwareentwickler in die Wüste geschickt 
zumindest ist dass die übliche Reaktion.

Zunächst ist das eines der Probleme die sehr typisch für die Softwareentwicklung ist, man hat Software geschrieben die für eine Zielhardware optimiert war, z.B. 16Bit Code,
oder man hat Datentypen verwendet der z.B. mit 16 Bit locker bei der A4 auskam und nie daran gedacht das jemand nach der eigenen Pensionierung auf die (dumme) Idee kommt dies im Nachfolger wiederzuverwenden.
Ich kenne kaum einen alten Hasen (wie mich), dem sowas zumindest im eigenen Team schon passiert ist.
Das Problem ist hierbei aber ein anderes und das ist wirklich gravierend, man hat das Sensorinterface nicht sauber von der Weitervergabe getrennt.
Die Lösung wäre sowohl im Softwareinterface das diesen Wert verarbeitet, wie im nachfolgenden Application-Model möglich gewesen.
Eigentlich wurde geschlampt, vermutlich bei der Applikation und das war auch schon bei der A4 ein Fehler nur war der hier ohne Auswirkung.
Bei C# hat man dafür zurecht, getter und setter was es einfacher macht das sauber zu implementieren.
16Bit auf der Hardwareseite sollte heute auch Obsolet sein.

Weil solche Fehler passieren können wird sowas normalerweise getestet. Man hat entschieden um Geld zu sparen diese Tests nur teilweise durchzuführen, da das ganze System ja bereits bei vielen A4 Flügen erfolgreich funktioniert hat und dadurch flug-qualifiziert war.

Wenn man dem Buschfunk auf reddit Glauben schenken mag, scheint auch das März-Datum eventuell nicht zu halten zu sein. Zudem kursiert wohl ein RTF-Datum, das erst deutlich später im Lauf des Jahre liegt. So langsam kommt doch irgendwie ein ungutes Gefühl auf. Zum einen natürlich auf Grund der Verzögerung an sich, zum anderen weil man von SpaceX offiziell so garnichts dazu hört. Noch nicht einmal SES als Kunden wurde ein Startdatum mitgeteilt.

Gibt es eigentlich irgendeine seriöse Quelle, ob das nun nur den SES-Flug betrifft? So wie es derzeit aussieht scheint es ja doch eher wieder eine komplette Flugpause zu geben. Und wenn man den unbestätigten Aussagen Glauben schenken darf, möglicherweise mehrere Monate (?)...