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…
This morning I talked to my successor at the Cape, who was in the Range Safety
area during the launch. I've got a few things to report and some questions to
answer from previous issues. I found out that the Range Safety Officer
commanded the destruction of the SRBs approximately 20 sec after the main
explosion, as they were careening wildly away from the site. Both SRBs did
explode on command. The mood at the Cape is described as "devastated",
especially among those who went outside to watch live. My successor also
reported that Range Safety had been officially cleared as of yesterday,
with respect to any responsibility for the accident; but that they expected
*much* closer scrutiny than before (which is, of course, perfectly fine.)
Interestingly, many of the media and a large percentage of the general public
were not aware of the existence of the destruct system.
The latest theory I have heard contains a "leak" in one of the SRBs resulting
in a 6000 C jet of flame cutting into the tank and igniting its fuel.
Now, individual responses:
> From: John Carpenter
> As I read the article [by Martin Moore in RISKS-1.43,] it occurred to me
> that as we discuss the risks of the destruct system we could be creating
> another risk by revealing the nature of it's operation...
> If the destruct system is public information, I would like to know why,
> If it isn't, it certainly has no place on the net.
Your point is well taken, and I did have some misgivings about posting the
original article; not because I was revealing anything I shouldn't, but
because I have no wish to be drawn into a national media controversy. Hence
the restrictions on dissemination of the article. None of the information in
the article was classified, and all of it was publicly available; and NASA is
very good about providing access to any information that isn't classified.
As to *why* it is public information...I think Neumann's response in 1-45
sums this up pretty well. Also, if it's not public, then the question that
will be raised is "what are they hiding?"
Incidentally, my successor told me that there is an article in this morning's
(1/31) Orlando Sentinel about the destruct system, at about the same level
of detail as my article in 1-43. Would some Central Florida reader be kind
enough to send me a summary or a copy of that article?
> From: Jeff Siegal <JBS%DEEP-THOUGHT@mit-eddie.MIT.EDU>
> Is there someone who knows enough about the security at NASA/KSC to be
> able to estimate the difficulty that a malicious party would have in
> getting getting physical access to the shuttle/SRB/MFT prior to the launch?
I'm not a physical security expert, but I believe that it would be
extraordinarily difficult to get physical access to the shuttle itself at
any time. Regarding the possibility raised by Kyle of a rifle shot, NASA
maintains a "clear zone" 1.5 miles (I think) in radius around the shuttle when
it is on the pad. This includes the closing of a public beach while the
shuttle is on the pad, invariably causing complaints from some local citizens.
> From: b-davis@utah-cs.ARPA (Brad Davis)
> It also brings up an important question. If the hardware system is
> redundant, what about the software system? Is the same software running
> on all of the redundant hardware systems or are there more than one
> software packages developed. If there is only one software package then
> if one system fails due to a software failure then the other systems'
> software may fail since the same conditions may still be in effect.
Each member of a redundant set runs the same software (obviously, computers
with different functions run different software). The danger you note is a
real one; however, I believe the best solution is to make each piece of
software as robust and fail-safe as possible. Consider that if redundant
computers were running different software, you could have a failure of
computer A and switchover to computer B without being able to reliably predict
what computer B was doing at that instant! The whole idea of redundancy is
that if a tool breaks in my hand, I want to be able to slap another one of the
same kind of tool into my hand and not miss a beat. What your point leads to
is to have additional tools for cases where the first one doesn't apply; this
is a good idea, but it actually falls under the heading of "robustness" rather
than "redundancy."
mjm
>Date: 30 Jan 86 09:23:53 PST (Thu)
>From: Peter G. Neumann <Neumann@SRI-CSL.ARPA>
>Subject: Possible triggering of the self-destruct mechanism
[The physicist ... who speculated that the explosion in the solid-fuel
rocket booster set off the self-destruct mechanism ... suggested that it
could not have been a hydrogen leak because hydrogen burns clear and the
Shuttle explosion had an obvious orange glow] is a classic example of what
happens when people overspecialize themselves. Here we have a physicist
making inaccurate statements about a fact of chemistry. I would suggest that
this physicist watch the film of the Hindenberg disaster, and watch the
bright, opaque flames of hydrogen burning in an insufficient quantity of
oxygen for complete consumption. Only when hydrogen has a sufficient
quantity of oxygen to burn completely does it burn with a clear blue flame.
One of the problems that this brings up is the tendency of the average
person to regard any statement made by a scientist about a scientific
subject as being correct because "they've been trained in science, so they
know what they're talking about", whether they are making a statement within
their field or out of it. Particularly when a scientist says that something
is impossible or impractical. Too many scientists over history have delcared
something impossible or impractical that is commonplace today to reject some
line of research because of such pronouncements.
>Date: Thu 30 Jan 86 20:22:37-EST
>From: Jeff Siegal <JBS%DEEP-THOUGHT@mit-eddie.MIT.EDU>
>Subject: The Challenger [non]accident
>I have heard speculation that some fuel leaking (LHY or LOX) from the
>MFT and a unexpected flame could be seen (on slow-motion videotape)
>for some time prior to the explosion. This seems consistent with
>rifle bullet impact/puncture, long before the actual explosion
>occured.
This is one of the possibilities that the NASA investigating board is
going to be looking at. However, the existence of the flames in the
turbulent area just aft of the external tank is also consistent with a
leak in the fuel pipes from the external tank to the orbiter.
If it did occur from an external impact, then the leak would have to
have started after the shuttle had taken off, because the plume of
escaping LHY would have caused enough condensation to be visible on
the gantry monitors, a situation that would have halted the launch. I
don't know of any way that someone shooting at the shuttle could be
sure that the bullet would only damage the tank enough to fail at max
Q, rather than penetrate and start a leak immediately. Or, failing
that, to hit the external tank after launch, with the shuttle rolling
and pitching into its climb attitude.
Sean Malloy
(malloy@nprdc-arpa)
But the news has consistently been reporting that, after the explosion that
destroyed Challenger, the Air Force used the destruct mechanism to destroy
the boosters (?) because one had gone off course and threatened populated
areas. If this is true, can we not assume that the destruct mechanism did
not cause the accident? Is it not a 'one time only' capability?
Brint
[As Martin Moore said in RISKS-1.43, there are FIVE destruct receivers:
one on the ET and two on each of the SRBs. I was talking about the one
on the ET; the SRBs somehow survived until they were intentionally
destroyed. PGN]
From: Jeff Siegal <JBS at DEEP-THOUGHT.MIT.EDU>
I have heard speculation that some fuel leaking (LHY or LOX) ...
... This seems consistent with rifle bullet impact/puncture, long
before the actual explosion occured.
Depends on what you mean by "long". The licks of flame at the base of
the SRB occurred at most 2 sec before the main explosion. It was
going at 2900 fps, so at best its altitude would have been 1 nautical
mile lower when the bullet hit, meaning 8 nm altitude. Pretty far out
to imagine a rifle bullet hitting at that point.
There has been no public mention of the possibility of terrorism.
Terrorists claim credit for events. To my knowledge, no one has
claimed credit.
There is a point in the redundancy argument that has bothered me since I interviewed at Stratus a year or so ago. Using the Stratus example, they run two copies of what they call a dipole. One copy is "live" and one is shadowing the live one. Each dipole is two mirror image processors with a high-speed comparator in the middle. When the live module gets a miscompare, it lights a LED and hands control over to the backup module. The operating system is able to do whatever clean up has to be done to brief module 2 so that computing is essentially non-stop. (Oh, one little "goodie" is that the module connectors are designed so that *the customer* can pull out the lighted module and put in a new one without shutting off the machine.) Now the $64,000 question: isn't the compare logic a single point of failure? (Note that because in this example you have a total of 4 CPU's, this isn't necessarily a crash.) But in the shuttle version, as I understood it, the systems were only redundant and therefore a comparator or checker failure could, it seems, knock the system out.
I'm not sure how much information is publicly available on the generating
systems of various satellites but I would like to point out something that
has been published that is somewhat analogous: cardiac pacemakers.
As I remember it the plutonium powered ones were designed such that
the containment device could not be penetrated by:
- .38 special at 15 feet.
- cremation temperatures (natural gas)
- aircraft impact.
Obviously I am being very coarse here and I don't have the details but
I'm sure others do but if the above is "close" I'll throw out some
number estimates that I'm sure others will correct:
- .38 special at 15 feet, say 1000 feet/sec 300 foot-lbs???
- natural gas burns at 2000 degrees?
- say 9gs at impact?
The point is as follows: If pacemakers are designed to handle stresses
such as that I would assume that the satellites are designed much better,
especially since the Soviets dumped a load on Canada (did they ever pay
damages for that?).
marty schoffstall
Re Larry Shilkoff's note on Galileo carrying plutonium: Not only plutonium, but the spacecraft was to be deployed atop a new version of the Centaur hydrogen/oxygen upperstage used on the Atlas-Centaur and Titan III boosters. Therefore, aside from several hundred pounds of plutonium the Shuttle would be carrying several thousand pounds of highly volatile fuel <inside> the cargo bay, adding considerable energy to any explosion. 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. In contrast to previous unmanned missions, only <one> Galileo has been built. Considering that the cost of building a second one would only have been 15% of the cost of the first, NASA is taking a big chance by launching its only Jupiter orbiter on an untested upperstage, in view of the multiple failures of Shuttle-carried upperstages such as the IUS and various satellite kickstages. Sadly, the Galileo launch has already been delayed several years for various reasons (including one to switch it from the IUS to Centaur) and is likely to be delayed again. If the Shuttle fleet is not declared spaceworthy by May, the precession of Jupiter dictates a 13-month launch delay. Some of the parts of the spacecraft are nearly six years old now, and many have been in test for years on end. Even though the mission is projected to be shorter than Voyager, the spacecraft itself may actually "live" longer. As a footnote specific to the risks question, a friend of mine who is a an astronaut trainer for NASA said to me several months ago that crews training for Galileo and the Solar Polar launch also using Centaur were wary because of critical questions relating to aborts. If the Shuttle has to do a return to launch site abort or an abort to Africa before deploying Galileo, what are the dangers of trying to land with a full load of hydrogen and radioactive isotopes? The possibility of explosions never came up. Now it has to.
Yesterday I heard a radio report that a Swedish study found that video display terminals increased the incidence of birth defects in mice. Does anyone have more information on this? I have not previously heard of any controlled research in the area that has identified a hazard. I am interested in trying to find out what the results of the study indicated, whether it is a new result, and how credible it is. Dan
You realize, of course, that Martin Moore's fascinating and worthwhile
piece is accessible to *ANYONE* on the net who is allowed to use FTP by
their home site since SRI-CSL supports anonymous FTP logons and since
you have the RISKS back-issues in a public file.
[... or indeed from any BBOARD receiving RISKS,
not even necessarily on the ARPANET! PGN]
Ted
(For readers not familiar with it, ORCON is a handling marking in some
circles that means "further distribution only with permission of the
originator, i.e., ORiginator CONtrolled." It is a non-trivial task to
get a computer system to implement that handling marking in a secure but
natural way, especially across a network.)
[Yes, of course. Less obscurely, someone can even ask to be put on
the RISKS list, which I presume would permit me to send them the back
issue within the spirit of Martin's constraints. I think what Martin
may have been more concerned about was wholesale rebroadcastings.
So what we have is an experimental exercise in self-control, to see if
our network community is mature enough to adhere to his constraints.
I would be very interested in hearing of any postings contary to his
caveat. But you are very correct in suggesting that enforcing ORCON
is a nasty problem that cannot be adequately addressed in most computer
system environments today. That is one reason why overclassification
occurs. PGN]
Please report problems with the web pages to the maintainer