Boeing CST-100 / Starliner

Der neue Fehler wird ja als "valve mapping issue" (falsche Zuordnung der Ventile) in der Software beschrieben. Ich vermute hier fast, dass dann beide Fehlermoden zusammenhängen:
- der falsche Timer hat ungeplante Zündvorgänge nach dem Aussetzen ausgelöst
- die falsche "Triebwerkskonfiguration" (valve mapping issue) führt zum falschen Feuern, sobald man feuert.

Das hört sich alles überhaupt nicht gut an wenn man das so liest.
Klingt doch nach zumindest 2 größeren Fehlern, die sie genau analysieren müssen.

Ich bin wirklich gespannt wie hier jetzt die Marschroute sein wird. Sicher ist, dass der Starliner bemannt sicher nicht so schnell fleigen wird.
Ich bezweifle inzwischen, dass das 2020 noch passieren wird.

Weiß jemand, ob das das gesamte CCP beeinflussen könnte oder nur den Teil von Boeing?

Das hört sich alles überhaupt nicht gut an wenn man das so liest.
Klingt doch nach zumindest 2 größeren Fehlern, die sie genau analysieren müssen.

Ich bin wirklich gespannt wie hier jetzt die Marschroute sein wird. Sicher ist, dass der Starliner bemannt sicher nicht so schnell fleigen wird.
Ich bezweifle inzwischen, dass das 2020 noch passieren wird.

Weiß jemand, ob das das gesamte CCP beeinflussen könnte oder nur den Teil von Boeing?

Das Problem sind nicht primär die zwei Fehler. Die dürften relativ leicht zu beheben sein. Das Problem ist die gesamte Software-Entwicklung die diese Fehler und ihr durchschlüpfen durch alle Kontrollen ermöglicht hat. Zur Zeit sieht es so aus, daß NASA und wohl auch Boeing intern die Notwendigkeit sehen, die Software komplett von Grund auf neu zu validieren.

Die Frage ist, wenn bereits 2 Fehler in so kurzer Zeit durchschlüpfen konnte, wie konnte das Passieren? Hier gibt es mehrere Möglichkeiten, z.B.:

1) Gab es Kontrollen und keiner hat es bemerkt? Falls ja, warum?
2) Gab es keine Kontrollen? Falls, warum nicht?
3) Gab es Kontrollen, der Fehler wurde bemerkt und vertuscht? Falls ja, wer hat das angeordnet?

Und am Ende muss man sich die Frage stellen: Wie groß ist die Software, wie viele Fehler könnten noch vorhanden sein? Diese Frage kann man besser beantworten, wenn man erste Frage beantwortet hat.

Am Ende muss man sagen: Fehler können passieren und passieren auch. Wenn z.B. durch einen Fehler ein Teil einer Software nicht geprüft wurde und dort der Softwarebug lag, dann muss ich den Rest der Software nicht neu prüfen. Dann muss ich nur die ungeprüften Teile neu prüfen und herausfinden, warum ein Teil nicht geprüft wurde.

Gab es nicht ähnliche Fragen schon nach dem PAD-Abort Test am 4.11.2019 (3. Fallschirm)?

Gab es nicht ähnliche Fragen schon nach dem PAD-Abort Test am 4.11.2019 (3. Fallschirm)?

Ja, da hat Boeing argumentiert, bei dem unbemannten Test haben wir eben geschlampt, bei bemannten Flügen passen wir natürlich besser auf, kein Problem.

Ich sag dazu nur: 737 max. 

Vielleicht sind ja auch für einen zweiten Testflug wieder ein paar hundert Mio. $ von der NASA drin  .

Wenn dem so ist sollten sie jede Woche einen "bezahlten" testflug machen, das reicht dann sicher um die Verluste aus der 737 MAX auszugleichen.

Könnten hier bitte mal die ständigen Vergleiche mit SpaceX unterbleiben? Dafür gibt's schließlich einen eigenen Thread im SpaceX Bereich. Da könnt ihr lästern:
https://forum.raumfahrer.net/index.php?topic=16325.0

