PART 1: Non-essential Government work
PART 2: ProbeSquash activity: Installment #4
PART 3: Extra work helps get ready in case the recorder fails again
PART 4: Problems with time tag data

The Online from Jupiter project is classified as "non-essential 
government work". As a result, it is subject to the US Federal 
Government shutdown. I have been instructed to defer sending
additional messages until the furlough is lifted for NASA contractors.  
Hopefully the shutdown will be brief, since the Galileo spacecraft and 
the Jupiter encounter wait for no political leadership.

To recap, we suggest that after each Probe Squash installment, you
and your students make a prediction about how long the Probe's
mission will last.

Installment #4: The Big Five (Spacecraft design issues)

Once the Probe's mission starts, there are five things that might limit 
the Probe's lifetime: 

 - Jupiter's high pressure 
 - temperature 
 - the Probe's battery lifetime 
 - maintaining a radio link between the Probe and Orbiter through
   the increasingly dense atmosphere
 - or the constraints of the Orbiter's mission which will force it to
   stop listening for the Probe's signal

Over the next few weeks, we'll take a closer look at each of these 
threats to the Probe's mission, to give you more information to help 
in predicting how long the Probe mission will last.

General Design Issues

When designing a spacecraft, engineers and scientists work together 
to say what limits they'd like the spacecraft to reach. For example, an 
atmospheric scientist might say that she would like to be able to 
have the Probe reach down to a pressure level 14 times that of Earth. 
The engineers assigned with building the actual probe will then 
design a probe that can take that much pressure--and more, just as a 
safety margin. This is the design limit. 

Next, engineers need to check that the hardware that they've built 
can actually stand up to real-use conditions. This means that they 
must test it under conditions that are more severe than are expected 
in the flight. One good rule of thumb is to test to 125% of the 
expected flight use, which is enough to guarantee that the design of 
the hardware will be able to survive the real mission. However, you 
don't want to run your test all the way out to the design limit, since 
that's where it's more likely that the hardware will fail! This process 
is called qualification testing. Any hardware that goes through a qual 
test does not get flown because the testing itself over stresses the 
hardware. But having passed this test, the hardware design is 
assumed to be qualified and any hardware that uses this same 
design is qualified as well. 

Finally, the actual piece of hardware that will be flown into space 
gets tested as well, to 80% of the expected mission load. This checks 
that the equipment doesn't have any flaws, while at the same time 
not putting enough stress on the equipment to possibly cause it to 
fail at a critical time during the space flight! This is the actual 
acceptance test. A piece of hardware that passes this level is 
assumed to be okay for the actual flight.

To summarize,

1) Design limit is most stringent, but no hardware is tested to this 
level

2) Qualification test level is less stringent than the design limit, but 
exceeds the expected mission load. The hardware design is tested at 
this level, but the actual pieces of hardware that are tested are not 
used in flight. 

3) Acceptance test level is the least stringent, falling slightly below 
the expected mission load. Hardware is tested at this level, and can 
then be used on a mission. 

A GENERAL WARNING: the Probe, or any one part of the Probe, won't 
suddenly stop performing once the Probe passes beyond the 
acceptance or qualification limits. Engineers on the Probe Engineering 
Team expect the Probe to keep performing beyond these limits, 
beyond the battery voltage cut-off, and beyond the nominal (or 
expected) radio frequency link performance value. However, how far 
the Probe can go beyond those limits is an entirely different 
question--and one that we haven't tested for! 

November 9, 1995
About a month ago people in my work area were so overjoyed. We 
had started JAA, the first sequence of commands for Jupiter 
encounter. On paper, we had entered the mission phase called "Jovian 
Operations." "Earth-Jupiter Cruise," the mission phase we'd just 
finished, lasted almost three years. Both the asteroid Ida encounter 
and Shoemaker-Levy/9 comet collision observations occurred during 
"EJ cruise." But now we are in main mission. If we won the lottery 
would we continue to see it through?

