3-Feb-86 17:52:52-PST,13055;000000000000 Mail-From: NEUMANN created at 3-Feb-86 17:50:46 Date: Mon 3 Feb 86 17:50:46-PST From: RISKS FORUM (Peter G. Neumann, Coordinator) Subject: RISKS-2.5 Sender: NEUMANN@SRI-CSL.ARPA To: RISKS-LIST@SRI-CSL.ARPA RISKS-LIST: RISKS-FORUM Digest, Monday, 3 Jan 1986 Volume 2 : Issue 5 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: SRBs and What the Computers Should Monitor (Sean Malloy, Charley Wingate) SRB survival (Bill Keefe) Physical Security at the Cape (Tim Wicinski) A hard rain is gonna fall, (Marc Vilain) Correction re Galileo plutonium (James Tomayko) Quebec Election (Dan Craigen) SCRIBE time-bomb goes off! (Peter G. Neumann) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA.) (Back issues Vol i Issue j stored in SRI-CSL:RISKS-i.j. Vol 1: MAXj=45) ---------------------------------------------------------------------- Date: Mon, 3 Feb 86 07:14:54 pst From: malloy@nprdc.arpa (Sean Malloy) To: RISKS@SRI-CSL 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", >etc. 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 (malloy@nprdc-arpa) ------------------------------ Date: Mon, 3 Feb 86 14:00:39 EST From: Charley Wingate To: RISKS@SRI-CSL.ARPA 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 ------------------------------ Date: Monday, 3 Feb 1986 07:45:51-PST From: keefe%milrat.DEC@decwrl.DEC.COM (Bill Keefe) To: risks@sri-csl.ARPA, keefe%milrat.DEC@decwrl.DEC.COM 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 ------------------------------ Date: Mon, 3 Feb 86 07:41:52 est From: Tim Wicinski To: risks@sri-csl 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 ------------------------------ Date: Mon 3 Feb 86 15:18:48-EST From: Marc Vilain Subject: A hard rain is gonna fall. 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. ------------------------------ Date: Monday, 3 February 1986 11:40:09 EST From: James.Tomayko@a.sei.cmu.edu To: RISKS@sri-csl.arpa 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. ------------------------------ Date: Mon 3 Feb 86 14:43:55-CST From: Dan Craigen Subject: Quebec Election 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...) dan ------------------------------ Date: Mon 3 Feb 86 02:05:07-PST From: Peter G. Neumann Subject: SCRIBE time-bomb goes off! To: RISKS@SRI-CSL 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 working. Peter ------------------------------ End of RISKS-FORUM Digest ************************ -------