[sdiy] Ahhh...so I'm not the only one...

[Cornutt, David K]

From: Scott Stites [mailto:scottnoanh at peoplepc.com] 

> Actually, it was the sensor and not the gauge, and failure of 
> a sensor *could* send them plunging to their deaths if it 
> happened at the wrong time (which is about anytime throughout 
> the lift off phase of the mission).  When the fuel gets near 
> to empty, the engines shut off automatically before before 
> the external tank is completely empty.  

OK, I know it's OT, but I've got to jump in on this...

Like nearly everything that is flight-critical on the Shuttle,
the tank sensor system is heavily redundant and uses several
approaches to make sure that one fault doesn't lead to a 
catastrophe.  The standard for flight-critical subsystems is
at least "two fault tolerant", which means that any subsystem
should be able to survive two component failures and still
have the spacecraft be capable of flying nominally.  (Many
of these subsystems are actually three fault tolerant.)
So here's how the redundancy on the tank sensors works:

First of all, the launch rules require that all four sensors
be working at launch -- no launching with a known fault.
Of course, the sensors are observed before and after tanking
to make sure they report the expected state.  There is also
a built-in test circuit that is triggered about two hours before
launch, that tricks the sensors into thinking that they are
"dry", as part of an automated test.  This is the test that
stopped the count last week -- when they ran it, one sensor
continued to report "wet" during the test.  

Second, the tank sensors are actually ignored during most of
the flight.  The onboard computers know, from the amount of
fuel loaded, the launch weight, and the trajectory, how long
the engines need to run to achieve the orbital velocity.  
On a nominal Shuttle ascent, main engine cutoff (MECO) will
be at about 8:30 after launch, give or take about 15 seconds.
In a normal launch scenario, the computers command the MECO
at the time computed by guidance.  At this point enough
fuel is left in the tanks so that all of the sensors still
read "wet", and therefore they never come into play.  
Secondly, there is the possibility that incorrect data in
the guidance computation will lead to an incorrect cutoff
time computation.  For that reason, the software contains a
second path of execution which is simply a timer; at a given
time (which is maybe 10 seconds after the planned cutoff time),
if the engines are still running, the timer will command MECO.
Thirdly, the crew also has a time cue in their cue cards.  
At a given time after the nominal time (I'm not sure when),
if they engines are still running, they will shut them off.

However, there is the possibility of a leak, or a mixture shift
in an engine that causes asymmetrical burning of the propellants.
To allow for this possibility, the onboard software starts paying
attention to the tank sensors at around 7:30 after launch.
Each tank has four sensors.  If any two sensors in either tank
read "dry", the software will command MECO.  This is to avoid
the possibility of a tank running dry, which would allow gas
to enter the engine turbopumps leading to an overspeed and
probably a catastrophic failure.  However, if the MCC identifies 
after launch that a sensor is giving a false reading of "dry", 
they can send a command to the onboard software to ignore 
that sensor.  

Of course, there are 
> four sensors for redundancy, but why risk it?

Well, there is a group that is going back and re-looking at
the rationale for having all four sensors operational.  That
assessment is based on redundancy and maintaining the two-fault
tolerance standard.  It's good to go back and look at these
things sometimes, if for no other reason than to refresh everyone's
minds on why those decisions were made in the first place  
(given that the people who originally made them are probably
long gone).  However, the general feel seems to be that the
existing standard will be re-validated and the launch commit
criteria won't change.  There is a bit of a difference between
what you are willing to tolerate once you are flying, and what
you want to launch with.  In general, you want to launch with
as perfect a vehicle as possible.

As for the "shaking the wiring" bit:  Don't underestimate the sheer
amount of wiring in the Shuttle (miles and miles of it) and the
very unusual environment that it has to operate in.  Launch 
vibration is a particular problem.  The connectors are about the
best that money can buy; they are flight-certified versions of
the big circular zillion-pin Amphenol connectors that start at $20
a pop in the Mouser catalog for the very smallest ones.  There is
almost nothing that those connectors won't survive as long as they
remain mated, but bent pins have been known to happen when they
are disconnected and reconnected.  (And by "shaking the wiring",
what they are actually talking about is mostly just nudging them
a bit in the vicinity of the connectors.  The actual wire runs
are pretty well strapped down and aren't shakable anywhere.)

My own personal feel (and this is just me talking; I'm not speaking
for NASA or Boeing, etc.) is that it's a signal conditioning problem.
The basic nature of the problem is that the sensor state lags
waaay behind what is actually happening in the tank; it's as if
someone plugged it into a lag processor and set it on 4 hours/volt.
There's something very analog-ish about the behavior.