Zum Thema: NASA gibt zur Zeit eine Pressekonferenz zu den bislang ermittelten Fehlern, die beim OFT vom Starliner aufgetreten sind.

Es sind 3 schwere Probleme:

1. An error with the Mission Elapsed Timer (MET), which incorrectly polled time from the Atlas V booster nearly 11 hours prior to launch.

2. A software issue within the Service Module (SM) Disposal Sequence, which incorrectly translated the SM disposal sequence into the SM Integrated Propulsion Controller (IPC).

3. An Intermittent Space-to-Ground (S/G) forward link issue, which impeded the Flight Control team’s ability to command and control the vehicle.

Auf deutsch mit eigenen Ergänzungen:

1.Ein Problem mit dem Timer für die Zeit, die während des Fluges vergangen ist. Der Computer soll diese vom Träger in der Phase T-4 min bis T-0 übernehmen. Stattdessen fand der download bei T-11 h statt.

2. S/W Fehler innerhalb der Trennungssequenz Kapsel - Service Module. Wäre er nicht rechtzeitig während der Mission entdeckt worden, hätten sich beide Module nach der Trennung wieder treffen können.

3.ein wechselseitiger Fehler in der Funkverbindung Boden-Raumschiff, der verhinderte, daß die Bodenmannschaft zu Beginn den Starliner kontrollieren konnte.

Es wird in den nächsten Tagen sicher noch Berichte online gestellt, die auf Details eingehen.

Auf die Frage, wieviel Prozent der Flug-S/W überprüft und validiert werden muß, erwiderte Boeing: die komplette S/W.
Es wird hinzugefügt: die Starliner-S/W hat ungefähr 1 Mio. codes. 66% der S/W funktionierte einwandfrei, aber man überprüft trotzdem alles.

Soviel für den Moment.

Gruß
roger50

Könnten hier bitte mal die ständigen Vergleiche mit SpaceX unterbleiben? Dafür gibt's schließlich einen eigenen Thread im SpaceX Bereich....

Allerdings. Hier gelöscht.

Es wird hinzugefügt: die Starliner-S/W hat ungefähr 1 Mio. codes. 66% der S/W funktionierte einwandfrei, ...

Und die anderen 33%? Und damit sind sie zum Start angetreten? 

Gruß   Pirx

Zitat

Es wird hinzugefügt: die Starliner-S/W hat ungefähr 1 Mio. codes. 66% der S/W funktionierte einwandfrei, ...

Und die anderen 33%? Und damit sind sie zum Start angetreten? 

Gruß   Pirx

Ich habe das anders verstanden. Aufgrund des abgekürzten Fluges wurden nur 66% des Codes aufgerufen. Das hat funktioniert, bis auf die zwei Fehler, von denen der zweite korrigiert war, als der Programmabschnitt aufgerufen wurde.

Die übrigen 33% sind ungetestet, weil nicht genutzt.

Ich habe das anders verstanden. Aufgrund des abgekürzten Fluges wurden nur 66% des Codes aufgerufen. Das hat funktioniert, bis auf die zwei Fehler, von denen der zweite korrigiert war, als der Programmabschnitt aufgerufen wurde.

Die übrigen 33% sind ungetestet, weil nicht genutzt.

Man sollte das vielleicht der Klarheit zuliebe nicht "ungetestet" nennen.

Ich hab in die Softwareentwicklung von Boeing keine Einsicht, aber ich bin mir sicher, dass die eine Testabdeckung von 100% oder ganz, ganz nah dran an 100% haben, inklusive Branching, also nicht nur C0. Natürlich hat man das Problem, dass man vieles nur in simulierten Umgebungen testen kann, da Sensoren usw. bei einem Test keine echten Werte liefern können und man das Verhalten des Gesamtsystems nur möglichst gut nachbilden kann und der Software etwas "vorspielen" muss.

