PBS's "Nova" and MER

Diane Wilson wrote:
None of this is new; fault-tolerance concepts and continuous
operation have been around for a long time. A lot of our
key infrastructure items (think about phone systems, power,
etc.) run this way.

And a lot of time and money is spent ensuring that the redundancy and
fault tolerance *works*. The concepts are simple, but the execution
is far from it.

D.
--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.

In article ,
Pat Flannery wrote:
Are you under the impression that such things never happened on the old
slower/costlier/worse projects? If so, you are sadly mistaken.

I was concerned about the compressed timeline that was being used; when
you are within six months of launch, and your parachute system hasn't
been successfully tested yet, things seem too rushed.

Something has to be tested last, and if it doesn't work, you typically
don't have much time left to do something about it. And you've missed my
point: why do you assume that this is unusual, or restricted to the new
F/B/C projects? When the Viking life-detection package ran very late,
upper management ordered a "tiger team" review... which concluded that it
could not possibly be finished in time. By Herculean efforts, it was.

Before taking dire stories about current projects as a sign of degeneration
and mismanagement, one should always actually *compare* them to earlier
projects. Often this is an eye-opener. I'm currently reading Kraemer's
"Beyond the Moon", which is a very interesting upper-management view of
the 1970s planetary missions.

It's easy to say that a bit more money and time would fix these things,
but in practice, that's not what the money and time get used for -- they
get used to make the mission more ambitious instead.

As I stated in the original posting, they had five "iffy" things to fix...

Yeah, so? Why do you assume that this sort of last-minute scramble is new?

The most telling argument against "more money would make these problems
go away" is that we have plenty of evidence that *it doesn't*.

Pioneer 10 & 11 had time and money on their sides; both worked great.

Dan Goldin (just arrived as the new NASA Administrator) to Bob Kraemer
(who has just introduced himself): "Oh, I remember you. You were that
SOB from NASA Headquarters that pounded us bloody on Pioneer costs."
Kraemer also notes that it took considerable effort to get the Pioneer 10
instruments delivered in time to make the launch window.

Viking 1 & 2 had lots of money and time; both worked great; both the
orbiters...and landers.

Viking development was full of budget and schedule crises. Kraemer again:
"I took pride in having no overruns in Planetary Programs and never
handing my boss... a budget problem... But there was no way I could cover
the Viking overruns..." The only reason the project didn't get cut back
substantially was that top management badly wanted a major PR success in
the mid-1970s and didn't think ASTP was going to be it.

Voyager 1 & 2 had lots of money and time...

The Voyagers had major cutbacks before they were even named; remember that
they started as a four-spacecraft Grand Tour program. And it was only
thanks to the technical cutbacks that they had ample time, since their
launch window had little room for argument.

The only big-budget long-span program semi-flop we have had was Galileo;
and its problems were as much due to a hurried redesign of its launch
method and trajectory as anything else...

Most of Galileo's troubles -- and there were a lot more than you read
about in the newspaper headlines, e.g. the explosion-prone thrusters --
were designed in long before the last-minute changes in launch.

In comparison to this, our lower-cost fast timeline missions are running
around 50% as to success rate.

You've forgotten to count a few little failures like Mars Observer. And
the low-cost stuff has done rather better than 50%.

There's nothing particularly wrong with that, if you think of software
uploads as routine practice rather than as a dire emergency measure.

What happens if you launch them, and then run into some
software-spacecraft compatibility problem that can't be fixed before the
time that the software is needed, due to a compatibility problem that
can't be fixed in-flight; but could have been found via ground testing
of the systems and software on the ground prior to launch?

This is called "bad luck". :-) There are various measures you can take
to reduce the probability of such problems. Note that such problems are
not precluded by a policy of having all software on board at launch time,
as witness the Huygens receiver problem (which might have been fixable
had a software upload been possible...), not to mention MPL, not to
mention the Voyager safemode problems (which required substantial changes
to the Voyager on-board software not long after launch).

And actually, young is good. An unfortunately large fraction of the
middle-aged people at JPL, and NASA in general, are viewgraph engineers
whose net contribution to a fast-paced results-oriented project would be
negative...

