CEV development cost rumbles

The guilty party (dave schneider) wrote:
[...]
Well, I may be misquoting Ray Schmidt,

Ooops, sorry for *mis-identifying* him -- its Ray Schmitt
).

/dps

(Derek Lyons) wrote:
[...]
Yeah, but you need more up-tracks than down-trucks, so why pay to use
wings 50 times instead of 5 times?

Why pay to develop, test, build, maintain, and operate two different
spacecraft with almost identical requirements? 'One size fits all' is
bad, but 'a different spacecraft for each individual type of mission'
is hardly any better.


Well, of course there's a trade off, but if you can do big savings on
90% of your flights, you may recover the other craft's development
costs. And both CEV and OSP have the constraint of launching on
EELVs, which limits the mass you can bring down anyway. If you're
stuck designing 2 vehicles, why make both pay a "one size fits all"
penalty?

How big is a CMG relative to an empty-shell CEV capsule? If it fit,
an unmanned up-truck would be a (relatively) cheap down-truck.
Ignoring for the moment that the "biggest down load" at time x is
eventually going to be beat by the size at time x', but maybe this
covers long enough to get us to another generation of launch vehicles.

I'd like an efficient way of swapping science racks, which was aprt of
the big discussion during OSP days, but we might have to go through a
half-rack period for a while.

Perhaps an interesting way to handle CMGs and other unusual returns is
with a disposable down-truck, perhaps some variation on MOOSE. Spray
on a big foam mushroom -- er, heatshield, attach a parafoil or chute
package, give it a retrograde nudge, and voila!

Yeah, you have to the *mass* of the heatshield up, but at least you
get to take it up in a small volume internal to your uptruck, where it
doesn't add any drag.

What sort of obstacles have to be overcome to allow us to create 10's
of cubic meters of aerogels in orbit? That would be a handy trick,
although poly-x-thanes might work if you can make the shield thick
enough to not ablate too soon.

Or maybe a Shuttle-C variant (oops, that assumes someone ever okays an
HLV) that is *primarily* a down-truck, and carries wings inside for
the launch, and installs them for the flight down. Tricky, but with
the right sort of boot on the wing root, could be doable.

What are the mission requirements for a down-truck? It doesn't have
to have a great deal of cross range if you're willing to wait for the
right opportunity to deorbit, and slightly-used CMGs aren't a rush
job; large volume is a good idea; land-on-land is a good idea. Is
low-g reentry required? What about touchdown?

Be interesting to see what turns up.

/dps

(Derek Lyons) wrote:
remainder of reply filled with equally ludicrous fallacies snipped.

Could you be troubled to show *how* they are fallacious?


it took a lot of persuasion to get me to see the above viewpoint.

You don't have a viewpoint. You have a dogma.

Me, dogma? I'm Mr. Eclectic. And if you google my past posts, you
can probably see them swerving all over the landscape.

And once again,
'You also did not answer my question about what *you* see as the
issues
with WVs and how they can be solved, you just made the World Weekly
News statement that
"Putting it off won't make it easier, especially considering that the
real problems have nothing to do with TPS designs...." '

/dps

Derek Lyons wrote:

Herb Schaltegger
lid wrote:

As I noted in a prior post, the entire SSF ECLSS was spec'd to run on
about
2 286-class MDM boxes. The ARS used most of one box and the water rack
used another. And that was for a full-up closed-loop water and air
recycling system. Of course, they've since upped the spec's - a google
search the other day indicated that ISS MDMs ended up at 20 MHz
rad-hardened 386SX's.

How much of the 'up-speccing' is due to that particular processor
being more available, poor software management, increased demands
etc..?

Oh, who knows? Even when 286's were the spec there was pressure from
Software to free-up more processor cycles and storage space than the ARS
was allocated. The decision to up-spec was probably due to many different
factors all rolled into one big "Yea/Nay" decision by the WP1 Program Chief
Engineer at a basement Woodshed one Friday morning. Been there, done that
(3 times over about three years), even got an official "Attaboy" once.

