Starliner faced “catastrophic” failure before software bug found
1–10 of 64 posts
Re: Starliner faced “catastrophic” failure before software bug found
#2> According to the source, Boeing patched a software code error just two hours before the vehicle reentered Earth's atmosphere. Had the error not been caught, the source said, proper thrusters would not open during the reentry process, and the vehicle would have been lost.
Uh, that's extremely concerning for a CREWED capsule.
Re: Starliner faced “catastrophic” failure before software bug found
#3> According to the source, Boeing patched a software code error just two hours before the vehicle reentered Earth's atmosphere. Had the error not been caught, the source said, proper thrusters would not open during the reentry process, and the vehicle would have been lost. Uh, that's extremely concerning for a CREWED capsule.
Doesn't that depend on the testing schedule?
If the schedule called for simulations to be run in parallel with the live test, then it's an expected outcome. It should be _expected_ that every test will find a problem. Since this was uncrewed, there was no risk (other than to the uncompleted tests possibly requiring a second flight) to running them in parallel and porting across fixes for any problems that were found.
It was a schedule compression attempt with a cost of second test flight risk if it failed.
Re: Starliner faced “catastrophic” failure before software bug found
#4> According to the source, Boeing patched a software code error just two hours before the vehicle reentered Earth's atmosphere. Had the error not been caught, the source said, proper thrusters would not open during the reentry process, and the vehicle would have been lost. Uh, that's extremely concerning for a CREWED capsule.
Doesn't that depend on the testing schedule? If the schedule called for simulations to be run in parallel with the live test, then it's an expected outcome. It should be _expected_ that every test will find a problem. Since this was uncrewed, there was no risk (other than to the uncompleted tests possibly requiring a second flight) to running them in parallel and porting across fixes for any problems that were found.…
Boeing took the "we'll do very rigorous engineering up front and prove everything on paper" approach, where SpaceX took the "we'll prove it works by actually launching it" approach (which isn't to say SpaceX isn't operating with engineering rigor).
In theory Boeing ran all their simulations over the past couple years, and this flight should have just been a formality. As it turns out, Boeing is running into a lot of issues when they actually test their hardware.
Re: Starliner faced “catastrophic” failure before software bug found
#5> According to the source, Boeing patched a software code error just two hours before the vehicle reentered Earth's atmosphere. Had the error not been caught, the source said, proper thrusters would not open during the reentry process, and the vehicle would have been lost. Uh, that's extremely concerning for a CREWED capsule.
It depends on if the crew would have been able to control those thrusters themselves. Obviously you want the entire system to be autonomous enough that no crew interaction is required but things do happen and the crew needs to be able to act and fix the problem if capsule can't do it nor the ground. When the Starliner started a burn at the wrong time, a crew would have been able to stop it and prevent the loss of fuel. I wonder if this re-entry thruster issue was a result of the earlier thruster issue (or a result of the troubleshooting of it).
There are uncrewed test flights for a reason. You can't always simulate every possible failure mode. Things fail on the ground that wouldn't be possible during normal operation and vice versa.
Re: Starliner faced “catastrophic” failure before software bug found
#6> According to the source, Boeing patched a software code error just two hours before the vehicle reentered Earth's atmosphere. Had the error not been caught, the source said, proper thrusters would not open during the reentry process, and the vehicle would have been lost. Uh, that's extremely concerning for a CREWED capsule.
It depends on if the crew would have been able to control those thrusters themselves. Obviously you want the entire system to be autonomous enough that no crew interaction is required but things do happen and the crew needs to be able to act and fix the problem if capsule can't do it nor the ground. When the Starliner started a burn at the wrong time, a crew would have been able to stop it and prevent the loss of fue…
> You can't always simulate every possible failure mode. Things fail on the ground that wouldn't be possible during normal operation and vice versa.
This should be concerning, then:
https://spaceflightnow.com/2019/11/04/boeing-starliner-pad-a...
> “Boeing is not going to do an in-flight abort test,” said Jon Cowart, deputy manager of the mission management office for NASA’s commercial crew program, before the pad abort test. “They’re just going to do the ground one. They think that they can get enough data and then extrapolate that out, with good analytical techniques that we’ve endorsed. They will go and do it in that particular way, versus SpaceX, which is going to do both.
Re: Starliner faced “catastrophic” failure before software bug found
#7So we know there were catastrophic bugs in the 737 Max, they've found additional bugs that haven't been catastrophic yet and now we hear that the Starliner also has software bugs. I'm going to order a copy of "The Mythical Man-Month" for Boeing ... they need to get way back to the basics.
(Where's Margaret Hamilton when you need here?
Re: Starliner faced “catastrophic” failure before software bug found
#8"Given the potential for systemic issues at Boeing, I would also note that NASA has decided to proceed with an organizational safety assessment with Boeing as they previously conducted with SpaceX"
Re: Starliner faced “catastrophic” failure before software bug found
#9Earlier quoted context omitted.
Doesn't that depend on the testing schedule? If the schedule called for simulations to be run in parallel with the live test, then it's an expected outcome. It should be _expected_ that every test will find a problem. Since this was uncrewed, there was no risk (other than to the uncompleted tests possibly requiring a second flight) to running them in parallel and porting across fixes for any problems that were found.…
Boeing took the "we'll do very rigorous engineering up front and prove everything on paper" approach, where SpaceX took the "we'll prove it works by actually launching it" approach (which isn't to say SpaceX isn't operating with engineering rigor). In theory Boeing ran all their simulations over the past couple years, and this flight should have just been a formality. As it turns out, Boeing is running into a lot of…
The problem with simulations and paperwork with high tech engineering is you need enough competent, independent reviewers that understand how the whole system works together.
That sort of thing is rarely organized. So we test it instead.
Re: Starliner faced “catastrophic” failure before software bug found
#10> According to the source, Boeing patched a software code error just two hours before the vehicle reentered Earth's atmosphere. Had the error not been caught, the source said, proper thrusters would not open during the reentry process, and the vehicle would have been lost. Uh, that's extremely concerning for a CREWED capsule.
It depends on if the crew would have been able to control those thrusters themselves. Obviously you want the entire system to be autonomous enough that no crew interaction is required but things do happen and the crew needs to be able to act and fix the problem if capsule can't do it nor the ground. When the Starliner started a burn at the wrong time, a crew would have been able to stop it and prevent the loss of fue…
The "crew would fix it" argument is a very very bad one. Many spacecraft maneuvers need to be very precise in both pointing and direction. Something computers are very good at, humans less so.
Also, the crew would first have to know something wrong is going on either based on activity happening that was not planned previously or unexpected data on flight instruments. But guess what is driving those instruments in a modern crewed space vehicle - also computers and software. That software might be faulty as well or even displaying the same wrong data the automated control software is acting upon.
In such a case the crew might not even notice something is wrong until the craft is on a wrong and potentially even unrecoverable trajectory once ground radar notices something is wrong.
As for the crew taking over thtuster control during a reentry - sorry, if you space capsule is trying to kill you that hard, something is wrong.
At that point in time, the capsule is hurtling through the atmosphere protected only by its from ablative shield. The thrusters are used to shift the center of gravity a bit, to give the capsule some lift, offsetting some of the g forces due to the rapid deceleration. This is called "lifting reentry".
This all needs to be very very precise & based on up to date sensor data, as the whole capsule is not covered by the heat shield and if you change the center of gravity too much, you might expose unprotected parts of it to the hot plasma.
This is not really a good environment for a crew member to take over - not only are you under couple g's of deceleration but any mistake will kill you all. But hey, no pressure!
BTW, the Soyuz capsule has a backup mode available in case it's reentry control thrusters fail, where the capsule just follows an unguided ballistic reentry. This is much harder on the crew (due to no lift compensating for some of the deceleration), but survivable & has been used a couple times during various emergencies.