Wollte nur klarstellen, dass hier "ungetestet" als noch nicht im Realeinsatz getestet zu verstehen ist. 

33% ungetestet  liest sich für mich wie, Test nicht bestanden. Da man die fehlenden Teile nicht am Boden testen kann, heißt das für mich nochmals komplett testen.
Bei jedem normalen Vertrag muss der Auftragnehmer bei eigenverschulden die Kosten von einem zweiten Versuch selber tragen.

...
Wollte nur klarstellen, dass hier "ungetestet" als noch nicht im Realeinsatz getestet zu verstehen ist.

Also eigentlich können wir mit den Zahlen nicht viel anfangen? Genau zu wissen scheinen wir jetzt nur, dass etwas schief gegangen ist und dass man das Potential dazu offenbar übersehen hat.

Gruß   Pirx

Zitat von: MarsMCT am 08. Februar 2020, 00:00:07

Ich habe das anders verstanden. Aufgrund des abgekürzten Fluges wurden nur 66% des Codes aufgerufen. Das hat funktioniert, bis auf die zwei Fehler, von denen der zweite korrigiert war, als der Programmabschnitt aufgerufen wurde.

Die übrigen 33% sind ungetestet, weil nicht genutzt.

Man sollte das vielleicht der Klarheit zuliebe nicht "ungetestet" nennen.

Ich finde, viel klarer kann man es nicht ausdrücken. Den nächsten Satz habe ich aus genau dem Grund eingefügt. Ich schreibe das als Gegensatz zu 33% Fehler, was es nicht war.

Noch eine Einordnung was "ungetestet" hier wohl heißt:

• am Boden wird Boeing die Software in einem Simulator getestet haben, und das auch vollständig ... aber eben nur im Simulator,
• bei der Demonstrationsmission wird man aber auch gefordert haben, die Software im Orbit in einer Mission tatsächlich zu demonstrieren und ihre Funktion so zu validieren. So sind IOD-Missionen (In-Orbit-Demonstration) normalerweise charakterisiert/definiert. Da man die Mission nicht vollständig fliegen konnte, ist ein Teil der Softwarefunktionen somit noch nicht validiert.

Die aufgetretenen Probleme werden in einem SFN- Artikel noch einmal zusammengefasst.

https://www.nasaspaceflight.com/2020/02/boeing-nasa-admit-multiple-anomalies-starliner-mission/

Hiermal ein Artikel auf Golem.de

https://www.golem.de/news/nasa-boeing-umging-sicherheitsprozeduren-bei-starliner-2002-146558.html

bei dem unbemannten Testflug des Starliner's sind offensichtlich noch weitere Probleme aufgetreten. Und wieder war es die Software. Es wäre schon sehr verwunderlich, wenn Boeing ohne einen zweiten unbemannten Testflug weitermachen könnte.

https://www.teslarati.com/spacex-first-private-nasa-astronaut-launch-boeing-catastrophe/

Wenn ich mir die ganzen Softwarefehler ansehe und bedenke, dass der InFlight Abort nur simuliert wird, bekomme ich ein ungutes Gefühl in der Magengegend 

bei dem unbemannten Testflug des Starliner's sind offensichtlich noch weitere Probleme aufgetreten. Und wieder war es die Software. Es wäre schon sehr verwunderlich, wenn Boeing ohne einen zweiten unbemannten Testflug weitermachen könnte.

https://www.teslarati.com/spacex-first-private-nasa-astronaut-launch-boeing-catastrophe/

Damit hier keine Missverständnisse entstehen, es geht in dem Artikel um den zweiten Fehler, den wir seit vier Tagen diskutieren und nicht um einen dritten Fehler (was ich bei bei 1 Mio Codezeilen von Boeing mittlerweile durchaus auch noch für denkbar halte)

Ich glaube, niemand wird mir widersprechen, wenn ich sage, daß es KEINE einzige fehlerfreie Software gibt. Wer z.B. Windows verwendet, weiß, wovon ich spreche. Gab es nie, gibt es nicht, wird es nie geben. Erst recht nicht bei der heutigen Komplexität von S/W.