As I noted, the ARS utilized most (maybe 2/3 - 3/4) of the capacity of the
MDM in our rack; sadly, we had to provide processing capability for some
distributed THC stuff, IIRC. The fact that we had to share our MDM, plus
the inevitable demands from NASA to push more bloat into the code (think:
"Hey, wouldn't it be great if the ARS atmosphere sampling system could be
reconfigured on the fly to do . . . . " as spoken at a RID-closure review
meeting) probably had a lot to do with upgrading the baseline MDM spec.

--
Herb Schaltegger, B.S., J.D.
Reformed Aerospace Engineer
Remove invalid nonsense for email.

(Derek Lyons) wrote

(Allen Thomson) wrote:

But these are perhaps different days, and it might be worthwhile to
consider what somewhat pervasive computation could do for a Mars-
or Jupiter-ship.

Quite a bit. But very little of that pervasive computation really
needs heavy horsepower for extended periods.

No argument. I was thinking of a bunch of Z80s monitoring joints,
pressures, temperatures, gas composition, vibration, etc., etc.
throughout the ship. They'd initiate local action and/or report
up the line to the higher-level processors or even the crew.

Active and continuous monitoring of the life/support ecosystem could
probably be done with a 286 or maybe a 386.

Ecosystems can get complex, and even if a 386 could keep track of
things in detail, it might be better to have the flock of Z80s tending
to local matters and reporting up the line to one or more 386s for
the sake of redundancy and robustness.

Ditto for the propulsion system, unless it's *really* horridly
complex.

That, actually, is another interesting question, now that you
mention it. Properly operated reactors are not currently all
that fussy, do not need second-by-second control of many parameters
to be kept in rein. But consider the analogy with some fly-by-wire
aircraft which achieve high performance at the price of intrinsic
instability that is kept in check only by constant, fine-grained
computer intervention.

This is definitely a NIMBY thing, but has anyone ever looked at
what performance advantages an intrinsically unstable reactor under
active control might have? Especially in the context of the kinds
of reactor that would be suitable for spacecraft propulsion?

jeff findley wrote:

(Derek Lyons) writes:

Ok, I'll ask again; Why would an 'interim' vehicle have to meet the
'final' specs?

It doesn't.

Then why the claim that the various deficiencies of the Soyuz as
compared to the CRV "If this were a *real* requirement, NASA would
never accepted Soyuz as an interim emergency return vehicle."

My point is that when funding is repeatedly denied for
the "operational" vehicle due to cost, eventually the "interim"
vehicle becomes the "operational" vehicle. This can indicate that the
"final" specs were set too high (which generally translates into
higher development costs).

Where do you dream this stuff up? Accepting an interim vehicle as the
final vehicle because the actual final vehicle was never built says no
such thing. It says the final vehicle was never built and nothing
more.

For example, the house we are living in is 'interim', but acceptable.
It does not remotely meet what we really want or need. If our plans
fail and we are stuck in this house, that does not magically make it
meet those wants and needs, it was, is, and remains merely acceptable.

D.
--
Touch-twice life. Eat. Drink. Laugh.

rk wrote:

However, the major part of utilizing computing throughout a large vehicle
is not the computational element but the communications. Bus adapters,
couplers, cabling, etc., is very expensive.

And heavy. And, once you take NASA-STD-3000 human factors requirements (for
maintenance/repair/replacement) into account, they take up lots and lots of
volume.

--
Herb Schaltegger, B.S., J.D.
Reformed Aerospace Engineer
Remove invalid nonsense for email.

rk wrote:

Heck, just consider the mass of the
wiring (redundant of course) running through a large vehicle and then
compute the effective cost in launching it in $/kg.

Sure. On SSF, when it became apparent that we wouldn't be able to launch a
fully-outfitted Lab or Hab module, the program approved cash bonuses for
design engineers who came up with weight-reduction design changes. The
greater the reduction, the greater the bonus. For some reason, we never got
those in the ARS group; our hardware just kept getting heavier, noisier,
more expensive and more power-hungry . . . ;-)

--
Herb Schaltegger, B.S., J.D.
Reformed Aerospace Engineer
Remove invalid nonsense for email.

(Allen Thomson) wrote:

(Derek Lyons) wrote

(Allen Thomson) wrote:

But these are perhaps different days, and it might be worthwhile to
consider what somewhat pervasive computation could do for a Mars-
or Jupiter-ship.

Quite a bit. But very little of that pervasive computation really
needs heavy horsepower for extended periods.

No argument. I was thinking of a bunch of Z80s monitoring joints,
pressures, temperatures, gas composition, vibration, etc., etc.
throughout the ship. They'd initiate local action and/or report
up the line to the higher-level processors or even the crew.

The problem is, you can't really initiate local action sometimes
without knowing the global state. This means that a simple Z80 will
no longer suffice. With the need to provide increased bandwidth
between processors, more powerful local processors, more connections
(real and or virtual) to control elements... You drive up cost,
weight, complexity, *without* adding significant functionality (unless
your ship is truly huge, say about the size of a CVN) over a
centralized control system.

D.
--
Touch-twice life. Eat. Drink. Laugh.

"Bruce Sterling Woodcock" wrote in news:2Em3c.7716
:


"jeff findley" wrote in message
...
NASA wrote the specs so that *any* capsule would not be able to meet
the design, yet they chose to accept an interim vehicle that's far
worse than what a modern capsule could do. Excluding a simple capsule
design for a CRV insured that much research and development would have
to be done. Note that the HL-20 program (lifting body CRV) started in
1989 and the X-38 program started in 1995 (another lifting body CRV).

Note that the vast majority of said research was already done years ago,
with the Air Force's X-24A, the Shuttle, and a few other places.
Development would be required either way and the X-38 CRV's was actually
half done when canceled.


These sorts of overly aggressive requirements left us where we are
today (no US CRV at all). It's starting to look like the shuttle
might be the only manned US vehicle ever to dock with ISS.

But I don't think it's fair to say it was overly agressive in terms
of requirements. Only in cost. And in fact, assuming there were
no major issues with the X-38 (unlike the X-33), there was very
little additional funding required in order to start making and
deploying the CRV.

Exactly, it wasn't even close to being overly aggressive... That program
knew exactly what the actual mission requirements were for the vehicle's
job and focused on fulfilling those requirement without bloat (i.e. lets
add this, increase that, oh wouldn't this be nice, etc.). And they were
actually doing that better then some thought possible. Given just a little
more money (perhaps another $B) we'd have a few ready to go NEXT YEAR! It
would have finished with an overall development cost around $4 Billion, a
mear fraction of the cost of any other manned space craft...

Instead, O'Keefe canceled it 1/2 - 3/4 way through because it was
[supposedly] too focussed on a singular mission... But that singular
mission was precisely why it was being so cheap to develop. And I said
supposedly because, I see no reason why the X-38 based CRV couldn't have
been finished, then be used as the bases for a more advanced vehicle
capably of manned ascent on an ELV as well as independent rendezvous &
docking capability (aka a CTV!)... Its space tested systems, the Parafoil
landing system, and possibly even its basic aerodynamic shape could have
been directly applied to the other. Seems like NASA has done something
similar before, oh yea, they were called Mercury & Gemini... They built
what they could quickly and launched on what existed to answer an immediate
need, aka Mercury. Then they increased capability by a little increase in
scale of the basic shape to accommodate two people, added on-orbit
maneuvering systems & a primitive docking system to checkout rendezvous &
docking techniques, aka Gemini.

Now we've gone from CRV to OSP/CTV to CEV, each time this happens the
complexity goes up, the price goes up, and the deployment date moves ahead
5 years. No wonder NASA hasn't been able to build a next gen craft to
replace STS, or even seriously upgrade STS systems toward safer operation,
the dam flag pole gets moved every few years! If its not Congress or
whoever is President at any given time, its NASA's own Administrator!



I think it's very dangerous to take from this, though, that NASA
should stick to cheaper but less capable capsule designs, so
there is less chance their funding will be cut for such a program.

And its clear even that wouldn't prevent it... People complain STS is so
expensive cus it was made to do way to many things in one vehicle. But
when they try to make something that does do just one or two things well
(X-38 CRV), to make it much less expense, people complain its not versatile
enough.


Bruce

--
David,

--------------The Speed of Light---------------
---------------300,000 km/second---------------
----Its not just a good idea, it's the law!----