-
#1080
by
DistantTemple
on 11 Feb, 2020 07:27
-
If you really wanted to have two entirely different vehicles and you really wanted to drop Boeing, no matter the cost or delay, I think you're better off going with Blue Origin over SNC. Or even with Google over SNC. At least Google understands large, complex engineering projects.
AIUI SNC is a significant defense contractor, with many high tec skills, including aeronautics... and missiles. So they have experience of large complex projects.... and dealing with government and the military, and of course now with NASA with the cargo Dream Chaser.
I'm sure I remember reading that the cargo air-frame was going to be "the same without the windows", and that SNC wanted to keep a clear path back to a crewed version.
So in comparison to Blue or Google, SNC have a viable air-frame that is nearly ready for orbital testing, whereas they don't have a vehicle yet.
In comparison to SpaceX, SNC need to fit out the air-frame for crew, whereas SpaceX came up with Dragon2 - which is largely a new vehicle, with many extra technologies.
To me SNC has a clear head start. Google hasn't started, and Blue believes in being .... careful ! rather than rushed.
-
#1081
by
Captain Crutch
on 11 Feb, 2020 15:46
-
Can anybody reconcile the fact that these egregious software errors were discovered during flight, but not during testing prior to launch?
That is the most concerning and frightening aspect of this whole debacle. Only when things went wrong did they thoroughly check the thruster software? Nobody thought to do a thorough review prior to launch??? That NASA or Boeing wouldn’t have reviewed the critical event software is unfathomable.
What bothers me, even more, is the resistance from some to call this an issue or anomaly at all. I can't fathom why NASA would trust Boeing to launch crew on this capsule right now. Unfortunately, this is proving NASA's desire for redundancy as necessary. I would be much more comfortable if the response was that they're working on fixing all the issues and ensuring they're never going to happen again, instead of "we caught it before it became an issue so there's no issue right?" for this recent anomaly and then also saying "this is not an issue because the vehicle was designed to survive under these conditions" when a parachute wasn't fastened properly. I'm honestly appalled by the way these issues are being portrayed by Boeing as minor and of no real concern.
-
#1082
by
BogoMIPS
on 11 Feb, 2020 16:37
-
As much as I am alarmed at the poor performance of Boeing, SNC doesn't have any kind of a track record doing this kind of thing and a crew Dream Chaser would cost billions of dollars and many years more.
If you really wanted to have two entirely different vehicles and you really wanted to drop Boeing, no matter the cost or delay, I think you're better off going with Blue Origin over SNC. Or even with Google over SNC. At least Google understands large, complex engineering projects.
And about the comment about two competitors being complacent if they don't have a third nipping at their heels -- that makes no sense to me. Why not three being complacent without a fourth? Or 100 being complacent without a 101st? I don't think there's some magic about 3 versus 2 that keeps complacency from happening.
I just picked Dream Chaser for the example... you could have any vendor provide a third vehicle as they are getting close to cargo transport/return that could lead towards crew capability.
The bigger concern IMO is whether budgets and flight frequency are large enough to support the business costs for three different vehicle providers.
I just don't want to lose "dissimilar, redundant, US-based crew launch options" if any of my vehicles get grounded for an extended period.
If NASA wants to say "Soyuz remains our emergency backup"... (or even Orion but I suspect that is a non-starter due to the cost of it's LV), that is a viable "third leg of the stool"... as long as they fund whomever that provider is enough to have them proven and ready if we need them.
-
#1083
by
whitelancer64
on 11 Feb, 2020 17:05
-
As much as I am alarmed at the poor performance of Boeing, SNC doesn't have any kind of a track record doing this kind of thing and a crew Dream Chaser would cost billions of dollars and many years more.
The same thing was said about Space X when they were building Falcon 1.
At the time of the down-selection in September 2014, SNC / DreamChaser was about a year behind SpaceX and Boeing. SNC had just made a major design change to DC, switching from a hybrid main propulsion system to all liquid fuel.
There have been sufficient delays up to now, by both providers and by NASA, that being so far behind may not have made much of a difference, but keep in mind that in late 2014 the plan was still to fly crew by 2017.
-
#1084
by
whitelancer64
on 11 Feb, 2020 17:08
-
If you really wanted to have two entirely different vehicles and you really wanted to drop Boeing, no matter the cost or delay, I think you're better off going with Blue Origin over SNC. Or even with Google over SNC. At least Google understands large, complex engineering projects.
AIUI SNC is a significant defense contractor, with many high tec skills, including aeronautics... and missiles. So they have experience of large complex projects.... and dealing with government and the military, and of course now with NASA with the cargo Dream Chaser.
I'm sure I remember reading that the cargo air-frame was going to be "the same without the windows", and that SNC wanted to keep a clear path back to a crewed version.
*snip*
IIRC, Sierra Nevada has said the Cargo DC is about 80% the same as Crew DC.
-
#1085
by
whitelancer64
on 11 Feb, 2020 17:17
-
Can anybody reconcile the fact that these egregious software errors were discovered during flight, but not during testing prior to launch?
That is the most concerning and frightening aspect of this whole debacle. Only when things went wrong did they thoroughly check the thruster software? Nobody thought to do a thorough review prior to launch??? That NASA or Boeing wouldn’t have reviewed the critical event software is unfathomable.
What bothers me, even more, is the resistance from some to call this an issue or anomaly at all. I can't fathom why NASA would trust Boeing to launch crew on this capsule right now. Unfortunately, this is proving NASA's desire for redundancy as necessary. I would be much more comfortable if the response was that they're working on fixing all the issues and ensuring they're never going to happen again, instead of "we caught it before it became an issue so there's no issue right?" for this recent anomaly and then also saying "this is not an issue because the vehicle was designed to survive under these conditions" when a parachute wasn't fastened properly. I'm honestly appalled by the way these issues are being portrayed by Boeing as minor and of no real concern.
The cause of the one main parachute not deploying was quite simple, a connecting pin not being inserted correctly, so that was an easy fix, and additionally the parachutes didn't have anything to do with what was actually being tested - namely the abort system. Orion performed a test of its abort system without deploying any parachutes, you may recall. And the capsules
are designed to land safely with one parachute out, so that's all pretty well understandable.
But the potentially catastrophic consequences of these software errors is far more serious.
-
#1086
by
gaballard
on 11 Feb, 2020 18:08
-
Can anybody reconcile the fact that these egregious software errors were discovered during flight, but not during testing prior to launch?
That is the most concerning and frightening aspect of this whole debacle. Only when things went wrong did they thoroughly check the thruster software? Nobody thought to do a thorough review prior to launch??? That NASA or Boeing wouldn’t have reviewed the critical event software is unfathomable.
What bothers me, even more, is the resistance from some to call this an issue or anomaly at all. I can't fathom why NASA would trust Boeing to launch crew on this capsule right now. Unfortunately, this is proving NASA's desire for redundancy as necessary. I would be much more comfortable if the response was that they're working on fixing all the issues and ensuring they're never going to happen again, instead of "we caught it before it became an issue so there's no issue right?" for this recent anomaly and then also saying "this is not an issue because the vehicle was designed to survive under these conditions" when a parachute wasn't fastened properly. I'm honestly appalled by the way these issues are being portrayed by Boeing as minor and of no real concern.
The cause of the one main parachute not deploying was quite simple, a connecting pin not being inserted correctly, so that was an easy fix, and additionally the parachutes didn't have anything to do with what was actually being tested - namely the abort system. Orion performed a test of its abort system without deploying any parachutes, you may recall. And the capsules are designed to land safely with one parachute out, so that's all pretty well understandable.
But the potentially catastrophic consequences of these software errors is far more serious.
My parents and my first boss used to tell me, "if you can't handle the simple things, how can we trust you with the big things?"
The fact that their problems ranged from a pin out to major LOC-level issues kind of illustrates that point.
The pin out by itself isn't going to cause a LOC event. But it's such a basic mistake that it's highly worrying their QA/QC processes didn't catch it. Or, put another way, it's a symptom that in and of itself isn't (that) dangerous, but it's indicative of a larger problem that could be far more serious.
-
#1087
by
abaddon
on 11 Feb, 2020 18:58
-
IIRC, Sierra Nevada has said the Cargo DC is about 80% the same as Crew DC.
Yes, and Elon Musk said Crew Dragon was going to be basically the same as Cargo Dragon. An excess of enthusiasm is not surprising when the words are free.
Crew DC would be very like Cargo DC. Except 25% bigger. And not in a fairing. Requiring a different launcher, and vastly different aerodynamics when launching. Not having foldable wings. Adding a crew cabin with seats, controls, screens, etc. Adding ECLSS. Adding abort capability. NASA certification and all that entails...
"80% the same" is just like Musk - an excess of enthusiasm when words are free. Take it with a gigantic boulder of salt.
Since this is the Boeing Starliner discussion thread, SNC and DreamChaser aren't really on topic so I'll stop there.
-
#1088
by
lrk
on 11 Feb, 2020 19:41
-
Or even with Google over SNC. At least Google understands large, complex engineering projects.
(Google employee here. All statements expressed here are personally my own opinions and based on already-public information.)
Haha. No. Yikes.
Google is very much
not set up to undertake a human spaceflight project. Reliability assurances are mostly based on scale and having an insane amount of redundancy (in servers, etc.) so that when something breaks there is a fall-back. Except when someone accidentally deploys a global change that breaks everything without testing for a smaller region first (remember all the outages last year?)
Also complex projects are done by small teams that communicate well individually, but at a higher level things are more ...chaotic. (There is one giant code base for the company that everyone is free to reuse as fit, teams/projects are frequently spun up and cancelled, there are multiple teams working on basically the same thing, etc.)
Not a good fit for human spaceflight.
Edit: Also note that Google is primarily a software company (with a few teams working on hardware such as phones, machine learning accelerator ASICs, etc.) and doesn't have any aerospace experience or aerospace engineers. X (the research division formerly part of Google, now spun off under Alphabet) has some with projects like Loon and Wing but is geared towards lowish-cost, highly speculative projects that are likely to fail, not a huge program like Commercial Crew.
-
#1089
by
mgeagon
on 11 Feb, 2020 20:19
-
Do I have this correct? If the orbit rising anomaly wouldn’t have occurred and the mission proceeded nominally, Boeing would have neither looked for nor found the SM clocking error and a catastrophic collision might have occurred in space? So, it was basically dumb luck that prevented a loss of mission? And Boeing/NASA didn’t think this mattered with the whole “a lot went right” comments?
As launched, the Starliner was unsafe. No, there should not be humans riding on that thing anytime soon. We give too little weight to the importance of “software” and its impact on safety. A coding error can be just as deadly as an electrical fire in a pure oxygen environment, a leaky O ring on a cold day or an impact of insulation on soft aluminium.
-
#1090
by
whitelancer64
on 11 Feb, 2020 20:46
-
Do I have this correct? If the orbit rising anomaly wouldn’t have occurred and the mission proceeded nominally, Boeing would have neither looked for nor found the SM clocking error and a catastrophic collision might have occurred in space? So, it was basically dumb luck that prevented a loss of mission? And Boeing/NASA didn’t think this mattered with the whole “a lot went right” comments?
As launched, the Starliner was unsafe. No, there should not be humans riding on that thing anytime soon. We give too little weight to the importance of “software” and its impact on safety. A coding error can be just as deadly as an electrical fire in a pure oxygen environment, a leaky O ring on a cold day or an impact of insulation on soft aluminium.
That is correct, and terrifying.
-
#1091
by
whitelancer64
on 11 Feb, 2020 20:52
-
Can anybody reconcile the fact that these egregious software errors were discovered during flight, but not during testing prior to launch?
That is the most concerning and frightening aspect of this whole debacle. Only when things went wrong did they thoroughly check the thruster software? Nobody thought to do a thorough review prior to launch??? That NASA or Boeing wouldn’t have reviewed the critical event software is unfathomable.
What bothers me, even more, is the resistance from some to call this an issue or anomaly at all. I can't fathom why NASA would trust Boeing to launch crew on this capsule right now. Unfortunately, this is proving NASA's desire for redundancy as necessary. I would be much more comfortable if the response was that they're working on fixing all the issues and ensuring they're never going to happen again, instead of "we caught it before it became an issue so there's no issue right?" for this recent anomaly and then also saying "this is not an issue because the vehicle was designed to survive under these conditions" when a parachute wasn't fastened properly. I'm honestly appalled by the way these issues are being portrayed by Boeing as minor and of no real concern.
The cause of the one main parachute not deploying was quite simple, a connecting pin not being inserted correctly, so that was an easy fix, and additionally the parachutes didn't have anything to do with what was actually being tested - namely the abort system. Orion performed a test of its abort system without deploying any parachutes, you may recall. And the capsules are designed to land safely with one parachute out, so that's all pretty well understandable.
But the potentially catastrophic consequences of these software errors is far more serious.
My parents and my first boss used to tell me, "if you can't handle the simple things, how can we trust you with the big things?"
The fact that their problems ranged from a pin out to major LOC-level issues kind of illustrates that point.
The pin out by itself isn't going to cause a LOC event. But it's such a basic mistake that it's highly worrying their QA/QC processes didn't catch it. Or, put another way, it's a symptom that in and of itself isn't (that) dangerous, but it's indicative of a larger problem that could be far more serious.
Yeah, if the parachute's pin not being inserted correctly was the only issue Boeing had, it wouldn't be that big of a deal. The multitude of issues that have come to light, that it appears are symptoms of more fundamental problems, are certainly extremely worrying, to say the least.
-
#1092
by
Brian45
on 11 Feb, 2020 21:00
-
And if I recall, Boeing took pictures of the pins and didn't bother to look at them until after the failure.
-
#1093
by
AS_501
on 11 Feb, 2020 21:06
-
As an Apollo-era old timer, I was sort of hoping Boeing would get the honor of conducting the first crewed flight. That has changed. I'm pulling for (and expect) Space-X to earn this honor.
-
#1094
by
SWGlassPit
on 11 Feb, 2020 21:47
-
What bothers me, even more, is the resistance from some to call this an issue or anomaly at all.
Going to pick on this sentence a little bit because I'm a systems engineer, and I'm pedantic for a living.
Terms like "incident" and "anomaly" have very specific definitions in the CCtCap contracts. Unfortunately, I don't have the definitions in the contract in front of me, but a similar conversation happened around the SpaceX IFA hotfire anomaly.
If they appear to be dancing around terms, it may well be because certain words are given precise meaning in this context, meaning people are not going to just use them casually.
-
#1095
by
OM72
on 11 Feb, 2020 21:58
-
And if I recall, Boeing took pictures of the pins and didn't bother to look at them until after the failure.
For a while I would come on here and do my best to answer questions from an engineering perspective. I was called "Boeing PR", etc. I rarely come on here any more because many of you know better than anyone/everyone else.
But this....this is just out of order. The pin "buy" is a "TQN" buy. Meaning the tech believed it was installed, Quality believed it was installed correctly and NASA believed the pin was installed correctly. Every closeout photo is not reviewed, especially when three different and independent people believed it to be installed correctly.
That said, this was a definite lesson learned and the procedure and process has been revised.
-
#1096
by
Rebel44
on 12 Feb, 2020 01:35
-
And if I recall, Boeing took pictures of the pins and didn't bother to look at them until after the failure.
For a while I would come on here and do my best to answer questions from an engineering perspective. I was called "Boeing PR", etc. I rarely come on here any more because many of you know better than anyone/everyone else.
But this....this is just out of order. The pin "buy" is a "TQN" buy. Meaning the tech believed it was installed, Quality believed it was installed correctly and NASA believed the pin was installed correctly. Every closeout photo is not reviewed, especially when three different and independent people believed it to be installed correctly.
That said, this was a definite lesson learned and the procedure and process has been revised.
Well, NASA also somehow completely missed that Starliner software is trash, so I hope there will be major improvements in QA and testing mandated at both Boeing and NASA.
-
#1097
by
ChrisWilson68
on 12 Feb, 2020 04:59
-
As much as I am alarmed at the poor performance of Boeing, SNC doesn't have any kind of a track record doing this kind of thing and a crew Dream Chaser would cost billions of dollars and many years more.
The same thing was said about Space X when they were building Falcon 1.
Yeah, and SpaceX didn't get a contract to replace an almost-complete human-carrying spacecraft with a new design while they were building Falcon 1.
-
#1098
by
zodiacchris
on 12 Feb, 2020 05:44
-
And if I recall, Boeing took pictures of the pins and didn't bother to look at them until after the failure.
For a while I would come on here and do my best to answer questions from an engineering perspective. I was called "Boeing PR", etc. I rarely come on here any more because many of you know better than anyone/everyone else.
But this....this is just out of order. The pin "buy" is a "TQN" buy. Meaning the tech believed it was installed, Quality believed it was installed correctly and NASA believed the pin was installed correctly. Every closeout photo is not reviewed, especially when three different and independent people believed it to be installed correctly.
That said, this was a definite lesson learned and the procedure and process has been revised.
Are you serious? Belief belongs in a church and not in an aerospace company! I work with aircraft and that word is pretty much taboo.
Bob, have you tightened the wing attachment bolts? Yeah, I believe so...
If QA at Boeing can’t establish beyond doubt if a shackle pin has been tightened to specs and just ‘believe‘ that it has the process is entirely pointless. A design that cannot be properly QA checked during and after assembly is bad design and a QA team just going through the motions is beyond the pale. If the part cannot be inspected properly after assembly, at least review the photographs!
The software issues that also hadn’t been picked up pre flight just highlight that their QA is basically flawed. Excusing that is not Boeing PR, it’s Boeing hypocrisy IMHO...
-
#1099
by
ThatOldJanxSpirit
on 12 Feb, 2020 08:24
-
And if I recall, Boeing took pictures of the pins and didn't bother to look at them until after the failure.
For a while I would come on here and do my best to answer questions from an engineering perspective. I was called "Boeing PR", etc. I rarely come on here any more because many of you know better than anyone/everyone else.
But this....this is just out of order. The pin "buy" is a "TQN" buy. Meaning the tech believed it was installed, Quality believed it was installed correctly and NASA believed the pin was installed correctly. Every closeout photo is not reviewed, especially when three different and independent people believed it to be installed correctly.
That said, this was a definite lesson learned and the procedure and process has been revised.
Are you serious? Belief belongs in a church and not in an aerospace company! I work with aircraft and that word is pretty much taboo.
Bob, have you tightened the wing attachment bolts? Yeah, I believe so...
If QA at Boeing can’t establish beyond doubt if a shackle pin has been tightened to specs and just ‘believe‘ that it has the process is entirely pointless. A design that cannot be properly QA checked during and after assembly is bad design and a QA team just going through the motions is beyond the pale. If the part cannot be inspected properly after assembly, at least review the photographs!
The software issues that also hadn’t been picked up pre flight just highlight that their QA is basically flawed. Excusing that is not Boeing PR, it’s Boeing hypocrisy IMHO...
I’ve got to agree with that.
Having a critical safety system that can be misconfiguered by a simple human error, and which is not obviously revealed, is simply unacceptable in most high hazard industries. Multiple human checks buys nothing. I have witnessed multiple critical checks failing first hand simply because everyone assumed that it was being thoroughly checked multiple times by other people.
What I would like to know is if this was a tried and tested shackle design that was simply too venerable for anybody to bother doing a meaningful failure modes analysis, or if it was a design that had been ‘improved’ in some well meaning but ultimately misguided manner (I’ve seen that a few times too).
What is most worrying through all this is that I can still sense a reluctance to admit that anything has really gone wrong. Safety culture is built on embracing failure and learning from it.