PART 1: ProbeSquash activity: Installment #3
PART 2: Using computers - safely!
PART 3: The cost of the tape recorder's hiccups

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  #3: The Probe's Parachute:

When the Probe comes barreling into Jupiter's atmosphere, it's
traveling at around 106,000 miles per hour, far too fast for it to be
able to take a good look around. When the heat shield has slowed the
Probe to a speed of 1,800 mph, the pilot chute is deployed. The chute
is fired into the wake by a mortar. After this, the explosive nuts fire
to release the aft cover, which in turn pulls out the bag of the main
parachute.  All of the parachute activity occurs in less than two
seconds.

The main parachute is 8.2 feet in diameter, and is made of Dacron
and Kevlar.

And now, the real test of the Probe's longevity begins!

October 26, 1995
As an engineer on the Mission Control Team, people often ask me "Do
you use computers a lot on Galileo?" The answer, of course, is "Yes"
but I would like to share with you an aspect of computer programs that
most folks don't think about when they are at home playing "Math
Blaster" or "Sim City" on their PC or Macintosh. This is the concept
of computer program reliability.

An enormous amount of work goes into writing a computer program used
by a project like Galileo. We all know that the computer and computer
programs can make our lives and jobs easier, but if we have a computer
program that makes mistakes, the more we depend on it, the more
trouble we get into. For example, there is a "pocket calculator"
program in a recent version of Microsoft Windows that makes an
arithmetic error when you "subtract" 3.10 from 3.11. On the calculator
you get an answer of 0.00, instead of the correct answer of 0.01! This
is known as a software "bug".

The term "bug" comes from the old days when computers were the size of
a room. Sometimes an insect would actually crawl into the machinery
and cause electrical problems!

At JPL we realize that as computer programs get more and more complex
(sometimes the list of computer instructions can be 100,000 lines
long!), it is very difficult to makes sure there are no bugs.
Therefore, we decide to assign a reliability category to each program
and this determines how much time we will spend eliminating "bugs".
Software programs called Category "A" are so important to the Galileo
mission that we do a huge amount of testing to eliminate bugs and we
call a special review meeting to report the test results. The people
who are on this special committee ask a lot of tough questions and if
they come up with some idea that the tester did not think of then it's
back to the testing laboratory! It's sort of like doing the wrong
essay questions at the end of a chapter in your history book - BUMMER!
Go back and do your homework right!

A coworker named Kevin and I recently made some major changes to a
Category "A" software program used by the Mission Control Team. This
program, called SEG (for Sequence of Events Generation) collects
information about spacecraft activities and our Deep Space Network
system of radio tracking stations from around the world and combines
them all into the daily schedule of key events. This "daily journal"
is used by our people at Galileo Mission Control at JPL, called the
"Aces", who monitor the spacecraft 24 hr. a day. Although the SEG
program has been used successfully for six years, we had to make some
special changes to it because of the new computer software being
installed on the Galileo spacecraft in the Spring of 1996 (Yes, that
software is ALSO Category A!).

For this testing program, the Project wanted me as a "user" of the
software to design a really tough series of tests to meet two
objectives: First, make sure that in this new version no "bugs" were
introduced that caused us to not be able to do things we could do
before (this is called a "regression test"). Secondly, we had to make
sure that the new capabilities of the software would work, for example
recognize and report in the schedule the new kinds of spacecraft
computer commands.

My colleague Kevin is actually the engineer who wrote the original
version of the SEG program many years ago. I think that you can
understand that it is very important that the person looking for
mistakes in the software should not be the same person who wrote it. I
know that whenever I write a long essay, I always ask a friend to read
it over for spelling and grammatical errors. We also take this same
approach at JPL and it is part of what it means to be a professional -
nobody's perfect but we all work together as a team to make the
mission a success.

Anyway, our testing program was apparently the toughest one ever done
on the SEG software and when we reported our results to the review
committee they were very pleased and felt comfortable that this new
version was free of bugs. We put in many hours of overtime, and didn't
get much sleep, but we got the job done and even met our deadline!

November 2, 1995
It has been a depressing two weeks since the Galileo tape recorder
was found to have stumbled trying to rewind to where the first
global Jupiter image was stored. Worried that we might not have
a tape recorder for the mission, the project managers sent a lot
of us off to study how we could get data back without the tape
recorder. We met for two weeks, and two full Saturdays, and came
up with a way to do it: take all the computer memory that is
devoted to tape recorder programs, and make room to store data
Earth from the memory directly.

This makes it hard to get many images, since they take up so
much room. But a lot of other good science can be done without
images.

So why the depression? Because it was decided that until engineers
understand the tape recorder performance better, the project will cancel
all the remote observations of Jupiter and Io as we approach the planet.
That means, no pictures of where the Probe will fall in. No
pictures of the bizarre moon Io from just 1000 km away. No
temperatures of its volcanic surface. The project managers want
to ensure that the Probe data will be successfully recorded on
the tape, and most other use of the tape is put aside.

As a scientist, it is depressing to see so many wonderful science
opportunities that we had coming in to Jupiter disappear like that.
We understand the need for conservative engineering when something
as important as the Probe data is on the line. But people have
thought about these last few days before Dec. 7 1995 for many
years, and planned every second in a long integration process, and
then had the sequence of events checked and rechecked. We generated
piles of paper, and lots of computer files, and plots, and spent
endless hours meeting, compromising, negotiating. And now it is
decided not to do any of it, because the tape recorder coughed.

We have a lot of good stuff yet to come, and we need to get back
to planning for what happens AFTER getting into orbit on Dec. 7.
But the loss of our very special plans will take a while to put behind
us.