Re: staging, reliability, etc. (was Re: Towed Booster Stability)
From: Kim Keller (kimekeller_at_yahoo.com)
Date: 07/07/04
- Next message: TKalbfus: "Re: More Space Elevator news"
- Previous message: TKalbfus: "Re: Just How Blind is the Human Race?"
- In reply to: Henry Spencer: "staging, reliability, etc. (was Re: Towed Booster Stability)"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 07 Jul 2004 12:28:27 GMT
"Henry Spencer" <henry@spsystems.net> wrote in message
news:I0E6H1.MEI@spsystems.net...
> Of course, witnessing the first two launches of Delta III or Pegasus XL
> might lead one to a somewhat different conclusion, despite the even
> greater heritage involved.
One D III failure was due to poor judgement by the company in not expending
effort on the aerodynamic model of the new configuration. That led to loss
of the first flight. D III had a lot of D II heritage, but there was a lot
of first-flight stuff on that bird, too. The second mission fell to a
manufacturing change and resultant defect in the second stage nozzle. It
hadn't been qualified sufficiently. So, yeah, experienced teams can make bad
decisions, too.
I did notice, though, that staging on the second and third flights worked
correctly....:-)
As for Pegasus, I'm really not crazy about that company's work. That said,
their last failure (which occured on Peg flight 14) was over 20 missions
ago. They appear to now have a mature design and operation.
> "To ensure it employs technology over technique, an organization must, if
> possible, certify all critical hardware through testing - not just
> analysis. However, if analysis must be used, it should be verified by
> testing. For example, even today's computerized aircraft-design process
> does not eliminate the necessity for flight-testing..."
> -- "Beyond the Widget: Columbia Accident Lessons Affirmed"
> Brig Gen Duane W. Deal, USAF (CAIB)
> http://www.spaceref.com/news/viewnews.html?id=955
>
> Flight test programs are indispensable. Launch systems designed so that
> they cannot support an affordable flight-test program -- that's a design
> decision, not a law of nature -- are living on borrowed time. The fact
> that this is common does not make it a good idea; see comments made after
> both Challenger and Columbia about "normalization of deviance" (we got
> away with it a few times so it must be okay).
I agree, I agree, I agree. Flight test programs are essential. But launch
companies have a terrible time making an economic case for test flights
beyond the typical giveaway first flight. Having to survive in a commercial
market pushes them to take the risk and rely on qual/acceptance testing and
qual by analysis. It's a liability of expendable systems. "Normalization of
deviance" is something I don't see too much of in the US ELV world -
post-flight analysis is pretty thorough, with engineering review boards
triggered by deviations from pre-flight predictions of more than 3-sigma.
> However, such contributions can be indirect, for example by making it
> possible for would-be customers to obtain affordable launch insurance.
> Or even making them willing to buy at all -- note how Sea Launch ended
> up flying a test launch despite using almost all well-proven hardware,
> because the customer slated to fly on their first one backed out.
Certainly. You don't have to convince me of this. But US ELV companies
aren't making all that much profit per launch, so they would rather gamble
on the quality of their design and their operation. They'll be decades
recouping their sunk costs as matters stand now, let alone adding in the
financial burden of flight test.
> >Pegasus XL was a far bigger design change than could be called
incremental
> >improvement...
>
> Uh, a 10% stretch in the first- and second-stage motors sounds like an
> incremental improvement to me. That sort of small stage stretch hardly
> rates mention in the Delta or Atlas world.
Well, there was a *bit* more to the upgrade than just stretching stages. If
corporate were to ask engineering for 10% improvement on Delta and Atlas I'm
sure there'd be groans audible in Canada. The number may not sound like much
to the public, but at the detail design level it is.
> I would be more inclined to agree if similar failures hadn't happened in
> well-established US programs. While I concur with your basic point, I
> think you are underestimating the extent to which "technically mature"
> programs can gradually rot into similar states of inexperience when they
> lose their experienced people. The Indians may even have an advantage,
> since they *know* they're new to the business.
Rot certainly can occur, but that doesn't mean a design or operational
concept is bad. It means the team has left its eye slip off the target, and
it can happen to anyone. Focus and dedication to excellence is required of
all members of the team. That can apply to training and preservation of
corporate knowledge, and experience, too.
> >Workmanship error that should have been caught, not a design error.
>
> So if it's a design error it's due to immaturity,
I didn't say all design errors are due to immaturity, did I? Some are due to
economic decisions, some are due to an engineer overlooking something that
is small enough no one else notices it. So, who's design is going to contain
more potential for failure - one that's flown 1-6 times, or one that's made
20 successful flights?
A lot of design errors are small enough that they don't kill a mission, and
so they get caught in the post-mission analysis and fixed. You don't hear
about those. But they get caught, lessons get learned and the program
matures a bit more.
> and if it's a
> workmanship error that doesn't count because people are supposed to be
> perfect?
The "system" is supposed to be set up so that it keeps operations as close
to perfect as possible. People still make mistakes, but those mistakes ought
to be caught by the system. That's a mark of maturity.
> So, what's left? Is there any class of failure you're willing
> to admit as "real"?
All failures are real. But they can be categorized, studied and eliminated
as sources of future failure.
> A failure due to a workmanship error remains a failure.
Where did I say it didn't? What I said was that a workmanship error is not a
design error.
> It is fairer to
> count all failures which occur during operational service, rather than
> compiling a long list of excuses as to why each failure doesn't count.
I wasn't making excuses for failures. I was pointing to a significant
difference between types of failures, some of which can be laid at the feet
of immaturity and some that can be laid elsewhere.
> Imperfect workmanship is a fact of life, not some inexplicable act of God
> before which we are helpless.
Exactly. Which is why a system put together by an experienced team is going
to see less workmanship failures fly than an inexperienced team.
> What matters is how vulnerable the system
> (which includes both hardware and people) is to it. See Mars Climate
> Orbiter and Apollo 13.
The launch environment is not very forgiving, nor is there a lot of time for
troubleshooting and work-arounds. You get it right in the pre-flight
operations and settle for nothing less. It's great to build robustness into
the launch system, but you can't always afford to build in enough to handle
every conceivable problem and still have enough performance margin left to
put a meaningful payload on top. US companies build for a 1.25 safety factor
in unmanned ELVs because that seems to be sufficient to handle 99.XXX% of
potential problems and still remain financially acceptable.
> >Getting back to the subject of this thread, staging is *not* a technical
> >challenge. We know how to do it reliably, and if everyone has done their
> >jobs correctly it will work every time.
>
> What if somebody hasn't done his job correctly? That *will* *happen*
> eventually. The vulnerability of a system to human error is a legitimate
> criterion for evaluating the system.
Certainly. The system (which I believe to be composed of the people, the
paper and the hardware) has to be designed to catch errors and fix them
before T-0. Experience makes it possible to design and execute such a
system.
> Actually, I agree that with sufficient effort, staging can be made
> passably reliable, at least in fault-tolerant reusable systems where
> hardware can be tested repeatedly. The question is whether that is the
> best use of limited money and engineering manpower, and whether adequate
> resources will continue to be allocated to it in a long-term operational
> program.
We're going to have staging with us for a long time. Even reusable TSTOs are
going to require sep systems. It's just not that hard to get it right.
Compared to what it'll probably cost to develop RLVs with a commercially
viable payload capacity the cost is peanuts.
-Kim-
- Next message: TKalbfus: "Re: More Space Elevator news"
- Previous message: TKalbfus: "Re: Just How Blind is the Human Race?"
- In reply to: Henry Spencer: "staging, reliability, etc. (was Re: Towed Booster Stability)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
