Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The following is excerpted from this Sunday's New York Times. It may
be somewhat old news to some, but does a good job of summarizing much of
the evidence and arguments surrounding the Challenger's computers.
SHUTTLE EXPERTS DOUBT COMPUTERS COULD DETECT FIRE
By David E. Sanger
The computers and sensors that guided the flight of the space shuttle
Challenger appear not to have been programmed to detect flames burning
throught the sides of a solid-fuel booster rocket, experts familiar with the
shuttle system said yesterday.
Their comments came as evidence accumulated that the right-side booster
began to fail as much as 10 seconds before the explosion that destroyed the
craft, as reported yesterday in the New York Times.
Even if the sensors had picked up the first signs of fire, safety
measures built into the system to protect the astronauts would have
prevented the shedding of the giant external fuel tank that exploded soon
after, NASA officials and the computers' designers said.
Only From Pilot
That command could have come only from the pilot, and officials said they
doubted even that could have saved the crew.
...
Experts who have studied the shuttle's computer system say it was not
programmed to separate the orbiter automatically from its fuel supply in
part because of the fears that faulty sensor readings could cause the
computers to abort a mission unnecessarily, risking the lives of the crew.
Preparation for Emergencies
Still the possibility that there were signs of trouble as long as 10
seconds before the explosion raised some questions yesterday about the
enormously complex equipment that guides the shuttle.
...
"The possibility that a booster might burn through could well have
been a failure mode that was never considered," said Alfred Spector, a
Carnegie-Mellon professor who two years ago conducted a study of the
computer system guiding the shuttle.
NASA officials said little publicly in response to the report that
data sent from the shuttle showed a sudden drop in the power of the
right booster rocket about 10 seconds before the spacecraft exploded.
But computer experts said the computer's response to such a power drop
may have been executed flawlessly. The program, they said, was primarily
designed to correct for the effects of an uneven rocket thrust by swiveling
engine nozzles to the side, keeping the shuttle on course. Sources close to
the situation say that the ground data show that the nozzles had in fact
swiveled to one side.
In the absence of other danger signals, however, the computer would not
have searched for the cause of the power loss. And the initial signals
apparently indicated only a 4 percent decrease in thrust, a figure that the
computer, or the cabin crew and officials at the Johnson Space Center in
Houston, may have judged did not indicate a serious problem.
...
[End of excerpt]
According to this morning's LA Times: - Early shuttle flights had sensors on the SRBs to monitor performance, but they were removed to save weight when it was felt that the SRBs were performing well. The sensors monitored pressure, temperature and vibration in the SRBs. - Two Rockwell officials familiar with the NASA inquiry said that NASA data shows that the 3 main engines experienced a power loss just before the explosion. The power loss was noted between one-tenth and one-one hundreth of a second before the explosion. The SRB that probably caused the explosion suffered a 3% loss of power (about 100,000 pounds of thrust) seconds before. - NASA noted that even if there were sensors on the SRBs, little can be done to save the crew if there is a problem during the first 2 minutes during the flight. They might be able to jettison the SRBs, but it would be difficult to stay clear of them and the external tank. And another NASA spokesman said later that the crews don't train for that maneuver, and that NASA documents state that such an escape is possible only after the SRBs have completed firing. The shuttle would have a near-impossible task of ditching in the ocean if it was able to steer clear of the SRBs and the ET. - Other Rockwell sources said that telemetry shows that the external tank experienced an increase in pressure in both the oxygen and hydrogen tanks, and that pressure relief valves in both tanks popped to decrease some of the pressure. Could the crew have survived had they known about the problem? Who knows? Maybe, if they had known about the SRB problem in time, if they had been able to get away from the SRBs and the ET, and been able to ditch successfully in the ocean. That's a lot of ifs... I wonder if NASA is going to think twice about removing sensors after this... Mike Iglesias University of California, Irvine
[Re Marty Schoffstall, on plutonium batteries for pacemakers and satellites:]
Note that the Soviet satellites use reactors, not isotope capsules, as
their power sources. The two are quite different, especially in this
context. It's not practical to encapsulate a reactor the way the isotope
capsules are armored against possible accidents.
[Re Larry Shilkoff, on Galileo:]
The capsules used to hold plutonium 238 (note that this is not the
fissionable isotope used in reactors and bombs) for deep-space power
sources are designed to withstand uncontrolled re-entry, and I think
to withstand launch accidents as well. Quite likely they would have
survived intact. There have been a few re-entries of satellites carrying
such capsules, and one went into the Pacific with the lunar module of
Apollo 13. No dire results.
[Re James Tomayko, on Centaur aboard shuttle:]
Apart from the volatility, this is nothing new: major solid-fuel motors
routinely ride in the cargo bay. Those things are dangerous too. People
doing some of the amateur-satellite work have estimated that the paperwork
needed to clear a satellite for a ride in the shuttle cargo bay roughly
triples if it is carrying any substantial rocket motor, solid or liquid.
> Worse yet, Galileo was to be the
> <first> user of the new upperstage, which shares little with its predecessor
> except the name. It has new tanks, engines, and instrumentation...
Not quite true: the Ulysses solar-polar mission, using the same upper
stage, was to launch about a week before Galileo. Still awfully tight.
> [in an abort] what are the dangers of trying to land with a full load of
> hydrogen and radioactive isotopes? ...
Actually, although the liquid hydrogen is what everyone points at, the
liquid oxygen is probably the greater danger. "Stages to Saturn", the NASA
history of the Saturn boosters, commented that liquid hydrogen hazards were
found to be comparable to those of highly-volatile gasoline (not trivial,
mind you!), while it was liquid oxygen that really needed extraordinary
handling precautions.
[Re: Jeff Siegal on NASA/KSC physical security:]
It's not conspicuous, but it's there. Practically nothing is said about
it in public. I was down at the Cape for the 41C launch, on the National
Space Institute tour. We got (I think) a slightly closer look at things
than the ordinary KSC tours, but when we went past the actual active pad
a day or two before launch we were cautioned that (a) the bus could slow
down but it must not stop, and (b) all windows, including the driver's
little vent window, must stay 100% shut. With a strong indication that
we were being watched and our NASA guide would be in deep guano if either
rule was violated even momentarily. We went past some press folks setting
up cameras, and our guide commented "if you're wondering why they're allowed
out of their bus and you aren't, it's because they've been searched and you
haven't". The pad area proper also has an impressive concentration of
things like concertina wire (think of it as industrial-strength barbed wire)
around its perimeter. It's difficult for a non-professional to evaluate
the quality of the precautions, but they did seem to be taking it seriously.
I have since heard a rumor that there were some awkward and hushed-up
incidents quite early in the Shuttle program that caused considerable
tightening of the original fairly loose security.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
[We may be approaching the point of no return on some of the second-
and third-order discussion. PGN]
If we're going to talk about SDI and WWIII rather than computers, please, let us at least use responsible analysis. Vilain quotes Some simple calculations indicate the likely consequences of SDI interceptions of Soviet ICBMs. A Soviet first strike could involve the simultaneous launching of some 5000 nuclear warheads at targets in the US. If only 20 percent of these warheads, each containing 10 kg of plutonium 239, are disintegrated (without a nuclear explosion) in the northern hemisphere, about 10^13 lethal doses (if inhaled or ingested) of alpha-emitting plutonium would be released — about 5,000 doses per person in the northern hemisphere. If that radioactive debris were distributed uniformly, there would be one lethal dose for every 25 square metres of the northern hemisphere. Not all the radioactive material will have immediate effects on Earth but, however delayed the fallout of stratospheric plutonium might be, its long half-life (24,000 years) would ensure its eventual arrival at altitudes likely to be occupied by human beings, other animals and plants. This arithmetic [of?] "simple calculations" is irrelevant. The "if"s are totally bogus. Every year, the US spreads about one fatal-dose per person of Arsenic Trioxide onto food-plants via crop-dusters. And how many fatal doses of salt does Connecticut spread on the roads every winter? If you believe the quote, everyone in the northern hemisphere is already dead (more than one fatal dose per person) from the atmospheric bomb tests of the '50s and 60's. Bob
risks@SRI-CSL.ARPA
From: Marc Vilain <MVILAIN at G.BBN.COM>
This brings up a similar issue with the Strategic Defense Initiative.
If that radioactive debris were distributed uniformly, there would be
one lethal dose for every 25 square metres of the northern hemisphere.
Bad assumption. Most of boost-phase intercept occurs over the Soviet Union.
The regrettable lesson, is that success of an engineering
application, if defined overly narrowly, may not be success at all.
This general point is well-taken, despite my comments above. As they
say, "The operation was a success but the patient died."
I thought the following incident fits into RISKS. Recently one of our
people moved from our Philadelphia corporate headquarters site
(thousands of employees) to our new Atlanta Development Center (only
dozen or so on board at the time.) He sent the appropriate change of
address notifications into the publishers of his professional journals.
("change my address, P.O. Box xyz, Blue Bell, Pa., to P.O. Box qrs,
Norcross, Ga.", or words close to that.) Shortly thereafter our poor
office secretary and part-time mail clerk down there was inundated with
mountains of journals from one of those publishers. We don't know
exactly what happened, but apparently the software used to maintain the
circulation list was instructed, and dutifully did so, to "change all
addresses that match" (which, I guess, would be used to move a
household) rather than "change this particular subscriber record":
every single journal by that publisher addressed to our corporate
headquarters (modulo spelling variations, I presume) had by a handful of
keystrokes been redirected elsewhere. The publisher involved shall
remain nameless (not ACM, that would make too nice a story) but it was
one dealing with the computer field. The problem appears to have been
fixed, naturally the fix taking the usual "six weeks", whereas the
original error, naturally, happened in a couple of days.
Please report problems with the web pages to the maintainer