-
#800
by
mlindner
on 07 Feb, 2020 03:50
-
February 07, 2020
MEDIA ADVISORY M20-023
NASA, Boeing to Provide Update on Starliner Orbital Flight Test Reviews
NASA and Boeing will host a media teleconference at 3:30 p.m. EST Friday, Feb. 7, to discuss the status of the joint independent review team investigation into the primary issues detected during the company’s uncrewed Orbital Flight Test in December as part of NASA’s Commercial Crew Program.
Participants in the briefing will be:
NASA Administrator Jim Bridenstine
Jim Chilton, senior vice president, Boeing Space and Launch
Douglas Loverro, associate administrator, NASA’s Human Exploration and Operations Mission Directorate
Kathy Lueders, program manager, NASA’s Commercial Crew Program
John Mulholland, vice president and program manager, Boeing’s CST-100 Starliner Program
Audio of the teleconference will stream live online at:
https://www.nasa.gov/live
To participate in the teleconference, media must contact Kathryn Hambleton at [email protected] by 3 p.m. Friday for the dial-in information.
So Boeing is going to try again attempts at glossing over the issues like they did at their last press conference? I guess they're not doing another direct media call with the engineers involved that previously illustrated all the real problems.
-
#801
by
meekGee
on 07 Feb, 2020 04:42
-
From near the end of the ArsTechnica article
The safety panel also recommended that NASA conduct "an even broader" assessment of Boeing's Systems Engineering and Integration processes. Only after these assessments, Hill said, should NASA determine whether the Starliner spacecraft will conduct a second, uncrewed flight test into orbit before astronauts fly on board.
So “an even broader” assessment of Boeing’s SI&T process before NASA decides if they should refly the OFT?
If NASA accepts that recommendation it has to significant impact the prospective date for CFT.
What are the chances?
It feels like a collective "we've had enough of your BS" storm is brewing.
All the inflated preposterous charges, all the hubris, all the lack of progress, all the spoiled child behavior.
This may not be limited to Boeing... They may be the most egregious right now, but they are hardly in a class of their own...
They may have just ruined it for their peers as well.
Good.
-
#802
by
JonathanD
on 07 Feb, 2020 05:58
-
Hopefully we will hear some more during the teleconference tomorrow, but at first blush this seems like a pretty significant thing to omit from the initial post-flight news conference or even during live coverage. There seems to be 3 main possibilities:
1. NASA and Administrator Bridenstine were not fully aware of the extent of mid-flight software updates at the time of the post-flight press conference, which could mean a) Boeing didn't think it was significant enough to share, or b) Boeing deliberately withheld the information at that time.
2. NASA and Administrator Bridenstine were aware of the software update, but based upon the communications from Boeing were assured it was not a significant situation worth mentioning.
3. NASA and Administrator Bridenstine were aware of the software update and the potentially serious events that could have happened had it not been caught on the fly, and still chose not to mention it in the post-flight news conference.
Scenarios 1. and 2. are situations where, ostensibly, NASA and Administrator Bridenstine could have been acting in good faith and simply did not have sufficient information to make a statement about that portion of the mission directly following its completion, especially in light of the focus on the MET issue.
Scenario 3. would be a bit more concerning, because it makes some of the "a lot of things went right" cheer-leading seem a whole lot less appropriate.
At this point we have a spacecraft that was unable to achieve its orbital insertion due to an MET issue, which cascaded into erratic firing of control thrusters that pushed them beyond specifications (concerning enough on its own), and then had a separate and unrelated software flaw that could have resulted in loss of vehicle had it not been corrected on the fly mid-mission. Yikes. I had really been trying to give the Boeing team the benefit of the doubt up until this point, but they are losing me in a hurry.
I'm getting the impression some of the space press feel a bit lied-to as well. It will be interesting to not only hear what facts are shared tomorrow, but how much of the call comes off as damage control as opposed to a transparent accounting of who knew what and when.
-
#803
by
Rocket Science
on 07 Feb, 2020 06:36
-
Re-reading the OIG report is interesting in light of the current circumstances...
-
#804
by
Stan-1967
on 07 Feb, 2020 07:02
-
I'm now expecting ULA to start casually mentioning & emphasizing what an important role their Lockheed Martin heritage plays in their corporate values, culture, & business practices whenever any media opportunity arise.
-
#805
by
avollhar
on 07 Feb, 2020 07:15
-
What is even more disturbing for me:
how can such a 'critical' flaw remain unseen during months (maybe years) of preflight testing and the patch being developed, tested and uploaded within 48 hours (probably much less)?
Either the patch wasn't tested very thoroughly (you have to be sure not to make things worse!) or it is so simple that it did not require extensive testing.. which also says something about the level of detail for the preflight testing.
Sorry, but when reading this on the same page as the 737max situation this tells a lot about the company culture in Boeing (not necessarily the software developers as there are hopefully separate teams).
-
#806
by
ugordan
on 07 Feb, 2020 08:21
-
a valve mapping software issue, which was diagnosed and fixed in flight.
So if I'm parsing this correctly, they messed up which valves the software *thinks* it's controlling with wiring to wrong *actual* valves?
If so, wow, just wow. How can something like this pass ground testing?
Earlier, I was kinda puzzled why "just" the MET issue would necessitate a reflight of OFT before putting crew on from an ISS safety standpoint, but evidently the Starliner software raised one too many red flags. Between this and the pad abort parachute issue, I'm also in the OFT needs to refly camp now.
-
#807
by
jerwah
on 07 Feb, 2020 08:39
-
a valve mapping software issue, which was diagnosed and fixed in flight.
So if I'm parsing this correctly, they messed up which valves the software *thinks* it's controlling with wiring to wrong *actual* valves?
That's how I read it as well. It seems reasonable to assume that the MET issue is the only reason they found this bug too. As I understand the MET issue, it caused rapid firing of the thrusters at the wrong time.
I can see a path to finding this bug where someone was very confused as to why the system tried to fire thruster A to cause some m/s change in one axis, but instead got the opposite result. so now the computer thinks it needs to fire thruster A again, even longer, feedback loop ensues, bad things happen.
-
#808
by
ugordan
on 07 Feb, 2020 08:44
-
a valve mapping software issue, which was diagnosed and fixed in flight.
So if I'm parsing this correctly, they messed up which valves the software *thinks* it's controlling with wiring to wrong *actual* valves?
That's how I read it as well. It seems reasonable to assume that the MET issue is the only reason they found this bug too. As I understand the MET issue, it caused rapid firing of the thrusters at the wrong time.
I can see a path to finding this bug where someone was very confused as to why the system tried to fire thruster A to cause some m/s change in one axis, but instead got the opposite result. so now the computer thinks it needs to fire thruster A again, even longer, feedback loop ensues, bad things happen.
But reportedly this second issue was identified in *ground* testing while actual hardware was in orbit. What kind of ground testing did they do beforehand, then, and why was it not identified *before* flight?
So many questions...
-
#809
by
woods170
on 07 Feb, 2020 09:01
-
a valve mapping software issue, which was diagnosed and fixed in flight.
So if I'm parsing this correctly, they messed up which valves the software *thinks* it's controlling with wiring to wrong *actual* valves?
That's how I read it as well. It seems reasonable to assume that the MET issue is the only reason they found this bug too. As I understand the MET issue, it caused rapid firing of the thrusters at the wrong time.
I can see a path to finding this bug where someone was very confused as to why the system tried to fire thruster A to cause some m/s change in one axis, but instead got the opposite result. so now the computer thinks it needs to fire thruster A again, even longer, feedback loop ensues, bad things happen.
But reportedly this second issue was identified in *ground* testing while actual hardware was in orbit. What kind of ground testing did they do beforehand, then, and why was it not identified *before* flight?
So many questions...
Valve mapping relates to what valve must be operated for how long to provide a certain amount of thrust along a certain axis. Get this wrong and you fire the wrong thrusters, or you may fire the right thrusters too long or too short. All of which are not good obviously.
-
#810
by
ugordan
on 07 Feb, 2020 09:03
-
Valve mapping relates to what valve must be operated for how long to provide a certain amount of thrust along a certain axis. Get this wrong and you fire the wrong thrusters, or you may fire the right thrusters too long or too short. All of which are not good obviously.
So was this actually uncovered after the simulated ISS approach where a thruster "underperformance" was observed, or something to that effect?
-
#811
by
woods170
on 07 Feb, 2020 09:06
-
What is even more disturbing for me:
how can such a 'critical' flaw remain unseen during months (maybe years) of preflight testing and the patch being developed, tested and uploaded within 48 hours (probably much less)?
Yes. This.
The very same question applies to the original MET screw-up.
Speaking as a software quality control engineer I wonder how Boeing tested the Starliner software. What errors in test design, test setup, test execution and test evaluation did they make?
WHY was this missed? WHY was the other thing missed?
-
#812
by
meekGee
on 07 Feb, 2020 12:30
-
I hope NASA revisits the decision to have only a simulated IFA. I always thought it was a dumb idea, and all the counter-arguments were based on Boeing's supposed proficiency in exactly what they are failing at right now.
-
#813
by
Svetoslav
on 07 Feb, 2020 12:32
-
I hope NASA revisits the decision to have only a simulated IFA. I always thought it was a dumb idea, and all the counter-arguments were based on Boeing's supposed proficiency in exactly what they are failing at right now.
I think the main problem with Starliner IFA is that they'll have to waste a whole new Atlas V rocket. Other crewed spacecraft either have dedicated rockets for in-flight abort (like Orion), or use recycled rockets (like Crew Dragon)
-
#814
by
meekGee
on 07 Feb, 2020 12:40
-
I hope NASA revisits the decision to have only a simulated IFA. I always thought it was a dumb idea, and all the counter-arguments were based on Boeing's supposed proficiency in exactly what they are failing at right now.
I think the main problem with Starliner IFA is that they'll have to waste a whole new Atlas V rocket. Other crewed spacecraft either have dedicated rockets for in-flight abort (like Orion), or use recycled rockets (like Crew Dragon)
I don't see the problem. An IFA teat should cost a rocket. SpaceX's rocket still had life in it. They'll have to build another. Same for the S2.
What you're saying is that Boeing's "solution" is cheaper. I'll be sure to let the astronauts know.
People in the industry that proposed this should do some soul searching.
-
#815
by
Vettedrmr
on 07 Feb, 2020 13:16
-
WHY was this missed? WHY was the other thing missed?
And the really deafening part of your question: "What else has been missed?"
-
#816
by
Rebel44
on 07 Feb, 2020 13:48
-
I hope NASA revisits the decision to have only a simulated IFA. I always thought it was a dumb idea, and all the counter-arguments were based on Boeing's supposed proficiency in exactly what they are failing at right now.
I think the main problem with Starliner IFA is that they'll have to waste a whole new Atlas V rocket. Other crewed spacecraft either have dedicated rockets for in-flight abort (like Orion), or use recycled rockets (like Crew Dragon)
Considering how much more Boeing is being paid compared to SpaceX, a "free" (for taxpayers) IFA test seems appropriate considering how screwed up Boeing software appears to be.
I would count ULA having to build an extra Atlas V as Boeing's problem.
-
#817
by
anof
on 07 Feb, 2020 14:08
-
I hope NASA revisits the decision to have only a simulated IFA. I always thought it was a dumb idea, and all the counter-arguments were based on Boeing's supposed proficiency in exactly what they are failing at right now.
I think the main problem with Starliner IFA is that they'll have to waste a whole new Atlas V rocket. Other crewed spacecraft either have dedicated rockets for in-flight abort (like Orion), or use recycled rockets (like Crew Dragon)
Most previous IFA tests except for Crew Dragon have not used the rocket they would normally launch on. They usually would use special solid rockets that were most likely cheaper.
-
#818
by
meekGee
on 07 Feb, 2020 14:22
-
I hope NASA revisits the decision to have only a simulated IFA. I always thought it was a dumb idea, and all the counter-arguments were based on Boeing's supposed proficiency in exactly what they are failing at right now.
I think the main problem with Starliner IFA is that they'll have to waste a whole new Atlas V rocket. Other crewed spacecraft either have dedicated rockets for in-flight abort (like Orion), or use recycled rockets (like Crew Dragon)
Most previous IFA tests except for Crew Dragon have not used the rocket they would normally launch on. They usually would use special solid rockets that were most likely cheaper.
"most" has to date back to Apollo or earlier - otherwise which examples are we discussing?
The availability of Atlas can't be compared to that of Saturn V. Starliner is supposed to be a commercial carrier to the ISS, fly relatively often, and on a "commodity" rocket.
Even with Apollo, they chose to do as much as possible. With Starliner, Boeing bent over backwards to do as little as possible.
-
#819
by
anof
on 07 Feb, 2020 14:48
-
I hope NASA revisits the decision to have only a simulated IFA. I always thought it was a dumb idea, and all the counter-arguments were based on Boeing's supposed proficiency in exactly what they are failing at right now.
I think the main problem with Starliner IFA is that they'll have to waste a whole new Atlas V rocket. Other crewed spacecraft either have dedicated rockets for in-flight abort (like Orion), or use recycled rockets (like Crew Dragon)
Most previous IFA tests except for Crew Dragon have not used the rocket they would normally launch on. They usually would use special solid rockets that were most likely cheaper.
"most" has to date back to Apollo or earlier - otherwise which examples are we discussing?
The availability of Atlas can't be compared to that of Saturn V. Starliner is supposed to be a commercial carrier to the ISS, fly relatively often, and on a "commodity" rocket.
Even with Apollo, they chose to do as much as possible. With Starliner, Boeing bent over backwards to do as little as possible.
From what I remember all previous In-Flight Abort tests including Mercury and Apollo did not use their normal launcher. They used the Little Joe solid rockets. Only SpaceX has used a full orbital rocket. Boeing doesn't need to purchase an Atlas for a Starliner IFA. Orion used a modified Peacekeeper ICBM last year.