The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 2 Issue 05

Monday, 3 Jan 1986


o SRBs and What the Computers Should Monitor
Sean Malloy
Charley Wingate
o SRB survival
Bill Keefe
o Physical Security at the Cape
Tim Wicinski
o A hard rain is gonna fall,
Marc Vilain
o Correction re Galileo plutonium
James Tomayko
o Quebec Election
Dan Craigen
o SCRIBE time-bomb goes off!
Peter G. Neumann

Sean Malloy <>
Mon, 3 Feb 86 07:14:54 pst
Subject: Solid Propellants and What the Computers Should Monitor

 >Date: Sun, 2 Feb 86 14:08:17 est
 >From: mikemcl@nrl-csr (Mike McLaughlin)
 >Subject:  SRBs and What the Computers Should Monitor

 >Another result could be that the errant jet impinged on the main fuel tank,
 >heating, penetrating, and igniting the fuel load. (It might be able to ignite
 >it without penetrating the tank structure.)  *This should be quickly detec-
 >table by excursions in tank pressure.*  Reaction times, even of computers,
 >might not be fast enough to make any difference in the outcome.

>I believe that both of the above could have been detected with instrumentation
 >that was certainly on board.  Additional (or existing?) instrumentation could
 >detect temperature changes in SRB and fuel tank skins, torques on SRB mounts,
 >abnormal "seismic" vibrations within the SRB structure, abnormal "plumes",

One of the points that was brought up during the broadcasts the day of the
disaster was that the telemetry tapes were going to have to be analyzed to
determine if there was any indication as to what happened.  The temperature
data for the external tank was specifically mentioned as one of the
telemetry streams that was NOT fed to a display in either the launch control
area or Mission Control. The NASA spokesman explained that there was so much
information coming in that a decision had to be made to limit what the
launch control personnel had to pay attention to.

This brings up a much more subtle problem in risk evaluation -- what data is
considered relevant to the task at hand? A line has to be drawn between
significant and extraneous data, based on the processing capacity of the
system/personnel interpreting the data. NASA had decided that the ET
temperatures were not of immediate use to the launch control personnel, and
simply recorded the data.  In the previous 24 shuttle launches, they were
right; in this case, they were wrong. In the future, they probably will have
someone monitoring that data. What also has to be considered in the decision
is what can be done on the basis of a given stream of data. I don't know how
long the ET temperatures would have been elevated before the explosion, so I
don't know whether there would have been time to recognize the problem,
identify the source, and jettison the SRBs. If you can show that there won't
be enough time to react properly, then giving someone responsibility for
making the right decision in that situation is asking someone to volunteer
to have a nervous breakdown.

In retrospect, there should have been immediate scrutiny of the SRB
performance. Looking at the pictures of the exhaust trails after the
explosion, one of the SRBs is looping away from the blast apparently
undamaged, while the trail from the other proceeds straight for a
short distance, then peters out abruptly. Why would one survive
unscathed while the other one was badly damaged unless something
happened with or adjacent to the SRB? Hindsight is always 20/20.

        Sean Malloy

Charley Wingate <>
Mon, 3 Feb 86 14:00:39 EST
Subject:   SRBs and What the Computers Should Monitor
Organization: University of Maryland, Dept. of Computer Sci.

  >  If this [new plume]
  >was a casing/grain burn-through, the mildest result would be assymetric
  >thrust.  *This should have been immediately detectable by the guidance
  >system's reaction in attempting to maintain the desired trajectory.*  If
  >similar pert[u]rbations occurred in wind shears, etc., it might not be
  >recognizable as abnormal.

In fact, the shuttle was just passing out of an area where wind shear is
common.  If you look at the trail that was left, there appears to be a sharp
jog just before the plume enters the base of the fireball cloud, suggesting
either wind shear or perhaps the thrust from the extra hole.  It's also
possible that the thrust from the spurious plume would be too small to be
noticed (which I believe is in this case a matter of several percent).

  >Another result could be that the errant jet impinged on the main fuel tank,
      [... see above message ...]

Judging from the film, this seems unlikely, although localized overheating
could have occured and caused a failure.

  >Those of us discussing this were momentarily satsified until somebody
  >asked, "Yes, but how do you tell which SRB is which??!"  ...

Actually, the shuttle is within visual range throughout the SRB boost phase,
if I remember correctly.  The two boosters could be distinguished by
painting a different roll pattern on each.