Then there was the tape recorder anomaly.  Without a tape recorder, 
the current mission design and current sequences for Galileo's 
computers could not be used. What would we do? The answer 
was...redesign, fast! Many people on Galileo have been working days, 
evenings, and weekends planning what to do if the tape recorder 
really stops working (not just scaring us into thinking that it was 
broken as it did three weeks ago). Also, project management is 
deciding how to modify the existing plans for the spacecraft's 
activities, so that we use the tape recorder less, and don't rely on it 
as heavily as we do now. For example, we removed all imaging of Io 
(Jupiter's volcanic moon) during our approach to Jupiter to simplify 
the real job of getting into orbit. Since we are not planning to return 
to Io, many of us are real disappointed with this decision.

Yesterday we held an all day review.  People from each team got up 
and presented the results of the last three weeks of planning. How 
would we run the Galileo spacecraft without a working tape 
recorder? The meeting was both intense and a good place to take a 
nap. (I even wore a skirt, a real change for me.) The basic theme was 
that lots of software and documentation needs to be modified, and 
sequences of spacecraft commands need to be reviewed and changed, 
representing months of work for dozens of people who would 
otherwise be reasonably busy running the mission as it is. Much of 
this work will be done by people working extra, unpaid hours, at 
night or on weekends. But, if we did lose the tape recorder, we'd be 
ready to switch over to our alternate plans and continue the mission.

We haven't yet recaptured the feelings we had entering the Jupiter 
approach period, but the incredible team work under pressure to 
develop a realistic plan has been inspiring.

When I'm not worried about Galileo, I normally do mom things, such 
as worry about whether my daughter will get a good part in the 
Children's Theater Network's performance of Joseph and His 
Technicolor Dream Coat (Jan. 25 - 28, 1996 at the California State 
University at Northridge) and I work with my son planning his Bar 
Mitzvah.  

November 10, 1995
It's 8 am on Friday morning and I've been here since 10 pm last 
night. Our team conducted an Operational Readiness Test (ORT, for 
short).  That went well but a much larger problem looms on the 
horizon. The equipment at the station that records our data is 
apparently not working correctly. The data file on the magnetic tape 
has "headers" (something that tells us what data is coming up next) 
which time-tag the information. The scientists working on the 
experiment  *must* have the time tags in order to analyze the data.  
The time tags are being duplicated or they are being
skipped - we don't know why.

This is a VERY big problem. We are only four weeks from our 
experiment (on December 8). We think right now that the problem is 
with a piece of equipment which was replaced in July of this year, so 
the solution is to go back to using the old piece of equipment.  But, 
the Project has placed a configuration freeze on the Deep Space 
Network, or DSN (the network of tracking stations around the world 
thru which the Project receives all of its data), meaning that nothing 
is supposed to be changed around at the DSN.  The configuration 
freeze is meant to insure that we are ready for arrival at Jupiter; we 
want to be sure that no one changes *anything* that could possibly 
affect the Project's ability to receive telemetry or tracking 
information or to command the spacecraft.  Basically, "if it ain't 
broke, don't fix it." We will have to appeal our case to the Project 
management and request an exception to the freeze. Since the Radio 
Science system is independent from the command, telemetry, and 
tracking systems (the most critical systems), we think we have a 
good chance for having our request granted.

A common question I've been getting is "How did we come this far 
and get this close to the experiment without previously detecting this 
problem?" Well, one factor is that we're switching our work between 
two different computers. That meant that some of the software that 
we'd normally use to check for problems couldn't be used, so we 
were relying on the investigators (the scientists working on the Radio 
Science experiment) to help us check that the data tapes were okay.  
We checked areas that we thought might cause problems (by 
performing what's known as a spectral analysis of the data) but we 
didn't check on the header information, because we didn't think 
there'd be any problems there. This portion of the tape was NOT 
supposed to have changed. 

Our investigators pointed out some discrepancies back on October 23 
but we figured it was a problem in reading the data off the tape - not 
a real problem with the data on the tape. It was last week (11/3) 
that the investigators sent us an e-mail detailing the problems they 
were seeing. That's when we knew that there was a real problem.

Once we've received an OK from the Project to change back to the old 
system, we'll still have a lot of work ahead of us. Our experiment 
takes place over the ground station in Madrid, Spain, so there will be 
different people actually running the experiment. To make sure that 
everything goes as planned, the Operations Engineer must put 
together a detailed script telling the station personnel in Spain what 
to do, step by step.

Then, we must test the old system to insure that it is still working 
and that we don't see the same problems. If we get the approval 
weeks before our experiment. I believe that everything MUST be 
ready at least one week before the experiment. That leaves us with 
two weeks to implement and test the old system. That is cutting it 
VERY close.

Boy, considering that a week ago, I thought that we would easily 
slide into home plate,  whew!!  The next few weeks are going to be 
very busy. Luckily, I'm sailing to Catalina Island this weekend with 
four other friends.  Sort of the calm before the storm......ciao!