-
#1020
by
abaddon
on 09 Feb, 2020 01:14
-
According to Garrett Reisman, the SpaceX nickname for the CST-100 is the "POS 100"? He was on the Joe Rogan channel doing an interview.
That's disappointing if true, that's unprofessional (and not very creative).
If you think that was unprofessional than you really don't want to know Boeing's nickname for Crew Dragon.
Having a nickname internally isn’t the same as divulging it in a podcast.
After reading the actual quote, definitely not a big deal.
-
#1021
by
oldAtlas_Eguy
on 09 Feb, 2020 03:37
-
The reason I voted no for another flight to test software fixes is that actual flight only catches way outside the box bugs when way outside the box events happen. When that happens it is best to do an immediate abort and hope like ... the abort works.
The best method is to use hardware in the loop testing on the ground where you can run through every bad condition possibly thought of. A normal flight doesn't validate software. It only tests one execution path. You would need a few hundred or even several thousand flights to test just the major execution paths in a 1 million line set of software code.
What was discovered was Boeing did very poor job of realistic tests of its software.
Added:
I was the Chairman of the Atlas E,F and H launch vehicles Software Review Board. On the hook with my signature on every software change.
-
#1022
by
TrevorMonty
on 09 Feb, 2020 03:42
-
On plus side NASA can use Dragon2 for crew flights till Boeing proves the Starliner is safe. SpaceX won't have problem being sole supplier for next year or two.
-
#1023
by
Rocket Science
on 09 Feb, 2020 04:51
-
I as others voted for another OFT only after the entire program is reviewed, faults are caught and corrected, not simply another flight test. This pause is for the time to do a re-flight to demonstrate and earn credibility for both NASA and Boeing. The administrator wants dissimilar redundancy, well he has it with Dragon and Soyuz... Time to swallow some pride and forget the whole capture the flag game...
-
#1024
by
FinalFrontier
on 09 Feb, 2020 06:34
-
This is embarrassing to the point of being somewhat clownish. Yes space is hard.
But both of these vehicles have now been in development and testing for over ten years. And the human spaceflight gap for the United States now stands at nearly 9 years.
Some flaws with any new system are to be expected.
Spacecraft that explode, can't communicate with the ground, fire their thrusters backwards, and can't count to ten or tell what time it is are not expected and this kind of stuff is starting to call the entire commercial crew program into question.
Enough is enough at some point someone needs to take accountability for this and either cancel or fix this nonsense. We cannot afford to lose a crew or the space station and we can't afford anymore graft and waste of public money, the spend it on earth lobby is getting too loud and too well financed.
I can make a prediction right now that if this type of thing continues happening and we lose a crew the future congress will throw out the entire human spaceflight program both on LEO and BEO. I really really hope that someone or some people within these companies and organizations are aware of just how precarious their future is becoming. Once that pork is gone it's never coming back.
The lack of quality control is totally unacceptable period. Boeing needs to wake up or it's going to be gone in a few short years.
Also the idea that this flight test would NOT be reflown is appalling and should raise concern with congress and perhaps even the FBI. The flight test MUST be reflown it would be homicidally negligent to put a crew on this vehicle right now and NASA needs to stop glossing over and molly coddelling this.
Anyway, this is ridiculous bottom line. It's cartoonishly bad from start to finish particularly considering both NASA and Boeing LIED about the anomolies. Never thought I'd be agreeing with ASAP on anything but they actually did their job for once and it was a home run calling out the truth for once on this.
-
#1025
by
oldAtlas_Eguy
on 09 Feb, 2020 06:36
-
The point I was trying to put across as well is that the two bugs encountered were in the primary execution paths and not some contingency or off nominal flight. Because of this fact there was a serious fault in Boeing's testing process that should have identified such straight line execution bugs.
Which brings up the point that because of this, any reliability of software testing and validation is out the window. Meaning the software should go through a complete new test series for validation. But only after the faults in the test process is fixed first with NASA/ASAP concurrence.
-
#1026
by
FinalFrontier
on 09 Feb, 2020 06:44
-
The administrator wants dissimilar redundancy, well he has it with Dragon and Soyuz...
Wrong. Without going too OT here no, the situation is much worse.
Soyuz is arguably getting more dangerous with every flight due to deteriorating quality control due in turn to corruption within Russia. Holes in the spacecraft. Exploding boosters.
Dragon exploded. Yes I know they claim its fixed. Dragon still has super high pressure COPVs embedded in the body of the spacecraft for its LAS. I don't trust this system and I don't trust that there aren't more bugs hiding.
The truth is what we have is dissimilar hazards not dissimilar reliability and broken risk assessment and quality control across all three systems. And I have yet to see anybody really stepping up here and actually fixing this nonsense and that includes admin Jim.
-
#1027
by
Rocket Science
on 09 Feb, 2020 07:02
-
The administrator wants dissimilar redundancy, well he has it with Dragon and Soyuz...
Wrong. Without going too OT here no, the situation is much worse.
Soyuz is arguably getting more dangerous with every flight due to deteriorating quality control due in turn to corruption within Russia. Holes in the spacecraft. Exploding boosters.
Dragon exploded. Yes I know they claim its fixed. Dragon still has super high pressure COPVs embedded in the body of the spacecraft for its LAS. I don't trust this system and I don't trust that there aren't more bugs hiding.
The truth is what we have is dissimilar hazards not dissimilar reliability and broken risk assessment and quality control across all three systems. And I have yet to see anybody really stepping up here and actually fixing this nonsense and that includes admin Jim.
Without being argumentative, what else do we have at this point?
-
#1028
by
FinalFrontier
on 09 Feb, 2020 07:20
-
The administrator wants dissimilar redundancy, well he has it with Dragon and Soyuz...
Wrong. Without going too OT here no, the situation is much worse.
Soyuz is arguably getting more dangerous with every flight due to deteriorating quality control due in turn to corruption within Russia. Holes in the spacecraft. Exploding boosters.
Dragon exploded. Yes I know they claim its fixed. Dragon still has super high pressure COPVs embedded in the body of the spacecraft for its LAS. I don't trust this system and I don't trust that there aren't more bugs hiding.
The truth is what we have is dissimilar hazards not dissimilar reliability and broken risk assessment and quality control across all three systems. And I have yet to see anybody really stepping up here and actually fixing this nonsense and that includes admin Jim.
Without being argumentative, what else do we have at this point?
What you have is nothing right now but a chance to fix things and have some kind of program in the future.
The alternative is to have less than nothing when starliner slams into the space station or kills its crew and a future earth centric anti science congress responds by canceling all HSF programs and funding. Software and communications issues are what lead to the circumstances that caused the MIR progress collision. Quality control and risk assessment failure are what led to 51L and 107.
Looks to me like canceling STS and not building the J130 in favor of the stick and a bunch of paper vehicles was a really bad idea. Gee who could have guessed it except the entire Augustine commission all of the industry engineering rank and file and this entire websites' user base.
For reference I'm not mad at you or anyone else on here I'm mad at the people who allow this nonsense to happen and I'm sick of my taxes being frakked away on infinite nothings that never fly or become death traps worse than the device they were supposed to replace. It's even worse because Congress was told about this multiple times after Columbia and after CXP and here we are again, so was NASA and yet the lack of safety culture that brought down two vehicles is right back again. Twenty year cycle as usual.
-
#1029
by
ncb1397
on 09 Feb, 2020 07:31
-
We are about due for another crew accident..
Apollo 1 to Challenger - 6941 days
Challenger to Columbia - 6213 days
Columbia to today - 6217 days
Especially with the myriad of different new crew systems that are planned for use in the next ~36 months. It really is a matter of when(and what, who, how many, etc.), not if, and with BLEO flights the risk just goes up. Sure, Boeing should do another OFT, but NASA should pay them fair value for cargo. Let SpaceX take the risk with only 1 uncrewed orbital test flight.
edit: Maybe Doug Loverro should change his pin from counting down to December 31st 2024 to counting up from February 1st, 2003.
-
#1030
by
oldAtlas_Eguy
on 09 Feb, 2020 07:42
-
The path forward for Starliner:
-Fix the test process and get government concurrence on process.
-Fix the two bugs.
-Revalidate complete software, iterating with fixing bugs found and retest. Hopefully not many or new software bugs of only minor severity are found. TIAOMB software coding axiom "There is always one more bug!".
-Based on software testing and what software is changed, another OFT may be mandatory. If only bugs found are the original two (not likely [my inside opinion being a software developer/coder/manger] because of a breakdown in testing rigor), then no new OFT. Other than the two extremes whether there would be or not another OFT is an upper management assessment of risks and whether having a OFT would lower or lower the perceived risks.
In all a probable minimum of 6 months prior to the OFT need assessment is made. Then if another OFT then add another 3 to 6 months proir to an OFT flight. Then 3 to 6 months prior to manned flight.
-
#1031
by
LouScheffer
on 09 Feb, 2020 08:04
-
Starliner used its CM thrusters during pad abort test, why didn't mapping error show up then?
The failure is very strange. It should have shown up in the simulations as well.
I've seen this happen before. Engineer A writes the thruster command table, saying what the software expects when each thruster is fired. Engineer B writes the code that simulates spacecraft attitude changes as a result of thruster firings. This will contain a very similar, if not identical table. If both are wrong in the same way, the sim will pass but the spacecraft fail.
In theory these two pieces are written independently. But maybe they were both written from a spec that contained an error. Maybe A and B, tracking down a sim failure, noticed they were different, but made the wrong fix. Maybe B asked person A for his tables as a starting point. Maybe A and B were completely independent, but made the same mistake (This is quite common. If a single person programming has an error probability E, having a second person program the same thing independently only reduces the error chance to E/4, not E*E, since programmers tend to make similar errors.) There's lots of ways a cancelling error can occur.
The same error can screw up hardware-in-the-loop simulations, too. Unless it's super-realistic, with real thrusters moving a fake mass on low friction bearings, measured by real gyroscopes, (this is very rare, especially in 3D), something still has to transform thruster firings into attitude changes. If that table is screwed up in the same way as the command software, the sim will pass and the flight will fail.
-
#1032
by
oldAtlas_Eguy
on 09 Feb, 2020 08:25
-
Starliner used its CM thrusters during pad abort test, why didn't mapping error show up then?
The failure is very strange. It should have shown up in the simulations as well.
I've seen this happen before. Engineer A writes the thruster command table, saying what the software expects when each thruster is fired. Engineer B writes the code that simulates spacecraft attitude changes as a result of thruster firings. This will contain a very similar, if not identical table. If both are wrong in the same way, the sim will pass but the spacecraft fail.
In theory these two pieces are written independently. But maybe they were both written from a spec that contained an error. Maybe A and B, tracking down a sim failure, noticed they were different, but made the wrong fix. Maybe B asked person A for his tables as a starting point. Maybe A and B were completely independent, but made the same mistake (This is quite common. If a single person programming has an error probability E, having a second person program the same thing independently only reduces the error chance to E/4, not E*E, since programmers tend to make similar errors.) There's lots of ways a cancelling error can occur.
The same error can screw up hardware-in-the-loop simulations, too. Unless it's super-realistic, with real thrusters moving a fake mass on low friction bearings, measured by real gyroscopes, (this is very rare, especially in 3D), something still has to transform thruster firings into attitude changes. If that table is screwed up in the same way as the command software, the sim will pass and the flight will fail.
This defines not a software fault but a design hardware/software interface fault. This is where an OFT is needed to validate such things. So t his second item may not be an actual software bug but a true design/test/process fault. Many of these types aare only found when a real flight is performed.
Meaning since one such problem like this was found there may be another which may only be found by another flight that performs all the nominal flight tasks. I consider this second item a much more worrisome problem.
-
#1033
by
jpo234
on 09 Feb, 2020 08:43
-
Mulholland: All the software will be verified to check whether the requirements are being met. About a million lines of code.
A million lines is not that huge considering the project size. Your video player has about a million lines of code. The Linux bare kernel has 27.8 million lines of code, including nothing else in the OS.
From a
recent VW presentation:
-
#1034
by
MattMason
on 09 Feb, 2020 11:00
-
I'm feeling very lonely, being only one of the three people who voted No on the reflight poll. I think a reflight is not necessary because the previous flight found the major problems that needed to be fixed, two software and one communications, as well as the process errors that led to those errors slipping through. In the past, NASA also had problems that were discovered with test flights.
For example, Mercury Redstone 2 on 31 January 1961 had a number of problems, although the spacecraft was safely recovered. However, Von Braun insisted on another test flight, which went perfectly with Mercury Redstone BD on 24 March 1961. However, the additional delay resulted in the USSR being the first in space on 12 April 1961.
The second example were the problems experienced from pogo and on the S-II and S-IVB stages of the Saturn V during Apollo 6 on 4 April 1968. In this case, NASA took the gamble and put crew on the next Saturn V flight, Apollo 8 on 21 December 1968. This allowed the US to be first around the Moon, beating the Russians with their Proton-Zond program.
NASA also flew crew after Challenger and Columbia. NASA could have modified the Shuttle to do an uncrewed test flight, but had enough confidence that the corrective measures taken would be successful.
Of course, the US is no longer in a geopolitical battle with Russia for dominance in space, as the US is so far ahead in terms of achievements, technology and money being spent. It can afford to take its time, especially since Dragon 2 is nearly ready to fly. So what would another test flight achieve and what are the risks to the crew? The last test showed that the spacecraft is basically sound. The two software bugs are easily fixed. The process errors that led to those bugs will take much longer to fix, but will result in the software being much safer. I am confident the communications problem will be fixed as well. So, I would personally feel confident in flying on CST-100, except for one thing.
That one thing is an inflight-abort. I have no confidence that will work since it hasn't been tested. I would rather Boeing spend money on that, instead of a repeat of OFT. NASA could provide a Peacekeeper first stage for the test as government supplied equipment to help reduce overall costs.
Your reasoning is understandable. But today's human spacecraft and their computer controls differ from the analog fly-by-wire systems of Mercury. The Shuttle Orbiter's computers are likely quite primitive to Starliner, although that's a better comparison.
While an in-flight abort test would remove the assumption that the abort system works in all modes, the software flaw of the Service Module that could fire incorrectly and make recontact with the capsule would be just as much a threat on ascent as in deorbit.
I was also in the "no reflight" camp for a time, before the teleconference. An autonomous vehicle simply can NOT have so many bugs as these, both of which may have been LOC level. And given that the vehicle hasn't tested its rendezvous and docking abilities (another assumption), that's another stake in the "no reflight" argument.
If NASA is serious on transparency, a reflight is virtually inevitable for both Boeing's reputation and the agency's.
Surely Boeing has a counterpart to the SAIL simulator where all avionics and code are tested?
-
#1035
by
MattMason
on 09 Feb, 2020 11:07
-
I was the Chairman of the Atlas E,F and H launch vehicles Software Review Board. On the hook with my signature on every software change.
Given how history has clearly documented the original Atlas and later variants to work it into such a reliable vehicle over the decades, you, sir, have some
extremely serious street cred with any points you make.And what you and your teammates did may be
exactly what is flawed or missing with Boeing, and not just at the aerospace level.
Perhaps you could offer your services as a consultant?
-
#1036
by
scdavis
on 09 Feb, 2020 11:36
-
Which brings up the point that because of this, any reliability of software testing and validation is out the window. Meaning the software should go through a complete new test series for validation. But only after the faults in the test process is fixed first with NASA/ASAP concurrence.
Exactly, this is much better stated and specific than my attempted explanation yesterday. As you say, precisely because these bugs are seen in the main execution path, we now know with reasonable confidence that the sum of all prior testing has low probability to have caught the remaining critical bugs. Their test performance is way below expectations.
-
#1037
by
woods170
on 09 Feb, 2020 12:07
-
This is embarrassing to the point of being somewhat clownish. Yes space is hard.
But both of these vehicles have now been in development and testing for over ten years. And the human spaceflight gap for the
Emphasis mine.
Some finetuning of your statement needed here.
- NASA-funded development of Crew Dragon began in late 2011 after having won an award in CCDev, round 2. Risk reduction effort for the integrated abort system.
- NASA-funded development of Starliner began in the latter half of 2010 after having won an award in CCDev, round 1. Risk reduction effort for the clamshell-like pressure shell.
Any development done on those vehicles PRIOR to winning NASA funding was done in-house with only marginal funding.
Really serious development on both vehicles didn't start until late 2012 when both companies received awards under the CCiCAP phase of CCP.
Stating that both vehicles have been in development for over 10 years is basically correct but does NOT paint the correct picture without mentioning the available funding levels over these past 10 years.
-
#1038
by
woods170
on 09 Feb, 2020 12:16
-
The administrator wants dissimilar redundancy, well he has it with Dragon and Soyuz...
Wrong. Without going too OT here no, the situation is much worse.
Soyuz is arguably getting more dangerous with every flight due to deteriorating quality control due in turn to corruption within Russia. Holes in the spacecraft. Exploding boosters.
Dragon exploded. Yes I know they claim its fixed. Dragon still has super high pressure COPVs embedded in the body of the spacecraft for its LAS. I don't trust this system and I don't trust that there aren't more bugs hiding.
The truth is what we have is dissimilar hazards not dissimilar reliability and broken risk assessment and quality control across all three systems. And I have yet to see anybody really stepping up here and actually fixing this nonsense and that includes admin Jim.
Emphasis mine.
Crew Dragon has high-pressure COPVs right next to its pressure vessel. Boeing has high-pressure COPVs three feet away from its pressure vessel in the service module. In both cases the catastrophic failure of a high-pressure COPV in-orbit has exactly the same result: Loss Of Vehicle and Loss Of Crew.
Singling out Crew Dragon over the placement of its COPVs is silly. Starliner has the same basic issue.
Shuttle had it as well with COPVs placed in the nose area, payload bay area and tail section. Anyone of those COPV's letting go in-orbit would have meant the end of the vehicle and the crew.
You really have to come up with better arguments why any of those vehicles is safer or less-safe than the others.
-
#1039
by
GWR64
on 09 Feb, 2020 13:41
-
Starliner used its CM thrusters during pad abort test, why didn't mapping error show up then?
From a Boeing press release on November 18, 2019.
https://boeing.mediaroom.com/2019-11-18-Boeing-Statement-Regarding-OIG-Report-on-NASAs-Commercial-Crew-Program-- In 2019, we completed:
-- Service module hot fire test, validating the performance of our propulsion system in both nominal and contingency scenarios.
-- All parachute qualification tests without a single test failure, demonstrating the resiliency of our parachute system even in dual-fault scenarios.
-- Discussions with NASA about our system led to our mutual agreement to perform even more tests and analysis, which validated our system as designed.
-- We are confident in the safety of our system, and we have proven through extensive testing that we have a robust design that has consistently performed above requirements, even in dual-fault scenarios.
-- Pad Abort Test, which was Starliner’s first flight test and a near-flawless performance of our integrated propulsion and flight control systems in an abort case.
emphasis by me
We don't know what is behind the little word "near".