But some of the old guys might have pointed out that you may want to put
a method on the outside of one or more of the three MER lander petals
that would let you get the rover out if you needed to work on it without
firing the pyros...

They *might* have done so, in 20-20 hindsight. There's no guarantee that
they would have. It's not like there haven't been embarrassing oversights
in earlier programs. (Testing Galileo's star scanner in only two possible
attitudes was not exactly good engineering judgement at work, nor was
wiring the Galileo probe's G-switches backward.)
--
MOST launched 30 June; science observations running | Henry Spencer
since Oct; first surprises seen; papers pending. |

On Tue, 6 Jan 2004, JimO wrote:


"Pat Flannery" wrote in message
...
The only big-budget long-span program semi-flop we have had was Galileo;
and its problems were as much due to a hurried redesign of its launch
method and trajectory as anything else, and it still got a lot of its
job done at Jupiter.
In comparison to this, our lower-cost fast timeline missions are running
around 50% as to success rate.

While agreeing with your main point, I also nominate MO as an expensive
project that wasted money by failing.

If it's not unfair to include projects that never got launched at all, add
Lunar Observer and CRAF to the list of big-budget, long-span program flops.

After Voyager and Viking, in the era of Galileo and VOIR (later downsized to
Magellan), interplanetary probes were getting expensive, infrequent, and
loaded with experiments.

Mars Observer, Lunar Observer, Cassini, and Comet Rendezvous-Asteroid Flyby
all began as attempts to control costs. Using common hardware for a series
of spacecraft seemed an idea worth trying.

By the standards of later Discovery missions, though, they were still pretty
expensive. CRAF and LO didn't survive to be launched. MO (LO's sister)
failed upon injection into Mars orbit. NASA's Cassini (CRAF's sister) alone
survives (knock wood) and will reach Saturn next summer.

To me, short development cycles, tight budgets, and frequent flight
opportunities still seem like a pretty good idea. They are not appropriate
for every kind of mission, but they seem to be effective, so far, as a part
of the U.S. interplanetary exploration effort.

The Mars effort is leading up to a sample return lander, and I would love to
see JIMO or something like it visit Jupiter; you're not going to build those
on Discovery budgets.

Nevertheless, a cadre of people who have designed and managed in Faster,
Cheaper, Better spacecraft programs may well be valuable in attempting
grander missions.

--
Bill Higgins | They can have my World Almanac
Fermilab | when they pry it from my cold, dead fingers.
Internet: | Or when next year's edition comes out, whichever is first.
| --Lois A. Fundis

On Mon, 5 Jan 2004, Pat Flannery wrote:
Henry Spencer wrote:

Are you under the impression that such things never happened on the old
slower/costlier/worse projects? If so, you are sadly mistaken.

I was concerned about the compressed timeline that was being used; when
you are within six months of launch, and your parachute system hasn't
been successfully tested yet, things seem too rushed.

I didn't see the show-- but wasn't a Mars rover originally planned to launch
at the 2001 opportunity? The loss of MPL and MCO caused the Mars program to
fall back and regroup. So maybe they did have extra time, in some sense.

--
"A good rule of thumb is: If | Bill Higgins
Henry Spencer says something you | Fermi National Accelerator Laboratory
disagree with, then you're wrong." | Internet:
--Tom Fitzgerald, |

On Tue, 06 Jan 2004 18:09:15 GMT, (Derek
Lyons) wrote:

Scott Ferrin wrote:

Even if that is the case (it's been a while since I saw the show about
the construction of the Truman but I'd have sworn they were outdoors
when they bolted the sections together) that is still a far cry from
"the levelest and flattest floor in the world".

Sorry, you are *WRONG*. Don't confuse the assembly of the shaft
segments (which is done on the pier) with the alignment of the shaft
segments and the alignment of the shaft itself, which is done once
installation is complete.

D.


In case you didn't notice I admitted I was *WRONG* but it seems you
think you have cause to celebrate so I guess that justifies your
enthusiasm.

In article , Henry Spencer wrote:

This is called "bad luck". :-) There are various measures you can take
to reduce the probability of such problems. Note that such problems are
not precluded by a policy of having all software on board at launch time,
as witness the Huygens receiver problem (which might have been fixable
had a software upload been possible...), not to mention MPL, not to

This reminds me. Didn't MPL get an emergency software upload, as a
result of the MCO loss - which did help, in that it got into the
atmosphere and lasted long enough for a different software glitch to
kill it - or am I thinking at crossed purposes here?

Oh - Hyugens reciever problem? As in Cassini/Hyugens?

--
-Andrew Gray

Andrew Gray wrote:

Oh - Hyugens reciever problem? As in Cassini/Hyugens?


Have they ever fixed the Euro-U.S. compatibility screw-up in regards to
that?

Pat

Henry Spencer wrote:

In article ,
Brett Buck wrote:

... The technology and missions are so unforgiving that even tiny
problems have to be addressed, and beaten to death. That takes time and
money - there's no getting around it.


Actually, it's perfectly reasonable to simply accept a modest amount of
risk... especially since you are *always* doing that anyway, because you
can never anticipate all the problems. (At no time did Apollo planning
ever consider the possibility of losing all oxygen and all electrical
power in the CSM; studies of the "LM lifeboat" were confined to using the
LM *engine* to cover for a CSM propulsion failure.) A sense of proportion
is needed; you can waste unlimited amounts of money on unlikely what-ifs.

If you want to have a "sense of proportion" and "modest risk" then I
suggest that everyone that excoriates NASA for Challenger (why should we
wait just because it's out of the qual temperature envelope, what are
the odds), Columbia (we had a lot of foam hits, it's just a maintanence
issue, what are the chances) , Mars Observer (pyro valves are really
reliable, why bother running a full up test), MCO (we navigated for
years, we always get it right, we'll figure out what's wrong later), MPL
(we can't afford to do a full-up retest ever time we change the wiring
harness, and anyway, the software spec says it's OK), whatever the next
one will be, to retract their comments. You can't at the same time bitch
mercilessly about program failures caused by "unlikely what-ifs" coming
true, and trying to cheap out on retiring risk by "having a sense of
proportion".

It's been my experience (over the last 20 years and being in the
front lines for the development and launch activities for 11
spacecraft, all of which were more complex than a NASA probe) that
virtually every time you ignore something based on a "sense of
proportion" that it comes back to bite you later. In fact, I can only
think of one item out of about 25 or so "potentially serious but not
pursued as unlikely and/or too difficult to fully analyze or fix"
problems that didn't ultimately boomerang on us. Fortunately, only one
was fatal to the project, but they were all severly impacting in
practice and also far more expensive and time consuming to correct
afterwards than they ever would have cost to address up front.

You have the kernel of a valid point in that the management tends to
waste money. Money wasted by management is money wasted. But if you
simply got rid the waste, for the most part, you wouldn't improve the
likelihood of success. The budgets are generally *right* - the money
wasted my inefficient management needs to be applied to more rigor in
development and testing.

Brett

On Mon, 05 Jan 2004 20:25:24 -0600, Pat Flannery
wrote:

In comparison to this, our lower-cost fast timeline missions are running
around 50% as to success rate.

Mars Pathfinder - Success
Mars Global Surveyor - Success
NEAR Shoemaker - Success
Lunar Prospector - Success
Mars Climate Orbiter - Failure
Mars Polar Lander - Failure
Stardust - In Progress
Mars Odyssey - Success
Genesis - In Progress
CONTOUR - Failure
MER Spirit - In Progress
MER Opportunity - In Progress

5 successes, 3 failures, 4 TBD.


Brian

Scott Ferrin wrote:

In case you didn't notice I admitted I was *WRONG*

Um, no. You didn't.

You stated 'if that was the case', which is not an admission of being
wrong, but a dodge. You then restated your original, and incorrect,
thesis that the alignment was a far cry from the 'level, flat' floor.

but it seems you think you have cause to celebrate so I guess that
justifies your enthusiasm.

It's not enthusiasm, but pointing out that statement that was wrong
remains wrong when restated.

D.
--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.