PBS's "Nova" and MER

Henry Spencer wrote:

In article ,
Scott Hedrick wrote:
(It'd be an interesting detail to see a list of what *is* sitting in the
clean rooms with no definite plan for the future...)

As to *unclean* rooms, I seem to recall reading many years ago (10+) that
the Navy reclaimed a satellite that had been hanging in the Smithsonian
for several years and successfully flew it.

So long as there aren't any serious optics involved, the need for clean
rooms for space hardware is much exaggerated. The practice of doing
everything in clean rooms was a quick fix for some early problems on
spacecraft which did have optics, and when it appeared to work, it quickly
became entrenched superstition.

Clean rooms have their place where there is any issue involving particulate
contamination. This can (and often does) include electical work (not
necessarily just microelectronics) and anything involving elastomeric
seals, for example; you don't want any kind of grit (or hair or clothing
fluff or . . .) abrading a mission-critical data cable or a seal on a
vacuum valve. That doesn't mean you need a Class 1,000 clean room for every
spacecraft assembly task but you might require a Class 10,000 or 100,000
facility.

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

Henry Spencer wrote:
In article ,
Scott Hedrick wrote:

(It'd be an interesting detail to see a list of what *is* sitting in the
clean rooms with no definite plan for the future...)

As to *unclean* rooms, I seem to recall reading many years ago (10+) that
the Navy reclaimed a satellite that had been hanging in the Smithsonian for
several years and successfully flew it.


So long as there aren't any serious optics involved, the need for clean
rooms for space hardware is much exaggerated. The practice of doing
everything in clean rooms was a quick fix for some early problems on
spacecraft which did have optics, and when it appeared to work, it quickly
became entrenched superstition.

In some cases, maybe. But contamination issues are incredibly
common, even with supposedly clean processes. Gyros, thrusters, reaction
wheels, etc. are quite prone to contamination issues, and *absolutely
do* need clean-room procedures of various classes during their
manufacturing. Once the whole spacecraft is built up, then there is less
problem, but even then any sort of optical sensor, or even worse,
thrusters, are exceptionally prone to getting contaminated and thus not
working properly, even despite extraordinary efforts to prevent it.

And don't even get me started on the topic of various fluids and or
adhesives like grease and epoxy. Contamination is a constant battle.

Brett

(Henry Spencer) writes:
The alternative is to insist that the software must be officially finished
before launch, while privately conceding that it may have to be fixed up
afterward because of the tight schedule; this does not actually strike me
as an improvement on letting the developers do the job right once.

Every onboard SW project I've ever worked on (admitedly only one that
actually flew, but several orphans as well) has taken that line, at
least officially: SW must be "done" before launch. In practice, the
Oersted satellite would have been space-scrap if we hadn't designed
in the ability to upload permanent patches.

I concur with the viewpoint that SW is best kept as HW's child, rather
than sibling (and I speak as an electrical engineer). Design the HW
the best you can, freeze it as early as you can (of course after testing),
but accept that meaningful SW development cannot really commence until
the HW exists (or is at least mostly spec'ed out). The SW guys will do
a better job if they're designing it to real HW, but that does mean they
do their job uncomfortably close to the lanuch deadline, and may not
even be done then. Just make sure that the functional kernel of the
SW (including a safe and robust patch mechanism with fall-backs) works
well; but other stuff can be fixed on the fly.

grant..

On Fri, 09 Jan 2004 16:56:55 +0000, Henry Spencer wrote:

So long as there aren't any serious optics involved, the need for clean
rooms for space hardware is much exaggerated. The practice of doing
everything in clean rooms was a quick fix for some early problems on
spacecraft which did have optics, and when it appeared to work, it quickly
became entrenched superstition.

In the case of manned spacecraft, the clean room requirement didn't spring
from optics, for Mercury and Gemini the driver was more to avoid
contamination of fluid and gas systems. For more on this look at the
"Spacecraft Fabrication" section of the Gemini press kit which is
available on-line at http://www.apollosaturn.com/geminiNR/sec12.htm
This section describes the procedures used in fabricating both Gemini and
Mercury spacecraft.

I don't believe that whatever optics these spacecraft had such as
periscopes, horizon scanners and the like were the driving force behind
the use of clean rooms in manufacture and assembly.

Bill Higgins wrote in message nal.gov...
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 engineer in me agrees with your point. However Joe Sixpack, Jay
leno, and the Congresscritters see no difference between a classic
unmanned mega buck s/c like Voyager or Viking or a faster, better,
cheaper albeit riskier unmanned spacecraft. One of the reasons why the
great unmanned missions of the 70's and early 80's were less likely to
fail was because NASA threw gobs of development money at them. The FBC
approach meant less development money and less development time,
therefore more chances of failure. All us space geeks here on this
group know that but the Capitol Hill Mob, the man-in-the-street, and
late-night comedians don't know or care...


Gene DiGennaro
Baltimore, Md.

In article , Grant Goodes
wrote:

(Henry Spencer) writes:
The alternative is to insist that the software must be officially finished
before launch, while privately conceding that it may have to be fixed up
afterward because of the tight schedule; this does not actually strike me
as an improvement on letting the developers do the job right once.

Every onboard SW project I've ever worked on (admitedly only one that
actually flew, but several orphans as well) has taken that line, at
least officially: SW must be "done" before launch. In practice, the
Oersted satellite would have been space-scrap if we hadn't designed
in the ability to upload permanent patches.