As far as risks are concerned, I think that the one point of all of this is
to illustrate the value of collecting data even if you can't immediately use
it to determine what to do.  There seems to be a consensus, for instance,
that temperature readings on the ET and the removed sensors on the SRBs were
useless under normal circumstances.  It was immediately apparent how
valuable they would be in illuminating the failure that did finally occur.
It will be interesting to see if NASA's philosophy changes as a result of
the accident.

Charles Wingate

Bill Keefe <keefe%milrat.DEC@decwrl.DEC.COM>
Monday, 3 Feb 1986 07:45:51-PST
Subject: SRB survival

That both SRB's survived, while the shuttle didn't, makes me wonder how the
structural integrity of the SRB's differed from the shuttle in allowing
them to survive the explosion.

        - Bill Keefe

Tim Wicinski <wicinski@nrl-css.ARPA>
Mon, 3 Feb 86 07:41:52 est
Subject: Physical Security at the Cape

I believe someone asked about the security out at the Cape, I have some good
first hand knowledge about it.  I have been to over a half dozen launches
and/or attempted launches at the Cape, and I worked there for a few months
as a Contractor during a few launches.  A few days before a launch the Air
Force closes off the beaches north of the Cape for a good distance (over 3
miles) as well as some of the beaches south of the Cape.  I believe they try
to keep visitors away from the launch site at a distance of about 4 miles,
which is is how far away you see the launch if you get a car pass from Nasa.
The press and VIP's sit only 2.3 miles from the launch pad, and they have a
hard time from the guards getting there (I once viewed the launch from
here).  Also, planes are allowed in a restricted air space around the Cape,
but you are still a good distance from the launch itself, and with Air Force
jets patrolling the area to make sure of this.

On launch days when I worked at the Cape, I usually had my car searched,
and a few times they put in spot check points to make sure no one was going
where they weren't supposed to.  At every launch the security I felt was
very good, but I guess there is always somewhere where there could be
a place where someone could get in undetected, it is a big place.

--tim           wicinski@nrl-css        {umcp-cs decvax}!nrl-css!wicinski

A hard rain is gonna fall.

Mon 3 Feb 86 15:18:48-EST
To: risks@SRI-CSL.ARPA

   Larry Shilkoff observed in RISKS 1-45 that future shuttle missions have
(or maybe had) been planned to carry plutonium-powered spacecraft, the
Galileo probe in particular.  Had Challenger carried such a spacecraft,
Southern Florida would have been exposed to substantial plutonium fallout.

   This brings up a similar issue with the Strategic Defense Initiative.  In
a recent Forum article in New Scientist (16 January 1986), physicist Raymond
Harrowell considered the after-effects of a *successful* interception of
Soviet ICBM boosters.  He looked at the levels of radioactive fallout that
would ensue from the return to Earth of disabled ICBMs and their warheads.
Quoting from his article:

  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.

   Most of the technical discussion of the risks in deploying the SDI has
focussed on its failure modes.  Harrowell's analysis brings up another face
of the problem, namely that the success mode of the system may be so
narrowly defined as to ensure significant, if not unacceptable, risks --
whether the system succeeds or fails.

   The regrettable lesson, is that success of an engineering
application, if defined overly narrowly, may not be success at all.

   marc vilain.

PS: Full reference to the article: Raymond Harrowell, "Debris that
shatters the star wars myth", _New Scientist_, 16 January 1986, page 55.

Monday, 3 February 1986 11:40:09 EST
Subject: Correction re Galileo plutonium

Re my post dated 31 January:

>...aside from several hundred pounds of plutonium.....(onboard Galileo)

Make that 24 pounds---sorry for the mistatement.

Quebec Election

Mon 3 Feb 86 14:43:55-CST
To: risks@SRI-CSL.ARPA

Naturally I was somewhat interested in Lamy's comments on the Quebec
election (1981) and I.P. Sharp's role.  I was only marginally aware of the
details involved and thought I should check the facts.
                                                   [Dan is at IPSharp.  PGN]
Lamy is essentially accurate in his comments. His message does,
however, seem to indicate that there was an error in the APL language
interpreter. Such was not the case -- it was a programming error.
A case could possibly be made that the programming styles that have developed
around the APL notation led to the resulting situation. (But there
are always penalties that arise from using any notation...)


SCRIBE time-bomb goes off!

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Mon 3 Feb 86 02:05:07-PST

At the same time over the past weekend, SCRIBE stopped working on several
(but not all) SRI computer systems.  There was some sort of accidental
latent time-bomb in the UNILOGIC software (other than the expected annual
crypto-lock time-bomb that goes off annually to prevent people from merrily
copying SCRIBE and using it indefinitely or without paying their dues).
This is a fine example of software that has always worked suddenly no longer


Please report problems with the web pages to the maintainer