Das Stichwort ist natürlich "fehlertolerante" S/W, weshalb gerade bei kritischer S/W, die Menschenleben gefährden könnte, fast immer mehrere CPUs (bis zu 4) mit 2 unabhängigen S/Ws parallel arbeiten und Mehrheitsentscheidungen Fehler aufdecken. Ich habe keine Ahnung (wie keiner von uns) von der Rechnerstruktur in Starliner oder Dragon. Entscheidend ist aber der Punkt, daß Fehler bei Simulationen entdeckt werden sollten. Zumindest, wenn man genügend Simulationen von A-Z gefahren hat.

Leider habe ich etwas Erfahrung mit solchen Problemen gemacht, als aus diesem Grund ein Countdown meines Lieblingfahrzeugs abgebrochen werden mußte, weil Threshholds zu eng gesetzt waren.

Und an dieser Verifikation möglicher Fehler scheint es bei Starliner wirklich gehapert zu haben, da muß dringend nachgebessert werden. Und auch ich hoffe auf einen weiteren unbemannten Testflug, bevor Starliner Menschen befördern darf.

SpaceX scheint in dieser Beziehung eine bessere S/W als Boeing entwickelt zu haben. Aber: eine erfolgreiche erste Mission bedeutet nicht automatisch, daß auch die nächsten Missionen problemlos verlaufen werden. Es kann - und wird - immer irgendwann ein Fehler auftauchen.

Gruß
roger50

Das Software nicht fehlerfrei ist, ist sicher unbestritten. Aber wenn man sich mal den Artikel von Golem durchliest, wurde in meinen Augen echt geschlampt und nicht nur von Boeing.


Hier mal ein paar Beispiele:

"Bei der Entwicklung und den Tests der Software für das Raumschiff habe es "mehrfach Umgehungen der Sicherheitsprozeduren" gegeben, sagte Loverro. John Mulholland, Vizepräsident für das Commercial Crew Programm der Nasa"


"Erst auf hartnäckiges Nachfragen mehrerer Journalisten, die in Antennenproblemen mögliche Probleme beim Andocken an die internationale Raumstation ISS sahen, wurde der zunehmend resigniert wirkende Mulholland deutlicher. Demnach entstanden die Störungen nach der bisherigen Einschätzung durch unbeabsichtigt aufgefangene Signale von Mobilfunksendern auf der Erde, nicht durch Störsignale, die vom Raumschiff selbst erzeugt wurden. Die Relaissatelliten konnten deshalb nur dann mit dem Starliner kommunizieren, wenn er nicht über bewohntes Gebiet mit Mobilfunksendern flog."

Und das schlimmste:

"Loverro ergänzte, bei der Ursachenforschung sei festgestellt worden, dass die Fehler entstanden seien, weil dieser Prozess von den Boeing-Mitarbeitern an mehreren Stellen umgangen worden sei. Sie hätten an mehreren Stellen während des Prozesses auffallen sollen. Nur weil der Prozess an so vielen Stellen durchbrochen worden sei, müsse nun der gesamte Code eingehend überprüfend werden. Bis dahin sei noch viel zu tun. Erst danach werde über die Notwendigkeit eines neuen Testflugs entschieden."

Es geht nicht um die Verifikation möglicher Fehler. Es geht um das falsch-mappen von Ventilsteuerung. Im PRIMÄRPFAD!
Das ist ja gerade das kuriose: das es sich nicht um seltsame Fehler in obscuren Situationen handelt, sondern um Fehler im Standartverhalten der Kapsel.

Wäre der 1. Fehler nicht aufgetreten und hätte man daraufhin nicht noch die Software überprüft und diesen 2. Fehler gefunden+behoben wäre es wohl beim abkoppeln des SM zum Kontakt gekommen..
Da fragt man sich dann wirklich wie das durchschlüpfen konnte.