I am writing the science software for the BAT instrument on the Swift
gamma ray burst (GRB) observatory, which will launch in a few months.
http://swift.gsfc.nasa.gov/
My software is 'done' and will be loaded onto the flight computer after
another ~week of testing, if all goes well. This is the version of
the software that will be on the instrument when we launch.

We expect this software will work (after a lot of tweaking of the
literally thousands of operating parameters), but We Do Not Know enough
about GRBs to know the optimal way to detect and observe them, and we
don't know enough about other things that might cause false triggers.
My software can be adjusted to cover a lot of this phase space (hence
the thousands of parameters) but it may be that there is a better way
to look at them. If GRBs were completely understood, there'd be no
point in flying the mission.

As part of the specification, we demanded the ability to upload a
complete new set of software. (The power-up boot uses code that is
stored in a non-writeable bank EEPROM and has enough capability to
support uploading a full software system to writeable EEPROM and then
rebooting from the new code.)

On another GRB spacecraft (HETE), all the science code is stored in
volatile memory, and is uploaded after each power cycle, or when
another change is needed. This has allowed agile software advancement
as more was learned about the spacecraft operations and about the
astrophysical sources.

I concur with the viewpoint that SW is best kept as HW's child, rather
than sibling (and I speak as an electrical engineer). Design the HW
the best you can, freeze it as early as you can (of course after testing),
but accept that meaningful SW development cannot really commence until
the HW exists (or is at least mostly spec'ed out). The SW guys will do
a better job if they're designing it to real HW, but that does mean they
do their job uncomfortably close to the lanuch deadline, and may not
even be done then. Just make sure that the functional kernel of the
SW (including a safe and robust patch mechanism with fall-backs) works
well; but other stuff can be fixed on the fly.

On Swift, I worked with the hardware designers to make what came out of
the hardware more efficiently processable by the software I was
developing at the same time. (Things like the order in which bits are
packed into structures, how much the data should be blocked up, etc.
are very important when you are trying to process 34kHz of random
events on a 25 MHz processor.) But for that I only had to co-optimize
the innermost loops of my software with the hardware, a very small but
important bit of code. The HW design was complete years ago, but I
just finished coding last month.

The hardware is excellent, but with 32,768 individual detectors, there
will not be perfection.

I designed my software to take care of most of the expected ways the
system can operate non-ideally. Then as the hardware was built and we
started to gain experience with it, I changed my design to take care of
the unexpected ways it operates non-ideally on the ground.

I expect that when this thing is launched, the hardware will find new
and interesting ways to behave. And I will have to modify the code in
to compensate.

I have a lot of advantages over the Mars folk on this project. This is
a LEO mission rather than a planetary probe, so if internal or external
forces require a code patch that takes a few weeks to prepare, the cost
will be a few weeks worth of science rather than an embarassing amount
of debris spread over red plains. The spacecraft safety and attitude
control is handled by the spacecraft ACS system and software, which is
being produced by a company that has built previous systems--My
software sees a GRB go off and says 'OOH SHINY--point over there' and
the spacecraft says 'that's the Sun you idiot, I'm not going to point
there' and doesn't fry the optics of the other telescopes on board.


But even with all that, this project is not easy. It has much better
odds than a Mars probe (are those still below 50-50?) but complacency
is notably absent. I feel the odds of the current version of my
software working 'good enough' to get good science are above 75%, and
most of the remaining 25% chance is due to unexpected hardware
behaviour that can be worked around in the software to some extent.
But I am 90% sure that after year of operations I will be able to
produce better science with improvements in the code based on what we
learn after launch. And we have the opportunity to implement that,
unlike hardware changes.

--
David M. Palmer (formerly @clark.net, @ematic.com)

On Fri, 09 Jan 2004 23:43:01 -0700, "David M. Palmer"
wrote:

I am writing the science software for the BAT instrument on the Swift
gamma ray burst (GRB) observatory, which will launch in a few months.
http://swift.gsfc.nasa.gov/

....And before the trolls descend and drown us out, on behalf of
everyone here let me wish you guys all the luck. Not only on a
successful launch, but on finally catching one of those bursts in the
act. Hopefully this will finally disprove the long-standing theory
that they're being caused by God/Yahweh/TrueAllah/Roddenberry playing
around with a Polaroid Instamatic :-)


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

On 9 Jan 2004 20:16:31 -0800, (Gene
DiGennaro) wrote:

All us space geeks here on this group know that but the Capitol Hill Mob, the man-in-the-street, and
late-night comedians don't know or care...

....Which is why they all - especially that dip**** Leno - should be
taken out and shot so they won't contaminate the gene pool any
further.

OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

Kevin Willoughby wrote:

Once the spacecraft is
launched, the landing software becomes quintessentially "hard real
time", I.e., "the right answer at the wrong time is wrong".


Before this goes any further, on rewatching the program they stated that
the software that remained to be written concerned the rovers ability to
navigate on the surface; _not_ the landing phase, I'm sorry that I got
that wrong (either that, or the show got changed between showing 1 and
showing 2), and it was my screw-up. Of course if the thing successfully
lands and you can't run the rovers because the software isn't finished
or won't work right, then you are still up the creek.
But it was a major misstatement on my part in regard to the "Nova" show
in question. :-[

Sheepishly,

Pat

Pat Flannery writes:

Kevin Willoughby wrote:

Once the spacecraft is launched, the landing software becomes
quintessentially "hard real time", I.e., "the right answer at the wrong time
is wrong".

Before this goes any further, on rewatching the program they stated that the
software that remained to be written concerned the rovers ability to navigate
on the surface;

So is this the actual reason they're not rolling off base petal? The
code will be ready real soon now?